On Thu, May 23, 2013 at 7:56 PM, Manger, James H < [email protected]> wrote:
> > Sharing a media type only makes sense if there's a way to disambiguate. > So the "typ" header would have to be mandatory. > > The assumption is that looking at the JSON header of any JOSE message is > sufficient to work out what it is (signed, MACed, directly encrypted, > unprotected etc). In many situations a JOSE message will NOT be accompanied > by a media type (eg a JOSE message as a bearer token in an HTTP message) so > the media type cannot be required for disambiguation. > This point is not entirely germane to this issue, since the question here is how to define the media type (thus focused on cases where there is a media type expressed). But it's a valid point w.r.t. the requirement level on "typ". > It might well be helpful in some situations to distinguish the variety of > JOSE message before peeking into the JSON header (I proposed a 1-character > prefix to do just that a year ago). In that case, though, I want to > distinguish "unprotected" from "asymmetrically signed" from "MACed" from > "encrypted with a shared secret" from "key exchange + encrypted" -- not > "JWS" vs "JWE". > I don't see a huge difference between the indicator being in the header or out. As long as the first component is JSON for all JW* variants. I agree that a "typ" JSON header field should be mandatory. It should be > the primary way to indicate how to process the message, should obviate the > need for "crit", and should have values like "sig", "mac", "plain", "aead", > "keyex". > > Allowing the "typ" field as a parameter of an application/jose media type > would be a reasonable design. > No, it wouldn't :) If it's a parameter, then it can be omitted, and the bare media type would have to have a semantic. Also, this would be duplicative of the "typ" in the object (what if they don't match?). --Richard > -- > James Manger > > > From: Richard Barnes [mailto:[email protected]] > > Sharing a media type only makes sense if there's a way to disambiguate. > So the "typ" header would have to be mandatory. > > On Wed, May 22, 2013 at 11:32 PM, Manger, James H < > [email protected]> wrote: > Why have separate media types for JWS and JWE? > Wouldn’t it be better to have one media type for the > dot-separated-base64url serialization of a JOSE message — regardless of > whether the content was unprotected, signed, MACed, encrypted with any of > the supported options, or any future algorithm? > > application/jose > > A second media type for the separate serialization is useful. > > application/jose+json > > > ---------- > > #22: JSON Serialization media types not consistent with RFC 6839 > > > > The JSON Serialization media types "application/jwe-js" and > > "application /jws-js" are not consistent with RFC 6839. > > > > * "application/jwe-js" should be "application/jwe+json" > > * "application/jws-js" should be "application/jws+json" > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
