I would prefer going with option 2, however based on the suggested text I got at least one surprise that I was not expecting and want to get confirmed.
It would appear from the text that parameters are expected to be allowed for the content type. This makes it equivalent to what is allowed by MIME, but I don't remember it ever being explicitly stated as something to be allowed. (see below note on use of / as a marker) Jim From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Wednesday, September 18, 2013 4:05 PM To: [email protected] Cc: James H Manger Subject: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type 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 '/'. [JLS] I think that this is too restrictive. It would mean that Foo; separator="/" Would not be allowed as there is a slash character, but is not part of the front. While it is true it makes the test easier, it seems odd that the parameter value should allow for that to be part of the criteria to omit the application text. 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
