A Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolvable with high availability, and cryptographically verifiable. DIDs are typically associated with cryptographic material, such as public keys, and service endpoints, for establishing secure communication channels. DIDs are useful for any application that benefits from self-administered, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and identifiers for Internet of Things scenarios. For example, current commercial deployments of W3C Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. This document is an introduction to the concept of Decentralized Identifiers.

Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to public-credentials@w3.org (subscribe, archives).

Portions of the work on this specification have been funded by the United States Department of Homeland Security's Science and Technology Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002 and HSHQDC-17-C-00019. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.

Work on this specification has also been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, Drummond Reed, Joe Andrieu, Kim Duffy, and Heather Vescent.

Introduction

At a superficial level, a decentralized identifier (DID) is simply a new type of globally unique identifier. But at a deeper level, DIDs are the core component of an entirely new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. This decentralized public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world).

This primer is designed to give newcomers to DID architecture the background they need to understand not just the DID specification, but the overall architecture for decentralized identity represented by the family of DID-related specifications currently under development. It covers:

How DIDs Differ from Other Globally Unique Identifiers

The need for globally unique identifiers that do not require a centralized registration authority is not new. UUIDs (Universally Unique Identifiers, also called GUIDs, Globally Unique Identifiers) were developed for this purpose in the 1980s and standardized first by the Open Software Foundation and then by IETF RFC 4122.

The need for persistent identifiers (identifiers that can be assigned once to an entity and never need to change) is also not new. This class of identifiers was standardized as URNs (Uniform Resource Names) first by IETF RFC 2141 and more recently by RFC 8141.

As a rule, however, UUIDs are not globally resolvable and URNs – if resolvable – require a centralized registration authority. In addition, neither UUIDs or URNs inherently address a third characteristic – the ability to cryptographically verify ownership of the identifier.

For self-sovereign identity, which can be defined as a lifetime portable digital identity that does not depend on any centralized authority, we need a new class of identifier that fulfills all four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.

The Format of a DID

In 2016 the developers of the DID specification agreed with a suggestion from Christopher Allen that DIDs could be adapted to work with multiple blockchains by following the same basic pattern as the URN specification:

urn:uuid:fe0cde11-59d2-4621-887f-23013499f905
urn:uuid:fe0cde11-59d2-4621-887f-23013499f905

The key difference is that with DIDs the namespace component identifies a DID method, and a DID method specification specifies the format of the method-specific identifier.

did:example:12345abcde
did:example:12345abcde

DID methods (further explained below) define how DIDs work with a specific blockchain. All DID method specs must define the format and generation of the method-specific identifier. Note that the method specific identifier string must be unique in the namespace of that DID method.

DID Documents

DID infrastructure can be thought of as a global key-value database in which the database is all DID-compatible blockchains, distributed ledgers, or decentralized networks. In this virtual database, the key is a DID, and the value is a DID document. The purpose of the DID document is to describe the public keys, authentication protocols, and service endpoints necessary to bootstrap cryptographically-verifiable interactions with the identified entity.

A DID document is a valid JSON-LD object that uses the DID context (the RDF vocabulary of property names) defined in the DID specification. This includes six components (all optional):

  1. The DID itself, so the DID document is fully self-describing.

  2. A set of cryptographic material, such as public keys, that can be used for authentication or interaction with the DID subject.

  3. A set of cryptographic protocols for interacting with the DID subject, such as authentication and capability delegation.

  4. A set of service endpoints that describe where and how to interact with the DID subject.

  5. Timestamps for auditing.

  6. A optional JSON-LD signature if needed to verify the integrity of the DID document.

See the DID specification for several examples of DID documents.

DID Methods

DIDs and DID documents can be adapted to any modern blockchain, distributed ledger, or other decentralized network capable of resolving a unique key into a unique value. It does not matter whether the blockchain is public, private, permissionless, or permissioned.

Defining how a DID and DID document are created, resolved, and managed on a specific blockchain or “target system” is the role of a DID method specification. DID method specifications are to the generic DID specification as URN namespace specifications (UUID, ISBN, OID, LSID, etc.) are to the generic IETF URN specification (RFC 8141).

DID method specifications typically define at least the following operations for a particular target system:

  1. Create. Some DID methods may generate a DID directly from a cryptographic key pair. Others may use the address of a transaction or a smart contract on the blockchain itself.

  2. Read. Some DID methods use blockchains that can store DID documents directly on the blockchain. Others may instruct DID resolvers to construct them dynamically based on attributes of a blockchain record. Still others may store a pointer on the blockchain to a DID document stored in one or more parts on other decentralized storage networks such as IPFS or STORJ.

  3. Update. The update operation is the most critical from a security standpoint because control of a DID document represents control of the public keys or proofs necessary to authenticate an entity (and therefore for an attacker to impersonate the entity). Since verification of DID document update permissions can only be enforced by the target blockchain, the DID method specification must define precisely how authentication and authorization are performed for any update operation.

  4. Delete. DID entries on a blockchain are by definition immutable, so they can never be “deleted” in the conventional database sense. However they can be revoked in the cryptographic sense. A DID method specification must define how this termination is performed, e.g., by writing a null DID document.

See the DID Method Registry for a complete list of all known DID Method specifications.

DIDs and Privacy by Design

Privacy is an essential component of any identity management solution; it is especially critical for a global identity system that uses immutable public blockchains. Thankfully DID architecture can incorporate Privacy by Design at the very lowest levels of infrastructure and thus become a powerful, new, privacy-preserving technology if deployed using best practices such as:

  1. Pairwise-pseudonymous DIDs. While DIDs can be used as well-known public identifiers, they can also be used as private identifiers issued on a per-relationship basis. So rather than a person having a single DID, like a cell phone number or national ID number, she can have thousands of pairwise-unique DIDs that cannot be correlated without her consent, yet can still be managed as easily as an address book.

  2. Off-chain private data. Storing any type of PII on a public blockchain, even encrypted or hashed, is dangerous for two reasons: 1) the encrypted or hashed data is a global correlation point when the data is shared with multiple parties, and 2) if the encryption is eventually broken (e.g., quantum computing), the data will be forever accessible on an immutable public ledger. So the best practice is to store all private data off-chain and exchange it only over encrypted, private, peer-to-peer connections.

  3. Selective disclosure. The decentralized PKI (DPKI) that DIDs make possible opens the door to individuals gaining greater control over their personal data in two ways. First, it enables it to be shared using encrypted digital credentials (see below). Second, these credentials can use zero-knowledge proof cryptography for data minimization, e.g., you can disclose that you are over a certain age without disclosing your exact birthdate.

DIDs and Verifiable Credentials

DIDs are only the base layer of decentralized identity infrastructure. The next higher layer – where most of the value is unlocked – is verifiable credentials. This is the technical term for a digitally signed electronic credential that conforms to the interoperability standards being developed by the W3C Verifiable Claims Working Group.

DIDs can be used to identify various entities in the Verifiable Credentials ecosystem such as issuers, holders, subjects, and verifiers. More generally, DIDs can be used as identifiers for people, devices, and organizations.

See the Verifiable Credentials Primer for a brief introduction to the topic.

Appendix A: DID Community Resources

Besides the links throughout this primer, these additional resources are available to anyone interested in joining the communities that are actively developing specifications, experiments, and pilot projects.