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