Trust in Self-Sovereign Identity (SSI)

Last time we looked at what works well and what needs to be improved in federated identity. We concluded with the statement that using large social identity providers to sign in to third-party services has problems if we don’t trust these providers to respect our privacy. To get to a more privacy-preserving model we to move from centrally-held identities to decentralized – and that’s the subject of this article.

Recap on terminology

It’s useful to recap on terminology because we’ll be updating our language from federated identity when we talk about self-sovereign identity (SSI). In federated identity:

• User: the person accessing an online service (relying party)
• Relying party: an online service that needs to know something about a user
• Identity provider: an entity that can hold and state information about a user

In self-sovereign identity:

• User -> Holder: the person accessing an online service (relying party)
• Relying party -> Verifier: an online service that needs to know something about a user
• Identity provider -> Issuer: an entity that can hold and state information about a user

We also introduce new terminology:

• Verifiable credential: information given to a holder by an issuer (e.g., date of birth)
• Verifiable presentation: information given by a holder to a verifier (e.g., that I am over 18)
• Public DID: an identifier for a subject that controls it (e.g. public key information) stored in Distributed Ledger
• Peer DID: a portable identifier that enables parties to communicate securely
• Distributed ledger: a network that proves transaction immutability (e.g. Bitcoin)

What is self-sovereign identity?

Self-sovereign identity (SSI) shifts the control of identity to the individual. Rather than keeping identity information in a centralised database, the data is issued by a trusted party (e.g., Government department) and stored on a holder’s device (typically a “wallet” app) in the form of Verifiable Credentials (a W3C standard). When an individual accesses a service that requires identity data, he or she controls whether to give consent to share their credential, hence it is self-sovereign.

Trust in SSI

Like federated identity, holders (previously users) and issuers (previously IdPs) need to trust each other. The holder needs to submit personal information before they get given a verifiable credentials; the issuer needs to check this before they give a credential. This is the same as in the non-digital world where I need to present information before being given an identity document: think about getting a passport for the first time: an application with other supporting documents, photographs etc is required.

Like any identity transaction, we need to establish trust before data can flow:

Establishing holder to issuer trust is similar in SSI to federated identity, but verifier to issuer trust is different. While in federated identity issuers (identity providers) have to establish trust with verifiers (relying parties), self-sovereign identity is different. In SSI, issuers don’t know where the credentials they’ve issued are being used: holders can use their credentials with a number of verifiers without any issuer involvement.

If we think about passports again: at border control, the passport is scanned and checked against its security features, and maybe against a revocation list. However, the issuing government is not informed about its use at a foreign passport control point.

So verifier and issuer trust looks like:

In the diagram above, the verifier has the known (public) DID of the issuer. This means that the issuer can check credentials purporting to be from an issuer (e.g., Government department) are in fact from that issuer (and not a fraudulent issuer pretending to be a Government department – the DID would be different).

Resulting trust

So how does this work in an end-end transaction:

1. An issuer publishes validates themselves to the ledger
2. Credentials issued are signed with the issuer’s private key corresponding to the public key in the DID
3. Verifiers construct proof the request which is then presented to the holder
4. Holders construct verifiable presentation using credentials issue
5. Verifiers check the presentation against the issuers public key from the DID
6. Successful transaction

So that’s how identity works in SSI. Next time we’ll look at how we join up current authentication protocols (OIDC) with SSI.