Introduction to the future of identity - DIDs & VCs

Updated: 4 days ago

Update 26/11/2021 – Microsoft has depreciated the SDK for verifiable credentials. In their own words:

“From October 31, 2021 certain Microsoft Azure AD Verifiable Credential SDK functionality will stop working in Microsoft Authenticator. Applications and services that currently use the Microsoft Azure AD Verifiable Credential SDK should migrate to the Microsoft Request Service REST API

I will be updating and adding to the blogs over the coming weeks. Rather than simply editing the current blogs, I have decided to add new blogs that show the functionality using the Microsoft Request Service REST API Service. The old blogs I have tagged as using the SDK. I have left them as they could be a useful reference.

Now that Microsoft has made their Verifiable Credentials (VCs) issuer service available in public preview, it's time to understand what VCs are and how they work with Decentralized Identifiers (DIDs). VCs and DIDs provide a new paradigm for identity, a true step into the future.

In this blog, I want to start by thinking about identity in general and then explaining Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). I will show you how you can issue your own DIDs and VCs using the new Microsoft service in future blogs.

The blogs in the series are (No 3 and 5 are coming soon)

  1. Introduction to the future of identity - DIDs & VCs

  2. Issuing DIDs and VCs with the Microsoft SDK app and Authenticator

  3. Issuing DIDs and VCs with the Microsoft Request Service REST API - replaces no 2

  4. Issuing your own DIDs & VCs with Azure AD and the SDK apps

  5. Issuing your own DIDs & VCs with Azure AD and Microsoft Request Service REST API - replaces no 4

By the end of blog 5, you will be issuing your own VCs.

verifiable credential in Microsoft authenticator
Identity masterclass verifiable credentials

For now, read on for an introduction to DIDs and VCs.

Let's start by considering the question What is identity and access control?

Identity is about knowing who someone is; the user is identified when they are authenticated. Access control manages access to resources based on the individual's credentials. I've used the term credential to refer to "known" information about the user. Traditionally an individual's credentials have been set by the systems that authenticate the user and/or control access to a resource.

Individual's credentials being set by the systems that authenticate the user and/or control access to a resource
Setting user credentials

Identity and access control could be governed by a single entity, such as a website authenticating users via its own accounts database and controlling access to the site's resources. Alternatively, a central identity provider (IdP) can authenticate the user, and individual resources implement access control based on the user's credentials.

If our systems use industry-standard authentication protocols such as SAML or OpenID Connect / OAuth 2.0, one organization can manage the authentication and another organization control access to the resources. This is a federated solution, and there are many industry players providing enterprise Identity and Access Management (IAM) services including, Microsoft, Okta, OneLogin, Ping Identity. These enterprise IAM services are full-featured, allowing an organization to manage their own users and application access. In addition to the enterprise IAM services, there is a range of consumer identity services such as Google(Gmail), Microsoft(MSA), Amazon, and Facebook. These consumer services allowing self-service sign up for the core service, for example, Gmail. However, they also provide federated sign-in for any resources that are configured to trust the IdP to authenticate users.

Diagram contrasts Enterprise versus Consumer Identity Providers
Enterprise versus consumer identity providers

Identity providers need to be able to uniquely identify a user and provide a method of authenticating that user. Traditionally this has been done with a username and password. When a user is registered with an IdP, the user will be identified by a username and password. When the user initially signs in, what do we know about them? Nothing. All the system knows is that the same user has returned. If it is required to know more information about the user, some form of identity proofing will need to be implemented. This could be as simple as verifying an email address by sending the user an email and requesting that they respond, through to asking the user to attend an interview with appropriate documents, and performing in-person verification.

Your digital identity

To live in the digital world, you will probably have a corporate user account and then accounts with multiple IdPs (Google, Facebook etc). We will have access to resources based on all these different accounts. Are we in charge of our identity? The answer to that is a BIG NO. When we leave an organization, we lose our corporate identity. A consumer IdP may go bust or block our account. Once again, we have lost our identity. In both cases, we have lost the ability to prove who we are to the different resources that trust the IdP. Of course, in a corporate world, it's a good thing that when we leave, we can no longer access the organization's systems, but what about other systems that we signed up to using our work identity?

If the potential to lose your identity wasn't bad enough, the other major pain point is that you are constantly being asked to prove things about yourself. You open an online bank account. You have to prove who you are. Open a savings account with a different bank. Once again, you are sending off all the same documents as part of the required identity proofing. And it goes on and on.

Identity in the real-world

Do we continuously lose our identity as we move between jobs, countries, relationships, and hobbies in the real world? It may feel like it sometimes, but in reality, the answer is No. When we are born, we have biometric characteristics, our first set of credentials. Throughout our life, we gain other credentials—birth certificate, education achievements, driving licence, passport, marriage certificate and so on.

