search

w3c / vc-jose-cose

Verifiable Credentials Working Group — VC JSON Web Tokens specification
https://w3c.github.io/vc-jose-cose/
Other
30 stars 9 forks source link

Media types are incorrect; usage can't be counted on #204

Closed msporny closed 5 months ago

msporny commented 7 months ago

The IANA Considerations section media types are (debatably) incorrect. Namely, the encapsulating media type for an application/vc+ld+json secured using SD-JWT should be application/sd-jwt which, when decoded, will contain a cty property of application/vc+ld+json.

I expect that to be the argument that @TallTed is going to put in front of the IETF MEDIAMAN WG. @TallTed, correct me if I'm misreading between the lines. That argument will go counter to the way that the "+jwt" structured suffix is used today. The alternative is to keep what's there, but that is unlikely to happen w/o a lengthy debate in the IETF MEDIAMAN WG.

Section 3 also mentions that media types can be optionally application/sd-jwt OR application/vc+ld+json+sd-jwt, meaning that implementations will not be able to depend on the media type and will need to perform some other type of processing (such as checking the cty value) to have a mechanism that they can count on.

Section 3.1.1 states that implementers can't count on typ and cty either, which means that implementers can't count on any media type information being consistent or present, which means that implementations MUST implement content sniffing logic (which is an anti-pattern).

Section 3.2.1 suggests the usage of the "+cose" structured suffix, which doesn't exist. The "+cwt" structured suffix doesn't seem to exist either.

Section 3.2.2 suggests the usage of the "+sd-jwt" structured suffix, which isn't a COSE media type?

At the very minimum, a "AT RISK" marker should go into the VC-JOSE-COSE specification noting that the media type might change during Candidate Recommendation. I expect that a debate will have to be had over the future of "encapsulating" structured suffixes like "+jwt" and "+sd-jwt" when applied to other structured suffixes.

TallTed commented 7 months ago

[@msporny] I expect that to be the argument that @TallTed is going to put in front of the IETF MEDIAMAN WG.

An excellent capture of what I've been trying to get across in multiple issues and PRs. I guess I'm at least starting to succeed!

selfissued commented 7 months ago

Changing the typ value from vc+ld+json+sd-jwt to sd-jwt would lose the spirit of what typ is for - a type for the whole object - including both the envelope and the body.

+cwt is being registered by https://datatracker.ietf.org/doc/draft-ietf-rats-eat-media-type/, which is close to completion.

That said, I'm perfectly willing to add an "at risk" marker.

msporny commented 7 months ago

Changing the typ value from vc+ld+json+sd-jwt to sd-jwt would lose the spirit of what typ is for - a type for the whole object - including both the envelope and the body.

That doesn't make sense, does it? The outer media type is the media type for the envelope, which the typ value should reflect. The cty is the content type for the payload. My statements above were mostly about cty, not typ.

+cwt is being registered by https://datatracker.ietf.org/doc/draft-ietf-rats-eat-media-type/, which is close to completion.

Good to know, thanks.

That said, I'm perfectly willing to add an "at risk" marker.

Yes, at a minimum. It sounds like the group needs to come to agreement on three things:

  1. The media type for the entire message.
  2. What goes in the typ field.
  3. What goes in the cty field.

The issue marker needs to highlight that all three decisions have yet to be finalized.

selfissued commented 6 months ago

@msporny you wrote:

That doesn't make sense, does it? The outer media type is the media type for the envelope, which the typ value should reflect.

That's not actually the case. You'll see at https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.9 that the definition of typ says:

The "typ" (type) Header Parameter is used by JWS applications to declare the media type [IANA.MediaTypes] of this complete JWS. This is intended for use by the application when more than one kind of object could be present in an application data structure that can contain a JWS; the application can use this value to disambiguate among the different kinds of objects that might be present.

Note that it types the "complete JWS" - not just the envelope.

TallTed commented 6 months ago

That is indeed what RFC 7515 says. I think that's in strong disagreement with the way the media type system is documented and with its historical and current use, at least excepting JWS.

I believe the profile media type parameter should have been used there, and in this case should be populated identically to the cty field.

David-Chadwick commented 6 months ago

To add a further element to this issue, @msporny has stated (correctly) that an sd-jwt is not exactly the same as a pure jwt, and that this specification should cater for both JOSE and sd-jwt securing mechanisms. Therefore besides the media type for sd-jwt we also need a media type and example for a pure jwt secured VC.