Draft
This is a proposed charter for a Decentralized Identifier Working Group, currently undergoing development by the W3C Credentials Community Group; this is the development version.
It is available on GitHub.
You may raise issues on this document issues to help further discussion.
Items (mostly URLs), that will need updates if and when the charter is accepted, are marked thusly.
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 | September 2019 |
|---|---|
| End date | September 2021 |
| Chairs |
TBD TBD |
| Team Contacts | TBD (0.2 FTE) |
| Meeting Schedule |
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. |
Scope
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.
- Recommend 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".)
Success Criteria
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).
Deliverables
More detailed milestones and updated publication schedules are available on the group publication status page.
Normative Specifications
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 Deliverables
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.
Timeline
| Note: The group will document significant changes from this initial schedule on the group home page. | ||||||
| Specification | FPWD | CR | PR | Rec | ||
|---|---|---|---|---|---|---|
| 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 | ||
Coordination
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:
W3C Groups
- 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.
Participation
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.
Communication
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 public-did-wg@w3.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/.
Decision Policy
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.
Patent Policy
This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). 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.
Licensing
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.