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

[Richard Barnes <[e-mail]>]

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 <[e-mail]>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:[e-mail]]
> *Sent:* Thursday, May 30, 2013 8:48 AM
> *To:* Mike Jones; 'Richard Barnes'
> *Cc:* [e-mail]; '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:[e-mail]<[e-mail]>]
>
> *Sent:* Thursday, May 30, 2013 8:06 AM
> *To:* Richard Barnes
> *Cc:* Jim Schaad; [e-mail]; Dick Hardt
> *Subject:* RE: [jose] Should we delete the "typ" header field****
>
> ** **
>
> 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] <[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****
>
>  ****
>
>  ****
>
> ** **
>