[=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.
Each [=DID document=] can express cryptographic material, [=verification
methods=], or [=services=], which provide a set of mechanisms enabling a
[=DID controller=] to prove control of the [=DID=]. [=Services=] enable
trusted interactions associated with the [=DID subject=]. A [=DID=] might
provide the means to return the [=DID subject=] itself, if the [=DID
subject=] is an information resource such as a data model.
This document specifies the DID syntax, a common data model, core properties,
serialized representations, DID operations, and an explanation of the process
of resolving DIDs to the resources that they represent.
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: [[[DID-CORE]]].
Introduction
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.
A Simple Example
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.
A simple example of a decentralized identifier (DID)
The example [=DID=] above resolves to a [=DID document=]. A [=DID
document=] contains information associated with the [=DID=], such as ways
to cryptographically [=authenticate=] a [=DID controller=].
{
"@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"
}]
}
Design Goals
[=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.
Architecture Overview
This section provides a basic overview of the major components of
Decentralized Identifier architecture.
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 [[[#did-syntax]]] and
[[[#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 [[[#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 [[[#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
[[[#methods]]].
DID documents
[=DID documents=] contain information associated with a [=DID=]. They
typically express [=verification methods=], such as cryptographic public
keys, and [=services=] relevant to interactions with the [=DID subject=].
The generic properties supported in a [=DID document=] are specified in [[[#core-properties]]]. A [=DID document=] can be serialized to a byte
stream (see [[[#representations]]]). The properties present in
a [=DID document=] can be updated according to the applicable operations
outlined in [[[#methods]]].
DID 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 [[[#methods]]].
DID resolvers and DID resolution
A [=DID resolver=] is a system component that takes a [=DID=] as input and
produces a conforming [=DID document=] as output. This process is called
[=DID resolution=]. The steps for resolving a specific type of [=DID=] are
defined by the relevant [=DID method=] specification. The process of [=DID
resolution=] is elaborated upon in [[?DID-RESOLUTION]].
DID URL dereferencers and DID URL dereferencing
A [=DID URL dereferencer=] is a system component that takes a [=DID URL=]
as input and produces a [=resource=] as output. This process is
called [=DID URL dereferencing=]. The process of [=DID URL dereferencing=]
is elaborated upon in [[?DID-RESOLUTION]].
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
[[[#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 [[[#data-model]]] and [[[#core-properties]]]. A
serialization format for the conforming document is deterministic,
bi-directional, and lossless, as described in [[[#representations]]].
A conforming producer is any algorithm realized as software and/or
hardware that generates [=conforming DIDs=] or [=conforming DID
Documents=] and complies with the relevant normative statements in [[[#representations]]].
A conforming consumer is any algorithm realized as software and/or
hardware that consumes [=conforming DIDs=] or [=conforming DID documents=]
and complies with the relevant normative statements in [[[#representations]]].
A conforming DID method is any specification that
complies with the relevant normative statements in [[[#methods]]].
Audience
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.
Terminology
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.
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 specific [=DID methods=] in their respective
specifications. The creation processes, and their timing, for [=DIDs=] and
[=DID URLs=] are described in [[[#method-operations]]] and
[[[#creation-of-a-did]]].
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 [=DIDs=] MUST conform to the
DID Syntax ABNF Rules.
For requirements on [=DID methods=] relating to the [=DID=] syntax, see
Section [[[#method-syntax]]].
DID URL Syntax
A [=DID URL=] is a network location identifier for a specific
[=resource=]. It can be used to retrieve things like representations
of [=DID subjects=], [=verification methods=], [=services=],
specific parts of a [=DID document=], or other resources.
The following is the ABNF definition using the syntax in [[!RFC5234]]. It builds
on the `did` scheme defined in [[[#did-syntax]]]. The `path-abempty`, `query`, and `fragment` components are
defined in [[!RFC3986]]. All [=DID URLs=] MUST conform to the
DID URL Syntax ABNF Rules. [=DID methods=] can further restrict these
rules, as described in [[[#method-syntax]]].
The DID URL Syntax ABNF Rules
did-url = did path-abempty [ "?" query ] [ "#" fragment ]
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.
did:example:123456/path
Query
A [=DID query=] is identical to a generic [=URI=] query and conforms to
the `query` ABNF rule in RFC 3986, section 3.4.
did:example:123456?versionId=1
Fragment
[=DID fragment=] syntax and semantics are identical to a generic [=URI=]
fragment and conforms to the `fragment` ABNF rule in RFC 3986, section 3.5.
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.
In order to maximize interoperability, implementers are urged to ensure that
[=DID fragments=] are interpreted in the same way across
[=representations=] (see [[[#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 [[[#application-did]]]. For information
about how to dereference a [=DID fragment=], see [[?DID-RESOLUTION]].
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
[[[#did-syntax]]]. The URL is expected to reference
a [=resource=] in the same [=DID document=]. Relative [=DID URLs=] MAY
contain relative path components, query parameters, and fragment identifiers.
When resolving a relative [=DID URL=] reference, the algorithm specified in
RFC3986 Section 5: Reference Resolution
MUST be used. The base URI value is the [=DID=] that is
associated with the [=DID subject=], see [[[#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.
Relative [=DID URLs=] are often used to reference [=verification methods=]
and [=services=] in a [=DID Document=] without having to use absolute
URLs. [=DID methods=] where storage size is a consideration might use
relative URLs to reduce the storage size of [=DID documents=].
{
"@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`.
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.
A [=DID document=] consists of a map of entries, where each entry consists of a
key/value pair. The [=DID document=] data model contains at least two
different classes of entries. The first class of entries is called properties,
and is specified in section [[[#core-properties]]]. The second class
is made up of [=representation-specific entries=], and is specified in
section [[[#representations]]].
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.
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.
[=Representations=] MAY 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 [=representation=] SHOULD
define a mapping of all properties and [=representation=] syntax into the data model and its type system.
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.
Core Properties
A [=DID=] is associated with a [=DID document=], which is an extension
of a [=controlled identifier document=] as defined in [[[CID]]].
[=DID documents=] are expressed using the
data model and can be serialized into a
representation.
The following sections define the properties in a [=DID document=],
including whether these properties are required or optional. These properties
describe relationships between the [=DID subject=] and the value of the
property.
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.
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 `service` [=map=] can be a URL.
Property
Required?
Value constraints
Definition
`id`
yes
A string that conforms to rules defined
in Section [[[#did-syntax]]].
Section [[[#did-subject]]].
`controller`
no
A string or a
set of
strings, each of which conforms to rules
defined in Section [[[#did-syntax]]].
Section [[[#did-controller]]].
`alsoKnownAs`
no
A set of
strings, each of which conforms to the URL
syntax or Section [[[#did-syntax]]].
A set of data where each element is either
a string which conforms to rules defined in
Section [[[#did-syntax]]], or a
map that conforms to the rules for
[=verification methods=] defined in Section [[[#verification-methods]]].
A set of data where each element is either
a string which conforms to rules defined in
Section [[[#did-syntax]]], or a
map that conforms to the rules for
[=verification methods=] defined in Section [[[#verification-methods]]].
Section 2.3.2: Assertion
of the [[[CID]]] specification and Section [[[#verification-methods]]].
`keyAgreement`
no
A set of data where each element is either
a string which conforms to rules defined in
Section [[[#did-syntax]]], or a
map that conforms to the rules for
[=verification methods=] defined in Section [[[#verification-methods]]].
A set of data where each element is either
a string which conforms to rules defined in
Section [[[#did-syntax]]], or a
map that conforms to the rules for
[=verification methods=] defined in Section [[[#verification-methods]]].
A set of data where each element is either
a string which conforms to rules defined in
Section [[[#did-syntax]]], or a
map that conforms to the rules for
[=verification methods=] defined in Section [[[#verification-methods]]].
This section describes the mechanisms by which [=DID documents=]
include identifiers for [=DID subjects=] and [=DID controllers=].
DID Subject
The [=DID=] for a particular [=DID subject=] is expressed using the
`id` property in the [=DID document=]. This property
is defined in Section 2.1.1: Subjects of
the [[[CID]]] specification and extended by this specification to include
[=decentralized identifiers=] as defined in Section [[[#did-syntax]]].
{
"id": "did:example:123456789abcdefghijk"
}
[=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.
DID Controller
A [=DID controller=] is an entity that is authorized to make changes to a
[=DID document=]. This property is defined in
Section 2.1.2: Controllers of
the [[[CID]]] specification and extended by this specification to include
DIDs as defined in Section [[[#did-syntax]]]. The process of authorizing a
[=DID controller=] is defined by the [=DID method=].
A [=DID document=] can express [=verification methods=], as defined in
Section 2.2: Verification Methods of
[[[CID]]] with the added restriction that the `id` value
MUST conform to the [[[#did-url-syntax]]] and the
`controller` value MUST conform to the [[[#did-syntax]]].
See
Section 2.2: Verification Methods
of the [[[CID]]] specification for a description of [=verification methods=].
A [=DID document=] can express [=services=], as defined in
Section 2.1.4: Services of the [[[CID]]]
specification. Identifiers used in [=services=]
can be expressed according to Section [[[#did-syntax]]] or
Section [[[#did-url-syntax]]]. See
Section 2.1.4: Services of the [[[CID]]]
specification for a description of [=services=].
Representations
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=].
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 [[[#extensibility]]]
for more information.
The requirements for all [=representations=] are as follows:
A [=representation=] MUST define deterministic production and consumption
rules for all data types specified in [[[#data-model]]].
A [=representation=] MUST be uniquely associated with an IANA-registered
Media Type.
A [=representation=] MUST define fragment processing rules for its Media
Type that are conformant with the fragment processing rules defined in
[[[#fragment]]].
A [=representation=] SHOULD 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 [=representation=] MAY 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.
A [=representation=] MAY define [=representation-specific entries=] that
are stored in a [=representation-specific entries=]
map
for use during the [=production=] and [=consumption=] process. These
entries are used when consuming or producing to aid in ensuring lossless
conversion.
In order to maximize interoperability, [=representation=] specification
authors SHOULD register their [=representation=] in the repository of
DID Extensions [[?DID-EXTENSIONS]].
The requirements for all [=conforming producers=] are as follows:
A [=conforming producer=] MUST take a [=DID document=] data model and a [=representation-specific entries=]
map as input into the [=production=] process.
The [=conforming producer=] MAY accept additional options as input
into the [=production=] process.
A [=conforming producer=] MUST serialize all entries in the [=DID
document=] data model, and the
[=representation-specific entries=] map,
that do not
have explicit processing rules for the [=representation=] being produced
using only the [=representation=]'s data type processing rules and
return the serialization after the [=production=] process completes.
A [=conforming producer=] MUST return the Media Type string associated with the [=representation=]
after the [=production=] process completes.
A conforming producer MUST NOT produce non-conforming [=DIDs=] or [=DID
documents=].
The requirements for all [=conforming consumers=] are as follows:
A [=conforming consumer=] MUST take a [=representation=] and
Media Type string as input into
the [=consumption=] process. A [=conforming consumer=] MAY accept
additional options as input into the [=consumption=] process.
A [=conforming consumer=] MUST determine the [=representation=] of a
[=DID document=] using the Media Type input string.
A [=conforming consumer=] MUST detect any [=representation-specific
entry=] across all known [=representations=] and place the entry into a
[=representation-specific entries=] map
which is returned after the [=consumption=] process completes. A list of
all known [=representation-specific entries=] is available in the repository of
DID Extensions [[?DID-EXTENSIONS]].
A [=conforming consumer=] MUST add all [=non-representation-specific
entries=]
that do not have explicit processing rules for the [=representation=] being
consumed to the [=DID document=] data model using
only the [=representation=]'s data type processing rules and return the
[=DID document=] data model after the [=consumption=] process completes.
A conforming consumer MUST produce errors when consuming non-conforming
[=DIDs=] or [=DID documents=].
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.
JSON
This section defines the [=production=] and [=consumption=] rules
for the JSON [=representation=].
Production
The [=DID document=], DID document data structures, and
[=representation-specific entries=] map MUST
be serialized to the JSON [=representation=] according to the following
[=production=] rules:
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 implementers creating [=conforming producers=] that produce JSON
[=representations=] are advised to ensure that their algorithms are aligned
with the JSON
serialization rules in the [[INFRA]] specification and the precision advisements regarding Numbers in the
JSON [[RFC8259]] specification.
All entries of a [=DID document=] MUST 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 producer=] MUST
specify a media type of `application/did+json` to downstream
applications.
The [=DID document=] and DID document data structures JSON
[=representation=] MUST be deserialized into the data
model according to the following [=consumption=] rules:
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 consumers=] that produce JSON
[=representations=] are advised to ensure that their algorithms are aligned
with the JSON
conversion rules in the [[INFRA]] specification and the precision advisements regarding Numbers in the
JSON [[RFC8259]] specification.
If media type information is available to a [=conforming consumer=] and the
media type value is `application/did+json`, then the data structure
being consumed is a [=DID document=], and the root element MUST be a JSON Object where all members of the object
are entries of the [=DID document=]. A [=conforming consumer=] for a JSON
[=representation=] that is consuming a [=DID document=] with a root
element that is not a JSON Object MUST
report an error.
JSON-LD
JSON-LD [[JSON-LD11]] is a JSON-based format used to serialize Linked Data. This
section defines the [=production=] and [=consumption=] rules for the
JSON-LD [=representation=].
The JSON-LD [=representation=] defines the following
[=representation-specific entries=]:
The [=DID document=], DID document data structures, and
[=representation-specific entries=] map MUST
be serialized to the JSON-LD [=representation=] according to the JSON
[=representation=] [=production=] rules as defined in [[[#json]]].
In addition to using the JSON [=representation=] [=production=] rules,
JSON-LD production MUST include the
representation-specific`@context` entry. The serialized value of
`@context` MUST be the JSON
String `https://www.w3.org/ns/did/v1.1`, or a JSON Array where the first item is the JSON String
`https://www.w3.org/ns/did/v1.1` and the subsequent items are
serialized according to the JSON [=representation=] [=production=]
rules.
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]].
A [=conforming producer=] that generates a JSON-LD [=representation=]
SHOULD NOT produce a [=DID document=] that contains terms not defined via the
`@context` as [=conforming consumers=] are expected to remove
unknown terms. When serializing a JSON-LD [=representation=] of a [=DID
document=], a [=conforming producer=] MUST specify a media type of
`application/did+ld+json` to downstream applications.
Consumption
The [=DID document=] and any DID document data structures expressed by a
JSON-LD [=representation=] MUST be deserialized into the data model according to the JSON [=representation=]
[=consumption=] rules as defined in [[[#json]]].
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.
[=Conforming consumers=] that process a JSON-LD [=representation=] SHOULD
drop all terms from a [=DID document=] that are not defined via the
`@context`.
Media Types
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 [[[#iana-considerations]]]:
`application/did`.
Media Type Precision
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
[[[#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`.
Methods
A [=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.
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 [[[#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 method=] MUST 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 method=] MAY 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.
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=].
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.
A [=DID method=] specification MUST specify how a [=DID controller=]
creates a [=DID=] and its associated [=DID document=].
A [=DID method=] specification MUST specify how a [=DID resolver=] uses a
[=DID=] to resolve a [=DID document=], including how the [=DID
resolver=] can verify the authenticity of the response.
A [=DID method=] specification MUST specify what constitutes an update to a
[=DID document=] and how a [=DID controller=] can update a [=DID
document=] or state that updates are not possible.
The [=DID method=] specification MUST specify how a [=DID controller=] can
deactivate a [=DID=] or state that deactivation is not possible.
The authority of a party that is performing authorization to carry out the
operations is specific to a [=DID method=]. For example, a [=DID method=]
might —
make use of the `controller` property.
use the [=verification methods=] listed under
`authentication`.
use other constructs in the [=DID Document=] such as the [=verification
method=] specified via the `capabilityInvocation`
[=verification relationship=].
not use the [=DID document=] for this decision at all, and depend on an
out-of-band mechanism, instead.
Security Requirements
The requirements for all [=DID method=] specifications when authoring the
Security Considerations section are as follows:
A [=DID method=] specifications MUST follow all guidelines and normative
language provided in RFC3552: Writing Security
Considerations Sections for the [=DID=] operations defined in the [=DID
method=] specification.
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 [[[#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 method=] MUST 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 [[[#services]]], SHOULD consider the
security requirements of the supported authentication protocol.
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.
Security Considerations
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 [[[CID]]] 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.
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.
Non-Repudiation
Non-repudiation of [=DIDs=] and [=DID document=] updates is supported if:
The [=verifiable data registry=] supports
[=verifiable timestamps=]. See "DID Document Metadata" in [[?DID-RESOLUTION]]
for further information on useful timestamps that can be used during the
[=DID resolution=] process.
The subject is monitoring for unauthorized updates as elaborated upon in
[[[#notification-of-did-document-changes]]].
The subject has had adequate opportunity to revert malicious updates according
to the authorization mechanism for the [=DID method=].
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.
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.
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 [[[#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 [[[#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=].
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.
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=].
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.
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.
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.
The `alsoKnownAs` property permits an equivalence assertion to
[=URIs=] that are not governed by the same [=DID method=] and cannot be
trusted without performing verification steps outside of the governing [=DID
method=]. See additional guidance in
Section 2.1.3: Also Known As of the
[[[CID]]] specification.
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.
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.
Evaluating Competing Considerations
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.
Privacy Considerations
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 [[[CID]]] 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 [[[CID]]] specification.
Herd Privacy
When a [=DID subject=] is indistinguishable from others in the herd,
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 herd 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.
Examples
DID Documents
See
Verification Method Types [[?DID-EXTENSIONS]] for optional extensions
and other verification method types.
These examples are for information purposes only, it is considered a best
practice to avoid using the same [=verification method=] for multiple
purposes.
{
"@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"
]
}
Following is a diagram showing the relationships among [[[#data-model]]],
[[[#core-properties]]], and [[[#methods]]], and [[?DID-RESOLUTION]].
Detailed overview of DID architecture and the relationship of the basic components.
Creation of a DID
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=].
Determining the DID subject
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.
Referring to the DID document
The [=DID=] refers to the [=DID subject=] and resolves to the
[=DID document=] (by following the protocol specified by the
[=DID method=]). The [=DID document=] is not a separate resource from
the [=DID subject=] and does not have a [=URI=] separate from the
[=DID=]. Rather the [=DID document=] is an artifact of [=DID
resolution=] controlled by the [=DID controller=] for the purpose of
describing the [=DID subject=].
This distinction is illustrated by the graph model shown below.
A [=DID=] is an identifier assigned by a [=DID controller=] to refer to
a [=DID subject=] and resolve to a [=DID document=] that describes the
[=DID subject=]. The [=DID document=] is an artifact of [=DID
resolution=] and not a separate resource distinct from the [=DID subject=].
See also: narrative description.
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.
Statements in the DID document
Each property in a [=DID document=] is a statement by the
[=DID controller=] that describes:
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 [[[#did-and-did-document-graph]]]
with a direct link between the [=DID=] and the [=DID subject=].
Discovering more information about the DID subject
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.
A [=DID document=] can use the alsoKnownAs property to assert that another
[=URI=] (including, but not necessarily, another [=DID=]) refers to the
same [=DID subject=]. See also: narrative description.
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.
Serving a representation of the DID subject
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=].
Assigning DIDs to existing web resources
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.
The relationship between DID controllers and DID subjects
To avoid confusion, it is helpful to classify
[=DID subject=]s into two disjoint sets based on their relationship to
the [=DID controller=].
Set #1: The DID subject is the DID controller
The first case, shown in [[[#controller-subject-equivalence]]], 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.
The [=DID subject=] is the same entity as the [=DID controller=]. See
also: narrative description.
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
[[[#controller-subject-equivalence]]] are distinct, there is a
logical arc connecting them to express a semantic equivalence relationship.
Set #2: The DID subject is not the DID controller
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.
Multiple DID controllers
A [=DID document=] might have more than one [=DID controller=]. This can
happen in one of two ways.
Independent Control
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=]).
The same arcs ("controls" and "controller") exist between each
[=DID controller=] and the [=DID document=].
Multiple independent [=DID controllers=] that can each act independently. See
also: Text
Description
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".
Group Control
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"). 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
[[[#group-did-controllers]]].
Multiple [=DID controllers=] who are expected to act together as a [=DID
controller=] group. See also: narrative description.
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.
Changing the DID subject
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 [[[#persistence]]].
Changing the DID controller
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.
If it is important to verify a change of [=DID controller=], implementers are
advised to [=authenticate=] the new [=DID controller=] against the
[=verification methods=] in the revised [=DID document=].
Revision History
This section contains the changes that have been made since the publication of
this specification as a W3C First Public Working Draft.
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.
Acknowledgements
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.
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.
Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen
Change controller:
W3C
Fragment identifiers used in JSON-LD environments are treated
according to the rules associated with the
JSON-LD 1.1: application/ld+json
media type [[JSON-LD11]]. Fragment identifiers used in JSON environments
have the same semantic interpretation as those in JSON-LD environments.
