reconcile media types with VCDM media types #282
Comments
|
The issue was discussed in a meeting on 2024-07-10
View the transcript1.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! Manu Sporny: Strange for WG to register a different media type for jose cose. We should use the base media types.
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. 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. Manu Sporny: supportive of the PR.
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.
Brent Zundel: hearing no opposition to proposed change. |
|
@brentzundel wrote:
The media types for VC-JOSE-COSE would then become:
+1 to those being the media types for VC-JOSE-COSE. During the last telecon, it was suggested that we switch back to Additionally, the issue seems to be that the IETF OAuth WG has decided to use
IOW, an SD-JWT VC (
So, I expect that an attempted registration of
What happens when the OAuth WG attempts the registration is not really of concern to this WG (other than we probably have members that would oppose the registration). It would, however, create a situation where our registration might be held up until a determination is made all around. In order to avoid that hold up, we could do the following: The current VC-JOSE-COSE specification says this today:
If we change that language to:
... then it would allow all registration attempts to proceed AND allow the OAuth WG to differentiate their credential data format from the VCWG's credential data format. Obviously, the two WGs need to come to ground on the way to proceed here, so I'm cc'ing the relevant Editors and Chairs to start that discussion: @brentzundel @decentralgabe @selfissued @awoie @danielfett @bc-pi @debcooley @hannestschofenig @rifaat-auth0 also cc'ing people that have participated in the discussion to date: @dlongley @jandrieu @TallTed @OR13 @iherman |
|
I am supportive of this proposal, @msporny, if we can find consensus amongst both working groups. |
|
A minor comment, as an addition to the argumentation. During the call last week there was a remark that the
Therefore the addition of |
Thanks @msporny. This is an interesting idea and, frankly, seems better aligned with how typing conventions for JWTs and SD-JWTs arguably should have emerged (but unfortunately didn't). This vc-jose-cose work in the W3C is not as much constrained by those conventions though so is more free to pursue codification and use of a better approach. I might suggest broadening/extending your suggestion a bit for more cohesion in general and consistency throughout the vc-jose-cose draft. If we change that language to:
the same meaning is conveyed in the token/credential in a slightly more concise way. And if a similar changes were made to the others in the document, the need to request any new media types would be obviated. i.e.: typ=sd-jwt and cty=vc and honestly using jose for the typ rather than jwt on the middle two would probably be even more consistent with the other content in vc-jose-cose not to mention the title of the document itself. So: typ=sd-jwt and cty=vc |
Agreed.
Yes, we had proposed what you just suggested initially, but some folks with ties to the JOSE work seemed to reject the notion outright (probably due to the "constrained by conventions" reasons you mentioned above). I'll ask that they object again in this thread if they still hold that viewpoint, but if not; great, as what you're suggesting was what some of us wanted to do initially because it would halt the proliferation of lots of unnecessary media types. Just to be excruciatingly clear, you're suggesting:
If so, great, that's even better as long as the same people that objected before don't object again. |
|
The reason for my previous objection regarding less specific typ values is compliance with the JWT BCP. https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing I think it would be better for JWT and SD-JWT based JSON-LD credentials and presentations to follow the JWT BCP, and in cases where they deviate explain why. Another option is to simply not create any normative requirement for typ in JOSE or COSE. A complaint regarding VCDM 1.0 and 1.1 was that it set typ to JWT... It made it seem like JSON-LD VCs and JWT VCs were the same thing... And it prevented profiling, and using typ like the JWT BCP describes. Another problem with ignoring the JWT BCP is that you cannot negotiate for credential formats with a single media type. That wouldn't be a problem if there was only 1 media type, but there are currently 4 credential media types defined in W3C and 1 defined in OAuth WG. If you want to negotiate for data integrity proofs, you would ask for application/vc. Which is also what you would ask for, if wanting the claimset which is secured as cty application/vc. What http header does an implementation respond with when instructing clients which credential formats it supports? If vc-ld stays, it appears to contradict what is already registered... If it gets replaced with vc, OAuth should probably do the right thing for disambiguity and change their media type registration... But that's up to the OAuth WG to decide. It's possible that OAuth will have to change registration requests based on feedback from IETF DEs later anyway. My view is that the vc-jose-cose spec should use suffixes properly and follow the JWT BCP, or be abandoned by the vc working group. Since cty is already a registered param in both JOSE and COSE, it's possible to secure application/vc and application/vp without writing any new documents. When you put cty in a header and sign it, you are securing your intention to convey that media type. The core data model describes what being a well formed instance of those media types means. Regardless of what media type W3C or OAuth registers for typ:vc+sd-jwt... The semantics of cty:application/vc are already defined and that media type is already registered. application/vc already works with any protocol that understands media types properly. JOSE and COSE are already capable of supporting certificates, DIDs, or whatever comes next... They have confirmation methods which are already registered for key / holder binding... All this stuff works. What is this draft (vc-jose-cose) enabling and how does it improve the web / internet? It's not providing any new semantics or security, it's simply repeating that reasonable security technologies exist, and that they can secure arbitrary media types, including the media types the core data model defines. This has been long, so I will leave a short summary of proposed next steps:
|
|
The often invoked 3.11. Use Explicit Typing section of JWT BCP is a recommendation (not requirement) as one of a number of techniques to mitigate the potential for substitution/confusion attacks. Some of the other techniques mentioned in the next section 3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs of the vaunted JWT BCP is requiring different content and/or headers, which use of cty=vc/vp along with a completely unique JSON-LD payload with its own typing system more than fulfills. One could also quibble over the applicability of the JWT BCP to something that is not JWT but that's likely a tedious and unproductive discussion so I'd prefer not. One could further quibble over how truly best the B in that BCP really is but that likewise seems tedious and unproductive as well as being beyond the actionable scope of the issue at hand. I don't believe any of this needs to be explained in the vc-xose document. But if it would placate or preempt objections to what seems to be our best last hope of a mutually agreeable path forward on this cross SDO conflict, then I'd welcome some expository text. The suggestion that vc-xose needs nothing normative with respect to 'typ' header values does resonate and seems worth consideration. |
Yes. Although somewhere in @OR13's objection(?) is the suggestion that treatment for the
|
|
The core data model context includes jwt claims. SD-JWT secures JWT claims. It should be application/jwt not application/jose. If I'm wrong then let's remove SD-JWT for. This spec, and the associated terms from the v2 JSON-LD context, because we are sure that the VCDM and JWT claimsets do not intersect. |
|
@bc-pi wrote:
and with @OR13's change suggestions:
Regarding the last entry, why does vc-jose-cose choose to not align w/ CWT given that the other approaches align with JWT (and not JOSE) and SD-JWT (and not JOSE)? IOW, should |
No, because a CWT is a CBOR map. A, JWT claimset is a JSON Object, where when these terms are present, they have special meaning: The core data model context includes jwt claims. SD-JWT secures JWT claims. It should be application/jwt not application/jose. If I'm wrong then let's remove SD-JWT from this spec, and the associated terms from the v2 JSON-LD context, because we are sure that the VCDM and JWT claimsets do not intersect. To be clear, I am talking about the "payload" that application/jwt and application/jose and application/cose secure. It has to be a JSON object, that complies with the core data model requirements. When terms like this exist in the v2 context: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L292 It implies there is an intersection of JWT claims and VCDM terms. If the goal is to remove that intersection, then change application/jwt to application/jose and remove application/sd-jwt. If the goal is to preserve it, the media types for the entire secured token / object are:
Its also possible to request a content type, but then have the token not contain a typ value:
|
|
@OR13 wrote:
The strongest argument against more generalized media types is the one @OR13 raised, which is that you can't easily content negotiate for the content type of the envelope with the JOSE/COSE stuff because those media types don't have optional parameters where you could specify the desired
Given that we can't do the above today, developers using these enveloping securing formats are forced to register a new media type for every different content type that's encoded using these enveloping formats, leading to unnecessary media type proliferation. Again, the BCP on this topic is misguided, as @bc-pi has noted above. So, do we need to content negotiate on formats in the VCWG beyond Does anyone have a use case where the above wouldn't work for them? That is, the ONLY way you can ask for what you want is via an |
|
If an API only returns credentials that comply with the core data model, you can use: Accept: application/jwt It doesn't comply with the JWT BCP, but it also doesn't require any new media types to be registered. By the same argument that application/ld+json is also application/json... application/vc+sd-jwt is also application/sd-jwt. OAuth could decide to register parameters for vc+sd-jwt... For example: application/vc+sd-jwt; profile=https://... Or application/vc+sd-jwt; cty=vc The implication, being that without any parameters, the claimset is JWT claims. I don't think it's possible for a subtype to register parameters for every suffix, but if it is, W3C has change control on application/vc and application/vp. And could register a profile or cty parameter that would apply to vc+jwt, vc+sd-jwt... There are some codec media types look similar to this: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter https://www.iana.org/assignments/media-types/application/vc Note the You would need to use a detached signature along with that extension to support any of the securing format in jose/cose... For example: ./license.vc Or you would need to use an attached signature and a different file extension: ./license.vc.cbor (with attached JSON payload) |
We should be complying with the JWT BCP provision on enabling explicit typing. The good news is that the specification already does so, so no changes are needed to achieve this. |
Indeed, the explicit typing subsection of the JWT BCP has been frequently cited during the VCWG's discussions on this topic in general, and in this issue specifically. The good news is that #282 (comment) explained why the use of the type header in this context is unnecessary, while still fulfilling the objectives of the BCP. |
I am admittedly less familiar with the COSE/CBOR suite of standards but I don't believe that is correct. In https://www.rfc-editor.org/rfc/rfc9052.html#section-3.1-3.6 COSE has 3/"content type" which can be used 'to indicate the content type of the data in the "payload"'. A standard "typ" (type) Header Parameter for COSE didn't exist until more recently with this https://datatracker.ietf.org/doc/rfc9596/ from Orie and Mike. |
|
@selfissued, and others in the thread, can you let us know if you would formally object to either one of these proposals: Proposal 1Media type: application/sd-jwt
Media type: application/jwt
Media type: application/cose (cty expressed via "content type" [label 3])
Proposal 2Media type: application/vc+sd-jwt
Media type: application/vc+jwt
Media type: application/vc+cose (cty expressed via "content type" [label 3])
|
|
I believe the idea of HTTP layer content negotiation of Verifiable Credentials at the level being discussed herein is a bit of a red herring. Typing of credentials has much more complexity and nuance and most (all?) applications that I'm aware of try and deal with it at a different layer. Perhaps we could not suggest/require type level media types at all and only suggest/require content type level media types? |
I am in favor of this proposal with the following two notes. I'll suggest again that COSE's content type needs to be a full text media type value a la
I would formally object. |
Use cty: application/vc and cty: application/vpcty shortening is not supported outside of JWTs, as Brian already pointed out: https://datatracker.ietf.org/doc/html/rfc7519#section-5.2 Be consistent with payload claims"iss" / "sub" / "cnf" are for As are the rest of these: https://www.iana.org/assignments/jwt/jwt.xhtml Either you consider the payload content type a JWT claimset, or you don't... calling the typ : application/jose signals you think the payload is not a JWT claimset... using application/sd-jwt signals you think the payload is a JWT claimset... be consistent. Drop sd-jwt, and just use |
The shorting of some media type values is specified for
I do have some familiarity with that particular registry although I typically demure at the important sounding word near my name. It does seem worth noting though that the properties defined by the Verifiable Credentials Data Model v2.0 for Verifiable Credentials and Verifiable Presentations do not appear in that registry.
I'd humbly suggest that there's a deeper disagreement or misunderstanding or something at play here, probably manifested in part in https://www.w3.org/TR/vc-jose-cose/#jose-header-parameters-jwt-claims, that is only tangentially related to media types and should be discussed separately.
No,
This is is entirely incorrect. SD-JWT (+ its aspiration to register that media type) says in its abstract that it "defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims." Some of the terminology and layering in SD-JWT (and JOSE/JWT for that matter) is admittedly confused and/or confusing. But that unfortunate reality does not give license to be factually incorrect about it.
Despite our many apparent disagreements here, that is indeed my goal.
Maybe better would be for this document to not suggest/require type level media types at all and only deal with content type level media types. |
|
@bc-pi wrote:
Then, I expect you would object at IETF if/when those media types -- |
|
I have not objected to a media type registration in a decade and a half of participation in the IETF. I don't anticipate that changing. |
|
Sorry this is long, these are just my opinions as an individual. @bc-pi You are correct about content type shortening, although I expect when reading a spec that uses JWT public claims, you probably start with https://datatracker.ietf.org/doc/html/rfc7519#section-5.2
I agree with this too... It can also unquestionably be a JWT by the same logic, because a JWT has no required fields... just special semantics for:
This is sorta like how a JWS and JWE are not limited to JWT claims. The important part is that SD-JWT cannot selectively disclose YAML or CBOR maps... It only works on JSON objects... and when https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-10.7 Thats what makes the SD-JWT "payload" a "JWT Claimset"... those are... "Public Claims"... https://datatracker.ietf.org/doc/html/rfc7519#section-4.2 ... If I've not not convinced you by now, lets agree to disagree, you are still my friend : )
This would be against the JWT BCP (which is fine, if the vcwg agrees, as you noted its just a recommendation). https://datatracker.ietf.org/doc/html/rfc8725#name-use-mutually-exclusive-vali Let me summarize what I perceive to be the strongest parts of your argument, please correct me:
1 and 4 are contradictions... but 4 is a draft (which are allowed to have contradictions), whereas 1 is a registry entry that is already approved by designated experts... and requires an appeal to change. There is an appeals process for IANA registrations: https://www.rfc-editor.org/rfc/rfc8126.html#section-10 I have not seen any concrete statement that there will be objections to the registration requests or appeals to the existing registrations, please point them out to me if they exist. Additionally draft-ietf-mediaman-suffixes directs designated experts to reject registrations that look like the ones in draft-ietf-oauth-sd-jwt-vc. If draft-ietf-mediaman-suffixes is published with IETF consensus before draft-ietf-oauth-sd-jwt-vc, DEs will reject the registration of application/vc+sd-jwt... and if its appealed, the IESG, and then eventually maybe the IAB will review the normative text in suffixes which states:
This thread will end up in the evidence bucket (assuming the text above becomes an RFC). Assuming draft-ietf-mediaman-suffixes is still a draft if that happens (reasonably high probability imo), this is probably the critical text that would be reviewed:
And also https://www.rfc-editor.org/rfc/rfc8417.html#section-2.3 which established the convention of using
It seems challenging to argue that VCs and VPs won't be used in contexts which could be confused with other kinds of JWTs, based on:
The VCWG needs a resolution on the record that answers this question: Option 0 - VCs / VPs can be JWT ClaimsetsThe vc-jose-cose specification defines a mechanism for securing application/vc and application/vp as defined in the core data model. Option 1 - VCs / VPs must not be JWT ClaimsetsThe vc-jose-cose specification defines a mechanism for securing application/vc and application/vp as defined in the core data model. After that, the VCWG needs a resolution on the record that says: If the JWT BCP applies, the VCWG declines to register more specific media types... or... If the VCWG does not intend to change the registration requests for I don't have a preference for how this is resolved in W3C or in IETF, it just needs to reflect consensus in the respective SDOs. It might be required to declare some contributors / authors / editors "in the rough" to progress these documents, if I end up being one of those people, thats ok with me.... these are just my opinions as an individual. |
|
@bc-pi wrote:
Hmm, now I'm confused. You said in this comment that you would formally object if the VCWG pursued the It sounds like you are now saying that you wouldn't do that. Maybe you meant "soft objection"? Or maybe you're saying "I'd rather the group didn't do Proposal 2, I object, but not to the level of registering a formal objection"? Your preference is clearly for Proposal 1 (with the modifications you provided, which seem fine to me, but @OR13 seems to disagree with some of it... and I expect that @selfissued might object to that one, so we'll have to sort that out). We need at least one proposal where we won't see formal objections, or if we do, we have a high confidence that the formal objections will be overridden because its a proposal that draws the least number of formal objections. If you are now saying that you won't formally object to either, we have at least one proposal that seems to be workable with no formal objections (Proposal 2). If, instead, you are saying that you will formally object (at W3C) to Proposal 2, then we might also have one workable proposal (Proposal 1, which I expect at least one person to formally object to... just waiting for them to read this thread; bringing us back down to zero proposals, all of which are being formally objected to by individuals in the OAuth/JOSE community). |
|
The issue was discussed in a meeting on 2024-08-21
View the transcript7. reconcile media types with VCDM media types (issue vc-jose-cose#282)See github issue vc-jose-cose#282.
Gabe Cohen: Brent asked that we not spend time on it on this call but happy to take a minute. Manu Sporny: Mike, it would be good to get your feedback on proposal 1 vs. proposal 2.
Manu Sporny: Your question in the PR was about objecting to media type registrations within the IETF. That's a different forum.
Michael Jones: I'm about three days behind on this and there has been substantial traffic on it, so I'm not going to state opinions at this time. |
|
Clarifying or restating what I said during near the end of the 2024-08-21 meeting: |
|
There are two things that I can unequivocally agree with in @OR13's comment yesterday:
|
Currently the media types here use
application/vc-ldorapplication/vp-ldas base types.Now that the core data model's media types
application/vcandapplication/vphave been approved by the designated experts and registered by IANA, the media types used in VC-JOSE-COSE should be updated to match.The text was updated successfully, but these errors were encountered: