Skip to main content

Decentralized identifiers (DIDs)

⏱️ Skim​

Decentralized identifiers (DIDs) are globally unique identifiers generated without a centralized authority and used to identify some kind of resource — in this context, typically used to identify an issuer, a holder, or a verifier of digital identities and credentials.

The identifier, which looks similar to a URL one would type into a browser, can be resolved, or looked up, to get information about the identified subject along with cryptographic material. This cryptographic material enables the controller of the DID to prove their control using cryptographic proofs.

In practical terms, DIDs offer benefits over other identifiers on two levels: first, they offer highly available, high-assurance identifiers with less friction and more control. Second, DID-based architecture offers a universal standard for resolving identifiers while those identifiers can vary in method and implementation — so one system can handle identifiers with different trust models and levels of assurance.

⏲️ Peruse​

DIDs are globally unique identifiers used to identify a resource. This resource is commonly an issuer, a holder, or a verifier of digital credentials, but a DID could be used to identify anything. Global uniqueness is useful because it gives some assurance that the thing referred to or interacted with is the same entity across different times and places.

Typically the creation, maintenance, and control of globally unique identifiers is mediated by some central authority responsible for ensuring global uniqueness. DIDs, however, can be generated and controlled by individuals and organizations apart from central authorities. This reduces friction and offers those identified more control over their own identifiers.

The identifier itself is a URI, which looks similar to a URL one would type into a browser. This URI can be resolved, or looked up, to return a DID document which offers information about the identified resource, the DID subject. In addition to identifying the DID subject, the DID document also contains methods for verifying control of the DID. This means the DID itself carries with it a statement on how the controller of the DID will authenticate themselves.

Generally this authentication is done through cryptographic keys. DIDs are commonly generated in association with a cryptographic private/public key pair, with the public key being stated in the DID document. This enables the controller of the DID to authenticate themselves using cryptographic proofs.

In practical terms, DIDs offer benefits over other identifiers on two levels:

  • DIDs enable agents — issuers, holders, and verifiers — to interact with each other with a high level of assurance in the identity of the other, without the added friction of centralized authorities mediating the creation and resolution of the identifiers. This assurance is rooted in cryptography: the DID carries with it what is needed for proving oneself to be the thing identified.

  • Since DIDs offer a universal standard for resolving identifiers while also leaving open certain details of implementation, they bring an extra layer of abstraction to identifiers. This abstraction enables identifiers to use different trust models and offer different levels of assurance, all within the same DID-based architecture.

📖 Deep dive​

Globally unique identifiers are in use everywhere, for example:

  • A social security number assigned to a person at birth by a government

  • An employee ID number assigned by an employer to an employee

  • A URL as registered with an ICANN-accredited registrar

These identifiers are useful because they allow us to refer to the same thing across different times and places. This ability to refer across contexts is based on the global uniqueness of the identifier. In the cases above (and in many, many more) the identifier is granted and maintained by a central authority.

Centralized identifiers​

Take, for example, the names of race horses. In order to compete in events, a horse must have a unique name to differentiate it from other horses past and present. Someone wanting to register a horse for racing must register this horse with a central authority (for example, The Jockey Club Registry) and the central authority may, if the name is both unique and follows all the other rules of naming as determined by the central authority, grant the proposed name to the horse.

The central authority is responsible for maintaining the identifier "database" (be it in electronic form, or on paper or however). The trustworthiness of any given racing horse name being unique or following any other rule of race horse names is directly tied to the trustworthiness of the central authority and its processes for granting and maintaining identifiers.

This kind of identifier is centralized. Nobody can simply generate their own social security number and go about using it, or bring a horse to a race, declare the horse's name to be "Seabiscuit" and expect to compete. In addition to granting or assigning the identifier, the central authority also controls the identifier through its lifecycle. The authority can revoke the identifier, for example, or reassign it to someone or something else. All basic operations of the identifier — Create, Resolve, Update, and Deactivate, or what is effectively "CRUD" for identifiers — are done either directly by or mediated through the central authority.

