Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Decentralized Identity: The Basics of Decentralized Identity
Published Mar 24 2022 09:00 AM 15.9K Views
Microsoft

Here in part three of our decentralized identity series, I’ll describe the key parts of a decentralized identity architecture without diving too far into the technical details. It takes a village for this kind of ecosystem to work – as you’re about to see – and the concepts discussed here are industry standards that anyone can research and implement. If I succeed, you’ll be able to explain the design pattern behind this architecture and have enough information to look up the underlying specifications, if you choose.

 

Quick background: We started this series with the 5 guiding principles for decentralized identities. Then, we looked at why we think that the Direct Presentation model gives us advantages in moving towards our goals. Now comes the FUN part – we get to dig into the technical mechanisms that we think could underlie decentralized trust for individuals.

 

Part I: The Five Guiding Principles
Part II: The Direct Presentation model
Part III: The Basics of Decentralized Identity <-- You are here
Part IV: Deep Dive: Verifiable Credentials
Part V: Deep Dive: Anchored Decentralized Identifiers

 

A story of three documents

At the most basic level, decentralized identity is the story of three standardized documents: a proclamation, a letter of introduction, and an endorsement. That’s it! The rest is just tying up loose ends. Because I hate to leave you all in suspense, I’ll give you the technical names for each of these documents up front - but don’t panic! We’ll define them in context right away.

 

A DID document is a proclamation that helps strangers verify communications are authentic.

A verifiable credential is a letter of introduction by an issuer containing authoritative statements about a subject.

A verifiable presentation is an endorsement of a subject at the time a verifiable credential is passed to a verifier.

 

You can think of this architecture as a feudal letter passing scheme, with just as much intrigue but a lot more math involved. We open our feudal saga in a mythical land, long ago…

 

Chapter 1: The proclamation

Rose Abbey is known throughout the land for its beautiful gardens. The main building is something of a famous landmark: everyone knows where to find it, and those who do can find a proclamation nailed to the door with a wax seal attached that only this abbey can produce:

 

Trevor_Rusher_0-1648055420488.png

A paper with a wax seal in the shape of a flower that says: “Hear ye hear ye: All messages from Rose Abbey will be sealed with wax mixed with rose petals that can only be found in the Abbey. It looks like this”

 

There are two interesting properties of this proclamation document.

 

First is the provenance of the proclamation. It’s clearly a proclamation from Rose Abbey because it’s nailed right to the door, for all to see. Anyone can find Rose Abbey on a map, walk to the door, and read the document to learn about the wax that verifies a message is from the Abbey.

 

The second is the verification method within the document. The proclamation provides the recipe that explains how anyone can compare the exact composition of wax affixed to a given message to the one on this proclamation, and verify the message was created using wax from the roses unique to the Abbey. Let’s go one step further and say that any attempt to melt and re-form the wax changes the color so that only the Rose Abbey artisans are able to achieve a unique seal from specific raw ingredients. What will Rose Abbey do with this magic superpower?

 

Rose Abbey needs shoes for their monks. Cobbler Jan is the best around, working from her pushcart which she wheels around the village. Luckily, Jan has a proclamation too - but Cobbler Jan isn’t as rich or established as Rose Abbey. Jan doesn’t have a fixed, well-known storefront. Instead of hanging on a fancy door, Cobbler Jan’s proclamation is posted among other merchants’ proclamations on a board in the town squares:

 

Trevor_Rusher_1-1648055420499.png

A paper with a wax seal in the shape of a boot that says: “Hear ye hear ye: All messages from Cobbler Jan will be sealed with a handmade one-of-a-kind wax seal made in the cobbler’s shop. It looks like this”

 

With these proclamations, Rose Abbey and Cobbler Jan can start corresponding with a guarantee of message integrity, each signing messages with the resource only they control, and verifying the other’s message using the public proclamation document. As long as Cobbler Jan can reliably find Rose Abbey’s proclamation and Rose Abbey can reliably find Cobbler Jan’s proclamation, they should be able to evaluate the unique signature represented by each other’s wax and know they’re the true originators of the message.

 

A DID document is the digital equivalent of a proclamation nailed to the door of Rose Abbey. DID documents contain statements about how to securely interact with an entity. Message recipients who want to validate a message need to know two things: 1) how the DID document can be located and 2) what exact proclamation to use. 

 

