Re: [w3ctag/design-reviews] Review Decentralized identifiers (DIDs) (#216)

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!



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/216#issuecomment-434744284