We discussed issue #50 on Monday's call and it seems like there are two viable
choices before us:
1. Continue to have "cty" values come from a JOSE registry, while allowing
MIME Media Type values to also be used, if desired.
ADVANTAGES:
+ Keeps values compact
+ Uses case-sensitive value comparison (like all other JOSE parameters),
avoiding internationalization issues
+ Already working in production deployments
DISADVANTAGES:
- Creates a content type value space distinct from the widely used IANA
Media Type Registry (http://www.iana.org/assignments/media-types).
- Requires a convention to consistently spell media type names so they can
be matched case sensitively, when used.
- Names can come from one of two registries, rather than just one (possibly
being disambiguated by the presence of a "/" in the name).
2. Accept a form of James' proposal described in
http://trac.tools.ietf.org/wg/jose/trac/ticket/50, in which "cty" values are
defined to hold MIME Media Type values, also specifying that the "application/"
prefix may be omitted for compactness purposes. (MIME Media Type values are
not case sensitive and are limited to ASCII.) Furthermore, we could keep this
from being a breaking change for JWTs by RECOMMENDING that the value
"cty":"JWT" continue to be used for nested JWTs (rather than "application/jwt"
or "jwt", which would break existing deployments).
ADVANTAGES:
+ Retains the ability to have compact values for application/* media types
+ Uses only the widely used IANA Media Type Registry
+ Can be deployed without breaking changes, provided people use the
existing spellings "JWT", "JWK", and "JWK-SET" when creating content for those
media types
DISADVANTAGES:
- Uses case-insensitive value comparison, which can lead to
interoperability problems
- Implementations have to be aware of the need to prefix values not
containing a "/" with "application/" to get normal media type names
New text for "cty" under option 2 would look something like this:
4.1.9. "cty" (Content Type) Header Parameter
The cty (content type) header parameter is used to declare the MIME Media Type
[IANA.MediaTypes] of the secured content (the payload) in contexts where this
is useful to the application. This parameter has no effect upon the JWS
processing. Use of this header parameter is OPTIONAL.
Per [RFC 2045], all media type values, subtype values, and parameter names are
case-insensitive. However, parameter values are case-sensitive unless
otherwise specified for the specific parameter.
To keep messages compact in common situations, a sender MAY omit an
"application/" prefix of a media type from a "cty" value when no other '/'
appears in the media type. A recipient reconstructing the media type MUST
prepend "application/" to a "cty" value that does not contain a '/'.
As background, see
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-4.1.9
for the current "cty" text, see
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-4.1.8
for the related "typ" text, and see
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-8.2
for the Type Values Registry.
I'm curious what people's preferences are between the two choices. I can
personally live with either outcome, since both can be deployed without
breaking existing deployments. At this point, it seems to come down to a
question of personal taste. Your thoughts...?
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
