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

From: Mike Jones <[email-masked]>
Date: Fri, 12 Jul 2013 15:31:31 +0000

I’ve applied the proposed changes in the -12 drafts.

                                                            -- Mike

From: Mike Jones
Sent: Thursday, May 30, 2013 12:22 AM
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]> [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, May 30, 2013 12:17 AM
To: [email-masked]<mailto:[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]]
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: "Manger, James H" <[email-masked]>
Date: Sat, 13 Jul 2013 23:41:24 +1000

Mike,

The “typ” changes (below) make no sense.
The first sentence is marginally clearer that “typ” is some sort of label for a higher-layer (above JOSE processing), eg values are application-specific. But the very next sentence suggests “JOSE” as a value! Argh!! How can that be “application-specific”? It is the definition of not application-specific. Defining “JOSE+JSON” in the next sentence is even worse. That makes It seem that “typ” is indicating the serialization, which everyone (including yourself) have agreed is wrong.

-- from http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-jose-json-web-encryption-12.txt

4.1.10.  "typ" (Type) Header Parameter

   The "typ" (type) header parameter is MAY be used to declare the type of
   this
   object. complete JWE object in an application-specific manner in
   contexts where this is useful to the application.  This parameter has
   no effect upon the JWE processing.  The type value "JWE" is "JOSE" MAY be used
   to indicate that this object is a JWS or JWE using the JWS Compact
   Serialization or the JWE Compact Serialization.  The type value "JWE+JSON"
   is
   "JOSE+JSON" MAY be used to indicate that this object is a JWS or JWE
   using the JWS JSON Serialization or the JWE JSON Serialization.
   Other type values MAY be used, and if not understood, SHOULD be
   ignored.  The "typ" value is a case sensitive string.  Use of this
   header parameter is OPTIONAL.

   MIME Media Type [RFC2046] values MAY be used as "typ" values.

   "typ" values SHOULD either be registered in the IANA JSON Web
   Signature and Encryption Type Values registry [JWS] or be a value
   that contains a Collision Resistant Namespace.

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Saturday, 13 July 2013 1:32 AM
To: Manger, James H; [email-masked]
Subject: RE: [jose] FW: Should we delete the "typ" header field

                                                            -- Mike

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

                                                            Best wishes,
                                                            -- Mike

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Sun, 14 Jul 2013 20:09:12 +0000

It can be application-specific if the application chooses to use that value.  I will plan change the sentence in question by adding the words “by applications” as below to eliminate the potential ambiguity that you identified:
   The type value "JOSE" MAY be used by applications
   to indicate that this object is a JWS or JWE using the JWS Compact
   Serialization or the JWE Compact Serialization.

As for the choice of the names “JOSE” and “JOSE+JSON”, those reflect the decision on the last call to change from the type-specific MIME types application/jws, application/jwe, application/jws+json, and application/jwe+json to the more inclusive names application/jose and application/jose+json.  Both the MIME types exist because the serializations use different representations, and so their content types need to be different.

                                                            -- Mike

From: Manger, James H [mailto:[email-masked]]
Sent: Saturday, July 13, 2013 6:41 AM
To: Mike Jones; [email-masked]
Subject: RE: [jose] FW: Should we delete the "typ" header field

Mike,

--
James Manger

                                                            -- Mike

From: Mike Jones

                                                            Best wishes,
                                                            -- Mike

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Sun, 14 Jul 2013 16:32:49 -0400

I think James's point is that there's no point to using "typ": "JOSE".  If
you've already parsed the object far enough to read that field, you know
it's a JOSE object.  So we should just remove that value.

--Richard

On Sun, Jul 14, 2013 at 4:09 PM, Mike Jones <[email-masked]>wrote:

