Closed msporny closed 5 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!
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.
Changing the
typ
value fromvc+ld+json+sd-jwt
tosd-jwt
would lose the spirit of whattyp
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:
typ
field.cty
field.The issue marker needs to highlight that all three decisions have yet to be finalized.
@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.
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.
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.
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 beapplication/sd-jwt
which, when decoded, will contain acty
property ofapplication/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
ORapplication/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 thecty
value) to have a mechanism that they can count on.Section 3.1.1 states that implementers can't count on
typ
andcty
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.