Subject: [jose] Canonical JSON form

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Oct 2018 13:03:41 -0600

Dear WG,

I was reading through RFC 7515 to see if it would work for a project I am working on.  Basically the need to sign and resign a JSON object.  However, in RFC 7515 there does not seem to be any definition for serializing a canonical form of JSON. This means that two organizations that serialize it differently would produce two different signatures.

Super simple example

{ “type” : “house”, “size” : “1000 sq feet” }

Or 

{
  “type” : “house”, 
  “size” : “1000 sq feet”
}

Or

{“type”:“house”,“size”:“1000 sq feet”}

Or (tabs not spaces)

{
	“type” : “house”, 
	“size” : “1000 sq feet”
}

All four of these JSON structures would produce a different signature as defined by RFC 7515. What am I missing?

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 10 Oct 2018 15:15:00 -0400

JWS signs a byte stream, not JSON. If you want to use a JWS to sign
JSON data it is your responsibility to ensure that both sides produce
an equivalent byte stream.
On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan <[email-masked]> wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Oct 2018 14:48:52 -0600

Would this WG be open to working on a solution to sign JSON (not a byte stream) and define a canonical representation for said JSON?

Thanks,
Bret

> On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <[email-masked]> wrote:
>

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 10 Oct 2018 17:02:51 -0400

I can't speak for the WG. However, I think such is unnecessary. It is
long standing custom, when working with JSON (with or without JOSE),
to serialize without whitespace and with sorted keys. Every single
JSON implementation I've ever come across gives you the ability to do
this.

---

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Oct 2018 15:18:32 -0600

I am also needing the ability to have signatures embedded in the JSON and have multiple groups sign various individual or holistic parts of the JSON structure.

I found this page, and from a first read it looks like it gets me some of the way to what I am needing. 
https://cyberphone.github.io/doc/security/jcs.html <https://cyberphone.github.io/doc/security/jcs.html>

Thanks,
Bret

> On Oct 10, 2018, at 3:02 PM, Nathaniel McCallum <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 10 Oct 2018 16:52:18 -0700

The working group has closed and is not entertaining any new work.  You would need to create a proposal for a new working group (could have the same name) to do this.  However, trying to canonicalize JSON is generally not considered to be doable without having some external constraints added.  Consider the problem with serializing {“int”: 3} which has a large number of possible ways to encode the number 3.

From: jose <[email-masked]> On Behalf Of Bret Jordan
Sent: Wednesday, October 10, 2018 1:49 PM
To: Nathaniel McCallum <[email-masked]>; [email-masked]
Subject: Re: [jose] Canonical JSON form

 

Thanks,

Bret

On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]> > wrote:

JWS signs a byte stream, not JSON. If you want to use a JWS to sign
JSON data it is your responsibility to ensure that both sides produce
an equivalent byte stream.
On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan <[email-masked] <mailto:[email-masked]> > wrote:

Dear WG,

Super simple example

Or

{
 “type” : “house”,
 “size” : “1000 sq feet”
}

Or

Or (tabs not spaces)

{
“type” : “house”,
“size” : “1000 sq feet”
}

Thanks,
Bret

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 10 Oct 2018 16:53:13 -0700

> -----Original Message-----
> From: jose <[email-masked]> On Behalf Of Nathaniel McCallum
> Sent: Wednesday, October 10, 2018 2:03 PM
> To: [email-masked]
> Cc: [email-masked]
> I can't speak for the WG. However, I think such is unnecessary. It is long
> standing custom, when working with JSON (with or without JOSE), to serialize
> without whitespace and with sorted keys. Every single JSON implementation
> I've ever come across gives you the ability to do this.

Other implementations say that you should preserver the order of the fields you read when serialized which is part of JSON for the browser implementations but not necessarily elsewhere.

Jim

> > Would this WG be open to working on a solution to sign JSON (not a byte
> stream) and define a canonical representation for said JSON?
> >
> >
> > Thanks,
> > Bret
> > I was reading through RFC 7515 to see if it would work for a project I am
> working on.  Basically the need to sign and resign a JSON object.  However, in
> RFC 7515 there does not seem to be any definition for serializing a canonical
> form of JSON. This means that two organizations that serialize it differently
> would produce two different signatures.
> >
> > Super simple example
> >

---

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Oct 2018 17:59:09 -0600

How many of you would be interested in helping open a new working group to work on this sort of thing?

Maybe I am missing something, but there has to be a way of dealing with this.  Maybe just treat the entire JSON object has a string to be passed in to a signing function ? 

Thanks,
Bret

> On Oct 10, 2018, at 5:52 PM, Jim Schaad <[email-masked]> wrote:
> 
>> On Oct 10, 2018, at 1:15 PM, Nathaniel McCallum <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> On Wed, Oct 10, 2018 at 3:04 PM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
>>> Dear WG,
>>> 
>>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>

