Polis — community of communities

Identities in a Web of Trust

Bijun Li -

Democratic decision making requires that each person is assigned the same voting power, but such a system is vulnerable to people impersonating multiple voters by creating multiple identities. We are developing a decentralized blockchain system to guarantee the singularity of identities, while ensuring the privacy of their personal information.

Introduction

Reaching agreement via an asynchronous medium such as the internet is a difficult task. The general solution is to repeatedly vote until a qualified majority agrees on an outcome, but then one may ask: what measure should be taken to determine a majority?

Take the current decentralized blockchain technology as an example, where the weight assigned to a vote is typically the amount of computational or financial power controlled by the corresponding voter (e.g. Bitcoin, Ethereum). Although the system is decentralized since there is no primary to initiate voting, the voting process itself is nevertheless not a fair democracy as the big voters who own more power also have more weight in their votes.

Assuming one wants to implement functionality like democratic voting or governance, we require a system where each person has equal influence on a vote. Decisions should be made by a majority of people, not a majority of resources. In other words, trust is not tied to resource ownership. However, even if each person is assigned the same weight in a vote, the voting process is still vulnerable to Sybil attacks where a single person impersonates multiple voters.

So the question arises: How can we guarantee singular and trustworthy identities In a democratic voting system?

Having singular and trustworthy identities means that in the network, each person has at most one identity, and each identity must correspond to at least one person. For this purpose we are building a web-of-trust, a social network based on blockchain technology, by having each participant of the network vouch for the identities of their social relations.

Identity Vouching

When creating decentralized identities, we make use of the following concepts.

  • Participant:
    People that join the network are participants of the network. For instance a person that installs our identity software on their mobile phone.

  • Neighbour:
    Relations of a participant as modelled in the network are called its neighbours. Friends, family members, and work colleagues are all possible examples of such relations.

  • Datum:
    Pieces of identity information belonging to each participant are called datums. These can include various items such as names, keys, social security numbers, and biometric information.

  • Correlation:
    A datum that describes a relationship between other datums creates a correlation between said datums. For example the relation of a key with a biometric (e.g. finger prints).

  • Identity:
    A set of datums that is strongly mutually correlated forms an identity. Typically an identity is a cluster of related datums that belong to one person.

In the web of trust all participants are able to share information and get connected with their neighbours. For instance, each participant's datums can be turned into a hash (a unique numeric identifier), which can be published to the blockchain network and therefore be visible to the public. Participants can then confirm the datums of their neighbours by vouching for the corresponding hashes, which leads to the establishment of a web of trust with these neighbours. Moreover, trust in datums associated with more distant identities can be propagated.

By identity vouching, multiple related datums (i.e., the collection of individual identity datums) can be correlated and form an identity. Correlations start by identities vouching for their own datums, then the more confirmations datums get, the stronger their correlation becomes. And a strong correlation eventually enhances the trustworthiness of the datums. Trustworthiness foremost is the datums being real; i.e., being verifiably associated to a person. This information can then be extended by recording other properties of datums, such as their uniqueness in a certain context.

Participant roles

The identity system we envision has multiple components, and each participant can decide in the execution of which components it wants to play a role.

  • Web of Trust Agent:
    A participant that actively takes part in the establishment of a web of trust is called a web-of-trust agent. Agents publish datums and relations between datums to form a web of trust, which outputs decentralised identities that are clusters of correlated datums.

  • Secure Multi-Party Computation (SMPC) Player:
    A participant joining a multi-party computation is called an SMPC player. An SMPC player must be a network participant. The SMPC is used for privacy preserving computations and outputs a secure result.

  • Blockchain Peer:
    A participant that is part of the blockchain network for data storage is called a blockchain peer. Peers use the blockchain to achieve persistent data storage.

  • Consensus Protocol Instance:
    A participant executing the consensus protocol is taking on the role of a consensus protocol instance. The goal of running a consensus protocol instance is to reach transitive agreement.

The software of a participant contains several major components: A consensus protocol instance for achieving agreement across the network, a blockchain peer for storing data using the blockchain network, an SMPC player for secure calculation, and a web-of-trust agent for decentralised identity vouching. The first three components can communicate with the corresponding components of the participant’s neighbours by establishing connections via the network application programming interface (network API) component, while the web-of-trust agent does not directly connect to its counterparts, but uses the other components to achieve its functionality.

Note that although a participant includes all these components, it does not necessarily have to be involved in all their operations. Therefore we define the different types of roles a participant could obtain within the network and leave it up to the participant, and its specific circumstances,  to decide which roles it wants to fulfill.

When a participant joins the network, it automatically obtains the basic role as a web-of-trust agent. Based on this role, depending on which component a participant wants to activate, it could also become a consensus instance, an SMPC player or a blockchain peer. The more components are active, the more roles a participant will obtain, and the more operations the participant will process.

Use Case

We show a use case of participants implementing a duplicate identity detection function with configuration options. Singularity of an identity is proven with respect to a group of people, all of which submit their data to one and the same SMPC.

⓵ Join the network
In order to join the social network, a participant needs to create its own identity datum and then hash it to get a hash value. It also needs to generate a private/public key pair and use the private key to sign the hash. The signed hash as well as the correlation of the hash and the signing key will be then published on the blockchain so that they can be obtained by every participant of the network.

⓶ Create correlation
A participant can confirm the correlation of other participants’ datums, by vouching for its neighbours. The correlation of others’ identities will be signed by the participant with its own key.

⓷ Prove singularity
A participant can prove the uniqueness of its identity datum by submitting it to an SMPC: When the SMPC receives the submitted datum and its hash, it verifies the hash and the uniqueness of the datum against its local store of datums from previous submissions. After being given the result, a participant can decide to either publish the verification result or hand it over to others when needed for proof.

⓸ Initializing an SMPC
The initialisation starts with generating a key pair inside of the SMPC, and optionally storing a backup of the key pair among other players after being encoded via erasure coding. This requires a tradeoff between redundancy for players failing, and security for players colluding.

⓹ Detect duplicate
To detect duplicate identities, both the identity datum and its hash will be verified. The hash needs to match the datum, and it needs to be verified for authenticity by the SMPC against the web of trust of its players. A hash is considered authentic if it has been vouched for by enough neighbours. After uniqueness of the identity datum is verified, the SMPC will sign a proof as part of the correlation of the identity datums. Alternatively the datum is rejected when matching a previous submission.

⓺ Hand over SMPC
When one or more SMPC players fail (e.g. due to crashes), a handover of the SMPC can be used to securely move a running SMPC to a new set of players. An SMPC has a certain amount of redundancy built in, but if too many players fail, recovery will require restarting the SMPC.

⓻ Restart SMPC
Restarting the SMPC requires creation of a new key, or optionally recovery of the old key from a backup among a previously chosen set of players. The database can then be restored by resubmission of all datums, or optionally by using a backup encoded with the old key.