Hey Chris,
Thanks for your comments here.
I share your concerns, part of our formal objection focused on the lack of
precision regarding URLs vs DID URLs:
> We would like to see the DID Resolution and Dereferencing Specification
and
> the DID Core specification updated simultaneously, in order to better
> support web standards, and rely less on JSON-LD and semantic web
> conventions.
- https://lists.w3.org/Archives/Public/public-new-work/2023Aug/0015.html
We're concerned that DIDs / DID URLs are being designed in a way that is
not compatible with or reinvents parts of HTTP (specifically resolution,
dereferencing and media types).
Essentially, DID Resolution and dereferencing is reinventing
https://www.w3.org/TR/json-ld11/#loading-documents ... but for a new kind
of URN, and with concrete support for only `+ld+json` based media types.
As the URL standard is now maintained at https://url.spec.whatwg.org and
HTTP is maintained at https://datatracker.ietf.org/wg/httpbis/about
It would be great to ensure that W3C does not charter work that contradicts
these standards since they provide building blocks that many implementers
might have otherwise leveraged.
Another point of contentiousness in the last working group was
serialization formats.
Some folks wanted to use conventions from IETF... others wanted to support
alternative ways of expressing key material
that have become popular in the blockchain / web3 community, while defining
the data model entirely in JSON-LD / RDF.
This led to `application/did+json` being exactly the same as
`application/did+ld+json` except with broken / non functional RDF interop.
I wonder if the charter might resolve this issue of serialization formats
before working group members get committed to working on an abstract data
model that is exclusively defined in RDF.
I'd be supportive of scoping the charter to only JSON-LD / RDF, I'd prefer
to not see the work chartered without consensus on doing 1 media type very
well, based on the last working group experience.
Do you have any thoughts on how we might leverage the charter to ensure the
working group can deliver better documents this time?
OS
On Thu, Oct 5, 2023 at 3:34 PM Chris Wilson <cwilso@google.com> 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
>>
>>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>