Update media types according to WG resolution

[decentralgabe]

fix #282

as per the TPAC resolution on Friday September 27th

RESOLUTION: For VC-JOSE-COSE, we will proceed with a request to register application/vc+jwt, application/vp+jwt, application/vc+cose, application/vp+cose, application/vc+sd-jwt, and application/vp+sd-jwt. We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values.

This PR updates the media types accordingly. Separately, there is a PR to the respec-vc plugin to fix the examples. This PR will be merged after the change to the respec-vc plugin is merged.

---

Preview | Diff

[bc-pi]

As indicated in #282 (comment) I am "objecting" to the direction of this.

[msporny]

Other than the hex encoding concern for COSE, LGTM.

[philarcher]

AFAICT (OK, as far as MDN tells me :-) ), data URLs can only take text or base64. So good that this has been fixed.

[TallTed]

[editorial] Just a bit of language...

[brentzundel]

As indicated in #282 (comment) I am "objecting" to the direction of this.

@bc-pi to be perfectly clear, are you indicating that should this change be made, Ping Identity will be formally objecting to the publication of VC JOSE COSE as a recommendation?

[bc-pi]

@bc-pi to be perfectly clear, are you indicating that should this change be made, Ping Identity will be formally objecting to the publication of VC JOSE COSE as a recommendation?

While I honestly have no interest in raising a formal objection, if this change is implemented, we will be compelled to formally object to the publication of VC JOSE COSE as a recommendation.

I have made several efforts to engage in good faith across various forums to seek a reasonable, mutually agreeable (or at least acceptably disagreeable) solution that addresses the contention over the application/vc+sd-jwt media type. Unfortunately, the current proposed change does not reflect any such compromise or agreement.

[awoie]

I agree with @bc-pi that the current resolution does not aim to reach a compromise and does not reflect a mutual agreement between IETF SD-JWT VC and W3C COSE-JOSE. I am opposed to merging this PR, as it may cause very unnecessary issues in OIDF OID4VC and IETF SD-JWT VC and corresponding implementations.

[Sakurann]

"verifiable credentials" have become a widely used and accepted term that is used not only to point to w3c vcdm. this working group should be proud of it, but should not try to appropriate that term. what distinguishes w3c vcdm is json-ld, so that should be clearly reflected int he media types too

[decentralgabe]

Thank you all for your feedback. I understand your concerns, and I appreciate you bringing them to this group for consideration. However, I believe the time for discussions has run out—we need to progress past CR one way or another. Here are a few final points:

The media type application/vc was registered with IANA for the VCDM, which explicitly includes JSON-LD as its core format. Building off of this established media type within the W3C ecosystem is both consistent and appropriate. This is not an attempt to appropriate the term 'verifiable credentials,' but a continuation of the model we have already established. Our goal remains to ensure technical clarity and prevent confusion in the broader ecosystem.

It is unfortunate that we haven’t reached a mutual agreement with the IETF group, despite good-faith efforts from both sides. The reality is that aligning two technical communities is always challenging, especially when both have strong, differing views. That said, the consensus we reached during TPAC was based on technical merit, and that is where we need to focus.

Implementations—even draft ones—rely on media types, and conflicts between draft implementations can be disruptive. That alone, however, is not reason enough to change course. To reduce conflict, draft implementations should clearly communicate that they are subject to change as the standards evolve.

We are past the point where re-litigating historical arguments will help. I welcome further technical input on how to make these media types work harmoniously across ecosystems, and I remain committed to engaging with the IETF to find common ground. I believe that this proposal does not force our game of chicken to end in a proverbial crash—we can both keep using vc+sd-jwt with differing cty values.

If the processes guide us differently, we will respect that outcome.

[TallTed]

this working group [...] should not try to appropriate that term.

The above suggests both ill will and misbehavior on the part of this WG. That is offensive at best. Please adjust your comment.

[David-Chadwick]

I thought we had agreed that for sd-jwt the cty header would be used to differentiate between this and the IETF non-W3C VC sd-jwt

[David-Chadwick]

Suggested change

	When present, the <code>cty</code> header parameter SHOULD be <code>vc</code>.
	The <code>cty</code> header parameter MUST be <code>vc</code>.

[brentzundel]

David, since this suggestion touches on language not proposed in this PR, please raise a separate issue to discuss your desire to strengthen the normative language here. The group agreed to use the 'cty' property, it was not decided how strongly to require it.

[David-Chadwick]

"agreed to use it" to differentiate between our use of typ with the IETF's use, implies to me thatcty was to be mandated. Otherwise, the current text implies it is both optional (i.e. When present) and even then only SHOULD be used.

So I maintain that my proposed rewording is in the spirit of the WG resolution, and that the current text is definitely not in the spirit of the resolution. So I do not think it is appropriate to raise another issue, since the current PR is meant to be implementing the WG resolution.

[David-Chadwick]

Suggested change

	When present, the <code>cty</code> header parameter SHOULD be <code>vp</code>.
	The <code>cty</code> header parameter MUST be <code>vp</code>.

[brentzundel]

David, since this suggestion touches on language not proposed in this PR, please raise a separate issue to discuss your desire to strengthen the normative language here. The group agreed to use the 'cty' property, it was not decided how strongly to require it.

[David-Chadwick]

Here is the wording of the 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."
Thus is seems totally appropriate that this PR, which is meant to enact the resolution, should include text to show how that the differentiation is technically enforced.

[bc-pi]

this working group [...] should not try to appropriate that term.

The above suggests both ill will and misbehavior on the part of this WG. That is offensive at best. Please adjust your comment.

English is @Sakurann's 2nd or 3rd (maybe more) language so there may be some inadvertent or unintended subtleties of meaning in specific word choice.

[brentzundel]

@bc-pi and @awoie @Sakurann Thank you for clarifying your positions. The alternative solutions proposed previously have been thoroughly discussed by the working group. The option that most closely gained consensus is the one the group resolved to pursue, and those changes are reflected in this PR.

During previous conversations with folks from IETF SD-JWT VC, there was very little willingness for any sort of mutual compromise. We recognize that this step does not reflect a mutual agreement, because when we tried to find a solution we could all agree on, none were acceptable.

The VC-JOSE-COSE spec is stable, and has been for some time. The only outstanding normative decision left for the group was around the media types. The notes for the group meeting where that decision was made are here: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-09-27-vcwg#section1
The minutes clearly show an exploration of the various options that have been presented, and that the option that gained the most consensus was to attempt to register the media types as reflected in this PR.

Gabe, thank you for your comments and for this PR, to my view it reflects the best consensus we could find as a working group and we are going to proceed to request the media types as contained herein. We will of course respect the outcome of the process.

@david, please open an issue to track your concerns.

If those who intend to formally object have additional proposals to suggest that have not already been presented to the group, we would be happy to discuss them.

I am merging this PR in accordance with the VCWG resolution.

[bc-pi]

Thank you all for your feedback. I understand your concerns, and I appreciate you bringing them to this group for consideration. However, I believe the time for discussions has run out—we need to progress past CR one way or another. Here are a few final points:

The media type application/vc was registered with IANA for the VCDM, which explicitly includes JSON-LD as its core format. Building off of this established media type within the W3C ecosystem is both consistent and appropriate. This is not an attempt to appropriate the term 'verifiable credentials,' but a continuation of the model we have already established. Our goal remains to ensure technical clarity and prevent confusion in the broader ecosystem.

It is unfortunate that we haven’t reached a mutual agreement with the IETF group, despite good-faith efforts from both sides. The reality is that aligning two technical communities is always challenging, especially when both have strong, differing views. That said, the consensus we reached during TPAC was based on technical merit, and that is where we need to focus.

Implementations—even draft ones—rely on media types, and conflicts between draft implementations can be disruptive. That alone, however, is not reason enough to change course. To reduce conflict, draft implementations should clearly communicate that they are subject to change as the standards evolve.

We are past the point where re-litigating historical arguments will help. I welcome further technical input on how to make these media types work harmoniously across ecosystems, and I remain committed to engaging with the IETF to find common ground. I believe that this proposal does not force our game of chicken to end in a proverbial crash—we can both keep using vc+sd-jwt with differing cty values.

If the processes guide us differently, we will respect that outcome.

There's quite a bit in @decentralgabe's comment there with which I am in fundamental disagreement. Further discussion of the disagreements seems unproductive though. Especially because this PR was merged by @brentzundel while I was typing the prior sentence.

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.

[bc-pi]

@bc-pi and @awoie @Sakurann Thank you for clarifying your positions. The alternative solutions proposed previously have been thoroughly discussed by the working group. The option that most closely gained consensus is the one the group resolved to pursue, and those changes are reflected in this PR.

During previous conversations with folks from IETF SD-JWT VC, there was very little willingness for any sort of mutual compromise. We recognize that this step does not reflect a mutual agreement, because when we tried to find a solution we could all agree on, none were acceptable.

The VC-JOSE-COSE spec is stable, and has been for some time. The only outstanding normative decision left for the group was around the media types. The notes for the group meeting where that decision was made are here: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-09-27-vcwg#section1 The minutes clearly show an exploration of the various options that have been presented, and that the option that gained the most consensus was to attempt to register the media types as reflected in this PR.

Gabe, thank you for your comments and for this PR, to my view it reflects the best consensus we could find as a working group and we are going to proceed to request the media types as contained herein. We will of course respect the outcome of the process.

@david, please open an issue to track your concerns.

If those who intend to formally object have additional proposals to suggest that have not already been presented to the group, we would be happy to discuss them.

I am merging this PR in accordance with the VCWG resolution.

Unsurprisingly, I disagree with considerable amounts of @brentzundel's comment. I will only comment on one part, however.

In the meeting notes and accompanying slide deck, I do not see an exploration of the option in the first part of #282 (comment) that was my slight refinement of a proposal that Manu made and seemed for a brief time to be an actual compromise coming from "both sides".

[decentralgabe]

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.

[David-Chadwick]

@brentzundel I think you merged this PR prematurely before the discussions had been completed. Could you please re-open it. Thanks.

[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.

[msporny]

@bc-pi wrote:

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.

It's clear that there is, at best, a miscommunication here. The intent was to share the media type between the two groups and have source code switch off of the cty property. That was the compromise. Here are the statements, from the VCWG meeting at W3C TPAC 2024, that assert that compromise:

The arguments leading up to the resolution:

manu: proposal 3 is the ideal way forward, it's not incompatible with what IETF wants to do, we will share the media type with them, content type will be different but typ and media will be the same
...
manu: technical argument, proposal 3 is fine from a technical perspective, it has the benefit of letting us share the base media type with IETF
...
brent: … personal view is, in light of possibility to different using the cty value, I would be fine moving forward with registering VC+ as the base media type for JOSE COSE
...
decentralgabe: +1 what brent said about cty

The resolution itself:

We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values.

At this point, it seems like @bc-pi, @awoie, and @Sakurann might have not understood the discussion that occurred and the explicit allowance to share the application/vc+sd-jwt media type, but in a way that would allow deterministic differentiation between the VC-JOSE-COSE work and the SD-JWT VC work.

I think we can better reflect this in the spec text, the media type registration, or future updates to both. The WG discussion and the WG resolution is clear that there was a compromise made.

Would realizing the above address each of your concerns @bc-pi, @Sakurann, and @awoie?

[bc-pi]

The WG discussion and resolution from TPAC was cited several times as justification for this PR. Putting aside the technical merits, or lack thereof, of the consensus reached during TPAC - I was only attempting to say that the actual content of the PR was not fully reflective of the content of that VCWG resolution. I don't personally believe the direction of the resolution is a good one but the (currently missing) allowance for sharing a media type might lessen the prospect for, or severity of, a future direct conflict. So I was looking to preserve things that might leave options involving less conflict open. #313 was created to track that. But I'd still prefer to see something that avoids this conflict completely (such as was alluded to in #306 (comment)).

Word choice has been a topic in this thread too - so it feels not inappropriate to say that it seems disingenuous to call a decision a 'compromise' when it was made largely without representation from one faction (acknowledging no group is a monolith but there do appear to be roughly two distinct sides in this whole disagreement).

[decentralgabe]

@bc-pi, @brentzundel has opened a PR here to incorporate the language from the resolution #314

please let us know if you think this is a step in the right direction. I agree it's not quite a 'compromise' but perhaps just an avoidance of the most contentious solution, albeit still a contentious one.

FWIW I did add your proposal (or at least I tried to represent it) as you can see in Slide 36 here - Proposal 1 (In a Diplomatic World).

The group did not have much discussion on this that was minuted. I recall some private conversations that spoke to how this proposal was insufficient because (paraphrasing) it didn't follow guidance on using a 'specific type' and did not accurately capture the novelty of the work which necessitates a new media type.

[bc-pi]

The proposal is really more to:

• not to use the "typ" header at all (across JWS/JWT, SD-JWT, and COSE)
• utilize the "cty" header with application/vc|vp as appropriate for specific typing
• use existing media types in places outside the thing like HTTP's content-type or data: URLs