Change the registration request for SD-JWT

[OR13]

Its been suggested that application/vc+ld+json+sd-jwt is not worth registering, see:

https://github.com/w3c/vc-jose-cose-test-suite/issues/8

We would need to request registration of some other typ value, to comply with the JWT BCP.

Perhaps application/vc-ld-json+sd-jwt

[TallTed]

As I've said in many other places, SD-JWT (application/sd-jwt) is analogous to ZIP (application/zip) -- neither should display the media types of the documents they envelop/contain.

Neither application/vc-ld+sd-jwt nor application/vc+ld+json+sd-jwt should exist; both should be just application/sd-jwt. As I understand your intent for these latter types, upon extraction, they would both deliver an application/vc+ld+json document.

Regrettably, §3.11. Use Explicit Typing and §3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs suggest significant misunderstandings of the Media Type RFC on the part of the JWT RFC authors.

To my mind, after extensive reading of RFCs on and about Media Types, just as there is no explicit sub-typing of ZIPs based on their content, there should be no explicit sub-typing of JWTs basd on their content — except and unless where a generic JWT processor can process those sub-types to some degree, but that does not appear to be what the JWT RFC authors have had in mind.

[msporny]

Agree with what @TallTed says above, the media type is application/sd-jwt and that media type has it's own payload typing system (cty). It's analogous to application/zip.

However, given that there exist multiple erroneous application/foo+jwt entries in the media types registry, registering application/vc+sd-jwt might work as long as the semantics are aligned with application/vc+ld+json, but I expect there to be vigorous debate given that this is a /new/ registration... which would then kick off whether those types of registrations should be allowed... which will then further delay the suffixes draft and vc-jose-cose.

[TallTed]

Feedback should probably reach the JWT RFC authors, toward some revision there. I think their intentions would be well served by the Media Type profile feature.

[selfissued]

The editors talked about this on today's editors' call. We're thinking that the path of least resistance is to leave the present registration requests in place. Then one of two things could happen:

1. Structured suffixes are approved in the IETF. In that case, no changes will be required in this specification.
2. Structured suffixes are rejected by the IETF. In that case, we will change our registration requests, which could require a second CR.

We propose to close this issue on that basis.

[OR13]

See also: https://github.com/w3c/vc-jose-cose/issues/184

[OR13]

Per is up here: https://github.com/w3c/vc-jose-cose/pull/186

[TallTed]

The editors talked about this on today's editors' call. We're thinking that the path of least resistance is to leave the present registration requests in place.

W3C WG editors are supposed to implement decisions made by the WG as a whole, not the other way around.

I can think of numerous instances of "paths of least resistance" which would have been bad for interoperation, web users on both sides (servers and browsers), and the Internet writ large.

I do not think that such "paths of least resistance" are a good basis for most technological decisions, especially where that "least resistance" essentially ignores or negates existing specifications, and may impact many implementations and deployments which are not generally known to spec authors/editors because implementers and deployers are not required to announce their activities and have (and should have) a reasonable expectation that such existing specifications will not be changed out from under them.

[selfissued]

Categorizing as post-CR, per decision on 20-Dec-23 working group call.

[TallTed]

20-Dec-23 -> 20-Dec-2023

[decentralgabe]

Fixed by https://github.com/w3c/vc-jose-cose/pull/279