---

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Oct 2018 18:02:05 -0600

> Other implementations say that you should preserver the order of the fields you read when serialized which is part of JSON for the browser implementations but not necessarily elsewhere.

Preserving order is hard.  Depending on your programming language you might be deserializing the content in to a struct or you may be using a map. 

What I need is a way for individuals and organizations to be able to pass around and share JSON data and collaboratively work on that JSON data and sign the parts that they have done. 

Thanks,
Bret

---

From: "Manger, James" <[email-masked]>
Date: Thu, 11 Oct 2018 00:29:21 +0000

https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme
is a decent attempt at JSON canonicalization (and an appendix lists a few other attempts).
This one sorts object members based on their UTF-16 encoding (without escapes), and assumes double precision floats is the model for numbers.

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <[email-masked]>
Cc: Nathaniel McCallum <[email-masked]>; [email-masked]
Subject: Re: [jose] Canonical JSON form

Thanks,
Bret

---

From: David Waite <[email-masked]>
Date: Wed, 10 Oct 2018 19:42:43 -0600

Even this I-D presents some interesting potential compatibility issues when round-tripping from canonical JSON to an internal representation and back, such as an implementation normalizing external text, or storing numbers in numerical types other than double.

The bigger issue in the past has not been the body of work defining a canonicalization scheme, but that people did that in the past for XML signatures. It became a huge interoperability issue due not just to the complexity of the canonicalization scheme[s], but to the difficulty in detecting and dealing with modifications to the canonical form. This also gracefully went down the slipper slope to signing portions and even specific features of a document, and tooling needing to accommodate preserving canonical form when e.g. signed documents were placed inside other documents.

-DW

> On Oct 10, 2018, at 6:29 PM, Manger, James <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 10 Oct 2018 21:47:38 -0400

Bret,

You could define it within a draft in a different working group other than
JOSE and ask for reviewers from JOSE to review and comment to catch
problems.  Although already described above, there are issues with this and
JSON, which is why the WG didn't want to do canonicalization.

I'm assuming you want to do basically what was done for RID in XML using
JSON.  You may want to look at the set of possibilities to replicate as
they are all likely needed with what you are trying to do or just as part
of your gap analysis.

https://tools.ietf.org/html/rfc6545#section-9.1
Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop
authentication too.

To David's point in the message that follows this (came in while typing),
RID signed portions of the message to enable interoperability and you are
likely to need to do very similar things that are described in RID related
to the policy work I had previously mentioned for your gap analysis as
being similar functionality.  If you haven't looked at that part of the
document, I think it will be helpful.

Best regards,
Kathleen

On Wed, Oct 10, 2018 at 8:29 PM Manger, James <
[email-masked]> wrote:

> This one sorts object members based on their UTF-16 encoding (without
> escapes), and assumes double precision floats is the model for numbers.
>
>
>
> --
>
> James Manger
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Bret Jordan
> *Sent:* Thursday, 11 October 2018 11:02 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* Nathaniel McCallum <[email-masked]>; [email-masked]
> *Subject:* Re: [jose] Canonical JSON form
>
>
>
>
> Other implementations say that you should preserver the order of the
> fields you read when serialized which is part of JSON for the browser
> implementations but not necessarily elsewhere.
>
>
>
> Preserving order is hard.  Depending on your programming language you
> might be deserializing the content in to a struct or you may be using a
> map.
>
>
>
> What I need is a way for individuals and organizations to be able to pass
> around and share JSON data and collaboratively work on that JSON data and
> sign the parts that they have done.
>
>
>
>
>
>
>
> Thanks,
>
> Bret
>

-- 

Best regards,
Kathleen

---

From: Neil Madden <[email-masked]>
Date: Thu, 11 Oct 2018 06:33:42 +0100

> On 11 Oct 2018, at 01:02, Bret Jordan <[email-masked]> wrote:
> 
>> 

Have you considered Git with PGP-signed commits? It solves this use-case extremely well.

— Neil

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 11 Oct 2018 08:44:04 +0200

I for one think this is interesting.

