decentralized ID based on randomized peer-to-peer verification

lucas2lucas2 Member Posts: 5
a one year old post (http://forum.ethereum.org/discussion/comment/12827) had some interesting ideas.

It describes a proof-of-one-account ID system. The system sounds very reliable and i think it could become popular fast. The system matches random groups of people based on their location, and arranges meet-ups where these random peers sign each other's contracts and photograph each other.
This protocol relies on the fact that you cannot be in two places at once, and as long as you participate in a majority of your meetings, everyone can be sure that the identity you chose is your only identity within this system.
It's more invasive then friend-to-friend ID but could scale faster because if that. I'm thinking launch it and then let friend-to-friend IDs gradually replace it over the next 2-3 years.

I'm interested in developing this. I'll open this thread if anyone else is interested in developing it with me, and for conversations about the future of proof-of-one-account IDs.

Comments

  • tym4ttym4t Nagata-ku, Kobe-shi, Hyogo-ken, JapanMember Posts: 71 ✭✭✭
    Yes. I have some other ideas to actually make this work better. Please send me a PM with your e-mail and I can invite you to our Slack chat.
  • PofickPofick Member Posts: 8
    edited October 2015
    So what ideas do you have guys? Some clues maybe?)
  • ethereumnickethereumnick Member Posts: 49
    The name I like for a P2P distributed Identity system is VouchSafe.

    I pitched a similar plan to Vinay Gupta when I met him at P2P value in the spring, he made happy faces but he never replied to my emails so that went no where.

    In the old thread there is a comment about not liking the invasive nature of the system and problems of collusion. I don't have a problem with the “invasive” part as long as the information is kept at the edge of the system. As for collusion, at a large scale collusion becomes impossible the only thing I worry about is the boot strapping process.

    Here is my elevator pitch.
    Jury service is a cornerstone of Magna Carter.

    It is a system designed to conscript people into peer mediation because static power has repeatedly proven liable to corruption. Ethereum could use a random jury system to validate identity or other information, including leveraging pre existing identity systems or by extension to validate qualifications, births and deaths or anything else real world that needed to be validated into the system.

    To prevent jury stacking and collusion we need Pre selection. This may be handled by a contract that pares participants in reasonably close geographic locations (or when they are on holiday if you like) but the VouchSafe contract would not hold any of the validated information, it's function would be to administer the lottery and forward contact information to 'jurors'. Each participating account will have to perform VouchSafe validation at random intervals and in turn be validated at random intervals, so building up an “Identity” and “Persistence” that will be harder and harder to fake and more and more precious to preserve. This system will of course sit well along side a Friend of a Friend (FoaF) system but has the benefit of guarding against conspiracies of friends

    Alice and Bob live less than 20miles apart and have each signed up to VouchSafe (you want an ID you have to validate others too). The system randomly assigns Bob to validate Alice, Craig (one or many random referees in any geographic location) is nominated to provide each with cryptographic secrets to exchange so that the referees can validate that they have genuinely met in the real world. Alice and Bob are offered a zero knowledge communication channel which is escrowed through Craig who is the man-in-the-middle and can see all their coms in the clear to prevent fraud.

    Bob is presented with his afk retrieval task. The information given to Bob is limited as far as possible through the design of the communication channel, to the minimum required for this validation. He may be presented with the real world address that he is required to validate, along with a date and time dialogue from which to select preferred appointments and a question to ask when there. In this way he does not know if he is to validate the answer to the question, or the address or something else. So Bob now has a piece of target data to validate; it may be Alice's age or address or that she has the passport she claims to have or whatever.

    In our example Bob and Alice settle on a time and Bob goes to Alice's location and presents his half of the secret to Alice who in turn will reply with her half. Now they can each send their combined secrets to Craig as confirmation tokens and go back to their normal lives. If there is something 'wrong' then it is flagged for verification in a shorter time.
    Well that's what ideas I have, don't know if tym4t was thinking like this?

    Ta


  • geoffslittlegeoffslittle Member Posts: 1
    Hey all, is there a status update for this? I'm also interested in contributing.
  • ethereumnickethereumnick Member Posts: 49
    Yes.

    With a team of 2 (and a half) etherre.al came close to a prize at the hack.ether.camp and the rough demo is here.


    Unfortunately we all went back to other things, and for my part I'm working full time trying to make a living elsewhere at the moment. New blood, especially on the solidity side might make all the difference to getting going again so if your up for that them PM me.
Sign In or Register to comment.