>  It can be application-specific if the application chooses to use that
> value.  I will plan change the sentence in question by adding the words “by
> applications” as below to eliminate the potential ambiguity that you
> identified:****
>
>    The type value *"JOSE" MAY be* used by applications****
>
>    to indicate that this object is a *JWS or* JWE using the *JWS Compact*
>
> *   Serialization or the* JWE Compact Serialization.****
>
> ** **
>
> As for the choice of the names “JOSE” and “JOSE+JSON”, those reflect the
> decision on the last call to change from the type-specific MIME types
> application/jws, application/jwe, application/jws+json, and
> application/jwe+json to the more inclusive names application/jose and
> application/jose+json.  Both the MIME types exist because the
> serializations use different representations, and so their content types
> need to be different.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Manger, James H [mailto:[email-masked]]
> *Sent:* Saturday, July 13, 2013 6:41 AM
> *To:* Mike Jones; [email-masked]
>
> *Subject:* RE: [jose] FW: Should we delete the "typ" header field****
>
>  ** **
>
> Mike,****
>
> ** **
>
> The “typ” changes (below) make no sense.****
>
> The first sentence is marginally clearer that “typ” is some sort of label
> for a higher-layer (above JOSE processing), eg values are
> application-specific. But the very next sentence suggests “JOSE” as a
> value! Argh!! How can that be “application-specific”? It is the definition
> of not application-specific. Defining “JOSE+JSON” in the next sentence is
> even worse. That makes It seem that “typ” is indicating the serialization,
> which everyone (including yourself) have agreed is wrong.****
>
> ** **
>
> ** **
>
> -- from
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-jose-json-web-encryption-12.txt
> ****
>
> ** **
>
> *4.1.10.*  "typ" (Type) Header Parameter****
>
> ** **
>
>    The "typ" (type) header parameter is *MAY be* used to declare the type
> of****
>
>    this****
>
>    object. *complete JWE object in an application-specific manner in*
>
> *   contexts where this is useful to the application.  This parameter has*
>
> *   no effect upon the JWE processing.*  The type value "JWE" is *"JOSE"
> MAY be* used****
>
>    to indicate that this object is a *JWS or* JWE using the *JWS Compact*
>
> *   Serialization or the* JWE Compact Serialization.  The type value
> "JWE+JSON"****
>
>    is****
>
>    *"JOSE+JSON" MAY be* used to indicate that this object is a *JWS or*JWE
> ****
>
>    using the *JWS JSON Serialization or the* JWE JSON Serialization.****
>
>    Other type values MAY be used, and if not understood, SHOULD be****
>
>    ignored.  The "typ" value is a case sensitive string.  Use of this****
>
>    header parameter is OPTIONAL.****
>
> ** **
>
>    MIME Media Type [RFC2046] values MAY be used as "typ" values.****
>
> ** **
>
>    "typ" values SHOULD either be registered in the IANA JSON Web****
>
>    Signature and Encryption Type Values registry [JWS] or be a value****
>
>    that contains a Collision Resistant Namespace.****
>
> ** **
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* Mike Jones [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Saturday, 13 July 2013 1:32 AM
> *To:* Manger, James H; [email-masked]
> *Subject:* RE: [jose] FW: Should we delete the "typ" header field****
>
> ** **
>
> I’ve applied the proposed changes in the -12 drafts.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Mike Jones
> *Sent:* Thursday, May 30, 2013 12:22 AM
> *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
>
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 14 Jul 2013 21:14:44 +0000

Per the discussion on the call, people made the point that it's useful to have a generic MIME type for use by applications that choose to use it.  An analogy was made to the application/json MIME type.  The JSON spec could have omitted that, leaving it up to applications to always use application-specific MIME types for JSON objects.  But in practice, it's proven useful to have application/json, because it will do the job without an application-specific MIME type in many circumstances.  That was the reason cited for continuing to have generic JOSE MIME types.  The value "JOSE" is simply a registered shorthand for "application/jose".

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Sunday, July 14, 2013 1:33 PM
To: Mike Jones
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] FW: Should we delete the "typ" header field

