Re: [jose] Common elements (was: Re: Should we keep or remove the JOSE JWS and JWE MIME types?)

And as I said in that conversation, it seems like you could have those two
sentences instead of 12 sections of duplicative text.

On Thu, Jun 20, 2013 at 3:04 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:

>  As you know from our private conversation about your review comments,
> while closely related, the key selection header parameter definitions are,
> by design, not identical between the JWS and JWE spec.  In JWS they refer
> to the key that is used to check the signature/MAC.  In JWE they refer to
> the key to which the JWE was encrypted.  Trying to coalesce them would only
> make the text unnecessarily muddier in both cases.****
>
> ** **
>
>
> -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:rlb@ipv.sx]
> *Sent:* Thursday, June 20, 2013 11:41 AM
> *To:* Mike Jones
> *Cc:* Matt Miller (mamille2); jose@ietf.org
> *Subject:* Common elements (was: Re: [jose] Should we keep or remove the
> JOSE JWS and JWE MIME types?)****
>
> ** **
>
> While we're at it, you could move over the header parameters that are
> shared between the two.  Namely all but "enc" and "zip".  ("epk", and "apu"
> should move to JWA.)****
>
> ** **
>
> And once you do that, it seems more and more like JWE is becoming the
> little brother to JWS, in which case we might as well combine them.****
>
> ** **
>
> On Thu, Jun 20, 2013 at 1:47 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:****
>
> 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 >****
>
> 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>****
>
> 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>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 <rlb@ipv.sx>]****
>
> >> *Sent:* Thursday, June 20, 2013 8:15 AM****
>
> >> *To:* Mike Jones****
>
> >> *Cc:* 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>****
>
> >> 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****
>
> >> https://www.ietf.org/mailman/listinfo/jose********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> > _______________________________________________****
>
> > jose mailing list****
>
> > jose@ietf.org****
>
> > https://www.ietf.org/mailman/listinfo/jose****
>
>  ****
>
> ** **
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>