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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 15:02:56 -0700

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 May 2013 18:44:54 -0400

As I understand it, "typ" lets you look at an object and tell if it's a JWE
or JWS.  That seems handy enough to keep around.

Depending on how we do MIME types, it might even be necessary, namely if we
have a single application/jose type. I forget if that's the case in the
current docs.

On Wednesday, May 29, 2013, Jim Schaad wrote:

> 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****
>
> ** **
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 May 2013 15:49:16 -0700

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-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

-- 
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Wed, 29 May 2013 23:24:21 +0000

"typ" is there so that there's a standard header parameter field for declaring what the data structure is so that it's there for applications for which this declaration is useful.  For instance, the JWT spec specifies that "typ": "JWT" can be used to declare that the object is a JSON Web Token, should that be useful in context.

For those of you who may not be aware of it, the JSON Web Signature and Encryption Type Values Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-10.2> semantically ties short "typ" names to MIME types - so there's a well-defined way that the types of JOSE objects relate to the well-established MIME type system.  In fact, MIME types are explicitly allowed to be used as "typ" values.

Ironically, there was actually a working discussion on this late 2011 and early 2012 that resulted in the decision to keep "typ" in our specs, rather than having the JWT spec define it, and that resulted in the creation of the registry.  In that thread ("[jose] Comments on the -03 JSON Web Signature document"), you wrote Jim:

[JLS] If it is believe that a parameter this list is going to be "commonly" used by many different profilers, then I believe that the core items needs to be done the in the base specification.  I would therefore not be in favor of punting it out to somebody else.  The only exception would be if we are going to have a very light core and a "real" core specs.  In this case the very light core spec could punt to the "real" core spec.  Having said that I think that a registry would be a good idea.

That's been the state of the "typ" parameter specs ever since - I believe for the good reasons that you cited then.  I haven't heard anyone argue that that reasoning was wrong - only that *their particular use case* may not need a "typ" value.  Just because all use cases don't need it isn't a sufficient argument to delete it and thereby hinder those that do.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, May 29, 2013 3:03 PM
To: [email-masked]
Subject: [jose] Should we delete the "typ" header field

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 16:40:38 -0700

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-masked]] 
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

-- Dick

Jim

 

-- 
-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 16:41:16 -0700

That would be true if it was mandatory to be present -however it is an
optional field.  So it is only sometimes helpful.

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, May 29, 2013 3:45 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 16:43:25 -0700

Can you justify why the JWT spec should not specify that  it should not be
"ctyp" : "JWT"?

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, May 29, 2013 4:24 PM
To: Jim Schaad; [email-masked]
Subject: RE: [jose] Should we delete the "typ" header field

"typ" is there so that there's a standard header parameter field for
declaring what the data structure is so that it's there for applications for
which this declaration is useful.  For instance, the JWT spec specifies that
"typ": "JWT" can be used to declare that the object is a JSON Web Token,
should that be useful in context.

For those of you who may not be aware of it, the JSON Web Signature and
Encryption Type Values Registry
<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-10
.2>  semantically ties short "typ" names to MIME types - so there's a
well-defined way that the types of JOSE objects relate to the
well-established MIME type system.  In fact, MIME types are explicitly
allowed to be used as "typ" values.

Ironically, there was actually a working discussion on this late 2011 and
early 2012 that resulted in the decision to keep "typ" in our specs, rather
than having the JWT spec define it, and that resulted in the creation of the
registry.  In that thread ("[jose] Comments on the -03 JSON Web Signature
document"), you wrote Jim:

[JLS] If it is believe that a parameter this list is going to be "commonly"
used by many different profilers, then I believe that the core items needs
to be done the in the base specification.  I would therefore not be in favor
of punting it out to somebody else.  The only exception would be if we are
going to have a very light core and a "real" core specs.  In this case the
very light core spec could punt to the "real" core spec.  Having said that I
think that a registry would be a good idea.

That's been the state of the "typ" parameter specs ever since - I believe
for the good reasons that you cited then.  I haven't heard anyone argue that
that reasoning was wrong - only that *their particular use case* may not
need a "typ" value.  Just because all use cases don't need it isn't a
sufficient argument to delete it and thereby hinder those that do.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Wednesday, May 29, 2013 3:03 PM
To: [email-masked]
Subject: [jose] Should we delete the "typ" header field

Jim

---

From: Mike Jones <[email-masked]>
Date: Wed, 29 May 2013 23:51:45 +0000

"typ" declares what the type of THIS OBJECT is.
"cty" declares what the type of THE PAYLOAD or THE PLAINTEXT is.

They're different.

In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a JSON Object containing Claims, is a completely different data structure from a JWT, which is a dot-separated list of base64url encoded fields.  The "cty" represents the former; the "typ" represents the latter.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 4:43 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Should we delete the "typ" header field

Can you justify why the JWT spec should not specify that  it should not be "ctyp" : "JWT"?

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 4:24 PM
To: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Should we delete the "typ" header field

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, May 29, 2013 3:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Should we delete the "typ" header field

Jim

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 May 2013 16:56:03 -0700

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-masked]> 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-masked]]
> *Sent:* Wednesday, May 29, 2013 3:49 PM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *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.****
>
> ** **
>
> 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-masked]>
> wrote:****
>
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>

-- 
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 00:03:22 +0000

It's fine for your application to specify that it's required for your use case.  Not applications need it, so they shouldn't be forced to pay the space penalty of an unnecessary field.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we delete the "typ" header field

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"

-- Dick

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
In reading the documents, I am trying to understand the justification for having the "typ" header parameter in the JOSE documents.

Jim

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

--
-- Dick

--
-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 May 2013 17:17:52 -0700

I'd prefer to be able to use standard libraries for creating and parsing
tokens, and not specialized libraries dependent on the use case.

I strongly think we either drop "typ" or make it required.

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <[email-masked]>wrote:

>  It’s fine for your application to specify that it’s required for your
> use case.  Not applications need it, so they shouldn’t be forced to pay the
> space penalty of an unnecessary field.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Dick Hardt
> *Sent:* Wednesday, May 29, 2013 4:56 PM
>
> *To:* Jim Schaad
> *Cc:* [email-masked]
> I use it all the time and my code would barf if it was not there.****
>
> ** **
>
> there.****
> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <[email-masked]>
> wrote:****
>

-- 
-- Dick

---

From: John Bradley <[email-masked]>
Date: Wed, 29 May 2013 20:25:23 -0400

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.

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.

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.

John B.

On 2013-05-29, at 7:56 PM, Dick Hardt <[email-masked]> 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
> 
>  
> 
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 May 2013 17:29:49 -0700

