Provide guidance on use of cty in JOSE / COSE

[OR13]

Describe why we believe that cty should be used to specify the media type of the payload.

• https://www.rfc-editor.org/rfc/rfc7515#section-4.1.10
• https://www.rfc-editor.org/rfc/rfc7519#section-5.2

Note that JWS guidance on cty and JWT guidance on it differ.

Comment also on the use of COSE cty, for compatibility with more recent IETF work that has been published in the decades since the original RFCs were written, perhapse including:

• https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-19#name-use-of-json-cbor-or-both
• https://datatracker.ietf.org/doc/html/rfc9338#appendix-A.2.1
• https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-09

[dlongley]

Why this advice for "Explicit Typing" was not solely used and instead cty was also added against the advice of RFC 7519 should be mentioned. Notably, that "Explicit Typing" is now preferred should not be the reason why RFC 7519's advice was ignored because RFC 8725 which defines "Explicit Typing" does not use cty. This should be explained in the spec here.

[OR13]

@dlongley Not sure I fully follow, for the case where you are securing application/credential+ld+json... would you prefer to not see that media type, but instead see:

typ: vc+ld+jwt ?

[dlongley]

@OR13,

As RFC 8725 (and it draws from RFC 8417) states, disambiguating different types of JWTs (with "normal case" claims set content) should be done via typ. So, it's best practice to use that field to disambiguate different types of "normal" JWTs. This is just me quoting best practice -- it's not about my personal opinion on what should be done.

That being said, my thoughts on cty are this (but they are congruent with the RFCs mentioned in this thread and in others around the cty issue):

In a JWT, the default content type is a claims set. If you're going to change that to be something else, such as application/credential+ld+json, or you're talking about using cty with a JWS, then using cty makes sense to me. The problem is with using cty with a claims set -- no matter what the claims are. It goes against the advice of RFC 7519 to use cty for the "normal case" where content is a claims set. If you need to differentiate a JWT with one claims set from another you should use typ because that's what RFC 8417 says to do.

Only if the content is something else, for example, another JWT (which is NOT a JWT claim set, but rather looks a string of dotted base64url-encoded values) or some other thing, for example, a W3C Credential from the VCDM (application/credential+ld+json), then should cty be considered for use.

[dlongley]

A decision making chart / flow:

Is the content of the JWT a claims set?

• If yes, do NOT use cty (RFC 7519). Use typ instead for explicit typing.

• If no, use cty because your content is not the default content type for a JWT.

[OR13]

@dlongley I think you just agreed with my framing above... you prefer to see:

1. no use of cty or ctyp
2. use of typ to disambiguate between a "normal claim set" and application/credential+ld+json

If you're going to change that to be something else, such as application/credential+ld+json, or you're talking about using cty with a JWS, then using cty makes sense to me.

Yes.

The problem is with using cty with a claims set -- no matter what the claims are.

Acknowledged... but really you mean

No cty with JWTs

Yes cty with JWSs

Basically what you said here: #47 (comment)

[dlongley]

@OR13,

My read of the specs is that you should use cty whenever the content type is not a claims set and never use it when it is.

That means that the specs recommend using cty when the content type is application/credential+ld+json, because it's not a claims set.

As for the use of typ, explicit typing is used (in the example given in RFC 8417 with secevent+jwt) in the "normal case" for JWTs, where the content type is a claims set. Whether or not you should also use an explicit typ value when the cty is not a claims set is ambiguous (from my reading of the specs).

[dlongley]

To further clarify:

Claims sets:

• application/credential-claims-set+json
• application/credential-claims-set-1.1+json

Not claims sets:

• application/credential+ld+json
• application/verifiable-credential+ld+json / application/vc+ld+json
• application/verifiable-credential+jwt
• application/jwt
• ...most other media types in existence

The former (Claims sets) should never appear in the cty field of a JWT from my read of the specs. This was what I was arguing elsewhere. If we're going to go against the advice of the specs, which I believe we're doing so far, we should say why we're doing it.

The latter (Not claims sets) can appear in cty in a JWT without running afoul of the RFCs, AFAICT. I'd say it should be done because it's NOT the normal case / expected content of a JWT.

[OR13]

This seems over taken by events, I think we have resolved these issues, and when #88 is merged this should be closed.

[OR13]

@selfissued still blocked by the PR above.

[selfissued]

Closing, since PR #88 has been merged.