Decentralized identifiers (DIDs) are a new type of identifier that
enables verifiable, decentralized digital identity. A DID refers to any
subject (e.g., a person, organization, thing, data model, abstract entity, etc.)
as determined by the controller of the DID. In contrast to
typical, federated identifiers, DIDs have been designed so that they may
be decoupled from centralized registries, identity providers, and certificate
authorities. Specifically, while other parties might be used to help enable the
discovery of information related to a DID, the design enables the
controller of a DID to prove control over it without requiring permission
from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions
associated with that subject.
This document specifies the DID syntax, a common data model, core properties,
serialized representations, DID operations, and an explanation of the process
of resolving DIDs to the resources that they represent.
Status of This Document
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 standards and drafts index at
https://www.w3.org/TR/.
This version of the DID Core specification, version 1.1, is experimental.
DO NOT implement it. If you want to implement DIDs, use the current version 1.0
specification: Decentralized Identifiers (DIDs) v1.0.
Publication as a Working Draft does not
imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
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 in
a wide variety of contexts. They serve as communications addresses (telephone
numbers, email addresses, usernames on social media), ID numbers (for passports,
drivers licenses, tax IDs, health insurance), and product identifiers (serial
numbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are used for
resources on the Web and each web page you view in a browser has a globally
unique URL (Uniform Resource Locator).
The vast majority of these globally unique identifiers are not under our
control. They are issued by external authorities that decide who or what they
refer to and when they can be revoked. They are useful only in certain contexts
and recognized only by certain bodies not of our choosing. They might
disappear or cease to be valid with the failure of an organization. They might
unnecessarily reveal personal information. In many cases, they can be
fraudulently replicated and asserted by a malicious third-party, which is
more commonly known as "identity theft".
The Decentralized Identifiers (DIDs) defined in this specification are a new
type of globally unique identifier. They are designed to enable individuals and
organizations to generate their own identifiers using systems they trust. These
new identifiers enable entities to prove control over them by authenticating
using cryptographic proofs such as digital signatures.
Since the generation and assertion of Decentralized Identifiers is
entity-controlled, each entity can have as many DIDs as necessary to maintain
their desired separation of identities, personas, and interactions. The use of
these identifiers can be scoped appropriately to different contexts. They
support interactions with other people, institutions, or systems that require
entities to identify themselves, or things they control, while providing control
over how much personal or private data should be revealed, all without depending
on 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 cryptography
to underpin the generation, persistence, resolution, or interpretation of DIDs.
For example, implementers can create Decentralized Identifiers based on
identifiers registered in federated or centralized identity management systems.
Indeed, almost all types of identifier systems can add support for DIDs. This
creates an interoperability bridge between the worlds of centralized, federated,
and decentralized identifiers. This also enables implementers to design specific
types of DIDs to work with the computing infrastructure they trust, such as
distributed ledgers, decentralized file systems, distributed databases, and
peer-to-peer networks.
This specification is for:
Anyone that wants to understand the core architectural principles that
are the foundation for Decentralized Identifiers;
Software developers that want to produce and consume Decentralized Identifiers
and their associated data formats;
Systems integrators that want to understand how to use Decentralized
Identifiers in their software and hardware systems;
Specification authors that want to create new DID infrastructures, known as DID
methods, that conform to the ecosystem described by this document.
In addition to this specification, readers might find the
Use Cases and Requirements for Decentralized Identifiers [DID-USE-CASES]
document useful.
1.1 A Simple Example
This section is non-normative.
A DID is a simple text string consisting of three parts: 1) the
did URI scheme identifier, 2) the identifier for the DID method, and 3) the DID method-specific identifier.
Figure 1
A simple example of a decentralized identifier (DID)
{
"@context": "https://www.w3.org/ns/did/v1.1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Multikey",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}
1.2 Design Goals
This section is non-normative.
Decentralized Identifiers are a component of larger systems, such as the
Verifiable Credentials ecosystem [VC-DATA-MODEL], which influenced the design
goals for this specification. The design goals for Decentralized Identifiers
are summarized here.
Goal
Description
Decentralization
Eliminate the requirement for centralized authorities or single points of
failure in identifier management, including the registration of globally unique
identifiers, public verification keys, services, and other information.
Control
Give entities, both human and non-human, 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.
1.3
Architecture Overview
This section is non-normative.
This section provides a basic overview of the major components of
Decentralized Identifier architecture.
Figure 2
Overview of DID architecture and the relationship of the basic components.
See also: narrative description.
Six internally-labeled shapes appear in the diagram, with labeled arrows
between them, as follows. In the center of the diagram is a rectangle labeled
DID URL, containing small typewritten text "did:example:123/path/to/rsrc". At
the center top of the diagram is a rectangle labeled, "DID", containing small
typewritten 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 rectangle
labeled, "DID document". At the bottom left is an oval, labeled, "DID
Controller". On the center right of the diagram is a two-dimensional rendering
of a cylinder, labeled, "Verifiable Data Registry".
From the top of the "DID URL" rectangle, an arrow, labeled "contains", extends
upwards, pointing to the "DID" rectangle. From the bottom of the "DID URL"
rectangle, an arrow, labeled "refers, and
dereferences, 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 left
to 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 Data
Registry" cylinder.
DIDs and DID URLs
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.
These concepts are elaborated upon in 3.1 DID Syntax and
3.2 DID URL Syntax.
DID subjects
The subject of a DID is, by definition, the entity identified by the
DID. The DID subject might also be the DID controller.
Anything can be the subject of a DID: person, group, organization,
thing, or concept. This is further defined in 5.1.1 DID Subject.
DID controllers
The controller of a DID is the entity (person, organization, or
autonomous software) that has the capability—as defined by a DID method—to make changes to a DID document. This capability is
typically asserted by the control of a set of cryptographic keys used by
software acting on behalf of the controller, though it might also be asserted
via other mechanisms. Note that a DID might have more than one
controller, and the DID subject can be the DID controller, or one
of them. This concept is documented in 5.1.2 DID Controller.
Verifiable data registries
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 distributed ledgers,
decentralized file systems, databases of any kind, peer-to-peer networks, and
other forms of trusted data storage. This concept is further elaborated upon in
7. Methods.
DID methods are the mechanism by which a particular type of DID
and its associated DID document are created, resolved, updated, and
deactivated. DID methods are defined using separate DID method
specifications as defined in 7. Methods.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, RECOMMENDED, 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 inline
comments (//) and the use of ellipsis (...) to denote
information that adds little value to the example. Implementers are cautioned to
remove this content if they desire to use the information as valid JSON
or JSON-LD.
Some examples contain terms, both property names and values, that are not
defined in this specification. These are indicated with a comment (//
external (property name|value)). Such terms, when used in a DID document, are expected to be registered in the repository of DID Extensions
[DID-EXTENSIONS] with links to both a formal definition and a JSON-LD
context.
Interoperability of implementations for DIDs and DID documents is
tested by evaluating an implementation's ability to create and parse DIDs
and DID documents that conform to this specification. Interoperability
for producers and consumers of DIDs and DID documents is provided
by ensuring the DIDs and DID documents conform. Interoperability
for DID method specifications is provided by the details in each DID method specification. It is understood that, in the same way that a web
browser is not required to implement all known URI schemes, conformant
software that works with DIDs is not required to implement all known
DID methods. However, all implementations of a given DID method
are expected to be interoperable for that method.
A conforming DID is any concrete expression of the rules specified in
3. Identifier which complies with relevant normative statements in
that section.
A conforming DID document is any concrete expression
of the data model described in this specification which complies with the
relevant normative statements in 4. Data Model and 5. Core Properties. A
serialization format for the conforming document is deterministic,
bi-directional, and lossless, as described in 6. Representations.
A conforming DID method is any specification that
complies with the relevant normative statements in 7. Methods.
1.5
Audience
This section is non-normative.
This specification has two primary audiences: implementers of conformant DID methods; and implementers of systems and services that wish to interact and interface with DIDs. The intended audience includes, but is not limited to, software architects, data modelers, application developers, service developers, testers, operators, and user experience (UX) specialists. Other people involved in a broad range of standards efforts related to decentralized identity, verifiable credentials, and secure storage might also be interested in reading this specification.
2. Terminology
This section is non-normative.
This section defines the terms used in this specification and throughout
decentralized identifier infrastructure. A link to these terms is
included whenever they appear in this specification.
amplification attack
A class of attack where the attacker attempts to exhaust a target system's
CPU, storage, network, or other resources by providing small, valid inputs into
the system that result in damaging effects that can be exponentially more costly
to process than the inputs themselves.
decentralized identifier (DID)
A globally unique persistent identifier that does not require a centralized
registration authority and is often generated and/or registered
cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID
method specification. Many—but not all—DID methods make use of
distributed ledger technology (DLT) or some other form of decentralized
network.
DID controller
An entity that has the capability to make changes to a DID document. A
DID might have more than one DID controller. The DID controller(s)
can be denoted by the optional controller property at the top level of the
DID document. Note that a DID controller might be the DID
subject.
DID delegate
An entity to whom a DID controller has granted permission to use a
verification method associated with a DID via a DID document. For
example, a parent who controls a child's DID document might permit the child
to use their personal device in order to authenticate. In
this case, the child is the DID delegate. The child's personal device would
contain the private cryptographic material enabling the child to
authenticate using the DID. However, the child might not
be permitted to add other personal devices without the parent's permission.
The portion of a DID URL that follows the first hash sign character
(#). DID fragment syntax is identical to URI fragment syntax.
DID method
A definition of how a specific DID method scheme is implemented. A DID method is
defined by a DID method specification, which specifies the precise operations by
which DIDs and DID documents are created, resolved, updated,
and deactivated. See 7. Methods.
DID path
The portion of a DID URL that begins with and includes the first forward
slash (/) character and ends with either a question mark
(?) character, a fragment hash sign (#) character,
or the end of the DID URL. DID path syntax is identical to URI path syntax.
See Path.
DID query
The portion of a DID URL that follows and includes the first question
mark character (?). DID query syntax is identical to URI query
syntax. See Query.
DID resolution
The process that takes as its input a DID and a set of resolution
options and returns a DID document in a conforming representation
plus additional metadata. This process relies on the "Read" operation of the
applicable DID method. The inputs and outputs of this process are
defined in [DID-RESOLUTION].
DID resolver
A DID resolver is a software and/or hardware component that performs the
DID resolution function by taking a DID as input and producing a
conforming DID document as output.
DID scheme
The formal syntax of a decentralized identifier. The generic DID scheme
begins with the prefix did: as defined in 3.1 DID Syntax. Each DID method specification defines a specific
DID method scheme that works with that specific DID method. In a specific DID
method scheme, the DID method name follows the first colon and terminates with
the second colon, e.g., did:example:
DID subject
The entity identified by a DID and described by a DID document.
Anything can be a DID subject: person, group, organization, physical thing,
digital thing, logical thing, etc.
DID URL
A DID plus any additional syntactic component that conforms to the
definition in 3.2 DID URL Syntax. This includes an optional DID
path (with its leading / character), optional DID query
(with its leading ? character), and optional DID fragment
(with its leading # character).
DID URL dereferencing
The process that takes as its input a DID URL and a set of input
metadata, and returns a resource. This resource might be a DID
document plus additional metadata, a secondary resource
contained within the DID document, or a resource entirely
external to the DID document. The process uses DID resolution to
fetch a DID document indicated by the DID contained within the
DID URL. The dereferencing process can then perform additional processing
on the DID document to return the dereferenced resource indicated by the
DID URL. The inputs and outputs of this process are defined in
[DID-RESOLUTION].
A non-centralized system for recording events. These systems establish
sufficient confidence for participants to rely upon the data recorded by others
to make operational decisions. They typically use distributed databases where
different nodes use a consensus protocol to confirm the ordering of
cryptographically signed transactions. The linking of digitally signed
transactions over time often makes the history of the ledger effectively
immutable.
resource
A thing that is identified by a URI, as defined in [RFC3986]. Similarly,
any resource might serve as a DID subject identified by a DID.
representation
A concrete expression of a resource, as defined by [RFC7231]: "information
that is intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the protocol, and
that consists of a set of representation metadata and a potentially unbounded
stream of representation data." A DID document is a representation of
information describing a DID subject. See 6. Representations.
A means of communicating or interacting with the DID subject or
associated entities via one or more service endpoints.
Examples include discovery services, agent services, social networking
services, file storage services, and verifiable credential repository services.
service endpoint
A network address, such as an HTTP URL, at which services operate on
behalf of a DID subject.
Uniform Resource Identifier (URI)
The standard identifier format for all resources on the World Wide Web as
defined by [RFC3986]. A DID is a type of URI scheme.
verifiable data registry
A system that facilitates the creation, verification, updating, and/or
deactivation of decentralized identifiers and DID documents. A
verifiable data registry might also be used for other
cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials
specification [VC-DATA-MODEL].
verifiable timestamp
A verifiable timestamp enables a third-party to verify that a data object
existed at a specific moment in time and that it has not been modified or
corrupted since that moment in time. If the data integrity could reasonably have
been modified or corrupted since that moment in time, the timestamp is not
verifiable.
In addition to the terminology above, this specification also uses terminology
from the [INFRA] specification to formally define the data model. When [INFRA] terminology is used, such as
string, set, and map, it is linked directly to that specification.
3. Identifier
This section describes the formal syntax for DIDs and DID URLs.
The term "generic" is used to differentiate the syntax defined here from syntax
defined by specificDID methods in their respective
specifications. The creation processes, and their timing, for DIDs and
DID URLs are described in 7.2 Method Operations and
B.2 Creation of a DID.
3.1 DID Syntax
The generic DID scheme is a URI scheme conformant with
[RFC3986]. The ABNF definition can be found below, which uses the syntax in
[RFC5234] and the corresponding definitions for ALPHA and
DIGIT. All other rule names not defined in the ABNF below are
defined in [RFC3986]. All DIDsMUST conform to the
DID Syntax ABNF Rules.
did-url = did path-abempty [ "?" query ] [ "#" fragment ]
Note: Semicolon character is reserved for future use
Although the semicolon (;) character can be used according to the
rules of the DID URL syntax, future versions of this specification may
use it as a sub-delimiter for parameters as described in [MATRIX-URIS]. To
avoid future conflicts, developers ought to refrain from using it.
Path
A DID path is identical to a generic URI path and conforms to the
path-abempty ABNF rule in RFC 3986, section 3.3. As with
URIs, path semantics can be specified by DID Methods, which in
turn might enable DID controllers to further specialize those semantics.
A DID fragment is used as a method-independent reference into a DID document or external resource. Some examples of DID fragment
identifiers are shown below.
Example 4: A unique verification method in a DID Document
In order to maximize interoperability, implementers are urged to ensure that
DID fragments are interpreted in the same way across
representations (see 6. Representations). For example, while
JSON Pointer [RFC6901] can be used in a DID fragment, it will not be
interpreted in the same way across non-JSON representations.
Additional semantics for fragment identifiers, which are compatible with and
layered upon the semantics in this section, are described for JSON-LD
representations in E.1 application/did. For information
about how to dereference a DID fragment, see [DID-RESOLUTION].
3.2.1 Relative DID URLs
A relative DID URL is any URL value in a DID document that does
not start with did:<method-name>:<method-specific-id>. More
specifically, it is any URL value that does not start with the ABNF defined in
3.1 DID Syntax. The URL is expected to reference
a resource in the same DID document. Relative DID URLsMAY
contain relative path components, query parameters, and fragment identifiers.
When resolving a relative DID URL reference, the algorithm specified in
RFC3986 Section 5: Reference ResolutionMUST be used. The base URI value is the DID that is
associated with the DID subject, see 5.1.1 DID Subject. The
scheme is did. The authority is a
combination of <method-name>:<method-specific-id>, and the
path, query, and fragment
values are those defined in Path, Query, and Fragment,
respectively.
{
"@context": "https://www.w3.org/ns/did/v1.1",
"id": "did:example:123456789abcdefghi",
"verificationMethod": [{
"id": "did:example:123456789abcdefghi#key-1",
"type": "Multikey", // external (property value)
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}, ...],
"authentication": [
// a relative DID URL used to reference a verification method above
"#key-1"
]
}
In the example above, the relative DID URL value will be transformed to
an absolute DID URL value of
did:example:123456789abcdefghi#key-1.
4. Data Model
This specification defines a data model that can be used to express DID documents and DID document data structures, which can then be serialized
into multiple concrete representations. This section provides a
high-level description of the data model, descriptions of the ways different
types of properties are expressed in the data model, and instructions for
extending the data model.
The diagram is titled, "Entries in the DID Document map". A dotted grey line
runs horizontally through the center of the diagram. The space above the line
is labeled "Properties", and the space below it, "Representation-specific
entries". Six labeled rectangles appear in the diagram, three lying above the
dotted grey line and three below it. A large green rectangle, labeled "DID
Extensions", encloses the four leftmost rectangles (upper left,
upper center, lower left, and lower center). The two leftmost rectangles
(upper left and lower left) are outlined in blue and labeled in blue, as
follows. The upper left rectangle is labeled "Core Properties", and contains
text "id, alsoKnownAs, controller, authentication, verificationMethod, service,
serviceEndpoint, ...". The lower left rectangle is labeled "Core
Representation-specific Entries", and contains text "@context". The four
rightmost rectangles (upper center, upper right, lower center, and lower right)
are outlined in grey and labeled in black, as follows. The upper center
rectangle is labeled, "Property Extensions", and contains text
"ethereumAddress". The lower center rectangle is labeled,
"Representation-specific Entry Extensions", and contains no other text. The
upper right rectangle is labeled, "Unregistered Property Extensions", and
contains text "foo". The lower right rectangle is labeled "Unregistered
Representation-specific Entry Extensions", and contains text "%YAML, xmlns".
All entry keys in the DID document data model are strings. All entry values are expressed using one
of the abstract data types in the table below, and each representation
specifies the concrete serialization format of each data type.
A finite ordered sequence of key/value pairs, with no key appearing twice as
specified in [INFRA]. A map is sometimes referred to as an
ordered map in [INFRA].
A finite ordered sequence of items that does not contain the same item twice
as specified in [INFRA]. A set is sometimes referred to as an
ordered set in [INFRA].
datetime
A date and time value that is capable of losslessly expressing all values
expressible by a dateTime as specified in
[XMLSCHEMA11-2].
A sequence of code units often used to represent human readable language
as specified in [INFRA].
integer
A real number without a fractional component as specified in
[XMLSCHEMA11-2]. To maximize
interoperability, implementers are urged to heed the advice regarding
integers in RFC8259, Section 6: Numbers.
double
A value that is often used to approximate arbitrary real numbers as specified
in [XMLSCHEMA11-2]. To maximize
interoperability, implementers are urged to heed the advice regarding
doubles in RFC8259, Section 6: Numbers.
A value that is used to indicate the lack of a value as defined in [INFRA].
As a result of the data model being defined using
terminology from [INFRA], property values which can contain more than one
item, such as lists, maps and sets, are explicitly ordered. All list-like
value structures in [INFRA] are ordered, whether or not that order is
significant. For the purposes of this specification, unless otherwise stated, map and set ordering is not important and
implementations are not expected to produce or consume deterministically ordered
values.
4.1 Extensibility
The data model supports two types of extensibility.
For maximum interoperability, it is RECOMMENDED that extensions use the
repository of DID Extensions [DID-EXTENSIONS]. The use of
this mechanism for new properties or other extensions is the only specified
mechanism that ensures that two different representations will be able to
work together.
RepresentationsMAY define other extensibility mechanisms, including ones
that do not require the use of the DID Extensions. Such extension
mechanisms SHOULD support lossless conversion into any other conformant
representation. Extension mechanisms for a representationSHOULD
define a mapping of all properties and representation syntax into the data model and its type system.
Note: Unregistered extensions are less reliable
It is always possible for two specific implementations to agree out-of-band to
use a mutually understood extension or representation that is not
recorded in the repository of DID Extensions [DID-EXTENSIONS];
interoperability between such implementations and the larger ecosystem will be
less reliable.
The following tables contain informative references for the core properties
defined by this specification, with expected values, and whether or not they are
required. The property names in the tables are linked to the normative
definitions and more detailed descriptions of each property.
Note: Property names used in maps of different types
The property names id, type, and
controller can be present in maps of different types
with possible differences in constraints. For example, an id
at the top-level of a DID document is required to be a DID, while an
id in a servicemap can be a URL.
DID method specifications can create intermediate representations of a
DID document that do not contain the id property,
such as when a DID resolver is performing DID resolution.
However, the fully resolved DID document always contains a valid
id property.
Identifiers used in a DID document to identify a DID subject or a DID Controller cannot use query parameters or fragment identifiers.
Implementers are urged to pay particular attention to the list of allowable
characters in Section 3.1 DID Syntax which makes this requirement clear; the
syntax does not include the ? character nor the # character. This is in
contrast to identifiers used in a DID document to identify a verification method or a service, which follow the syntax rules in Section
3.2 DID URL Syntax, which do allow the use of query parameters and fragment
identifiers. Even so, the use of query parameters in long-lived canonical
identifiers made for DID ecosystems is discouraged as it can increase the
complexity of DID resolution software and potentially lead to a larger
security attack surface. Fragment identifiers are also expected to be unique
within a particular DID document and implementers are discouraged from
reusing them to refer to different resources over time, such as two
different verification methods within the same DID document.
A concrete serialization of a DID document in this specification is
called a representation. A representation is created by
serializing the data model through a process called
production. A representation is transformed into the data model through a process called
consumption. The production and consumption
processes enable the conversion of information from one representation to
another. This specification defines representations for JSON and JSON-LD,
and developers can use any other representation, such as XML or
YAML, that is capable of expressing the data model.
The following sections define the general rules for production and
consumption, as well as the JSON and JSON-LD representations.
6.1 Production and Consumption
In addition to the representations defined in this specification,
implementers can use other representations, providing each such
representation is properly specified (including rules for
interoperable handling of properties not listed in the repository of
DID Extensions [DID-EXTENSIONS]). See 4.1 Extensibility
for more information.
A representationMUST define deterministic production and consumption
rules for all data types specified in 4. Data Model.
A representationMUST be uniquely associated with an IANA-registered
Media Type.
A representationMUST define fragment processing rules for its Media
Type that are conformant with the fragment processing rules defined in
Fragment.
A representationSHOULD use the lexical representation of data model data types. For example, JSON and JSON-LD use
the XML Schema dateTime lexical serialization to represent
datetimes. A representationMAY choose to serialize the data model data types using a different lexical
serializations as long as the consumption process back into the data model is lossless. For example, some CBOR-based
representations express datetime values using integers to
represent the number of seconds since the Unix epoch.
The upper left quadrant of the diagram contains a rectangle with dashed grey
outline, containing two blue-outlined rectangles, one above the other.
The upper, larger rectangle is labeled, in blue, "Core Properties",
and contains the following INFRA notation:
The lower, smaller rectangle is labeled, in blue, "Core Representation-specific
Entries (JSON-LD)", and contains the following monospaced INFRA notation:
From the grey-outlined rectangle, three pairs of arrows extend to three
different black-outlined rectangles, one on the upper right of the diagram, one
in the lower right, and one in the lower left. Each pair of arrows consists of
one blue arrow pointing from the grey-outlined rectangle to the respective
black-outlined rectangle, labeled "produce", and one red arrow pointing in the
reverse direction, labeled "consume". The black-outlined rectangle in the upper
right is labeled "application/did+cbor", and contains hexadecimal data. The
rectangle in the lower right is labeled "application/did+json", and contains
the following JSON data:
An implementation is expected to convert between representations by using
the consumption rules on the source representation resulting in the data model and then using the production rules
to serialize data model to the target representation,
or any other mechanism that results in the same target representation.
A JSON Object, where each entry is
serialized as a member of the JSON Object with the entry key as a JSON String member name and the entry value
according to its type, as defined in this table.
All entries of a DID documentMUST be included in the root JSON Object. Entries MAY contain additional
data substructures subject to the value representation rules in the list above.
When serializing a DID document, a conforming producerMUST
specify a media type of application/did+json to downstream
applications.
Example 10: Example DID document in JSON representation
A map, where each member of the JSON
Object is added as an entry to the map. Each entry key is set as the
JSON Object member name. Each entry value is set by converting the JSON Object
member value according to the JSON representation type as defined in this table.
Since order is not specified by JSON Objects, no insertion order is guaranteed.
A list, where each value of the JSON Array is
added to the list in order, converted based on the JSON representation type of
the array value, as defined in this table.
A set, where each value of
the JSON Array is added to the set in order, converted based on the JSON
representation type of the array value, as defined in this table.
All implementers creating conforming producers that produce JSON-LD
representations are advised to ensure that their algorithms
produce valid JSON-LD [JSON-LD11] documents. Invalid JSON-LD documents will
cause JSON-LD processors to halt and report errors.
In order to achieve interoperability across different representations,
all JSON-LD Contexts and their terms SHOULD be registered in the repository of
DID Extensions [DID-EXTENSIONS].
All implementers creating conforming consumers that consume JSON-LD
representations are advised to ensure that their algorithms only accept
valid JSON-LD [JSON-LD11] documents. Invalid JSON-LD documents will cause
JSON-LD processors to halt and report errors.
Media types, as defined in [RFC6838], identify the syntax used to express a
DID document as well as other useful processing guidelines.
Syntaxes used to express the data model in this specification SHOULD be
identified by a media type, and conventions outlined in this section SHOULD be
followed when defining or using media types with DID documents.
There is one media type associated with the core data model, which is
listed in Section E. IANA Considerations:
application/did.
6.4.1 Media Type Precision
This section is non-normative.
At times, developers or systems might use lower-precision media types to convey
DID documents. Some of the reasons for use of lower-precision media types
include:
A web server defaults to text/plain or application/octet-stream when a file
extension is not available and it cannot determine the media type.
A developer adds a file extension that leads to a media type that is less
specific than the content of the file. For example, .json could result in a
media type of application/json and .jsonld might result in a media type of
application/ld+json.
A protocol requires a less precise media type for a particular transaction; for
example, application/json instead of application/did,
Implementers are discouraged from raising errors when it is possible to determine
the intended media type from the payload, provided that the media type used is
acceptable in the given protocol. For example, if an application only accepts
payloads that conform to the rules associated with the application/did media
type, but the payload is tagged with the lower-precision application/json or
application/ld+json, the application might perform the following steps to
determine whether the payload also conforms to the higher-precision media type:
Parse the payload as a JSON document.
Ensure that the first element of the @context property matches
https://www.w3.org/ns/did/v1.1.
Assume an application/did media type if the JSON document contains a top-level
id property containing an identifier that conforms to the rules in Section
3.1 DID Syntax.
Whenever possible, implementers are advised to use the most precise (the highest-
precision) media type for all payloads defined by this specification.
Implementers are also advised to recognize that a payload tagged with a lower-
precision media type does not mean that the payload does not meet the rules
necessary to tag it with a higher-precision type. Similarly, a payload tagged
with a higher-precision media type does not mean that the payload will meet the
requirements associated with the media type. Receivers of payloads, regardless
of their associated media type, are expected to perform appropriate checks to
ensure that payloads conform with the requirements for their use in a given
system.
HTTP clients and servers use media types associated with DID documents in
Accept: headers and when indicating content types. Implementers are warned that
HTTP servers might ignore the Accept: header and return another content type, or
return an error code such as 415
Unsupported Media Type.
7. Methods
A conforming DID method defines how implementers can realize the features
described by this specification. DID methods are often associated with a
particular verifiable data registry. New DID methods are defined in
their own specifications to enable interoperability between different
implementations of the same DID method.
Conceptually, the relationship between this specification and a DID method specification is similar to the relationship between the IETF generic
URI specification [RFC3986] and a specific URI scheme
[IANA-URI-SCHEMES], such as the http scheme [RFC7230]. In
addition to defining a specific DID scheme, a DID method
specification also defines the mechanisms for creating, resolving, updating, and
deactivating DIDs and DID documents using a specific type of
verifiable data registry. It also documents all implementation
considerations related to DIDs as well as Security and Privacy
Considerations.
This section specifies the requirements for authoring DID method
specifications.
7.1 Method Syntax
The requirements for all DID method specifications when defining the
method-specific DID Syntax are as follows:
A DID method specification MUST define exactly one method-specific DID scheme that is identified by exactly one method name as specified by the
method-name rule in 3.1 DID Syntax.
The DID method specification MUST specify how to generate the
method-specific-id component of a DID.
The DID method specification MUST define sensitivity and normalization of
the value of the method-specific-id.
The method-specific-id value MUST be unique within a DID method. The method-specific-id value itself might be globally
unique.
Any DID generated by a DID methodMUST be globally unique.
To reduce the chances of method-name conflicts, a DID method
specification SHOULD be registered in the repository of DID Extensions
[DID-EXTENSIONS].
A DID methodMAY define multiple method-specific-id formats.
The method-specific-id format MAY include colons. The use of
colons MUST comply syntactically with the method-specific-id ABNF
rule.
A DID method specification MAY specify ABNF rules for DID paths
that are more restrictive than the generic rules in Path.
A DID method specification MAY specify ABNF rules for DID queries
that are more restrictive than the generic rules in this section.
A DID method specification MAY specify ABNF rules for DID fragments that are more restrictive than the generic rules in this section.
Note: Colons in method-specific-id
The meaning of colons in the method-specific-id is entirely
method-specific. Colons might be used by DID methods for establishing
hierarchically partitioned namespaces, for identifying specific instances or
parts of the verifiable data registry, or for other purposes.
Implementers are advised to avoid assuming any meanings or
behaviors associated with a colon that are generically applicable to all
DID methods.
7.2 Method Operations
The requirements for all DID method specifications when defining the
method operations are as follows:
A DID method specification MUST define how authorization is performed to
execute all operations, including any necessary cryptographic processes.
The Security Considerations section MUST document the following forms of attack
for the DID operations defined in the DID method specification:
eavesdropping, replay, message insertion, deletion, modification, denial of
service, amplification, and man-in-the-middle. Other known
forms of attack SHOULD also be documented.
The Security Considerations section MUST discuss residual risks, such as the
risks from compromise in a related protocol, incorrect implementation, or cipher
after threat mitigation was deployed.
The Security Considerations section MUST provide integrity protection and update
authentication for all operations required by Section 7.2 Method Operations.
If authentication is involved, particularly user-host authentication, the
security characteristics of the authentication method MUST be clearly
documented.
The Security Considerations section MUST discuss the policy mechanism by which
DIDs are proven to be uniquely assigned.
Method-specific endpoint authentication MUST be discussed. Where DID methods make use of DLTs with varying network topology, sometimes
offered as light node or thin client
implementations to reduce required computing resources, the security assumptions
of the topology available to implementations of the DID methodMUST be
discussed.
If a protocol incorporates cryptographic protection mechanisms, the DID method specification MUST clearly indicate which portions of the data are
protected and by what protections, and it SHOULD give an indication of the
sorts of attacks to which the cryptographic protection is susceptible. Some
examples are integrity only, confidentiality, and endpoint authentication.
Data which is to be held secret (keying material, random seeds, and so on)
SHOULD be clearly labeled.
DID method specifications SHOULD explain and specify the implementation
of signatures on DID documents, if applicable.
Where DID methods use peer-to-peer computing resources, such as with all
known DLTs, the expected burdens of those resources SHOULD be discussed
in relation to denial of service.
DID methods that introduce new authentication service
types, as described in 5.4 Services, SHOULD consider the
security requirements of the supported authentication protocol.
7.4 Privacy Requirements
The requirements for all DID method specifications when authoring the
Privacy Considerations section are:
The DID method specification's Privacy Considerations section MUST
discuss any subsection of Section 5 of [RFC6973] that could apply in a
method-specific manner. The subsections to consider are: surveillance, stored
data compromise, unsolicited traffic, misattribution, correlation,
identification, secondary use, disclosure, and exclusion.
8. Security Considerations
This section is non-normative.
This section contains a variety of security considerations that people using
Decentralized Identifiers are advised to consider before deploying this
technology in a production setting. Readers are urged to read the
Security Considerations section
of the Controlled Identifiers v1.0 specification before reading
this section. DIDs are designed to operate under
the threat model used by many IETF standards and documented
in [RFC3552]. This section elaborates upon a number of the considerations
in [RFC3552], as well as other considerations that are unique to DID
architecture.
8.1 Choosing DID Resolvers
The repository of DID Extensions [DID-EXTENSIONS] contains an
informative list of DID method names and their corresponding DID method specifications. Implementers need to bear in mind that there is no
central authority to mandate which DID method specification is to be used
with any specific DID method name. If there is doubt on whether or not a
specific DID resolver implements a DID method correctly, the DID
Specification Registries can be used to look up the registered specification
and make an informed decision regarding which DID resolver
implementation to use.
8.2 Non-Repudiation
Non-repudiation of DIDs and DID document updates is supported if:
The subject has had adequate opportunity to revert malicious updates according
to the authorization mechanism for the DID method.
8.3 Notification of DID Document Changes
One mitigation against unauthorized changes to a DID document is
monitoring and actively notifying the DID subject when there are changes.
This is analogous to helping prevent account takeover on conventional
username/password accounts by sending password reset notifications to the email
addresses on file.
In the case of a DID, there is no intermediary registrar or account
provider to generate such notifications. However, if the verifiable data registry on which the DID is registered directly supports change
notifications, a subscription service can be offered to DID controllers.
Notifications could be sent directly to the relevant service endpoints
listed in an existing DID.
If a DID controller chooses to rely on a third-party monitoring service
(other than the verifiable data registry itself), this introduces another
vector of attack.
8.4 Revocation in Trustless Systems
Trustless systems are those where all trust is derived from cryptographically
provable assertions, and more specifically, where no metadata outside of the
cryptographic system is factored into the determination of trust in the system.
To verify a signature of proof for a verification method which has been
revoked in a trustless system, a DID method needs to support either or
both of the versionId or versionTime, as well as both the updated and
nextUpdate, DID document metadata properties. A verifier can validate a
signature or proof of a revoked key if and only if all of the following are
true:
The proof or signature includes the versionId or versionTime of the DID document that was used at the point in time at which the signature or
proof was made.
The verifier can determine the point in time at which the signature or proof was
made; for example, it was anchored on a blockchain.
In the resolved DID document metadata, the updated timestamp is
before, and the nextUpdate timestamp is after, the point in time at which the
signature or proof was made.
Similar trust may be achieved in systems that are willing to accept metadata
beyond that which constitutes cryptographic input -- but this always requires
a careful judgment about whether a DID document's content included the
expected content at the moment of a signing event.
8.5 DID Recovery
Recovery is a reactive security measure whereby a controller that has
lost the ability to perform DID operations, such as through the loss of a
device, is able to regain the ability to perform DID operations.
The following considerations might be of use when contemplating the use of
DID recovery:
Proactively performing recovery, on an infrequent but regular basis, can help to
prevent loss of control.
It is considered a best practice to never reuse cryptographic material
associated with recovery for any other purposes.
Recovery is advised when a controller or any service trusted to act on
their behalf no longer has the exclusive ability to perform DID operations as
described in 7.2 Method Operations.
DID method specifications might choose to enable support for a quorum of
trusted parties to facilitate recovery. Some of the facilities to do so are
suggested in 5.1.2 DID Controller.
Not all DID method specifications will recognize control from DIDs
registered using other DID methods and they might restrict third-party
control to DIDs that use the same method.
Access control and recovery in a DID method specification can also
include a time lock feature to protect against key compromise by maintaining a
second track of control for recovery.
There are currently no common recovery mechanisms that apply to all
DID methods.
8.6 The Role of Human-Friendly Identifiers
DIDs achieve global uniqueness without the need for a central
registration authority. This comes at the cost of human memorability.
Algorithms capable of generating globally unambiguous identifiers
produce random strings of characters that have no human meaning. This
trade-off is often referred to as
Zooko's
Triangle.
There are use cases where it is desirable to discover a DID when
starting from a human-friendly identifier. For example, a natural language
name, a domain name, or a conventional address for a DID controller,
such as a mobile telephone number, email address, social media username, or
blog URL. However, the problem of mapping human-friendly identifiers to
DIDs, and doing so in a way that can be verified and trusted, is
outside the scope of this specification.
Solutions to this problem are defined in separate specifications, such as
[DNS-DID], that reference this specification. It is strongly recommended that
such specifications carefully consider the:
Numerous security attacks based on deceiving users about the true human-friendly
identifier for a target entity.
Privacy consequences of using human-friendly identifiers that are inherently
correlatable, especially if they are globally unique.
8.7 DIDs as Enhanced URNs
If desired by a DID controller, a DID or a DID URL is
capable of acting as persistent, location-independent resource identifier.
These sorts of identifiers
are classified as Uniform Resource Names (URNs) and are defined in [RFC8141].
DIDs are an enhanced form of URN that provide a
cryptographically secure, location-independent identifier for a digital
resource, while also providing metadata that enables retrieval. Due to the
indirection between the DID document and the DID itself, the
DID controller can adjust the actual location of the resource — or
even provide the resource directly — without adjusting the DID.
DIDs of this type can definitively verify that the resource retrieved is,
in fact, the resource identified.
A DID controller who intends to use a DID for this purpose is
advised to follow the security considerations in [RFC8141]. In particular:
The DID controller is expected to choose a DID method that
supports the controller's requirements for persistence. The Decentralized
Characteristics Rubric [DID-RUBRIC] is one tool available to help
implementers decide upon the most suitable DID method.
The DID controller is expected to publish its operational policies so
requesting parties can determine the degree to which they can rely on the
persistence of a DID controlled by that DID controller. In the
absence of such policies, requesting parties are not expected to make any
assumption about whether a DID is a persistent identifier for the same
DID subject.
8.8 Immutability
Many cybersecurity abuses hinge on exploiting gaps between reality and the
assumptions of rational, good-faith actors. Immutability of DID documents
can provide some security benefits. Individual DID methods ought to
consider constraints that would eliminate behaviors or semantics they do not
need. The more locked down a DID method is, while providing the
same set of features, the less it can be manipulated by malicious actors.
As an example, consider that a single edit to a DID document can change
anything except the root id property of the document. But
is it actually desirable for a service to change its
type after it is defined? Or for a key to change its value? Or
would it be better to require a new id when certain
fundamental properties of an object change? Malicious takeovers of a website
often aim for an outcome where the site keeps its host name identifier,
but is subtly changed underneath. If certain properties of the site, such
as the ASN
associated with its IP address, were required by the specification to be
immutable, anomaly detection would be easier, and attacks would be much
harder and more expensive to carry out.
For DID methods tied to a global source of truth, a direct,
just-in-time lookup of the latest version of a DID document is always
possible. However, it seems likely that layers of cache might eventually sit
between a DID resolver and that source of truth. If they do, believing
the attributes of an object in the DID document to have a given state
when they are actually subtly different might invite exploits. This is
particularly true if some lookups are of a full DID document, and
others are of partial data where the larger context is assumed.
8.9 Encrypted Data in DID Documents
Encryption algorithms have been known to fail due to advances in cryptography
and computing power. Implementers are advised to assume that any encrypted data
placed in a DID document might eventually be made available in clear text
to the same audience to which the encrypted data is available. This is
particularly pertinent if the DID document is public.
Encrypting all or parts of a DID document is not an appropriate
means to protect data in the long term. Similarly, placing encrypted data in
a DID document is not an appropriate means to protect personal data.
Given the caveats above, if encrypted data is included in a DID document,
implementers are advised to not associate any correlatable information
that could be used to infer a relationship between the encrypted data
and an associated party. Examples of correlatable information include
public keys of a receiving party, identifiers to digital assets known to be
under the control of a receiving party, or human readable descriptions of a
receiving party.
8.10 Equivalence Properties
Given the equivalentId and canonicalId
properties are generated by DID methods themselves, the same security and
accuracy guarantees that apply to the resolved DID present in the
id field of a DID document also apply to these properties.
The alsoKnownAs property is not guaranteed to be an accurate
statement of equivalence, and should not be relied upon without performing
validation steps beyond the resolution of the DID document.
The equivalentId and canonicalId
properties express equivalence assertions to variants of a single DID
produced by the same DID method and can be trusted to the extent the
requesting party trusts the DID method and a conforming producer and
resolver.
As with any other security-related properties in the DID document,
parties relying on any equivalence statement in a DID document should
guard against the values of these properties being substituted by an attacker
after the proper verification has been performed. Any write access to a DID document stored in memory or disk after verification has been performed is
an attack vector that might circumvent verification unless the DID document is re-verified.
8.11 Persistence
DIDs are designed to be persistent such that a controller need not
rely upon a single trusted third party or administrator to maintain their
identifiers. In an ideal case, no administrator can take control away from the
controller, nor can an administrator prevent their identifiers' use for
any particular purpose such as authentication, authorization, and attestation.
No third party can act on behalf of a controller to remove or render
inoperable an entity's identifier without the controller's consent.
However, it is important to note that in all DID methods that enable
cryptographic proof-of-control, the means of proving control can always be
transferred to another party by transferring the secret cryptographic material.
Therefore, it is vital that systems relying on the persistence of an identifier
over time regularly check to ensure that the identifier is, in fact, still under
the control of the intended party.
Unfortunately, it is impossible to determine from the cryptography alone whether
or not the secret cryptographic material associated with a given
verification method has been compromised. It might well be that the
expected controller still has access to the secret cryptographic material
— and as such can execute a proof-of-control as part of a verification
process — while at the same time, a bad actor also has access to those
same keys, or to a copy thereof.
As such, cryptographic proof-of-control is expected to only be used as one
factor in evaluating the level of identity assurance required for high-stakes
scenarios. DID-based authentication provides much greater assurance than
a username and password, thanks to the ability to determine control over a
cryptographic secret without transmitting that secret between systems. However,
it is not infallible. Scenarios that involve sensitive, high value, or
life-critical operations are expected to use additional factors as appropriate.
In addition to potential ambiguity from use by different controllers, it
is impossible to guarantee, in general, that a given DID is being used in
reference to the same subject at any given point in time. It is technically
possible for the controller to reuse a DID for different subjects and,
more subtly, for the precise definition of the subject to either change over
time or be misunderstood.
For example, consider a DID used for a sole proprietorship, receiving
various credentials used for financial transactions. To the controller,
that identifier referred to the business. As the business grows, it eventually
gets incorporated as a Limited Liability Company. The controller
continues using that same DID, because to them the
DID refers to the business. However, to the state, the tax authority, and
the local municipality, the DID no longer refers to the same entity.
Whether or not the subtle shift in meaning matters to a credit provider or
supplier is necessarily up to them to decide. In many cases, as long as the
bills get paid and collections can be enforced, the shift is immaterial.
Due to these potential ambiguities, DIDs are to be considered valid
contextually rather than absolutely. Their persistence does not imply
that they refer to the exact same subject, nor that they are under the control
of the same controller. Instead, one needs to understand the context in
which the DID was created, how it is used, and consider the likely shifts
in their meaning, and adopt procedures and policies to address both potential
and inevitable semantic drift.
8.12 Evaluating Competing Considerations
This section is non-normative.
This specification does not require or suggest the use of any specific type of
verifiable data registry. Different use cases might result in different
requirements. Different requirements might suggest different considerations with different
trade-offs. For example, trade-offs between computation (energy usage), trust
(deference to authority), coordination (network bandwidth), or memory (physical
storage) might or might not be appropriate for any given use case. Other use cases
might not make the same trade-offs. Those that need to consider different criteria
for their use case are directed to the DID Method Rubric, which provides
evaluation criteria to help decision makers determine whether or not a particular
DID Method is appropriate for their use cases.
9. Privacy Considerations
This section is non-normative.
Since DIDs and DID documents are designed to be administered
directly by the DID controller(s), it is critically important to apply
the principles of Privacy by Design [PRIVACY-BY-DESIGN] to all aspects of the
decentralized identifier architecture. All seven of these principles
have been applied throughout the development of this specification. The design
used in this specification does not assume that there is a registrar, hosting
company, nor other intermediate service provider to recommend or apply
additional privacy safeguards. Privacy in this specification is preventive,
not remedial, and is an embedded default. Before reading this section, readers
are urged to read the
Privacy Considerations section
of the Controlled Identifiers v1.0 specification, as it contains
more general privacy considerations that also apply to DIDs. The rest
of this section covers privacy considerations that are specific to
decentralized identifiers and are in addition to the guidance provided
in the Controlled Identifiers v1.0 specification.
9.1 Group Privacy
When a DID subject is indistinguishable from others in the group,
privacy is available. When the act of engaging privately with another party is
by itself a recognizable flag, privacy is greatly diminished.
DIDs and DID methods need to work to improve group privacy, particularly for those who
legitimately need it most. Choose technologies and human interfaces that
default to preserving anonymity and pseudonymity. To reduce digital
fingerprints, share common settings across requesting party
implementations, keep negotiated options to a minimum on wire protocols, use
encrypted transport layers, and pad messages to standard lengths.
Example 16: DID Document that uses relative DID URLs
{"@context":"https://www.w3.org/ns/did/v1.1","id":"did:example:123","verificationMethod":[{// A relative DID URL, that will be transformed to the absolute DID URL value did:example:123#key-1"id":"#key-1","type":"Ed25519VerificationKey2020","controller":"did:example:123","publicKeyMultibase":"z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"}],"authentication":["#key-1"],"capabilityInvocation":["#key-1"],"capabilityDelegation":["#key-1"],"assertionMethod":[// Using relative DID URL #key-1 is equivalent to using the absolute DID URL value did:example:123#key-1"did:example:123#key-1"]}
Example 17: Verifiable Credential linked to a verification method of type Multikey
{// external (all terms in this example)"@context":["https://www.w3.org/ns/credentials/v2","https://w3id.org/citizenship/v4rc1"],"type":["VerifiableCredential","PermanentResidentCardCredential"],"issuer":{"id":"did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz","image":"data:image/png;base64,iVBORw0KGgo...5CYII="},"name":"Permanent Resident Card","description":"Government of Utopia Permanent Resident Card.","credentialSubject":{"type":["PermanentResident","Person"],"givenName":"JANE","familyName":"SMITH","gender":"Female","image":"data:image/png;base64,iVBORw0KGgoAA...kJggg==","residentSince":"2015-01-01","commuterClassification":"C1","birthCountry":"Arcadia","birthDate":"1978-07-17","permanentResidentCard":{"type":"PermanentResidentCard","identifier":"83627465","lprCategory":"C09","lprNumber":"999-999-999"}},"validFrom":"2025-01-04T00:00:00Z","validUntil":"2026-01-04T23:59:59Z","proof":{"type":"DataIntegrityProof","created":"2025-01-04T15:02:36Z","verificationMethod":"did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz#zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z5CK4DPN7...Jpqwp"}}
Example 18: Verifiable Credential linked to a verification method of type JsonWebKey
{// external (all terms in this example)"@context":["https://www.w3.org/ns/credentials/v2","https://w3id.org/citizenship/v4rc1"],"type":["VerifiableCredential","PermanentResidentCardCredential"],"issuer":{"id":"did:example:123#key-1","image":"data:image/png;base64,iVBORw0KGgo...5CYII="},"name":"Permanent Resident Card","description":"Government of Utopia Permanent Resident Card.","credentialSubject":{"type":["PermanentResident","Person"],"givenName":"JANE","familyName":"SMITH","gender":"Female","image":"data:image/png;base64,iVBORw0KGgoAA...kJggg==","residentSince":"2015-01-01","commuterClassification":"C1","birthCountry":"Arcadia","birthDate":"1978-07-17","permanentResidentCard":{"type":"PermanentResidentCard","identifier":"83627465","lprCategory":"C09","lprNumber":"999-999-999"}},"validFrom":"2025-01-04T00:00:00Z","validUntil":"2026-01-04T23:59:59Z","proof":{"type":"DataIntegrityProof","created":"2025-01-04T15:02:36Z","verificationMethod":"did:example:123#key-1","cryptosuite":"ecdsa-jcs-2019","proofPurpose":"assertionMethod","proofValue":"z5m9akGtdL...6rqBspGQP"}}
Example 19: Verifiable Credential linked to a bls12381 verification method
{// external (all terms in this example)"@context":["https://www.w3.org/ns/credentials/v2","https://w3id.org/citizenship/v4rc1"],"type":["VerifiableCredential","PermanentResidentCardCredential"],"issuer":{"id":"did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE","image":"data:image/png;base64,iVBORw0KGgoAA...CYII="},"name":"Permanent Resident Card","description":"Government of Utopia Permanent Resident Card.","credentialSubject":{"type":["PermanentResident","Person"],"givenName":"JANE","familyName":"SMITH","gender":"Female","image":"data:image/png;base64,iVBORw0KGgoAAA...3dgg==","residentSince":"2015-01-01","commuterClassification":"C1","birthCountry":"Arcadia","birthDate":"1978-07-17","permanentResidentCard":{"type":"PermanentResidentCard","identifier":"83627465","lprCategory":"C09","lprNumber":"999-999-999"}},"validFrom":"2025-01-04T00:00:00Z","validUntil":"2026-01-04T23:59:59Z","proof":{"type":"DataIntegrityProof","verificationMethod":"did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE#zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE","cryptosuite":"bbs-2023","proofPurpose":"assertionMethod","proofValue":"u2V0ChVhQik2d4...pc3N1ZXI"}}
Example 20: Verifiable Credential selective disclosure zero knowledge proof linked to a bls12381 verification method
{// external (all terms in this example)"@context":"https://www.w3.org/ns/credentials/v2","type":"VerifiablePresentation",// holder did:key is pairwise to the domain to avoid correlation"holder":"did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX","verifiableCredential":{"@context":["https://www.w3.org/ns/credentials/v2","https://w3id.org/citizenship/v4rc1"],"type":["VerifiableCredential","PermanentResidentCardCredential"],"issuer":{"id":"did:web:unlinkable.example","image":"data:image/png;base64,iVBORw0KGgoAA...CYII="},"credentialSubject":{"type":["PermanentResident","Person"],// only country is selectively disclosed"birthCountry":"Arcadia"},"proof":{"type":"DataIntegrityProof","verificationMethod":"did:web:vcplayground.org#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp","cryptosuite":"bbs-2023","proofPurpose":"assertionMethod","proofValue":"u2V0DhV...3JnIn0"}},"proof":{"type":"DataIntegrityProof","created":"2025-01-04T15:10:39Z","verificationMethod":"did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX#z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX","proofPurpose":"authentication","challenge":"QZVVFcXlMPStFmpXTSktv","domain":"https://unlinkable.example","proofValue":"z5tXmHk...x2GvTt3bF"}}
{// external (all terms in this example)"protected":{"kid":"did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A","alg":"EdDSA"},"payload":{"@context":["https://www.w3.org/ns/credentials/v2","https://w3id.org/citizenship/v4rc1"],"type":["VerifiableCredential","PermanentResidentCardCredential"],"issuer":{"id":"did:key:zUC7Do...oAVE","image":"data:image/png;base64,iVBORw0KGgoAA...CYII="},"name":"Permanent Resident Card","description":"Government of Utopia Permanent Resident Card.","credentialSubject":{"type":["PermanentResident","Person"],"givenName":"JANE","familyName":"SMITH","gender":"Female","image":"data:image/png;base64,iVBORw0KGgoAAA...3dgg==","residentSince":"2015-01-01","commuterClassification":"C1","birthCountry":"Arcadia","birthDate":"1978-07-17","permanentResidentCard":{"type":"PermanentResidentCard","identifier":"83627465","lprCategory":"C09","lprNumber":"999-999-999"}},"validFrom":"2025-01-04T00:00:00Z","validUntil":"2026-01-04T23:59:59Z",},"signature":"qSv6d...bJRAw"}
A.3 Encrypting
This section is non-normative.
Note
These examples are for information purposes only, it is considered a best
practice to avoid dislosing unnecessary information in JWE headers.
Example 22: JWE linked to a verification method via kid
{// external (all terms in this example)"ciphertext":"3SHQQJajNH6q0fyAHmw...","iv":"QldSPLVnFf2-VXcNLza6mbylYwphW57Q","protected":"eyJlbmMiOiJYQzIwUCJ9","recipients":[{"encrypted_key":"BMJ19zK12YHftJ4sr6Pz1rX1HtYni_L9DZvO1cEZfRWDN2vXeOYlwA","header":{"alg":"ECDH-ES+A256KW","apu":"Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s","apv":"ZGlkOmVsZW06cm9wc3RlbjpFa...","epk":{"crv":"X25519","kty":"OKP","x":"Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s"},"kid":"did:example:123#zC1Rnuvw9rVa6E5TKF4uQVRuQuaCpVgB81Um2u17Fu7UK"}}],"tag":"xbfwwDkzOAJfSVem0jr1bA"}
Figure 5
Detailed overview of DID architecture and the relationship of the basic components.
B.2 Creation of a DID
This section is non-normative.
The creation of a DID is a process that is defined by each DID Method. Some DID Methods, such as did:key, are purely
generative, such that a DID and a DID document are generated by
transforming a single piece of cryptographic material into a conformant
representation. Other DID methods might require the use of a
verifiable data registry, where the DID and DID document
are recognized to exist by third parties only when the registration has been
completed, as defined by the respective DID method. Other processes
might be defined by the respective DID method.
B.3 Determining the DID subject
This section is non-normative.
A DID is a specific type of URI (Uniform Resource Identifier), so a
DID can refer to any resource. Per [RFC3986]:
the term "resource" is used in a general sense for whatever might be
identified by a URI. [...] A resource is not necessarily
accessible via the Internet.
Resources can be digital or physical, abstract or concrete. Any resource that
can be assigned a URI can be assigned a DID. The resource referred to
by the DID is the DID subject.
The DID controller determines the DID subject.
It is not expected to be possible to determine the DID subject
from looking at the DID itself, as DIDs are generally
only meaningful to machines, not human. A DID is unlikely to contain
any information about the DID subject, so further information
about the DID subject is only discoverable by resolving the DID
to the DID document, obtaining a verifiable credential about the
DID, or via some other description of the DID.
While the value of the id property in the retrieved
DID document must always match the DID being resolved, whether
or not the actual resource to which the DID refers can change over time
is dependent upon the DID method. For example, a DID method
that permits the DID subject to change could be used to generate a
DID for the current occupant of a particular role—such as the CEO
of a company—where the actual person occupying the role can be different
depending on when the DID is resolved.
Two filled black circles appear at the top of the diagram, one on the left,
labeled "DID Controller", and one on the right, labeled "DID Subject". A
rectangle, with lower right corner bent inwards to form a small triangle,
appears below, containing the label "DID Document". Arrows extend between these
three items, as follows. A solid red arrow points directly from the DID
Controller circle, rightwards to the DID Subject circle, labeled "DID" above it
in large font, and "Identifies" below it in small italic font. The other arrow
labels are also in small italic font. A dotted red arrow, labeled "Resolves
to", extends from DID Controller, starting in the same line as the first arrow,
then curving downward to point to the DID Document rectangle. A green arrow,
labeled "Controls", points directly from DID Controller to DID Document. A
green arrow labeled "Controller" points in the opposite direction, from DID
Document to DID Controller, making an arc outward to the left of the diagram. A
blue arrow, labeled, "Describes" points directly from DID Document to DID
Subject.
The string of characters defining identifiers for the DID subject
(e.g., the id and alsoKnownAs
properties)
How to interact with the DID subject (e.g., the
verificationMethod and service
properties).
How to interpret the specific representation of the DID document
(e.g., the @context property for a JSON-LD representation).
The only required property in a DID document is id,
so that is the only statement guaranteed to be in a DID document.
That statement is illustrated in Figure 6
with a direct link between the DID and the DID subject.
B.6 Discovering more information about the DID subject
This section is non-normative.
Options for discovering more information about the DID subject depend
on the properties present in the DID document. If the
service property is present, more information can be
requested from a service endpoint. For example, by querying a
service endpoint that supports verifiable credentials for one or more
claims (attributes) describing the DID subject.
Another option is to use the alsoKnownAs property if it
is present in the DID document. The DID controller can use it
to provide a list of other URIs (including other DIDs) that refer to
the same DID subject. Resolving or dereferencing these URIs might yield
other descriptions or representations of the DID subject as
illustrated in the figure below.
The diagram contains three small black filled circles, two rectangles with bent
corners, arrows between them, and labels, as follows. On the upper left is a
circle labeled "DID Controller". On the upper right is a circle labeled "DID
Subject". On the lower-middle right is a circle without a label. On the lower
right is a rectangle labeled "Description". In the center of the diagram is a
rectangle labeled "DID Document". Inside the DID Document rectangle, beneath
its label, is two lines of code: "alsoKnownAs: [", and "URI]". A black arrow
extends from the second line, to the right, crossing the rectangle border,
pointing to the unlabeled circle at the right of the diagram. This arrow is
labeled above it in large font, "URI", and below it in italic, "Identifies". A
black arrow points from the unlabeled circle downwards to the Description
rectangle, labeled "Dereferences to". A blue arrow, labeled "Describes",
extends from Description, arcing on the right, pointing up to DID Subject. A
blue arrow, also labeled "Describes", points directly from the rectangle,
labeled "DID Document", in the center of the diagram, up and to the right to the
DID Subject circle. A red arrow, labeled "alsoKnownAs", points from DID Subject
down to the unlabeled circle. A red arrow, labeled "DID" above it in large font,
and "Identifies" below it in italic font, lies at the top of the image, pointing
from DID Controller to DID Subject. A dotted red line starts in the same place
but branches off and curves downward to point to the DID Document rectangle at
the center of the image. A green arrow, labeled "Controls", points directly
from DID Controller to DID Document. Another green arrow points in the opposite
direction, labeled "Controller", curving outwards on the left of the image,
from DID Document to DID Controller.
B.7 Serving a representation of the DID subject
This section is non-normative.
If the DID subject is a digital resource that can be retrieved
from the internet, a DID method can choose to construct a DID URL
which returns a representation of the DID subject itself. For example,
a data schema that needs a persistent, cryptographically verifiable identifier
could be assigned a DID, and passing a specified Path
or Query could be used as a standard way to retrieve a
representation of that schema.
Similarly, a DID can be used to refer to a digital resource (such as
an image) that can be returned directly from a verifiable data registry
if that functionality is supported by the applicable DID method.
B.8 Assigning DIDs to existing web resources
This section is non-normative.
If the controller of a web page or any other web resource wants to
assign it a persistent, cryptographically verifiable identifier, the
controller can give it a DID. For example, the author of a blog
hosted by a blog hosting company (under that hosting company's domain)
could create a DID for the blog. In the DID document, the
author can include the alsoKnownAs property pointing to
the current URL of the blog, e.g.:
If the author subsequently moves the blog to a different hosting company
(or to the author's own domain), the author can update the DID document
to point to the new URL for the blog, e.g.:
"alsoKnownAs": ["https://myblog.example/"]
The DID effectively adds a layer of indirection for the blog URL. This
layer of indirection is under the control of the author instead of under the
control of an external administrative authority such as the blog hosting
company. This is how a DID can effectively function as an enhanced URN (Uniform Resource
Name)—a persistent identifier for an information resource whose
network location might change over time.
B.9 The relationship between DID controllers and DID subjects
This section is non-normative.
To avoid confusion, it is helpful to classify
DID subjects into two disjoint sets based on their relationship to
the DID controller.
B.9.1 Set #1: The DID subject is the DID controller
This section is non-normative.
The first case, shown in Figure 8, is
the common scenario where the DID subject is also the DID controller. This is the case when an individual or organization creates a
DID to self-identify.
Two small black circles appear in the diagram, one on the upper left, labeled,
"DID Controller", and one on the upper right, labeled "DID Subject". A solid red
arrow extends from the DID Controller circle to the DID Subject circle, labeled
"DID" in large bold text above the arrow, and "Identifies" in small italic text
beneath the arrow. A dotted red double-ended arrow, labeled "Equivalence",
extends between the two circles, forming an arc in the space between and above
them. In the lower part of the diagram is a rectangle with bent corner, outlined
in black, containing the label "DID Document". Arrows point between this DID
Document rectangle and the small black circles for DID Controller and DID
Subject, with italic labels, as follows. A blue arrow points from the DID
Document to the DID Subject, labeled, "Describes". A green arrow points from the
DID Controller to the DID Document, labeled "Controls". A green arrow points
from the DID Document to the DID Controller, in an outward arc, labeled,
"Controller". A dotted red arrow, labeled "Resolves to", extends from the DID
controller starting to the right, branching off from the arrow to the DID
Subject, then curving downward to point to the DID Document.
From a graph model perspective, even though the nodes identified as the
DID controller and DID subject in
Figure 8 are distinct, there is a
logical arc connecting them to express a semantic equivalence relationship.
B.9.2 Set #2: The DID subject is not the DID controller
This section is non-normative.
The second case is when the DID subject is a separate entity from the
DID controller. This is the case when, for example, a parent creates
and maintains control of a DID for a child; a corporation creates and
maintains control of a DID for a subsidiary; or a manufacturer
creates and maintains control of a DID for a product, an IoT device,
or a digital file.
From a graph model perspective, the only difference from Set 1 that there is
no equivalence arc relationship between the DID subject and
DID controller nodes.
In this case, each of the DID controllers might act on its own, i.e.,
each one has full power to update the DID document independently. From
a graph model perspective, in this configuration:
Each additional DID controller is another distinct graph node
(which might be identified by its own DID).
Three black circles appear on the left, vertically, each labeled "DID
Controller". From each of these circles, a pair of green arrows extends towards
the center of the diagram, to a single rectangle, labeled "DID Document". The
rectangle has the lower right corner cut and bent inward to form a small
triangle, as if to represent a physical piece of paper with curled corner. Each
pair of green arrows consists of one arrow pointing from the black circle to the
rectangle, labeled "Controls", and one pointing in the opposite direction, from
the rectangle to the black circle, labeled "Controller". From the right of the
rectangle extends a blue arrow, labeled, "Describes", pointing to a black circle
labeled, "DID Subject".
B.10.2 Group Control
This section is non-normative.
In the case of group control, the DID controllers are expected to act
together in some fashion, such as when using a cryptographic algorithm that
requires multiple digital signatures ("multi-sig") or a threshold number of
digital signatures ("m-of-n"). These additional thresholds for
verifying a proof can be expressed in a verification method as described in
Section 5.2 Verification Methods or can be an intrinsic part of the
verification material of the verification method, where the number of DID controllers that
participated in the generation of a particular digital signature are hidden for
privacy reasons. Verification methods that require a proof be produced by a combination of cryptographic operations performed by members of a group can be used to control the contents of a DID document; exactly how this is realized depends on individual DID method specifications.
From a functional standpoint, this option is
similar to a single DID controller because, although each of the
DID controllers in the DID controller group has its own graph
node, the actual control collapses into a single logical graph node
representing the DID controller group as shown in
Figure 10.
On the left are three black filled circles, labeled "DID Controller Group" by a
brace on the left. From each of these three circles, a green arrow extends to
the center right. These three arrows converge towards a single filled white
circle. A pair of horizontal green arrows connects this white circle on its
right to a rectangle shaped like a page with a curled corner, labeled "DID
Document". The upper arrow points right, from the white circle to the
rectangle, and is labeled "Controls". The lower arrow points left, from the
rectangle to the white circle, and is labeled "Controller". From the right of
the rectangle extends a blue arrow, labeled "Describes", pointing to a black
circle, labeled "DID Subject".
This configuration will often apply when the DID subject is an
organization, corporation, government agency, community, or other group
that is not controlled by a single individual.
B.11 Changing the DID subject
This section is non-normative.
A DID document has exactly one DID which refers to
the DID subject. The DID is expressed as the value of the
id property. This property value is immutable for
the lifetime of the
DID document.
However, it is possible that the resource identified by the DID,
the DID subject, may change over time. This is under the exclusive
authority of the DID controller. For more details, see section 8.11 Persistence.
B.12 Changing the DID controller
This section is non-normative.
The DID controller for a DID document might change over time.
However, depending on how it is implemented, a change in the DID controller might not be made apparent by changes to the DID document
itself. For example, if the change is implemented through a shift in ownership
of the underlying cryptographic keys or other controls used for one or more of
the verification methods in the DID document, it might be
indistinguishable from a standard key rotation.
On the other hand, if the change is implemented by changing the value of the
controller property, it will be transparent.
Addition of at risk markers to most of the DID Parameters, the data model
datatypes that are expected to not be implemented, and the
application/did+ld+json media type. This change resulted in the DID WG's
decision to perform a second Candidate Recommendation phase. All other
changes were either editorial or predicted in "at risk" issue markers.
Removal of the at risk issue marker for the method-specific-id ABNF rule
and for nextUpdate and nextVersionId.
Clarification that equivalentId and canonicalId are optional.
Addition of a definitions for "amplification attack" and "cryptographic suite".
Replacement of publicKeyBase58 with publicKeyMultibase.
Updates to the DID Document examples section.
A large number of editorial clean ups to the Security Considerations section.
The introduction of an abstract data model that can be serialized to multiple
representations including JSON and JSON-LD.
The introduction of a repository of DID Extensions for the purposes of
registering extension properties, representations, DID Resolution input
metadata and output metadata, DID Document metadata, DID parameters, and DID
Methods.
Separation of DID Document metadata, such as created and updated values,
from DID Document properties.
The removal of embedded proofs in the DID Document.
The addition of verification relationships for the purposes of authentication,
assertion, key agreement, capability invocation and capability delegation.
The ability to support relating multiple identifiers with the DID Document,
such as the DID controller, also known as, equivalent IDs, and canonical IDs.
Enhancing privacy by reducing information that could contain personally
identifiable information in the DID Document.
The addition of a large section on security considerations and privacy
considerations.
A Representations section that details how the abstract data model can be
produced and consumed in a variety of different formats along with general
rules for all representations, producers, and consumers.
A section detailing the DID Resolution and DID URL Dereferencing interface
definition that all DID resolvers are expected to expose as well as inputs
and outputs to those processes.
DID Document examples in an appendix that provide more complex examples of
DID Document serializations.
IANA Considerations for multiple representations specified in DID Core.
Removal of the Future Work section as much of the work has now been
accomplished.
An acknowledgements section.
D. Acknowledgements
This section is non-normative.
The Working Group extends deep appreciation and heartfelt thanks to our Chairs
Brent Zundel and Dan Burnett, as well as our W3C Staff Contact, Ivan Herman, for
their tireless work in keeping the Working Group headed in a productive
direction and navigating the deep and dangerous waters of the standards process.
The Working Group gratefully acknowledges the work that led to the creation of
this specification, and extends sincere appreciation to those individuals that
worked on technologies and specifications that deeply influenced our work. In
particular, this includes the work of Phil Zimmerman, Jon Callas, Lutz
Donnerhacke, Hal Finney, David Shaw, and Rodney Thayer on Pretty Good Privacy
(PGP) in the 1990s and 2000s.
In the mid-2010s, preliminary implementations of what would become Decentralized
Identifiers were
built in collaboration with Jeremie Miller's Telehash project and the W3C
Web Payments Community Group's work led by Dave Longley and Manu Sporny. Around
a year later, the XDI.org Registry Working Group
began exploring decentralized technologies for replacing its existing
identifier registry. Some of the first
writtenpapers
exploring the concept of Decentralized Identifiers can be traced back to the
first several Rebooting the Web of Trust workshops convened by Christopher
Allen. That work led to a key collaboration between Christopher Allen, Drummond
Reed, Les Chasen, Manu Sporny, and Anil John. Anil saw promise in the technology
and allocated the initial set of government funding to explore the space.
Without the support of Anil John and his guidance through the years, it is
unlikely that Decentralized Identifiers would be where they are today. Further
refinement at the Rebooting the Web of Trust workshops led to the first
implementers documentation, edited by Drummond Reed, Les Chasen, Christopher
Allen, and Ryan Grant. Contributors included Manu Sporny, Dave Longley, Jason
Law, Daniel Hardman, Markus Sabadello, Christian Lundkvist, and Jonathan
Endersby. This initial work was then merged into the W3C Credentials Community
Group, incubated further, and then transitioned to the W3C Decentralized
Identifiers Working Group for global standardization.
Portions of the work on this specification have been funded by the United States
Department of Homeland Security's (US DHS) Science and Technology Directorate
under contracts HSHQDC-16-R00012-H-SB2016-1-002, and HSHQDC-17-C-00019, as well
as the US DHS Silicon Valley Innovation Program under contracts
70RSAT20T00000010, 70RSAT20T00000029, 70RSAT20T00000030, 70RSAT20T00000045,
70RSAT20T00000003, and 70RSAT20T00000033. 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.
Portions of the work on this specification have also been funded by the European
Union's StandICT.eu program under sub-grantee contract number CALL05/19. The
content of this specification does not necessarily reflect the position or the
policy of the European Union 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, Kim Hamilton Duffy, Manu Sporny, Drummond
Reed, Joe Andrieu, and Heather Vescent. Development of this specification has
also been supported by the W3C Credentials
Community Group, which has been Chaired by Kim Hamilton Duffy, Joe Andrieu,
Christopher Allen, Heather Vescent, and Wayne Chang. The participants in the
Internet Identity Workshop, facilitated by Phil Windley, Kaliya Young, Doc
Searls, and Heidi Nobantu Saul, also supported this work through numerous
working sessions designed to debate, improve, and educate participants about
this specification.
The Working Group thanks the following individuals for their contributions to
this specification (in alphabetical order, Github handles start with @ and
are sorted as last names): Denis Ah-Kang, Nacho Alamillo, Christopher Allen, Joe
Andrieu, Antonio, Phil Archer, George Aristy, Baha, Juan Benet, BigBlueHat, Dan
Bolser, Chris Boscolo, Pelle Braendgaard, Daniel Buchner, Daniel Burnett, Juan
Caballero, @cabo, Tim Cappalli, Melvin Carvalho, David Chadwick, Wayne Chang,
Sam Curren, Hai Dang, Tim Daubenschütz, Oskar van Deventer, Kim Hamilton Duffy,
Arnaud Durand, Ken Ebert, Veikko Eeva, @ewagner70, Carson Farmer, Nikos Fotiou,
Gabe, Gayan, @gimly-jack, @gjgd, Ryan Grant, Peter Grassberger, Adrian Gropper,
Amy Guy, Daniel Hardman, Kyle Den Hartog, Philippe Le Hegaret, Ivan Herman,
Michael Herman, Alen Horvat, Dave Huseby, Marcel Jackisch, Mike Jones, Andrew
Jones, Tom Jones, jonnycrunch, Gregg Kellogg, Michael Klein, @kdenhartog-sybil1,
Paul Knowles, @ktobich, David I. Lehn, Charles E. Lehner, Michael Lodder,
@mooreT1881, Dave Longley, Tobias Looker, Wolf McNally, Robert Mitwicki, Mircea
Nistor, Grant Noble, Mark Nottingham, @oare, Darrell O'Donnell, Vinod Panicker,
Dirk Porsche, Praveen, Mike Prorock, @pukkamustard, Drummond Reed, Julian
Reschke, Yancy Ribbens, Justin Richer, Rieks, @rknobloch, Mikeal Rogers,
Evstifeev Roman, Troy Ronda, Leonard Rosenthol, Michael Ruminer, Markus
Sabadello, Cihan Saglam, Samu, Rob Sanderson, Wendy Seltzer, Mehran Shakeri,
Jaehoon (Ace) Shim, Samuel Smith, James M Snell, SondreB, Manu Sporny, @ssstolk,
Orie Steele, Shigeya Suzuki, Sammotic Switchyarn, @tahpot, Oliver Terbu, Ted
Thibodeau Jr., Joel Thorstensson, Tralcan, Henry Tsai, Rod Vagg, Mike Varley,
Kaliya "Identity Woman" Young, Eric Welton, Fuqiao Xue, @Yue, Dmitri Zagidulin,
@zhanb, and Brent Zundel.
E. IANA Considerations
This section will be submitted to the Internet Engineering Steering Group
(IESG) for review, approval, and registration with IANA when this specification
becomes a W3C Proposed Recommendation.
Any application that requires an identifier that is decentralized, persistent,
cryptographically verifiable, and resolvable. Applications typically consist of
cryptographic identity systems, decentralized networks of devices, and
websites that issue or verify verifiable credentials.
