#2 seems like a reasonable path forward.
On Wed, Sep 18, 2013 at 5:04 PM, Mike Jones <[email protected]>wrote: > 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.9for > the current “cty” text, see > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-4.1.8for > the related “typ” text, and see > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-8.2for > 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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
