Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 16.2K All Categories
- 9K Mining
- 509 Pool Discussion
- 1.3K General Project Discussion (non-technical)
- 430 Education
- 757 Protocol and Client discussion
- 149 web3-js
- 24 Whisper
- 12 Swarm
- 3 RLP
- 292 IoT & Hardware
- 990 Smart Contracts and Dapps
- 28 Serpent
- 336 Solidity
- 570 Projects
- 1.2K Reference clients code and builds
- 248 Eth & AlethZero- Cpp Implementation
- 462 Geth - Go Implementation
- 239 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 48 Mix
- 30 Other Implementations
- 159 Meetups
- 36 Other Events
- 196 Jobs & Skills
- 203 Press and Articles
- 74 Audio/Video
- 282 Ether Sale
- 1.1K Other Languages
- 87 Chinese
- 245 German
- 31 Italian
- 104 French
- 2 Hebrew
- 20 Japanese
- 66 Portugese
- 44 Romanian
- 172 Russian
- 214 Spanish
- 42 Turkish
- 118 Watercooler
Proposal for a 1-on-1 identity system protocol.
krl
Member Posts: 5 ✭
Having an identity system that more or less guarantees that each person can only hold one identity at a time would allow many things that would otherwise be vounerable to sybil attacks to be built.
The method i'm proposing relies on having meetings organized where people authenticate each other.
Let's call the code/procedure an identity contract.
It would work like this:
1. Register an name in the identity contract
2. Give your approximate positional data, this can be updated as you move around.
3. A few days before the date, participants in the contract are randomly grouped together based on location, and get invited to a channel to communicate a meeting point.
4. The people thus invited (maybe around 10-20 people, depending on how many are registered in this area) gather to the agreed upon meeting point.
5. At the meeting, each participant signs a statement saying who they met at the meeting, so that every person is signed by at least one other who was participating in this meetup.
6. The contract registers that the meeting was successful, and gives everyone involved one identity point.
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.
I have not been able to see any obvious attacks on this system, but maybe i'm missing out on something? Would love to hear your comments.
The method i'm proposing relies on having meetings organized where people authenticate each other.
Let's call the code/procedure an identity contract.
It would work like this:
1. Register an name in the identity contract
2. Give your approximate positional data, this can be updated as you move around.
3. A few days before the date, participants in the contract are randomly grouped together based on location, and get invited to a channel to communicate a meeting point.
4. The people thus invited (maybe around 10-20 people, depending on how many are registered in this area) gather to the agreed upon meeting point.
5. At the meeting, each participant signs a statement saying who they met at the meeting, so that every person is signed by at least one other who was participating in this meetup.
6. The contract registers that the meeting was successful, and gives everyone involved one identity point.
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.
I have not been able to see any obvious attacks on this system, but maybe i'm missing out on something? Would love to hear your comments.
Comments
Now even with such calculations perfect, you need a way to afterwards detect frauds and draw consequences from it. Next to signing parties, i think it might be good to also add 'detectives' that get paid when they find frauds, and convince the system of such. Of course, must be able to detect false positives.
The answer to the problem of registering fake accounts in remote places that vouch each other is the most interesting attack possibility.
How you might be able to defend against this is to only allow growth of new groups from actual people traveling to set them up.
The way i think this kind of approach makes sense, is really related to fraud and potential speed of growth.
If you want to quickly enable identity-trust in remote regions, a system like this would probably be faster to establish, than webs of trusts growing only at the edges of real personal connections between people.
A functioning 1-on1 system that is based on webs of trust is clearly more efficient, since you don't have to take part in these rituals, but it might actually offer some advantages.
Thank you for the constructive feedback so far, i do think this is one of the 'big ones' in these emerging technologies.
How do you deal with people claiming the same location as different somehow. I mean, i suppose you could do GPS locations, but maybe something like local areas like cities, or portions of cities in large cities is better. Maybe going to different places and 'registering' there might tie different cities together.
Might need some math thrown at it, also what sort of effort it takes And to figure out how to use the information. I mean, 'identity point' simply adding up is an idea, but what exactly does the number mean?
Something like approximate location would work well, GPS coordinates of the center of your city/district would work for the matching algo.
As for identity points, the contract would just have an api to return the successfully attended meetings in the last year or something, then other contracts could calculate compound scores based on this, for use in other automatic-trust systems.
The time of the meeting should probably be calculated from the longitude of the coordinate where the meetup will be 'centered', so that time-zone limits are harder to exploit.
I think i want to experiment with this as part of the Berlin based Blockchain Research Group. (which i forgot to announce on the forum, but will do now)
like, I extend trust to @krl, @krl extends trust to @Jasper
and design the web of trust so that you'd need X number of verifications to be included. each person could set the value of X.
the most extreme would be to have X = number of users, and then go downwards from there until you reach the minimal-trustable value for X
and combine with a hierarchy
and have another value, Y, for levels in a hierarchy
i extend authority to @vitalik, and I'd be Y-1 relative him
the most extreme hierarchy would be to have Y-number of users,
then let each user set what value of Y they trust,
and see how low it can go
I was thinking about a system in which, say there were 2 people who met up - the protocol would display unique QR codes on each of their phones, and the participants would be required to take a picture of their face with the QR code in the frame. Perhaps you could use some sort of facial recognition too?
Anyways, this would make it rather difficult for participants to collude, since the people themselves aren't verifying one another's existence. The face recognition + unique QR code is really the thing doing the verifying
what I don't like about it: it's invasive, it's the equivalent of the nation-state ID system except on Ethereum, people are still forced to meet with ID-providers that they might not trust and that they haven't chosen themselves. I prefer friend-to-friend IDs.
http://forum.ethereum.org/discussion/3117/decentralized-id-based-on-randomized-peer-to-peer-verification?new=1