JOSE is intended to be generic. A JWS may unwrap to a XMPP message, GIF or some yet to be thought of JSON document.
What people want to use JOSE for colours there perception of it. If in your environment all the body's are JWT claim sets then saying the over all token is a JWT is redundent We will get into interop problems if one JWT library tags all its tokens as "typ":"jwt" and another is expecting them as "typ":"jwe" to shortcut looking at the alg. From a JOSE perspective I can see why people think of typ as JWE or JWS but if you look at the text in JWS the options are JWS or JWS+JSON intended to differentiate between the two possible serializations. What it is missing because the reference is awkward is the reference to JWT saying that "typ":"JWT" is always compact serialization. John B. On 2013-05-29, at 8:29 PM, Dick Hardt <[email protected]> wrote: > > > > On Wed, May 29, 2013 at 5:25 PM, John Bradley <[email protected]> wrote: > In the JWT spec the value of "typ" SHOULD be "jwt". That indicates as Mike > stated that it is a JWT in compact format that has as its body a jwt claim > set. If the claim set is signed then encrypted, the inner JWT has a a typ > of jwt and no cty , and the outer one has a typ of JWT and a cty of jws. > > I'm doing symmetric encryption with an integrity check, so I don't have a JWT > in a JWE > > > If a JOSE object has a typ of jws then one would assume that it is a jws in > compact serialization with some other body type then a jwt claimset. > > I think this is somewhat a symptom of the JWT and JOSE specs getting split > into different WG. > > So Mike can correct me but I don't think putting jwe or jws in typ is the > intended use of that element if you are in fact sending JWT. > > I understand where Jim is coming from I think of JWT as a jwt claim-set and > JWE and JWS as the outer layer, where JWT thinks of itself as a total > security token definition including overall processing rules for security > tokens, with a standard envelope segment and JWE or JWS encoding as > determined by the alg. > > That is confusing to me. > > > In security token processing knowing that what you have will unwrap to a JWT > claim-set , rather than to some other thing is quite important. > > What else would it unwrap to? > > > John B. > > > On 2013-05-29, at 7:56 PM, Dick Hardt <[email protected]> wrote: > >> I use it all the time and my code would barf if it was not there. >> >> I think it should be required rather than be a hint if it is going ot be >> there. >> >> >> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <[email protected]> wrote: >> I think the values just changed >> >> >> >> However the way you are using it would be an argument to say that it should >> be a required field. Are you just using it as a hint if it exists and then >> looking at the rest of the fields if it is not present? >> >> >> >> Jim >> >> >> >> >> >> From: Dick Hardt [mailto:[email protected]] >> Sent: Wednesday, May 29, 2013 3:49 PM >> To: Jim Schaad >> Cc: [email protected] >> Subject: Re: [jose] Should we delete the "typ" header field >> >> >> >> Well, I have been using, but now realize the spec changed or I was confused. >> >> >> >> I had been setting "typ" to be either "JWE" or "JWS" depending on the type >> of token I was creating or parsing as it was easier than looking at "alg" >> >> >> >> As currently defined, I don't see value in "typ". >> >> >> >> -- Dick >> >> >> >> >> >> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <[email protected]> wrote: >> >> In reading the documents, I am trying to understand the justification for >> having the “typ” header parameter in the JOSE documents. >> >> >> >> The purpose of the field is to hold the type of the object. In the past, I >> believe that values which should now be placed in the cty field (such as >> “JWT”) were placed in this field as well. However the parameter is optional >> and an implementation cannot rely on its being present. This means that for >> all practical purposes all of the code to determine the value of the type >> field from the values of the alg and enc fields. If the field was mandatory >> then this code would disappear at a fairly small space cost and I can >> understand why the parameter would be present. >> >> >> >> Can anybody justify why this field should be present in the document – or >> should it just disappear? >> >> >> >> Jim >> >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> >> >> >> -- >> -- Dick >> >> >> >> >> -- >> -- Dick >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > > > > -- > -- Dick
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
