Fundamentals of Decentralized Identities
If you are interested in knowing what is happening at the bleeding edge in the identity space, Verifiable Credentials powered by Decentralized Identities (DID from here on) is what you need to keep an eye on.
Note: I have seen people use the terms Verifiable Credentials and DID interchangeably but DID is really the mechanism by which Verifiable Credentials is achieved.
This post is not a detailed deep dive on Decentralized Identities or Microsoft Azure’s implementation of it but just a primer for someone who is looking to understand the need for DID, a brief overview of the end user experience and an even briefer overview of how it works under the hood.
Please note that I have over simplified the ‘how’ part copiously and you should look for further reading to get an in-depth understanding of the actual implementation. I am planning to come up with another post soon to delve a bit deeper into the nitty gritty of the implementation.
Pre-requisite
- Federated Identity Management
A fair understanding of Federated Identity Management(FIM) is needed to truly appreciate the power of DID. Long story short, FIM is the mechanism that you are familiar with where you are able to login to the Spotify app with your Facebook account.
Here is an excellent video on FIM authentication fundamentals by a colleague of mine.
Authentication fundamentals: The basics | Azure Active Directory — YouTube
2. Public Key-Cryptography
Public key cryptography is at the heart of verifiable credentials and if you don't have a working knowledge of it, I would recommend you read the wiki page before proceeding further if you want to understand the how part of Verifiable Credentials.
Why Verifiable Credentials?
So we have FIM which works great and has been perfected over the years by billions of user logins. Why then do we need this verifiable credentials and decentralized identities now? To understand that we need to look at two problems of FIM.
- A digital identity is every user’s right, but in FIM the IdP has full control over that Identity and technically the user can get cut off if the Idp decides to do that.
When you log into a website or an application with your social identity like Gmail or Facebook you are ultimately at the mercy of the social identity provider to prove your identity. If they decide one fine morning to cut you off from their network, you will be left hung out to dry with no digital identity.
2. The IdP is always watching whenever the user logs in with their digital identity.
Humans are probably more concerned about their privacy now than they have ever been in the entire history of the Internet because of the widely popularized fact that data is an extremely powerful tool. So when you log into a dating app with your Gmail account, you might not want google to know that at all. But based on the currently OIDC protocol used by Federated Identity Management, Google, the IdP has to know when you try to login in to the dating app because it is the centralized database that verifies your username and password. This is almost like taking your university ID card to a pub and then the receptionist calling up the university to check if you are a student there! You surely deserve some privacy! Your date of birth and name on the university ID card is all it takes the receptionist to let you in in the real world and the digital world should be no different if you care about your privacy. The ID card is your fundamental right and the university shouldn't have to know where you use that identity and verifiable credentials will enable you to do just that!
What are Verifiable Credentials?
Verifiable credentials are credentials that any verifier can verify by just knowing the public key of the credential issuer. There is no centralized Identity provider like Google or Microsoft that verifies a users as legit. Any verifier can obtain the necessary public keys from a decentralized tamper proof ledger and verify that the user is legit. ( More on the mouthful decentralized tamper proof ledger later )
Let’s start by looking at a scenario.
Suppose Alice is a student at the Contoso university. She wants to use her student id card to obtain a discount for Spotify premium for students but doesn’t want her university be notified that she is using the student id card at Spotify.
The student ID card is Alice’s right and nobody should be able to stop her from using it wherever she wants.
The follow steps are involved in Alice accomplishing the whole process of logging into Spotify with her student ID card.
- Alice installs Microsoft Authenticator (or any credential wallet) and sets up her biometric (fingerprint) based authentication which is a one-time activity.
2. Alice navigates to Contoso university website’s ‘get student id card page’ and scans a QR code from that page into her authenticator app.
3. She will have to login with her Contoso credentials once and then verify her identity again with her earlier configured biometric data (fingerprint).
4. Alice’s Contoso University student id card is downloaded to her Authenticator App and is ready for use.
5. Alice navigates to the Spotify website and scans a QR code via the Authenticator App to prove that she is a student to get a Spotify premium for students discount.
6. A consent prompt is shown in Alice’s Authenticator App which she accepts and verifies again with her fingerprint.
7. Alice is a now a Spotify premium student member after she presented and successfully verified her Verifiable credential from Contoso University.
Note: Contoso university is NOT notified that Alice has used their University credentials at Spotify.
P.S Alice can store multiple verifiable credentials from multiple credential issuers in her wallet as show below.
The How?
Let’s split the above scenario into 3 parts and then look at each part separately.
- Alice installs the Microsoft Authenticator App
2. Alice gets a Verifiable credential (Student ID card) from the Contoso university.
3. Alice uses her Verifiable credential (Student ID card) at Spotify.
- Alice installs the Microsoft Authenticator App
A public key, private key pair for Alice is made by authenticator App and then the public key is published in a Decentralized Public Key Infrastructure(DPKI) like ION.
ION is a public, permissionless, Decentralized Identifier (DID) network from the DIF — Decentralized Identity Foundation that implements the blockchain-agnostic Sidetree protocol on top of Bitcoin (as a ‘Layer 2’ overlay) to support DIDs/DPKI (Decentralized Public Key Infrastructure) at scale. Microsoft is an active contributor to this project.
A DKPI can be thought of as a huge list of public keys which is replicated across millions of distributed data bases across the globe. There are protocols in place to ensure that this data is completely tamper proof. If you want to know more about this you need look up blockchains and tamper proof ledgers. I am giving below a very simplified example of such a ledger with Alice’s public key and a whole lot of other public keys.
SomePerson:SomePersonPublicKey,
AliceDoe: AliceDoePublicKey
2. Alice gets a Verifiable credential (Student ID card) from the Contoso university.
When Alice scans the QR code, a verifiable credential in the form of a DID will be passed on to her Authenticator app by the Contoso University. This DID which looks a lot similar to a normal ID TOKEN and will contain certain claims such as her name, date of birth etc. It will also be signed by using the Contoso University’s private key whose public key twin is already published in the same tamper proof ledge which we saw earlier.
ContosoUni:ContosoUniPublicKey
SomePerson:SomePersonPublicKey,
AliceDoe: AliceDoePublicKey
3. Alice uses her Verifiable credential (Student ID card) at Spotify.
When Alice scans the QR presented by Spotify, she gets a notification on her Authenticator App requesting access to her Contoso university Student ID card. The Authenticator App signs the student ID card DID provided by Contoso University in the earlier step with Alice’s private key and presents the result to Spotify.
Spotify now retrieves Alice’s and Contoso university’s public keys respectively and verifies that both of those entities have signed the DID document presented ( Student ID card) with their respective private keys. Once that is successful Alice becomes a Spotify premium member.
The beauty of DID lies in the fact that all the necessary public keys are available in a decentralized network of public keys which anybody can get access to. There is no all powerful centralized Identity provider like Facebook or Google involved in this. All Spotify has to do is look up the public keys in the decentralized ledger of keys. As long as that ledger or blockchain is alive and maintained, Alice is able to use her digital credentials anywhere she wants without the issuer of her credentials ( Contoso university in this case) being notified of that fact. Once Contoso issues her a verifiable credential they can’t accidently or intentionally forget Alice! The truth is out there on our tamper proof distributed ledger for all the world to see!
As of 2021, more than a billion displaced refugees and people from extremely poor countries are left out there without a digital identity and I am truly proud to be a part of an organization like Microsoft which is at the forefront of the global efforts to get them their fundamental right to a digital Identity.
References
An introduction to decentralized identities | Azure Friday — YouTube
Whitepaper on DID by Microsoft
MS Build SK114 Building trust into digital experiences with decentralized identities
