W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > July 2017

Re: JSON Signatures in OpenBanking (UK)

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
Message-ID: <ff182d37-5219-fbac-c69a-0eb82db582fc@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:59 UTC