Decentralized Identifier Working Group Charter
URL-based identifiers (URIs) in use on the Web today (2019) require that the identifier be leased from an authority such as a Domain Name Registrar. A Decentralized Identifier (DID) is an identifier that does not need to be leased; its creation and use is possible without a central authority to manage it. The advent of Blockchains and Decentralized Ledger Technologies have led to other innovations that support this new type of decentralized URI. DIDs have various benefits over more traditional URIs:
- DIDs are controlled by individuals, organizations, and machines.
- DIDs enable cryptographic authentication of a DID controller (e.g., DID-based website login using a WebAuthn/FIDO token).
- DIDs provide discovery information for bootstrapping into secure and privacy preserving communication protocols (e.g., encrypted messaging endpoints).
- DIDs provide a path to service-agnostic data portability (including, but not limited to, switching between Verifiable Credential digital wallet providers).
W3C Members that would like to learn more about the motivations that led to this work may find the Primer for Decentralized Identifiers useful. There are also a set of Decentralized Identifier Use Cases that have been curated by the various organizations implementing and deploying this technology in commercial environments, resulting in a set of requirements to guide this work. Finally, there are a set of Self-Sovereign Identity Principles that have influenced the direction of this work.
The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.
|Start date||30 September 2019|
|End date||31 March 2023|
Daniel Burnett (W3C Invited Expert)
Brent Zundel (Avast)
|Team Contact||Pierre-Antoine Champin (0.1 FTE)|
Teleconferences: 1-hour calls will be held weekly
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.
The design approach for the DID specification is the same as the URI specification (RFC 3986). RFC 3986 defines the generic syntax for URIs, and all URI schemes are separate specifications. In fact, the DID specification is a conformant URI scheme. The goal of the DID specification is to do exactly the same for DIDs, that is, for this Working Group to define the generic DID specification, and then for others to define DID Method specifications.
The Working Group will:
- Define the DID URI scheme.
- Recommend a data model and syntax(es) for the expression of Decentralized Identifier Documents, including one or more core vocabularies.
- Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications.
- Provide a rubric of decentralized characteristics for DID Method specifications. This allows the DID Method specifications to self-certify, or independent third parties to evaluate, the DID Method specification's level of adherence to principles of decentralization.
- Concentrate their efforts on the initial use cases with a particular focus on enabling future specification and implementation of Identity and Access Management. Use cases from other industries may be included if there is significant industry participation.
- Define extension points enabling authentication, signing and cryptography mechanisms, but not defining specific authentication, signing, or cryptography mechanisms. (See "Out of Scope".)
- With the initial use cases document as input, the WG will produce a NOTE at the end of the process that is a refined Use Cases document.
- Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.
Out of Scope
The following features and topics are out of scope and will not be addressed by this Working Group.
- Authentication or Authorization Protocols
- Browser APIs
- Specific DID Method specifications or Protocol specifications
- "Solving Identity" on the Web
- Defining specific authentication, signing, or cryptography mechanisms. Scope is limited to defining extension points for these mechanisms. (See "Scope".)
In order to advance to Proposed Recommendation, each specification will fulfill the implementation experience required by the W3C Process as follows:
- The Working Group will seek evidence of independent interoperable uses of the DID syntax and data model from at least two independent implementations of each feature defined in the specification.
- The group will add a section detailing any known security or privacy implications for implementers, Web authors, and end users.
- The group will maintain and advance a test suite enabling interoperability testing, which will ensure the deterministic production and consumption of DIDs (URI syntax) and DID Documents (data model).
More detailed milestones and updated publication schedules are available on the group publication status page.
The Decentralized Identifier Working Group will deliver the following W3C normative specifications:
- Decentralized Identifiers v1.0
Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may express cryptographic material, verification methods, and/or service endpoints. These provide a set of mechanisms which enable a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject. This document specifies a common data model, format, and operations that all DIDs support.
The Credentials Community Group has developed a Final Community Group Specification for Decentralized Identifiers that has been shipped in multiple production-grade commercial systems that will serve as input for this document.
Note that the WG may decide, based on editorial and readability considerations, to spin off sections into separate Recommendations.
Other non-normative documents may be created such as:
- Decentralized Identifier Use Cases v1.0
The Working Group will develop a set of use cases and requirements to underpin its work. Abstract use cases will be supported by real world evidence of applicability. The Credentials Community Group has developed a set of initial use cases and requirements that will serve as input for this document.
- Decentralized Characteristics Rubric v1.0
The Working Group will develop a rubric of decentralized characteristics for DID Method specifications. This rubric will provide reference points according to which a DID Method specification may self-certify, or an independent third party may evaluate, the DID Method specification's level of adherence to principles of decentralization.
- Test Suite and Implementation Report
The Working Group will develop a test suite and implementation report to test and document conformance levels achieved by implementors.
|Note: The group will document significant changes from this initial schedule on the group home page.|
|Decentralized Identifier Use Cases & Requirements (NOTE)||November 2019||August 2021|
|Decentralized Characteristics Rubric (NOTE)||December 2019||September 2021|
|Decentralized Identifiers Data Model and Syntax(es)||November 2019||November 2020||July 2021||August 2021|
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and at least 3 months before CR, and should be issued when major changes occur in a specification.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
- Credentials Community Group
- Coordination on other specifications related to Decentralized Identifiers.
- JSON-LD Working Group
- Coordination to ensure that the JSON-LD syntax meets the DID Working Group's needs.
- Web Authentication Working Group
- Coordination to ensure that Web Authentication primitives, such as public keys, can be expressed in DID Documents.
To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
W3C Members are invited to join this Working Group. Individuals who wish to participate as Invited Experts (i.e., they do not represent a W3C Member) should refer to the policy for approval of Invited Experts. The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Decentralized Identifier Working Group home page.
Most Decentralized Identifier Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on the public mailing list firstname.lastname@example.org ( archive) or on GitHub issues (and specification-specific GitHub repositories and issue trackers). The public is invited to review, discuss and contribute to this work.
The group will publish minutes for each teleconference at https://github.com/w3c/did-wg/Meeting/Minutes/.
This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.
This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
This Working Group will use the W3C Software and Document license for all its deliverables.
About this Charter
This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):
|Charter Period||Start Date||End Date||Changes|
|Initial Charter||September 2019||September 2021||none|
|Initial Charter||September 2019||September 2021||Changed an erroneous link to the publication status page (Ivan Herman, 2020-01-24)|
|Update||Daniel Burnett re-appointed as group co-Chair (Xueyuan Jia, 2020-07-24)|
|Rechartered||15 December 2020||September 2021||New Patent Policy|
|Update||June 2021||September 2021||FTE value update for staff contact: 0.2 reduced to 0.15|
|Extension||1 October 2021||31 December 2021||none|
|Extension||31 December 2021||30 June 2022||none|
|Update||January 2022||Added Pierre-Antoine Champin as staff contact|
|Extension||30 June 2022||31 December 2022||none|
|Update||19 July 2022||(1) Brent Zundel's affiliation changed to Avast; (2) Ivan Herman is no longer staff contact (Ivan Herman, 2022-07-10)|
|Extension||15 December 2022||31 March 2023||none|