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 protected] [mailto:[email protected]] On Behalf Of Jim
Schaad
Sent: Monday, 30 September 2013 7:34 AM
To: 'Mike Jones'; [email protected]
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.
(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