I have published two implementations of the draft James mentions,
draft-rundgren-json-canonicalization-scheme
<https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme>, (
Java
<https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar>
and JavaScript <https://www.npmjs.com/package/canonicalize>) and I know
Anders (the author of the draft) has implementations in .NET and Python too
(all working well together).

The I have my self been part in writing a draft that uses this
canonicalization mechanism to create signed cleartext JSON (
draft-erdtman-jose-cleartext-jws
<https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01>). I have
ported a JavaScript JOSE implementation to this new schema without any
issues and Anders has at least a Java implementation.

Finally there was a resent conversation about this subject on the OAuth
mailing-list
<https://mailarchive.ietf.org/arch/msg/oauth/YL29UE_gNj73mChXTr9FgkCF5Kg>
recently.

Best regards
//Samuel

On Thu, Oct 11, 2018 at 7:33 AM Neil Madden <[email-masked]>
wrote:

> > What I need is a way for individuals and organizations to be able to
> pass around and share JSON data and collaboratively work on that JSON data
> and sign the parts that they have done.
>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 08:32:20 -0600

Awesome advise.  Thanks.

Thanks,
Bret

> On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Bret,
> 
> You could define it within a draft in a different working group other than JOSE and ask for reviewers from JOSE to review and comment to catch problems.  Although already described above, there are issues with this and JSON, which is why the WG didn't want to do canonicalization.
> 
> I'm assuming you want to do basically what was done for RID in XML using JSON.  You may want to look at the set of possibilities to replicate as they are all likely needed with what you are trying to do or just as part of your gap analysis.
> 
> https://tools.ietf.org/html/rfc6545#section-9.1 <https://tools.ietf.org/html/rfc6545#section-9.1>
> Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop authentication too.
> 
> To David's point in the message that follows this (came in while typing), RID signed portions of the message to enable interoperability and you are likely to need to do very similar things that are described in RID related to the policy work I had previously mentioned for your gap analysis as being similar functionality.  If you haven't looked at that part of the document, I think it will be helpful.
> 
> Best regards,
> Kathleen
> 
> 
> 
> On Wed, Oct 10, 2018 at 8:29 PM Manger, James <[email-masked] <mailto:[email-masked]>> wrote:
> From: jose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bret Jordan
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> Cc: Nathaniel McCallum <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 08:34:13 -0600

Neil,

That is interesting.  But as others have said, I need to be able to round trip the content.  The JSON data needs to be consumed by solutions, acted on, added to, and resigned.

Thanks,
Bret

> On Oct 10, 2018, at 11:33 PM, Neil Madden <[email-masked]> wrote:
> 
>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 08:40:41 -0600

There is a lot of value that the market could gain from something like this.  I think it would be great if we could do this work here in the IETF.  I for one would be willing to spend some time on it if we can somehow get the work kickstarted.  

I know of several large projects (most outside the IETF, but one is an upcoming IETF project) that need this for their solutions. For the IETF one, we will be hosting a WebEx to talk through it on the 24th, see the CACAO mailing list if you are interested. 

Things that I see we need to figure out are:

1) Canonicalization of JSON to enable round-tripping 

2) Ability to sign JSON string data

3) Ability to have JSON signatures located in the content themselves with nested signatures and partial tree signatures

Thanks,
Bret

