Re: [Json-canon] [EXT] Re: Support for a WG

Carsten, Here comes a few another concrete example where canonical JSON
would be beneficial (not an absolute need).

Open Banking (
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0#AccountandTransactionAPISpecification-v1.1.0-Processforsigningapayload
)
In this case RFC 7797 is used to keep the payload separated form the
signature and headers.
If you look at the processing steps the HTTP body (josn) is Base64 encoded
and used as payload for the JWS calculation, it is however not the base64
encoded payload that is sent in the HTTP body but the cleartext json (as
can be seen in the verification steps). This is a workable but brittle
solution. With a canonical JOSN format this solution could be made stable.
(I have no personal contact with this group so I do not know if they
formally would be interested, but it is a case here cleartext JSON is
signed)

Then there are the TEEP usecase (
https://tools.ietf.org/id/draft-ietf-teep-opentrustprotocol)
In this case JOSE is used and there is several layers of signing (and
encryption) being done, since the payload is always base64 encode and then
wrapped the messages becomes very opaque. So to me they have a workable
solution but would benefit from canonical JOSN in combination with RFC
7797. (Once again I have no personal contact with this group so I do not
know if they formally would be interested)

Then there is the Signing HTTP Messages case (
https://tools.ietf.org/html/draft-cavage-http-signatures)
This one is a bit more far fetched, but instead of defining how to
canonicalize the HTTP headers they could do a simple mapping form https
headers to JOSN and have it canonicalized and then signed using RFC 7797.
(Once again I have no personal contact with this group so I do not know if
they formally would be interested)

Best regards
//Samuel

On Thu, Jan 24, 2019 at 7:17 AM Samuel Erdtman <samuel@erdtman.se> wrote:

> Thanks for the followup Allan.
>
> In my opinion the application layer schemas for defining what the JSON can
> look like (optional values different values meaning the same thing etc),
> should be verified by application layer. I would like to keep the
> canonicalization (and potential signatures) at the level where they say the
> JSON has not changed.
>
> When it comes to empty empty values I think those are values too, they
> might convey some meaning to the application layer.and with empty I mean
> {"empty": ""}. And since I do not want the canonicalization to be involved
> with application level details optional attributes are not a concept.
>
> Does that make sense?
>
> Cheers
> //Samuel
>
>
>
>
>
> On Tue, Jan 22, 2019 at 5:47 PM Allan Thomson <
> athomson@lookingglasscyber.com> wrote:
>
>> I’m not sure how you can create a consistent hash value without
>> considering how empty/optional fields in a JSON structure are treated
>> consistently across implementations.
>>
>>
>>
>> So if the same optional/empty fields exist from 2 different
>> vendors/instances then do they end up with the same hash?
>>
>>
>>
>> Allan
>>
>>
>>
>> *From: *Samuel Erdtman <samuel@erdtman.se>
>> *Date: *Tuesday, January 22, 2019 at 8:37 AM
>> *To: *Allan Thomson <athomson@lookingglasscyber.com>
>> *Cc: *"Struse, Richard J." <rjs@mitre.org>, Carsten Bormann <cabo@tzi.org>,
>> "json-canon@ietf.org" <json-canon@ietf.org>
>> *Subject: *Re: [Json-canon] [EXT] Re: Support for a WG
>>
>>
>>
>> I do not think we should go into schemas, that is one of the things that
>> makes XMLDigSig inconvenient. But instead keep to simple JSON stringifying
>> with predictable result.
>>
>> On Tue, 22 Jan 2019 at 16:19, Allan Thomson <
>> athomson@lookingglasscyber.com> wrote:
>>
>> Particularly important in what Rich says is also is to ensure the same
>> hash is created where those JSON objects have optional or empty/missing
>> properties that are defined in the schema of the object.
>>
>> Regards
>>
>> Allan
>>
>> On 1/22/19, 4:31 AM, "json-canon on behalf of Struse, Richard J." <
>> json-canon-bounces@ietf.org on behalf of rjs@mitre.org> wrote:
>>
>>     The use case is to enable other standards that use a JSON
>> serialization to be able to count on two objects, each with the same
>> contents, having the same hash value based on their representation in JSON.
>>
>>     Does that help?
>>
>>     On 1/18/19, 1:47 AM, "Carsten Bormann" <cabo@tzi.org> wrote:
>>
>>         On Jan 18, 2019, at 03:50, Struse, Richard J. <rjs@mitre.org>
>> wrote:
>>         >
>>         > A standardized deterministic canonicalization of JSON data
>> streams is essential
>>
>>         For what?
>>
>>         I think we would all benefit if you could explain your use case.
>>
>>         Grüße, Carsten
>>
>>
>>
>>     --
>>     json-canon mailing list
>>     json-canon@ietf.org
>>     https://www.ietf.org/mailman/listinfo/json-canon
>>
>>
>> --
>> json-canon mailing list
>> json-canon@ietf.org
>> https://www.ietf.org/mailman/listinfo/json-canon
>>
>>