Driver for /.well-known/did-configuration

[peacekeeper]

Add a driver that can resolve a domain name to a DID, using the /.well-known/did-configuration mechanism:

https://github.com/decentralized-identity/well-known/tree/master/did-configuration

Note that there's already a driver for resolving domain names to DIDs via DNS lookups:

https://github.com/decentralized-identity/universal-resolver/tree/master/drivers/dns https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/

[OR13]

How to handle the case of multiple linked DIDs?

unlike /.well-known/did which @awoie and UPort probably know more about.

/.well-known/did-configuration

returns a list of DIDs, and they are in theory equals, and may be of varying or identical methods.

Does the universal resolver, have a notion of returning many DID Documents for a single identifier?

Using .well-known/did, I can resolve did:web:example.com, which will return a single DID Document.

Using /.well-known/did-configuration I would get a list of dids, did:btcr:0..., did:sov:0...

I can imagine knowing i want a BTCR did, and wanting to ask the universal resolver to get me the btrc did for example.com if it exists.

Similarly for the other DID Methods.

[OR13]

we could use built in namepsacing / query strings to solve this...

did:web:example.com:btcr?index=0 -> did:btcr:0... -> didDoc

This would be a sort of mapping from DIDs in one method to DIDs in another, I'm sure this has been discussed elsewhere...

And it would involve updating the spec for did:web

A related query string support issue: https://github.com/decentralized-identity/universal-resolver/issues/42

[peacekeeper]

Does the universal resolver, have a notion of returning many DID Documents for a single identifier?

If you resolve a DID, then obviously it can return only a single DID Document. But if you resolve something else (like a domain name), then the UR can return whatever the spec defines, so in this case 1) a list of DIDs, which in turn can be resolved to a 2) list of DID Documents.

I wonder if the UR would by default return 1) or 2). We have been vaguely thinking about an input option called follow-redirect (https://w3c-ccg.github.io/did-resolution/#dereferencing-input-follow-redirect) that could instruct a resolver that if one identifier points to another identifier, it would automatically continue to resolve that. But we need to define the details of something like this a bit better.

[OR13]

sounds like the input option would be the best way of handling this.

From an API perspective, the UR should always try and to the least amount of work required to fufill the client request, encouraging the client o be more specific if needed.

I think the UR should return a list of DIDs by default for this case, with support for expanding them if requested.

Its also worth noting that while the list of DIDs would be fast, the resolve time for all of them to document might be really really really slow... worst case scenario, its hundreds or thousands of different DIDs with different methods.

[peacekeeper]

We revisited this on the 23 Jun 2021 Universal Resolver call, and realized that by now the Universal Resolver is about resolving DIDs, and nothing else. Looking up DIDs from domain names or web addresses can be done by other tools. Therefore we are closing this.