Subject: [jose] #22: JSON Serialization media types not consistent with RFC 6839

From: "jose issue tracker" <[email-masked]>
Date: Wed, 22 May 2013 21:05:40 -0000

#22: JSON Serialization media types not consistent with RFC 6839

 The JSON Serialization media types "application/jwe-js" and "application
 /jws-js" are not consistent with RFC 6839.

 * "application/jwe-js" should be "application/jwe+json"
 * "application/jws-js" should be "application/jws+json"

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  json-web-    |    Version:
  encryption             |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/22>
jose <http://tools.ietf.org/jose/>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 22 May 2013 18:51:54 -0400

+1

On Wednesday, May 22, 2013, jose issue tracker wrote:

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 22 May 2013 22:53:12 +0000

For what it's worth, I'm fine with this proposal.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, May 22, 2013 3:52 PM
To: jose issue tracker
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] #22: JSON Serialization media types not consistent with RFC 6839

+1

  [email-masked]<javascript:;>     |  [email-masked]<javascript:;>

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

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 23 May 2013 08:24:04 +0900

+1

=nat via iPhone

May 23, 2013 6:05、jose issue tracker <[email-masked]> のメッセージ:

> [email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 23 May 2013 13:32:14 +1000

Why have separate media types for JWS and JWE?
Wouldn’t it be better to have one media type for the dot-separated-base64url serialization of a JOSE message — regardless of whether the content was unprotected, signed, MACed, encrypted with any of the supported options, or any future algorithm?

  application/jose

A second media type for the separate serialization is useful.

  application/jose+json

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jose issue tracker
> Sent: Thursday, 23 May 2013 7:06 AM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: [jose] #22: JSON Serialization media types not consistent with
> RFC 6839
> 
>  The JSON Serialization media types "application/jwe-js" and
> "application  /jws-js" are not consistent with RFC 6839.
> 
> -------------------------+---------------------------------------------
> -
> -------------------------+---
> -------------------------+---------------------------------------------
> -
> -------------------------+---
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 May 2013 14:14:12 -0400

Sharing a media type only makes sense if there's a way to disambiguate.  So
the "typ" header would have to be mandatory.

On Wed, May 22, 2013 at 11:32 PM, Manger, James H <
[email-masked]> wrote:

> Wouldn’t it be better to have one media type for the
> dot-separated-base64url serialization of a JOSE message — regardless of
> whether the content was unprotected, signed, MACed, encrypted with any of
> the supported options, or any future algorithm?
>
>   application/jose
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 24 May 2013 09:56:02 +1000

> Sharing a media type only makes sense if there's a way to disambiguate.  So the "typ" header would have to be mandatory.

The assumption is that looking at the JSON header of any JOSE message is sufficient to work out what it is (signed, MACed, directly encrypted, unprotected etc). In many situations a JOSE message will NOT be accompanied by a media type (eg a JOSE message as a bearer token in an HTTP message) so the media type cannot be required for disambiguation.

It might well be helpful in some situations to distinguish the variety of JOSE message before peeking into the JSON header (I proposed a 1-character prefix to do just that a year ago). In that case, though, I want to distinguish "unprotected" from "asymmetrically signed" from "MACed" from "encrypted with a shared secret" from "key exchange + encrypted" -- not "JWS" vs "JWE".

I agree that a "typ" JSON header field should be mandatory. It should be the primary way to indicate how to process the message, should obviate the need for "crit", and should have values like "sig", "mac", "plain", "aead", "keyex".

Allowing the "typ" field as a parameter of an application/jose media type would be a reasonable design.

--
James Manger

From: Richard Barnes [mailto:[email-masked]] 

Sharing a media type only makes sense if there's a way to disambiguate.  So the "typ" header would have to be mandatory.

On Wed, May 22, 2013 at 11:32 PM, Manger, James H <[email-masked]> wrote:
Why have separate media types for JWS and JWE?
Wouldn’t it be better to have one media type for the dot-separated-base64url serialization of a JOSE message — regardless of whether the content was unprotected, signed, MACed, encrypted with any of the supported options, or any future algorithm?

  application/jose

  application/jose+json

> ----------

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 May 2013 10:19:39 -0400

On Thu, May 23, 2013 at 7:56 PM, Manger, James H <
[email-masked]> wrote:

> > Sharing a media type only makes sense if there's a way to disambiguate.
>  So the "typ" header would have to be mandatory.
>
> The assumption is that looking at the JSON header of any JOSE message is
> sufficient to work out what it is (signed, MACed, directly encrypted,
> unprotected etc). In many situations a JOSE message will NOT be accompanied
> by a media type (eg a JOSE message as a bearer token in an HTTP message) so
> the media type cannot be required for disambiguation.
>

This point is not entirely germane to this issue, since the question here
is how to define the media type (thus focused on cases where there is a
media type expressed).  But it's a valid point w.r.t. the requirement level
on "typ".

> It might well be helpful in some situations to distinguish the variety of
> JOSE message before peeking into the JSON header (I proposed a 1-character
> prefix to do just that a year ago). In that case, though, I want to
> distinguish "unprotected" from "asymmetrically signed" from "MACed" from
> "encrypted with a shared secret" from "key exchange + encrypted" -- not
> "JWS" vs "JWE".
>

I don't see a huge difference between the indicator being in the header or
out.  As long as the first component is JSON for all JW* variants.

I agree that a "typ" JSON header field should be mandatory. It should be
> the primary way to indicate how to process the message, should obviate the
> need for "crit", and should have values like "sig", "mac", "plain", "aead",
> "keyex".
>

No, it wouldn't :)  If it's a parameter, then it can be omitted, and the
bare media type would have to have a semantic.  Also, this would be
duplicative of the "typ" in the object (what if they don't match?).

--Richard

> Sharing a media type only makes sense if there's a way to disambiguate.
>  So the "typ" header would have to be mandatory.
>