Decentralised Identifier

0 views

Skip to first unread message

Vickiana Sconyers

unread,

Aug 3, 2024, 5:28:07 PM8/3/24

to rapalrelu

Decentralized identifiers (DIDs) are a type of globally unique identifier that enables an entity to be identified in a manner that is verifiable, persistent (as long as the DID controller desires), and does not require the use of a centralized registry.[1] DIDs enable a new model of decentralized digital identity that is often referred to as self-sovereign identity or decentralized identity.[2] They are an important component of decentralized web applications.

A decentralized identifier resolves (points) to a DID document, a set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.[1]

Just as there are many different types of URIs, all of which conform to the URI standard, there are many different types of DID methods, all of which must conform to the DID standard.[1] Each DID method specification must define:

A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. DIDs are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URIs that associate a DID subject with a DID document.[4] Each DID document can express cryptographic material, verification methods, and service endpoints to enable trusted interactions associated with the DID subject. A DID document might contain additional semantics about the subject that it identifies. A DID document might also contain the DID subject itself (e.g. a data model).[5][1] National efforts include the European Digital Identity (EUDI) Wallet as a part of eIDAS 2.0 in the European Union,[6] and China Real-Name Decentralized Identifier System (China RealDID) under China's Ministry of Public Security.[7]

Decentralized identifiers (DIDs) are a new type of identifier thatenables verifiable, decentralized digital identity. A DID refers to anysubject (e.g., a person, organization, thing, data model, abstract entity, etc.)as determined by the controller of the DID. In contrast totypical, federated identifiers, DIDs have been designed so that they maybe decoupled from centralized registries, identity providers, and certificateauthorities. Specifically, while other parties might be used to help enable thediscovery of information related to a DID, the design enables thecontroller of a DID to prove control over it without requiring permissionfrom any other party. DIDs are URIs that associate a DIDsubject with a DID document allowing trustable interactionsassociated with that subject.

Each DID document can express cryptographic material, verificationmethods, or services, which provide a set of mechanisms enabling aDID controller to prove control of the DID. Services enabletrusted interactions associated with the DID subject. A DID mightprovide the means to return the DID subject itself, if the DIDsubject is an information resource such as a data model.

This document specifies the DID syntax, a common data model, core properties,serialized representations, DID operations, and an explanation of the processof resolving DIDs to the resources that they represent.

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

At the time of publication, there existed103experimental DID Method specifications, 32 experimental DID Method driverimplementations, a test suite that determineswhether or not a given implementation is conformant with this specificationand 46 implementations submitted to the conformance test suite.Readers are advised to heed the DID Core issues and DID Core Test Suiteissues that each contain the latest list of concerns and proposed changesthat might result in alterations to this specification. At the time ofpublication, no additional substantive issues, changes, or modificationsare expected.

A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

As individuals and organizations, many of us use globally unique identifiers ina wide variety of contexts. They serve as communications addresses (telephonenumbers, email addresses, usernames on social media), ID numbers (for passports,drivers licenses, tax IDs, health insurance), and product identifiers (serialnumbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are used forresources on the Web and each web page you view in a browser has a globallyunique URL (Uniform Resource Locator).

The vast majority of these globally unique identifiers are not under ourcontrol. They are issued by external authorities that decide who or what theyrefer to and when they can be revoked. They are useful only in certain contextsand recognized only by certain bodies not of our choosing. They mightdisappear or cease to be valid with the failure of an organization. They mightunnecessarily reveal personal information. In many cases, they can befraudulently replicated and asserted by a malicious third-party, which ismore commonly known as "identity theft".

The Decentralized Identifiers (DIDs) defined in this specification are a newtype of globally unique identifier. They are designed to enable individuals andorganizations to generate their own identifiers using systems they trust. Thesenew identifiers enable entities to prove control over them by authenticatingusing cryptographic proofs such as digital signatures.

Since the generation and assertion of Decentralized Identifiers isentity-controlled, each entity can have as many DIDs as necessary to maintaintheir desired separation of identities, personas, and interactions. The use ofthese identifiers can be scoped appropriately to different contexts. Theysupport interactions with other people, institutions, or systems that requireentities to identify themselves, or things they control, while providing controlover how much personal or private data should be revealed, all without dependingon a central authority to guarantee the continued existence of the identifier.These ideas are explored in the DID Use Cases document [DID-USE-CASES].

This specification does not presuppose any particular technology or cryptographyto underpin the generation, persistence, resolution, or interpretation of DIDs.For example, implementers can create Decentralized Identifiers based onidentifiers registered in federated or centralized identity management systems.Indeed, almost all types of identifier systems can add support for DIDs. Thiscreates an interoperability bridge between the worlds of centralized, federated,and decentralized identifiers. This also enables implementers to design specifictypes of DIDs to work with the computing infrastructure they trust, such asdistributed ledgers, decentralized file systems, distributed databases, andpeer-to-peer networks.

Decentralized Identifiers are a component of larger systems, such as theVerifiable Credentials ecosystem [VC-DATA-MODEL], which influenced the designgoals for this specification. The design goals for Decentralized Identifiersare summarized here.

Six internally-labeled shapes appear in the diagram, with labeled arrowsbetween them, as follows. In the center of the diagram is a rectangle labeledDID URL, containing small typewritten text "did:example:123/path/to/rsrc". Atthe center top of the diagram is a rectangle labeled, "DID", containing smalltypewritten text "did:example:123". At the top left of the diagram is an oval,labeled "DID Subject". At the bottom center of the diagram is a rectanglelabeled, "DID document". At the bottom left is an oval, labeled, "DIDController". On the center right of the diagram is a two-dimensional renderingof a cylinder, labeled, "Verifiable Data Registry".

From the top of the "DID URL" rectangle, an arrow, labeled "contains", extendsupwards, pointing to the "DID" rectangle. From the bottom of the "DID URL"rectangle, an arrow, labeled "refers, anddereferences, to", extends downward, pointing to the"DID document" rectangle. An arrow from the "DID" rectangle, labeled"resolves to", points down to the "DID document"rectangle. An arrow from the "DID" rectangle, labeled "refers to", points leftto the "DID subject" oval. An arrow from the "DID controller" oval, labeled"controls", points right to the "DID document" rectangle. An arrow from the"DID" rectangle, labeled "recorded on", points downards to the right, to the"Verifiable Data Registry" cylinder. An arrow from the "DID document" rectangle,labeled "recorded on", points upwards to the right to the "Verifiable DataRegistry" cylinder.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document contains examples that contain JSON and JSON-LD content.Some of these examples contain characters that are invalid, such as inlinecomments (//) and the use of ellipsis (...) to denoteinformation that adds little value to the example. Implementers are cautioned toremove this content if they desire to use the information as valid JSONor JSON-LD.

Some examples contain terms, both property names and values, that are notdefined in this specification. These are indicated with a comment (//external (property namevalue)). Such terms, when used in a DIDdocument, are expected to be registered in the DID Specification Registries[DID-SPEC-REGISTRIES] with links to both a formal definition and a JSON-LDcontext.