How do DIDs relate to (differ from?) other such distributed identifier attempts like DOI https://en.wikipedia.org/wiki/Digital_object_identifier or Handle System based identifiers in general? https://en.wikipedia.org/wiki/Handle_System

How do DIDs relate to (differ from?) other such distributed identifier attempts like DOI https://en.wikipedia.org/wiki/Digital_object_identifier or Handle System based identifiers in general?

Moar blockchain.

DIDs differ from earlier attempts like DOI in a couple of respects:

• Simplicity of representation (DIDs must resolve, and to fairly simple JSON objects)
• Emphasis on crypto public key material -- the /main/ purpose of DIDs is less to provide a permanent URN (though they do that too), but more to contain public key material (which can be used for authentication and proof of possession).

DIDs also serve as a unified URN scheme to be able to address into an arbitrary number of blockchains and other non-traditional-http sort of resources.

Discussed at London f2f. @hadleybeeman to write something.

Just got linked to this item... DID Spec isn't ready for review just yet. I thought we'd raise this w/ the TAG when the spec was ready (we're finalizing the CG version of the spec over the next month or two).

Here's a Primer on DIDs (that should answer some of @tantek's questions):

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/did-primer.md

There are 4 implementations of the spec in progress (Bitcoin, Ethereum, Sovrin, and Veres One). More information on Veres One here that gives more background on why these networks are being created:

Primer on Veres One: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/veres-one-primer.md

Primer on Veres One DID Method: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/veres-one-did-method.md

Background on Sovrin: https://sovrin.org/technology/

Background on uPort (Ethereum implementation): https://medium.com/uport/what-is-a-uport-identity-b790b065809c

Hi all. We've just caught up with this at our face-to-face in Seattle. We'll close the issue since you've said you're not ready, @msporny. Let us know if/when that changes.

Will do, thanks @hadleybeeman ...