There are a several drawbacks to centralized identifiers.

  • Not so easy to create:

    Because creation is mediated through the central authority there is always added friction and extra resources required. Beyond that, the ease of creation will vary across different centralized registries.

  • Dependent on a centralized authority:

    Centralized identifiers rely wholly on the centralized authority. If the authority dissolves, the identifier no longer functions. The subject has no control over the identifier, as evidenced by the authority's ability to reassign an identifier to a different subject or delete it from the registry. A registered domain name only identifies the subject for as long as the domain name is rented. If the bills stop getting paid or the terms reach their end without renewal, the identifier still exists but ceases to refer to the same subject.

  • Resolvability is limited:

    Whether the identifier is resolvable to useful information about the thing identified depends on what data the authority makes available and how readily accessible this data is. A domain name is resolvable to a website but many centralized identifiers are not so readily resolvable. Generally speaking, centralized identifiers are useful within the context for which the centralized authority has a use case.

  • Not cryptographically verifiable: This kind of identifier comes with no inherent method of cryptographic verification of identity and ownership. The proof of ownership of an identifier of this kind relies on an additional layer of authentication on top of the identifier itself.

Designing a better identifier​

The essential goal of decentralized identifiers is to create trustable identities across contexts, without the need for a centralized authority to register and maintain identities, and while giving the subjects of the identities control over their respective identifiers.

In order to accomplish this, several things must be in place:

  • Method for generating identifiers quickly and easily without relying on a central authority

  • Assurance that any given identifier is unique and persistent

  • Method for resolving the identifier to reliably return information about its subject

  • Method for proving identity and ownership of the identifier

To accomplish this, the W3C specifies DIDs as a new kind of identifier.

DIDs​

Put simply, a DID is a uniform resource identifier (URI), similar to a URL one puts in a browser to go to a website. They look like this:

did:method:1234567890abcdefghijklmnop...

In the example above, the did identifies the URI scheme. Many URI schemes are registered alongside DIDs. All DIDs start with did:.

The method: specifies which DID method was used to generate the DID and thus the processes used to resolve the DID. More on DID methods below.

What follows after the DID method is the method-specific identifier, the unique string that completes the identifier.

Similar to how a URL can be resolved, using a browser as a tool, to a web resource, a DID can be resolved to a DID document, a document containing information about the DID, including:

  • Identification of the controller of the DID document

  • Cryptographic materials that can be used to prove identity and ownership, along with other verification methods

  • Optionally provide references to external references such as websites, email addresses, or other points of service

DID methods​

Each DID method specifies how CRUD operations are performed for that method. The W3C specification leaves many of the details open-ended so that different entities can create different methods for different use cases while still meeting the core DID specification. To date, more than 100 different methods are in some form of development. See the registry.

DID lifecycle​

Next we look at how DIDs come to be and how they are used. The lifecycle described below is generalized to apply to many different DID methods and does not describe all DID methods.

  1. Generate a cryptographic key pair

Most DIDs are backed by cryptographic keys, and it's the public key that makes the DID powerful.

  1. Generate a DID and its corresponding DID document

Choose the preferred DID method and perform that method's specified operations for DID and DID document creation. No need to go to a centralized authority to register the identifier; instead the identifier is generated from the cryptographic key.

For those DIDs which are backed by public keys, it's here where the public key is specified as the authentication verification method for the DID. This means the owner of the private key associated with the DID's authentication verification method can prove this ownership cryptographically.

The precise details on DID generation differ according to the method.

Some DID methods involve publishing to some kind of external registry such as a distributed ledger or a web server. Other DID methods generate everything locally. Each method carries with it benefits and drawbacks. For example, while publishing to a distributed ledger brings with it certain advantages to maintaining verifiability through key rotation, it also is more resource intensive and may not be appropriate for use cases where a high number of DIDs need to be created or where interactions are expected to be transient.

  1. Resolve the DID

Each DID method specifies how to resolve DIDs of that method. These operations are used to return the associated DID document. This could mean performing a calculation or looking something up on a blockchain or something else entirely. The important thing is that resolving the DID document provides the verification methods of the DID. Typically, this means the public keys provided for authenticating control of the DID. It can also mean the verification method for some other verification relationship, such as a public key used for issuing credentials or one used for transmitting confidential information.

