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

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