Re: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>

> #2 seems like a reasonable path forward.
>
>
> On Wed, Sep 18, 2013 at 5:04 PM, Mike Jones <[e-mail]>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en