> On Oct 11, 2018, at 12:44 AM, Samuel Erdtman <[email-masked]> wrote:
> 
> I have published two implementations of the draft James mentions, draft-rundgren-json-canonicalization-scheme <https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme>, (Java <https://search.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/jar> and JavaScript <https://www.npmjs.com/package/canonicalize>) and I know Anders (the author of the draft) has implementations in .NET and Python too (all working well together).
> 
> The I have my self been part in writing a draft that uses this canonicalization mechanism to create signed cleartext JSON (draft-erdtman-jose-cleartext-jws <https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01>). I have ported a JavaScript JOSE implementation to this new schema without any issues and Anders has at least a Java implementation.
> 
> Finally there was a resent conversation about this subject on the OAuth mailing-list <https://mailarchive.ietf.org/arch/msg/oauth/YL29UE_gNj73mChXTr9FgkCF5Kg> recently.
> 
> Best regards
> //Samuel
> 
> 
> On Thu, Oct 11, 2018 at 7:33 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 11 Oct 2018, at 01:02, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 11:23:56 -0600

Kathleen,

From your comments I take it is okay then to do a draft proposal in another WG and then have this mailing list review it?  Would we then restart JOSE if the draft was good to have it standardized in JOSE or just some other WG?  

I just want to be sensitive to the work that has already been done and build on it.  I also do not want to do things that are “bad form”.  We are all in this boat together, and I just want to work with everyone to row in the same direction.

BTW, I have spoken with a few other vendors and service providers and they are also very interested in this work as it would solve a lot of problems they have or are seeing. 

Thanks,
Bret

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 11 Oct 2018 18:26:01 +0100

Hi

If the signature can be verified then what difference does it make what the
signature value is, the same for every JSON variation or not ? If JSON1,
JSON2, etc, with some minor formatting differences, all make it, after
being validated, into SomeJsonBean, then it should work ?

Thanks, Sergey

On Thu, Oct 11, 2018 at 3:35 PM Bret Jordan <[email-masked]> wrote:

> Neil,
>
> That is interesting.  But as others have said, I need to be able to round
> trip the content.  The JSON data needs to be consumed by solutions, acted
> on, added to, and resigned.
>
> Thanks,
> Bret

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Oct 2018 14:06:00 -0400

Hi Bret,

JOSE is closed, so a new WG would have to be formed if this were to be done
in a WG.  That might be reopening JOSE or something else.  Another
possibility is for James to try to progress his existing draft and
determine interest.  Has it been presented at SecDispatch yet to gauge
interest and uncover problems?

You could also consider alternate solutions.  The problems cited were
problems with XML already.  Since RID defined the same capability, you
could test out interoperability using RID in XML more extensively as you'd
be mapping the same functionality into JSON.  This would give you in your
new effort feedback into design considerations and help you determine if
you really want to go this route or perhaps some other solution may be
preferred (see Neil's message).  In any case, more work should be done
before a new WG around canonicalization is performed IMO, but I am also no
longer an AD, so advice from current ones may vary :-)

Best,
Kathleen

On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan <[email-masked]> wrote:

> Kathleen,
>
> From your comments I take it is okay then to do a draft proposal in
> another WG and then have this mailing list review it?  Would we then
> restart JOSE if the draft was good to have it standardized in JOSE or just
> some other WG?
>
> I just want to be sensitive to the work that has already been done and
> build on it.  I also do not want to do things that are “bad form”.  We are
> all in this boat together, and I just want to work with everyone to row in
> the same direction.
>
> BTW, I have spoken with a few other vendors and service providers and they
> are also very interested in this work as it would solve a lot of problems
> they have or are seeing.
>
> Thanks,
> Bret

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Thu, 11 Oct 2018 11:23:02 -0700

I am not sure of the value of canonicalization.  I prefer bytestream encoding style where the original content goes with the signature.

Another example is ATLAS which signs encoded http requests.

Some JSON formats will have the same issues that XMLDSIG had.  For example, SCIM supports multiple ways to identfiy attributes much like XML (it uses IANA registered schemas). You can reference an attribute with the full path or just its name.  We tried to avoid schemas, but localized extensibility and easy of coding forced us to do this.  So for SCIM it is easier to canonicalize than XML, but I would not say simple.  

In the end, I felt it was a good trade-off because of an assumption to sign encoded json data instead.

Note:  SCIM does not yet have a signed format. I anticipate however the development of signed SCIM events per the new SET spec.

If you were to proceed, I would recommend including considerations identifying JSON formats not well suited to canonicalization.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Oct 11, 2018, at 11:06 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Bret,
> 
> JOSE is closed, so a new WG would have to be formed if this were to be done in a WG.  That might be reopening JOSE or something else.  Another possibility is for James to try to progress his existing draft and determine interest.  Has it been presented at SecDispatch yet to gauge interest and uncover problems?
> 
> You could also consider alternate solutions.  The problems cited were problems with XML already.  Since RID defined the same capability, you could test out interoperability using RID in XML more extensively as you'd be mapping the same functionality into JSON.  This would give you in your new effort feedback into design considerations and help you determine if you really want to go this route or perhaps some other solution may be preferred (see Neil's message).  In any case, more work should be done before a new WG around canonicalization is performed IMO, but I am also no longer an AD, so advice from current ones may vary :-)
> 
> Best,
> Kathleen
> 
> On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> Kathleen,
> 
>> On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Bret,
>> 
>> https://tools.ietf.org/html/rfc6545#section-9.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6545-23section-2D9.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=22u9NErU0ozC5-MfcgjryGcdeGT_X5t9OCSSYtvY-a0&e=>
>> https://tools..ietf.org/html/draft-rundgren-json-canonicalization-scheme <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Drundgren-2Djson-2Dcanonicalization-2Dscheme&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=sZq9Tv1-r2RLEkVR50tXkMNdFi6nOmqWmEkuNbdTJio&e=>
>> https://www.ietf.org/mailman/listinfo/jose <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Oct 2018 21:03:49 +0200

> I am not sure of the value of canonicalization.  I prefer bytestream encoding style where the original content goes with the signature.

I’m afraid a lot of people are sitting in front of their screens silently agreeing, but not typing anything because their hands are tied up in an interminable facepalm.

So, for the record:
To the people asking for a c14n solution for signature: If you want XMLDSig, you know where to find it.
The basic approach of having humongous XML documents that get signatures added to themselves as part of the document only makes sense in certain processing models that went out of favor with XML.
JOSE does the right thing for more modern applications.

I’m not opposed to doing some “c14n” work on serialization schemes — deterministic serialization has other applications than just XMLDSig.
That would be work for a JSONbis WG (but I fear the interest level among JSON experts will be low).
I definitely do not like giving the message that c14n-based signatures are the new thing that will replace doing the right thing (JOSE, that is).

Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 11 Oct 2018 19:10:20 +0000

I very much agree with Phil. Xmldsig was a pain for developers, libraries did it differently thus causing interoperability problems.
Jose was designed simple but a canonical JSON form introduces new complexity.
We had the same with Oauth1 – developers were not able to sort the URL parameters according to the spec.
So jose is better off without canonical JSON.

