#556: Review Request - Decentralized Identifiers (DIDs) v1.0

Visit on Github.

Opened Sep 15, 2020

Saluton TAG!

I'm requesting a TAG review of Decentralized Identifiers (DIDs) v1.0.

A decentralized identifier, or DID, is a new URI scheme. Unlike existing HTTP URLs, email addresses, commercial account identifiers, most government identifiers, etc., the DID is purpose-designed to support cryptographically-controlled identifiers backed by decentralized oracles (such as a distributed ledger).

Syntactically, a DID looks like this: did:btcr:xyv2-xzpq-q9wa-p7t.

The three parts of a DID, separated by colons, are:

  • The string “did”, representing the did URI scheme.
  • A DID Method, in this case btcr, that must be one of the values in the DID Method Registry
  • A string that is interpreted according to the rules of the specific DID method, in this case xyv2-xzpq-q9wa-p7t.

Requested Links:

Further details:

  • I have reviewed the TAG's API Design Principles

  • Relevant time constraints or deadlines: We are planning to request transition to Candidate Recommendation after TPAC 2020.

  • The group where the work on this specification is currently being done: https://www.w3.org/2019/did-wg/

  • Major unresolved issues with or opposition to this specification: We are wrapping up some issues that were contentious, but they are not expected to remain unresolved.

  • This work is being funded by: The member organizations of the group members.

    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 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 specification has also been supported by the Rebooting the Web of Trust community.

You should also know that we are not seeking feedback on any particular part of the specification. We look forward to receiving general feedback from you, but this specification does not define any new web APIs nor add requirements to any browser vendors. We understand that you may, therefore, have less feedback for us than for other work.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback


Discussions

2021-01-11

Minutes

Hadley: we're still missing - the explainer not phrased in the context of user needs. Lukash brought up security issues - they have now filled out the s&p questionnaire. They've done a good job - thoughtful response. Also highlights how the s&p questionnaire is browser centric. They have left feedback on what we "should have asked." Amy what do you think?

Amy: There are a lot of people in the group who care deeply about security & privacy. They are hoping to get to CR by end of the month. Ths spec has had a bunch more editorial restructuring. A couple of concentious issues about privacy in the group. That said it is just a data model. The issues people raise are at other levels in the spec. Thet group is trying to cover as many bases as possible.

Hadley: Having the data model in front us ... Any other issues from a TAG PoV.

Amy: I can take the feedback on the explainer back to the group.

Rossen: I'd like to complete the proces...

Lea: I'm worried the action separated by a colon. There is alot of JS code that assumes - incorrectly - that it parses a URL that way. Wondering if that would break existing code. Using another character instead of a colon would solve the drawbacks.

Hadley: sounds reasonable.

Rossen: a break-out of the breakout. For one more end-to-end.