Re: [jose] Should we delete the "typ" header field

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 <Michael.Jones@microsoft.com>wrote:

>  Actually, John, the text in the JWT spec is<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-5.1>
> :****
>
> ** **
>
> *5.1*<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Dick Hardt
> *Sent:* Wednesday, May 29, 2013 5:30 PM
> *To:* John Bradley
> *Cc:* Jim Schaad; jose@ietf.org
>
> *Subject:* Re: [jose] Should we delete the "typ" header field****
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, May 29, 2013 at 5:25 PM, John Bradley <ve7jtb@ve7jtb.com> 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 <dick.hardt@gmail.com> 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 <ietf@augustcellars.com>
> 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:dick.hardt@gmail.com]
> *Sent:* Wednesday, May 29, 2013 3:49 PM
> *To:* Jim Schaad
> *Cc:* jose@ietf.org
> *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 <ietf@augustcellars.com>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
>  ****
>
> --
> -- Dick ****
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>

-- 
-- Dick