//Axel

From: jose [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Donnerstag, 11. Oktober 2018 20:23
To: Kathleen Moriarty <[email-masked]>
Cc: Manger, James <[email-masked]>; [email-masked]; Bret Jordan <[email-masked]>
Subject: Re: [jose] Canonical JSON form

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Oct 11, 2018, at 11:06 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bret,

Best,
Kathleen

On Thu, Oct 11, 2018 at 1:24 PM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
Kathleen,

Thanks,
Bret

On Oct 10, 2018, at 7:47 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Bret,

https://tools.ietf.org/html/rfc6545#section-9.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6545-23section-2D9.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=22u9NErU0ozC5-MfcgjryGcdeGT_X5t9OCSSYtvY-a0&e=>
Also look at 9.3.1 and 9.3.2 as you're likely to also need multi-hop authentication too.

Best regards,
Kathleen

On Wed, Oct 10, 2018 at 8:29 PM Manger, James <[email-masked]<mailto:[email-masked]>> wrote:
https://tools..ietf.org/html/draft-rundgren-json-canonicalization-scheme<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Drundgren-2Djson-2Dcanonicalization-2Dscheme&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=sZq9Tv1-r2RLEkVR50tXkMNdFi6nOmqWmEkuNbdTJio&e=>
is a decent attempt at JSON canonicalization (and an appendix lists a few other attempts).
This one sorts object members based on their UTF-16 encoding (without escapes), and assumes double precision floats is the model for numbers.

--
James Manger

From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bret Jordan
Sent: Thursday, 11 October 2018 11:02 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: Nathaniel McCallum <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Canonical JSON form

Thanks,
Bret

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>

--

Best regards,
Kathleen

--

Best regards,
Kathleen
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MMo12b48B6GqvKdy8eBzH6ZAMMue9XSrSjSfwjHnqkQ&s=68ephlmudUEVF-9EE70huCbhCWZMtZFLhQwmunkXcbc&e=>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 11 Oct 2018 21:58:36 +0200

Before dismissing Canonical JSON, you may take it for spin at:
https://mobilepki.org/jws-jcs/home

This particular signature variant is 100% JWS compatible.

Although enveloped signatures may be "out of fashion", I find them quite practical since they don't interfere with the message structure.

An example: In the IETF TEEP work (building on JOSE), the designers were forced adding an unsigned outer JSON layer in order to get a reasonable system.

The idea is not replacing JOSE, only creating a viable alternative for folks who don't want to shroud their precious JSON data in Base64Url!

Thanks,
Anders

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 14:05:08 -0600

Anders,

I really like what you have done with this.  I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking.  If it does work, then I think we should really try and figure out how we get your work standardized. 

Thanks,
Bret

> On Oct 11, 2018, at 1:58 PM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Oct 2018 22:45:10 +0200

On Oct 11, 2018, at 21:58, Anders Rundgren <[email-masked]> wrote:
> 
> shroud their precious JSON data in Base64Url

I know how to fix this, but that’s a different WG :-)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Oct 2018 14:36:34 -0700

I think quite a few people might benefit from JSON c14n, but the water was
poisoned by the hideous XML experience and there's a general reluctance to
go anywhere near it. If we saw a really plausible proposal, we could
possibly think about rehydrating the JSON WG to look at it.

---

From: Bret Jordan <[email-masked]>
Date: Thu, 11 Oct 2018 16:22:38 -0600

We have a real need for it with some work I am starting here in the IETF and work I am doing in other SDOs.  So I would love to figure out how to kickstart this work back to life.

Thanks,
Bret

> On Oct 11, 2018, at 3:36 PM, Tim Bray <[email-masked]> wrote:
> 
> I think quite a few people might benefit from JSON c14n, but the water was poisoned by the hideous XML experience and there's a general reluctance to go anywhere near it. If we saw a really plausible proposal, we could possibly think about rehydrating the JSON WG to look at it.
> 
> On Thu., Oct. 11, 2018, 1:45 p.m. Carsten Bormann, <[email-masked] <mailto:[email-masked]>> wrote:
> On Oct 11, 2018, at 21:58, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Oct 2018 00:50:07 +0200

> We have a real need for it with some work I am starting here in the IETF and work I am doing in other SDOs.  So I would love to figure out how to kickstart this work back to life.

If this is about CACAO, let me question this need.
Please explain how CACAO would benefit from “monster document with embedded partial signatures”.
Because of the way this information flows together, a multi-file approach for composing information from the various stakeholders makes much more sense to this observer.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 12 Oct 2018 08:38:33 +0200

> I really like what you have done with this.  I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking.  If it does work, then I think we should really try and f…

Thanx Bret!

The https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 I-D provides quite a lot of features including an extension option that can be used for adding possibly missing functionality.