When we are stopped for speeding, how do we prove who we are to the police officer? We present our driving licence. Provided the photo matches and the driving licence has the correct hologram, the police officer may accept this as proof of who we are. For extra surety, she may well check that the licence has not been revoked. Once she knows the document is genuine, she can trust all the credentials it holds, age, address, and so forth.

Let's step back a moment and think about what's happened in this scenario. I had the license in my wallet and presented it to the police officer. She validated the licence by checking:

  • It was about me by matching the photo ID

  • That it came from an issuer she trusted by examining the document hologram

  • Getting extra surety by checking for revocation

What my identity? My image, who can take away? No one!

Digital identity mimics real-world identity

How would it be if we could digitally mimic the driving licence scenario? Well, now we can with DIDs and VCs.

My image is replaced with a globally unique digital ID which I generate and own. I will go into the details of this digital ID later in this blog; for now, let's keep it simple. Of course, being a mere human, I cannot generate globally unique IDs, so I leave that to my user-agent (also called a wallet). Microsoft has implemented a user-agent to do this in the Microsoft Authenticator App that you can install on your phone. This is the same app that does all those great things, such as multi-factor authentication and passwordless sign in to Microsoft 365/Azure AD. Thank you, Microsoft, for not cluttering up our phones with yet another app.

My globally unique ID consists of a cryptographic private/public key pair. The private key is securely held by the user-agent and never leaves the agent. Using the private key, my agent can digitally sign a message which includes the public key and send it to a recipient service. Using the public key (contained in the message), the recipient can validate the signature. The recipient now knows that the message's sender owns the private key. The private key is unique to the user and never leaves their possession. Consequently, the message has been signed by the user's globally unique digital identity (private key). This can be confirmed by anyone using the user's globally unique associated public key.

Shows how the private key is used to sign a message and the public key used to verify it
Signing and verifying a message

This is a great start. The recipient service could store my public key and maybe some characteristics about my interaction with the service. When I return to the service, I supply another signed message, and the service can uniquely identify me as a returning user. We have just thrown away the need for usernames and passwords together with their associated vulnerabilities. We have also eliminated the requirements for an identity provider.

Eric celebrating the ownership of his identity
Eric now creates and owns his identity

The FIDO 2 standards are implemented in a similar way using public/private keys. Traditionally, the next step would be for the service to do some form of identity proofing and create a user profile that contains the appropriate credentials.

Back to the driving license and the police officer. Once I have passed my driving test, I can apply to the Driving Licence Authority (DLA) to issue a licence. The DLA will ask me for specific documents, including my test certificate, my photo, DOB, proof of address etc. Today they create a licence containing my photo to prove it belongs to me, appropriate credentials, and a hologram that confirms it was issued by the DLA.

Let's go digital!

I apply for a licence, submitting my digital ID (public key) rather than supplying my photo. I furnish the other documents necessary (which could be done digitally). The DLA creates a digital record that includes my credentials, my digital ID (the subject), the DLA's digital ID (the issuer) and is signed by the DLA. I store this in my user-agent.

Illustration of converting a real driving licence to a digital one
Physical to digital driving licence

The police officer questions my speeding (I am sure my Fiat 500 was going that fast!) she asks me to show her my driving licence. I unlock my phone (with a biometric) and use the agent to submit my driving licence to be verified. My agent digitally signs the submission using my private key, which proves I am the licence owner (only I have the private key, it has never left my wallet.)

Show driving licence (verifiable claims) digitally signed by the subject
Presenting the driving licence for verification

We now have the trio of issuer, holder and verifier, which is fundamental to verifiable credentials. A little like the three musketeers all supporting each other. “All for one and one for all, united we stand divided we fall.”

The three key components of verifiable claims
The three musketeers

The issuer, holder and verifier all have their own unique digital identity. I left out a bit of detail above. When the police officer asks me to submit my licence, her systems will make a presentation request which is digitally signed by the verification system. I then have the opportunity to decide if it is safe to submit the credentials to that system.

I have just introduced you to the world of verifiable claims (VCs). A key feature of VCs is that as the holder, I can submit a VC to multiple verifiers and provided they trust the issuer, they can all accept my credentials. This avoids me having to prove my credentials to numerous services. Prove the credentials once to an issuer and use them everywhere. Don't you just love that? I know I do.

If you are wondering how you trust the issuer, you will need to read the section below on DIDs

A world of endless possibilities

A verifier, via a presentation request, could ask for multiple VCs from different issuers or just a single credential. Using Zero-Knowledge Proof (ZKP), it will also be possible to prove to a verifier that you are over 21 without submitting your DOB.

Here's a thought, does our IdP need a user accounts database? When a user signs up to use our service, we make a presentation request to the user. The user submits the appropriate VCs from issuers we trust, and then we issuer a VC that proves the user is approved for access to our services. When the user subsequently signs in to our service, the VC that we issued is presented and we verify it.