In the case of Rose Abbey, this is easy; they use the time-tested “front-door” method to locate their proclamation, which involves opening a map, looking for a building called Rose Abbeythen proceeding to the front door of the largest building at that address. If you get to an address, look at the front door, and the proclamation doesn’t say “Rose Abbey,” you know you’re in the wrong place or don’t have the right proclamation. In the real world, you would encode both pieces of information into a  DID. The amazing thing about the DID is that that it’s self-contained, holding both the “how” and the “what.” For example, the DID for Rose Abbey could be did:front-door:RoseAbbey. Anyone who sees a message from did:front-door:RoseAbbey knows to get a map, find Rose Abbey, and to read the proclamation containing the identifier did:front-door:RoseAbbey on the largest building.

 

In Cobbler Jan’s case, you would visit the commons to find their proclamation among those posted. Cobbler Jan has fewer resources than Rose Abbey but still has a DID. A message signed using the “town-square” method such as did:town-square:CobblerJan is just as valid, but the instructions are different. Instead of opening a map and looking for a direct address for Cobbler Jan, the town square method instructions say to find on the map, and search for the proclamation posted at the commons with a matching identifier. Note that no matter what method the DID uses, the DID document produced has the same standardized contents.

 

2: Verifiable credentials: The letter of introduction

Now that Rose Abbey and Cobbler Jan know they can correspond securely, they negotiate for the contract to make shoes, and Jan is awarded the job. Rose Abbey creates a new credential document that Cobbler Jan can use to purchase supplies. This is a document standardized throughout the land – here's a before and after of Rose Abbey filling out the document:

 

Trevor_Rusher_2-1648055420507.png

A form-based letter of introduction with blanks where four values can be filled in. The letter says “To whom it may concern, blank (the issuer) says blank (the subject) is blank (claims). Signed, blank (a signature).”

 

Trevor_Rusher_3-1648055420530.png

The same form-based letter of introduction filled in to say “To whom it may concern, did:front-door: RoseAbbey says did:town-square: CobblerJan is an authorized buyer of leather. Signed, wax seal in the shape of a flower.”

 

Cobbler Jan is now in possession of an authoritative statement that can be used to buy leather for the Rose Abbey boot order! But notice this letter doesn’t say “the bearer of this document is an authorized buyer.” It states that Cobbler Jan is an authorized buyer. Because of this, leather merchants won’t release leather to anyone who presents this credential, only to someone who can prove they’re the person explicitly named. Cobbler Jan can’t sell the letter or give it away because they would have to give up the secret recipe to their handmade wax.

 

The modern equivalent to this letter of introduction is a verifiable credential, or VC. In this case, Rose Abbey has wrapped an entitlement to buy leather into a container that is coded to their DID and signed cryptographically. Anyone who wants to confirm the VC really came from Rose Abbey can use the embedded issuer DID in the VC to find a public cryptographic key in the associated DID document and do the math to confirm. 

 

Time to go buy some leather!

 

3: Verifiable presentation: The endorsement

This brings us to the morning that Cobbler Jan arrives at the leather shop. They must do two things:

 

  1. Produce the letter of introduction signed by Rose Abbey that shows entitlement to buy on behalf of the Abbey.
  2. Prove in the moment that the entitled party mentioned by Rose Abbey is the same party that is present in the shop.

Cobbler Jan accomplishes these two steps by opening the document from Rose Abbey and stamping an endorsement onto the credential, attaching the cobbler’s own unique wax seal only they can produce to prove they’re the same Cobbler Jan that the Rose Abbey credential refers to.

 

Trevor_Rusher_4-1648055420543.png

The previously shown letter of introduction with an additional note sealed by a wax seal in the shape of a boot that says “Endorsed by Cobbler Jan on April 22”

 

This is the most important part! The leather merchant could be looking at fraudulent documents that look convincing. Only by verifying the wax on both seals against the wax in the proclamations of each party can the merchant be sure they’re not giving away leather to the wrong party. If, for example, Cobbler Fred (a competitor) creates a fake letter of Introduction claiming to be from Rose Abbey using his own identifier and authoritative seal, when the leather merchant looks up the seal that is authoritative for Rose Abbey they’ll see that it doesn’t quite match the seal on the endorsement that Cobbler Fred handed over. One difference between our feudal world and modern times is that Cobbler Fred might be smart and talented enough with an inkpot and quill to steal the original letter, and alter it convincingly while keeping the seal intact. Luckily, modern digital doesn’t rely on human perception, so this risk is mitigated today.

 

This endorsement of Rose Abbey’s letter of introduction could happen many times. Cobbler Jan could visit various leather merchants and prove each time that the entity referred to in the letter of introduction is in fact the person there in the moment. As long as everyone protects their secret wax formulas, and everyone faithfully validates the documents there’s reasonable protection against counterfeit letters.

 

