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

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

> 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 the purpose of this design review

I tried to do that in the opening paragraph with this text:

> This v1.1 revision does not allow any class 4 changes and the only substantive changes that have occurred since v1.0 have been...

The differences are very minimal, with the class 3 changes as the only significant changes to note (which were really not that significant). We're in a maintenance release and we're not changing much.

> perhaps some details on the changes relating to CID dependency and changes that go up to (and including) correction class 3.

The CID dependency was to "generalize" some parts of DID for a few people in the VCWG, the sections were largely lifted from the DID spec, placed into the CID spec, and editorial changes made to clean stuff up. From a normative standpoint, there shouldn't have been any changes to implementations (except for using the v1.1 DID Context). We tried to be very careful to ensure that this was just a re-arranging of specifications with no significant implementer changes.

>  I have however processed the class 3 change tagged issues you've linked to, and that has been useful in informing this review.

Good, because those are largely the ones we needed the TAG to review.

> * 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)? 

That is the expectation, yes. As you know, different media types can have different fragment processing rules and so we only define the rules for `application/did` and `application/cid` (both of which are JSON-based data formats, that can be interpreted using JSON-LD libraries, where the semantics between both documents MUST be the same). We don't say those rules apply to any other media type (because different media types can have different fragment processing rules). We try to be explicit about it in this algorithm:

https://www.w3.org/TR/cid-1.0/#retrieve-verification-method

and provide a NOTE at the bottom of that section (NOTE: Fragment identifier processing) that makes it clear that we're only talking about the fragment processing rules for the media types that we define.

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

They are allowed, but are out of scope; we don't define what they are. We wanted to allow other media types to be used for DID Documents, but can't define every single one that might appear in the wild. For example, CBOR encodings of DID Documents were of interest to some in the group, so the way we addressed that particular concern was to note that you have to be able to get back to a conforming `application/did` from your serialization, whatever that might be -- and we don't really care how you do it as long as the end result is a conformant `application/did` document.

> * 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)?

No, that behavior is undefined -- we only define fragment processing rules for the media types we define.

> 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/)?

We don't expect much re-familiarisation to be needed by implementers. Implementers can just change the `@context` value and everything else should continue to work. We will learn if this is true when implementers upgrade, but given the implementers we have in the group, none of them have raised any concerns about having to refamiliarize themselves or make significant changes to their implementations. 



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

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