iherman
commented
2 months ago The issue was discussed in a meeting on 2024-07-10
- no resolutions were taken
Open brentzundel opened 2 months ago
iherman
commented
2 months ago The issue was discussed in a meeting on 2024-07-10
msporny
commented
3 weeks ago @brentzundel wrote:
the media types used in VC-JOSE-COSE should be updated to match.
The media types for VC-JOSE-COSE would then become:
application/vc+jwtapplication/vc+sd-jwtapplication/vc+coseapplication/vp+jwtapplication/vp+sd-jwtapplication/vp+cose+1 to those being the media types for VC-JOSE-COSE.
During the last telecon, it was suggested that we switch back to application/vc-ld+jwt (and variations thereof, but only for VC-JOSE-COSE or SD-JWT). That drew objections, just as it was rejected in https://github.com/w3c/vc-data-model/issues/1509#issuecomment-2221558964 as a path forward.
Additionally, the issue seems to be that the IETF OAuth WG has decided to use application/vc+sd-jwt for a data model and syntax that is explicitly not based on the W3C VC data model (but instead, re-invents some aspects of it). It has been asserted that there is OAuth WG consensus on this path forward, and we need to get a confirmation from the OAuth Chairs that this is the case. An excerpt from SD-JWT VC:
Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 [W3C.VCDM]
Added a note that this is not W3C VCDM
IOW, an SD-JWT VC (application/vc+sd-jwt) is explicitly NOT an application/vc or an application/vp, which goes against this guidance that achieved consensus a while ago in the IETF MEDIAMAN WG:
Media types that make use of a named structured syntax, or similar separator such as a dash "-", MUST ensure that the registration is semantically aligned, from a data model perspective, with existing base subtype names in the media type registry. For example, for the media types "application/foo+bar" and "application/foo+baz", the expectation is that the semantics suggested by the base subtype name "application/foo" are the same between both media types. The Designated Expert MUST reject a registration if they believe the semantics for a media type registration does not align with existing base subtype names in the media type registry.
So, I expect that an attempted registration of application/vc+sd-jwt by the IETF OAuth WG will draw objections and be rejected by the Designated Experts for all the reasons stated above. If the OAuth WG intends to pursue this path, then the only paths forward for the VCWG that I see are:
application/env-vc+sd-jwt, which I expect to draw objections in the VCWG now. As an aside, I expect the IETF DEs to reject an OAuth WG attempt to register application/vc+sd-jwt), ORcty field to differentiate between an IETF SD-JWT VC and a W3C VC secured using SD-JWT, unblocking both groups from proceeding in whichever way they choose. Similarly, I expect the IETF DEs to reject an OAuth WG attempt to register application/vc+sd-jwt.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:
The
typheader parameter SHOULD bevc-ld+sd-jwt. When present, thectyheader parameter SHOULD bevc. See Registered Header Parameter Names for additional details regarding usage oftypandcty.
If we change that language to:
The
typheader parameter MUST bevc+sd-jwtand thectyheader parameter MUST bevc.
... 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
decentralgabe
commented
3 weeks ago I am supportive of this proposal, @msporny, if we can find consensus amongst both working groups.
iherman
commented
3 weeks ago A minor comment, as an addition to the argumentation.
During the call last week there was a remark that the application/vc+jwt media type does not convey the fact that we are talking about JSON-LD, hence the media type should include, somehow, the -ld flag. (Unfortunately, this remark was not minuted.) I respectfully disagree. The media type definition in the VCDM spec contains this:
Resources that use the "application/vc" Media Type are required to conform to all of the requirements for the "application/ld+json" Media Type.
Therefore the addition of -ld is unnecessary.
bc-pi
commented
3 weeks ago If we change that language to:
The
typheader parameter MUST bevc+sd-jwtand thectyheader parameter MUST bevc.... 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.
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 typ header parameter MUST be
sd-jwtand thectyheader parameter MUST bevc
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 typ=sd-jwt and cty=vp typ=jwt and cty=vc typ=jwt and cty=vp typ=cose and cty=vc typ=cose and cty=vp
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 typ=sd-jwt and cty=vp typ=jose and cty=vc typ=jose and cty=vp typ=cose and cty=vc typ=cose and cty=vp
msporny
commented
3 weeks ago 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).
Agreed.
I might suggest broadening/extending your suggestion a bit for more cohesion in general and consistency throughout the vc-jose-cose draft.
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:
typ/cty in COSE)
If so, great, that's even better as long as the same people that objected before don't object again.
OR13
commented
3 weeks ago 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:
Abandon this work item.
Remove media type registrations, and make cty a MUST, explain why you are not following JWT BCP.
Keep media type registrations, follow JWT BCP.
Keep vc-ld, wait for that to come to the DEs and get rejected, or for formal objections to kill it... This resolves to 1 with extra frustration.
bc-pi
commented
3 weeks ago 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.
bc-pi
commented
3 weeks ago Just to be excruciatingly clear, you're suggesting:
* Media type: application/sd-jwt * typ=sd-jwt and cty=vc * typ=sd-jwt and cty=vp * Media type: application/jose * typ=jose and cty=vc * typ=jose and cty=vp * Media type: application/cose (with some handwaving around `typ`/`cty` in COSE) * typ=cose and cty=vc * typ=cose and cty=vpIf so, great, that's even better as long as the same people that objected before don't object again.
Yes. Although somewhere in @OR13's objection(?) is the suggestion that treatment for the typ header is not needed in this context, which I think is very sensible and could futher shorten and simplify. So, riffing on what you had, perhaps:
* Media type: application/sd-jwt * cty=vc * cty=vp * Media type: application/jose * ty=vc * cty=vp * Media type: application/cose * cty=vc * cty=vp
OR13
commented
3 weeks ago 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.
msporny
commented
3 weeks ago @bc-pi wrote:
So, riffing on what you had, perhaps...
and with @OR13's change suggestions:
Media type: application/sd-jwt
Media type: application/jwt
Media type: application/cose (note that COSE uses 'typ', instead of 'cty' to specify content type)
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 application/cose really be application/cwt?
OR13
commented
3 weeks ago @msporny
IOW, should application/cose really be application/cwt?
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:
msporny
commented
3 weeks ago @OR13 wrote:
What http header does an implementation respond with when instructing clients which credential formats it supports?
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 cty. The lack of this feature is what's causing this concerning proliferation of +jwt / +cwt media types in the IANA Media Types table. For example, if you could do this today, we'd be done (and this conflict would never have arisen):
Accept: application/jwt;cty=vc
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 application/jwt, application/sd-jwt, and application/cwt? I'd argue that "No, we do not, because these are not the same resources". Conneg is for content negotiating for the SAME resource... and a resource encoded as an application/sd-jwt IS NOT the same resource as one encoded as an application/jwt, nor one encoded as a application/cwt, because they are different objects w/ different feature sets -- they DO NOT represent the same information and therefore they DO NOT represent the same resource. Since they are different resources, you need to use a different URL to get to them (for example, via the use of a query parameter such as ?cty=application/vc or POST body option or HTTP Header, but that last one will trigger an HTTP Range 14 discussion).
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 Accept header, and if so, how are you justifying that architectural choice (in a way that's going to be defensible in front of the IETF Media Type Designated Experts and W3C Technical Architecture Group)?
OR13
commented
3 weeks ago If an API only returns credentials that comply with the core data model, you can use:
Accept: application/jwt Accept: application/sd-jwt Accept: application/cose
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 .vc file extension only makes sense if you are using embedded / data integrity proofs...
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 ./license.vc.cbor (for cose)
Or you would need to use an attached signature and a different file extension:
./license.vc.cbor (with attached JSON payload)
selfissued
commented
2 weeks ago It doesn't comply with the JWT BCP, but it also doesn't require any new media types to be registered.
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.
bc-pi
commented
2 weeks ago 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 https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2291185453 explained why the use of the type header in this context is unnecessary, while still fulfilling the objectives of the BCP.
bc-pi
commented
2 weeks ago ... application/cose (note that COSE uses 'typ', instead of 'cty' to specify content type)
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.
msporny
commented
2 weeks ago @selfissued, and others in the thread, can you let us know if you would formally object to either one of these proposals:
Media type: application/sd-jwt
Media type: application/jwt
Media type: application/cose (cty expressed via "content type" [label 3])
Media type: application/vc+sd-jwt
Media type: application/vc+jwt
Media type: application/vc+cose (cty expressed via "content type" [label 3])
bc-pi
commented
2 weeks ago 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?
bc-pi
commented
2 weeks ago @selfissued, and others in the thread, can you let us know if you would formally object to either one of these proposals:
Proposal 1
Media type: application/sd-jwt
* cty=vc * cty=vpMedia type: application/jwt
* cty=vc * cty=vpMedia type: application/cose (cty expressed via "content type" [label 3])
* cty=vc * cty=vp
I am in favor of this proposal with the following two notes.
I'll suggest again that application/jose is more appropriate than application/jwt for the things in 3.1.1 Securing JSON-LD Verifiable Credentials with JOSE and 3.1.2 Securing JSON-LD Verifiable Presentations with JOSE in a document titled "Securing Verifiable Credentials using JOSE and COSE".
COSE's content type needs to be a full text media type value a la application/vc and application/vp (unless integers for VC/VP get registered in the IANA CoAP Content-Formats registry but that's not happening afaik).
Proposal 2
Media type: application/vc+sd-jwt
* cty=vc * cty=vpMedia type: application/vc+jwt
* cty=vc * cty=vpMedia type: application/vc+cose (cty expressed via "content type" [label 3])
* cty=vc * cty=vp
I would formally object.
OR13
commented
2 weeks ago cty shortening is not supported outside of JWTs, as Brian already pointed out:
https://datatracker.ietf.org/doc/html/rfc7519#section-5.2
"iss" / "sub" / "cnf" are for application/jwt and application/sd-jwt
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 application/jose or keep application/jwt and application/sd-jwt.
bc-pi
commented
2 weeks ago cty shortening is not supported outside of JWTs, as Brian already pointed out:
The shorting of some media type values is specified for cty and typ in plain old JWS and JWE too, which can definitely be considered supported outside of JWTs. See, for example, https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.10, https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.9, https://www.rfc-editor.org/rfc/rfc7516#section-4.1.12, and https://www.rfc-editor.org/rfc/rfc7516#section-4.1.11
"iss" / "sub" / "cnf" are for
application/jwtandapplication/sd-jwtAs are the rest of these:
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.
Either you consider the payload content type a JWT claimset, or you don't...
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.
calling the typ : application/jose signals you think the payload is not a JWT claimset...
No, application/jose signals that the thing is a "JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization" (see https://www.rfc-editor.org/rfc/rfc7515.html#section-9.2.1), which a JSON-LD Verifiable Credential/Presentation secured with JOSE unquestionably is regardless of whether or not one wants to put them into the JWT box.
using application/sd-jwt signals you think the payload is a JWT claimset...
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.
be consistent.
Despite our many apparent disagreements here, that is indeed my goal.
Drop sd-jwt, and just use
application/joseor keepapplication/jwtandapplication/sd-jwt.
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.
msporny
commented
2 weeks ago @bc-pi wrote:
I would formally object.
Then, I expect you would object at IETF if/when those media types -- application/vc+(sd-jwt|jwt|jose|cose) -- were to be registered by the OAuth WG, too? (to be clear, I'm on board, just asking for a friend)
bc-pi
commented
2 weeks ago 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.
OR13
commented
2 weeks ago 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
No,
application/josesignals that the thing is a "JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization" (see https://www.rfc-editor.org/rfc/rfc7515.html#section-9.2.1), which a JSON-LD Verifiable Credential/Presentation secured with JOSE unquestionably is regardless of whether or not one wants to put them into the JWT box.
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:
iss - https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L316C15-L316C52sub - https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L332cnf - https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L293SD-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.
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 cnf (and other JWT claims) appears in those objects, they have special semantics:
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 : )
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.
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:
Media types that make use of a named structured syntax, or similar separator such as a dash "-", MUST ensure that the registration is semantically aligned, from a data model perspective, with existing base subtype names in the media type registry. For example, for the media types "application/foo+bar" and "application/foo+baz", the expectation is that the semantics suggested by the base subtype name "application/foo" are the same between both media types. The Designated Expert MUST reject a registration if they believe the semantics for a media type registration does not align with existing base subtype names in the media type registry.
Registrants MUST prove to the Designated Expert, such as through an email to a public mailing list or issue tracker comment, that they have consent from the existing Change Controller for the associated base subtype name to register the new media type.
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:
Each of the structured syntax suffixes defined in this document is appropriate for use when the media type identifies the semantics of the protocol payload. That is, knowing the semantics of the specific media type provides for more specific processing of the content than that afforded by generic processing of the underlying representation.
https://datatracker.ietf.org/doc/html/rfc6839#section-2
And also https://www.rfc-editor.org/rfc/rfc8417.html#section-2.3 which established the convention of using +jwt
This specification registers the "application/secevent+jwt" media type, which can be used to indicate that the content is a SET. SETs MAY include this media type in the "typ" header parameter of the JWT representing the SET to explicitly declare that the JWT is a SET. This MUST be included if the SET could be used in an application context in which it could be confused with other kinds of JWTs.
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:
The vc-jose-cose specification defines a mechanism for securing application/vc and application/vp as defined in the core data model. These content types MUST be interpreted as JWT claimsets, when vc-jose-cose specification is used. The JWT BCP applies to vc-jose-cose.
The vc-jose-cose specification defines a mechanism for securing application/vc and application/vp as defined in the core data model. These content types MUST NOT be interpreted as JWT claimsets, when vc-jose-cose specification is used. The JWT BCP does not apply to vc-jose-cose.
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 JWT BCP applies, the VCWG requests registration of the more specific media types per the JWT BCP.
If the VCWG does not intend to change the registration requests for vc-ld+jwt, the VCWG should submit them to the DEs for review as soon as possible, in case there are objections or appeals... This also requires a resolution from the VCWG as I am sure @iherman will say.
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.
msporny
commented
2 weeks ago @bc-pi wrote:
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.
Hmm, now I'm confused. You said in this comment that you would formally object if the VCWG pursued the application/vc+(sd-jwt|jwt|jose|cose) path (Proposal 2).
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).
iherman
commented
2 weeks ago The issue was discussed in a meeting on 2024-08-21
bc-pi
commented
2 weeks ago Clarifying or restating what I said during near the end of the 2024-08-21 meeting: I don’t quite understand the misunderstanding of prior statements in this comment thread but I would indeed object to Proposal 2 in https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2296998704 via comment(s) or "request for changes" on a PR reflective of such and/or formally via baroque w3c process in the event that it becomes necessary.
bc-pi
commented
2 weeks ago 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.