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

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Jun 2013 11:28:57 -0400

It would be a good point, if it were true :)  In particular, this part:
"[dropping 'typ'] is going to cause each and every application that uses
JOSE to define their own field"

So far, I've heard of exactly one application of JOSE that requires "typ"
in the way it is currently specified, namely JWT.

On the other hand, Dick's applications are apparently using it differently
(and, IMO, properly) to distinguish JWE/JWS.  Then there are all the
applications out there that are OK using application context and "cty" to
recognize what type of object they have.  Apps using CMS have been doing
this for ages.

So it's not at all clear to me that there's any other application that
would use "typ" besides JWT.  And it's not clear to me that JWT needs it.

--Richard

On Fri, May 31, 2013 at 5:45 PM, Brian Campbell
<[email-masked]>wrote:

> Nat makes a good point here, I think.
>
>
> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[email-masked]> wrote:
>
>> 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****
>>>
>>> ** **
>>>
>>> *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]> 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
>>> *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:****
>>>
>>>  ****
>>>
>>> -----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****
>>>
>>>  ****
>>>
>>> *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]>
>>> 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*
>>> ***
>>>
>>>  ****
>>>
>>> *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.****
>>>
>>>  ****
>>>
>>> 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]
>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>
>>>  ****
>>>
>>> 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.****
>>>
>>>  ****
>>>
>>> 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:****
>>>
>>> In reading the documents, I am trying to understand the justification
>>> for having the “typ” header parameter in the JOSE documents.****
>>>
>>>  ****
>>>
>>> The purpose of the field is to hold the type of the object.  In the
>>> past, I believe that values which should now be placed in the cty field
>>> (such as “JWT”) were placed in this field as well.  However the parameter
>>> is optional and an implementation cannot rely on its being present.  This
>>> means that for all practical purposes all of the code to determine the
>>> value of the type field from the values of the alg and enc fields.  If the
>>> field was mandatory then this code would disappear at a fairly small space
>>> cost and I can understand why the parameter would be present.****
>>>
>>>  ****
>>>
>>> Can anybody justify why this field should be present in the document –
>>> or should it just disappear?****
>>>
>>>  ****
>>>
>>> Jim****
>>>
>>>  ****
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>>
>>>
>>> ****
>>>
>>>  ****
>>>
>>> --
>>> -- Dick ****
>>>
>>>
>>>
>>> ****
>>>
>>>  ****
>>>
>>> --
>>> -- Dick ****
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>>
>>>
>>> ****
>>>
>>>  ****
>>>
>>> --
>>> -- Dick ****
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>> _______________________________________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 5 Jun 2013 21:53:54 +0900

What about such as this?

cty: original
typ: timestamp

2013/6/5 Richard Barnes <[email-masked]>

> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell <
> [email-masked]> wrote:
>
>>>> Inheritance is the wrong metaphor.  This is encapsulation of
>>>> application data:****
>>>>
>>>> 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
>>>> 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
>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones <
>>>> pass it to a standard library, which will then ignore the “typ” value.*
>>>> ***
>>>>
>>>>  ****
>>>>
>>>>                                                                 -- Mike
>>>> 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 <
>>>>                                                                 -- Mike
>>>> *From:* [email-masked] [mailto:[email-masked]] *On
>>>> Behalf Of *Dick Hardt
>>>> I think it should be required rather than be a hint if it is going ot
>>>> be there.****
>>>>
>>>>  ****
>>>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jun 2013 10:14:19 -0400

I'm not sure I understand the use case here.  Let me look at a couple of
options, and hopefully one of them will be what you meant :)

If it's just a signed timestamp you're talking about, then that's
adequately described by cty="timestamp", typ="JWS".

If you want to sign something and add a timestamp in the header, then
typ="timestamp" isn't accurate according to the current specification.  The
type of the whole object would have to be something like
"timestamped-content".  And in that case, an application can easily
recognized that it's timestamped content by looking for the timestamp field
in the header, so the "typ" isn't really helpful.

Moving from the example to the general question:

I think we finally have some common understanding on this list as to what
Mike means by "typ" in the current document -- a label for the
application-layer type of the overall object.  Thanks to Mike for
clarifying that in this discussion.

The question is whether this is a sufficiently useful thing to have in the
core spec.  Obviously, applications have to know what type of object
they're dealing with when they get a JOSE object.  That includes (1) what
type of content is in the payload, and (2) what application-layer fields
are required to be in the header.  (1) is covered by "cty".  So "typ" is
only useful in the case where:
A. The application is storing application-layer data in the JOSE header
B. The required application-layer fields can be different for different
objects
C. The required application-layer fields can be different for different
objects of the same content type
D. The required application-layer fields are not indicated by other
application-layer context

