Decentralized identifiers

SSI Course Module 08

1

© KEN Labs 2022

Decentralized identifiers

Understand DIDs at four progressively deeper levels.

​

​

​

​

Travel all the way down through these four levels

​

​

​

​

​

SSI standardization

Verifiable credentials (VCs)

Decentralized identifiers (DIDs)

• At the most basic level, a decentralized identifier (DID) is simply a new type of globally unique identifier—not that different from the URLs you see in your browser’s address bar.
• At a deeper level, DIDs are the atomic building block of a new layer of decentralized digital identity and public key infrastructure (PKI) for the internet.

The progression of four levels at which we can understand DIDs—from a basic definition to a deep understanding of how and why they work and what they mean for the future of the internet and the web.

Decentralized identifiers (DIDs) are the cryptographic counterpart to verifiable credentials (VCs). Together these are the “twin pillars” of SSI standardization.

2

© KEN Labs 2022

The conceptual level: What is a DID?

>1000

DID is a new type of globally unique identifier: a string of characters that identifies a resource.

URI

In terms of technical standards, a DID is a type of Uniform Resource Identifier (URI)

URL

A Uniform Resource Locator (URL) is a URI that can be used to locate a representation of that resource on the web.

URN

In web architecture, the subclass of URIs reserved for persistent identifiers are called Uniform Resource Names (URNs).

URLs and URNs are subclasses of URIs. URLs always point to representations of resources on the web, whereas URNs are persistent names for any resource, on or off the web. A DID is a URI that can be either a URL or a URN and that can be looked up (resolved) to get a standardized set of information (metadata) about the resource identified by the DID.

3

© KEN Labs 2022

Decentralized identifiers

The four core properties of a DID.

The general format of a DID: the scheme name followed by a DID method name followed by the method-specific string, the syntax for which is defined by the DID method.

Network�resources

1. A permanent (persistent) identifier

It never needs to change.

2. A resolvable identifier

You can look it up to discover metadata.

3. A cryptographically verifiable identifier

You can prove control using cryptography.

4. A decentralized identifier

No centralized registration authority is required.

As defined by the W3C DID Core 1.0 specification, a DID is a new type of globally unique identifier: a string of characters that identifies a resource.

4

© KEN Labs 2022

DID resolution

The process of obtaining the DID document associated with a DID is called DID resolution.

The functional level: How DIDs work?

How DIDs function.

The basic components of DID architecture.

DID documents

Every DID has exactly one associated DID document.

DID methods

These different types of DIDs are known as DID methods.

5

© KEN Labs 2022

• The DID document contains metadata about the DID subject, which is the term for the resource identified by the DID and described by the DID document. A DID document contains only the minimum amount of machine-readable metadata required to enable trustable interaction with the DID subject.
• The entity that controls the DID and its associated DID document is called the DID controller.
• In many cases, the DID controller is the same as the DID, but they can also be different entities.

​

DID documents

Examples of DIDs created using five different DID methods.

Relationships between the DID, DID document, and DID subject (in the case where the DID subject is also the DID controller)

6

© KEN Labs 2022

• The second part of the DID identifier format—between the first and second colons—is called the DID method name.
• As of early 2021, more than 80 DID method names have been registered in the DID Specification Registries.
• One consequence of the technological variety of DID methods is that some may be better suited for certain use cases than others. DID methods may differ in how “decentralized” or “trusted” they are, as well as in factors of scalability, performance, or cost of the underlying technical infrastructure.

DID resolution

How DIDs function.

Example DIDs generated using five different DID methods

7

© KEN Labs 2022

The functional level: How DIDs work?

>1000

How DIDs function.

DID resolution allows DID-enabled applications and services to discover the machine readable metadata about the DID subject expressed by the DID document. This metadata can be used for further interaction with the DID subject, such as the following:

1. To look up a public key to verify a digital signature from the issuer of a verifiable credential
2. To authenticate the DID controller when the controller needs to log in to a website or app
3. To discover and access a well-known service associated with the DID controller, such as a website, social network, or licensing authority

Common scenarios requiring DID resolution. The first is using a DID to identify the issuer of a verifiable credential, the second to log in to a website, and the third to discover a service associated with the DID.

8

© KEN Labs 2022

​

​

