Since the market for clear text JSON signatures is sort of heating up, the 
following may be of some interest...

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....@gmail.com 
<mailto:anders.rundgren....@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


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

Reply via email to