Which is to say, if what I said wasn't exactly clear, that the different
mimetypes don't necessarily add anything. If we're going to define a
mimetype we might as well just have the one, application/jose for the
compact encoding.
For the JSON-based encodings, the same argument applies. However,
personally, I've never been a fan of the plus-style mimetypes like
application/jose+json, since in most dev frameworks that I've worked in
you get "application/json" for free when you start spitting out JSON
objects. It raises the question: is it valid to put a JSON-encoded JOSE
object out as just application/json? I'd think you'd want it to be. I'd
predict that that's what you're going to have developers doing in general.
-- justin
On 06/20/2013 11:20 AM, Justin Richer wrote:
And I'd like to point out that we need this method anyway because you
won't always have a mimetype along with the JOSE object -- they can be
sent as HTTP headers, query parameters, any number of things really.
-- Justin
On 06/20/2013 11:19 AM, Mike Jones wrote:
There is a defined algorithm to distinguish between the JWS and JWE
objects in the third paragraph of
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4.
-- Mike
*From:*Richard Barnes [mailto:[email protected]]
*Sent:* Thursday, June 20, 2013 8:15 AM
*To:* Mike Jones
*Cc:* [email protected]
*Subject:* Re: [jose] Should we keep or remove the JOSE JWS and JWE
MIME types?
Multiplexing JWE and JWS under a single JOSE media type only makes
sense if there's a defined algorithm to demux them. So if you want
to do this, you would need to write down the algorithm.
Personally, it seems simpler and clearer to me to just have the four
current types, so that you know which type of object you're dealing
with, and in what serialization, without having to do content sniffing.
On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones
<[email protected] <mailto:[email protected]>> wrote:
The JWS and JWE documents currently define these MIME types for the
convenience of applications that may want to use them:
application/jws
application/jws+json
application/jwe
application/jwe+json
That being said, I'm not aware of any uses of these by applications
at present. Thus, I think that makes it fair game to ask whether we
want to keep them or remove them -- in which case, if applications
ever needed them, they could define them later.
Another dimension of this question for JWS and JWE is that it's not
clear that the four types application/jws, application/jws+json,
application/jwe, and application/jwe+json are even the right ones.
It might be more useful to have generic application/jose and
application/jose+json types, which could hold either JWS or JWE
objects respectively using the compact or JSON serializations
(although I'm not advocating adding them at this time).
Having different JWS versus JWE MIME types apparently did contribute
to at least Dick's confusion about the purpose of the "typ" field, so
deleting them could help eliminate this possibility of confusion in
the future. Thus, I'm increasingly convinced we should get rid of
the JWS and JWE types and leave it up to applications to define the
types they need, when they need them.
Do people have use cases for these four MIME types now or should we
leave them to future specs to define, if needed?
-- Mike
P.S. For completeness, I'll add that the JWK document also defines
these MIME types:
application/jwk+json
application/jwk-set+json
There are already clear use cases for these types, so I'm not
advocating deleting them, but wanted to call that out explicitly.
For instance, when retrieving a JWK Set document referenced by a
"jku" header parameter, I believe that the result should use the
application/jwk-set+json type. (In fact, I'll add this to the specs,
unless there are any objections.) Likewise,
draft-miller-jose-jwe-protected-jwk-02 already uses
application/jwk+json. Both could also be as "cty" values when
encrypting JWKs and JWK Sets, in contexts where that that would be
useful.
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
