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

[Richard Barnes <[e-mail]>]

What you mean to say is that there are really two algorithms here,
depending on the media type:

application/jose
-> If 3 components, JWS
-> If 5 components, JWE

application/jose+json
-> If 'payloaod', JWS
-> If 'ciphertext', JWE




On Thu, Jun 20, 2013 at 1:41 PM, Mike Jones <[e-mail]>wrote:

>  I know of no use cases where the application won’t know whether it’s
> using the Compact Serialization or the JSON Serialization.****
>
> ** **
>
> *From:* Richard Barnes [mailto:[e-mail]]
> *Sent:* Thursday, June 20, 2013 9:49 AM
>
> *To:* Mike Jones
> *Cc:* [e-mail]
> *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?****
>
> ** **
>
> 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 <[e-mail]>
> 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:[e-mail]]
> *Sent:* Thursday, June 20, 2013 8:15 AM
> *To:* Mike Jones
> *Cc:* [e-mail]****
>
>
> *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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ****
>
> ** **
>