Three approaches to Self-Sovereign Identity based on blockchain

In this short article, we investigate three different approaches to how SSI concepts map on the blockchain infrastructure.

Rosario De Chiara

Published in

Coinmonks

4 min readOct 20, 2021

Teatro Augusteo (Salerno, Italy), detail of the roof (photo by Rosario De Chiara)

This is the first of a series of articles about SSI, Self-Sovereign Identity

In this short article, we shortly compare three different approaches to implement a system of Self-Sovereign Identity (SSI) based on public-ledger/blockchain. We intend to classify the approaches by considering how much of the information is stored on the blockchain. In general speaking, the role of the blockchain in an SSI ecosystem is to keep track of the interactions between the actors by keeping hashes of the credentials and presentations that are issued and requested.

The first approach is used by Hyperledger Indy: the blockchain Indy is based on is Plenum, a domain-specific blockchain, that is in charge of collecting the interactions that happen between issuer/verifier/holder. SSI is the single purpose of the blockchain and credentials, identities and presentations are “first-class citizens”.
The second approach is the one adopted by smartcontracts based solutions like Alastria: identities, credentials, and presentations are kept in specialized registries within the storage of smart contracts on a generic Ethereum-compatible blockchain. The hashes of credentials, presentations, fragments of the DID Documents, the credential schemas, are kept in specialized registries that are hosted in smartcontracts that are in charge of protecting access to given actors.
The third approach is, in a way, derived from the previous one, and is the one pursued by uPort/Serto: the blockchain has one single registry that tracks down just the revocation of credentials, everything else, credentials issuance, the life-cycle of a presentation request/response, credential schemas, trusted issuers/verifiers, is outside the specification, every actor can issue whatever credential it likes to whomever; any further requirements for additional enforcement on who can do what has to be designed and developed from scratch.

These three approaches, Indy, Alastria, and uPort/Serto can be placed within different categories to compare them.

Subscribe to Coinmonks Youtube Channel to get daily crypto news.

Decentralized Identifiers (DIDs) creation

The differences between the three approaches are evident in the process of the creation of a new DID and, in general, what a DID in each system corresponds to.

In Indy, DID can be generated for each interaction between actors, each DID is a synonym of the controller; this is the extrema ratio to disable any chance of correlations between a single identity (e.g. a citizen) and its credential/presentation. This is pretty effective to avoid the risk of having a list of the DID that, for instance, have had a retired driving license.

Alastria handles DID by deploying a copy of a smartcontract, called Identity Proxy, when a DID is created; the address of the smartcontract became part of the identifying string. The Identity Proxy smartcontract is used to mask the transactions to modify the state of the registries, to circumvent the risk of correlating different transactions to a single DID.

The most lightweight approach is adopted by uPort/Serto: every Ethereum address is a DID but this is not prone to correlation because no registry tracks credential issuance or presentations response. Only the hash of a revoked credential is tracked in the revocation registry and it does not contain any reference to the DID to whom such credential was issued.

Discussion

Indy has a clear approach to preserving the privacy of each actor by putting a lot of effort to handle the generation of the synonym. Alastria, on the other hand, offers a lot of surface for customizations like implementing sophisticated policies to handle authorization: you can have registries to collect some specific kind of issuers, for instance, you can allow policies on the credential schemas each of the issuers can handle, and so on. uPort/Serto can be seen in the middle between these two approaches by having the strict necessary in a registry (the revocation list) and nothing more but also not closing the door to let the adopter implement something more expressive.

In the background, there is the fact that Indy requires a very specific, single-purpose, installation of blockchain, Plenum, while Alastria and uPort/Serto can easily be installed on any Ethereum blockchain both in public and private installment, letting the SSI be just one use case on a general-purpose blockchain.

Thanks to Francesco Zurolo and Paolo Servillo for the interesting feedback on this article

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Three approaches to Self-Sovereign Identity based on blockchain

In this short article, we investigate three different approaches to how SSI concepts map on the blockchain infrastructure.

Decentralized Identifiers (DIDs) creation

Discussion

Also, Read

Written by Rosario De Chiara