The modern equivalent of this endorsement process is a verifiable presentation, or VP. A VP can be considered a “proof of possession.” Here’s how it works in some truly medieval pseudocode:

 

If:

a VP and VC are presented together

and the issuer of the VP and the subject of the VC are both Cobbler Jan

and the VP signature can be validated with Cobbler Jan’s DID document verification method

and the VC signature can be validated with Rose Abbey’s DID document verification method

then

it can be assumed that the VC was issued to the entity that issued the VP.

 

The big picture

And that, my friends, is the basic model behind DID. We have fancier terms and we can use modern cryptography instead of wax seals with unique ingredients, but the fundamentals are the same. All parties involved must safely manage the ingredients needed to produce a signature that can’t be replicated, and must all proclaim a signature verification method using a mechanism that’s well-known. When credentials successfully validate, they guarantee message integrity, and that guarantee allows secure conversation to begin, a key layer for trusted commerce. Credentials can be issued to a subject, then presented and endorsed by that subject, enabling the exchange of goods and services as a result.

 

But where is the decentralization?

If you’ve made it this far, you may have noticed we aren’t talking a lot about decentralized concepts. You might also be itching to point out that this story is just a tale of a secure messaging scheme based on asymmetric cryptography, and that signed messages have been around for almost as long as Rose Abbey. You’re absolutely right. There's nothing about the model or standards we’ve defined that forces decentralization or excludes centralization. The DID and VC specifications are intentionally agnostic to the properties of the specific trust anchors that might be implemented, which is a big part of the reason we think they can be successful. The difference between any old, secure messaging scheme based on asymmetric cryptography and this messaging scheme based on asymmetric cryptography, is the layer of abstraction that allows old and new, decentralized and centralized - and anything we come up with in the future - to work alongside each other. We’ll talk more about this in the next installation of this series.

 

To quickly recap: DID documents are the posted proclamations that enable VCs. VCs are the “fill in the blank” authoritative statements of attribution of entitlement that are issued against a subject identifier. are endorsements at the time of presentation that prove that the entity showing the credential is, in fact, the named party. The system looks something like this:

 

Trevor_Rusher_5-1648055420551.png

A diagram showing rose abbey on the left with a title of “Issuer”, Cobbler Jan in the middle with the title of “Holder” and a leather shop on the right with the title of “Verifier”.  Below each entity is a DID document and there are arrows that show 1) a verifiable credential passing from Rose Abbey to Cobbler Jan, 2) Cobbler Jan verifying the Did document of Rose Abbey, 3) a verifiable presentation passing from Cobbler Jan to the leather shop, 4) the leather shop verifying Cobbler Jan’s DID document and 5) The leather shop verifying Rose Abbey’s DID document.

 

A few important things to note here: Everyone has a DID document (even the leather shop didn’t cover in-depth) and the content is standardized. But the method by which the document is fetched can differ. DID documents could be world-readable and searchable like Rose Abbey, but others could be shared privately at the time of first interaction, or even ephemerally created once and then discarded. Every entity can make its own choices about which method works best in each context. We can also support emerging options for DID document storage without requiring a rewrite of the entire architecture.

 

Of course, there’s a lot more to end-to-end architecture than just the documents that fly around. How are the documents delivered? How are the exact contents and types of letters negotiated to match the context? Can you selectively disclose part of the letter without revealing all the details? How does everyone know the rules in any given village? And, how do people know who to trust and for what? 

 

The answers are… stay tuned! Feudal metaphors were not built in a day. I’ll be back in the next installment to discuss fascinating topics, like whether Rose Abbey uses couriers on horseback to deliver their documents, or how Cobbler Jan can choose between African or European carrier pigeons to send different portions of the letter of introduction, depending on whether or not a given monk wants to be sure their shoes are made only from vegan leather. If you can’t wait that long, you can cheat a little and – it’s a long list but that’s the fun of it.

 

If you want to learn more about these topics and the technologies that fill out all the steps in the process, you’re in luck! Our next installment in this series is a DEEP DIVE! We’ll take our feudal tale and outline the industry stack we’ve implemented at Microsoft, including W3C Decentralized Identifiers, the OpenID Foundation OIDC4SSI Transport family, and the W3C VC Data Model 1.1. If you’re still here after this fantastical feudal adventure, I salute you and thank you for joining me on our quest.

 

Learn more about Microsoft identity: 

Co-Authors
Version history
Last update:
‎Mar 24 2022 02:52 PM
Updated by: