Great. Glad there's some agreement here. One other minor thing: We shouldn't call this thing "JWS", but maybe "JWContent" or something.
On Fri, Aug 2, 2013 at 2:10 AM, Manger, James H < [email protected]> wrote: > >> You cannot define the field as holding: a JOSE message (compact > >> serialization), or raw string content. Because the raw content might > >> look like a JOSE message! > > > If you base64 the content, it will never look like JOSE. It won't look > > like a compact JOSE object, since it's a base64 string with the wrong > > number of components (1 instead of 3/5). It won't look like a JSON > > JOSE object, because it won't be JSON. > > > > So, I actually proposed some syntax on this on the OAuth list. The > > proposal allows a header, but the concept is the same. > > <http://www.ietf.org/mail-archive/web/oauth/current/msg11857.html> > > I like that proposal. It should be in a JOSE doc, not JWT. > > Either "alg":"none" or "alg" being absent could be used to distinguish the > unprotect message from JWEs and JWSs. "alg":"none" is more consistent with: > "alg":"RS256" -> asym-JWS, > "alg":"HS256" -> sym-JWS, > "alg":"dir" -> sym-JWE, > "alg":"ECDH-ES" -> asym-key-agree-JWE, > "alg":"A128KW" -> sym-key-wrap-JWE > > "T":"none" would be better. > > > The important thing here is that however the unprotected stuff is > > represented, it must have the property that if I feed it into a JOSE > > library, the library will say "This is not a JWS or JWE", not "This is > > a valid JWS". > > Agree. > Unprotected stuff should have 2 segments (header.payload), which > encourages implementers not to treat it as a special case of JWS. > > -- > James Manger >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
