This may be just my personal opinion, but preserving member creation order is
only one small part of producing canonical JSON, which would be what would be
required for such a scheme to be guaranteed to work. For instance, if the
value 1e3 is part of the JSON input, will JSON.stringify() be guaranteed to
emit it as 1e3, or might it be 1E3 or 100? Unless it's deterministic,
different serializers will produce different results, and therefore different
signatures. Without a canonical JSON being both defined and widely deployed, I
can't recommend doing any work that requires a canonical JSON representation to
deterministically succeed.
-- Mike
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Anders Rundgren
Sent: Wednesday, October 28, 2015 11:40 PM
To: [email protected]
Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures
ES6-compliant in-object JS/JSON signature:
var inObjectSignedData =
{
// Object data expressed as JS properties
"device": "Pump2",
"value": 1e-18,
// Object signature
"signature": {
...Protected headers + Signature value expressed as JS
properties...
}
};
JavaScript's JSON.parse() and JSON.stringify() suffice for "canonicalization"
purposes.
Converting the above to JWS JSON Serialization you would get:
var signedData =
{
// Object data in a coded format
"payload":"<payload contents>",
// Protected headers wrapped in Base64URL
"protected":"<integrity-protected header contents>",
// Signature in a unique format
"signature":"<signature contents>"
}
ES6 was released in June 2015 so this opportunity is actually quite new.
Cheers,
Anders
http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html#rfc.section.3.3
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
