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
>