update media types to align with the VCDM

[decentralgabe]

fix #282

---

Preview | Diff

[OR13]

Thank you!

[selfissued]

The current media types are the correct ones, as they are specific to being JSON-LD. We should instead apply w3c/vc-data-model#1509 to align them.

[iherman]

The issue was discussed in a meeting on 2024-07-10

• no resolutions were taken

View the transcript

1.1. reconcile media types with VCDM media types (issue vc-jose-cose#282)

See github issue vc-jose-cose#282.

Brent Zundel: good news, vc data model has media types registered!
… need to reconcile media types in vc jose cose with these media types in iana.
… do we need to do something about this.

Manu Sporny: Strange for WG to register a different media type for jose cose. We should use the base media types.
… expect application/vc+jwt and vc+sdjwt vc+cose.
… Requested to avoid application/vc+sd-jwt.
… This is being used elsewhere.
… it is confusing to hear the work verifiable credential in a spec if unsure if it is a W3C or IETF VC.

Dave Longley: +1 to everything Manu said, other groups shouldn't add confusion to VCs and we should register application/vc+sd-jwt and application/vc+jwt here.

Brent Zundel: use application/vc and /vp as the base media types. Extend as usual with +jwt +cose etc.

See github pull request vc-jose-cose#283.

Gabe Cohen: I agree.
… Raise a PR to address this.

Brent Zundel: Thanks!

See github pull request vc-jose-cose#283.

Ivan Herman: Gabe, check the two diagrams in the VCDM for jwt and let me know what needs changing.
… there are media types there that need adapting.

Manu Sporny: supportive of the PR.
… searching for +cose and +cwt suffix in the registry and not seeing anything, we would be the first ones to register.
… sounds like +cose is the right thing to do.

Gabe Cohen: https://datatracker.ietf.org/doc/html/rfc9052#name-iana-considerations.

Manu Sporny: wondering why we would be the first to register a media type with +cose.

Gabe Cohen: believe +cose is registered in above link.

Brent Zundel: cose is registered, but nothing with a +cose registered.

Manu Sporny: yes, what Brent said... that's what's confusing to me.

Ted Thibodeau Jr.: decentralgabe -- RFC 9052 registered media type application/cose. It did not register structured suffix +cose.

Manu Sporny: yet, +cose is in the structured suffix registry :) ^.

Brent Zundel: hearing no opposition to proposed change.
… please indicate approval on the PR.
… moving into data integrity conversation.

[iherman]

The issue was discussed in a meeting on 2024-07-10

• no resolutions were taken

View the transcript

1.1. reconcile media types with VCDM media types (issue vc-jose-cose#282)

See github issue vc-jose-cose#282.

Brent Zundel: good news, vc data model has media types registered!
… need to reconcile media types in vc jose cose with these media types in iana.
… do we need to do something about this.

Manu Sporny: Strange for WG to register a different media type for jose cose. We should use the base media types.
… expect application/vc+jwt and vc+sdjwt vc+cose.
… Requested to avoid application/vc+sd-jwt.
… This is being used elsewhere.
… it is confusing to hear the work verifiable credential in a spec if unsure if it is a W3C or IETF VC.

Dave Longley: +1 to everything Manu said, other groups shouldn't add confusion to VCs and we should register application/vc+sd-jwt and application/vc+jwt here.

Brent Zundel: use application/vc and /vp as the base media types. Extend as usual with +jwt +cose etc.

See github pull request vc-jose-cose#283.

Gabe Cohen: I agree.
… Raise a PR to address this.

Brent Zundel: Thanks!

See github pull request vc-jose-cose#283.

Ivan Herman: Gabe, check the two diagrams in the VCDM for jwt and let me know what needs changing.
… there are media types there that need adapting.

Manu Sporny: supportive of the PR.
… searching for +cose and +cwt suffix in the registry and not seeing anything, we would be the first ones to register.
… sounds like +cose is the right thing to do.

Gabe Cohen: https://datatracker.ietf.org/doc/html/rfc9052#name-iana-considerations.

Manu Sporny: wondering why we would be the first to register a media type with +cose.

Gabe Cohen: believe +cose is registered in above link.

Brent Zundel: cose is registered, but nothing with a +cose registered.

Manu Sporny: yes, what Brent said... that's what's confusing to me.

Ted Thibodeau Jr.: decentralgabe -- RFC 9052 registered media type application/cose. It did not register structured suffix +cose.

Manu Sporny: yet, +cose is in the structured suffix registry :) ^.

