DID Method discovery mechanism requirement

[msporny]

@gklyne wrote:

maybe every DID service should have an associated DID document, which among other things connects the method name to its service access point(s), complete with cryptographic verification content. This document could in turn be served by any and/or all DID services. In this respect, the various DID services might function like multiple DNS root servers, and starting from any one of them, the others are discoverable. This is not a thought-out proposal, and is probably shot through with holes, but I offer it for consideration (or not!).

[msporny]

We had considered doing this a while ago. If I remember the conversation correctly, DID Resolver implementers pushed back and would rather have it in code than dereference a document to discover the DID methods. The latter increases implementation burden, may create potential attack vectors and it doesn't help the DID Resolver if there is no known way to talk w/ the DID Method network.

We could always make the registry referenced above machine-readable, but it's not clear it would be beneficial as a whole because:

• It increases implementation burden,
• It possibly creates a new attack vector (from a security standpoint - e.g. providing a document that contains spam/injection attacks),
• It enables DID Methods to censure other DID Methods by not listing them
• There are no "service access points" since these are decentralized networks. You connect to the node closest to you, or the one you trust the most, or some other metric that's important to you... and then bootstrap into the network from there.

[gklyne]

Ack. It was just a thought :)

Close?

[msporny]

Close?

Let's let this hang out there for a few weeks to get other feedback before closing. It is possible that I missed something.

[peacekeeper]

Related to https://github.com/w3c-ccg/did-resolution/issues/26 and https://github.com/w3c-ccg/did-spec/issues/198.

[jandrieu]

Closing as we have adopted this issue in the new DIDWG repo.