Self-Sovereign Identity: a path for the adoption
SSI cannot be successful without an ecosystem (like every new app we are designing in the 21st century, by the way)
Self-Sovereign Identity, SSI for short, is a paradigm shift in the way digital identities are managed and, in a wider sense, perceived by the citizens, first, and the rest of institutions that issue, handle and verify identities and credentials, then.
In the figure above you can see how the SSI can be seen as a mandatory step in the evolution of digital identities: from the centralized, first cut to the digital identities, a progressive and incremental evolution can be envisioned toward a future where a distributed way of handling such identities will be the usual way of handling them.
It is worth noting that the meaning of the adjective distributed is not only referring to the architecture of the components where credentials will be kept but, mainly, to the distribution of the responsibilities of how credentials are issued, kept, and shared: this is the exact meaning of self-sovereign, the holder, the citizens or the legal representative of a company, will be in charge of her own credentials and will apply control on the life-cycle of such credential.
An ecosystem is what we need
No matter how fascinating such a vision is, it is necessary to clarify that no SSI solution can work on its own, an SSI solution must, first of all, foster an ecosystem as florid as it can get, in which to host all the processes.
I have personally followed the development of at least three different wallet apps, each with subtle differences, and, for each of them, once you clarify the details of the user experience and the way you keep your secret stuff in a safe place on your mobile, it became clear you need to develop an issuer and a verifier, to demonstrate how your pretty JWT will be exchanged.
In the diagram above, you can see a simple sketch showing how a modern SSI system is composed.
Let’s just shortly comment on each of the components:
- The wallet: it is an app (it can be a web app but it is not relevant in this technological framework: the two concepts coincide), it must be able to receive asynchronous messages, scan QR-codes, get access to two different local storages;
- The storages: one is encrypted and protected by biometry, the other just provides the persistency that is functional to the state of the application. The differences between them are numerous but, shortly, if you lose your phone the encrypted storage will be hardly accessible to anybody who will find it, so it is a good place where to keep your secrets (e.g. the private key);
- The ledger: it can be a blockchain (of course) but it is not necessary, going for the blockchain will open access to the purest form of SSI, the blockchain will play the role of the single source of truth, open, public, resilient to failures and to crashes, unstoppable and tamper-proof.
- The registries: you will need at least a revocation registry, to record the credentials and presentations that will be revoked. It may appear that more registries will be needed but it will be just a variation of the revocation registry;
- Issuers and verifiers: those are the other actors, beyond the wallet, of each of the exchanges in SSI, they will have specific roles and, most importantly, will create credentials for others and ask for a presentation, of such credentials, to verify them, for the purposes of their roles.
- Distributed Identifiers: this is the DID infrastructure containing DIDs and DID documents (check this nice article by my good friend Francesco Zurolo);
- Asynchronous communication channels: this channel must factor in the idea of exchanging encrypted information between certified endpoints that will have to be cryptographically demonstrated to control such endpoints.
Fostering the ecosystem: issuers and verifiers
Issuer and verifier are the most complex part that hardly will be under the control of who is designing the SSI system and the wallet: issuers and verifiers (in this exact sequence) must be involved as soon as possible in the process.
The issuer must be authoritative for a given set of credentials, some examples: a group of universities for diplomas, a set of city municipalities for parking permissions, some small business for a loyalty program.
Verifiers should be included but this is way easier because once your wallet will have been hosting credentials it will be clear that checking them will enable citizens to have a new way to access services: students will be able to certify their own diplomas when looking for jobs, parking permissions will be tamper-proof and easily checked by officers, more customers will be engaged by the idea of collecting loyalty points doing shopping.
Both issuers and verifiers are subjects that already have processes involving credentials, it will be needed to imagine software kits to facilitate them in the process of adding a totally new way of doing what they already do: issuing credentials (e.g. diplomas, parking permissions, loyalty points) and verifying them. It must be clear that is necessary that there will be a process when both credentials, the traditional, maybe even paper-based, ones and the new SSI ones, will co-exist so processes must be able to accommodate both.
Conclusion
SSI is an unavoidable evolution of digital identities, planning ahead is necessary (of course) and it is fundamental to aim at having an ecosystem, the sooner the better, of issuers and verifiers. The adoption of the SSI approach is a battle that deserves to be fought but cannot be won alone.
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing
