#1029: Final Review Request of seven (7) W3C VCWG Specifications

Visit on Github.

Opened Dec 15, 2024

The W3C VCWG is requesting a final horizontal review of the following specifications, which your group has reviewed previous versions of over the past year or more.

We are requesting this before proceeding to the Proposed Recommendation phase based on a request by W3M to ensure that changes that have been made in the past six months are reviewed by your group since your last review. We are planning to enter the Proposed Recommendation phase for all seven (7) documents in Q1 2025 (roughly February, if possible).

Further details:

There are no major unresolved issues or opposition to these specifications that we know of at the present time.

Discussions

Log in to see TAG-private discussions.

Comment by @hadleybeeman Jan 8, 2025 (See Github)

Hi @msporny, @brentzundel, @iherman, @Wind4Greg, @selfissued, @decentralgabe and @dmitrizagidulin,

Thanks for this. Could you please give us a rundown of any architectural changes that have been made in the past six months?

Comment by @msporny Jan 8, 2025 (See Github)

Could you please give us a rundown of any architectural changes that have been made in the past six months?

Yes, happy to -- the changes since the First Candidate Recommendation for each specification are directly linked to via the initial issue via the "Changes since Candidate Recommendation" link:

https://github.com/w3ctag/design-reviews/issues/1029#issue-2740828699

Discussed Jan 20, 2025 (See Github)

Matthew: there are change logs for some of them... most of them small changes... appreciate the sentiment about whether we are an HR group or not. We could I guess not comment...

Amy: they did list change log links in the original question... but high level summary would be more useful

Matthew: JOSE and COSE one is just commits but the other ones all have a revision history...

Hadley: wanted the architectural highlights ... different than a change log having the diff between versions...

Matthew: APA was asked the same thing (in HR) we do have an expert... I can ping them to see if they've looked at it... because APA is looking into it I can see if I can figure out what out of the revision notes if there are architectural items...

we discuss TAG's role in HR - fodder for Dan's preparing a PR against the HR page

Amy: We've not really socialised widely that we're not a HR group... this group has felt blocked by TAG review before so declining might be confusing

Dan: it's appropriate for us to be involved in HR in some situations

Yves: HR better at the early design stage than at the verification / CR stage

Hadley: Jeffrey and I met with this group in TPAC and I told them that this has been an issue for us - getting large specs at the end of the process is less helpful for us and we can be less helpful. Ivan said that's not what the process says. If we decline to review we can do it in a way that says it doesn't make sense for us to get involved in this stage

Sarven: presume it's not all or nothing? If there's even one spec that would benefit from a review we can do it?

Dan: this is why they need to give us a better prompt about what might be architecturally significant for the TAG to review. We don't have the bandwidth to review all the changes to every single spec. We should not be considered part of the exhaustive horizontal review category. We tend to like to do reviews at the beginning of work where we can have more impact.

Discussed Jan 27, 2025 (See Github)

Matthew: I had a look at this... Summarizing: we've established that on the technical side of things we trust these people are the experts... We can go with their view that some of the changes are editorial. In their readable change log... there are several changes that need some further look or clarification... and one of the docs doesn't have a human readable change log... and I think we should ask for a human written one. The good news is - when looking across the 7 documents, there are 3 or 4 changes common to almost all of them... So actually less work than we thought. So +1 to Hadley that it would help to have some clarification on some of these... I'll put in my comment before the plenary what those are. They have provided ... some info .. but still not clear what the implications of some of the changes are...

we agree to re-visit at the plenary

discussion on adding WCAG citation to respec bibliograpgy

Discussed Jan 27, 2025 (See Github)

Matthew: some input... APA has looked at this ... and have had some opinions relating to which bits relate to accessibility. By breakout C I will have further input.

deferred to breakout C

Discussed Feb 3, 2025 (See Github)

