[jose] JSON Signatures in OpenBanking (UK)

Anders Rundgren <anders.rundgren.net@gmail.com> Sun, 09 July 2017 04:48 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E9126B71 for <jose@ietfa.amsl.com>; Sat, 8 Jul 2017 21:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3lyTSr-aqXI for <jose@ietfa.amsl.com>; Sat, 8 Jul 2017 21:48:28 -0700 (PDT)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087BA124D37 for <jose@ietf.org>; Sat, 8 Jul 2017 21:48:27 -0700 (PDT)
Received: by mail-wr0-x242.google.com with SMTP id k67so16891305wrc.1 for <jose@ietf.org>; Sat, 08 Jul 2017 21:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=S2qz6CimD6X/ARw/DJ8SZIenUw0diwpqolTUQNbcTBo=; b=DfTZKrQ9WWu//9rx7YcwDPYpgZlCQWnYqpxUFh5EKRyyYIUbHaD4GU/i+5Xg6TJbNH NumGHGpLZFR+GQuy6m9qQCExC4iGj2IVSFWqCwfR1n5NxiV+wZkunORGoBsbDnEuTeaQ sngVnBKpQjVHpzZavNWmjn97+QiweVgh/vojYjZofrUQDr/nn+jfIrx/ocfzfVXT+KOM lvbF5xMfMdP2QH2M9aMrcDk5S10/xDO3N4WBgb7O/PNNi28M8yN0JTqS+PkfrzjooqFo FZvqyzXvxgsnJuMZPWvQ32tDuAPWS1fM+sfHnp9QfITvi+bwj6p3jpjk5XwRHJD9jgZT COkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S2qz6CimD6X/ARw/DJ8SZIenUw0diwpqolTUQNbcTBo=; b=jo7H6m/fn4cmB4gZWCXVL5r2kDWwjt0iSoFatFZLANPqAznAikoKekY7D8Pq7QiYLi k4SwCxbUICRY7mVLikNKif+dtPbq2ZNBROfndTrURh4mcK/XBawNEzPrbUMB0rqZn+lM qQN5ijMyOCE14TGOUFIuhcYNakYNJh29p+o1Zp2CzMULUodkucWOS7i0S1aQIu5o69Sk p7m+DQjV07ZqEomRneGD+mkQ/jye0c4K+ljoIa8P4+lWAhbK+Gt0HyMbZUtyTmHzJ/IG O8wc4fznz3WtbPXjs+edcTAFqglHUXz5ADoywN1A+MaSHk3bcqoWza9t7qJ6PfrSV5bY n4/A==
X-Gm-Message-State: AIVw110viHqFMXTt5eZTpa5qVKeO0BDCMEKxYQVbiOYm6xJRkOkSozYz jRBpjTWxHRETkZfc
X-Received: by 10.28.133.76 with SMTP id h73mr3563622wmd.92.1499575705911; Sat, 08 Jul 2017 21:48:25 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b94sm6046809wrd.40.2017.07.08.21.48.25 for <jose@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 21:48:25 -0700 (PDT)
References: <c76cd89f-8b37-ac39-2cdd-7795bf4ae111@gmail.com>
To: "jose@ietf.org" <jose@ietf.org>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Forwarded-Message-Id: <c76cd89f-8b37-ac39-2cdd-7795bf4ae111@gmail.com>
Message-ID: <24f14cb1-3117-0eaa-4447-6f26581595d6@gmail.com>
Date: Sun, 09 Jul 2017 06:48:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <c76cd89f-8b37-ac39-2cdd-7795bf4ae111@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/TqGu3LntFurpJouT7bFYV4MpMlY>
Subject: [jose] JSON Signatures in OpenBanking (UK)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jul 2017 04:48:30 -0000

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.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
>