Re: [Json-canon] Dropping "Comparable" JSON

[Anders Rundgren <[e-mail]>]

Carsten,

Starting in another end...

As you probably know REST is a established way of architecting Web applications.  A fly in the soup is that there is no standard for creating signed REST requests.

Instead proprietary signature schemes based on detached clear text JSON data and HTTP bindings have become the norm while the JOSE WG has been concluded.  It has been claimed that the "right" solution (encoding and embedding the request data to be signed in the signature container itself) eventually will win.  However, I haven't seen this happening.  Maybe somebody can provide a link to such an activity?

In addition to be useful in entirely different contexts, JCS may function as a building block for future work in the REST space since it offers advantages over detached formats and HTTP bindings.

"Hashable" is a term I got from a related discussion on the ES-mozilla list.  In a JCS context "Hashable" means that a producer of (I-)JSON data can calculate a hash or signature over the data to be sent while the consumer of that data can use the hash or signature to verify the correctness of the received data. "Hashable" is obviously a lower form of canonicalization than required for comparing JSON data from arbitrary sources.

Regarding interoperability: With the (recently added...) constraint that the parsing of a JSON String followed by a serialization MUST return the same string you have together with the core JCS algorithm all the interoperability needed for supporting cryptographic methods.

Anders


On 2019-02-12 18:02, Carsten Bormann wrote:
> On Feb 9, 2019, at 08:05, Anders Rundgren <[e-mail]> wrote:
>>
>> I begin to wonder if "Comparable" JSON (in the draft named "true" canonicalization) shouldn't be a "Feature at Risk" as the W3C folks call this.
> 
> Well, first of all, there is no “feature” here — the current draft just points out that deterministic encoding (“canonicalization”) reaches up to the application using JSON wherever that does its own encoding work.
> 
> That is a fact that is good to know, but nothing is contributed to interoperability by this document.
> 
> To do so, one would need a way to describe elements of the application data model and constrain the application data encoding decisions made on the way to the JSON data model.  We don’t have a good way to do this at the moment (even if the document misleadingly mentions the “schema” word).
> 
> Actually, the document about deterministic encoding of JSON (your “Hashable” thing — I still have no idea where these confused terms came from) could be stating this fact, if only as a matter of delineating what is *not* being defined in that document.
> 
> The document currently does not say how it was intended to be developed further.  As it stands, it is indeed of little use.  Collecting a set of preferred application-data-model to JSON-data-model encoding decisions, however, might be a useful undertaking, somewhat unrelated to the constraints on serializing the JSON data model that the other document wants to define, and probably on a much longer time scale.
> 
> Grüße, Carsten
>