Processing a DID URL involves two stages:

DID resolution

Calling a DID resolver to retrieve the DID document.

DID dereferencing

The DID document is further processed to access or retrieve the resource identified by the DID URL—which can be either a subset of the DID document itself or a separate resource identified by the DID URL, such as a web page.

Telecom Italia

DID URL

Construct more advanced URLs rooted on a DID.

9

© KEN Labs 2022

© KEN Labs 2022

Comparison of DIDs and domain names

10

© KEN Labs 2022

Comparison of DIDs with other types of persistent identifiers

Other types of persistent identifiers are generally less suitable for SSI applications.

Compared to other identifiers, DIDs are persistent, resolvable, and decentralized (cryptographic verifiability is not shown since it does not apply to any of the other identifiers).

Customer�Experience

Revenue

Network�resources

11

© KEN Labs 2022

© KEN Labs 2022

The broad categories of DID methods developed

12

© KEN Labs 2022

PKI trust triangle

​

Since it was first conceived, PKI has had one hard problem at its very core.

​

It shows that it’s not enough to think about public/private key pairs.

​

You have to see each key pair in relation to its controlling authority (controller), be that a person, an organization, or even a thing (if the thing has the capacity to generate key pairs and store them in a digital wallet).

The architectural level: Why DIDs work?

Go a step deeper into why DID work.

The basic trust triangle at the heart of all public/private key cryptography

13

© KEN Labs 2022

The dilemma of PKI

​

Public and private keys are bound to each other mathematically such that neither can be forged.

​

But both types of keys are intrinsically related to the controller.

​

The private key must be reserved for the controller’s exclusive use (or its delegates) and must never be revealed to anyone else. By contrast, the public key is just the opposite: it must be shared with any party that wishes to communicate with the controller securely.

The hard problem at PKI‘s very core

The dilemma of PKI

The fundamental roles of public keys vs. private keys in PKI

14

© KEN Labs 2022

The problem is simply this:

​

How do you strongly bind a public key to its controller so that any party relying on that public key (the relying party) can be sure they are dealing with the real controller?

​

After all, if you can fool a relying party into accepting the public key for controller B when the relying party thinks it is the public key for controller A, then for all intents and purposes, controller B can fully impersonate controller A.

The core problem at the heart of PKI

How do you bind a public key to its controller?

The core problem at the heart of PKI: how do you bind a public key to its controller?

15

© KEN Labs 2022

One more piece of the puzzle :

​

The public keys are purely digital entities whose cryptographic validity can be verified in milliseconds, whereas controllers are not.

​

The controllers are real people, organizations, or things that exist in the real world.

​

So the only way to digitally bind a public key to a controller is to add one more piece of the puzzle: a digital identifier for the controller.

The real PKI trust triangle

How do you bind a public key to its controller?

The real PKI trust triangle includes a digital identifier for the controller.

As a relying party, it is essential to know you have the correct public key at the correct point in time for any controller you are dealing with. The additional piece of the puzzle is an identifier for the controller that can be bound to the public key in such a way that relying parties can be confident the public key belongs to the controller and nobody else.

16

© KEN Labs 2022

The identifier-binding problem has two parts:

​

• How do you strongly bind the identifier to the controller?

​

• How do you strongly bind the public key to the identifier?

Two problem spots in PKI

These are the two problem areas that PKI has struggled with since it was born in the 1970s.

The two problem spots when it comes to strongly binding an identifier to a controller.

17

© KEN Labs 2022

identifier-to-controller binding

The conventional PKI solution to the first problem——is to use one of the most suitable existing identifiers and then follow industry best practices to strongly bind this identifier to the controller.

Solution 1: The conventional PKI model

The first solution is the conventional PKI model for issuing digital certificates (certs)

Conventional PKI solves the public-key-to-identifier binding problem using digital certificates signed by some type of certificate authority.

This is the predominant model that has evolved over the last 40 years. Probably the best-known example is the SSL/TLS PKI, which uses X.509 certs to provide secure connections in browsers using the HTTPS protocol (the lock you see in your browser address bar).

public-key-to-identifier binding

18

© KEN Labs 2022

Web of trust

​

It didn’t rely on centralized CAs, but rather on individuals who knew each other directly and therefore could individually sign each other’s public keys—effectively creating peer-to-peer digital certificates.

