This document serves as an official registry for all known global parameters,
properties, and values used by the Decentralized Identifier ecosystem.
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the W3C technical reports index at
https://www.w3.org/TR/.
This registry is under active development and implementers are advised
against using the registry unless they are directly involved with the
W3C DID Working Group.
Portions of the work on this specification have been funded by the
United States Department of Homeland Security's Science and Technology
Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T00000010,
and HSHQDC-17-C-00019. The content of this specification does not
necessarily reflect the position or the policy of the U.S. Government
and no official endorsement should be inferred.
Work on this registry 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, Dmitri Zagidulin, and Dan Burnett.
Group Notes are not endorsed by
W3C nor its Members.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
The
W3C Patent
Policy
does not carry any licensing requirements or commitments on this
document.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
2. Introduction
This section is non-normative.
This document serves as an official registry for all known global parameters,
properties, and values used by the Decentralized Identifier ecosystem.
3. The Registration Process
Software implementers might find that the existing Decentralized Identifier Core
specification [DID-CORE] is not entirely capable of addressing their use case
and might need to add a new parameters, properties, or values to this registry
in order to achieve their use case in a globally interoperable fashion. In order
to add a new parameter, property, or value to this registry, an implementer MUST
submit a modification request for this registry, as a pull request on the
repository where this registry is hosted, where the modification request adheres
to the following policies:
Any addition to the DID Core Registries MUST specify a human readable
description of the addition.
Any name or value of a property or parameter MUST be indicative of
its function. Avoid generic terms such as "myProperty" or "foo".
Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
If there are copyright, trademark, or any intellectual property rights
concerns, the addition and use MUST be authorized in writing by the intellectual
property rights holder under a
F/RAND
license. Examples include DID Methods that use trademarked brand names,
property names that utilize the titles of copyrighted works, and patented
technology that would cause the use of the extension to require licensing a
patent.
Any addition MUST NOT create unreasonable legal, security, moral, or privacy
issues that will result in direct harm to others. Examples of unacceptable
additions include any containing racist language, technologies used to
persecute minority populations, and unconsented pervasive tracking.
Any addition to the DID Core Registries MUST link, via at least a URL,
preferably a content-integrity protected one, to the defining specification so
that implementers can implement the property.
Any addition to the DID Core Registries that is a property or value, MUST
specify a machine readable JSON-LD Context for the addition.
The JSON-LD Context MUST be included in full as part of the submission.
A namespace URI MUST be provided for the JSON-LD Context so that consumer
implementations can consistently map a URI to the full context.
The URI provided MUST be persistent, and link all terms to their associated
human readable descriptions.
The URI provided SHOULD resolve or link to the full context contents.
JSON-LD Contexts MUST be versioned and MUST NOT be date stamped.
JSON-LD Contexts SHOULD use scoped terms and MUST use the @protected
feature to eliminate the possibility of term conflicts.
Properties in the DID Core Registries MUST NOT be removed, only deprecated.
The Editors of the DID Specification Registries MUST consider all of the
policies above when reviewing additions to the registry and MUST reject registry
entries if they violate any of the policies in this section. Entities
registering additions can challenge rejections first with the W3C DID Working
Group and then, if they are not satisfied with the outcome, with the W3C Staff.
W3C Staff need not be consulted on changes to the DID Specification Registries,
but do have the final authority on registry contents. This is to ensure that W3C
can adequately respond to time sensitive legal, privacy, security, moral, or
other pressing concerns without putting an undue operational burden on W3C
Staff.
Entries that are identified to cause interoperability problems MAY be marked as
such at the discretion of the maintainers of this registry, and if possible,
after consultation with the entry maintainer.
Any submission to the registries that meet all the criteria listed above will be
accepted for inclusion. These registries enumerate all known mechanisms that
meet a minimum bar, without choosing between them.
4. The Labeling Process
This section describes labels that are used to categorize registry entries.
Deprecated
This label is applied to registry entries that should not be relied on.
No Contact Info
This label is applied to registry entries for which no point of contact has been provided.
5. Property Names
The following section defines the properties available for use in a DID
document. Note that some of these properties are defined in the
DID Core Specification, and
others are defined elsewhere and may be method- or domain-specific. Please read
the associated specifications to ensure that the properties you use are
appropriate for your implementation. The properties are arranged here according
to the purpose they serve.
Issue
This registry is a work in progress and some properties are missing normative
definitions. We are working on this! This does NOT mean that in future it will
be possible to submit items to the registry without normative definitions (see 3. The Registration Process).
5.1 DID document properties
These properties are foundational to DID documents, and are expected to be
useful to all DID methods.
These properties are for use on a verification method object, in the value of
verificationMethod. An
implementer is expected to not be relying directly on the linked contexts
registered below in nearly every case and instead should be including the
context definitions registered by the
verificationMethod.
This property is deprecated in favor of publicKeyMultibase or
publicKeyJwk. It's generally expected that this term will still be
used in older suites and therefore needs be supported for legacy compatibility,
but is expected to not be used for newly defined suites.
This property is deprecated in favor of publicKeyMultibase or
publicKeyJwk. It's generally expected that this term will still be
used in older suites and therefore needs be supported for legacy compatibility,
but is expected to not be used for newly defined suites.
This property is deprecated in favor of blockchainAccountId. It's
generally expected that this term will still be used in older suites and
therefore needs be supported for legacy compatibility, but is expected to not be
used for newly defined suites.
These are values to be used for the type in a verification method object.
6.1.1 JsonWebKey2020
Do not include private or extraneous information in verification methods. The
class of private information related to JWKs is defined here. Please review
the DID Core
specification for additional details on this topic.
DID
Specification Registries Issue 370 This property should be moved into a
separate suite and linked to here rather than relying on the Verifiable
Credentials vocabulary. There are known issues with the first version of the
Security vocabulary JSON-LD context and the first version of the Verifiable
Credentials JSON-LD context which will prevent these contexts from being listed
in the same document. For now it's suggested that implementers rely upon the
first version of the Verifiable Credentials JSON-LD context and not rely on
the Security vocabulary JSON-LD context in the same document.
Example 54: A DID URL with a 'resource' DID parameter
did:foo:21tDAKCERh95uGgKbJNHYp?resource=true
13. DID Methods
This table summarizes the DID method specifications currently in development.
The links will be updated as subsequent Implementer’s Drafts are produced.
The normative requirements for DID method specifications can be found in
Decentralized Identifiers
v1.0: Methods [DID-CORE]. DID methods that do not meet these requirements
will not be accepted. We encourage DID method authors to provide an email
address in the Author Links column, as this helps with maintenance.
If an email address is omitted, a label noting that there is no
contact information for the author will be applied to the registry entry.