There is one thing that is good to know for anyone thinking about standardizing Canonical JSON and that's the fact that canonicalization also can be performed on the text level as described by: https://gibson042.github.io/canonicaljson-spec/

This has the advantage that it is very simple and supports the entire JSON RFC without restrictions.

So why didn't I took this [superficially obvious] route? There are several reasons for that:

A downside of source level canonicalization is that it doesn't integrate with JSON parsers and serializers. https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01 was explicitly designed to eventually be an option of a standard JSON serializer as it already is in my Java reference implementation.

Another issue is that it is unclear what the value is with using the JSON "Number" format outside of the IEEE range.  In fact, it excludes parsers like JavaScript's JSON.parse() unless JavaScaript would be updated to always use a "BigNumber" as fundamental numeric type.

Regards,
Anders

---

From: Bret Jordan <[email-masked]>
Date: Fri, 12 Oct 2018 09:20:19 -0600

Please correct me if I am wrong…. The way I understand the problem is as follows:

1) If you verified the JSON string at consumption time, before it has been unmarshal-ed, then all you need to do is decide how to handle white space and carriage returns.  You could basically regex remove all white space and CR / CRLF and have a workable solution.

2) Where this breaks down is, when a tool unmarshals the data into a map or struct, then you have no guarantee that you would recreate the keys in the same order (a struct may force it to the order of the struct definition). So you have no way of being able to verify the hash after it has been unmarshal-ed.  Further, if you recreate the JSON and send it back out, the next person that gets the data might have a hash that can not be verified in option 1 above.

3) Another problem once you have unmarshal-ed the data is what do you do with JSON numbers.  Some programming languages store them as a float, some as who-knows-what.  So you would need a way to ensure that the number was always stored in the same way, especially for strongly typed systems (is this architecture dependent too?). So the options here are, if the ontology / semantics of the JSON data were well defined in schema (a meaning it was standardized and documented), then the code could know what it should do and interoperability tests could be made to ensure that it worked.

What am I not understanding here?  And what am I missing?

Thanks,
Bret

> On Oct 12, 2018, at 12:38 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 12 Oct 2018 09:26:15 -0700

From: jose <[email-masked]> On Behalf Of Bret Jordan
Sent: Friday, October 12, 2018 8:20 AM
To: Anders Rundgren <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Manger, James <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]; Phil Hunt <[email-masked]>
Subject: Re: [jose] Canonical JSON form

 

[JLS] Which is what JOSE does – passes the string in a form that will not be unmarshal-ed.

[JLS]  The issue is not so much what the format that the number is stored internally in, the problem is how is the number serialized out. Some have dealt with this problem by storing the string version of the number along side the numeric version.  Not what I consider to be an acceptable solution but it may be the only one that works.

 

Thanks,

Bret

On Oct 12, 2018, at 12:38 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> > wrote:

Anders,

Thanx Bret!

Regards,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 12 Oct 2018 18:47:23 +0200

> Please correct me if I am wrong…. The way I understand the problem is as follows:

Hi Bret,
Comments in line...
> 1) If you verified the JSON string at consumption time, before it has been unmarshal-ed, then all you need to do is decide how to handle white space and carriage returns.  You could basically regex…

It depends on what your goal is.  Canonicalization builds on the assumption that there is a unique representation of the data, preferably even after it has passed through a processor like an intermediary.

> 2) Where this breaks down is, when a tool unmarshals the data into a map or struct, then you have no guarantee that you would recreate the keys in the same order (a struct may force it to the order…

Right, therefore option 1 is not very useful.  Sorting of keys is the cure for this issue.

> 
> 3) Another problem once you have unmarshal-ed the data is what do you do with JSON numbers. 

Right, but even string data needs adjustments.  "\u0020" and " " both represents a space character.

> Some programming languages store them as a float, some as who-knows-what.  So you would need a way to ensure that the number was always stored in the same way, especially for strongly typed systems (is this architecture dependent too?). So the options here are, if the ontology / semantics of the JSON data were well defined in schema (a meaning it was standardized and documented), then the code could know what it should do and interoperability tests could be made to ensure that it worked.

This is (IMO) the only part of the puzzle that is non-trivial.  In my take on the matter, I have "prescribed" that the JSON Number type must be coerced into an IEEE 754 double precision number and be serialized according to ECMAScript V6+ rules.

If your application needs higher precision or bigger range, you are forced using the quoted string notation which (AFAIK...) is used by every IETF standard of any significance to date defining a JSON structure.

> What am I not understanding here?  And what am I missing?

As I wrote earlier, there are (at least) two entirely different and documented approaches.

Using a schema based canonicalizer as you mention is also an option but that is a much more ambitious project.

Regards,
Anders

>> On Oct 12, 2018, at 12:38 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 12 Oct 2018 15:31:30 -0600

Anders,

