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

From: Mike Jones <[email-masked]>
Date: Wed, 18 Sep 2013 23:04:44 +0000

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 19 Sep 2013 09:34:21 -0600

#2 seems like a reasonable path forward.

On Wed, Sep 18, 2013 at 5:04 PM, Mike Jones <[email-masked]>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-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 20 Sep 2013 01:32:12 +0900

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-masked]>

>> 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.****
>>
>> 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.****
>>
>>                                                                 -- Mike**
>> **

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 29 Sep 2013 14:34:05 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Wednesday, September 18, 2013 4:05 PM
To: [email-masked]
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

  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:

types

    + 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

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

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 30 Sep 2013 13:00:36 +1000

Media types can have parameters. It is not worth making JOSE a special case by forbidding parameters in "cty" media type values.

As for when a sender omits "application/" and a receiver prepends it...
The “easy” choice for a sender is to drop the prefix when mediaType.startsWith("application/") or when mediaType.type == "application".
The “easy” choice for a receiver is to prepend "application/" when a "cty" value has no ‘/’ character.
These “easy” choices are incompatible when a parameter includes a ‘/’.

My initial suggested text tolerated receivers making the “easy” choice so it couldn’t allow senders to always drop “application/”.
That probably is the wrong way around. It would be better to allow senders to make the “easy” choice and, consequently, require receivers to consider ‘/’ and ‘;’ characters when deciding whether to prepend "application/". It would probably be worth including an example with a ‘/’ in a parameter to help recipients get this right. We may as well make omitting "application/" a MUST (as MUSTs are better than MAYs).

Current proposal:

  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 '/'.

New proposal:

  To keep messages compact in common situations, a sender MUST omit the
  "application/" prefix when the top-level type is "application".
  A recipient reconstructing the media type MUST prepend "application/"
  to a "cty" value that contains no '/' character or no '/' before a ';' character.

  Example: {"cty":"foo;part=\"1/2\""} conveys the media type
  application/foo;part="1/2".

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, 30 September 2013 7:34 AM
To: 'Mike Jones'; [email-masked]
Cc: Manger, James H
Subject: Re: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type

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.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, September 18, 2013 4:05 PM
To: [email-masked]
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:

[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