search

w3c-ccg / did-spec

Please see README.md for latest version being developed by W3C DID WG.
https://w3c.github.io/did-core/
Other
124 stars 45 forks source link

What is protocol / port for DID document #114

Closed TomCJones closed 5 years ago

TomCJones commented 5 years ago

Maybe I just missed it, but I cannot see what the protocol or port for getting a DID document might be. Or is it XDI? I think the doc could be made a bit clearer. If it is obvious to the team, it is not to me.

peacekeeper commented 5 years ago

Hello Tom. Instead of thinking about a "protocol or port for getting a DID document" we rather think about "resolving a DID to a DID document". How this works is very different depending on the DID method. For example, to resolve a BTCR DID, this process involves reading from the Bitcoin blockchain. For a Veres One DID, the DID document can be retrieved with an HTTP GET call. And so on.

XDI is something else, it's a protocol for data sharing and messaging between services. A DID document can point to such an XDI service. In other words, you can use DID resolution (= different for every DID method, see above) to discover an XDI service and then talk to it. Other services can also be discovered from a DID (e.g. ActivityPub, OpenID Connect, XMPP, etc.)

If this answers your question, can you close this issue? Otherwise please feel free to ask more!

peacekeeper commented 5 years ago

You may also be interested in this webinar which explains DID resolution in more detail: http://ssimeetup.org/did-resolution-given-did-how-do-retrieve-document-markus-sabadello-webinar-13/

TomCJones commented 5 years ago

Thanks for the explanation. It helped a lot, but I would not like to see this closed without something like that explanation appear in the spec. Or at putting it in the registry doc and point to that from the DID spec.

While i will try to follow the resolution webinar, i suspect that more of the resolution spec needs to be formalized as the process used to get from the DID to the DID document seems to be missing a step where the registry points to a resolver. I only checked bitcoin, and that did not lead to a resolver, but to an english language description of a two step process. Somehow that gap needs to be spec'd. Is there an example that points to a resolver rather than to another spec?

I plan to write a few resolvers as well as a registry.

TomCJones commented 5 years ago

OK - I watched the video. It seems that most of the solutions proffered had about the same level of security as an Active-X control running on IE. That is, no security at all. All that is needed to subvert an entire user's implementation is the inclusion of one resolver that lies. I guess I will just go work with the DIF implementation. I still believe that more information is needed in the did-spec especially with regard to security challenges.

peacekeeper commented 5 years ago

We're actually planning to have a spec for did-resolution, separate from the "main" DID spec. This is where we can formalize how resolution works (but only the universal/generic aspects of DID resolution; everything that's method-specific should go into the respective DID method spec).

The W3C CCG currently maintains an informal list of known DID methods (did-method-registry). The CCG does NOT maintain or publish a list of resolver implementations. DIF is one organization that implements resolvers, but not the only one, anyone can implement resolvers.

With regards to security, resolvers can work in different ways. If you have a resolver that's operated by someone as a hosted service, or you have a resolver that talks to some externally hosted API, then you can probably NOT trust it; as you say it could lie. But if you run a resolver locally and it can connect directly to the target system (e.g. a Bitcoin full node), then you should be able to trust it more. These considerations will go into the DID resolution spec. This is also explained to some extent in the webinar.

TomCJones commented 5 years ago

I see no reason to trust code running on my machine more than code running on a well known service. That's the core falicy in the whole design of the DID.

peacekeeper commented 5 years ago

This is everyone's individual decision of course. If you don't trust code running on your machine (there may be good reasons for this!), then perhaps you should not trust your web browser or operating system either. Some would argue that certain code can be trusted more than other code. E.g. code that is open-source, documented, tested, reviewed, and governed by well-defined rules may be more trustable than proprietary binary code written and seen only by a single person in their basement.

You can also implement your own DID resolver based on the open specs.

In any case, this is not a fallacy of DIDs per se, and getting a bit off-topic.

msporny commented 5 years ago

I see no reason to trust code running on my machine more than code running on a well known service. That's the core falicy in the whole design of the DID.

If you're not going to trust the software running on a system that you have control over and can audit, then there is no solution that is going to work for you (or anyone else that takes this position). This last comment by you, @TomCJones, is borderline trolling and if the dialog isn't going to include constructive suggestions and changes to the specification, we'll have to close this issue.

That said, I'm assuming your last statement was hyperbolic and I'm trying to look for something actionable in this thread. I think it is:

TomCJones commented 5 years ago

Thanks, that's just what I asked for. BTW, my last comment was merely a restatement of the first law of computer security. Since this is an extensible design, I believe you need to take it seriously.. https://tcwiki.azurewebsites.net/index.php?title=Laws_of_Security

TomCJones commented 5 years ago

i give up