Sarven: This is about the DID 1.1 release and they're highlighting the essential differences between 1.0 and 1.1. They don't go up to class 4 (i.e. no new features). There was some shuffling with some info between specs (DID, CID). I looked at the explainer and there was a commit message that mentioned it was written by an LLM and then edited by Manu. I flipped through it and it didn't say anything that was relevant to this design review. It didn't tell me what I should focus on. But there were links given in the review request to substantial isuses and their PRs, and that's what this review is.

Overall I am satisfied with it. They tried to address the objections. If you want me to summarize the changes, I can.

They're proposing application/did media type. From there, DID documents could also be interpreted as JSON or JSON-LD. It starts with being JSON, and you can have JSON-LD, and the difference is just the @context, as I understand it.

One issue Hadley pointed out, which turned into a PR. They have a new section about 'media type precision' that details what happens if a server uses a different media type, or one that's not recognized by the consumer, and what precision they need to work with. There are a bunch of steps there.

https://www.w3.org/TR/did-1.1/#media-type-precision

I think that addresses Hadley's comment about unknown media types. E.g. they detail, if you get text/plain what do you do?

Also, depending on the system DIDs may be passed around, from those native systems, like HTTP, they can handle unknown media types (e.g. via status code). This was a rabbit hole with fragment processing. What they've decided on is that they'll refer to CID's fragment resolution and re-use that. If the party that generates the data uses a different media type then they should be careful that the fragment is scoped to that media type.

The spec will only talk about application/did or some variant of that (with JSON and JSON-LD as core possible representations). Essentially it also mentions that if you use an HTML document, e.g., to serve a DID document, be mindful that the fragment is going to be of HTML and not one of the other formats. They're adding advisory info on this.

All in all this is aligned with WebArch.

They renamed JSON web key 2020 to Jsonwebkey - shuffled some other things around.

There may be some security/network issues that you may not be able to import context if you import context There's a good discussion on that in the PR. There seem to be a range of FUDs raised, but they're happy with the current direction.

Lastly, they've generalized a bit. CID is like a base spec.

They've shuffled around a lot of content. They are also making the point that because there were no new features added, everything still conforms, on paper. But I think in reality when you make these sorts of changes, implementers might struggle. I think they may need to be more careful about this.

The test suite implementation report was updated in 2023 - so there are no new statements of conformance (or intent to conform) to these changes.

Maybe that's not a TAG concern, but could be an AC concern.

DanA: None of that raises to the level of concern in your view?

Sarven: Happy to learn from you as to how TAG's scope is when it comes to these reviews. I don't think it's a concern in our scope, but it may be for the AC. Mentioning it so they think about it.

DanA: An example of the type of thing where we've put 'satisfied with concerns' is when we're happy with it, but only one browser is implementing it, or it's duplicating a feature from some other group.

Jeffrey: I think it's worth raising, when they go to REC, that they have interoperable implementations of 1.1, not just 1.0. That's not a TAG concern; it's a process concern, but worth us raising so they remember to do it. The only question you raise that I think is architectural is about the way they handle fragments. It's nearly right. But they say if there are two maps with the same ID field it's undefined, but HTML says it's the first one. So it may be on them to pick one, so that implementations are interoperable. It could be in the CID spec but they're copying from there. So I think we should say it but still be satisfied.

Sarven: If they consider anything outside of application/did or its variants not required for interop, then whatever happens in text/html happens in text/html - that's all in addition to taking media type precision into account - so I'm not sure if they need to have DID tick those boxes too - out of spec more likely.

Jeffrey: I didn't mean they should accept text/html docs, but rather that they should be consistent with fragment handling.

Sarven: They're saying adhere to HTML's fragment handling re fragments with media type scoping.

DanA: Is there something you'd recommend Jeffrey to change Sarven's bullet point 3?

Jeffrey: I would add a second sentence in the middle that we noticed that CID's fragment resolution leaves it undefined if there are multiple maps with the same ID field, but it would be better to define it for interop, so that when people write a bad document, it behaves consistently.

Sarven: They refer to CID resolution. From DIDs perspective is that something they need to add to the DID document?

Jeffrey: From a spec arrangement point of view, citing CID and not adding to it is the better thing to do.

DanA: Sarven, do you feel you could take something out of today's minutes and form a closing comment?

Sarven: Yes. If I can factor in Jeffrey's comment, I will. Do you want me to post an updated version in private brainstorming?

DanA: Considering we don't have a plenary I think it'd be better to just do it - and this does not seem contraversial.

Jeffrey: Yep.

DanA: I suggest we discourage LLMs for writing explainers.

Sarven: Explainer explainer

Jeffrey: I think the way they did it is one of the least offenisve ways it can be done - Manu reviewed it. The 'alternatives considered' section doesn't match what we'd expect, but this is an OK overview of DIDs in general.

Jeffrey: I've been reading about energy use and it seems to be that just using them doesn't use the main share of the energy; it's training them.

DanA: Yeah.

Jeffrey: Happy to review comment, but don't think I need to.

DanA: You have got the clearance to resolve it as 'satisfied'