"Comparable" JSON (JSONCOMP)
IndependentMontpellierFranceanders.rundgren.net@gmail.comhttps://www.linkedin.com/in/andersrundgren/
Security
JSON, ECMAScript, Canonicalization, Normalization
This application note describes how JCS
can be utilized to support applications needing canonicalization
beyond the core JSON level,
with comparisons as the primary target.
The purpose of JCS is creating "Hashable" JSON
data intended for cryptographic solutions.
JCS accomplishes this by combining normalization of the native JSON
String and Number primitives with a deterministic property sorting scheme.
That is, JCS provides canonicalization at the core JSON level.
For interoperability reasons JCS also constrains data to the I-JSON subset.
However, if you rather would like to compare JSON data from
different sources or runs, JCS would in many cases be
inadequate since the JSON String type is commonly used
for holding subtypes like "DateTime" or "BigNumber" objects.
This application note outlines how JCS in spite of having a limited
canonicalization scope still may be utilized by applications like above.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Assume you want to compare productions of JSON data where the schema
designer assigned the property "big" for holding a "BigInteger" subtype and
"time" for holding a "DateTime" subtype, while "val" is supposed to be a JSON Number
compliant with JCS. The example below shows such a string:
A problem here is that "055" clearly is not a canonical form for a "BigInteger"
while a "DateTme" object like "2019-01-28T07:45:10Z"
might as well be expressed as "2019-01-28T08:45:10.000+01:00" making
comparisons based on JCS canonicalization fail.
To resolve this issue using JCS the following measures MUST be taken:
The community or standard utilizing a specific JSON schema
defines a strict normalized form for each of the used subtypes.
Compatible serializers are created for each subtype.
A positive side effect of this arrangement is that it enforces strict definitions
of subtypes which improves interoperability in general as well.
Below is an example how such a serializer could be expressed in ECMAScript
for a "DateTime" subtype:
Defining specific subtypes and their normalized form is out of scope for
this application note.
This document has no IANA actions.
TBD.
TBD.
JSON Canonicalization Scheme - Work in progressA. Rundgren, B. Jordan, S. ErdtmanECMAScript 2015 Language SpecificationEcma International