Re: New proposal for the DID WG charter

Hello Jeffrey,

Thanks for your comments!

I think you are correct that requiring canonical https: resolver URLs 
for each DID method will probably not resonate with the DID community.
There are however some DID methods that do have such well-known, 
canonical resolver URLs, and there are also DID methods which have 
multiple resolver URLs that one can choose from.

I think it's in the nature of DIDs that very high levels of 
interoperability would automatically lead to lower levels of 
decentralization.
If we standardize an "official" set of DID methods that everybody in the 
world must support, we get perfect interoperability, but also reduce the 
decentralization inherent to the DID method design.
If we require all DID methods to designate canonical resolver URLs, we 
also get full interoperability, but introduce centralized services which 
the DID community wants to avoid.

I'd like to add that even if DID methods were left out of scope of this 
particular WG, some DID methods would still be likely to get 
standardized in various other places in the next few years. Quite a lot 
of DID methods are already being incubated in reputable organizations. 
Additionally, there are various applications, ecosystems, industries, 
use cases, etc. that do agree on limited sets of concrete DID methods 
which everyone within their scope must support.

So it seems what the DID community can offer is:

- Standard HTTP API for resolving DIDs.
- API to query the list of supported methods of a resolver.
- Redirect mechanism from one resolver to another resolver.
- Multiple independent implementations of popular DID methods, including 
test suites.
- Implementations that aim to support a large set of DID methods (e.g. 
DIF Universal Resolver).
- Documentation of existing applications and ecosystems that use a 
limited set of DID methods which every actor within that ecosystem knows 
how to resolve.
- List of well-known resolver URLs for some DID methods.

What the DID community apparently is not willing to do right now is:

- Standardize specific DID methods in the DID WG (but open to 
standardizing DID methods in other groups or orgs).
- Require canonical resolver URLs for all DID methods.
- A single endpoint or piece of code that is guaranteed to resolve all 
possible DIDs in existence.

I think your earlier point in this thread sums up the whole discussion 
really well:
"if a client (or resolver) receives a did: URL whose method it doesn't 
understand, what's it supposed to do?"

The honest answer is that - generally speaking - there is a possibility 
that the client will indeed not know what to do.

But we (the DID community) hope that the mechanisms and considerations 
in the first list above will still be considered sufficient to 
demonstrate the practical interoperability that we all want.

Markus

On 11/1/23 16:34, Jeffrey Yasskin wrote:
> Since https://www.w3.org/2002/09/wbs/33280/did-core-pr/results, Chris 
> and I have been suggesting that DIDs should match URLs in 
> standardizing some schemes at the same time as standardizing the URL 
> syntax. For DIDs, that would likely be the ones that are already being 
> used interoperably.
>
> Then, like with URLs, when a client receives a method it doesn't 
> support, and its developers look up the definition in the registry 
> <https://www.w3.org/TR/did-spec-registries/>, they can look at the 
> standardization status to figure out how stable and vetted the method 
> is. This can inform their decision of whether to implement or ask the 
> sender to send something different.
>
> The WG has proposed that standardizing resolution would serve the same 
> goals, but the existence of an HTTP API doesn't seem to give clients 
> the same options as standardizing some methods. If the registry 
> included canonical https: resolver URLs for each method, that would go 
> partway there, but I'm not sure it would serve the goals of the DID 
> community.
>
> Jeffrey
>
> On Wed, Nov 1, 2023 at 6:50 AM Robin Berjon <robin@berjon.com> wrote:
>
>     Hi Jeffrey,
>
>     On 31/10/2023 18:36, Jeffrey Yasskin wrote:
>     > A concrete question I have is "if a client (or resolver)
>     receives a did:
>     > URL whose method it doesn't understand, what's it supposed to
>     do?" I
>     > think we can practically expect interoperability among
>     non-standardized
>     > DID methods if there's a standardized algorithm to answer that
>     question.
>     > If the answer is, instead, "you need to just know the URL to a
>     resolver
>     > that understands the method", it's hard for me to expect that
>     software
>     > from different vendors will tend to be able to reliably exchange
>     did: URLs.
>
>     Do you mind clarifying a bit what your expectations are here? It's
>     not
>     obvious to me that the standard answer for a DID you don't know
>     how to
>     resolve ought to be anything other than some equivalent of 406 Not
>     Acceptable?
>
>     The DID space is whittling down and I expect it to whittle down
>     further.
>     It's a bit like image formats: we haven't really figured out a way to
>     have just one, once in a blue moon we introduce a new one, we
>     don't have
>     a wonderful way of managing unknown formats when they are introduced
>     (some exist, but they're provided at a separate layer like HTML or
>     HTTP). I would expect that we can get good enough interop from a
>     similar
>     arrangement. It won't be perfect, but it'll still be better than
>     what we
>     had pre-DID.
>
>
>     > On Sun, Oct 29, 2023 at 3:08 PM Markus Sabadello
>     > <markus@danubetech.com <mailto:markus@danubetech.com>> wrote:
>     >         - A resolver can indicate to clients which DID methods
>     it supports
>
>     This feels useful.
>
>     >         - A resolver can "forward" or "redirect" requests for
>     >         unsupported DID methods to other resolvers (the current DID
>     >         Resolution draft already mentions this)
>     I'm a lot less certain about the forwarding part of this. DID
>     resolution
>     could leak information, and having a resolver opaquely decide to
>     forward
>     strikes me as undesirable. Responding with a see-other list of
>     resolvers
>     it believes can handle it (as a form of redirect) seems better.
>
>     -- 
>     Robin Berjon (he/him)
>     Governance & Standards at Protocol Labs
>     https://berjon.com/ - https://bsky.app/profile/robin.berjon.com
>