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

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