[wbs] response to 'Call for Review: Decentralized Identifier (DID) Working Group Charter'

The following answers have been successfully submitted to 'Call for Review:
Decentralized Identifier (DID) Working Group Charter' (Advisory Committee)
for Transmute by Orie Steele.


The reviewer's organization suggests changes to this Charter, and only
supports the proposal if the changes are adopted [Formal Objection].

Additional comments about the proposal:
   We would like to see the following changes to the Charter:

1. Place the DID Resolution specification on the Recommendation track.
2. Remove "Decentralized Identifier (DID) Method Specifications" from
deliverables.
3. Allow work on DID Core v2.0 and allow it to advance to Candidate
Recommendation (allowing class 4 changes based off of lessons learned
around media types and transformations made during the VCWG v2.0 work). 

Reasoning for Point 1.

To address previous formal objections, the working group needs to
demonstrate that the DID URL format can be implemented with sufficient
interoperability.

Some working group members have argued that this requires a single standard
DID Method that is mandatory to implement. Others have argued that defining
the URL format and resolution behavior is sufficient. 

We don’t believe the W3C is the correct place to standardize specific
methods, in much the same way that it is not the place to standardize web
servers.

We believe that, following in the spirit of HTTP, W3C can define URLs,
Dereferencing and Resolution, and relinquish the responsibility of
standardizing DID Methods to other organizations.

In particular we believe that Key Transparency (keytrans), Supply Chain
Integrity, Transparency, and Trust (scitt), Multiformats (multi) working
groups at IETF might be better places to standardize specific DID Methods,
due to the active participation of subject matter experts whose interest in
relevant use cases demonstrates optimal contribution to fit-for-purpose DID
methods.

Reasoning for Point 2.

In addition to Point 1’s reasoning:

Previous formal objections focused on several dimensions of the DID
specification including determining if “sufficient decentralization was
achieved” and “measuring the trade offs and cost for achieving
decentralization”... This included commentary on Proof of Work and Proof
of Stake, and their impact on the environment, securities laws, and
international trade related topics, including sanctions and political
acceptability.

Based on the discussions observed in community groups related to the
specification, and the dialog following the previous formal objections, it
is our assessment that W3C is not the correct venue to address these
political challenges, or the technologies underlying them.

We believe IETF might be a better venue to address some of these concerns,
evidenced by the recent interest in Detecting Unwanted Location Trackers
(https://datatracker.ietf.org/wg/dult/about/).

Reasoning for Point 3.

The previous version of the specification suffered from a charter that made
addressing media types very difficult, and resulted in inelegance when
relating the two core concepts related to decentralization objectives,
namely “decentralized urls” (identifiers for identities) and
“decentralized media types” (representations of identity documents).

This created an “abstract data model” that was only comprehensible
through the lens of JSON-LD and RDF.

We feel it will be necessary to make breaking changes to correct the
standard.


The reviewer's organization intends to participate in these groups:
   - Decentralized Identifier (DID) Working Group

The reviewer's organization:
   - intends to review drafts as they are published and send comments.
   - intends to develop experimental implementations and send experience
reports.
   - intends to develop products based on this work.
   - intends to apply this technology in our operations.


Comments about implementation schedule:
   We have implemented many DID methods, at this time, the ones we are
planing to maintain moving forward are `did:jwk` and `did:web`.
We previously implemented `did:key`, `did:ion` and `did:elem`, we don't
plan to maintain those implementations moving forward, due to
interoperability issues arising from the method design.



General comments:
   We have concerns regarding the interaction between media types and DID
URL Resolution and Dereferencing.

Specifically, we are concerned that the structure of dereferencing
currently requires clients to process fragments of the resolved identity
documents in order to obtain key material.

This prevents implementations from negotiating for key representations
using registered media types, for example:

-  application/jwk+json
-  application/cose-key
-  application/pgp-keys

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.

We envision resolution patterns of the following format:

REQUEST  URL --accept "content type" => 
RESPONSE URL "content type" data.

Where URL equivalence is defined according to
https://url.spec.whatwg.org/#url-equivalence

And where `exclude fragments` is set to true, in order to enable the
resolving software to fully handle the requested media types.

We believe that DID URLs of the form `did:example:123#key-42` that
dereference to JSON-LD "verification methods", with no defined media types
have significantly harmed the adoption of DID URLs. 

Requiring systems to understand `application/did+ld+json` as opposed to
`application/jwk+json`, or `application/json` has harmed adoption and led
to complex and non-interoperable client side processing of URL fragments.



Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/did-wg-2023/ until 2023-09-08.

 Regards,

 The Automatic WBS Mailer

Received on Thursday, 17 August 2023 21:06:05 UTC