Introduction
This proposal is based on the assumption that it is easy to fake a person, but hard to fake a city. It describes a tiered Web of Trust based on clusters formed from offline “pseudonym parties.” It produces a temporary proof of personhood (i.e. unique identity) for participants who physically attend these parties. Successful participants are known as “seeds.” This system is designed to make it as easy as possible for anyone to become a seed. Seeds are not necessarily honest, but they are unique, and thus can provide a valuable data anchor for a Self-Sovereign Identity (SSI) system that uses a social graph analysis to detect Sybils (duplicate identity attackers).
The concept is predicated on the idea that pseudonym parties alone are not a sufficient basis for an inclusive SSI system, however any graph-based Sybil-resistant SSI system would stand to benefit from integrating personhood data generated by pseudonym parties. Two use cases jump out: the protocol could develop into a “validator” as described in the Circles UBI currency system, or it could be used as a “decentralized auditor” for the BrightID Sybil-detection algorithm.
This is a first draft and intended to be used as an outline. Feedback is more than welcome.
System Design
Pseudonym Parties
Pseudonym parties are meetups that occur simultaneously (*or may be slightly staggered in time, as long as physical travel between parties is deemed impossible) in different locations all over the world. For illustrative purposes we can refer to this event as “pseudonym day.” The goal of the parties is to verify that each participant is a unique human, based solely on physical attendance — i.e, without requiring any state-sponsored identity documents, biometrics, or any other personal information (not even a real name).
The internal mechanics of these offline (in-person) pseudonym parties are up for discussion. Ideally, validation at these parties will be entirely decentralized. The vouching process would therefore require group consensus on two things: group members and group name. There will be relatively strict time frames for group verification, so it needs to be simple and well organized. It could resemble speed-dating.
There should be a maximum group size, to make it possible for each group member to vouch for enough other group members within a reasonable time period. If there are too many people at one party and thus multiple groups in one room, these groups may either vouch for each other and unite under a single cluster, or else act as individual clusters (this is up for discussion — further discussed below).
Unique Identity Tokens
“Unique identity” tokens are distributed to all individuals who physically attend and successfully participate in any pseudonym party. Each new pseudonym event results in a fresh distribution of corresponding tokens. Tokens are identical to all other tokens generated on the same day, regardless of location; however, tokens generated on different days are different. Tokens are non-transferable.
Multiple Pseudonym Sessions
Previously we have implied that pseudonym parties occur only once on “pseudonym day,” but depending on the system design, this may be false. In the traditional model, there is only one pseudonym event, and therefore only one corresponding “unique identity” token. However, it is possible to divide this day into multiple days or sessions, and instead distribute “fractional unique identity” tokens that correspond to each session.
If a pseudonym event is split into multiple sessions, these sessions must occur in finite sets, with all tokens becoming active only after the entire set is complete. A participant is then declared a “seed” (meaning they have proven a unique identity) only if they have earned unique tokens from greater than half of the sessions in the active set.
If we assume that the average person’s probability of attending any party is greater than 50%, and attendance at one party does not affect the probability of attendance at another, we can maximize that person’s probability of successful participation by increasing the number of sessions per set. There should be an odd number of sessions in every set.
Increasing the number of sessions may be inconvenient, but it could also help to maximize the number of prospective participants. (Holding just one session provides one chance to participate, but holding three sessions provides three chances.)
Multiple Pseudonym Sessions: Drawbacks
There are several caveats here. First of all, if it is determined that the average person’s probability of attending any party is less than 50%, it would not make sense to hold multiple sessions. However, we may optimistically compare expected participation to international voter turnout rates, and act accordingly.
Second of all, it is possible that attending one party makes it more difficult to attend a second (e.g. it may be harder to ask for two days off from work instead of just one). In this case, it would also be better to limit the system to just one session.
We see one potential design as being a single-day pseudonym event, with multiple sessions held an hour or two apart throughout the day. This way, we could minimize one inconvenience of attending multiple sessions (by reducing the necessity of driving to and from a meetup multiple times — participants could remain between sessions just as they would wait at a doctor’s office); but additionally we provide a small amount of flexibility in timing, which could allow for more participants overall.
A system with multiple sessions opens up a new vulnerability to Sybils. It would become necessary to ensure that all earned tokens are non-transferable (i.e., tied to a single unique person), and to safeguard the in-person vouching process accordingly. This can be accomplished with something as simple as implementing a photo check at pseudonym parties; a participant would be rejected by their peers if they didn’t match the photo attached to their claimed identity. However, the added inconvenience and vulnerability of this secondary verification layer might outweigh the small benefits of having multiple sessions.
Cluster Verification and Tiered Web of Trust
Each local pseudonym party is labeled with a self-designated name (e.g. Weehawken Township Library) and ideally also location data (perhaps provided through a decentralized proof-of-location service like FOAM).
Each instance of a local pseudonym party, or cluster, is responsible for verifying other “nearby” or known clusters (similar to the concept of a “federation” as presented in the original pseudonym parties paper). In this way, a cluster-based Web of Trust will emerge.
For example, clusters formed at the Weehawken Town Hall, the Weehawken Township high school, and the Weehawken Township library should all be able to verify each other. This should be easy to do because these townspeople are real and actually know (and perhaps trust) each other — they may not even need a digital proof of location, although a proof of location should act as an additional security measure.
The architecture of the Web of Trust is up for discussion. Some research must be done into the most resilient system, i.e. how to recognize which pattern of vouches indicates a valid cluster. (Perhaps the Duniter Web of Trust would be a good start. Or perhaps this is a task for BrightID’s SybilGroupRank algorithm.)
Additionally, the governance process by which clusters verify other clusters is up for discussion. Verification may occur by consensus, popular vote, elected leader, etc. (It is also possible to allow each cluster to choose its own governance process.)
Token validity is contingent on the cluster’s position in the Web of Trust. Cluster verification can be organized entirely horizontally, but it can also be organized hierarchically. This is up for discussion. For example, it is possible for “superclusters” to form and democratically vote on the verification of other superclusters, e.g. imagine the Weehawken Township Supercluster (composed of the town hall, high school, and library clusters) voting to verify the neighboring Secaucus Town Supercluster.
Seed Expiration
Seeds are periodically reset in successive sets of pseudonym parties. This is because the population changes over time. Old seed tokens will expire as soon as a new set is completed and becomes active. Fractional tokens from previous sets may not be combined with tokens from new sets. Every time the tokens are reset, any SSI system using this information must be updated.
Discussion
In this system, seed status is proven not by a centralized register of people, but instead by literally showing up. This has several advantages.
First of all, the system is resistant to citizens registering multiple identities in different cities. This form of Sybil attack would be impossible as long as it remains impossible to physically be in two places at once. In fact, it has a particular advantage for travelers, who are now free to register their identity anywhere in the world, at any participating pseudonym party — even if they are not a citizen, and even if they don’t speak the language.
Second of all, this system has an advantage over a register system because it is decentralized. No trusted figurehead presides over the token distribution; instead, those who physically show up are responsible for vouching for each other and determining by consensus their own existence. This seems to be a fair and democratic way to organize seeds.
A major disadvantage of this system is its inconvenience. First, all seeds are temporary, thus participants would be obliged to continue attending pseudonym parties for the duration of their lives. Secondly, it may be rather optimistic to assume that the global population could coordinate on an optimal timing of synchronous parties. Another reservation is its accessibility: depending on its technical implementation (e.g. reliance on a smartphone app), this system may not be adequately accessible to economically disadvantaged populations.
