In the JWT spec a JWT is the entire object in compact JWE or JWS serialization eg three period separate base64encoded segments for compact JWS.
For a JWT the payload is 1 a claim-set (plain JSON with claims) or 2 another JWT (JWE or JWS as indicated by "cty") John B. On 2013-05-29, at 9:02 PM, Dick Hardt <[email protected]> wrote: > As currently defined, I won't use "typ" > > I was using "typ" to signal if the library was doing JWS or JWE processing. > > I don't understand the difference between a JWT which was the payload and a > JWT Claims Set. I personally think the term Claims to be confusing. > > > On Wed, May 29, 2013 at 5:41 PM, Mike Jones <[email protected]> > wrote: > Actually, John, the text in the JWT spec is: > > > > 5.1. "typ" (Type) Header Parameter > > > > > > The "typ" (type) header parameter is used to declare the type of this > > object. If present, it is RECOMMENDED that its value be either "JWT" > > or "urn:ietf:params:oauth:token-type:jwt" to indicate that this > > object is a JWT. The "typ" value is a case sensitive string. Use of > > this header parameter is OPTIONAL. > > > > The reason I’m pointing this out is that your message could be read to mean > that the JWT spec requires the use of the “typ” parameter, which it doesn’t. > What it does do is RECOMMEND values to use, should they be useful in context. > It needs to remain OPTIONAL. > > > > Answering Dick’s question “What else would it unwrap to?” – if you have a > nested JWT, it could unwrap to a JWT which was the Payload or Plaintext > value, rather than a JWT Claims Set. > > > > -- Mike > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Dick > Hardt > Sent: Wednesday, May 29, 2013 5:30 PM > To: John Bradley > Cc: Jim Schaad; [email protected] > > > Subject: Re: [jose] Should we delete the "typ" header field > > > > > > > > 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 > > > > > -- > -- Dick
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
