Describe what makes DIDs different than other identifiers

  • 6 minutes

As referenced during the W3C DID Working Group meeting in Fukuoka, Japan in September 2019, there were four reasons attributed to funding the development of the DID specification that is currently published as the W3C recommendation for Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations.

  • "A permanent (persistent) identifier" - A DID is designed to be persistent. Persistence means, “a DID cannot be removed or made inoperable by a third-party without the consent of the DID’s controller.”
  • "A resolvable identifier" - A DID is a resolvable identifier, meaning that you can look it up to discover something associated with that DID, for example to discover its metadata. The information the DID resolves to is a DID document.
  • "A cryptographically-verifiable identifier" - A DID is a cryptographically verifiable identifier, meaning that the entity that controls the DID, the DID Controller, can prove control of the identifier using cryptography.
  • "A decentralized identifier" - A DID is a decentralized identifier. This means there's no single registration authority to create and manage DIDs. DIDs use decentralized networks, also referred to as verifiable data registries, to register and record transactions. These registries can be distributed ledgers, blockchains, distributed file systems, or other trusted data storage. There are many different types of verifiable data registries that DIDs can use. The approach employed is dependent on the DID method.

These four reasons serve as core properties of DIDs. Although there are existing identifiers that can meet some of these properties, a DID is the first new type of identifier to meet all four of these properties.

Resolvable DID and DID Documents

If you think about identifiers in general, they provide value when they're used in the context of some application where it can provide some information or enable an interaction or communication. For example, a URL, which is a type of identifier, really only has value when it's entered into a web browser and returns a webpage that can be consumed. In this context, a URL resolves to a webpage. The same concept applies with DIDs but rather than using a web browser and resolving to a webpage, a DID uses a piece of software or hardware, called a resolver and returns a DID document.

A DID document is a publicly available data set that describes the entity identified by the DID, referred to as the DID subject. The W3C recommendation for Decentralized Identifiers (DIDs) v1.0 defines the core properties of a DID document. Included in the core properties are:

  • Verification methods - This includes Cryptographic public keys and associated metadata. For example, a cryptographic public key can be used as a verification method for a digital signature.
  • Services - Services are used for communicating or interacting with the DID subjects. This may include information the subject wants to advertise. Examples of these may include verifiable credential repository services, file storage services, agent services, and more. These are represented as service endpoints represented as a network address such as an HTTP URL.

Diagram that shows content that is included in a DID document. It includes the DID, the public keys, and service endpoints.

These are just a few examples of data, commonly included in the DID document. DID documents are publicly available documents that are consumed by the applications and services that employ DIDs (not intended for end-user consumption). DID documents contain information that describes the DID subject, such as its public key, service endpoints and other metadata, but should not contain personal data about the subject. As a publicly available document, a best practice is that it should contain the minimum amount of information needed to support the desired interaction or communication.

DIDs and public-key cryptography

To understand how DID controllers can prove control of their identifier, it's helpful to understand a bit about the public-key cryptography.

DIDs use asymmetric cryptography, also referred to as public-key cryptography. Public-key cryptography uses a public and private key pair, is used for securing information via encryption and, establishing proof of authenticity and consent via digital signatures. Refer to Describe concepts of cryptography, for more detailed information. With public-key cryptography, a challenge is to validate that the public key that is shared broadly actually comes from the entity you expect it to come from, not an imposter. In other words, how do you bind the public key to the identifier that represents the entity? In traditional public-key cryptography, that trust is established through digital certificates from trusted centralized certificate authorities (CAs) that form a centralized public-key infrastructure (PKI). A property of DIDs, however, is that they're decentralized so you don’t want to have a dependency on a CA. DIDs address this because their method specific identifier is derived, either directly or indirectly, from information related to the public key. This makes the DID inherently bound to the public key, without any centralized CA. The net result is that the entity that controls the DID can prove control of that identifier using cryptography. In so doing, DIDs enable a type of distributed public-key infrastructure.

An approach where a DID is based on a public key would suggest that the DID must change if you have to rotate the cryptographic keys, for security purposes. The need to change the DID contradicts the property that a DID is persistent. The DID document addresses this issue. When the keys need to change, the controller of the DID can publish an update to the DID document that includes the new public key but is signed with the original private key. The update to the DID document can be authenticated because the original public key can be traced back to the original version of the DID document. This approach establishes a chain of trust across the updates. Conceptually, you can think of this as being analogous to software version control, where there's only one current version of software, but you can trace back across previous versions to see what's been updated.