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