Brent Zundel: hearing no opposition to proposed change.
… please indicate approval on the PR.
… moving into data integrity conversation.

[brentzundel]

The current media types are the correct ones, as they are specific to being JSON-LD. We should instead apply w3c/vc-data-model#1509 to align them.

Media types have already been successfully registered for the VCDM https://www.iana.org/assignments/media-types/application/vc, there is no appetite in the group to once again revisit that conversation. There was certainly no consensus to change the registration to application/vc-ld and application/vp-ld

Since this specification describes how to secure application/vc and application/vp using JWT, COSE, and SD-JWT, it makes sense to me to proceed as suggested in this PR.

[selfissued]

Media types have already been successfully registered for the VCDM https://www.iana.org/assignments/media-types/application/vc, there is no appetite in the group to once again revisit that conversation. There was certainly no consensus to change the registration to application/vc-ld and application/vp-ld

Since this specification describes how to secure application/vc and application/vp using JWT, COSE, and SD-JWT, it makes sense to me to proceed as suggested in this PR.

The previously requested media types such as application/vc+ld+json and application/vc+ld+json+jwt gave us the desirable property of indicating that these credentials are JSON-LD specific. We lose that with application/vc, which is a shame. application/vc-ld would be more accurate.

At least we have retained this desirable property by choosing application/vc-ld+jwt, etc. in the VC-JOSE-SPEC. We should not give this up.

[decentralgabe]

I believe having diverging base media types between the core data model and this spec will cause more confusion. since we're securing the data model it makes sense to follow the pattern of their registered types.

I will note I was supportive of the LD-specific types for the data model, but that ship has sailed.

[Sakurann]

application/vc+sd-jwt is being used in sd-jwt vc draft and using the same media type there and here would be confusing https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#appendix-A.2.1
please use application/vc+ld+sd-jwt or something for w3c vcdm

[decentralgabe]

@Sakurann we should make sure both of our terms make sense and do not conflict, so thanks for flagging this.

We could adjust the term here to vc-ld+sd-jwt or similar. I'm not a big fan of this approach since it does not conform to the other terms we're registering. Going off the VCDM's base type of vc the type I have in this PR does make sense.

Alternatively, the SD JWT VC type could be adjusted to something like sd-jwt-vc - in fact this may make the most sense, since it seems like the 'SD' concept is intertwined with the 'VC' concept in SD JWT VC.

[brentzundel]

application/vc+sd-jwt is being used in sd-jwt vc draft and using the same media type there and here would be confusing https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#appendix-A.2.1 please use application/vc+ld+sd-jwt or something for w3c vcdm

Since the application/vc media type is defined to be a VCDM Verifiable Credential, and since the SD-JWT VC spec does not actually have anything to do with the application/vc media type, perhaps it would make more sense at this point for the SD-JWT VC spec to select a different media type.

