Now that we’ve covered the different components of decentralized identities, let’s take a closer look at decentralized identifiers and how they are used. The following is based on W3C’s definition of decentralized identifiers.
Decentralized identifiers enable the creation of decentralized, verifiable digital identities. These identities can represent people, organizations, businesses, etc. The aim of these identifiers is to be completely decoupled from centralized or federated entities.
External entities may nevertheless play a part in the process, but in a much more limited way. Indeed, the only actions that can be taken by third parties are the issuing and verification of proofs. Furthermore, as we have seen, disclosing the proof will only involve sharing confirmation of the veracity of the information, without revealing the underlying information itself. The decision to disclose the proof is at the sole discretion of the data owner.
As outlined above, each DID document can express cryptographic material, verification methods, or services that provide a set of mechanisms enabling a DID controller to prove control of the DID.
A DID is a text string consisting of three parts:
- a scheme identifier
- an identifier for the DID method
- a DID method-specific identifier attributed to the owner
The example DID above, taken from W3C’s definition, represents a DID document. A DID document contains information associated with the DID, such as the means of cryptographically authenticating a DID controller. We will look at DID controllers in more detail later.
Decentralized identifiers are essential components of verifiable credentials.
Let’s take a closer look at the design goals set out by W3C.
In the previous section, we covered the main elements of a decentralized identity solution. We will now turn to the essential components of a DID.
The diagram below, taken from the W3C definition, gives an overview of the architecture of a DID, as well as the relationship between the elements with which it interacts. The following descriptions of these elements are also taken from the W3C definition.
A decentralized identifier, or DID, is a URI composed of three parts: the scheme DID, a method identifier, and a unique, method-specific identifier specified by the DID method.
DIDs are resolvable to DID documents. A DID URL extends the syntax of a basic DID to incorporate other standard URI components such as path, query, and fragment, in order to locate a particular resource—for example, a cryptographic public key inside a DID document, or a resource external to the DID document.
The subject of a DID is the entity identified by the DID. The DID subject might also be the DID controller. The subject of a DID could be a person, group, organization, or even a concept.
The controller of a DID is the entity (person or organization) that has the capability—as defined by a DID method—to make changes to a DID document.
It is generally necessary to control a whole set of cryptographic keys in order to make these changes.
A DID may have more than one controller, and the DID subject can be the DID controller, or one of them.
In order to be resolvable to DID documents, DIDs are typically recorded on an underlying system or network of some kind. Regardless of the specific technology used, any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. Examples include blockchains, decentralized file systems (such as IPFS), databases of any kind, peer-to-peer networks, and other forms of trusted data storage.
DID documents contain information associated with a DID. They typically express verification methods, such as cryptographic public keys, and services relevant to interactions with the DID subject. A DID document can be serialized.
DID methods are the mechanism by which a particular type of DID and its associated DID document are created, resolved, updated, and deactivated.
A DID resolver is a system component that takes a DID as input and produces a conforming DID document as output. This process is called DID resolution. The steps for resolving a specific type of DID are defined by the relevant DID method specification.
A DID URL dereferencer is a system component that takes a DID URL as input and produces a resource as output. This process is called DID URL dereferencing.