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
