Decentralized identifiers
Last updated
Last updated
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.
DIDs are URIs that associate a DID subject with a DID document allowing identification and interactions associated with that subject.
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.
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
Decentralized identifiers are essential components of verifiable credentials.
Letβs take a closer look at the design goals set out by W3C.
Goal
Description
Decentralization
Eliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, services, and other information.
Control
Give entities, both human and nonhuman, the power to directly control their digital identifiers without the need to rely on external authorities.
Privacy
Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
Security
Enable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
Proof-based
Enable DID controllers to provide cryptographic proof when interacting with other entities.
Discoverability
Make it possible for entities to discover DIDs for other entities, to learn more about or interact with those entities.
Interoperability
Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
Portability
Be system and network independent, and enable entities to use their digital identifiers with any system that supports DIDs and DID methods.
Simplicity
Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy.
Extensibility
Where possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.
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.