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

From: "Manger, James H" <[email-masked]>
Date: Thu, 30 May 2013 17:17:17 +1000

> The purpose of “typ” is your 3.

Then why define "typ":"JWS", "typ":"JWS+JSON", "typ":"JWE", and "typ":"JWE+JSON"?
These values cause confusion as they only make sense for purposes [1] and [2].

The text describing "typ" says it declares the “type of this object”.
This clearly also causes massive confusion. The object is obviously a JOSE message; it is also obviously a JWS or JWE; it might also be a JWT, or a missile launch instruction, or a meeting invitation, or anything. “type” and “object” are too generic for readers to get the same understanding.

At a minimum it should be radically rephrased. Perhaps:
“The "xxx" header parameter can be used to hold an application-specific string identifying the meaning of a JOSE message to an application. This parameter has no affect on JOSE processing.”

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, 30 May 2013 4:45 PM
To: Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Should we delete the "typ" header field

The purpose of “typ” is your 3.

There can already be no confusion about 1 because they’re syntactically completely different.  2 is unnecessary because the “alg” value (or the existence of “enc”) already distinguishes between JWS and JWE semantics.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Wednesday, May 29, 2013 11:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we delete the "typ" header field

> Can anybody justify why this field should be present in the document – or should it just disappear?

It seems there are at least 3 different meanings given to "typ" in the header of a JOSE message:

[1] The "typ" value indicates the serialization of the JOSE message. For example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact (dot-separated-b64-blobs) and JSON serializations.

[2] The "typ" value indicates the high-level semantics of the JOSE structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the semantics defined in the separate JWE and JWS specifications.

[3] The "typ" value indicates the application-layer semantics of the message. For example, "typ":"JWT" value indicates that the message conveys a set of claims (as a JSON object) wrapped as a JOSE message (either unprotected, signed, MACed, encrypted, or signed then encrypted) that use the compact serialization.

Indicating the serialization [1] does not seem helpful as the recipient needs to know the serialization before they can extract the header to see the "typ" value. Indicating the serialization is actually harmful as it tightly couples a message to one serialization, whereas serialization is generally thought of as a transport-layer choice that is independent of the message security or semantics.

Indicating the high-level semantics of the JOSE structure [2] is slightly useful so a message can be switched to different code according to its structure. It is not that useful, however, as further switching is required to distinguish different modes (eg unprotected vs asymmetric signature vs MAC). This meaning only helps if the field is made mandatory, and the presence/absence of the "enc" field or looking up the class of the "alg" value are not specified as alternatives.

Being able to indicate application-layer semantics [3] could theoretically be useful. Perhaps the "profile" attribute or "rel=’profile’" link relation in HTML5 is analogous. In this case JOSE should not define values for the field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as application-layer semantics — and certainly not inside the JOSE message.

Most (all?) of the many specs mentioning the "typ" field make it optional, and if they suggest particular "typ" values those are only “MAY”s or “SHOULD”s — not “MUST”s. Consequently, apps cannot rely on "typ" regardless of its meaning.

My suggestions:

* For [1], define two media types to distinguish the two serializations, not a header field.

*  1st preference for [3], drop it from JOSE specs; let an application using JOSE (eg JWT) define a field (and value) for this. If the application defines the field in a generic fashion for reuse by other applications that is a nice bonus.

