Closed decentralgabe closed 2 months ago
Thank you!
The issue was discussed in a meeting on 2024-07-10
The issue was discussed in a meeting on 2024-07-10
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.
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.
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 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.
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 useapplication/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 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.
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.
Just reviewed Orie's requested changes, I think theyre a very sensible way to move this PR forward
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.
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.
A couple other options:
Withdraw the +sd-jwt variants registration requests.
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.
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.
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 theapplication/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.
I do not see this PR getting consensus. As such, I believe we should continue discussion in #282 before another PR is attempted.
The issue was discussed in a meeting on 2024-08-07
fix #282
Preview | Diff