On Wed, May 29, 2013 at 5:25 PM, John Bradley <[email-masked]> 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.
>
> 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?

> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <[email-masked]>wrote:
>
>> 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"****
>>
>> ** **
>>

-- 
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 00:30:36 +0000

A standard library is unlikely to know the meanings of all possible "typ" values - and more to the point, it doesn't have to.  It's the application's job to determine that "this blob is a JOSE object" and then pass it to a standard library, which will then ignore the "typ" value.

A standard JOSE library won't know what "typ": "JWT" means.  It won't know what "typ": "BCGovToken" is, should the BC Government want to declare that it's using a token with particular characteristics.  It won't know what "typ": "XMPP" is, should XMPP want to declare that it's using a JOSE data structure with particular characteristics.  Etc.

All these values can be registered in the registry and used by applications that understand them.  That's the application's job - not the library's job.  The "typ" field is just there so that applications have a standard place to make any such declarations that they may need.

                                                                -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

I'd prefer to be able to use standard libraries for creating and parsing tokens, and not specialized libraries dependent on the use case.

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It's fine for your application to specify that it's required for your use case.  Not applications need it, so they shouldn't be forced to pay the space penalty of an unnecessary field.

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM

To: Jim Schaad

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 00:41:44 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 5:30 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

On Wed, May 29, 2013 at 5:25 PM, John Bradley <[email-masked]<mailto:[email-masked]>> 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

That is confusing to me.

John B.

On 2013-05-29, at 7:56 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

---

From: John Bradley <[email-masked]>
Date: Wed, 29 May 2013 20:58:15 -0400

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.

---

From: John Bradley <[email-masked]>
Date: Wed, 29 May 2013 21:00:05 -0400

Sorry I wasn't trying to imply that the "typ" is REQUIRED in JWT only that a value other than JWT may well confuse other libraries.

John B.

On 2013-05-29, at 8:41 PM, Mike Jones <[email-masked]> wrote:

> Actually, John, the text in the JWT spec is:
>  
> 5.1.  "typ" (Type) Header Parameter
>  
>  
> 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: Dick Hardt <[email-masked]>
Date: Wed, 29 May 2013 18:02:22 -0700

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-masked]>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***
> *
>
> ** **
>
> *Sent:* Wednesday, May 29, 2013 5:30 PM
> *To:* John Bradley
> *Cc:* Jim Schaad; [email-masked]
>
> On Wed, May 29, 2013 at 5:25 PM, John Bradley <[email-masked]> wrote:**
> **
>
> jws.****
> JWT in a JWE****
> 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.****
>
> ** **
>
> intended use of that element if you are in fact sending JWT.****
>
> ** **
>
> determined by the alg.****
>
>  ** **
>
> That is confusing to me.****
>
>  ****
>
>  ** **
>
> 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-masked]> wrote:****
>
>
>
> ****
>

-- 
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 01:10:01 +0000

The way to signal whether to do JWS or JWE processing is the "alg" field value or presence of the "enc" field (both work).  This is specified in the 3rd paragraph of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4, which begins "There are two ways of distinguishing whether a header is a JWS Header or a JWE Header".

                                                                                 -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 6:02 PM
To: Mike Jones
Cc: John Bradley; Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

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-masked]<mailto:[email-masked]>> 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>:

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 5:30 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>

That is confusing to me.

John B.

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 May 2013 18:14:09 -0700

Interesting fragment from the signature draft section 4.1.9

For example, the JSON Web

   Token (JWT) [JWT
<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#ref-JWT> ]
specification uses the "cty" value "JWT" to

   indicate that the Payload is a JSON Web Token (JWT). 

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, May 29, 2013 5:42 PM
To: Dick Hardt; John Bradley
Cc: Jim Schaad; [email-masked]
Subject: RE: [jose] Should we delete the "typ" header field

Actually, John, the text in the JWT spec is
<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-5.1>
:

 <http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-5.1>
5.1.  "typ" (Type) Header Parameter

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-masked] [mailto:[email-masked]] On Behalf Of Dick
Hardt
Sent: Wednesday, May 29, 2013 5:30 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

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.

 

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.

into different WG.

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.

 

John B.

Jim

-- Dick

Jim

 

-- 
-- Dick 

-- 
-- Dick 

 

-- 
-- Dick

---

From: John Bradley <[email-masked]>
Date: Wed, 29 May 2013 21:16:49 -0400

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-masked]> wrote:

> On Wed, May 29, 2013 at 5:41 PM, Mike Jones <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 01:18:29 +0000