How do we move forward?  What can we do to make this happen?

Thanks,
Bret

> On Oct 12, 2018, at 10:47 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 20 Oct 2018 06:55:26 +0200

> How do we move forward?  What can we do to make this happen?

As you can see from the responses, there is considerable resistance and skepticism against this work.
I guess even fewer have bothered reading the actual I-D.

Personally I don't care that much since the JSON based systems I work with have up to 5 layers of signatures which doesn't translate well to the current JOSE standards.

Maybe the other editors of https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01 (which builds on a flavor of Canonical JSON) have an idea?

There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/

The 1 million of random and "edge" JSON Numbers used for testing the devised JSON canonicalization scheme, uncovered flaws in other systems as well...
https://github.com/dotnet/coreclr/issues/17467

Ciao,
Anders

>> On Oct 12, 2018, at 10:47 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>> On Oct 12, 2018, at 12:38 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 21 Oct 2018 18:15:32 -0600

Anders,

It is sad that we have to look at doing work outside of the IETF in order to solve the needs of the market.  But I would love to work with you on this effort, even if it means doing it outside of the IETF.

Your solution that uses 5 layers of signatures, which draft / document / write up is this based on?   I have a very similar need and would like to try and do what ever you are doing. 

Thanks,
Bret

> On Oct 19, 2018, at 10:55 PM, Anders Rundgren <[email-masked]> wrote:
>

---

From: David Waite <[email-masked]>
Date: Sun, 21 Oct 2018 20:47:01 -0600

> There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position…

This document is not on a standards track. The group which published this it is not a standards group. So this isn’t currently on track to reach the market as a IETF or W3 standard.

It also is based on RDF canonicalization; it canonicalized a specific format expressed in JSON, not arbitrary JSON. 

That isn't to say that there couldn’t be multiple canonicalization formats supported, possibly built as filters so you could combine them together, such as existed with XML-DSIG. Then you have a compatibility matrix to deal with.

This still doesn’t solve the problem that many internal representations of JSON will not preserve the full data set you are representing in your canonical form. 

From my development experience with XML-DSIG, this is most commonly that tools will discard information they do not understand, such as properties which aren’t part of the public schema. For developers who do not understand the additional restrictions a cleartext signature is placing on them, this causes issues that only come up late in broad interoperability testing, that can only be resolved through per-vendor workarounds or reimplementation to use different tools. This actually occurred multiple times across different implementations, sometimes when leveraging libraries that did claim to preserve the full information set of the XML document.

> https://github.com/dotnet/coreclr/issues/17467 <https://github.com/dotnet/coreclr/issues/17467>

This yet another case against canonical JSON, is it not? Or rather, how are people expected to deal with intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions comes out?

-DW

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 22 Oct 2018 07:04:15 +0200

Dear David et al,
I believe we all know IETF's position on this topic by now.

Anyway, there is considerable interest maintaining the core quality of text based messages (human readability) also for signed data, leading to various quests for alternative solutions.

To give some kind of perspective on the complexity, my C#/.NET implementation [1] weighs in at 30 Kb of executable code.

It took 3 complete revisions and five calendar years to get to this point but it was (hopefully) worth it :-)

Thanks,
Anders
1] https://github.com/cyberphone/json-canonicalization/tree/master/dotnet

On 2018-10-22 04:47, David Waite wrote:
> 
> 
>> On Oct 19, 2018, at 10:55 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 08:44:13 +0200

On Oct 22, 2018, at 04:47, David Waite <[email-masked]> wrote:
> 
> intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions

Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/

Grüße, Carsten

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 28 Oct 2018 21:32:05 +0100

In my opinion we can create a good canonicalization format for JSON to be
used to sign cleartext JSON.

As can be seen on this list many are skeptical so my approach would be to
publish easy to use open source implementations. If we do that and there is
real interest then we might be able to convince people here about the need.
In line with this ambition I have done the JS and Java publications. This
might also show there is no actual interest and then that is also an
outcome.

Best regards
//Samuel

On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <[email-masked]> wrote:

> > intermittent interoperability failures until a new language runtime
> release which revises the numerical print and parse functions
>
> Note that this is not a theoretical concern, as CVE-2010-4476 and
> CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of
> the latter in
> https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/
>
> Grüße, Carsten
>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 28 Oct 2018 21:04:20 -0600

Oh there is real need.  Several standards and implementations inside the IETF and outside the IETF in other SDOs need this.  So in my view there are a few options:

1) Try and convince a working group here in the IETF that this is a good idea so we can actually work on it. 

2) Work on this in another SDO outside the IETF (ETSI, OASIS, ITU, etc etc etc)

3) Do this work as an industry standard similar to what happened between W3C and WHATWG. 

I would personally prefer that this work be done here in the IETF.  But there seems to be a lot of resistance here. I am willing to work on this and help make this a reality.  There is a lot of great prior work on this.  