Are there any known applications that meet these criteria?  JWT does not,
for several reasons.
1. (!A) JWT does not store application-layer data in the JOSE header, only
in the claims in the body
2. (!C) A JWT object can indicate with "cty" that it contains JWT claims or
another JWT, either of which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type of
token is being presented, e.g., JWT

So there's not really any known use case for "typ" as currently specified.
 On the other hand, Dick and James have pointed out that it can be useful
to have "typ" indicate whether the object at hand is a JWE or JWS.  Which
brings us back to:
-- Change the definition of "typ" so that it indicates the JOSE-layer type
(JWE/JWS)
-- Remove "typ" altogether

On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <[email-masked]> wrote:

>> On the other hand, Dick's applications are apparently using it
>> differently (and, IMO, properly) to distinguish JWE/JWS.  Then there are
>> all the applications out there that are OK using application context and
>> "cty" to recognize what type of object they have.  Apps using CMS have been
>> doing this for ages.
>>
>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[email-masked]>wrote:
>>>
>>>> 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.
>>>>
>>>>>                                                             -- Mike***
>>>>>                                                             -- Mike***
>>>>> “text/plain” or “message/external-body”.  It would render it useless.*
>>>>> ***
>>>>>
>>>>>  ****
>>>>>
>>>>>                                                             -- Mike***
>>>>> *
>>>>>
>>>>>  ****
>>>>>
>>>>> pass it to a standard library, which will then ignore the “typ” value.
>>>>> ****
>>>>>
>>>>>  ****
>>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 6 Jun 2013 09:31:55 +0900

What I was thinking as an example was to have 'datetime' as a public header
parameter to be used generally, and then differentiate between two cases of
'agreement' and 'timestamp'. It is the same signing operation over the
original (e.g., a MS word document), but from an application point of view,
it is a bit different. Former constitute an agreement while the later does
not. The type=timestamp just signifies that the original document existed
at the time indicated.

> 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims
> or another JWT, either of which makes it obvious that this is a JWT
>>> "[dropping 'typ'] is going to cause each and every application that
>>> uses JOSE to define their own field"
>>>
>>> So far, I've heard of exactly one application of JOSE that requires
>>> "typ" in the way it is currently specified, namely JWT.
>>>
>>>>> I would rather drop them than define JOSE processing semantics to
>>>>> these fields.
>>>>>
>>>>>
>>>>>>                                                             -- Mike**
>>>>>> 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**
>>>>>> “text/plain” or “message/external-body”.  It would render it useless.
>>>>>> ****
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>>                                                             -- Mike**
>>>>>> **
>>>>>>
>>>>>>  ****
>>>>>>
>>>>>> “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****
>>>>>> 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, 5 Jun 2013 17:36:01 -0700

Why would you need that in the header? Why not in the payload?

On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <[email-masked]> wrote:

> What I was thinking as an example was to have 'datetime' as a public
> header parameter to be used generally, and then differentiate between two
> cases of 'agreement' and 'timestamp'. It is the same signing operation over
> the original (e.g., a MS word document), but from an application point of
> view, it is a bit different. Former constitute an agreement while the later
> does not. The type=timestamp just signifies that the original document
> existed at the time indicated.
>
>
>> The question is whether this is a sufficiently useful thing to have in
>> the core spec.  Obviously, applications have to know what type of object
>> 1. (!A) JWT does not store application-layer data in the JOSE header,
>> only in the claims in the body
>> So there's not really any known use case for "typ" as currently
>> specified.  On the other hand, Dick and James have pointed out that it can
>> be useful to have "typ" indicate whether the object at hand is a JWE or
>> JWS.  Which brings us back to:
>> -- Change the definition of "typ" so that it indicates the JOSE-layer
>> type (JWE/JWS)
>>>>>>>  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*
>>>>>>> ***
>>>>>>>
>>>>>>> ** **
>>>>>>>
>>>>>>> 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*
>>>>>>> ***
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> 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-----****
>>>>>>>
>>>>>>> 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.****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> 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****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> I think it should be required rather than be a hint if it is going
>>>>>>> ot be there.****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> 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"****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> In reading the documents, I am trying to understand the
>>>>>>> justification for having the “typ” header parameter in the JOSE documents.
>>>>>>> ****
>>>>>>>
>>>>>>>  ****
>>>>>>>

