Re: New proposal for the DID WG charter

For me, there is an element of timing to consider here.

We created DID methods because there are many ways to build the general
feature set of DIDs. We wanted to allow innovation to flourish, so we made
it easy to add another. The result has been exactly what we hoped, and I
don't regret the proliferation of methods in any way. For the early years
of DIDs, it was exactly the right thing. However, in the long run, I don't
believe that having hundreds of equally canonical ways to do DIDs is
optimal. Having a few (5? 10?) high-quality methods that deliberately make
different tradeoffs in important aspects of architecture or user experience
(with an unrestricted long tail to safeguard the possibility of future
innovation) seems like a better steady state for a mature version of the
technology.

Regarding the maturity of DIDs as a technology, we're definitely more
mature than we were 3 years ago, and implementation experience, the DID
rubric, Joe A's podcast, and other thoughtful conversations about them have
taught us a lot about how to evaluate tradeoffs. Some DID methods are
becoming less relevant, and I think that our community is becoming more
able to articulate why. However, my gut feeling is that we're still in an
early portion of the timeline. I think a lot of other DID folks have a
similar sense.

As a community, we never want to pick winners and losers. Market forces
will do that. But even so, when we evaluate interoperability strategies, I
think we should be thoughtful about the timeframe and maturity assumptions
of our goals, because the simple fact is that not all DID methods are
equally important. People should be able to use any DID method they like,
of course -- but they should also be forced to reckon with the
interoperability consequences of their choices. Giving an arbitrary DID to
an arbitrary, unknown party that's also using DIDs, with an expectation
that no interoperability impedance might arise, feels unrealistic and even
undesirable to me. Differences between DID methods often reflect important
ideological or market realities. If folks don't want to use technique X
because they don't like its cost or its latency or its centralization or
its privacy profile or its affiliation with crypto or its lack of
censorship resistance, whether those folks are in a tiny group or a massive
one is a relevant interoperability question. Should interoperability
initiatives hide such considerations from users -- or let them wrestle the
messy reality? My guess is that the optimal answer is somewhere in the
middle.

This is why I like Markus's proposal. It feels to me like it's doing some
concrete and useful things about interoperability, but it's patient and
realistic rather than overreaching. I think that's a good place to be, at
the current maturity of the technology.

On Tue, Oct 31, 2023 at 11:37 PM Jeffrey Yasskin <jyasskin@google.com>
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.
>
> Jeffrey
>
> On Tue, Oct 31, 2023 at 3:02 PM Chris Wilson <cwilso@google.com> wrote:
>
>> Hey Markus,
>> I'm cc'ing Jeffrey Yasskin, our alternate AC rep, as I am about to be out
>> on vacation for the next week and a half.
>>
>> I'm intrigued by the approach, but need to understand more about how this
>> affects pragmatic interoperability.  It seems like the approach you are
>> suggesting would enable an ecosystem that would be able to resolve DID
>> references even without each client needing to build in all the resolvers,
>> but perhaps I'm not clear on that point.
>>
>> -Chris
>>
>> On Sun, Oct 29, 2023 at 3:08 PM Markus Sabadello <markus@danubetech.com>
>> wrote:
>>
>>> Hello Chris,
>>>
>>> I think those of us who have worked on DID Resolution share your
>>> interest in increasing interoperability.
>>>
>>> We cannot and do not want to remove the abstraction layer that is
>>> inherent to DIDs via the DID method design.
>>> We have always believed that the fact that each DID method defines its
>>> CRUD operations in a different way (while using a standardized DID syntax
>>> and DID document format) is one of the most powerful features of DIDs.
>>>
>>> However, the DID Resolution draft defines an HTTP interface for
>>> resolving DIDs and dereferencing DID URLs.
>>> Using this interface, any client can talk to any resolver/dereferencer
>>> in exactly the same way, independent of the chosen DID method.
>>> So while DID Core defined this interface only in an abstract way, DID
>>> Resolution goes one step further by defining a concrete HTTP binding.
>>> I believe this would achieve the "practical interoperability" goal
>>> articulated at TPAC, would you agree?
>>>
>>> In addition, several other ideas have come up which the WG could perhaps
>>> explore:
>>> - A resolver can indicate to clients which DID methods it supports
>>> - A resolver can "forward" or "redirect" requests for unsupported DID
>>> methods to other resolvers (the current DID Resolution draft already
>>> mentions this)
>>>
>>> I'd be curious about your thoughts on this.
>>>
>>> all the best,
>>> Markus
>>> On 10/5/23 22:33, Chris Wilson wrote:
>>>
>>> I wanted to share our response here.
>>>
>>> We are still somewhat concerned, as we detailed in our support for this
>>> charter prior to these changes, that the group needs to focus on increasing
>>> interoperability. We did express that a sufficiently rigorous DID
>>> Resolution specification could achieve this goal, but the draft at
>>> https://w3c-ccg.github.io/did-resolution/ does not appear to be going
>>> in that direction and in fact adds a new dependency on unstandardized
>>> Method functionality (defining how to dereference a path and query).  While
>>> we don't formally object to these changes to the charter, we're concerned
>>> about them, and we might object to advancing this sort of DID Resolution
>>> spec to Recommendation if we believe it does not resolve our previous
>>> concerns with the interoperability goals.  We are happy to respond and give
>>> feedback on the goal of interoperability on the group's work along the way
>>> if that would be helpful.
>>>
>>> On Sat, Sep 30, 2023 at 11:40 AM Pierre-Antoine Champin <
>>> pierre-antoine@w3.org> wrote:
>>>
>>>> Dear all (DID WG + AC rep who voted on the charter proposal),
>>>>
>>>> you will find here :
>>>>      https://github.com/w3c/charter-drafts/pull/448
>>>>
>>>> a set of proposed changes on the DID charter proposal that take into
>>>> account most of the comments in the AC review and the discussions that
>>>> happened at TPAC (during the DID meeting, and after).
>>>>
>>>> Feel free to comment directly in the PR, or by responding to this email.
>>>>
>>>>     best
>>>>
>>>>