Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

Editorially, if we do decide to add application/jose and application/jose+json MIME types, I would register them in draft-ietf-jose-json-web-signature, just like other registry content shared between JWS and JWE, such as the JSON Web Signature and Encryption Header Parameters Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18>.

                                                            -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:mamille2@cisco.com]
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; jose@ietf.org
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

I just want to say that I think having a media type is important and useful.  It might not be important and useful for JWT or OAuth or OpenID-Connect, but I can think of many applications that would make use of them if at all possible.

I personally don't care if it's a generic media type or individual application/jwe and application/jws.  However, I think a generic media type would require a separate document; trying to fit this into the one shared document (JWA) seems wrong.

- m&m

Matt Miller < mamille2@cisco.com<mailto:mamille2@cisco.com> >

Cisco Systems, Inc.

PS: I've found +json useful for other things, because I do have applications that present in different formats (right now that's usually +xml).  While there's not a simple corollary with XML-based concepts, I think there will be corollaries in the future (e.g., CBOR).  Having them now means we're not painted into a corner if (when) we look at JOSE2 and support for binary representations.

On Jun 20, 2013, at 10:49 AM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>>

wrote:

> That algorithm is part of the story, but it's incomplete.  What we need is

> an algorithm that starts with an arbitrary octet string and sorts by

> JWS/JWE and serialization.  An outline of the flow chart:

>

> 1. If content parses as valid JSON

> 1.*. Parse JSON

> 1.1. Iontains a "ciphertext" field -> JWE + JSON

> 1.2. Contains a "payload" field -> JWS + JSON

> 1.3. Else fail

> 2. Else if content matches the regex "^[a-zA-Z0-9_.-]*$"

> 2.*. Split on "."

> 2.1. If 5 components -> JWE + compact

> 2.2. If 3 components -> JWS + compact

> 2.3. Else fail

> 3. Else fail

>

> There's also the question of which document this goes in.  It would be a

> natural thing for a combined JWS+JWE document, but we don't have one of

> those :(

>

>

>

>

> On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>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:rlb@ipv.sx]

>> *Sent:* Thursday, June 20, 2013 8:15 AM

>> *To:* Mike Jones

>> *Cc:* jose@ietf.org<mailto:jose@ietf.org>

>>

>> *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 <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>

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

>> jose@ietf.org<mailto:jose@ietf.org>

>> https://www.ietf.org/mailman/listinfo/jose****

>>

>> ** **

>>

> _______________________________________________

> jose mailing list

> jose@ietf.org<mailto:jose@ietf.org>

> https://www.ietf.org/mailman/listinfo/jose