​

It turns the problem of “Who do you trust?” (the TTP problem) into the problem of “Who do you trust who knows someone else you can trust?” That is, how do you discover a “trusted path” to the digital certificate you want to verify?

Solution 2: The web-of-trust model

So far, no one has developed a reasonably secure, scalable, adoptable solution to this problem.

A diagram of how a web of trust can be constructed

public-key-to-identifier binding

19

© KEN Labs 2022

public-key-to-identifier binding

​

1. It removes humans from the loop.

​

1. It also solves the identifier-to-controller binding problem because only the private key controller can prove control of the identifier.

​

The inability for public key-based identifiers alone to support key rotation has effectively prevented their adoption as an alternative to conventional PKI.

Solution 3: Public key-based identifiers

Generate an identifier for the controller based on the public key.

Public key-based identifiers take a completely different approach to the identifier binding problem by generating the identifier for the controller from the public key.

With public key-based identifiers, the controller controls all three points of the real PKI trust triangle because all three values are generated cryptographically using key material that only the controller possesses.

20

© KEN Labs 2022

Public-key-to-identifier binding

1. The controller generates the original public key-based identifier—the DID—once, based on the genesis public/private key pair. Next, the controller publishes the original DID document containing the DID and the public key.
2. When the controller needs to rotate the key pair, the controller creates an updated DID document and signs it with the previous private key.

Solution 4: DIDs and DID documents

Generate a public key-based identifier once and then be able to continue to verify it after every key rotation.

The controller publishes an updated DID document containing the original DID and the new public key and then digitally signs it with the original private key, creating a chain of trust between the DID documents.

This chain of trust between DID documents can be traced back through any number of updates to the original DID document with the original public key-based identifier. Essentially each DID document serves as a new digital certificate for the new public key—but without the need for a CA or any other human-based TTP to certify it.

21

© KEN Labs 2022

Four benefits of DIDs that go beyond PKI

The benefits of DIDs do not stop there.

3

1

2

Service endpoint discovery

4

Privacy by design at scale

Guardianship and controllership

DID-to-DID connections

DIDs allow us to finally achieve broad adoption of public key-based identifiers and still enjoy key rotation and other essential features of conventional PKI—without the drawbacks. But the benefits of DIDs do not stop there.

22

© KEN Labs 2022

Guardianship and Controllership

Take a newborn baby. The baby would need a parent (or another guardian) to issue this DID on their behalf.Digital guardianship only applies to humans, however.

These represent categories of entities that need third-party controllers—a relationship that has been called controllership to differentiate it from the guardianship of a human being. With guardianship and controllership, we can now extend the benefits of SSI and DPKI to every entity that can be identified.

Beyond PKI benefit 1: Guardianship and controllership

There are many situations where the registrant of the digital certificate is not the party identified by the digital certificate.

An example of a DID used to identify a DID subject (a newborn baby) that is not the controller of the DID.

SSI digital guardianship is a very broad, deep, and rich subject.

23

© KEN Labs 2022

Three-way binding

​

DID controller publishes one or more service endpoint URLs in a DID document.

​

While this makes DID documents generally useful for many types of discovery, it is essential for discovering the agent endpoints necessary to remotely establish DID-to-DID connections and communicate via the DIDComm protocol.

Beyond PKI benefit 2: Service endpoint discovery

Determine how to interact with a DID subject

The three-way binding between DIDs, public keys, and service endpoint URLs.

DID-based discovery of agent endpoint URLs is as essential to SSI as DNS-based discovery of IP addresses is to the web.

24

© KEN Labs 2022

peer DIDs

​

One DID method—peer DIDs created exclusively for this purpose.

​

Every DID represents the opportunity for its controller to create an instant, secure, private, peer-to-peer connection with any other DID controller.

​

Even better, unlike static public key certificates that must be obtained in advance from a CA, DIDs can be generated immediately, locally, on-the-fly as they are needed for new connections.

Beyond PKI benefit 3: DID-to-DID connections

The five special properties of DID-to-DID connections

Whether between peer DIDs (the default) or public DIDs, DID-to-DID connections are the centerpiece of Layer 2 of the Trust over IP stack.

25

© KEN Labs 2022

3rd Advantage :

