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.
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
Also, Read
- Best Futures Trading Signals | Liquid Exchange Review
- 3Commas Review | Pionex Review | Coinrule review
- Ledger vs Ngrave | Ledger nano s vs x | Binance Review
- Bybit Exchange Review | Bityard Review | CoinSpot Review
- 3Commas vs Cryptohopper | Earn crypto interest
- The Best Bitcoin Hardware wallet | BitBox02 Review
- BlockFi vs Celsius | Hodlnaut Review | KuCoin Review
- Bitsgap review | Quadency Review | Bitbns Review
- Crypto Copy Trading Platforms | Coinmama Review
- Crypto exchanges in India | Bitcoin Savings Account
- OKEx vs KuCoin | Celsius Alternatives | How to Buy VeChain
- Binance Futures Trading | 3Commas vs Mudrex vs eToro
- How to buy Monero | IDEX Review | BitKan Trading Bot
- CoinDCX Review | Crypto Margin Trading Exchanges
- Bookmap Review | 5 Best Crypto Exchanges in the USA
- How to trade Futures on FTX Exchange | OKEx vs Binance
- CoinLoan Review | YouHodler Review | BlockFi Review