- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 18 Jul 2017 11:37:57 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>, public-webpayments-ig@w3.org
On 2017-07-17 15:48, Manu Sporny wrote: > On 07/09/2017 12:30 AM, Anders Rundgren wrote: >> LDS primarily targets Linked Data, while JCS only targets >> plain-vanilla JSON/JavaScript. > > We're going to be releasing a plain-vanilla JSON/JavaScript > canonicalization algorithm later this year that mirrors exactly what's > happening in JCS, so expect further alignment there. I'm stubborn and continue claiming that plain-vanilla JSON/JavaScript doesn't really need canonicalization. Maintaining ES6 compatibility is no big deal and has something to offer for "ordinary" programming as well like honoring the order which objects are declared/created also during parsing/serialization: https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html Yeah, there is an exception for numerical property names but that is IMO an edge case which is more related to JavaScript than to JSON. The by far worst interoperability issue (not limited to signatures) is rather how to handle numbers since JavaScript treat all numbers as 64-bit IEEE floating point variables. My take on this problem was introducing strict type checking making it more difficult creating numerical data that cannot be properly represented in JSON/JavaScript: https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectWriter.html#setInt53-java.lang.String-long%2D > I should also note that there is also the Signing HTTP Signatures spec > here (originated by Mark Cavage at Joyent, now Oracle): > > https://tools.ietf.org/html/draft-cavage-http-signatures-06 > > ... which is implemented and deployed by BBC and other large players. > Mastadon (1 million users) looks like they are going to be deploying > HTTP Signatures as well. Needless to say, a number of Verifiable Claims > implementations and Digital Bazaar have had this deployed in production > for years. Apparently it has been adopted by this group as well: https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html > So, as far as signing HTTP Headers, there is another approach in > addition to the ones you mentioned, Anders. I may be wrong but AFAICT, only HTTP Signatures include headers, the other methods seem to only deal with actual content. The Financial API folks stick to base64url-encoded JWS payloads https://openid.net/specs/openid-financial-api-part-2.html#request which isn't that surprising since some of founding members like Microsoft and PING also were deeply involved in the JOSE WG. Personally (FWIW), I'm about converting all my wallet-2-mechant communication from HTTP to WebSocket because it supports scalable and interactive sessions better than REST. Anders > > -- manu >
Received on Tuesday, 18 July 2017 09:38:26 UTC