Yes, that's for the nested JWT case defined in http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-5.1.  JWTs use "cty" to distinguish between when the payload/plaintext is a JWT Claims Set (a JSON object) and when it's a JWT itself (a period-separated list of base64url encoded fields - the nested case).

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, May 29, 2013 6:14 PM
To: Mike Jones; 'Dick Hardt'; 'John Bradley'
Cc: [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

For example, the JSON Web
   Token (JWT) [JWT<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#ref-JWT>] specification uses the "cty" value "JWT" to
   indicate that the Payload is a JSON Web Token (JWT).

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 5:30 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we delete the "typ" header field

That is confusing to me.

John B.

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

---

From: John Bradley <[email-masked]>
Date: Wed, 29 May 2013 21:20:14 -0400

Yes a JWT and not a JWT claim-set.  So you have to look back at JWT to see that a JWT is a JWE or JWS with allowing for recursion a JWT claim-set as the payload.

On 2013-05-29, at 9:14 PM, "Jim Schaad" <[email-masked]> wrote:

>    Token (JWT) [JWT] specification uses the "cty" value "JWT" to

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 May 2013 23:03:05 -0400

If this is the level of "type" you're referring to, I think we should drop
it from the spec.  It's an application-layer thing that the app can add or
not according to its wishes.

I'm with Dick on this.  I think we should either have a mandatory indicator
of what type of JOSE object this, or nothing at all.   If the former, the
allowable values are "JWE" and "JWS".  The "+JSON" options are non-sensical
-- the app needs to know what it's parsing before it gets this header.
 While I have a preference for the former (for clarity), the latter
approach is also OK with me, since the MIME types are specific to JWE/JWS.

Another approach here would be to address the JSON and compact forms
separately.  The JSON form has no need of "typ" at all, since the type of
the object is completely clear from what fields are there, e.g.,
"recipients" vs. "signatures".  For the compact form, we could do something
like James's "E."/"S." prefix idea, which you need because the
dot-separated components have different meanings and no field names to
indicate this.

--Richard

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <[email-masked]>wrote:

>  A standard library is unlikely to know the meanings of all possible
> “typ” values – and more to the point, *it doesn’t have to*.  It’s the
> application’s job to determine that “this blob is a JOSE object” and then
> pass it to a standard library, which will then ignore the “typ” value.****
>
> ** **
>
> A standard JOSE library won’t know what “typ”: “JWT” means.  It won’t know
> what “typ”: “BCGovToken” is, should the BC Government want to declare that
> it’s using a token with particular characteristics.  It won’t know what
> “typ”: “XMPP” is, should XMPP want to declare that it’s using a JOSE data
> structure with particular characteristics.  Etc.****
>
> ** **
>
> All these values can be registered in the registry and used by
> applications that understand them.  That’s the application’s job – not the
> library’s job.  The “typ” field is just there so that applications have a
> standard place to make any such declarations that they may need.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *Sent:* Wednesday, May 29, 2013 5:18 PM
> *To:* Mike Jones
> tokens, and not specialized libraries dependent on the use case.****
>
> ** **
>
> I strongly think we either drop "typ" or make it required.****
>
> ** **
>
> On Wed, May 29, 2013 at 5:03 PM, Mike Jones <[email-masked]>
> wrote:****
>
> It’s fine for your application to specify that it’s required for your use
> case.  Not applications need it, so they shouldn’t be forced to pay the
> *Sent:* Wednesday, May 29, 2013 4:56 PM****
>
>
> *To:* Jim Schaad
> *Cc:* [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 04:53:42 +0000

Requiring that the "typ" value be only "JWS" or "JWE" would be analogous to the MIME spec requiring that the Content-Type: field be only "text/plain" or "message/external-body".  It would render it useless.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field

If this is the level of "type" you're referring to, I think we should drop it from the spec.  It's an application-layer thing that the app can add or not according to its wishes.

I'm with Dick on this.  I think we should either have a mandatory indicator of what type of JOSE object this, or nothing at all.   If the former, the allowable values are "JWE" and "JWS".  The "+JSON" options are non-sensical -- the app needs to know what it's parsing before it gets this header.  While I have a preference for the former (for clarity), the latter approach is also OK with me, since the MIME types are specific to JWE/JWS.

Another approach here would be to address the JSON and compact forms separately.  The JSON form has no need of "typ" at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures".  For the compact form, we could do something like James's "E."/"S." prefix idea, which you need because the dot-separated components have different meanings and no field names to indicate this.

--Richard

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
A standard library is unlikely to know the meanings of all possible "typ" values - and more to the point, it doesn't have to.  It's the application's job to determine that "this blob is a JOSE object" and then pass it to a standard library, which will then ignore the "typ" value.

                                                                -- Mike

                                                                -- Mike

To: Jim Schaad

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 30 May 2013 16:07:44 +1000

> Can anybody justify why this field should be present in the document – or should it just disappear?

It seems there are at least 3 different meanings given to "typ" in the header of a JOSE message:

[1] The "typ" value indicates the serialization of the JOSE message. For example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact (dot-separated-b64-blobs) and JSON serializations.

[2] The "typ" value indicates the high-level semantics of the JOSE structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the semantics defined in the separate JWE and JWS specifications.

[3] The "typ" value indicates the application-layer semantics of the message. For example, "typ":"JWT" value indicates that the message conveys a set of claims (as a JSON object) wrapped as a JOSE message (either unprotected, signed, MACed, encrypted, or signed then encrypted) that use the compact serialization.

Indicating the serialization [1] does not seem helpful as the recipient needs to know the serialization before they can extract the header to see the "typ" value. Indicating the serialization is actually harmful as it tightly couples a message to one serialization, whereas serialization is generally thought of as a transport-layer choice that is independent of the message security or semantics.

Indicating the high-level semantics of the JOSE structure [2] is slightly useful so a message can be switched to different code according to its structure. It is not that useful, however, as further switching is required to distinguish different modes (eg unprotected vs asymmetric signature vs MAC). This meaning only helps if the field is made mandatory, and the presence/absence of the "enc" field or looking up the class of the "alg" value are not specified as alternatives.
Being able to indicate application-layer semantics [3] could theoretically be useful. Perhaps the "profile" attribute or "rel=’profile’" link relation in HTML5 is analogous. In this case JOSE should not define values for the field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as application-layer semantics — and certainly not inside the JOSE message.

Most (all?) of the many specs mentioning the "typ" field make it optional, and if they suggest particular "typ" values those are only “MAY”s or “SHOULD”s — not “MUST”s. Consequently, apps cannot rely on "typ" regardless of its meaning.

My suggestions:

* For [1], define two media types to distinguish the two serializations, not a header field.

*  1st preference for [3], drop it from JOSE specs; let an application using JOSE (eg JWT) define a field (and value) for this. If the application defines the field in a generic fashion for reuse by other applications that is a nice bonus.

* 2nd preference for [3], define a field (but no values) that can hold an application-layer semantics identifier – but only put this definition in a spec that defines JOSE messages as a whole (not specs specific to JWE or JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.

* For [2], define a mandatory field that indicates the semantics of the JOSE structure at a low enough level that a JOSE implementation built on top of a crypto library could (almost) work without needing to recognize the "alg" value. "typ" would have been a reasonable name for this field but is now too polluted with confusion. How about "t"?
Consider for instance a JOSE implementation that only supports "alg":"HS256". To add support for "alg":"HS3" (HMAC with SHA-3) minimal (if any) new code is needed in a JOSE layer: perhaps an extra table entry mapping the JOSE label "HS3" to a crypto library label (eg "HmacSHA3"). "t":"mac" can accompany both these algs. To support "alg":"RS512", in contrast, requires calls to different crypto library functions (knowing the difference between public & private keys for instance). This deserves a separate value, say, "t":"sig".

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 06:45:00 +0000

The purpose of “typ” is your 3.

There can already be no confusion about 1 because they’re syntactically completely different.  2 is unnecessary because the “alg” value (or the existence of “enc”) already distinguishes between JWS and JWE semantics.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Wednesday, May 29, 2013 11:08 PM
To: [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

My suggestions:

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 10:34:22 -0400

You're mixing up "typ" and "cty".  If you want to make the analogy to
S/MIME, "cty" is the equivalent to Content-Type inside the protected MIME
body; "typ" is the content-type on the outer MIME header.  Pasting in an
example:

-----BEGIN-----
Content-Type: application/pkcs7-mime; smime-type=signed-data;
     name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
-----END-----
<http://tools.ietf.org/html/rfc3851#section-3.4.2>

The outer Content-Type, which is analogous to "typ", MUST be
application/pkcs7-mime, with a parameter indicating the type of CMS object.
 This is the same as requiring "typ" to be JWE or JWS.  The inner
Content-Type (ASN.1/base64 encoded in the example) can be anything, just
like "cty".

--Richard

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <[email-masked]>wrote:

>  Requiring that the “typ” value be only “JWS” or “JWE” would be analogous
> to the MIME spec requiring that the Content-Type: field be only
> “text/plain” or “message/external-body”.  It would render it useless.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> Of *Richard Barnes
> *Sent:* Wednesday, May 29, 2013 8:03 PM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]; Dick Hardt
>
> not according to its wishes.****
>
> ** **
>
> I'm with Dick on this.  I think we should either have a mandatory
> indicator of what type of JOSE object this, or nothing at all.   If the
> former, the allowable values are "JWE" and "JWS".  The "+JSON" options are
> non-sensical -- the app needs to know what it's parsing before it gets this
> header.  While I have a preference for the former (for clarity), the latter
> indicate this.****
> --Richard****
> On Wed, May 29, 2013 at 8:30 PM, Mike Jones <[email-masked]>
> wrote:****
>
> A standard library is unlikely to know the meanings of all possible “typ”
> values – and more to the point, *it doesn’t have to*.  It’s the
> *Cc:* Jim Schaad; [email-masked]****
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 10:39:28 -0400

That is completely backwards.  [3] is satisfied by "cty".   JWT should be
setting "typ"=JWE/JWS, "cty"=JWT-claims.  If it's doing otherwise, it's
semantically confused and wrong.

On James's points:
(1) I think we all agree that (1) is not a useful application of "typ".
 The current docs are wrong to include the "+JSON" forms.
(2) My preference would be to keep an explicit indicator.  Relying on
structure / algorithm IDs is brittle.
(3) This is "cty", not a use case for "typ"

--Richard

On Thu, May 30, 2013 at 2:45 AM, Mike Jones <[email-masked]>wrote:

>  The purpose of “typ” is your 3.****
>
> ** **
>
> There can already be no confusion about 1 because they’re syntactically
> completely different.  2 is unnecessary because the “alg” value (or the
> existence of “enc”) already distinguishes between JWS and JWE semantics.**
> **
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> Of *Manger, James H
> *Sent:* Wednesday, May 29, 2013 11:08 PM
> *To:* [email-masked]
>
> > Can anybody justify why this field should be present in the document –
> or should it just disappear?****
>
> ** **
>
> It seems there are at least 3 different meanings given to "typ" in the
> header of a JOSE message:****
>
> ** **
>
> [1] The "typ" value indicates the serialization of the JOSE message. For
> example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact
> (dot-separated-b64-blobs) and JSON serializations.****
>
> ** **
>
> [2] The "typ" value indicates the high-level semantics of the JOSE
> structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the
> semantics defined in the separate JWE and JWS specifications.****
>
> ** **
>
> [3] The "typ" value indicates the application-layer semantics of the
> message. For example, "typ":"JWT" value indicates that the message conveys
> a set of claims (as a JSON object) wrapped as a JOSE message (either
> unprotected, signed, MACed, encrypted, or signed then encrypted) that use
> the compact serialization.****
>
> ** **
>
> Indicating the serialization [1] does not seem helpful as the recipient
> needs to know the serialization before they can extract the header to see
> the "typ" value. Indicating the serialization is actually harmful as it
> tightly couples a message to one serialization, whereas serialization is
> generally thought of as a transport-layer choice that is independent of the
> message security or semantics.****
>
> ** **
>
> Indicating the high-level semantics of the JOSE structure [2] is slightly
> useful so a message can be switched to different code according to its
> structure. It is not that useful, however, as further switching is required
> to distinguish different modes (eg unprotected vs asymmetric signature vs
> MAC). This meaning only helps if the field is made mandatory, and the
> presence/absence of the "enc" field or looking up the class of the "alg"
> value are not specified as alternatives.****
>
> ** **
>
> Being able to indicate application-layer semantics [3] could theoretically
> be useful. Perhaps the "profile" attribute or "rel=’profile’" link relation
> in HTML5 is analogous. In this case JOSE should not define values for the
> field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as
> application-layer semantics — and certainly not inside the JOSE message.**
> **
>
> ** **
>
> Most (all?) of the many specs mentioning the "typ" field make it optional,
> and if they suggest particular "typ" values those are only “MAY”s or
> “SHOULD”s — not “MUST”s. Consequently, apps cannot rely on "typ" regardless
> of its meaning.****
>
> ** **
>
> ** **
>
> My suggestions:****
>
> ** **
>
> * For [1], define two media types to distinguish the two serializations,
> not a header field.****
>
> ** **
>
> *  1st preference for [3], drop it from JOSE specs; let an application
> using JOSE (eg JWT) define a field (and value) for this. If the application
> defines the field in a generic fashion for reuse by other applications that
> is a nice bonus.****
>
> ** **
>
> * 2nd preference for [3], define a field (but no values) that can hold an
> application-layer semantics identifier – but only put this definition in a
> spec that defines JOSE messages as a whole (not specs specific to JWE or
> JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.*
> ***
>
> ** **
>
> * For [2], define a mandatory field that indicates the semantics of the
> JOSE structure at a low enough level that a JOSE implementation built on
> top of a crypto library could (almost) work without needing to recognize
> the "alg" value. "typ" would have been a reasonable name for this field but
> is now too polluted with confusion. How about "t"?****
>
> Consider for instance a JOSE implementation that only supports
> "alg":"HS256". To add support for "alg":"HS3" (HMAC with SHA-3) minimal (if
> any) new code is needed in a JOSE layer: perhaps an extra table entry
> mapping the JOSE label "HS3" to a crypto library label (eg "HmacSHA3").
> "t":"mac" can accompany both these algs. To support "alg":"RS512", in
> contrast, requires calls to different crypto library functions (knowing the
> difference between public & private keys for instance). This deserves a
> separate value, say, "t":"sig".****
>
> ** **
>
> --****
>
> James Manger****
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 14:43:50 +0000

Thanks for sharing the S/MIME details.  Although I was actually making the analogy to MIME - not S/MIME.  Like many analogies, it's imperfect, but I believe still illustrative.

The reason that the analogy isn't perfect is that the JOSE data structures are used to build application-specific data structures that are legal JOSE data structures but also have additional properties - including additional header fields with specific semantics.  (When we agreed to ignore not-understood header fields we let that horse out of the barn.)  For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so they can be used by routing software.

Think of JOSE as the base class and the application types built using it as derived classes.  JWT is a derived class.  Dick's structures are a derived class.  These derived classes sometimes need names.  That's what "typ" is for.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 7:34 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field

You're mixing up "typ" and "cty".  If you want to make the analogy to S/MIME, "cty" is the equivalent to Content-Type inside the protected MIME body; "typ" is the content-type on the outer MIME header.  Pasting in an example:

-----END-----

The outer Content-Type, which is analogous to "typ", MUST be application/pkcs7-mime, with a parameter indicating the type of CMS object.  This is the same as requiring "typ" to be JWE or JWS.  The inner Content-Type (ASN.1/base64 encoded in the example) can be anything, just like "cty".

--Richard

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Requiring that the "typ" value be only "JWS" or "JWE" would be analogous to the MIME spec requiring that the Content-Type: field be only "text/plain" or "message/external-body".  It would render it useless.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>; Dick Hardt

--Richard

                                                                -- Mike

                                                                -- Mike

To: Jim Schaad

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 May 2013 07:48:45 -0700

Alternatively if you are looking at CMS it would be

typ == the ASN.1 structure at the top (i.e. id-signedData)

ctyp == embedded content type (i.e. id-ct-keyPackage)

-----BEGIN-----

     name=smime.p7m

6YT64V0GhIGfHfQbnj75

-----END-----

--Richard

 

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <[email-masked]>
wrote:

Requiring that the "typ" value be only "JWS" or "JWE" would be analogous to
the MIME spec requiring that the Content-Type: field be only "text/plain" or
"message/external-body".  It would render it useless.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]; Dick Hardt

I'm with Dick on this.  I think we should either have a mandatory indicator
of what type of JOSE object this, or nothing at all.   If the former, the
allowable values are "JWE" and "JWS".  The "+JSON" options are non-sensical
-- the app needs to know what it's parsing before it gets this header.
While I have a preference for the former (for clarity), the latter approach
is also OK with me, since the MIME types are specific to JWE/JWS.

Another approach here would be to address the JSON and compact forms
separately.  The JSON form has no need of "typ" at all, since the type of
the object is completely clear from what fields are there, e.g.,
"recipients" vs. "signatures".  For the compact form, we could do something
like James's "E."/"S." prefix idea, which you need because the dot-separated
components have different meanings and no field names to indicate this.

--Richard

wrote:

A standard library is unlikely to know the meanings of all possible "typ"
values - and more to the point, it doesn't have to.  It's the application's
job to determine that "this blob is a JOSE object" and then pass it to a
standard library, which will then ignore the "typ" value.

A standard JOSE library won't know what "typ": "JWT" means.  It won't know
what "typ": "BCGovToken" is, should the BC Government want to declare that
it's using a token with particular characteristics.  It won't know what
"typ": "XMPP" is, should XMPP want to declare that it's using a JOSE data
structure with particular characteristics.  Etc.

All these values can be registered in the registry and used by applications
that understand them.  That's the application's job - not the library's job.
The "typ" field is just there so that applications have a standard place to
make any such declarations that they may need.

                                                                -- Mike

wrote:

It's fine for your application to specify that it's required for your use
case.  Not applications need it, so they shouldn't be forced to pay the
space penalty of an unnecessary field.

                                                                -- Mike

To: Jim Schaad
Cc: [email-masked]

Jim

-- Dick

Jim

 

-- 
-- Dick 

-- 
-- Dick 

 

-- 
-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 May 2013 07:50:50 -0700

I agree that [1] is incorrect.  Given that you could encode the same JSON
object either as a JSON object or as a compact serialization (if formed
correctly) signing the serialization into the type structure seems very
awkward.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Thursday, May 30, 2013 7:39 AM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

On James's points:

(1) I think we all agree that (1) is not a useful application of "typ".  The
current docs are wrong to include the "+JSON" forms.

--Richard

On Thu, May 30, 2013 at 2:45 AM, Mike Jones <[email-masked]>
wrote:

The purpose of "typ" is your 3.

There can already be no confusion about 1 because they're syntactically
completely different.  2 is unnecessary because the "alg" value (or the
existence of "enc") already distinguishes between JWS and JWE semantics.

                                                            -- Mike

Manger, James H

It seems there are at least 3 different meanings given to "typ" in the
header of a JOSE message:

[1] The "typ" value indicates the serialization of the JOSE message. For
example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact
(dot-separated-b64-blobs) and JSON serializations.

[2] The "typ" value indicates the high-level semantics of the JOSE
structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the
semantics defined in the separate JWE and JWS specifications.

[3] The "typ" value indicates the application-layer semantics of the
message. For example, "typ":"JWT" value indicates that the message conveys a
set of claims (as a JSON object) wrapped as a JOSE message (either
unprotected, signed, MACed, encrypted, or signed then encrypted) that use
the compact serialization.

message security or semantics.

value are not specified as alternatives.

Being able to indicate application-layer semantics [3] could theoretically
be useful. Perhaps the "profile" attribute or "rel='profile'" link relation
in HTML5 is analogous. In this case JOSE should not define values for the
field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as
application-layer semantics - and certainly not inside the JOSE message.

Most (all?) of the many specs mentioning the "typ" field make it optional,
and if they suggest particular "typ" values those are only "MAY"s or
"SHOULD"s - not "MUST"s. Consequently, apps cannot rely on "typ" regardless
of its meaning.

My suggestions:

* For [1], define two media types to distinguish the two serializations, not
a header field.

*  1st preference for [3], drop it from JOSE specs; let an application using
JOSE (eg JWT) define a field (and value) for this. If the application
defines the field in a generic fashion for reuse by other applications that
is a nice bonus.

* 2nd preference for [3], define a field (but no values) that can hold an
application-layer semantics identifier - but only put this definition in a
spec that defines JOSE messages as a whole (not specs specific to JWE or
JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.

* For [2], define a mandatory field that indicates the semantics of the JOSE
structure at a low enough level that a JOSE implementation built on top of a
crypto library could (almost) work without needing to recognize the "alg"
value. "typ" would have been a reasonable name for this field but is now too
polluted with confusion. How about "t"?

separate value, say, "t":"sig".

--

James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 10:57:57 -0400

Isn't that requirement met by "cty"?  The only thing JOSE adds is a crypto
wrapper around the real application content.  If you're an application, you
know a JOSE object is the thing you want because it contains the content
you want -- it's a JWT because it contains JWT claims.

Inheritance is the wrong metaphor.  This is encapsulation of application
data:
if (jws.valid && jws.cty == "application/jwt_claims") {
    jwtClaims = jws.content;
}

--Richard

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <[email-masked]>wrote:

>  Thanks for sharing the S/MIME details.  Although I was actually making
> the analogy to MIME – not S/MIME.  Like many analogies, it’s imperfect, but
> I believe still illustrative.****
>
> ** **
>
> The reason that the analogy isn’t perfect is that the JOSE data structures
> are used to build application-specific data structures that are legal JOSE
> data structures but also have additional properties – including additional
> header fields with specific semantics.  (When we agreed to ignore
> not-understood header fields we let that horse out of the barn.)  For
> instance, Dick Hardt uses JWEs with issuer and audience fields in the
> headers, so they can be used by routing software.****
>
> ** **
>
> Think of JOSE as the base class and the application types built using it
> as derived classes.  JWT is a derived class.  Dick’s structures are a
> derived class.  These derived classes sometimes need names.  That’s what
> “typ” is for.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, May 30, 2013 7:34 AM
>
> *To:* Mike Jones
> example:****
> -----BEGIN-----****
> Content-Type: application/pkcs7-mime; smime-type=signed-data;****
>
>      name=smime.p7m****
>
> Content-Transfer-Encoding: base64****
>
> Content-Disposition: attachment; filename=smime.p7m****
>
> ** **
>
> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7****
>
> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH****
>
> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh****
>
> 6YT64V0GhIGfHfQbnj75****
>
> -----END-----****
>
> <http://tools.ietf.org/html/rfc3851#section-3.4.2>****
>
> ** **
>
> like "cty".****
> *Cc:* Jim Schaad; [email-masked]; Dick Hardt****
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 15:05:46 +0000

No, "cty" is used by the derived class to determine the type of the encapsulated field.  But that's not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameters the derived type may add to the JOSE header.  "typ" is there to provide the type of the entire object, including what you're calling the wrapper parts.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 7:58 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field

Isn't that requirement met by "cty"?  The only thing JOSE adds is a crypto wrapper around the real application content.  If you're an application, you know a JOSE object is the thing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

Inheritance is the wrong metaphor.  This is encapsulation of application data:
if (jws.valid && jws.cty == "application/jwt_claims") {
    jwtClaims = jws.content;
}

--Richard

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for sharing the S/MIME details.  Although I was actually making the analogy to MIME - not S/MIME.  Like many analogies, it's imperfect, but I believe still illustrative.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 30, 2013 7:34 AM

To: Mike Jones

-----END-----

--Richard

                                                            -- Mike

--Richard

                                                                -- Mike

                                                                -- Mike

To: Jim Schaad

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 30 May 2013 15:31:14 +0000

I think that the two fields are fine as they're currently defined, as Mike describes below. They're hanging points for information that other applications of the JOSE stack can use to switch functionality out, and as such they should be well-defined and optional to allow general libraries and applications to do their jobs.

 -- Justin

On May 29, 2013, at 7:51 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

“typ” declares what the type of THIS OBJECT is.
“cty” declares what the type of THE PAYLOAD or THE PLAINTEXT is.

They’re different.

In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a JSON Object containing Claims, is a completely different data structure from a JWT, which is a dot-separated list of base64url encoded fields.  The “cty” represents the former; the “typ” represents the latter.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]<http://augustcellars.com>]
Sent: Wednesday, May 29, 2013 4:43 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Should we delete the "typ" header field

Can you justify why the JWT spec should not specify that  it should not be “ctyp” : “JWT”?

Jim

“typ” is there so that there’s a standard header parameter field for declaring what the data structure is so that it’s there for applications for which this declaration is useful.  For instance, the JWT spec specifies that “typ”: “JWT” can be used to declare that the object is a JSON Web Token, should that be useful in context.

For those of you who may not be aware of it, the JSON Web Signature and Encryption Type Values Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-10.2> semantically ties short “typ” names to MIME types – so there’s a well-defined way that the types of JOSE objects relate to the well-established MIME type system.  In fact, MIME types are explicitly allowed to be used as “typ” values.

Ironically, there was actually a working discussion on this late 2011 and early 2012 that resulted in the decision to keep “typ” in our specs, rather than having the JWT spec define it, and that resulted in the creation of the registry.  In that thread (“[jose] Comments on the -03 JSON Web Signature document”), you wrote Jim:

[JLS] If it is believe that a parameter this list is going to be “commonly” used by many different profilers, then I believe that the core items needs to be done the in the base specification.  I would therefore not be in favor of punting it out to somebody else.  The only exception would be if we are going to have a very light core and a “real” core specs.  In this case the very light core spec could punt to the “real” core spec.  Having said that I think that a registry would be a good idea.

That’s been the state of the “typ” parameter specs ever since – I believe for the good reasons that you cited then.  I haven’t heard anyone argue that that reasoning was wrong – only that *their particular use case* may not need a “typ” value.  Just because all use cases don’t need it isn’t a sufficient argument to delete it and thereby hinder those that do.

                                                                -- Mike

Jim

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 31 May 2013 00:31:58 +0900

>From what I understand, both typ and cty are something to be consumed by
the application and not JOSE processor. From the point of view of the JOSE
processor, they should be ignored.

We could drop both fields from JOSE specs, but that is going to cause each
and every application that uses JOSE to define their own field, which is a
waste. That is why we are defining them here.

I would rather drop them than define JOSE processing semantics to these
fields.

2013/5/31 Mike Jones <[email-masked]>

>  No, “cty” is used by the derived class to determine the type of the
> encapsulated field.  But that’s not a complete description of the **entire
> object** - especially not the additional meaning imbued by the additional
> parameters the derived type may add to the JOSE header.  “typ” is there to
> provide the type of the entire object, including what you’re calling the
> wrapper parts.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *Sent:* Thursday, May 30, 2013 7:58 AM
>
> *To:* Mike Jones
> you want -- it's a JWT because it contains JWT claims.****
>
> ** **
>
> data:****
> if (jws.valid && jws.cty == "application/jwt_claims") {****
>
>     jwtClaims = jws.content;****
>
> }****
>
> ** **
>
> --Richard****
>
> ** **
>
> On Thu, May 30, 2013 at 10:43 AM, Mike Jones <[email-masked]>
> wrote:****
>
> Thanks for sharing the S/MIME details.  Although I was actually making the
> analogy to MIME – not S/MIME.  Like many analogies, it’s imperfect, but I
> believe still illustrative.****
>
>  ****
>
> *Sent:* Thursday, May 30, 2013 7:34 AM****
>
>
> *To:* Mike Jones

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Thu, 30 May 2013 11:34:51 -0400

Once upon a time there were multiple security token formats all being dot separated base64url encoded segments with the first one containing a JSON object that told the recipient what it was.

Telling the difference between a JWT, JSS, Signed Request or other token type is important in the overall processing.  If you don't know that the sender intended it to be a JWT then you could possibly do things with optional user controlled content to generate a token that might be mis interpreted at the other end.  

JWT may also place additional constraints on JOSE headers beyond what is now a quite liberal ignoring of unknown headers in JOSE

Given that we may have multiply wrapped payloads knowing what is at the soft chewy centre of the token is important so the processing can be consistent through all the layers.

"typ"is optional because in the simple single layer signature case it is typically not needed as the body is available.

John B.
On 2013-05-30, at 11:05 AM, Mike Jones <[email-masked]> wrote:

> No, “cty” is used by the derived class to determine the type of the encapsulated field.  But that’s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameters the derived type may add to the JOSE header.  “typ” is there to provide the type of the entire object, including what you’re calling the wrapper parts.
>  
>                                                             -- Mike
>  
> On Thu, May 30, 2013 at 10:43 AM, Mike Jones <[email-masked]> wrote:
> Thanks for sharing the S/MIME details.  Although I was actually making the analogy to MIME – not S/MIME.  Like many analogies, it’s imperfect, but I believe still illustrative.
>  
> The reason that the analogy isn’t perfect is that the JOSE data structures are used to build application-specific data structures that are legal JOSE data structures but also have additional properties – including additional header fields with specific semantics.  (When we agreed to ignore not-understood header fields we let that horse out of the barn.)  For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so they can be used by routing software.
>  
> Think of JOSE as the base class and the application types built using it as derived classes.  JWT is a derived class.  Dick’s structures are a derived class.  These derived classes sometimes need names.  That’s what “typ” is for.
>  
>                                                             -- Mike
>  
> On Thu, May 30, 2013 at 12:53 AM, Mike Jones <[email-masked]> wrote:
> Requiring that the “typ” value be only “JWS” or “JWE” would be analogous to the MIME spec requiring that the Content-Type: field be only “text/plain” or “message/external-body”.  It would render it useless.
>  
>                                                             -- Mike
>  
> On Wed, May 29, 2013 at 8:30 PM, Mike Jones <[email-masked]> wrote:
> A standard library is unlikely to know the meanings of all possible “typ” values – and more to the point, it doesn’t have to.  It’s the application’s job to determine that “this blob is a JOSE object” and then pass it to a standard library, which will then ignore the “typ” value.
>  
> A standard JOSE library won’t know what “typ”: “JWT” means.  It won’t know what “typ”: “BCGovToken” is, should the BC Government want to declare that it’s using a token with particular characteristics.  It won’t know what “typ”: “XMPP” is, should XMPP want to declare that it’s using a JOSE data structure with particular characteristics.  Etc.
>  
> All these values can be registered in the registry and used by applications that understand them.  That’s the application’s job – not the library’s job.  The “typ” field is just there so that applications have a standard place to make any such declarations that they may need.
>  
>                                                                 -- Mike
>  
> On Wed, May 29, 2013 at 5:03 PM, Mike Jones <[email-masked]> wrote:
> It’s fine for your application to specify that it’s required for your use case.  Not applications need it, so they shouldn’t be forced to pay the space penalty of an unnecessary field.
>  
>                                                                 -- Mike
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 May 2013 08:48:09 -0700

Ok - I am having some problems with this.  Looking at some concrete
psudo-examples

{typ:JWT, ctyp:JWT,.{type:JWT, ctyp:JWT,.{jwt claims object } }  

1.       would be a legal or a non-legal description of a signed and then
encrypted set of JWT claims?

2.       Does it make a difference if there are or are not other header
fields?

{typ:JWE, ctyp:JWT,.{type:JWS, ctyp:JWT,. {jwt claims object }}

1.        Would be a legal or a non-legal description of a signed and then
encrypted set of JWT claims?

If typ and ctyp are using the same space, does that mean that a JWT set of
claims and a JWT token are being overloaded on the what the string means?
In one case it means a token and in the other case it means a set of claims.

 

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, May 30, 2013 8:06 AM
To: Richard Barnes
Cc: Jim Schaad; [email-masked]; Dick Hardt
Subject: RE: [jose] Should we delete the "typ" header field

No, "cty" is used by the derived class to determine the type of the
encapsulated field.  But that's not a complete description of the *entire
object* - especially not the additional meaning imbued by the additional
parameters the derived type may add to the JOSE header.  "typ" is there to
provide the type of the entire object, including what you're calling the
wrapper parts.

                                                            -- Mike

Isn't that requirement met by "cty"?  The only thing JOSE adds is a crypto
wrapper around the real application content.  If you're an application, you
know a JOSE object is the thing you want because it contains the content you
want -- it's a JWT because it contains JWT claims.

    jwtClaims = jws.content;

}

--Richard

Thanks for sharing the S/MIME details.  Although I was actually making the
analogy to MIME - not S/MIME.  Like many analogies, it's imperfect, but I
believe still illustrative.

The reason that the analogy isn't perfect is that the JOSE data structures
are used to build application-specific data structures that are legal JOSE
data structures but also have additional properties - including additional
header fields with specific semantics.  (When we agreed to ignore
not-understood header fields we let that horse out of the barn.)  For
instance, Dick Hardt uses JWEs with issuer and audience fields in the
headers, so they can be used by routing software.

Think of JOSE as the base class and the application types built using it as
derived classes.  JWT is a derived class.  Dick's structures are a derived
class.  These derived classes sometimes need names.  That's what "typ" is
for.

                                                            -- Mike

To: Mike Jones

-----BEGIN-----

     name=smime.p7m

6YT64V0GhIGfHfQbnj75

-----END-----

--Richard

 

                                                            -- Mike

--Richard

                                                                -- Mike

                                                                -- Mike

To: Jim Schaad
Cc: [email-masked]

Jim

-- Dick

Jim

 

-- 
-- Dick 

-- 
-- Dick 

 

-- 
-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 May 2013 09:01:26 -0700

FWIW I am confused on what properties and values are supposed to be used
when as well.

John's email confused me even more. If "typ"="JWT" is needed for some
tokens, then it should be required for those tokens.

On Thu, May 30, 2013 at 8:48 AM, Jim Schaad <[email-masked]> wrote:

> Ok – I am having some problems with this.  Looking at some concrete
> psudo-examples****
>
> ** **
>
> {typ:JWT, ctyp:JWT,…{type:JWT, ctyp:JWT,…{jwt claims object } }  ****
>
> ** **
>
> **1.       **would be a legal or a non-legal description of a signed and
> then encrypted set of JWT claims?****
>
> **2.       **Does it make a difference if there are or are not other
> header fields?****
>
> ** **
>
> {typ:JWE, ctyp:JWT,…{type:JWS, ctyp:JWT,… {jwt claims object }}****
>
> ** **
>
> **1.       ** Would be a legal or a non-legal description of a signed and
> then encrypted set of JWT claims?****
>
> ** **
>
> *From:* Mike Jones [mailto:[email-masked]]
> *Sent:* Thursday, May 30, 2013 8:06 AM
> *To:* Richard Barnes
>
> *Subject:* RE: [jose] Should we delete the "typ" header field****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]

-- 
-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 12:08:34 -0400

A distinction without a difference.  The wrapping has no application
meaning, it's just crypto stuff.

What's the difference between a JWT and a JWE/JWS wrapping JWT claims?

That which we call a JWT, by any other name, would still ... err ...

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 30 May 2013 18:54:25 +0000

I agree that they are fine as-is. We can and should be clearer that these fields don't effect the JOSE processing but are application fields.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Thursday, May 30, 2013 8:31 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

 -- Justin

They're different.

                                                                -- Mike

Jim

                                                                -- Mike

Jim

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 17:36:52 -0400

If they don't affect JOSE, then they shouldn't be in the base spec.
--Richard

On Thursday, May 30, 2013, Anthony Nadalin wrote:

>  I agree that they are fine as-is. We can and should be clearer that
> these fields don’t effect the JOSE processing but are application fields.*
> ***
>
> ** **
>
> *From:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *On Behalf Of *Richer, Justin P.
> *Sent:* Thursday, May 30, 2013 8:31 AM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> I think that the two fields are fine as they're currently defined, as Mike
> describes below. They're hanging points for information that other
> applications of the JOSE stack can use to switch functionality out, and as
> such they should be well-defined and optional to allow general libraries
> and applications to do their jobs. ****
>
> ** **
>
>  -- Justin****
>
> ** **
>
> ** **
>
> On May 29, 2013, at 7:51 PM, Mike Jones <[email-masked]>
> wrote:****
>
>
>
> ****
>
>  “typ” declares what the type of THIS OBJECT is.****
>
> “cty” declares what the type of THE PAYLOAD or THE PLAINTEXT is.****
>
>  ****
>
> They’re different.****
>
>  ****
>
> In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a
> JSON Object containing Claims, is a completely different data structure
> from a JWT, which is a dot-separated list of base64url encoded fields.  The
> “cty” represents the former; the “typ” represents the latter.****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Wednesday, May 29, 2013 4:43 PM
> *To:* Mike Jones; [email-masked]
> Can you justify why the JWT spec shou
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 22:19:01 +0000

It's not that they affect the JOSE processing rules - it's that they make it easier for JOSE applications to have more consistent processing rules.

This brings us back full circle.  I believe that Jim's original reasoning from the 2011-2012 discussion of this still applies:

                                                                Cheers,
                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, May 30, 2013 2:37 PM
To: Anthony Nadalin
Cc: Mike Jones; Richer, Justin P.; [email-masked]; Jim Schaad
Subject: Re: [jose] Should we delete the "typ" header field

From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf Of Richer, Justin P.
Sent: Thursday, May 30, 2013 8:31 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
Subject: Re: [jose] Should we delete the "typ" header field

 -- Justin

They're different.

                                                                -- Mike

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 31 May 2013 12:04:33 +0900

+1

=nat via iPhone

May 31, 2013 7:23、Mike Jones <[email-masked]> のメッセージ:

  It’s not that they affect the JOSE processing rules – it’s that they make
it easier for JOSE applications to have more consistent processing rules.

This brings us back full circle.  I believe that Jim’s original reasoning
from the 2011-2012 discussion of this still applies:

[JLS] If it is believe that a parameter this list is going to be “commonly”
used by many different profilers, then I believe that the core items needs
to be done the in the base specification.  I would therefore not be in
favor of punting it out to somebody else.  The only exception would be if
we are going to have a very light core and a “real” core specs.  In this
case the very light core spec could punt to the “real” core spec.  Having
said that I think that a registry would be a good idea.

                                                                Cheers,

                                                                -- Mike

*From:* [email-masked]
[mailto:[email-masked]<[email-masked]>]
*On Behalf Of *Richard Barnes
*Sent:* Thursday, May 30, 2013 2:37 PM
*To:* Anthony Nadalin
*Cc:* Mike Jones; Richer, Justin P.; [email-masked]; Jim Schaad
*Subject:* Re: [jose] Should we delete the "typ" header field

--Richard

I agree that they are fine as-is. We can and should be clearer that these
fields don’t effect the JOSE processing but are application fields.

*From:* [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>[mailto:
[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>]
*On Behalf Of *Richer, Justin P.
*Sent:* Thursday, May 30, 2013 8:31 AM
*To:* Mike Jones
*Cc:* Jim Schaad;
[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
*Subject:* Re: [jose] Should we delete the "typ" header field

and applications to do their jobs.

 -- Justin

On May 29, 2013, at 7:51 PM, Mike Jones <[email-masked]> wrote:

They’re different.

In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a JSON
Object containing Claims, is a completely different data structure from a
JWT, which is a dot-separated list of base64url encoded fields.  The “cty”
represents the former; the “typ” represents the latter.

                                                                -- Mike

*From:* Jim Schaad [mailto:[email-masked]]
*Sent:* Wednesday, May 29, 2013 4:43 PM
*To:* Mike Jones; [email-masked]
*Subject:* RE: [jose] Should we delete the "typ" header field

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 May 2013 15:45:27 -0600

Nat makes a good point here, I think.

On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[email-masked]> wrote:

>> object** - especially not the additional meaning imbued by the
>> additional parameters the derived type may add to the JOSE header.  “typ”
>> is there to provide the type of the entire object, including what you’re
>> calling the wrapper parts.****
>>
>> ** **
>>
>>                                                             -- Mike****
>>
>> ** **
>>
>> Isn't that requirement met by "cty"?  The only thing JOSE adds is a
>> crypto wrapper around the real application content.  If you're an
>> application, you know a JOSE object is the thing you want because it
>> contains the content you want -- it's a JWT because it contains JWT claims.
>> ****
>>
>> ** **
>>
>> The reason that the analogy isn’t perfect is that the JOSE data
>> structures are used to build application-specific data structures that are
>> legal JOSE data structures but also have additional properties – including
>> additional header fields with specific semantics.  (When we agreed to
>> ignore not-understood header fields we let that horse out of the barn.)
>> For instance, Dick Hardt uses JWEs with issuer and audience fields in the
>> If this is the level of "type" you're referring to, I think we should
>> drop it from the spec.  It's an application-layer thing that the app can
>> add or not according to its wishes.****
>>
>>  ****
>>
>> A standard JOSE library won’t know what “typ”: “JWT” means.  It won’t
>> know what “typ”: “BCGovToken” is, should the BC Government want to declare
>> that it’s using a token with particular characteristics.  It won’t know
>> what “typ”: “XMPP” is, should XMPP want to declare that it’s using a JOSE
>> data structure with particular characteristics.  Etc.****
>>
>>  ****
>>
>>                                                                 -- Mike**
>>                                                                 -- Mike**