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

Of all of the suggestions I've seen so far on this topic, I think this
one gives the best way to proceed on the media type.

To paraphrase, it

    1) replaces application/jws and application/jwe with application/jose
and
    2) replaces application/jws+json and application/jwe+json with
application/jose+json

And there is a simple algorithm that can be applied to determine whether
it's jwe or jws.

    Tony Hansen

On 6/20/2013 2:39 PM, Richard Barnes wrote:
> 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
> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> 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:rlb@ipv.sx <mailto:rlb@ipv.sx>]
>     *Sent:* Thursday, June 20, 2013 9:49 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?
>
>      
>
>     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 <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
> https://www.ietf.org/mailman/listinfo/jose