Re: [w3ctag/design-reviews] Horizontal Review of Decentralized Identifiers v1.1 (Issue #1086)

csarven left a comment (w3ctag/design-reviews#1086)

Thanks, Manu and the DID WG, for requesting the TAG's review.

Aside: We note that the [explainer was generated by an LLM](https://github.com/w3c/did/commit/1c0363c93671d63030092d2984870cfd79819a78). While I have looked at the explainer you have provided, I must admit that I did not read it thoroughly since it was a general explanation of DID 1.1, whereas I think it would've been more useful to highlight the differences between DID 1.0 and DID 1.1 for tor the purpose of this design review, or perhaps some details on the changes relating to CID dependency and changes that go up to (and including) correction class 3. I have however processed the class 3 change tagged issues you've linked to, and that has been useful in informing this review.

---

We appreciate that detailed consideration was given to correction class 3 changes, in particular:

* consolidating media types to `application/did`.
* providing guidance on media type precision, including steps to determine whether a payload also conforms to a higher-precision media type when it is acceptable, as well as guidance on appropriate handling of unknown media types in a given system, e.g., HTTP 415, and acknowledging that lower-precision or "wrong" media types are common.
* the fragment processing rules for `application/did` are adopted from CID 1.0, and are consistent with media type scoped resolution rules. If the understanding is that DID 1.1's fragment resolution explicitly adopts CID 1.0's algorithm, then does that mean that regardless of whether the DID document is served as `application/did`, `application/did+json`, or `application/did+ld+json`, they all must follow CID's fragment resolution rules (as extended by DID 1.1)? On a related matter, is the understanding that DID documents served with media types other than the ones it describes are considered to be out of spec behaviour? If so, does this imply that the fragment processing rules of those other media types should not apply, from the perspective of intended interoperability (except when applying the highest-precision media type as per spec)?
* efforts towards alignment with VC specs with respect to `JsonWebKey`.
* not using imported contexts, in response to security concerns raised to the group.
* efforts towards using CID as the base specification and generalising DID without breaking existing conformance.

---

This (and the other items noted in the Revision History) seems like solid progress toward a 1.1 release. From what I understand, there has been significant shuffling of specifications and features to address concerns and further stabilise the work. I suspect that a substantive amount of re-familiarisation may be required by implementers. Is this already happening, and has it been [captured in the implementation reports or planned for](https://w3c.github.io/did-test-suite/)?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1086#issuecomment-2883903081
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1086/2883903081@github.com>