"we can both keep using vc+sd-jwt with differing cty values"

[bc-pi]

I would like to ask for one point of clarification though. You state that "we can both keep using vc+sd-jwt with differing cty values" - can you point me to the text in the document's IANA media type registration template that makes that allowance? Perhaps I've overlooked something obvious but I'm not seeing it.

You're right, IANA's media type registration template doesn't specifically address cty. Their process is mostly about registering media types, not defining how optional headers like cty should be used. That said, using cty to distinguish between payload types within the same media type is pretty common - you see it in JWT and COSE RFCs, for example.

If we agree to share application/vc+sd-jwt, we've got a couple of practical options:

1. We could tweak the IANA registration for vc+sd-jwt to mention both of our specs. We'd add some notes to help implementers figure out how to use cty to tell the types apart.

2. Or, we could put together a new joint spec. This would point to both our standards and lay out how vc+sd-jwt can handle different payload formats using cty. It'd be similar to how application/jose+json, application/jwt, and other media types use cty for further differentiation.

Practically, I am not sure this is the best option. Having distinct media types for different data models makes sense--reducing ambiguity and potential conflict. I would like to see SD-JWT VC separate the "SD-JWT" part from the "VC" part, register a media type for "VC" and subsequent media types for how the data model is secured, like we're doing here.

There's more there than I am in a position to comment on or respond to but I'll note again that the stated "compromise" that "we can both keep using vc+sd-jwt" is nowhere reflected in the actual text of the document or it's anticipated request to IANA.

Originally posted by @bc-pi in #306 (comment)

[decentralgabe]

If the authors of SD-JWT VC are amenable to this compromise then we should explore how to solidify it.

If not, there is no point in adding additional language.

[bc-pi]

I'd argue that the language added per the resolution should reflect that resolution. "We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types." - https://www.w3.org/2024/09/27-vcwg-minutes.html#r01