Maybe we can have a meeting in Prague?  Or I can setup a Telepresence WebEx after Bangkok and all those that are interested can join and we can discuss next steps. 

Thanks,
Bret

> On Oct 28, 2018, at 2:32 PM, Samuel Erdtman <[email-masked]> wrote:
> 
> In my opinion we can create a good canonicalization format for JSON to be used to sign cleartext JSON.
> 
> As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations. If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome.
> 
> Best regards
> //Samuel
> 
> 
> On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> On Oct 22, 2018, at 04:47, David Waite <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> Note that this is not a theoretical concern, as CVE-2010-4476 and CVE-2010-4645 amply demonstrate, nicely underscored by the re-occurrence of the latter in https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/ <https://www.exploringbinary.com/php-converts-2-2250738585072012e-308-incorrectly/>
> 
> Grüße, Carsten
>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 29 Oct 2018 09:33:10 +0100

On 2018-10-28 21:32, Samuel Erdtman wrote:
> As can be seen on this list many are skeptical so my approach would be to publish easy to use open source implementations.

Yes, and part of that is supplying test data like: https://github.com/cyberphone/json-canonicalization/tree/master/testdata
The Microsoft folks developing "Chakra" (their JS engine) already use the 100 million reference values.

> If we do that and there is real interest then we might be able to convince people here about the need. In line with this ambition I have done the JS and Java publications. This might also show there is no actual interest and then that is also an outcome.

Well, another part of the standards puzzle is getting early work into real products and services.

FWIW, I'm personally involved in a couple of efforts using clear text JSON signatures:
- Saturn, an open payment authorization scheme based on an enhanced "four corner" trust model which aims giving banks an upper hand against Apple Pay, Google Pay, PayPal, etc.
- Mobile ID, an open, PKI-based, multi-issuer mobile authentication and signature solution for e-governments.

Regards,
Anders

---

From: Tim Bray <[email-masked]>
Date: Mon, 29 Oct 2018 06:38:40 -0700

I like Samuel Erdtman's idea of starting with an open-source
implementation.  If I see one of those, with a convincing set of test
cases, I'd be inclined to make the case for spinning up a working group.

The argument isn't "Would it be useful?" it's "Can it be done?" So, start
by proving it can.

On Mon., Oct. 29, 2018, 1:33 a.m. Anders Rundgren <
[email-masked] wrote:

> > As can be seen on this list many are skeptical so my approach would be
> to publish easy to use open source implementations.
>
> Yes, and part of that is supplying test data like:
> https://github.com/cyberphone/json-canonicalization/tree/master/testdata
> > If we do that and there is real interest then we might be able to
> convince people here about the need. In line with this ambition I have done
> the JS and Java publications. This might also show there is no actual
> interest and then that is also an outcome.
>
> - Saturn, an open payment authorization scheme based on an enhanced "four
> corner" trust model which aims giving banks an upper hand against Apple
> Pay, Google Pay, PayPal, etc.
> >     On Oct 22, 2018, at 04:47, David Waite <[email-masked]
> <mailto:[email-masked]>> wrote:
> >      >
> >      > intermittent interoperability failures until a new language
> runtime release which revises the numerical print and parse functions
> >

---

From: Jim Schaad <[email-masked]>
Date: Mon, 29 Oct 2018 11:46:06 -0700

I would look at creating a new working group in the IETF rather than using an existing one.

1.	Get a personal draft published
2.	Find a cadre of people who are interested and think it is solvable
3.	Write a charter
4.	Talk to the ADs about getting the WG formed by holding a BOF

The first three should be really easy to do.  The fourth may take a bit of work but should be doable.  The trick with the IETF is to find people who want to work on things and not to worry over much about the people who don’t think it is solvable.  If necessary write the charter to say you are not going to cover some things or that you are going to require specific environments for your solution.  The tighter the requirements the easier the solution but the less harder it might be to get the cadre of people.

You should be looking at 1) one or more authors, 2) half a dozen or more reviewers, 3) at least a couple of people who think they are going to get this implemented.

Jim

From: jose <[email-masked]> On Behalf Of Bret Jordan
Sent: Sunday, October 28, 2018 8:04 PM
To: Samuel Erdtman <[email-masked]>
Cc: Anders Rundgren <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]; [email-masked]; Carsten Bormann <[email-masked]>; [email-masked]; Phil Hunt <[email-masked]>
Subject: Re: [jose] Canonical JSON form

Thanks,

Bret

On Oct 28, 2018, at 2:32 PM, Samuel Erdtman <[email-masked] <mailto:[email-masked]> > wrote:

Best regards

//Samuel

On Mon, Oct 22, 2018 at 8:44 AM Carsten Bormann <[email-masked] <mailto:[email-masked]> > wrote:

Grüße, Carsten