-- 
-- Dick

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 6 Jun 2013 10:03:56 +0900

It is giving the meaning to the signature - metadata about the signature,
so I thought header would be more appropriate, besides, the payload is
binary and I can avoid double base64 encoding that way.

2013/6/6 Dick Hardt <[email-masked]>

>>> I think we finally have some common understanding on this list as to
>>> what Mike means by "typ" in the current document -- a label for the
>>> Are there any known applications that meet these criteria?  JWT does
>>> not, for several reasons.
>>> 3. (!D) In the OAuth context, the Token Type value indicates what type
>>> of token is being presented, e.g., JWT
>>>
>>>>> It would be a good point, if it were true :)  In particular, this
>>>>> part: "[dropping 'typ'] is going to cause each and every application
>>>>> that uses JOSE to define their own field"
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> 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.,
>>>>>>>> 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****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Can anybody justify why this field should be present in the
>>>>>>>> document – or should it just disappear?****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>> Jim****
>>>>>>>>
>>>>>>>>  ****
>>>>>>>>
>>>>>>>>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 6 Jun 2013 12:18:57 +1000

> typ: timestamp

By verifying a signed JOSE message you know that the holder of the corresponding private key "processed" the bytes of the content.
What it doesn't tell you is whether the signer meant:
1. They didn't look at the content (eg signing an authentication challenge; timestamping arbitrary data)
2. They are vouching for the syntax, not meaning, of the content (eg anti-malware check; syntax checker)
3. They are committing to the content (eg signing a contract; vouching for claims)

It is probably best for the distinction between these to be bound to the verification public key. For instance, including a critical extendedKeyUsage extension in the public key's certificate with a value id-kp-timeStamping [RFC3161 Time-Stamp Protocol].

Next, the content type ('cty' field) should distinguish these cases. Signing the same JWT claim set, but with 'cty' set to 'application/octet-stream', 'application/json', or 'application/jwt+json'(*) could/should imply different meanings (1, 2, and 3 respectively).

Even if there are cases where a header parameter is useful for this purpose (despite JWE/JWS nor JWT being such a use case), 'typ' as currently defined cannot be the answer as it is optional and ignorable. A recipient receiving a JOSE message with {"typ":"timestamp"...} can legitimately ignore "typ" and assume the signer is committing to the content.

(*) I don't think application/jwt+json is a defined media type. I didn't use application/jwt as it is defined in the JWT draft as a media type for JOSE messages (which is crazy), instead of a media type for a JSON object holding claims (which it should be).

--
James Manger

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 12:11:23 +0200

My take on the "typ" header field:

-          "typ" must be optional because some application just knows what it is dealing with. It is a waste of space in this case.

-          "typ" is reserved header name and the values SHOULD be JWS, JWE, JWT. No MUST on the values.

-          For a general purpose JOSE library it makes sense to have "typ" and I would write it so that it  throws an exception on validateJWS( {"typ":"JWE", ...})
Especially if crit=["typ"].

I would like to keep (the first paragraph of)
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-4.1.8
as it is.

-Axel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Thursday, June 06, 2013 3:04 AM
To: Dick Hardt
Cc: Richard Barnes; Mike Jones; Brian Campbell; Jim Schaad; [email-masked]
Subject: Re: [jose] Should we delete the "typ" header field

It is giving the meaning to the signature - metadata about the signature, so I thought header would be more appropriate, besides, the payload is binary and I can avoid double base64 encoding that way.

2013/6/6 Dick Hardt <[email-masked]<mailto:[email-masked]>>
Why would you need that in the header? Why not in the payload?

On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
What I was thinking as an example was to have 'datetime' as a public header parameter to be used generally, and then differentiate between two cases of 'agreement' and 'timestamp'. It is the same signing operation over the original (e.g., a MS word document), but from an application point of view, it is a bit different. Former constitute an agreement while the later does not. The type=timestamp just signifies that the original document existed at the time indicated.

2013/6/5 Richard Barnes <[email-masked]<mailto:[email-masked]>>
I'm not sure I understand the use case here.  Let me look at a couple of options, and hopefully one of them will be what you meant :)

If it's just a signed timestamp you're talking about, then that's adequately described by cty="timestamp", typ="JWS".

If you want to sign something and add a timestamp in the header, then typ="timestamp" isn't accurate according to the current specification.  The type of the whole object would have to be something like "timestamped-content".  And in that case, an application can easily recognized that it's timestamped content by looking for the timestamp field in the header, so the "typ" isn't really helpful.

