Good questions, Mike. My (backward compatible) suggestions below. > 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
Drop these. Define application/jose and application/jose+json. Allow two optional parameters on these media types: inner -- indicates the media type of the content of the JOSE message, after removing 1 or more layers of JOSE protection. For instance, if a JPEG image is signed with an RSA key, then encrypted with AES-GCM, inner would be image/jpeg. mode -- indicates the sort of protection applied (eg signed, encrypted, unprotected...). If multiple modes of protection are applied in turn (eg signed then encrypted) they can all be listed: from the outer-most mode to the inner-most; separated by a plus (eg mode="enc+sig"). A "mode" media type parameter would be easy to specify if JOSE messages had a corresponding header field, instead of inferring the sort of processing from the "alg" value. :-( Suggestion: 1. Define a header parameter that indicates the sort of processing. Its name could be "T", or "mode" (just not "typ" as that is too confused). [I like "T" (short; stands out as THE primary field in a JOSE message), but I use "mode" below to be a little less controversial.] 2. Create a registry for "mode" values. 3. Define some initial "mode" values, alongside the spec for that processing: "sig1" for digitally signing B64(header).B64(content); "mac1" for MAC over B64(header).B64(content); "enc1" for AEAD, where AAD is B64(header) "none" for unprocessed content "cmp" for compressed (but not protected) content "enc2" for AEAD applied differently (as per the JSON representation) ... 4. Allow the "mode" parameter to be absent if an "alg" value is present and has a default "mode". This maintains compatibility with JOSE messages based on previous drafts. 5. Define the default "mode" for existing "alg" values. For instance, for "alg":"HS256" the default is "mode":"mac1". The registry of alg values would have a column for the default mode (though new algs can leave that column blank). 6. Drop the "crit" field. If you are creating a JOSE message with new semantics that MUST be understood, just define a new "mode" value. For example, to avoid some base64 overhead you could define "mode":"sig2" to mean digitally sign header||content||len(header). 7. Allow a list of "mode" values to be specified as a parameter on a JOSE media type. [probably] 8. A plus sign "+" can be appended to any "mode" value to indicate that the content of this JOSE layer is another JOSE layer. That is, process this message as per the "mode" without the "+", then process the content as another JOSE message. [Appending "+" is simpler than "cty":"jws" or "more":true, but assumes the inner JOSE message uses the same serialization as the outer one.] End result: simpler, more easily understood by people; one field that is suitable for an implementation to use to switch to the appropriate processing code; backward compatible with earlier drafts; clear mechanism for making changes that MUST-be-understood (that we can be confident code will notice). > That being said, I’m not aware of any uses of these by applications at > present. Apps such as OpenID Connect could use: application/jose;inner=application/jwt+json Apps can still define their own media types for JOSE messages (eg application/jwt) though that should not be necessary. > 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? We are defining a format for use on the web. The web identifies formats via media types. So JOSE needs to define media types. -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