Hey @hadleybeeman, just noticed you re-opened this... and based on TAG's "review early, please" request at W3C TPAC 2018, I guess we're ready for review (especially since we're going to ask for a DID WG in 2019). The reason that we've been hesitant to have a TAG review is because the spec isn't polished yet (implementations are speeding along, mostly aligned with the intent of the spec, although the details still need to be sorted -- and we were waiting for those details to be settled before asking for a review).

So, if TAG is okay with specs that are expected to be updated, then we're ok with having a review done. I suggest reading this first:

https://w3c-ccg.github.io/did-primer/

Then this:

https://w3c-ccg.github.io/did-wg-proposal/

Then the specification:

https://w3c-ccg.github.io/did-spec/

Pay particular attention to open issues and PRs to make sure you don't re-open issues that have already been identified:

https://github.com/w3c-ccg/did-spec/issues/

NOTE: This isn't the "official" request for review by the W3C Credentials Communtiy Group, but I expect that will be forthcoming after our next call.

/cc @jandrieu @ChristopherA @kimdhamilton

Thanks, @msporny! We've discussed it at length in our TAG face-to-face meeting in Paris.

Two questions to help us in our review:

1. We found ourselves struggling to work out what use cases you are trying to support. What is the user need? When would I need a DID, and what would I do with it? It would be useful for our review if you would produce an explainer. (We've produced a template, which might be useful). We didn't find those answers in your primer, since it starts from the explanation of what a DID is. We would really like to understand the need from a user's perspective, which already exists in daily life, written in clear non-technical language.

2. Also, does the group have or anticipate a mechanism for interoperability with current content loading? What relationship to HTTP do you envision? The question of whether DIDs are actually compatible with the web may be different depending on how they interact with HTTP. And if I were type a DID into a browser, application or user agent -- what would happen?

1. We found ourselves struggling to work out what use cases you are trying to support. What is the user need? When would I need a DID, and what would I do with it? It would be useful for our review if you would produce an explainer. (We've produced a template, which might be useful).

Yes, we can put this document together. What is the TAGs guidance where there are a very wide range of potential use cases? Would you rather see a specific one, or have us speak in generalities? A set of 2-3 use cases, or 10+ use cases?

For example, here's one for use of DIDs in the Corporate Identifier space:

https://docs.google.com/document/d/1wz8sakevXzO2OSMP341w7M2LjAMZfEQaTQEm_AOs3_Q/edit#heading=h.i145wu1x8b6x

... but that same document has some ones that are more exploratory than mainstream use cases:

https://docs.google.com/document/d/1wz8sakevXzO2OSMP341w7M2LjAMZfEQaTQEm_AOs3_Q/edit#heading=h.4dm04olljqqu

We also have a repository of 50+ papers written with Decentralized Identifiers in mind:

• Rebooting the Web of Trust I: San Francisco (November 2015)
• Rebooting the Web of Trust II: ID2020 (May 2016)
• Rebooting the Web of Trust III: San Francisco (October 2016)
• Rebooting the Web of Trust IV: Paris (April 2017)
• Rebooting the Web of Trust V: Boston (October 2017)
• Rebooting the Web of Trust VI: Santa Barbara (March 2018)
• Rebooting the Web of Trust VII: Toronto (September 2018)

I know that pouring through all of this documentation isn't what the TAG has in mind, so I'm trying to understand exactly what sort of summary you want to see (since the DID Primer didn't answer the questions you had wrt. use cases).

We didn't find those answers in your primer, since it starts from the explanation of what a DID is. We would really like to understand the need from a user's perspective, which already exists in daily life, written in clear non-technical language.

Yep, we can do this.

2. Also, does the group have or anticipate a mechanism for interoperability with current content loading?

If you mean "type the DID into the URL bar in a browser", then no, not at this moment. If you mean by anything that "lives on the Web", like server to server communication or in browser Javascript code that resolves DIDs via HTTP, then yes. I'm not certain I'm answering your question, though.

What relationship to HTTP do you envision?

HTTP may be used to:

• Resolve DIDs to DID documents (but not always).
• Provide new DID-based Authentication mechanisms
• Provide new DID-based Authorization mechanisms

Note that there is also work on using W3C WebAuthn+DIDs to do authentication via the browser.

The question of whether DIDs are actually compatible with the web may be different depending on how they interact with HTTP. And if I were type a DID into a browser, application or user agent -- what would happen?

The general consensus in the group is currently: If everyday people ever see or need to know about DIDs, we will have failed.

DIDs are expected to be used much like IP addresses or content hashes. Developers will use them to build systems, but they are not expected to be bubbled up in the application stack any further than that. So, we suggest that they are not something that you type or enter into a browser, user application, or user agent.

Did that answer your questions?

There is also a 1 hour introduction to DIDs (screencast) here: https://youtu.be/LkUkcoyksSI?t=226

Hi @msporny. Thanks for the quick reply!

We are keen to see you flesh out (and commit to) the use cases you are going to build for. This not only gives you room to explain the problem you are solving for your users and your logic in your architectural decisions (for example, why URLs? Why blockchains? etc). It also helps the rest of the web community understand what you're doing and sets expectations for we will all know when it's been accomplished.

What is the TAGs guidance where there are a very wide range of potential use cases? Would you rather see a specific one, or have us speak in generalities? A set of 2-3 use cases, or 10+ use cases?

Your choice. But making these specific and concrete may help you, for example, formulate your CR exit criteria or work out what dependencies you should have (or expect) from other parts of the web platform.

So... go for as many as make sense to you and the group.

The general consensus in the group is currently: If everyday people ever see or need to know about DIDs, we will have failed. DIDs are expected to be used much like IP addresses or content hashes. Developers will use them to build systems, but they are not expected to be bubbled up in the application stack any further than that. So, we suggest that they are not something that you type or enter into a browser, user application, or user agent.

Even if they are invisible to the user, I would expect that they still solve a problem for the user. For example, I as a user need my computer to communicate directly with a web server or another computer, to retrieve web content or to send an email. IP addresses make it possible for my computer to send traffic and content requests directly to the right server. They also make it possible for the routing between my computer and the server to be determined at request time, so that I (as the user) have a greater chance of getting my content quickly or my message delivered quickly. And they work with the DNS, so that I don't have to remember the numbers myself but can navigate my online experience with memorable names like google.com or nhs.uk.

As for HTTP, our question revolves around the protocol layer. When a DID is resolved or dereferenced... what happens? How is a look-up done? How do I as a user authenticate, or generate/request keys? What happens when I initiate some action in this ecosystem?

Your spec goes to great lengths to describe the DID document, for example, or the authentication credential field... but how are these passed around? How do clients and resolvers interact with them, and what do their APIs look like?

Hope that helps!

FWIW, I'd suggest starting with one user scenario and getting some feedback from non-DID folks that they find it coherent and meaningful, if not necessarily valuable to them, before proceeding.

For example, I personally would like to a see a use case contrasting a Veres One DID to an https URL of a machine-readable profile document. For example, maybe use TimBL's WebID, https://www.w3.org/People/Berners-Lee/card#i . Then explain specific software functions that could be performed or attacks that could be prevented if Tim used a did:v1: ID instead of that one. (And for completeness, also list any weaknesses or issues, such as perhaps if the v1-did would become useless if Tim lost his private key.)

@hadleybeeman: "type the DID into the URL bar in a browser":

http curl example for did:ipid:12D3KooWMHdrzcwpjbdrZs5GGqERAvcgqX3b5dpuPtPa9ot69yew

curl -s https://ipfs.io/api/v0/name/resolve?arg=12D3KooWMHdrzcwpjbdrZs5GGqERAvcgqX3b5dpuPtPa9ot69yew

{"Path":"/ipld/zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY"}

followed by:

curl -s https://ipfs.io/api/v0/dag/get?arg=zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY

{ "@context": { "/": "zdpuAqceEaefp2YLbsyVaoJk8NH47qJvomsd1WouNC1CVYTZn" }, "control": [ { "signer": [ "did:eth:0xd3382e07f2173270ef43817ab1b4e1cdeb36f23b", "did:sov:8uQhQMGzWxR8vw5P3UWH1j", "did:ipid:QmcEF77C6QKj6Rzru7MR2N5tSM33PHQYEqXYzQuVHHAvvv" ], "type": "OrControl" } ], "created": "2017-09-24T17:00:00Z", "id": "did:ipid:QmcEF77C6QKj6Rzru7MR2N5tSM33PHQYEqXYzQuVHHAvvv", "owner": [ { "curve": "ed25519", "expires": "2017-11-08T16:02:20Z", "id": "did:ipid:QmcEF77C6QKj6Rzru7MR2N5tSM33PHQYEqXYzQuVHHAvvv", "publicKeyBase64": "lji9qTtkCydxtez/bt1zdLxVMMbz4SzWvlqgOBmURoM=", "type": [ "CryptographicKey", "EdDsaPublicKey" ] }, { "expires": "2019-03-22T00:00:00Z", "id": "did:ipid:QmcEF77C6QKj6Rzru7MR2N5tSM33PHQYEqXYzQuVHHAvvv", "publicKeyPem": "----BEGIN PUBLIC KEY-----\r\nMIIBOgIBAAJBAKkbSUT9/Q2uBfGRau6/XJyZhcF5abo7b37I5hr3EmwGykdzyk8GSyJK3TOrjyl0sdJsGbFmgQaRyV\r\n-----END PUB", "type": [ "CryptographicKey", "RsaPublicKey" ] } ], "previous": { "/": "zdpuArY8PA81cxdoNqsP42xT5itMHi6savk7GReyaVxBoCgkv" }, "proof": "did:eth:0x37aea9fdc10874d4048806187cbf6325ee102018", "serviceEndPoints": [ { "didAuth": "/ip4/108.241.29.84/tcp/1265/ipfs/QmZTefe4V1KYwLUfhGVMMBbAkAa4E9vynzSNx5vPtrG4dv" }, { "didAuth": "/ip4/37.120.35.245/tcp/1265/ipfs/Qmcfd7YfViNyxa4LZ2ubrubKa2cPYzeL8pN9E7emPSAVk4" } ], "signature": { "created": "2016-02-08T16:02:20Z", "creator": "did:ipid:QmeJGfbW6bhapSfyjV5kDq5wt3h2g46Pwj15pJBVvy7jM3", "signatureValue": "IOmA4R7TfhkYTYW87z640O3GYFldw0yqie9Wl1kZ5OBYNAKOwG5uOsPRK8/2C4STOWF+83cMcbZ3CBMq2/gi25s=", "type": "ed25519Signature2017" }, "updated": "2018-07-09T02:41:00Z" }

also can validate that the same content ID:

curl -s https://ipfs.io/api/v0/dag/get\?arg\=zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY | ipfs dag put

zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY

Does not depend on any single provider, could also be done via localhost, Cloudflare's server or any other gateway that supports the method resolution.

https://ipfs.infura.io/api/v0/dag/get?arg=zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY

http://localhost:5001/api/v0/name/resolve?arg=12D3KooWMHdrzcwpjbdrZs5GGqERAvcgqX3b5dpuPtPa9ot69yew

http://localhost:5001/api/v0/dag/get?arg=zdpuAyyen4DeAzm2pvc3h9TP3qkCnYUYN1sa9kSu9Tcub1XoY

We are looking at this in our face-to-face in Reykjavik.

And thanks, @jonnycrunch -- this is a helpful start.

To conduct a review, we need to see a full spec, including these kinds of details. We also would like to see your completed Security and Privacy Questionnaire. And an explainer of what you're trying to accomplish, and expecially what use cases and user needs you're trying to meet.

(You can see our template for beginning a TAG review. This thread didn't begin that way, which is part of why this conversation has been disjointed.)

I hope that helps. We are looking forward to seeing the detail!

Coming back to this in our F2F in Tokyo. We're going to close this issue, since we haven't received sufficient information to conduct a review. We'd encourage the (now) working group to share with us any spec or design documents, including user needs and how it works with web technologies (as above) -- which we'd expect to see in the form of an explainer -- whenever they're ready.