* 2nd preference for [3], define a field (but no values) that can hold an application-layer semantics identifier – but only put this definition in a spec that defines JOSE messages as a whole (not specs specific to JWE or JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.

* For [2], define a mandatory field that indicates the semantics of the JOSE structure at a low enough level that a JOSE implementation built on top of a crypto library could (almost) work without needing to recognize the "alg" value. "typ" would have been a reasonable name for this field but is now too polluted with confusion. How about "t"?
Consider for instance a JOSE implementation that only supports "alg":"HS256". To add support for "alg":"HS3" (HMAC with SHA-3) minimal (if any) new code is needed in a JOSE layer: perhaps an extra table entry mapping the JOSE label "HS3" to a crypto library label (eg "HmacSHA3"). "t":"mac" can accompany both these algs. To support "alg":"RS512", in contrast, requires calls to different crypto library functions (knowing the difference between public & private keys for instance). This deserves a separate value, say, "t":"sig".

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 May 2013 07:21:53 +0000

I agree, given this thread, that clarified wording is in order along the lines of that which you suggest.  Thanks for writing it.  I’ll put doing so on my to-do list.

The purpose of the “JWS” and “JWE” types is to provide standard identifiers for applications that may want to use them, either in the “typ” field or the “cty” field (the values of which are in the same namespace).  I’ll plan to similarly clarify that the semantics of “cty” are application-specific and the contents of “cty” do not affect the JOSE processing.

                                                            Best wishes,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, May 30, 2013 12:17 AM
To: [email-masked]
Subject: [jose] FW: Should we delete the "typ" header field

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 30 May 2013 18:09:53 +1000

> The purpose of the “JWS” and “JWE” types is to provide standard identifiers for applications that may want to use them, either in the “typ” field

Don’t do that. We already know it’s a JOSE message. We already know it’s a JWE or JWS by alg or enc (or [2]). So typ:JWE or typ:JWS can add nothing but confusion. If an app has no extra semantics above it being a JOSE message, then they should omit “typ”.

> or the “cty” field (the values of which are in the same namespace).

> I’ll plan to similarly clarify that the semantics of “cty” are application-specific and the contents of “cty” do not affect the JOSE processing.

Don’t do that. “cty” is the media type of the content. It is clear that this is metadata about the content and doesn’t affect JOSE processing (of this message). Media types are well defined so there is no need to call them application-specific.

Suggested simplification: Define “cty” as holding the media type of the content. State that an “application/” prefix may be omitted to save a few bytes for this common case. To reconstruct the full media type, add a “application/” prefix if and only if there is no “/” before the first “;” in the value.
No registry needed.

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, 30 May 2013 5:22 PM
To: Manger, James H; [email-masked]
Subject: RE: [jose] FW: Should we delete the "typ" header field

                                                            Best wishes,
                                                            -- Mike

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 May 2013 10:42:23 -0400

+1 to everything James says here.

"cty" == Content-Type.  It's just a MIME type for the encapsulated content.

The "application/" hack is clever.  I would like some apps people to
review, but it seems workable to me at first blush.

On Thu, May 30, 2013 at 4:09 AM, Manger, James H <
[email-masked]> wrote:

> > The purpose of the “JWS” and “JWE” types is to provide standard
> identifiers for applications that may want to use them, either in the “typ”
> field****
>
> ** **
>
> Don’t do that. We already know it’s a JOSE message. We already know it’s a
> JWE or JWS by alg or enc (or [2]). So typ:JWE or typ:JWS can add nothing
> but confusion. If an app has no extra semantics above it being a JOSE
> message, then they should omit “typ”.****
>
> ** **
>
> > or the “cty” field (the values of which are in the same namespace).  ***
> *
>
> ** **
>
> > I’ll plan to similarly clarify that the semantics of “cty” are
> application-specific and the contents of “cty” do not affect the JOSE
> processing.****
>
> ** **
>
> Don’t do that. “cty” is the media type of the content. It is clear that
> this is metadata about the content and doesn’t affect JOSE processing (of
> this message). Media types are well defined so there is no need to call
> them application-specific.****
>
> ** **
>
> Suggested simplification: Define “cty” as holding the media type of the
> content. State that an “application/” prefix may be omitted to save a few
> bytes for this common case. To reconstruct the full media type, add a
> “application/” prefix if and only if there is no “/” before the first “;”
> in the value.****
>
> No registry needed.****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* Mike Jones [mailto:[email-masked]]
> *Sent:* Thursday, 30 May 2013 5:22 PM
>
> *To:* Manger, James H; [email-masked]
> *Subject:* RE: [jose] FW: Should we delete the "typ" header field****
>
> ** **
>
> I agree, given this thread, that clarified wording is in order along the
> lines of that which you suggest.  Thanks for writing it.  I’ll put doing so
> on my to-do list.****
>
> ** **
>
> The purpose of the “JWS” and “JWE” types is to provide standard
> identifiers for applications that may want to use them, either in the “typ”
> field or the “cty” field (the values of which are in the same namespace).
> I’ll plan to similarly clarify that the semantics of “cty” are
> application-specific and the contents of “cty” do not affect the JOSE
> processing.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Manger, James H
> *Sent:* Thursday, May 30, 2013 12:17 AM
> *To:* [email-masked]
> *Subject:* [jose] FW: Should we delete the "typ" header field****
>
> ** **
>
> > The purpose of “typ” is your 3.****
>
> ** **
>
> Then why define "typ":"JWS", "typ":"JWS+JSON", "typ":"JWE", and
> "typ":"JWE+JSON"?****
>
> These values cause confusion as they only make sense for purposes [1] and
> [2].****
>
> ** **
>
> The text describing "typ" says it declares the “type of this object”.****
>
> This clearly also causes massive confusion. The object is obviously a JOSE
> message; it is also obviously a JWS or JWE; it might also be a JWT, or a
> missile launch instruction, or a meeting invitation, or anything. “type”
> and “object” are too generic for readers to get the same understanding.***
> *
>
> ** **
>
> At a minimum it should be radically rephrased. Perhaps:****
>
> “The "xxx" header parameter can be used to hold an application-specific
> string identifying the meaning of a JOSE message to an application. This
> parameter has no affect on JOSE processing.”****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* Mike Jones [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Thursday, 30 May 2013 4:45 PM
> *To:* Manger, James H; [email-masked]
> *Subject:* RE: [jose] Should we delete the "typ" header field****
>
> ** **
>
> The purpose of “typ” is your 3.****
>
> ** **
>
> There can already be no confusion about 1 because they’re syntactically
> completely different.  2 is unnecessary because the “alg” value (or the
> existence of “enc”) already distinguishes between JWS and JWE semantics.**
> **
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Manger, James H
> *Sent:* Wednesday, May 29, 2013 11:08 PM
> *To:* [email-masked]
> *Subject:* Re: [jose] Should we delete the "typ" header field****
>
> ** **
>
> > Can anybody justify why this field should be present in the document –
> or should it just disappear?****
>
> ** **
>
> It seems there are at least 3 different meanings given to "typ" in the
> header of a JOSE message:****
>
> ** **
>
> [1] The "typ" value indicates the serialization of the JOSE message. For
> example, "typ":"JWE" and "typ":"JWE+JSON" distinguish the compact
> (dot-separated-b64-blobs) and JSON serializations.****
>
> ** **
>
> [2] The "typ" value indicates the high-level semantics of the JOSE
> structure. For example, "typ":"JWE" and "typ":"JWS" distinguish the
> semantics defined in the separate JWE and JWS specifications.****
>
> ** **
>
> [3] The "typ" value indicates the application-layer semantics of the
> message. For example, "typ":"JWT" value indicates that the message conveys
> a set of claims (as a JSON object) wrapped as a JOSE message (either
> unprotected, signed, MACed, encrypted, or signed then encrypted) that use
> the compact serialization.****
>
> ** **
>
> Indicating the serialization [1] does not seem helpful as the recipient
> needs to know the serialization before they can extract the header to see
> the "typ" value. Indicating the serialization is actually harmful as it
> tightly couples a message to one serialization, whereas serialization is
> generally thought of as a transport-layer choice that is independent of the
> message security or semantics.****
>
> ** **
>
> Indicating the high-level semantics of the JOSE structure [2] is slightly
> useful so a message can be switched to different code according to its
> structure. It is not that useful, however, as further switching is required
> to distinguish different modes (eg unprotected vs asymmetric signature vs
> MAC). This meaning only helps if the field is made mandatory, and the
> presence/absence of the "enc" field or looking up the class of the "alg"
> value are not specified as alternatives.****
>
> ** **
>
> Being able to indicate application-layer semantics [3] could theoretically
> be useful. Perhaps the "profile" attribute or "rel=’profile’" link relation
> in HTML5 is analogous. In this case JOSE should not define values for the
> field. "JWS", "JWS+JSON", "JWE", and "JWE+JSON" make no sense as
> application-layer semantics — and certainly not inside the JOSE message.**
> **
>
> ** **
>
> Most (all?) of the many specs mentioning the "typ" field make it optional,
> and if they suggest particular "typ" values those are only “MAY”s or
> “SHOULD”s — not “MUST”s. Consequently, apps cannot rely on "typ" regardless
> of its meaning.****
>
> ** **
>
> ** **
>
> My suggestions:****
>
> ** **
>
> * For [1], define two media types to distinguish the two serializations,
> not a header field.****
>
> ** **
>
> *  1st preference for [3], drop it from JOSE specs; let an application
> using JOSE (eg JWT) define a field (and value) for this. If the application
> defines the field in a generic fashion for reuse by other applications that
> is a nice bonus.****
>
> ** **
>
> * 2nd preference for [3], define a field (but no values) that can hold an
> application-layer semantics identifier – but only put this definition in a
> spec that defines JOSE messages as a whole (not specs specific to JWE or
> JWS). Use a different name: "app" or "profile" or "mean"ing or "pur"pose.*
> ***
>
> ** **
>
> * For [2], define a mandatory field that indicates the semantics of the
> JOSE structure at a low enough level that a JOSE implementation built on
> top of a crypto library could (almost) work without needing to recognize
> the "alg" value. "typ" would have been a reasonable name for this field but
> is now too polluted with confusion. How about "t"?****
>
> Consider for instance a JOSE implementation that only supports
> "alg":"HS256". To add support for "alg":"HS3" (HMAC with SHA-3) minimal (if
> any) new code is needed in a JOSE layer: perhaps an extra table entry
> mapping the JOSE label "HS3" to a crypto library label (eg "HmacSHA3").
> "t":"mac" can accompany both these algs. To support "alg":"RS512", in
> contrast, requires calls to different crypto library functions (knowing the
> difference between public & private keys for instance). This deserves a
> separate value, say, "t":"sig".****
>
> ** **
>
> --****
>
> James Manger****
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>