I think James's point is that there's no point to using "typ": "JOSE".  If you've already parsed the object far enough to read that field, you know it's a JOSE object.  So we should just remove that value.

--Richard

On Sun, Jul 14, 2013 at 4:09 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It can be application-specific if the application chooses to use that value.  I will plan change the sentence in question by adding the words "by applications" as below to eliminate the potential ambiguity that you identified:
   The type value "JOSE" MAY be used by applications
   to indicate that this object is a JWS or JWE using the JWS Compact
   Serialization or the JWE Compact Serialization.

As for the choice of the names "JOSE" and "JOSE+JSON", those reflect the decision on the last call to change from the type-specific MIME types application/jws, application/jwe, application/jws+json, and application/jwe+json to the more inclusive names application/jose and application/jose+json.  Both the MIME types exist because the serializations use different representations, and so their content types need to be different.

                                                            -- Mike

From: Manger, James H [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, July 13, 2013 6:41 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>

Mike,

The "typ" changes (below) make no sense.
The first sentence is marginally clearer that "typ" is some sort of label for a higher-layer (above JOSE processing), eg values are application-specific. But the very next sentence suggests "JOSE" as a value! Argh!! How can that be "application-specific"? It is the definition of not application-specific. Defining "JOSE+JSON" in the next sentence is even worse. That makes It seem that "typ" is indicating the serialization, which everyone (including yourself) have agreed is wrong.

--
James Manger

I've applied the proposed changes in the -12 drafts.

                                                            -- Mike

From: Mike Jones

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

> The purpose of "typ" is your 3.

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

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

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

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:

* 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.

--
James Manger

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 14 Jul 2013 14:48:52 -0700

But life does get strange at some point.

If I have a JSON serialization that has typ being jose, does that mean that
something is wrong in the processing?  Any compact serialization can be
represented as a JSON serialization.  Does that act invalidate anything?

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Sunday, July 14, 2013 2:15 PM
To: Richard Barnes
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] FW: Should we delete the "typ" header field

Per the discussion on the call, people made the point that it's useful to
have a generic MIME type for use by applications that choose to use it.  An
analogy was made to the application/json MIME type.  The JSON spec could
have omitted that, leaving it up to applications to always use
application-specific MIME types for JSON objects.  But in practice, it's
proven useful to have application/json, because it will do the job without
an application-specific MIME type in many circumstances.  That was the
reason cited for continuing to have generic JOSE MIME types.  The value
"JOSE" is simply a registered shorthand for "application/jose".

                                                            -- Mike

--Richard

On Sun, Jul 14, 2013 at 4:09 PM, Mike Jones <[email-masked]>
wrote:

It can be application-specific if the application chooses to use that value.
I will plan change the sentence in question by adding the words "by
applications" as below to eliminate the potential ambiguity that you
identified:

As for the choice of the names "JOSE" and "JOSE+JSON", those reflect the
decision on the last call to change from the type-specific MIME types
application/jws, application/jwe, application/jws+json, and
application/jwe+json to the more inclusive names application/jose and
application/jose+json.  Both the MIME types exist because the serializations
use different representations, and so their content types need to be
different.

                                                            -- Mike

Mike,

The first sentence is marginally clearer that "typ" is some sort of label
for a higher-layer (above JOSE processing), eg values are
application-specific. But the very next sentence suggests "JOSE" as a value!
Argh!! How can that be "application-specific"? It is the definition of not
application-specific. Defining "JOSE+JSON" in the next sentence is even
worse. That makes It seem that "typ" is indicating the serialization, which
everyone (including yourself) have agreed is wrong.

-- from http://tools.ietf.org/rfcdiff?difftype=--hwdiff
<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-jose-json-w
eb-encryption-12.txt> &url2=draft-ietf-jose-json-web-encryption-12.txt

   this

   no effect upon the JWE processing.  The type value "JWE" is "JOSE" MAY be
