Self-Sovereign Identity

We live in a world where data is everything. While advances in technology have made the management of data easier, they have also created a need for people to have digitized identities. Like a key to a person’s life, control of an identity may grant the user unfiltered access to private information. Identity fraud and theft are some of the most frequent crimes today, and it is due to the fact that we are still not entirely in control of our own identities. We are at the mercy of the centralized powers that control our information.

HISTORY

To understand why self-sovereign identity is necessary, we must understand how Identity has developed in recent history. We can separate it into 3 sections:

  1. Centralized Identity: In the 1900’s, certain organizations assigned identities. Even governments needed a way to assign identities to individuals for various reasons.
    Ex. Social security numbers were created as a way for the government to track lifetime earnings. The validation of IP Addresses and the distribution of domain names was also forms of centralized identities.
  2. Federated Identity: A single identity allows access to multiple sites. This type of identity faces the same problem of being controlled by an organization.
    Ex. Microsoft Passport
  3. User-Centric: Individual or administrative control across multiple authorities. The organizations that verify the identities still hold power. Accessing untrustworthy sites result in vulnerability.
    Ex. OpenID, 0Auth, or FIDO

STANDARDS OF SELF-SOVEREIGN IDENTITY

True self-sovereign identity requires a few features:

  1. Users must be unique.
  2. Users must have control over who views their identity.
  3. Users must be able to access their own identity.
  4. The verification process must be clear and unconcealed.
  5. Identities must be interoperable.
  6. Users must be protected.

Identity verification has always been centralized in some way. The complete decentralization of it is simply not possible. There will always be an organization that has to verify the identity. In order to minimize this centralized power as much as possible, we make the verification process as transparent as possible. This aspect of self-sovereign identity is just as important to the user, as it is to the security of the whole system.

ARCHITECTURE

The use of distributed ledger technology/blockchains have made the creation of a self-sovereign identity a real possibility. With a public ledger, multiple parties can potentially have access to a created identity. An example solution would be based on this:

4 locations for data to pass through:

  1. User: The person whose identity needs to be verified.
  2. Issuer: The party responsible for verifying the identity and issuing a certificate.
  3. Requester: The party requesting whether or not the user has been verified.
  4. Public Ledger: The blockchain that is being used.

2 Forms of Data:

  1. Certificate: Proof that the user has been verified
  2. Verification Data: Data hosted by user that allows access to the certificate

Steps:

  1. The user sends information to be validated by the issuer. The Issuer verifies the information through a public process. If the public process is passed, the Issuer sends the user verification data.
  2. If the user passes, a certificate is added to the public ledger by the issuer.
  3. The user wants access to an application. The requestor asks the user for the verification data. If the request is accepted by the User, the verification data is sent to the requestor.
  4. The Requester uses the verification data in order to access the certificate on the public ledger. The certificate is proof that the user’s identity has been verified.

It is important to note that in this process, the Issuer holds power, as opposed to the requestor. The requestor will know no specific information about the individual.

This is the general architecture, but improvements can be made. If we add an option to make the Verification Data dynamic, it will add an extra layer of security to the system. The requestor will not even have access to the certificate on the public ledger after the initial request.

ERC725 / ERC735

  1. A public key is issued to a user.
  2. The user can send a transaction to the controller contract to call a function that manages key data by purpose and type.
  3. If approved, execute functions can be used for identity usage.
    • Approve an execution or claim addition.
  • A proxy contract could provide an extra layer of protection between the user and the application contract.

OTHER PROJECTS

CIVIC: Identity Verification System

Steps:

  1. User submits personal information to Civic and the information is validated using fraud detection algorithms. If the user passed, the verified identity data is sent to the user’s Civic App.
  2. Civic sends a certificate to the blockchain (Ethereum) confirming that the user’s identity has been verified.
  3. An Identity requester defines the requirements for identity validation. The requester asks the user for his verified identity data. If the User accepts the request, the verified identity data is sent from the civic app to the requester.
  4. Using the verified identity data, the requester can check the authenticity of the data by checking the blockchain. Confirmation of ownership and validity of the identity is returned to the requester.

Notes:

  • In this system, civic (or appointed groups) maintains a large amount of power by being the source of identity verification
  • A requester may still collect data about the user indirectly.
  • Verification data is not dynamic.

Most other projects trying to solve the issue of self-sovereign identity, follow the same process that civic follows with slight differences.

uPort provides a process for identity recovery through the user of multiple recovery.

Leave a Reply