Subject: [jose] Open Issue for WG Discussion: Disposition of JSON Serialization Functionality

From: Mike Jones <[email-masked]>
Date: Mon, 9 Apr 2012 16:25:38 +0000

You'll recall that I created JSON Serialization drafts in response to WG input that use the same cryptographic operations as JWS and JWE, but that serialize the results into a JSON objects, rather than base64url encoded values separated by periods.  These representations also enable multiple signatures/HMACs to be used and content to be encrypted to multiple recipients.  The current versions of these drafts are:

*        http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-01

*        http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serialization-01

It was decided in Paris that the disposition of this functionality should be discussed by the WG on the list.  I think the questions we need to decide are:

1.  Is the working group interested in pursuing this functionality?  (Evidence to date is that the answer to this question is "yes".)

2.  If the answer to (1) is "yes", would the working group like to have this functionality be in working group documents at this time (rather than being described in individual submissions, as at present)?

3.  If the answer to (2) is "yes", should working group -00 versions of the JSON Serialization documents be created or should this functionality be folded into the existing JWS and JWE specs?

Arguments for keeping this functionality separate for now are:
  - Different level of maturity:  I'm aware of over a dozen implementations of JWS a few of JWE, but I know of no implementations of JWS-JS or JWE-JS.  There's an argument that we should keep this new functionality separate until we have "rough consensus and running code".
  - Document simplicity for the Compact Serialization use case.  Not describing a second serialization in the JWS and JWE documents makes the documents somewhat easier to read if all the implementer needs is the Compact Serialization.

Arguments for merging it in now are:
  - Fewer documents needed to provide comprehensive treatment of the material.

Opinions from the Working Group?

                                                            Thanks,
                                                            -- Mike

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Apr 2012 13:41:20 -0300

Inline
On 2012-04-09, at 1:25 PM, Mike Jones wrote:

> You’ll recall that I created JSON Serialization drafts in response to WG input that use the same cryptographic operations as JWS and JWE, but that serialize the results into a JSON objects, rather than base64url encoded values separated by periods.  These representations also enable multiple signatures/HMACs to be used and content to be encrypted to multiple recipients.  The current versions of these drafts are:
> ·        http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-01
> ·        http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serialization-01
>  
> 1.  Is the working group interested in pursuing this functionality?  (Evidence to date is that the answer to this question is “yes”.)
>  
Yes
> 2.  If the answer to (1) is “yes”, would the working group like to have this functionality be in working group documents at this time (rather than being described in individual submissions, as at present)?

Yes
>  
> 3.  If the answer to (2) is “yes”, should working group -00 versions of the JSON Serialization documents be created or should this functionality be folded into the existing JWS and JWE specs?
>  

Create WG documents separate from the  JWS and JWE and consider merging them later after some more maturity.

John B.
>   - Different level of maturity:  I’m aware of over a dozen implementations of JWS a few of JWE, but I know of no implementations of JWS-JS or JWE-JS.  There’s an argument that we should keep this new functionality separate until we have “rough consensus and running code”.
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 13 Apr 2012 04:44:31 +0900

On Tue, Apr 10, 2012 at 1:41 AM, John Bradley <[email-masked]> wrote:
> You’ll recall that I created JSON Serialization drafts in response to WG
> input that use the same cryptographic operations as JWS and JWE, but that
> serialize the results into a JSON objects, rather than base64url encoded
> values separated by periods.  These representations also enable multiple
> signatures/HMACs to be used and content to be encrypted to multiple
> recipients.  The current versions of these drafts are:
> It was decided in Paris that the disposition of this functionality should be
> discussed by the WG on the list.  I think the questions we need to decide
> are:
>
> 1.  Is the working group interested in pursuing this functionality?
> (Evidence to date is that the answer to this question is “yes”.)
>
>
> Yes

Yes.

>
> 2.  If the answer to (1) is “yes”, would the working group like to have this
> functionality be in working group documents at this time (rather than being
> described in individual submissions, as at present)?
>
>
> Yes

Yes.

>
>
> 3.  If the answer to (2) is “yes”, should working group -00 versions of the
> JSON Serialization documents be created or should this functionality be
> folded into the existing JWS and JWE specs?
>
>
>

+1

>   - Different level of maturity:  I’m aware of over a dozen implementations
> of JWS a few of JWE, but I know of no implementations of JWS-JS or JWE-JS.
> There’s an argument that we should keep this new functionality separate
> until we have “rough consensus and running code”.
>   - Document simplicity for the Compact Serialization use case.  Not
> describing a second serialization in the JWS and JWE documents makes the
> documents somewhat easier to read if all the implementer needs is the
> Compact Serialization.
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 18 Apr 2012 14:06:56 +0000

Yes

Yes

>   - Fewer documents needed to provide comprehensive treatment of the material.

Keep them separate - Id like to see fewer documents, but no need for mass extermination ;-)