• with signed data, we can finally protect both individuals and relying on parties from the damage caused by the massive data breaches we read about almost daily (Target, Equifax, Sony, Yahoo, Capital One).
• What motivates criminals to break into those data silos is the value of that personal data— primarily because the criminals can use it to break into accounts all over the internet.

1st Advantage :

• Each pairwise-unique peer DID gives you and your relying party your own permanent private channel connecting the two of you.
• this channel is that you can authenticate each other automatically—in both directions—just by exchanging messages signed by each of your private keys.
• Spoofing or phishing a relying party with whom you already have a connection becomes next to impossible.

2.5 days

2nd Advantage :

• peer DIDs and private channels give you one simple, standard, verifiable way to share signed personal data.

​

• On your side, the benefit is convenience and control—at a glance, you can see what you shared with whom and why.

​

• On the relying party side, the benefit is fresh, first-person data with cryptographically verifiable, GDPR-auditable consent.

Beyond PKI benefit 4: Privacy by design at scale

The five special properties of DID-to-DID connections.

26

© KEN Labs 2022

The semantic level: What DIDs mean?

Exploring what they mean for the future of SSI and the internet.

3

1

2

DID networks and digital trust ecosystems

4

What does a DID identify?

The meaning of an address

​

Why isn’t a DID human-meaningful?

Having explained how and why DIDs work, we now turn to the lowest level of understanding DIDs: exploring what they mean for the future of SSI and the internet.

27

© KEN Labs 2022

The meaning of an address

An historical perspective on the evolution of addresses for different types of networks.

Addresses do not exist on their own. They only exist in the context of a network that uses them.

28

© KEN Labs 2022

DID networks and digital trust ecosystems

DIDs are essential to each layer of the stack as follows:

DIDs published on public blockchains like Bitcoin and Ethereum; distributed ledgers like Sovrin, ION, Element, and Veres One; or distributed file systems like IPFS can serve as publicly verifiable trust roots for participants at all higher layers. They literally form the foundation of a trust layer for the internet.

By default, these are pairwise pseudonymous peer DIDs issued and exchanged following the Peer DID specification, so they exist only at Layer 2. However, DIDComm can also use public DIDs from Layer 1.

DIDs are integral to the process of issuing and verifying digitally signed verifiable credentials as well as to the discovery of service endpoint URLs for credential exchange protocols.

DIDs are the anchor points for discovery and verification of the governance authorities (as legal entities) and governance frameworks (as legal documents) for digital trust ecosystems of all sizes and shapes (as well as for the participants they specify). DIDs also enable verifiable credentials to persistently reference the governance frameworks under which they are issued—and for governance frameworks to reference each other for interoperability.

29

© KEN Labs 2022

Why isn’t a DID human-meaningful?

Zooko’s triangle.

Operators are looking to implement big data and analytics in the next 2 years

​

​

It is the trilemma illustrated above Zooko’s trigngle, which states that an identifier system can achieve at most two of the following three properties.

Although some believe Zooko’s triangle can be solv`ed, most internet architects agree it is far easier to achieve two of these three properties than all three.

The DIDs alone could not solve the human-meaningful naming problem, they could in fact anchor a promising new solution. The trick was to do it at the verifiable credentials layer (Layer3).

By creating searchable credential registries for the names in these credentials, we could collectively build a naming layer that is semantically richer, fairer, more trusted, and more distributed than the current DNS naming layer.

30

© KEN Labs 2022

What does a DID identify?

Does the DID identify the DID document as a resource?

No!

To be very precise, the DID identifies the DID subject and resolves to the DID document (by following the protocol specified by the DID method). The DID document is not a separate resource from the DID subject and does not have a URI separate from the DID. Rather the DID document is an artifact of DID resolution controlled by the DID controller to describe the DID subject.

​

——W3C DID Working Group

​

“A DID identifies the DID subject.” And that is completely true, no matter what that subject is: a person, organization, department, physical object, digital object, concept, software program—anything that has identity.Where confusion may arise is with the DID document that a DID resolves to.

31

© KEN Labs 2022

Pando DID: pando.network

KEN Labs Research: kencloud.com

info@pando.network

twitter.com/KenLabs_Web3

​

THANK YOU

WATCHING

32

© KEN Labs 2022