Credit goes to Ankur Patel @ MSFT

What is this?

I’m passionate about highly complex technical topics, and identity fits squarely into that description. Another thing about identity is that it doesn’t matter who/what/when/where, the success of an organizations technology execution is dictated by a well designed, well understood and well supported identity strategy.

But the enterprise is only part of it. Citizen identity is an equally important topic; people’s lives revolve around their online/offline identities and management/consumption of such.

That’s why it’s my favourite topic to discuss.

A new buzzword on the block is the concept of a ‘decentralized identity’ (or DID) -> where no single organization owns or controls the identity of someone, instead the identity itself is controlled by that person.

In this 2 part blog series, we will first discuss at an ultra high level what a decentralized identity is, and in the second part discuss the technical components and how they fit together.

But first, we need to look at the ‘centralized identity’ design of today, and why is sucks.

The current system sucks - centralized identities

Firstly, what is a centralized identity?

It’s an entity that provides a service that manages the identities on-behalf of a user. Because they manage/own all identities for all of their users, it’s centralized. The buck stops with them about who is who, who exists, who doesn’t etc.

…

There’s a couple key reasons the current implementation of enterprise/citizen identities suck:

Usernames and password (mainly passwords)
Who owns what?

1. Usernames and passwords

As we begin to use more online services, those services require a username and password. Unless there’s a form of SSO configured, each service will require a seperate username and password. This requires remembering those credentials and quickly adds up once you’re using multiple services.

Take Github and LinkedIn for example. Let’s assume no SSO. You (an identity) go to github, create an account (another identity) and login with it.

You then go to LinkedIn, create an account (yet another identity) and login there.

3 identities, 2 username/password combos:

1a. Passwords suck

How many times have you seen an organization leak credentials?

www.haveibeenpwned.com currently has over 9 billion accounts on file. That’s 9 zeroes. Plug a few of your emails in and see the results.

In essence, there's no protection or privacy here

2. A person doesn’t actually own their identity

Mentioned above, when you sign up to GitHub or something, GitHub own’s the identity. Just because you have a username/password doesn’t mean anything. You have no control over that.

Take a morbid reality example of the government. Certain governments around the world excercise complete control over their citizens, making people and towns ‘disappear’ overnight. Google “current affairs in China”.

This is but 2 examples of where it doesn’t work. There are more topics, such as system-to-system identity schema, GDPR etc.

3. Chain of trust (or lack thereof)

There’s been cases all over the planet of professionals not obtaining or having their professional certification. For example, doctors. There was one particular case from Australia where a doctor was performing complex surgeries but had never gone to medical school.

In a digital world there’s no real solution for this, as of yet (read below)

A better proposal - decentralized identities

Given the reality above, what if there was a standard where each citizen, regardless of the service/enterprise/system they’re trying to use, has complete and private control over their identity? The citizen gets to choose who they share what information with and when.

This is, more or less, exactly what the DID standard addresses.

In the above example, instead of creating a new identity for each respective service, on sign-up you go through a form of ‘validation’ of your identity and then the service returns you a ‘verifiable credetial’, which is securly stored in a ‘wallet’ that the citizen and only the citizen owns.

When that citizen shows up to login to Microsoft, instead of a username/password combination, they securely provide their credential from their wallet, and can consume the service.

The credential doesn’t store any sensitive information about the user; just that the user is authorized to use the service.

It’s a similar concept as a building pass or work pass, except in the digital era. I have a Microsoft pass, which is a credential which proves I work at Microsoft, but it’s not my identity.

Another thing you can see in the above diagram, there’s a form of a chain-of-trust. When a credential is provided, information about validation and verification of that credential is stored publicly; making it an immediate task of validation.

Lastly again, from the above diagram, instead of 3x identities and 2x username/pass combos, it would be 1x identity and (1 to N) credentials stored in the user wallet.

What does this solve?

Many points:

User privacy -> no identity is handed over to anyone else
User control -> each user/citizen is in control of their own identity
User protection -> user details can no longer get leaked or stolen
User experience -> Because the credentials are stored securly in a wallet, logging into or consuming services is much easier (QR code for example)
Organizational security -> because there’s a chain-of-trust (technically discussed in the next article), there’s a form of integrity which currently isn’t available
Technology integration -> the standard is being developed to integrate into existing OAuth2/OIDC standards in a very seamless manner.

When is this happening?

This is one thing I’m super excited about; it’s happening much sooner than you think. Can’t yet go into details about dates etc. but definitely ‘in a bit’ (and my timeframe for ‘bit’ is much shorter then yours! :))

…

So that was a long winded way to say we can do things better and it’s coming soon. Decentralized identity solves fundamental problems with the current identity models, stepping-up levels of privacy, control and flexability.

In part-2, we will look at technical details about how components fit together.