For a verifiable credential (VC), a verifier resolves the issuer's DID, returning the public key to verify the issuer's signature on the credential.

  1. Update & Deactivate

These are optional operations according to the DID specification; each method must declare if and how a DID can be updated or deactivated. Typically for locally generated DIDs there are no means for updating or deactivating.

Why are DIDs special?​

What makes DIDs different? And how do these relate to the tenets for a better identifier, listed above?

  • Method for generating identifiers quickly and easily without relying on a central authority

While DIDs vary in their quickness and ease of generation, they are inherently easier to generate than centralized identifiers because they remove the friction in dealing with a centralized authority. One needs only to follow the operation as described by the DID method they've chosen. Anyone with the knowledge of the method or the right tools can do it, whenever desired.

  • Assurance that an identifier is unique and persistent

All valid DID methods produce method-specific identifiers which are globally unique within the given DID method; some DID methods produce method-specific identifiers which are themselves globally unique. This uniqueness is derived from cryptographic algorithms such as elliptic curves or random number generation.

DIDs are also persistent, meaning that the identifier is not reliant on a central authority to maintain its existence and reference and, generally speaking, some third-party is unable to take one's identifier away. Of course, it is possible to lose control over one's private key and thus lose control of a DID. It's also possible that a DID refers to a subject and this reference changes at some point in time to refer to some other subject. But there is no central authority that can simply take an DID from someone without consent.

info

There's already a type of identifier which generates globally unique and persistent identifiers without the need for a central authority: the Universally Unique ID, or UUID. UUIDs are 128-bit identifiers generated through mathematical algorithms which virtually guarantee global uniqueness. But UUIDs are missing some key elements, described next.

  • Method for resolving the identifier to reliably return information about its subject

Unlike, for instance, a UUID, all DIDs are resolvable to their associated DID document if the specified operations are used. This universal standard for resolving identifiers enables a special kind of interoperability discussed in the next section.

  • Method for proving identity and ownership

DIDs are backed by verification methods which are typically cryptographic keys. The DID document essentially lists the public key and the identifier is generally generated from a public key. This means that control over the private/public key pair equates to control over the identifier; the public key and the identifier are bound together and control of one proves control of the other.

While the private/public key pair provides the DID with cryptographic backing for verification of control, the DID adds a layer of abstraction to the key pair. This abstraction layer makes it possible to, in some cases, achieve a kind of longevity not normally possible with key pairs. For example, if one is using only a key pair and there is suspicion of a private key leak, the key is essentially lost because key rotation is not possible. For those DID methods allowing key rotation, it's possible to keep the same identifier long-term by executing a regular key rotation for security purposes by updating the DID method with new keys.

The DID superpower​

The benefits of DIDs described above make for highly available, high-assurance identifiers with increased control and decreased friction. The real superpower of DIDs, however, is seen when taking a step back and looking at DID-based architecture.

DIDs offer a universal standard of resolving identifiers while enabling flexibility for different trust models and levels of assurance within the same system.

DIDs are effectively a layer of abstraction above identifiers: universal standards can be defined for all DIDs while context-specific implementation details can be defined for each method. This enables different trust models to be enacted in different DID methods, and different DID methods to be implemented within the same system.

This means that implementing a DID-based architecture enables interoperability and flexibility, both now and in the future. Choose the DID methods that suit current needs and contexts — for example, one DID method for use with long-term verifiable credentials, one DID method for user authentication, and one DID method for short-lived physical access credentials — and employ them all in the same system. As contexts change, use new DID methods.

Procivis One & DIDs​

See the DIDs guide for supported methods. Procivis One is extensible: we've built our solution to enable the addition of new DID methods with little effort. To inquire about or request a specific DID method, use the contact form on our supported technologies page.

Procivis One takes the flexibility and interoperability associated with DID-based architecture and extends it to the entire digital identity and credentials ecosystem: seamlessly swap DID methods, cryptographic algorithms, credential formats, protocols, revocation methods, and key storage methods — all while maintaining the same user-friendly workflows. Procivis One handles the complexity of how all these elements interact so users can easily issue, hold, and verify digital identities and credentials.