Decentralized Identifiers

  1. First, email addresses have a real, intended use (sending email) and so might change for reasons unrelated to their use as an identifier.
  2. Second, email addresses are generally correlatable. If you use the same email address for all your account identifiers, it’s easy to track your activity at all those different places.
  3. Third, email addresses are generally administered by someone else who can take them away. Even if you use your own domain name, you’re just renting that and may give up control in the future.
  4. Fourth, email addresses have limited global resolvability. All you can do is send an email message to the owner.
  5. Lastly, email addresses are reusable. If you stop using an email address the administrator of the email system may reassign it, decreasing security and privacy.

Decentralized Identifiers

Decentralized Identifiers, or DIDs, are a new kind of identifier that solves the problems outlined in the last section. As noted above, DIDs are one of the foundational technologies of self-sovereign identity. The DIDs specification is being developed inside the W3C Credentials Community Group. Let’s explore the properties of DIDs and look at how they are formatted.

DID Properties

Decentralized identifiers should be implemented so that they have these important properties:

  • non-reassignable-DIDs should be permanent, persistent, and non-reassignable. Permanence ensures that the identifier always references the same entity. As a result, DIDs are more private and more secure than identifiers that can be reassigned such as a domain name, IP address, email address, or mobile number. Permanence is vital for user control and self sovereignty.
  • resolvable-DIDs are made useful through resolution. Resolution ensures that a DID is actionable. We’ll discuss how DID resolution works in more detail below.
  • cryptographically verifiable-DIDs are designed to be associated with cryptographic keys and the entity controlling the DID can use those keys to prove ownership. That can happen in several ways. The result of resolving a DID may be cryptographically signed to ensure its integrity. The resolution also provides one or more public keys associated with the DID. Using cryptographic keys, the owner can prove they are in control of the DID. Parties who have exchanged DIDs can mutually authenticate each other and encrypt their communication.
  • decentralized- DIDs are designed to function without a central registration authority. Depending on the DID method specification for a given class of DIDs, they might also be created and updated outside the purview of any single party or entity, increasing censorship resistance.

DID Syntax

The syntax of a DID is fairly simple and designed to support different decentralization methods. The following diagram shows the primary, required components of a DID:

DID Resolution

Useful identifiers have a means of discovering what the identifier means. Discovery is performed in the manner outlined in the DID method. The DID specification outlines the necessary operations any method must implement. Different methods can support their own way of performing resolution using a specific blockchain or other storage system. The method outlines the way to create, retrieve, and update the DID and it’s associate DID Document. For example, the did:sov method outlines how to create, lookup, and update the DID on the Sovrin ledger. A resolver can use the method to find the routines necessary for interacting with a given identifier. Methods allow a variety of systems to serve as repositories for DIDs.

DID Documents

DID Documents describe the public keys, authentication protocols, and service endpoints necessary to initiate trustworthy interactions with the identified entity. A DID Document is a JSON-LD document that contain the following six, optional components:

  1. The DID that points to the DID Document, identified by the key id.
  2. A list of public keys identified by the key publicKey.
  3. Lists of protocols for authenticating control of the DID and delegated capabilities identified by the key authentication.
  4. A set of service endpoints, usually URLs, that allow discovery of way to interact with the entity that the DID identifies identified by the key service.
  5. Timestamp indicating when the DID Document was created and updated for auditing the DID Document identified, respectively, by the keys created and updated.
  6. A digital signature for verifying the integrity of the DID Document identified by the key proof.
{
"@context": "https://w3id.org/did/v1",
"id": "did:sov:123456789abcdefghij",
"publicKey": [{
"id": "did:sov:123456789abcdefghij#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:sov:123456789abcdefghij",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"authentication": [{
"type": "RsaSignatureAuthentication2018",
"publicKey": "did:sov:123456789abcdefghi#keys-1"
}],
"service": [{
"id": "did:sov:123456789abcdefghij;exam_svc",
"type": "ExampleService",
"serviceEndpoint": "https://example.com/endpoint/8377464"
}],
"created": "2018-02-08T16:03:00Z",
"proof": {
"type": "LinkedDataSignature2015",
"created": "2018-02-08T16:02:20Z",
"creator": "did:sov:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
"signatureValue": "QNB13Y7Q9...1tzjn4w=="
}
}
did:sov:123456789abcdefghij;exam_svc
did:sov:123456789abcdefghij;exam_svc/foo/bar?a=1#flip
https://example.com/endpoint/8377464/foo/bar?a=1#flip

Public and Private DIDs

The preceding use case-putting my email in a DID Document-might be a privacy problem if I don’t want my email to be publicly readable. Fortunately, not all DIDs are public. Identifiers can be, in the language of Kim Cameron (PDF), omnidirectional or unidirectional. Kim says in reference to his fourth law, Directed Identity:

Peer Relationships

In On Sovereignty, I write:

DIDs and the Identity Metasystem

In The Laws of Identity, I make the case for Sovrin being an identity metasystem-a universal foundation upon which other identity systems can be built. DIDs and DID Documents are a big part of the metasystem. Sovrin is designed to support the use of DIDs and DID Documents. Furthermore, Sovrin agents manage DID-based peer relationships, verifiable credential exchange, public and private DID resolution, and DID-based secure communication and authentication. DIDs allow Sovrin to be used by multiple parties for their own purposes.

Online Sovereignty

Decentralized identifiers and the attendant infrastructure that supports them provide a significant improvement over the ad hoc, email, and domain name based identifiers we’ve used for identity systems in the past. DIDs represent a universal addressing, abstraction, and verification layer for key pairs, endpoints, and any other information we wish to include in the DID Document. Layer verifiable credential exchange on top of this for multi-source identity and this constitutes a significant upgrade to online identity.

Endnotes

  1. All of these may be other things as well like addresses or names, but they’re still identifiers.
  2. I’ve modified this DID Document slightly to support the examples I want to make.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Phil Windley

Phil Windley

I build things; I write code; I void warranties