Re: New proposal for the DID WG charter

One of the ideas that came from DW was that of federations of methods. I
believe he was chair of the DIF wg at about that time. Perhaps it is time
to restart the idea of a federation (with a trust anchor) that publishes
lists of well-known dids. This could be similar to the list of well-known
CAs that is maintained based on the CA|B governance rules. I could try to
reassemble the docs from that time (about two years ago now) to restart the
discussions. Presumably this could be based on the evolving federations std
from OIDC.

Hopefully ..tom


On Sat, Nov 4, 2023 at 2:35 PM Markus Sabadello <markus@danubetech.com>
wrote:

> 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
>>
>