used

   Serialization or the JWE Compact Serialization.  The type value
"JWE+JSON"

   is

 

--

James Manger

                                                            -- Mike

From: Mike Jones 

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

"typ":"JWE+JSON"?

[2].

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.

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

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

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.

message security or semantics.

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"?

separate value, say, "t":"sig".

--

James Manger

---

From: Mike Jones <[email-masked]>
Date: Sun, 14 Jul 2013 23:47:12 +0000

It could, but in those cases, I suspect the application would specify the use of an application-specific "typ" value.  I believe that many applications will specify the use of one serialization or the other, but not both, so the case you're concerned about wouldn't arise in practice for them, because no change of serialization representation would ever occur.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, July 14, 2013 2:49 PM
To: Mike Jones; 'Richard Barnes'
Cc: 'Manger, James H'; [email-masked]
Subject: RE: [jose] FW: Should we delete the "typ" header field

If I have a JSON serialization that has typ being jose, does that mean that something is wrong in the processing?  Any compact serialization can be represented as a JSON serialization.  Does that act invalidate anything?

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, July 14, 2013 2:15 PM
To: Richard Barnes
Cc: Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] FW: Should we delete the "typ" header field

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Sunday, July 14, 2013 1:33 PM
To: Mike Jones
Cc: Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] FW: Should we delete the "typ" header field

--Richard

                                                            -- Mike

Mike,

--
James Manger

                                                            -- Mike

From: Mike Jones

                                                            Best wishes,
                                                            -- Mike

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 15 Jul 2013 11:34:55 +1000

A generic media type for JOSE messages is fine (in fact it is necessary) so I fully support defining application/jose.
Sticking a media type for a message inside the actual message (in "typ") is the problem.

HTML has a hack to do a vaguely similar thing by putting <meta http-equiv="content-type" content="text/html;charset=UTF-8"> in the HTML. However, in HTML this hack is only done to convey the charset when web servers are too unreliable in setting it correctly in the HTTP header. This does not apply to JOSE.

Nobody has asked for "typ":"JOSE" or "typ":"JOSE+JSON". Nobody has any use for them. Drop them.

"typ" should be completely dropped; failing that it should be renamed (eg "profile"); failing that I suggest the following replacement text:

  The "typ" (type) header parameter is a placeholder that an application can use to
  convey additional (but optional) application-specific semantics to a JOSE message.
  A "typ" value is a string. A "typ" value is only useful when the
 additional semantics it conveys are over and above the general semantics of a
 JOSE message (eg cryptographic protection); and are not implied by the value of
 or metadata about the content being protected (eg beyond the semantics implied
 by media type in a "cty" header parameter).

  "typ" has no affect on JOSE processing rules. No "typ" values are defined by this
  specification. A "typ" value MUST be a URI.

[If the last sentence is too controversial, replace it with:
"typ" values SHOULD either be registered in the IANA JSON Web
  Signature and Encryption Type Values registry [JWS] or be a value
  that contains a Collision Resistant Namespace.]

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, 15 July 2013 7:15 AM
To: Richard Barnes
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] FW: Should we delete the "typ" header field

Per the discussion on the call, people made the point that it’s useful to have a generic MIME type for use by applications that choose to use it.  An analogy was made to the application/json MIME type.  The JSON spec could have omitted that, leaving it up to applications to always use application-specific MIME types for JSON objects.  But in practice, it’s proven useful to have application/json, because it will do the job without an application-specific MIME type in many circumstances.  That was the reason cited for continuing to have generic JOSE MIME types.  The value “JOSE” is simply a registered shorthand for “application/jose”.

                                                            -- Mike

--Richard

                                                            -- Mike

Mike,

--
James Manger

                                                            -- Mike

From: Mike Jones

                                                            Best wishes,
                                                            -- Mike

--
James Manger

                                                            -- Mike

My suggestions:

--
James Manger