Decentralized Identity Fundamentals - Part 1 DIDs

DIDs are?easier to explain in the context of an example. When you create a new email account in a service provider like Google, you get an unique identifier for the account and your user profile data. Next time you sign in to Google, you will use that identifier or email address and password to prove it is yours. That identifier can also be used for social authentication on third party websites. The main advantage is that you can use a single pair of credentials everywhere, just an email address and a password. Google will also share minimal information about your profile with those apps so we can keep everything centralized in a single place. However, there is price to pay for that convenience. Google owns that identifier and also your identity information. While this couldn't represent a problem for you, imagine an scenario where you don't have access to that identifier anymore. E.g. your phone was stolen and the attacker took control of your account or something more extreme like Google banning your account. If that happens, you not only lost access to Google and all your information associated with your identifier but also the third-party web apps. Another issue, not so evident is that Google could in theory track all the applications where our credentials where used for authentication.

Having discussed all the issues associated with having your identity controlled by a third party, let's talk about DIDs and how they address those problems.

A DID or Decentralized Identifier is just an string representing an identifier that you can generate and own. This identifier adheres to a few rules that I will discuss next.

1. It is made of three parts, a prefix, a method and an unique identifier which takes the following form did:<method>:<identifier>. It is very similar in escence with an URL for locating a resource in the web, but the resource in this case is a document or also known as DID document that can be used to prove that you own the DID.?
2. Decentralized identity relies heavily on asymmetric cryptography. You prove you own an identity by signing a message with a private key that only you own/know and let other parties verify that signature by using the corresponding public key. This is what we have beeing using for decades under the hood for authenticating a server serving data over https, and it is now becoming a real thing for authenticating users with crypto wallets or more modern web specifications like Passkeys.
3. That DID document contains all the public keys associated to the DID. If you sign any data for authentication, the receiver of that signature can validate it by resolving the DID document and getting the corresponding public key.
4. Any application that receives a signature associated to a DID can use the <method> and <identifier> to retrieve the DID document and all the associated public keys. For example, if the <method> is ethr, it means the DID document is stored in the Ethereum Network as NFT and it can be located with a query on an Ethereum node.
5. DID Documents are usually stored in decentralized ledgers or blockchains so the application receiving the signature does not need to use a single server or set of servers to get the information. This is not always the case, you could also have centralized methods like did:web, which specify the document is available on a web server.
6. When you sign data with a private key associated to a DID, you don't include the public key in the same message, but only a reference to the key in your DID document. That prevents anyone to sign a message with any key that does not belong to you and attach your DID to the message.

Microsoft recently released a Decentralized Identity offering as part of Azure AD Verifiable Credentials. This implementation leverages ION, a decentralized ledger or blockchain as DID registry. That means the DID documents are persisted in this ledger and replicated across all the nodes in the network. A curious fact about ION is that runs on top of Bitcoin.?

The following code shows how to register a new DID on the ION network using the?SDK provided my Microsoft. These are free to use, and connects to the nodes hosted by Microsoft.

let authnKeys = await ION.generateKeyPair()
let did = new ION.DID({
? content: {
? ? publicKeys: [
? ? ? {
? ? ? ? id: 'key-1',
? ? ? ? type: 'EcdsaSecp256k1VerificationKey2019',
? ? ? ? publicKeyJwk: authnKeys.publicJwk,
? ? ? ? purposes: [ 'authentication' ]
? ? ? }
? ? ],
? ? services: [
? ? ? {
? ? ? ? id: 'domain-1',
? ? ? ? type: 'LinkedDomains',
? ? ? ? serviceEndpoint: 'https://foo.example.com'
? ? ? }
? ? ]
? }
});

const requestBody = await did.generateRequest();
const request = new ION.AnchorRequest(requestBody);
let response = await request.submit();
        

The code above generates a DID document that contains a public key (Elliptic curve) that could be used for authentication, which is the scenario previously discussed. It also adds a linked domain stating that the owner of this DID document and public key also owns the given domain. Azure AD in particular verifies this domain belongs to the user before submitting pushing the DID document to ION.

Once the document is pushed, you get two identifiers or DIDs, a long identifier that can be used to look up for the document in the ledger while the transaction is confirmed or a short identifier after it was confirmed and added to the ledger.

Those identifiers are what you could use to authenticate in third party websites from now on. You own the keys associated to those and also the documents. There is no need to involve an intermediary anymore. Also, when you sign a document for authentication, the third party verifying the signature does not need to contact any central authority. It could pull the DID document associated with the DID, retrieve the public key and verify the signature to make sure it was signed by one of the keys you own.?

That is the magic with decentralized identity.?

In the next article about this serie, we will review Verifiable Credentials, another core aspect of Decentralized identity.