Alternatively, the SD-JWT VC spec could describe how to secure the VCDM (or describe how the SD-JWT VC data model can be mapped to the VCDM, according to https://w3c.github.io/vc-data-model/#syntaxes). In that case we could work together to incorporate the SD-JWT portions of this document with SD-JWT VC, which would render this entire conversation moot.

[bc-pi]

JSON-LD is very important to the output of this WG so the current JSON-LD specific media types should remain. Or they should be made more specific about being JSON-LD and follow the general approach of the media types the WG was using until recently (and asked to be registered https://mailarchive.ietf.org/arch/msg/media-types/_pmQrj8nkW25FOqIXmPa1wyzizU/):

application/vc-ld-json+jwt
application/vp-ld-json+jwt
application/vc-ld-json+sd-jwt
application/vp-ld-json+sd-jwt
application/vc-ld-json+cose
application/vp-ld-json+cose

[OR13]

@bc-pi suggestion makes sense to me.

I don't think the SD-JWT VC spec needs to do anything to secure the VCDM, since JWT claimsets are compatible with the VCDM.

There is nothing stopping an SD-JWT VC issuer from including all the JSON-LD sugar they want when they issue... It just won't be understood in the context of the IANA JWT claims registry.

[awoie]

This PR conflicts with IETF SD-JWT VC. A number of specifications use IETF SD-JWT VC with the vc+sd-jwt media type, such as OID4VP, OID4VCI, HAIP, and related implementations (e.g., as highlighted in the POTENTIAL LSP interoperability event), and conformance tests developed in OIDF. When IETF SD-JWT VC added this media type, COSE-JOSE used a different one. Changing COSE-JOSE to use vc+sd-jwt would cause a lot of unnecessary trouble for these specifications, conformance tests, and implementers. For that reason, the media type in this PR needs to change to something else.

[csuwildcat]

[peacekeeper]

+1 to this PR, it makes sense to align the media types for VCs.

perhaps it would make more sense at this point for the SD-JWT VC spec to select a different media type

I agree with this. Other groups that have historically overloaded the term "VC" to mean a different data model should clearly reflect this distinction in the choice of their media types. sd-jwt-vc has been suggested and could be a good option.

It's time to let VCs be VCs.

[OR13]

I suggest to split out the application/vc+sd-jwt change... from the application/vc+jwt changes... because there does not seem to be any objection except for application/vc+sd-jwt... it may be possible to address that change in a separate PR and gain approvals on this one.

[OR13]

Suggested change

	<code>application/vc+sd-jwt</code> and
	<code>application/vc-ld+sd-jwt</code> and

[OR13]

Add this back for now.

[selfissued]

The Mike who likes consistency would prefer that we keep the media types in this specification as consistent as possible. Specifically, I suggest that we stay with application/{vc-ld,vp-ld}+{jwt,sd-jwt,cose}. Deviating from that pattern will only cause more confusion and probably inadvertent interop errors.

[OR13]

Suggested change

	<h2 id="vc-ld-json-sd-jwt"><code>application/vc+sd-jwt</code></h2>
	<h2 id="vc-ld-json-sd-jwt"><code>application/vc-ld+sd-jwt</code></h2>

[OR13]

Suggested change

	<code>application/vc+sd-jwt</code> Media Type specifically for
	<code>application/vc-ld+sd-jwt</code> Media Type specifically for

[OR13]

Suggested change

	"id": "data:application/vc+sd-jwt;eyVjV...RMjU",
	"id": "data:application/vc-ld+sd-jwt;eyVjV...RMjU",

[OR13]

Suggested change

data:application/vc+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

data:application/vc-ld+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

[OR13]

I'm changing my approval to a change request to attempt to land the changes with no objections or collisions first.

[mkhraisha]

Just reviewed Orie's requested changes, I think theyre a very sensible way to move this PR forward

[peacekeeper]

The problem with @OR13 's suggestions is that they introduce the kind of inconsistencies that @selfissued and others have been rightfully concerned about.

It would be super-weird and invite all kinds of interop problems if we had application/vc and application/vc+jwt, but then had to introduce a special exception for SD-JWT.

Considering that application/vc has been registered by IANA, this PR should be treated as a simple logical cleanup and merged as-is. Any community conflicts related to the overloading of the term "VC" should be decoupled from this PR and resolved ASAP in a separate process.

[decentralgabe]

I'd like us to have consensus and consistency for all media types. Until we find that consensus this cannot be merged. If we fail to find it, I'll need to close the PR.

[OR13]

A couple other options:

1. Withdraw the +sd-jwt variants registration requests.

2. Handle these changes when the registration requests get rejected... If that happens in the future.

If the registration requests don't get rejected, then experts agree that there is no issue here.

If the vcwg wants to argue that point with the DEs, then at least keep that argument to the one media type which is being claimed by the vcwg which was previously claimed by OAuth... Which is application/vc+sd-jwt.

This problem would not exist had W3C not taken normative dependencies on IETF drafts... Perhaps the solution is to stop doing that.

Remove sd-jwt just like multiple suffixes has been removed.

[jandrieu]

This PR conflicts with IETF SD-JWT VC.

I'll echo @brentzundel's comment:

Since the application/vc media type is defined to be a VCDM Verifiable Credential, and since the SD-JWT VC spec does not actually have anything to do with the application/vc media type, perhaps it would make more sense at this point for the SD-JWT VC spec to select a different media type.

In particular, there is currently no registered media type for SD-JWT-VC, so while I applaud the IETF's ambition, what the IETF is doing is something separate from what we are doing AND they have not yet secured the registration in question.

They have a different organization, with different members, a different charter, different technical choices, and a different serialization that is fundamentally incompatible with application/vc. Given that they are doing something new, different, and with a different data structure, it should be considered on its own merits without regard to its terminological similarity to our own work.

@awoie said

For that reason, the media type in this PR needs to change to something else.

I find it questionable to assert that we should base our media types on unfinished work in another organization.

On the contrary, we should encourage the IETF to use distinctive terminology to avoid confusion in the marketplace. IMO, application/vc* should be used only for media types defined by this working group. It would be helpful if those working with the IETF could help them to find a media type that doesn't confuse the market about what is or is not compatible with W3C VCs.

That said, my point is that we should figure out what we want and help IETF (and IANA) avoid the likely mistake of creating a media type that confuses developers.

So, +1 to @decentralgabe's comment that we should find consensus for the set of media types this group is going to request before adjusting the spec text.

[dwaite]

There is no concept of a base media type; application/foo, application/foo+bar and application/foo+baz are entirely different concepts. In particular, you don't extract application/foo as a commonality between the three on a programmatic level and do something with it.

The use of structured suffixes is a limitation you are imposing on yourself as part of the name of your media type, so that you can convey extra information. It isn't there to form a hierarchy of media types.

Something I cluster with media types and structured suffixes conceptually is the newer concept of cookie name prefixes - if you name a cookie __Host-foo , that is its full real name - but that prefix limits it such that the browser considers it an error to attempt to set that cookie on an insecure server, against a subdirectory path, or against the parent domain.

This lack of semantic structure also means that the existence of a registration of application/vc does not affect the registration of application/vc+sd-jwt, nor did the vc+sd-jwt registration rely on any sort of vc registration existing. My understanding is that at this point, registration of application/vc-ld+jwt and application/vc+jwt would be through an identical process.

As a consequence, this makes this less of a technical discussion and more of one weighing consistency and expectations against interoperability.

It sounds like application/vc+sd-jwt as used by SD-JWT VC may have existing implementations and ongoing interoperability efforts around it. So A W3C Verifiable Credentials specification using this media type may inherit interoperability problems by using that name.

I agree with the current spec text (using vc-ld+…) in that it attempts to avoid the conflict which will hurt interoperability. In the absence of trademarks, IPR and conformance programs, specifications exist to promote interoperability. Pre-existing use of a name is a good reason to consider avoiding use of that name.

Since the application/vc media type is defined to be a VCDM Verifiable Credential, and since the SD-JWT VC spec does not actually have anything to do with the application/vc media type, perhaps it would make more sense at this point for the SD-JWT VC spec to select a different media type.

I would be supportive of this line of investigation; in particular raising the issue in the relevant working group, encouraging a change of the media type, and discussing the impact (specifically, whether there deployed implementations using the media type yet, or if this would only be an effort impacting pre-production implementations).

I'm not supportive of merging a PR which creates a potential long-term interoperability issue if the justification is consistent string values. We either need to resolve the conflict or come up with stronger justification.

Alternatively, the SD-JWT VC spec could describe how to secure the VCDM (or describe how the SD-JWT VC data model can be mapped to the VCDM, according to https://w3c.github.io/vc-data-model/#syntaxes). In that case we could work together to incorporate the SD-JWT portions of this document with SD-JWT VC, which would render this entire conversation moot.

I think this would still retain the need to differentiate the two models with different media types within the JWS; one for a payload expressed in JWT claims with a documented mapping into the VCDM, and one in which the payload is the JSON-LD expression of the VCDM, with the specific required contexts and the like.

[decentralgabe]

I do not see this PR getting consensus.
As such, I believe we should continue discussion in #282 before another PR is attempted.

[iherman]

The issue was discussed in a meeting on 2024-08-07

• no resolutions were taken

View the transcript

2. VC JOSE COSE Media Types.

See github pull request vc-jose-cose#283.

Brent Zundel: Next topic is vc-jose-cose media types.
… In our group there was media type confusion ... we had media types that we wanted and we tried to get them registered for quite a long time -- or get the group into a state where we could get them registered.
… The IETF registrations dragged on for years, but what it came down to was that we could not register the media types that we wished to, but due to some quirks of our process, consensus fell in different places in different specs in different ways.
… The way consensus worked out was that our core spec uses application/vc and application/vp.
… The vc-jose-cose spec were different.
… The mismatch in media types between the two specification might be bad.
… I have learned since then, that it's actually not that big of a deal.
… I talked to a bunch of folks at IETF and learned a lot more about how they are interpreted -- the way the media types are used and how they are seen and interpreted, plus signs don't mean what we thought they meant which is related to why our multiple plus signs didn't go through.
… As the person that raised the issue about making the media types align -- I'm now saying it doesn't matter, it might not be awesome, but it doesn't matter.
… However, another thing I learned at IETF last month, the inconsistency across media types handling things at different levels in different specs, isn't a big deal, but in the same spec could lead to confusion.
… So the conversation right now with doing application/vc+jwt but then application/vc-ld+sd-jwt would be bad.
… Why does this matter? There's a specification at IETF called SD-JWT-VC and they have been using the media type application/vc+sd-jwt in production over there. We could talk about the appropriateness of them doing that if we want, but I think them using a media type that wasn't in conflict with our group's media types at the time doesn't really matter.
… There are a lot of cans of worms we could open here -- that is where the conflict lies. If we were to go forward and assert that we should have application/vc-sd+jwt to mean something else, out from underneath that group that was using it for something else, that would be the kind of move I wouldn't be proud to make.
… I'm going to go to the queue we can talk about this for about 15 minutes.

Manu Sporny: Thanks for that summary, Brent, I agree with most of it, except potentially the last bit.
… My interpretation of the way this unfolded between people that knew we were working on things in this WG is different.
… You said that there are production deployments using vc+sd-jwt -- I'd like to know what those are.
… We need to understand at what level it's deployed in production because the core issue here is that we are going to put the entire ecosystem into a situation where all of the application/vc media types except for one is going to use the W3C VC data model.
… Just one of them is going to specifically not use that.
… Anyone looking at this without this deep understanding of the text strings not meaning anything -- which is new -- which is where we could get to consensus, but even that isn't quite right, having been the one that has had to tease apart the plus signs and their meaning. But that one plus sign still means something.
… What it means is that there is a base subtype -- and I know there's a difference of opinion at IETF -- and the expectation that most developers have is that you're using something remotely the same.
… Most of those media types that use the W3C VC data model, you will be surprised when just one doesn't.
… I agree there's a consistency problem here, where vc-jose-cose isn't going to be consistent. And, it's going to create confusion in a way that is at IETF that doesn't use the W3C data model, there will be confusion there as well.
… People are using this non-W3C VC data model -- they will be very surprised that it's not W3C VC.
… We can pick a different media type -- the people in that process at IETF are also involved in this group. We cannot say they didn't see it coming. We told them it would create a problem, and they did it anyway.
… I also Brent for us to say that if we prevent the registration of that media type ... that it's something we should not be proud of doing. I think there are a number of anti-social things that have happened during this process and that is not on this group.
… I think we can take the higher road maybe with someone threading the needle with different data models sharing the base part of the media type, but it's highly problematic.
… I think the way that some groups have been operating and it's created a problem now. We should potentially have that group come in here and talk about what the best path forward is. I don't think we should confuse developers with media types that look like the same thing but they are different.

Michael Jones: On the editors call I was asked to prepare some remarks.
… I will paste into the minutes to save the scribe.

Michael Jones: Level set.
Michael Jones: The VCDM media types are application/{vc,vp}.

Michael Jones: I am not going to cover the politics, just the engineering.
… The VC-JOSE-COSE media types are application/{vc-ld,vp-ld}+{jwt,sd-jwt,cose}.
… The VCDM and VC-JOSE-COSE media types are used in different places.
… The VCDM types are used in the "cty" (content type) header parameter to describe the type of the payload.
… The VC-JOSE-COSE media types are used in the "typ" (type) header parameter to describe the type of the entire secured object.
… They are not in the same logical or semantic namespace.
… The VC-JOSE-COSE media types do not reference the VCDM media types in their definitions.
… Rather, they reference the data types defined by the VCDM.
… There is no syntactic relationship between the VCDM and VC-JOSE-COSE media types.
… There is no concept of "Base Media Type".
… There is a concept of Structured Suffix, which is different.
… As David Waite commented, there is no concept of a base media type; application/foo, application/foo+bar and application/foo+baz are entirely different concepts. In particular, you don't extract application/foo as a commonality between the three on a programmatic level and do something with it.
… Therefore, while it would be nice for the name components across the specs to be similar (which they already are), they needn't be identical.
… Practicalities:.
… We're not going to get consensus to merge #283.
… We're not going to get consensus to change application/{vc,vp} to application/{vc-ld,vp-ld}.
… We're not going to get consensus to make the VC-JOSE-COSE media types inconsistent with one another.
… We could keep beating our head against this or solve it now.
… Recommendations:.
… 1. Close #283.
… 2. Request registration of the VC-JOSE-COSE media types with IANA.

Gabe Cohen: Thanks, Mike for laying that out. I think I reached the same conclusion through different reasoning. The editors of vc-jose-cose have tried to talk to the sd-jwt-vc group but haven't been able to find common ground.
… I don't think it's worth this group's time to invite them here because I don't think things will change.
… I don't see a better path, I think we should keep the -ld types, I think that's the best we can get.

Dave Longley: I can make comments about how I think that other group is going to continue to have problems because they're using VC terminology and there is already a stake in the group what VCs mean and that other group is going to continue to confuse people related to prohibiting the use of VCs... but we don't have control over that group or if we can't convince them to do something different.
… For the concept of enveloped VCs, maybe we can solve them in a way to do enveloped-vc? Maybe because of the way we express media types and information, maybe we don't need to have additional media types for this case. Those are two other options we can put on the table.

Manu Sporny: https://datatracker.ietf.org/doc/html/rfc6838#section-3.

Manu Sporny: I'm taking issue with some of the assertions that are being said. Subtype names do mean things. This section does says that subtype names can be registered to accommodate the ... [missed see link].
… This was revisited during the subtype discussions and many people stepped up to the mic to say that the subtype matters and it should match.
… The discussions in that WG have said that they do matter. Item two -- huge strong -1 to vc-ld as the core mechanism.
… The problem here is anti-social behavior in another group that has been requested multiple times -- asking them to not do what they are doing. This has been happening for 18 months.
… They have been asked multiple times, that group continues to not do it, there have been technical, process, social arguments and that group continues to not do that. I think there is a problem with us making invalid technical arguments, I think that someone rushed forward and used the media type in production and then tell others it can't be changed -- don't do that, people who work on standards don't do that.
… I think we need to make decisions based on technical rational decisions based on what's in the specs, if we don't do that, it's a problem -- we can't go against what's said in the RFCs and specs. All that said. I think maybe Dave's enveloping thing might work.
… Or we can just do with application/sd-jwt and say you don't need the media type on there. But huge -1 to just going forward with what's in the spec right now.
… We need to do something better.

Brent Zundel: Dave has made a suggestion -- Manu says he could live with it, if we changed the media types to application/enveloped-vc+whatever -- could you live with that?
… From my perspective as chair, that's the closest thing we have for consensus.

Michael Jones: Responding to Dave Longley's suggestion that we don't need VC-JOSE-COSE media types, Explicit Typing of JWTs, etc. is a best practice defined at https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing.

Michael Jones: One is long -- responding to Dave Longley's suggestion that we don't need vc-jose-cose media types, it's a best practice to do it.
… Following best practices we don't have an option to not do that.
… The whole enveloped thing is superclunky -- and never in plain human language describe things that way, just in the spec. It's an explicit goal for JWTs to be compact and that goes against that engineering design principle.

Ted Thibodeau Jr.: "best practice" is not a standard in the sense of SDO. it's a practice and can be changed.

Brent Zundel: What about env-vc+jwt?

David Chadwick: +1 brent.

Michael Jones: We don't talk verbally about "Enveloped Verifiable Credentials". So we shouldn't put that in the names.

Dave Longley: I think env-vc+jwt would be ok.
… Saying vc-ld is redundant.

Michael Jones: No, it's not, there are other formats for VCs.

Dave Longley: No, VC is JSON-LD, that's what this group created and established.
… I'm ok with env-vc+jwt, I don't think a few extra characters matter since the JWT enveloped VCs are already quite large because they base64-encode everything anyway.

Manu Sporny: The attacker generally controls the media type -- and there's a part of that that can be signed over though. But if we're talking about the media type inside, then that is an application/vc or an application/enveloped-vc -- it's not actually a JWT that is inside, isn't that correct? I'm ok with env-vc thing.
… I forgot about version 1.1 that does have VC-JWTs, and we use a media type there. That is also something in production in a big way that we may need to pay attention to. I don't think we need to pay attention to it so much that we establish it as the only way things can be done before the media types were decided and they will have to live with changing it to whatever we say here.
… But that's another consideration -- and we might want to think about that.

Brent Zundel: Can we live with env-vc env-vp for JOSE/COSE?

Joe Andrieu: +1 for living with env-vc and env-vp.

Michael Jones: The VC-JOSE-COSE media types are used in the "typ" (type) header parameter to describe the type of the entire secured object. This is in the cryptographically secured JWT Header Parameter. It is not subject to control of the attacker.

Brent Zundel: I believe everyone has nodded to live with it except Mike.

Benjamin Young: +1 to evn-vc and env-vp.

Michael Jones: No, I think it's not verbally how we talk about it.
… The vc-jose-cose types are used in the header parameter to define the entire cryptographic object, it's not subject to control of the attacker.

Brent Zundel: I suppose we will try again next week, thanks for scribing, Dave, the meeting is done.

---