Hadley: [reviews last week's discussion] Conclusion: we decided we needed Marcos's input. Matthew: I'll assign him and ask him for his input. Hadley: If it's possible to feed in before the plenary, that would be amazing. Quick turnaround though.

Look at the plenary.

Discussed Feb 10, 2025 (See Github)

we agree we need Marcos's input

Discussed Feb 24, 2025 (See Github)

Hadley: we are waiting for Marcos's feedback...

Jeffrey: he said he would have a chance to look at this in a couple weeks... I will poke.

Yves: giving a deadline... saying we have a f2f and will give an update after that...

Dan: Would prefer to close this before Paris.

Jeffrey: I think it's ready enough...

Comment by @marcoscaceres Mar 6, 2025 (See Github)

@msporny, any reason why the mime type is lacking +json?

Comment by @msporny Mar 7, 2025 (See Github)

@marcoscaceres wrote:

@msporny, any reason why the mime type is lacking +json?

Grab your tissues, my friend, because this is going to be a really sad story with an unsatisfying end. :P

Yes, the topic of using a structured suffix came up 5+ years ago when some of us tried to register application/did+ld+json, which resulted in a: "That's legal, but we don't know what it means to have multiple plus signs." from the Designated Experts at IETF. That sent both the W3C DIDWG and VCWG on a side quest at IETF to determine if "+ld+json" was allowable as a suffix since the data model was JSON-LD and the media type for JSON-LD is application/ld+json... so, obviously, if a media type used JSON-LD as a format, the base media type would just add "+ld+json", right?

At the time, we thought we could just keep adding plus signs because RFC6838 allowed it syntactically... and we thought it was ok since, for JSON-LD, we were just asked to add +json to the base media type (application/ld) to state that the format was JSON... but then when we tried to repeat that pattern for application/did by doing application/did+ld+json the DEs were like: Hmm, no idea what that means.

So, the IETF MEDIAMAN WG was chartered to answer that question and after years of discussion at W3C and IETF, we landed on this spec (which tried to explain the rules behind using multiple plus signs):

https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-05.html

...and after more years of grueling debate at the IETF, the result was (consensus through exhaustion) to NOT allow the use of multiple structured suffixes, which resulted in this spec:

https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-08.html

... which is being rolled into RFC6838bis as we speak.

The side-effect of that decision meant that if we added "+json", we couldn't add any other sort of suffix in the future, and we already knew that people wanted to add other suffixes (like "+sd-jwt", or "+cborld"). So, the WG was like "We now hate suffixes because they've caused us nothing but pain over 5+ years AND because we know that we want to do +sd-jwt at some point and we're only allowed one plus sign now."... so we picked a media type that had no plus signs so this issue wouldn't bite future VCWGs or DIDWGs when they (inevitably) extended the media type.

Like I said, sad story with an unsatisfying ending.

In order to salvage something positive from all of that, we are thinking of creating an off-broadway musical inspired by these events... working titles are currently "MIME and Punishment", "The Forbidden Plus", or "Cat+as+trophe". We'd bring the cast of Cats back for that last one, obviously.

Comment by @marcoscaceres Mar 14, 2025 (See Github)

Lol, ok. I want a role in this musical tho, or there will be a 🥁🎶 FoOOoormAAlll ObjeCCCttion 🥁.

Ok, so seeing you've suffered enough, I don't have any further comments.

Comment by @msporny Mar 14, 2025 (See Github)

I want a role in this musical tho

Done.

🥁🎶 FoOOoormAAlll ObjeCCCttion 🥁

Looks like we're gonna need the entire cast of Hamilton, too.

so seeing you've suffered enough, I don't have any further comments.

Thank you, kind sir, this act of compassion will not soon be forgotten.

Discussed Mar 17, 2025 (See Github)

Marcos: closing it, and close #899 Securing Verifiable Credentials using JOSE and COSE as well

Comment by @marcoscaceres Mar 19, 2025 (See Github)

Closing as satisfied.

Comment by @marcoscaceres Mar 19, 2025 (See Github)

@msporny, what's the relationship of this issue to https://github.com/w3ctag/design-reviews/issues/899 ? (hehe, yes, do my job for me)

Comment by @msporny Mar 19, 2025 (See Github)

@msporny, what's the relationship of this issue to #899 ?

#899 predates the request to review Securing Verifiable Credentials using JOSE and COSE in this issue. IOW, #899 is a duplicate of this issue and the satisfaction of this review, IMHO, closes #899 as well. I see you came to the same conclusion in #899, so I think we're good here (no further action from TAG necessary).

(hehe, yes, do my job for me)

I'll take it out of your positive karma balance... your remaining balance is around a trillion karma points. :)