I think we finally have some common understanding on this list as to what Mike means by "typ" in the current document -- a label for the application-layer type of the overall object.  Thanks to Mike for clarifying that in this discussion.

The question is whether this is a sufficiently useful thing to have in the core spec.  Obviously, applications have to know what type of object they're dealing with when they get a JOSE object.  That includes (1) what type of content is in the payload, and (2) what application-layer fields are required to be in the header.  (1) is covered by "cty".  So "typ" is only useful in the case where:
A. The application is storing application-layer data in the JOSE header
B. The required application-layer fields can be different for different objects
C. The required application-layer fields can be different for different objects of the same content type
D. The required application-layer fields are not indicated by other application-layer context

Are there any known applications that meet these criteria?  JWT does not, for several reasons.
1. (!A) JWT does not store application-layer data in the JOSE header, only in the claims in the body
2. (!C) A JWT object can indicate with "cty" that it contains JWT claims or another JWT, either of which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type of token is being presented, e.g., JWT

So there's not really any known use case for "typ" as currently specified.  On the other hand, Dick and James have pointed out that it can be useful to have "typ" indicate whether the object at hand is a JWE or JWS.  Which brings us back to:
-- Change the definition of "typ" so that it indicates the JOSE-layer type (JWE/JWS)
-- Remove "typ" altogether

On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
What about such as this?

cty: original
typ: timestamp

2013/6/5 Richard Barnes <[email-masked]<mailto:[email-masked]>>
It would be a good point, if it were true :)  In particular, this part: "[dropping 'typ'] is going to cause each and every application that uses JOSE to define their own field"

So far, I've heard of exactly one application of JOSE that requires "typ" in the way it is currently specified, namely JWT.

On the other hand, Dick's applications are apparently using it differently (and, IMO, properly) to distinguish JWE/JWS.  Then there are all the applications out there that are OK using application context and "cty" to recognize what type of object they have.  Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any other application that would use "typ" besides JWT.  And it's not clear to me that JWT needs it.

--Richard

On Fri, May 31, 2013 at 5:45 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Nat makes a good point here, I think.

On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
>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]<mailto:[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

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

To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[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.

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]<mailto:[email-masked]>]
Sent: Thursday, May 30, 2013 7:34 AM

To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[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:

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

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.

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]<mailto:[email-masked]>]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[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.

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

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
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we delete the "typ" header field

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

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]<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.

The purpose of the field is to hold the type of the object.  In the past, I believe that values which should now be placed in the cty field (such as "JWT") were placed in this field as well.  However the parameter is optional and an implementation cannot rely on its being present.  This means that for all practical purposes all of the code to determine the value of the type field from the values of the alg and enc fields.  If the field was mandatory then this code would disappear at a fairly small space cost and I can understand why the parameter would be present.

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

Jim

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

--
-- Dick

--
-- Dick

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

--
-- Dick

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

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

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

--
-- Dick

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 9 Jun 2013 22:39:59 -0700

<no hat>

I kept trying to send this message out during the last week, but I have been
doing too much physical activity to be awake at night and produce a coherent
message.

The opinions here are my personal opinions, some of them might be things
that I would also advocate as a chair, but don't assume just because it is
here I would.

I have been looking at the conversation on this topic with slight surprise,
I did not really expect this type of firestorm to occur on a part of the
spec that had been in for quite a while.

Givens:
1.  My general inclination is that things in the document generally stay in
the document, however they do need to be shown to be clearly described and
useful.

2.  My general inclination is that things which can be shown to be useful
for multiple applications can be done in the base document.  That said,
there is nothing that says such a thing could not be defined in one of the
application specs which uses it rather than the base document.

My understanding:

My understanding of what Mike has said is that this field is meant to
clearly present that this is a JSON thing for a specific application.  This
is contrary to the expectation that Richard, Dick and myself had where it
was a description of the "security service" rather than the application.

My problem with this understanding is I am not sure when it is a useful
concept to have.  In order for it to be needed you would need to have two
statements being true:

1.  There is no way to know the application from the current protocol being
exercised and
2.  There is no way to correctly infer the application from the value of the
ctyp field (if present).

Under the current circumstances as I understand the JWT specification,
neither of these criteria would be met.

