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

[Brian Campbell <[e-mail]>]

Nat makes a good point here, I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[e-mail]> 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 <[e-mail]>
>
>>  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:[e-mail]]
>> *Sent:* Thursday, May 30, 2013 7:58 AM
>>
>> *To:* Mike Jones
>> *Cc:* Jim Schaad; [e-mail]; 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 <[e-mail]>
>> 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:[e-mail]]
>> *Sent:* Thursday, May 30, 2013 7:34 AM****
>>
>>
>> *To:* Mike Jones
>> *Cc:* Jim Schaad; [e-mail]; 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 <[e-mail]>
>> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
>> Of *Richard Barnes
>> *Sent:* Wednesday, May 29, 2013 8:03 PM
>> *To:* Mike Jones
>> *Cc:* Jim Schaad; [e-mail]; 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 <[e-mail]>
>> 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:[e-mail]]
>> *Sent:* Wednesday, May 29, 2013 5:18 PM
>> *To:* Mike Jones
>> *Cc:* Jim Schaad; [e-mail]****
>>
>>
>> *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 <[e-mail]>
>> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
>> Of *Dick Hardt
>> *Sent:* Wednesday, May 29, 2013 4:56 PM****
>>
>>
>> *To:* Jim Schaad
>> *Cc:* [e-mail]
>> *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 <[e-mail]>
>> 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:[e-mail]]
>> *Sent:* Wednesday, May 29, 2013 3:49 PM
>> *To:* Jim Schaad
>> *Cc:* [e-mail]
>> *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 <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> --
>> -- Dick ****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> --
>> -- Dick ****
>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> --
>> -- Dick ****
>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>>  ****
>>
>>  ****
>>
>> ** **
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>