I’m more concerned about keeping things simple for recipients than senders, as
there are orders of magnitude more relying parties than identity providers, and
while identity providers tend to be written by professionals, relying parties
are all over the map.
The “does it have a slash in it?” test is a one-liner in every programming
language I know of.
The “is the media type name missing a prefix?” test, when the type may contain
slashes in parameters, is not quite as simple.
-- Mike
From: Manger, James H [mailto:[email protected]]
Sent: Thursday, October 03, 2013 7:24 PM
To: Mike Jones; Jim Schaad; [email protected]
Subject: RE: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a
media type
“if the major type is “application” omit the “application/” prefix” is an even
simpler rule ;-)
Even if the spec text was “if it doesn’t have a slash in it, add application/
to the front of it” I would be tempted to implement “if it doesn’t have a slash
in it (that isn’t after a semicolon), add application/ to the front of it”.
That doesn’t break any correct cases. It is merely a little bit lenient in
cases where the originator was slightly sloppy by checking the major type but
not the parameters (perhaps a parameter was set in a different part of the
originator’s code than setting the base media type). But if these slightly
sloppy messages interoperate with some recipients, that pressures other
recipients to be equally lenient otherwise they lose market share. Hence, I
think a dirt-simple rule for originators (always omit “application/”) is a
better for the spec.
--
James Manger
From: Mike Jones [mailto:[email protected]]
Sent: Friday, 4 October 2013 10:34 AM
To: Manger, James H; Jim Schaad; [email protected]<mailto:[email protected]>
Subject: RE: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a
media type
I think that “application/foo;part="1/2"” should be required to retain the
“application/” part. Then the rule can still be the dirt-simple “if it doesn’t
have a slash in it, add application/ to the front of it”.
Cheers,
-- Mike
-----Original Message-----
From: Manger, James H [mailto:[email protected]]
Sent: Sunday, September 29, 2013 8:01 PM
To: Jim Schaad; Mike Jones; [email protected]<mailto:[email protected]>
Subject: RE: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a
media type
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]>
[mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Monday, 30 September 2013 7:34 AM
To: 'Mike Jones'; [email protected]<mailto:[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]>
[mailto:[email protected]] On Behalf Of Mike Jones
Sent: Wednesday, September 18, 2013 4:05 PM
To: [email protected]<mailto:[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