Nat gave an interesting example of a case where it might be useful, that of
a Time Stamp Provider.  My problem with this is that I don't think of this
as being an application protocol, but as being a different security service.
Thus a timestamp JWS is a specialized version of a normal JWS.  As such, yes
it would make sense to me that the type field could be used to differentiate
between a normal JWS and a timestamp-JWS.  But a timestamp would be, by
definition, completely agnostic about the inner content provided.  The same
could not be said of a JWT application.  It needs to understand the specific
inner content that was provided.  

SideBar:  It is not immediately clear to me that a classic timestamp
provider could be done using the JOSE data structures as it normally
requires that one can produce a timestamp without sharing the content with
the timestamp producer.  There are also interesting discussions on if the
fact that it is a timestamp or other special signature should be signaled in
the signature object or as a key parameter.  However none of this paragraph
is relevant to the current discussion.

I think that I would like to see the following things:

1.  Two clear use cases provided, one for JWT and one for something else
where the typ field as an application indicator would be useful/required.  I
think that such a thing needs to address the two points that I presented
previously.

2.  I don't believe that anyone has addressed the question I raised about
the fact that both the ctyp and typ fields are using the same registry, thus
JWT would mean different things depending on which field it is in.

3.  I had a message dated 5/30/13 where I asked a couple of questions.  This
message was not responded to.

Jim

---

From: Mike Jones <[email-masked]>
Date: Tue, 11 Jun 2013 00:25:02 +0000

Answering Jim's message that inadvertently went unanswered...

Neither of these would be correct because of the last "cty":"JWT" in both examples.  That's because a JWT Claims Set is not a JWT.  You would need to omit the last "cty":"JWT" in both examples for this to be correct.

No, there is no overloading.  JWT uses the absence of a "cty" value to say that the payload is a JWT Claims Set - which is the default case.

                                                                -- Mike

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

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]<mailto:[email-masked]>; Dick Hardt
Subject: RE: [jose] Should we delete the "typ" header field

                                                            -- Mike

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

--Richard

                                                            -- Mike

To: Mike Jones

-----END-----

--Richard

                                                            -- Mike

--Richard

                                                                -- Mike

                                                                -- Mike

To: Jim Schaad

Jim

-- Dick

Jim

--
-- Dick

--
-- Dick

--
-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Tue, 11 Jun 2013 14:58:21 -0400

Let me try to patch Jim's example and illustrate why there's no need for
"typ" here.  Starting with a JWT in an OAuth header:

Authorization: JWT { "typ": "JWT", "cty": "JWT", ... { "typ": "JWT", "cty":
"JWT", ... { "typ": "JWT", ... [ claims ] }}}

They "typ" does nothing here, because the type is always known from a level
up.  Worse, it introduces the possibility of conflict.  What if "cty" is
"JWT", but at the next level down, "typ" is not "JWT"?   I notice you
didn't answer Jim's question about this case, where the next level down has
"typ":"JWS" and not "JWT".

The following syntax, without "typ", gives you the same amount of
information:

Authorization: JWT { "cty": "JWT", ... { "cty": "JWT", ... { ... [ claims ]
}}}

--Richard

On Mon, Jun 10, 2013 at 8:25 PM, Mike Jones <[email-masked]>wrote:

>  Answering Jim’s message that inadvertently went unanswered…****
>
> ** **
>
> Neither of these would be correct because of the last “cty”:”JWT” in both
> examples.  That’s because a JWT Claims Set is not a JWT.  You would need to
> omit the last “cty”:”JWT” in both examples for this to be correct.****
>
> ** **
>
> No, there is no overloading.  JWT uses the absence of a “cty” value to say
> that the payload is a JWT Claims Set – which is the default case.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Thursday, May 30, 2013 8:48 AM
> *To:* Mike Jones; 'Richard Barnes'
> *Cc:* [email-masked]; 'Dick Hardt'
>
> *Subject:* RE: [jose] Should we delete the "typ" header field****
>
>  ** **
>
> 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]<[email-masked]>]
>
> *Sent:* Thursday, May 30, 2013 8:06 AM
> *To:* Richard Barnes
> *Subject:* RE: [jose] Should we delete the "typ" header field****
>
> ** **
>
> 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] <[email-masked]>]
> 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.****
>
> ** **
>
> 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
> On Thu, May 30, 2013 at 12:53 AM, Mike Jones <[email-masked]>
> wrote:****
>
> “text/plain” or “message/external-body”.  It would render it useless.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> 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 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
> 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.****
>
>  ****
>
> 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
> 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"*
> ***
>
>  ****
>
> 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
> Can anybody justify why this field should be present in the document – or
> should it just disappear?****
>
>  ****
>
> Jim****
>
>  ****
>
>