Brief Introduction to self-sovereign identity

Introduction

In this brief introduction to self-sovereign identity, we will talk about how we build identity systems to create trust.  Trust was something that was local and useful for establishing trust in a single domain.  The only issue with existing identity systems is that they are not trust worthy.  Still there is no good way to prove that you are a certain age, you have an account with a certain bank, etc.  It is very difficult for someone else to vouch for you.

Initially identity was siloed, then came federated identity, and now it is time for user centric identity, this is what self-sovereign identity is.

Siloed Identity

In early days of Internet you had separate credentials for every site on the internet.

 

Federated Identity

Then came Facebook, and Google where websites enabled authentication using your Facebook or Google credentials.

 

User Centric Identity

In user centric identity, aka self-sovereign identity, user is in control of their identity. Open and flexible, interoperable and portable, viable and sustainable.

Verifiable Claims

Verifiable claims allow us to digitally do what we would do at a bar, pharmacy, hotel with a driver’s license.  For example attributes on a driver’s license are called claims.  A claim can be a JSON document that has been signed in a specific way holding certain attributes. Important properties of verifiable claim are:

  • They are decentralized and contextual
  • Anybody can be a issuer, owner, or verifier
  • Verifier does not need to have any kind of relationship with the issuer, not commercial, contractual, or technical.
  • Verifiers make their own trust decisions
  • Credential owner decides what credentials they want to carry around

 

Decentralized Identifiers(DIDs)

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.[From <https://w3c-ccg.github.io/did-spec/>]

Some key characteristics of DID’s are:

  • DIDs are a string of digits , cryptonyms derived from the elliptic curve private/public keys.
  • The DID is written to the ledger
  • DIDs provide pairwise identifiers for every relationship to prevent correlation.  DID Descriptor Objects link DIDs to public keys and end points.
  • Verifiable claims allow third parties to provide identity owner with credentials they can use just like we do offline
  • Once the other system has your DID, they can lookup your public key, take a nonce sign it with their private key, send it to you, and then you can then sign the nonce with their public key and this way they can confirm that the person they are talking to is the person in control of the private keys.
  • They can then ask you for claims about information, create accounts associated with your DID.
  • Every DID has a unique Private keys, and something the user holds.
  • Every claim has a link to a schema , and the schema are written to the ledger. The claims schema tells you what the claim is about and what do the fields mean.
  • Anybody can write a claims schema and write that claim.

 

Key requirements

Any system that plans to implement self-sovereign identity, has to implement following mandatory requirements.

  • No data visible to network operators
  • No central database, which eliminates the issue with honeypots
  • Because it is distributed, there are no points of failure
  • Allows total privacy
  • Cannot track users across relying parties

 

Implementations

These are some of the implementations of self-sovereign identity

  1. uPort is using Ethereum blockchain.
  2. Blockstack is using bitcoin blockchain.
  3. SecureKey is using  Hyperledger Fabric blockchain.
  4. Sovrin is using Hyperledger Indy blockchain.

 

Conclusion

Current self-sovereign identity systems are still very crude, they are still missing some essential tooling.  Which will show up as the current platforms evolve due to learning from implementations.