search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
326 stars 55 forks source link

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

Closed brentzundel closed 3 years ago

brentzundel commented 3 years ago

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:

Requested Links:

Further details:

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

atanassov commented 3 years ago

Thank you for filing the issue @brentzundel. Myself and @hadleybeeman started reviewing it during our Cork virtual f2f. The use cases and examples are much stronger and clear to follow compared to previous reviews. Before we close it we want to take the next couple of weeks and review at the technical details more closely. Provided we don't see any red flags we should be able to provide feedback to you before TPAC 2020.

brentzundel commented 3 years ago

That sounds wonderful, thank you!

lknik commented 3 years ago

Since there's no security/privacy questionnaire yet, I would kindly ask to compare the current status quo to the one with DID, including in terms of - what some stakeholders (i.e. government) may or may not do with this technology. Specifically, can this lead to fragmentation of the internet/web itself? If so, that would sound quite harmful to me.

It seems to me that specificity of the identifiers may be used to classify content, so perhaps even make content easier to block. Mandating this kind of technology would bring great responsibility to W3C. I hope that these problems will be sufficiently analysed.

A side question to the authors: can DIDs be used to deploy a China-style social credit system to the web? I'm simply worried what this may lead to, if not immediately than in the medium or long term. I do not think this is even limited to security/privacy issues, though.

It seems to be that the below innocuous use case scenario can be inverted to invite harm:

Sam is a long term immigrant to the United States who just received notice of Permanent Resident status from the United States Customs and Immigration Services (USCIS). Along with his notice is directions for downloading and using a digital version of his physical card, including a one-time activation code. After getting a digital wallet, he visits the USCIS website, signs in, and uses his activation code to get a digital credential. His wallet provides a DID to the website and demonstrates control over the DID to prove to USCIS that the identifier is under Sam's control. USCIS issues a newly minted digital credential with the subject identifier set to the provided DID.

Now, Sam can use that digital credential anywhere by demonstrating the same proof of control to provide a specific level of identity assurance, anchored in the cryptography of the proof-of-control ceremony. Verifiers of that credential can cryptographically verify both the authenticity and origin of the credential itself—it can be proven that it was issued by USCIS and unchanged since then—AND it can verify that the presenter of the credential still controls the identifier.

I believe this specification is triggering many human rights concerns.

brentzundel commented 3 years ago

We have completed the Security and Privacy Questionnaire; the link is here: https://docs.google.com/document/d/1c36r86oI7q4qv0YKVsu0zlNiMwWTqCfWWReAkg3gd2A/edit#

We look forward to hearing from you.

brentzundel commented 3 years ago

Pinging TAG again. We plan to transition to CR by the end of this month and would love to hear any feedback you may have for us.

LeaVerou commented 3 years ago

Initially, I was skeptical about the decision to use a colon (:) to separate the method name from the method-specific id. Since the colon has several different special meanings in URLs already, adding yet another separate meaning makes parsing harder, and increases the likelihood that old or carelessly written code will misparse these. However, after digging in a bit more, I was reminded that this syntax is consistent with URNs, so using colons is perfect for consistency.

Do note however that NIDs and NSSes in URNs (somewhat analogous to method names and method-specific ids here) are parsed as paths. Given that DIDs have a separate path component, how are they supposed to be parsed? Is <method-name>:<method-specific-id> part of the host (which is inconsistent with URNs), or part of the path (which means the actual path needs to be extracted manually)?

TomCJones commented 3 years ago

Right - it is impossible to parse a did w/o access to every single did method. That is execrable. Especially since it seems like some (did:web and did:indy) are infinitely extensible. BTW that has really nasty implication for discovery. That means that you cannot rationally discover if you support a method without dynamically scanning the current state of the method.

peacekeeper commented 3 years ago

@LeaVerou thanks for your feedback. As you note, URN syntax has been an inspiration for DID URL syntax. You are correct that NIDs and NSSes in URNs are parsed as paths, and the same is true for a DID's method-name and method-specific-id. Note that URNs actually also allow the / character. E.g.:

In order to get the "path starting with the first slash", a parser would have to manually support that, this is the case for both URN and DID URL syntax. I would agree that this may be a bit unintuitive and confuse badly written parsers, but it should be consistent and fully compliant with standard URI syntax.

Also see this comment in our corresponding issue for more details: https://github.com/w3c/did-core/issues/556#issuecomment-762984818.

peacekeeper commented 3 years ago

Right - it is impossible to parse a did w/o access to every single did method.

@TomCJones after thinking this through, I don't think this is correct. You can absolutely parse a DID into its method-name and method-specific-id components, without necessarily understanding the method-specific-id. The same is true for URNs, you can parse a URN into its components, without necessarily understanding the NSS (which BTW can also contain an arbitrary number of colons). See this part from RFC8141:

   Because the colon character (":") is used to separate "urn" from the
   NID and the NID from the NSS, it's tempting to think of the entire
   URN as being structured by colon characters and to assume that colons
   create a structure or hierarchy within the NSS portion of the URN.
   Such structure could be specified by a particular NID specification,
   but there is no implicit structure.  In a URN such as

      urn:example:apple:pear:plum:cherry

   the NSS string is "apple:pear:plum:cherry" as a whole, and there is
   no specific meaning to the colon characters within that NSS string
   unless such meaning is described in the specification of the
   "example" namespace.

This is very consistent with how additional colons in a DID's method-specific-id are understood, see this language in DID Core:

The meaning of colons in the method-specific-id is entirely method-specific. Colons might
be used by DID methods for establishing hierarchically partitioned namespaces, for
identifying specific instances or parts of the verifiable data registry, or for other purposes.
Implementers are advised to avoid assuming any meanings or behaviors associated with
a colon that are generically applicable to all DID methods.
atanassov commented 3 years ago

@rhiaro, @hadleybeeman and myself had another breakout to review the data model proposal for DID. At this point we feel that all of the initial major problems have been addressed (dependency on JSON-LD etc.). We remain interested in future of this work and its evolution, especially when it comes to integrations/interactions with browsers, UI and other user facing capabilities that might have impact to the overall Web architecture. We whish you luck in this endeavor and look forward to helping review the next parts of the design.

torgo commented 3 years ago

As discussed in today's TAG plenary call, we're closing this. Thanks for working with us.