I prefer #2. #1 has certain appeal if there is a right use case, but I cannot think of one easily.
2013/9/20 Brian Campbell <[email protected]> > #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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
