Identity defines who we are and what we are capable of accomplishing.
The irony, however, is that we don’t get to tell who we are but are often required to represent ourselves by an identity given by a centralized authority.
Digital identities such as emails were supposed to change this situation when they evolved in the 2000sy Yet we are in 2021 and instead of providing such a situation we now centralized organizations that can control our digital or physical existence from a remote location 2000 kilometres away.
Currently, a centralized authority reserves the right to take away, with or without force, all your private keys, and forcibly control anyone you trust to recover those private keys if required.
It’s these inherent drawbacks for privacy and independence of identity that demanded the need for a system & infrastructure where an individual, institute or company gets to choose how they identify themselves with another individual.
That’s how the concept of self-sovereign identity came into place.
So, what is a Self-Sovereign Identity?
According to Drummond Reed’s book on Self Sovereign Identity, a pioneer and leading voice in the self-sovereign identity space, self-sovereign identity refers to:
“Lifetime portable identity for any person, organization, or thing that does not depend on any centralized authority and can never be taken away”
All of the conventional intermediaries that we depend on for digital identity are not needed in self-sovereign identity. Self-sovereign identity is very different from what a typical identity provider (like the government) would provide.
To understand the concept of self-sovereign identity better, let us look at digital identities.
There are three types of digital identities.
1. Centralized Identity
Also known as Siloed Identity, it is what most of us have on the internet these days when creating a relationship with an organization.
All of the accounts that we have today – our emails, usernames, passwords – across all the sites & apps that we maintain, are nothing but a rented property of that organization.
This means if they turn it off, our accounts and our digital identity will vanish in a matter of seconds. In essence, there is no real identity that we control in centralized identities.
It is also a highly inefficient way as there are thousands of instances of account hassle and fraud that happen every day, which points to the weak cyber security infrastructure that we currently have.
Of course, there are a set of basic security & encryption standards to make the current centralized identity possible, such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS). The most widely used standards in the world.
But they are not really solving any problem and so, to relieve the pain of managing all these accounts there was a second generation of internet identity was created.
2. Federated Identity
Also known as Third-Party IDP identity, it refers to inserting a third-party identity provider. Basically, you have an account with an IDP and then use it to create an account with another organization. The best example of this is using your social login such as Facebook or Google account to register with another organization such as apps and websites.
Essentially, your identity with this organization is federated & managed by the third-party identity provider. In other words, any organization within the federation of these third-party identity providers will be able to use them for account creation, user creation and other activities; while the IDP gets to manage, control, and have authority over the identities.
It does have benefits such as making the process easier for a user to log in or register at sites with one or two clicks, and not having to remember a separate user name or password.
However, to do this, a whole set of additional standards had to be put in place.
Some of such standards created for this purpose are Security Assertion Markup Language (SAML), OAuth, and OpenID Connect.
There is no doubt that federated identity has taken us a long way ahead but it still has some significant limitations.
The biggest of them all is that now you have a third-party identity provider sitting in between you and the organization you want to connect to, giving them the power of control over all the data. That’s why we are evolving a third model of identity.
3. Self-Sovereign Identity
Interestingly, SSI brings us back to the two-party identity peer-to-peer model.
In the SSI model, we do not talk about organizations anymore, we only talk about you and the peer.
And what makes the self-sovereign identity possible is the distributed ledger technology – blockchain technology. For you and the peer to set up and talk with each other, you need to be able to trust each other cryptographically.
That’s where the ledger comes into the picture.
The Ledger gives us a way to store and verify public keys that anyone else can reference in a decentralized way. In other words, we are creating a decentralized public key infrastructure, popularly known as DPKI.
With this infrastructure, we can now have a model where you are a first-class citizen on the internet. You will have your own identifiers and relationships that you can use for your lifetime.
In this relationship, you don’t have accounts. Like how you would give a business card, but you will not say that you now have an account with me.
You form a connection and that connection is peer-to-peer.
That’s what makes self-sovereign identity different from other identities as it has a totally different landscape.
Forming Trust in Self Sovereign Identity
Alright, it all sounds good and fancy. However, you may have an important question that needs answering: how do you form trust in these relationships?
With SSI, you have digital wallets. Digital wallets let you operate all of your devices – your laptops, mobile devices, tablets – where you need to have a digital presence to do so.
These digital wallets get power by obtaining credentials from peers and you sharing your credentials. Just the way you would in the physical world.
Like you would get a passport or driver’s license, then you go to other peers and show your credentials.
All of us that use our mobile phones and had to travel, have the experience of mobile boarding pass where you have a QR code in your phone and show it to the gate agent to board a plane. The same applies when you are entering a theatre to watch a movie, where you show the QR code of the ticket instead of a physical.
That showing of a QR code (digital credential) from your mobile phone, where we are using wallet functions, is provided by mobile operating system providers such as apple or google.
However, the form of trust we are talking about is moving to digital wallets that are not built under the operating systems by these vendors but are designed as SSI wallets that work for you.
And the credentials you get can be used anywhere they are accepted. You also get to control what credentials you share. That’s the basic model of how self-sovereign identity works.
Standards Governing Self Sovereign Identity
When we say governing, it does not mean a centralized authority. Rather it talks about certain standards that infrastructure should be built upon, to make it a truly decentralized platform.
Just like the standards for the other identities, there are four open standards for SSI.
1. DIDs – Decentralized Identifiers for public keys.
2. DKMS – Decentralized Key Management System for private keys.
3. DID Auth – For peer-to-peer authentication.
4. Verifiable Credentials – The exchange of verifiable credentials and their standards for presenting, accepting, format, and signatures.
Let’s understand these standards
1. Decentralized Identifiers (DIDs)
To understand this standard, let’s take the example of an Aadhar card or Aadhar number.
There are many fake Aadhar cards in India. Let’s say somebody asks for your Aadhar card and you show one, there is no way to confirm that the Aadhar number is really yours.
The only way to verify is to go through a verification process from an authorized center who can confirm if it is genuine or not.
However, let’s take a DID: 8ik94jhk89ius3tu789sd1s45hko
You can actually prove that it is yours because this DID has a public key on the ledger and a private key in your wallet.
Both of them are 128 or 256-bit encrypted keys which look something like this: H@McQfTjWnZr4u7x!A%D*G-JaNdRgUkX One may say, it can be copied too.
But the key difference between a traditional identifier and a digital identifier is that you will have hundreds of them and not just one.
Because you will be using a different DID for each relationship for the sake of privacy.
Each one of these DIDs is not just creating a relationship but creating an encrypted channel for lifetime to engage with the peer – who can be an organization, person, or thing.
You will use it not to just prove your identity but to exchange verifiable digital credentials as well.
This is how Digital identity no longer becomes just identity but a robust cyber security infrastructure.
And it will result in a whole new generation of secure apps & services.
2. Decentralized Key Management System
For managing the private keys required in digital identifiers DKMS was created as an open standard. This standard also enables managing the private keys you need for DIDs, including robust, highly usable key recovery. DKMS tackles the other side of the problem. If DIDs are considered as the tip of the iceberg then the problem not seen is that DIDs will only work if you have a way of managing private keys.
That obviously has to include a way for the individual or organization to recover keys if you lose them or if they’re compromised.
Here is the decentralized identity stack to visualize At the bottom you have the DID layer where any modern blockchain can support having a unique address for DID document to fulfil the needs of the DID layer.
We then have the layers of agents and wallets. What distinguishes these layers is that the edge layer represents the devices that are directly used by identity owners (people or businesses). Mobiles, and laptop devices are at the edge. OR servers behind firewalls where companies feel they can safely keep their private keys.
So, the whole point is that your private keys are maintained in an edge wallet under your control and they are generated there.
In an ideal practice, the private keys never leave the wallet. Edge agents maintain the encrypted backups of those wallets in the cloud.
That’s how individuals can have multiple edge agents and they can share & maintain an encrypted backup. They can synchronize what needs to be done. Not the keys but the metadata and the DIDs across multiple devices, enterprises, and organizations can do for their devices and applications.
Both edge agents can communicate edge-to-edge in a mesh and cloud agents can communicate with others 24/7 at the server layer.
This stack created was the DKMS protocol for generating and sharing and backing up keys through these two layers of agents and using ledgers to register and rotate those keys when needed.
This is the basic background on DKMS. This protocol can be found in the Hyperledger Indy repository at the Linux Foundation.
By the way, TruScholar uses Hyperledger Indy to establish digital identities for students and institutions. DKMS key recovery supports offline recovery (“paper wallet”) meaning how do you back up the master key for your wallet on paper & hardware of some kind. It also supports social recovery (“trustee”) where you shard that key and you share it with other individuals or institutions you trust.
If you ever lose your devices or some compromise, you can recover it by going to those trustees. Both of these methods have tremendous promise and will solve the problem of decentralized key management.
3. DID Auth
DID Auth is a simple standard way for a DID owner to authenticate by proving control of a private key. Everybody wants a simple way to log in and authenticate in any place. With DID and DKMS we have the public key infrastructure to support DID Auth.
Through DID Auth you can confirm that you are the one who registered that digital identity and you control the private key for it and you can prove it cryptographically.
If you refer to the previous picture again, once you we have stacked in place, what DID Auth becomes is simply a way for one agent to authenticate over its connection with another agent.
Any app, service or device that needs to form a connection will use DID and DKMS but to authenticate who’s on the other end then you would need a very simple challenge-response protocol because now you are going to assign that challenge with your private key.
4. Verifiable Credentials
Verifiable credentials are the format for interoperable, cryptographically-verifiable digital credentials defined by the W3C.
It is like the meatloaf in a burger. We can put all of this in place and now we can actually exchange the credentials that will really prove human trust at the human level, not just at the cryptographic level.
This is approved by W3C (World Wide Web Consortium) working group.
Verifiable credentials are what two agents will exchange once they’ve formed a connection.
Once two parties have got DIDs and are able to authenticate each other, they can share credentials just like two people would shake hands and say hi to each other.
W3C Verifiable Credentials Ecosystem
According to the W3C verifiable credentials ecosystem, There are three key roles as you can see. Issuer, Holder (wallet), and Verifier.
Issuer signs credentials and issues credentials. The wallet then countersigns the credential and presents it to the verifier.
To understand this let’s consider a driver’s license which is issued by the local government authority. When traffic police want to verify if you are a valid rider, they ask for your driver’s license. Once they verify in their registry, they then let you go.
Of course, in India, sometimes you have to do more but that’s for another story.
If we want to do this digitally in a self-sovereign identity model that the same issuer will register a public DID and when they give the holder the physical credential, they’ll also generate the digital credential. The identity holder can then use their digital wallet, scan a bar code, or they can send me a link. Verifier can download a digital version of that driver’s license. It’s understood that the DID will be signed by the private key.
In the same way, you can use this driver’s license at various places where it is required as identity proof. You show the QR code, the verifier scans the code and in ideally less than a second that software will ping the blockchain to check for the validation of the public and the private keys and confirm that the credential presented by the holder is valid.
In many self-sovereign systems, they take this up by a notch by completely protecting the DID given by the issuer to the holder where they can share zero-knowledge credentials and proofs.
This sort of digital identity and privacy protection is in line with many privacy standards such as GDPR, PDP, etc.
So, Why is TruScholar Talking about SSI?
Because at TruScholar, we use Hyperledger Indy to create self-sovereign identities between institutes and students.
We are doing so to eradicate the problem of fake education credentials in India and to completely replace paper-based credentials with verifiable digital credentials.
It also protects the brands of institutes where they can conveniently issue certificates and provides a secure way for students to easily get them verified.
And that’s why we are talking about SSI.
Schedule a free demo with us today and we will show you how it works in reality.
