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: Sun, 9 Jul 2017 06:30:01 +0200
To: Kim Hamilton <kimdhamilton@gmail.com>, Web Payments IG <public-webpayments-ig@w3.org>
Message-ID: <c76cd89f-8b37-ac39-2cdd-7795bf4ae111@gmail.com>
Here is a (probably biased), extremely condensed comparison of the three JSON signature schemes, all having one thing in common which was NOT the priority of the IETF JOSE WG, namely preserving the JSON text "as is" (=human readable).

The OpenBanking signature scheme is quite straightforward but also have huge limitations since messages are tied to HTTP making the concept incompatible with JavaScript/Browsers, WebSockets, Message Embedding as well as with Serialization in databases.

LDS (Linked Data Signatures) and JCS both claim adherence to JOSE standards but achieves that through entirely different methods:
- LDS use (a subset of) the JWS detached signature format but put all information regarding the signature key outside of the base64-encoded JWS container.
- JCS do not use the JWS container since one of the goals was providing all information in clear, including algorithms, public keys, etc. JCS rather reuse (a subset of) the JWK container and the JWA signature algorithms.

Since in-line signatures need some form of normalization in order to be interoperable, LDS utilizes a specific canonicalization algorithm while JCS only relies on JSON.stringify() as defined by ECMA.  This difference has major implications for applications as well as tools.

LDS primarily targets Linked Data, while JCS only targets plain-vanilla JSON/JavaScript.

Anders

On 2017-07-08 22:04, Kim Hamilton wrote:
> 
> We're about to release a paper on this topic originating out of last Rebooting Web of Trust. Manu developed an approach reconciling LD signatures with JWS. The approach uses the unencoded payload option (also detached), enabled by RFC7797 (https://tools.ietf.org/html/rfc7797).
> 
> The LD signature suite is called RSA Signature Suite 2017 (https://w3c-dvcg.github.io/lds-rsa2017/).
> 
> The paper describing the approach and implementation is in draft form below, but will soon be released in final form
> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/event-documents/group-abstracts/SignatureAlignmentAbstract.md
> 
> -- Kim
> 
> On Sat, Jul 8, 2017 at 4:25 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     Maybe of interest to the Security Task Force:
>     https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-0-0/#basics-headers
> 
>     Apparently they use a signature based on a detached JWS supplied as a header parameter and where the data to be signed is simply the HTTP body "as is".
> 
>     So at this stage we have not less than three entirely different ways of dealing with signed JSON:
> 
>     - OpenBanking(UK) as described above
> 
>     - The Linked Data Signature scheme (initially) created by Digitalbazaar and adopted by the Verified Credentials CG: https://github.com/w3c-dvcg/ld-signatures
> 
>     - My JSON Cleartext Signature scheme: https://cyberphone.github.io/doc/security/jcs.html
> 
>     Anders
> 
Received on Sunday, 9 July 2017 04:30:40 UTC

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