Decentralized Identifier Extensions

Known Extensions for the Decentralized Identifier Ecosystem

W3C Group Note

More details about this document
This version:
https://www.w3.org/TR/2024/NOTE-did-spec-registries-20240831/
Latest published version:
https://www.w3.org/TR/did-spec-registries/
Latest editor's draft:
https://w3c.github.io/did-extensions/
History:
https://www.w3.org/standards/history/did-spec-registries/
Commit history
Editor:
Manu Sporny (Digital Bazaar)
Former editors:
Kyle Den Hartog (MATTR)
Michael Prorock (mesur.io)
Orie Steele (Transmute)
Author:
The Decentralized Identifier Working Group (W3C)
Feedback:
GitHub w3c/did-extensions (pull requests, new issue, open issues)
public-did-wg@w3.org with subject line [did-spec-registries] … message topic … (archives)
Related Documents
DID Core
DID Core Implementation Report
DID Use Cases and Requirements

Abstract

This document serves as a repository 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 repository is under active development and implementers are advised against using the repository unless they are directly involved with the W3C DID Working Group.

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

Portions of the work on this specification have been funded by the United States Department of Homeland Security's Science and Technology Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 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 repository 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.

This document was published by the Decentralized Identifier Working Group as a Group Note using the Note track.

This Group Note is endorsed by the Decentralized Identifier Working Group, but is not endorsed by W3C itself 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.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

This document serves as an official repository for all known global parameters, properties, and values used by the Decentralized Identifier ecosystem.

1.1 Conformance

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. 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 repository in order to achieve their use case in a globally interoperable fashion. In order to add a new parameter, property, or value to this repository, an implementer MUST submit a modification request for this repository, as a pull request on the repository where this repository is hosted, where the modification request adheres to the following policies:

  1. Any addition to the DID Extensions MUST specify a human readable description of the addition.
  2. Any name or value of a property or parameter MUST be indicative of its function. Avoid generic terms such as "myProperty" or "foo".
  3. Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
  4. 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.
  5. 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.
  6. Any addition to the DID Extensions MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementers can implement the property.
  7. Any addition to the DID Extensions 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.
  8. Properties in the DID Extensions 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 repository and MUST reject repository 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 repository 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 repository, 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.

3. Extensions

The following documents list known extensions to the DID Ecosystem:

Document Description
Property and Value Extensions Extensions to DID Document properties and values.
Resolution Extensions Extensions to DID Resolution parameters and results.
DID Methods Ephemeral, distributed, and fully decentralized mechanisms for supporting Decentralized Identifiers across a variety of technology platforms.

A. References

A.1 Normative references

[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174