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 < [email protected] > 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 <[email protected]> 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 > <[email protected]>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]> >> 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] >> https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
