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

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

On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <sakimura@gmail.com> 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 <rlb@ipv.sx>
>
>> 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 <sakimura@gmail.com> wrote:
>>
>>> What about such as this?
>>>
>>> cty: original
>>> typ: timestamp
>>>
>>>
>>> 2013/6/5 Richard Barnes <rlb@ipv.sx>
>>>
>>>> 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 <
>>>> bcampbell@pingidentity.com> wrote:
>>>>
>>>>> Nat makes a good point here, I think.
>>>>>
>>>>>
>>>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <sakimura@gmail.com>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 <Michael.Jones@microsoft.com>
>>>>>>
>>>>>>>  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:rlb@ipv.sx]
>>>>>>> *Sent:* Thursday, May 30, 2013 7:58 AM
>>>>>>>
>>>>>>> *To:* Mike Jones
>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; 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 <
>>>>>>> Michael.Jones@microsoft.com> 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:rlb@ipv.sx]
>>>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM****
>>>>>>>
>>>>>>>
>>>>>>> *To:* Mike Jones
>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; 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 <
>>>>>>> Michael.Jones@microsoft.com> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On
>>>>>>> Behalf Of *Richard Barnes
>>>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM
>>>>>>> *To:* Mike Jones
>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; 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 <
>>>>>>> Michael.Jones@microsoft.com> 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:dick.hardt@gmail.com]
>>>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM
>>>>>>> *To:* Mike Jones
>>>>>>> *Cc:* Jim Schaad; jose@ietf.org****
>>>>>>>
>>>>>>>
>>>>>>> *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 <
>>>>>>> Michael.Jones@microsoft.com> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On
>>>>>>> Behalf Of *Dick Hardt
>>>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM****
>>>>>>>
>>>>>>>
>>>>>>> *To:* Jim Schaad
>>>>>>> *Cc:* jose@ietf.org
>>>>>>> *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 <ietf@augustcellars.com>
>>>>>>> wrote:****
>>>>>>>
>>>>>>> I think the values just changed****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> However the way you are using it would be an argument to say that it
>>>>>>> should be a required field.  Are you just using it as a hint if it exists
>>>>>>> and then looking at the rest of the fields if it is not present?****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> Jim****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com]
>>>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM
>>>>>>> *To:* Jim Schaad
>>>>>>> *Cc:* jose@ietf.org
>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> Well, I have been using, but now realize the spec changed or I was
>>>>>>> confused.****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on
>>>>>>> the type of token I was creating or parsing as it was easier than looking
>>>>>>> at "alg"****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> As currently defined, I don't see value in "typ".****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> -- Dick****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.com>
>>>>>>> wrote:****
>>>>>>>
>>>>>>> In reading the documents, I am trying to understand the
>>>>>>> justification for having the “typ” header parameter in the JOSE documents.
>>>>>>> ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> The purpose of the field is to hold the type of the object.  In the
>>>>>>> past, I believe that values which should now be placed in the cty field
>>>>>>> (such as “JWT”) were placed in this field as well.  However the parameter
>>>>>>> is optional and an implementation cannot rely on its being present.  This
>>>>>>> means that for all practical purposes all of the code to determine the
>>>>>>> value of the type field from the values of the alg and enc fields.  If the
>>>>>>> field was mandatory then this code would disappear at a fairly small space
>>>>>>> cost and I can understand why the parameter would be present.****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> Can anybody justify why this field should be present in the document
>>>>>>> – or should it just disappear?****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> Jim****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> --
>>>>>>> -- Dick ****
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> --
>>>>>>> -- Dick ****
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> --
>>>>>>> -- Dick ****
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>>  ****
>>>>>>>
>>>>>>> ** **
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>>
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

-- 
-- Dick