From nobody Wed Dec 13 20:08:16 2017 Return-Path: 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 75DA31270A0 for ; Wed, 13 Dec 2017 20:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NW8n2X1ijTO1 for ; Wed, 13 Dec 2017 20:08:13 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 43615126C22 for ; Wed, 13 Dec 2017 20:08:13 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id u62so8225885ita.2 for ; Wed, 13 Dec 2017 20:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NHF9Psptg8oa0o2R3YYUa23wn//rKXfCkfscoUev/6s=; b=GFgm0VZq6TfH8YDLP9fLZchoDLgBwvcLX1y6IpohYe+YDkXe0QW5lanq3DY5mxCBI4 FgMy4lUZAAASFlhez8BHIUGt6Gc2yXjxDPa6UBHjdNdn0F3/7ZAn88asIgi8t0pn8oES FYg2b81LRRfwMy+UZF7f9kxoMeWYUErSAt6cTLtWXEggitxe6+yPVevgM9DenxfrlMJv LRK1XTu/Gne22OuZ+EGORATGiEl7TFHe38+FRM22tKSjKwbsFgY0S636KfPU25PSwxUU w84voljoTmj8Jft/t+OKqTOzWySxq25aan6juM24enwX9RNP79ajCGsl0u7ztF6agQvt aeZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NHF9Psptg8oa0o2R3YYUa23wn//rKXfCkfscoUev/6s=; b=SORCQKb6DZF5QdHVatoOzApHwRzpA3fiFTL8IkpmpZyw+VNQk298VcVNd2xUenSai8 TqHMv6z/JDfPe3QOYjXaxs/cUEZJMo845hkuBedikvTf6DVVxQ5bUfKBCl1K3rvgXFqc 4Vxdm8ghe4Jyv7d9Cfe/KaK/f1ab6GsrE/QM8o4NCRFBVWTeAXEegH+fI01kJVa+92cL BUmcMKh2SDAetmB0bYltythg16NyhMHMVWLNsPrVUv0TWghYZz0X0dX5cL1WBfysdbrx DDcqpzR/MQE88XJiR9bPgmBrkvW7PRaZDU5BvD7dlVmD+bxKzI0JDKCxRITMMmGtj8iz 4bdw== X-Gm-Message-State: AKGB3mK0tLFxwdLzxf7S3U49iK+oLcWQtIGzyk5yGCyD6bz/r9MF0BdK Cb4rqnKM8WxaToV7zRQN19MMFHqEwpFC2rXImrE= X-Google-Smtp-Source: ACJfBossSfwQAFqv7WyZML24rGBHm+5Uen15238oxa1htdk5fu3qkSqrmXyAm3umBfOHGYxmkl2wqFyuhLr8qh3ZUPw= X-Received: by 10.107.112.22 with SMTP id l22mr6062204ioc.145.1513224492337; Wed, 13 Dec 2017 20:08:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Thu, 14 Dec 2017 04:08:01 +0000 Message-ID: To: Anders Rundgren Cc: "jose@ietf.org" Content-Type: multipart/alternative; boundary="089e082be2f454d48805604508b5" Archived-At: Subject: Re: [jose] Signed JSON for "Open Banking" - An implementation report X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 04:08:15 -0000 --089e082be2f454d48805604508b5 Content-Type: text/plain; charset="UTF-8" Part of the reason for people preferring non-base64ed content is the tooling issue. The current OpenAPI tooling does not take care of the Base64url encoded body or JWS. Once the support comes, the pain will be much less. On Fri, Nov 17, 2017 at 3:53 PM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > Dear List, > Here is a list of the three most well-known APIs for Open Banking and > their take on "Signed JSON": > > http://openid.net/specs/openid-financial-api-part-2.html#request > In-line JWS (base64url-encoded messages) > > https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56 > HTTP-Signatures > > (clear text messages using a not yet standardized signature scheme) > > > https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant-illustrative-interactions-payment-setup > Detached JWS (clear text messages signed by a JWS in a specific HTTP > header) > > I believe this supports my view that base64-encoded JSON will continue to > be a hard sell no matter how good it may be. > > Other "uncool" side-effects include lookup services providing signed > responses in base64url > https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2.1 > and security protocols needing artificial outer layers in order to make > objects recognizable > https://tools.ietf.org/html/draft-pei-opentrustprotocol-01#section-8.2.1.1 > > May I propose a JOSE2 effort based on ES6.JSON serialization [1] to end > the current proliferation of "DIY standards" and reducing the need for > [ugly] workarounds like used by UK's Open Banking? > > Making JOSE more Browser/JS friendly wouldn't be a terrible idea, either. > > Availability of ES6.JSON compatible tools isn't really a showstopper, we > are talking about < 2000 lines of pretty simple [2] code for parsing and > serialization. > > thanx, > Anders > > 1] > https://cyberphone.github.io/doc/security/jcs.html#Normalization_and_Signature_Validation > > 2] Well, number serialization is non-trivial so implementers probably need > to build on already written code and algorithms out there like I did. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura Chairman of the Board, OpenID Foundation --089e082be2f454d48805604508b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Part of the reason for people preferring=C2=A0non-base64ed= content is the tooling issue. The current OpenAPI tooling does not take ca= re of the Base64url encoded body or JWS. Once the support comes, the pain w= ill be much less.=C2=A0

On Fri, Nov 17, 2017 at 3:53 PM Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
Dear List,
Here is a list of the three most well-known APIs for Open Banking and their= take on "Signed JSON":

http://openid.net/specs/openid-finan= cial-api-part-2.html#request
In-line JWS (base64url-encoded messages)

https://www.s= tet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=3D56
HTTP-Signatures (clear text messages using a not yet standardized signa= ture scheme)

https://www.openbanking.org.uk/rea= d-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant-illustr= ative-interactions-payment-setup
Detached JWS (clear text messages signed by a JWS in a specific HTTP header= )

I believe this supports my view that base64-encoded JSON will continue to b= e a hard sell no matter how good it may be.

Other "uncool" side-effects include lookup services providing sig= ned responses in base64url
https://tools.ietf.org/html/dra= ft-ietf-oauth-discovery-07#section-2.1
and security protocols needing artificial outer layers in order to make obj= ects recognizable
https://tools.ietf.org/htm= l/draft-pei-opentrustprotocol-01#section-8.2.1.1

May I propose a JOSE2 effort based on ES6.JSON serialization [1] to end the= current proliferation of "DIY standards" and reducing the need f= or [ugly] workarounds like used by UK's Open Banking?

Making JOSE more Browser/JS friendly wouldn't be a terrible idea, eithe= r.

Availability of ES6.JSON compatible tools isn't really a showstopper, w= e are talking about < 2000 lines of pretty simple [2] code for parsing a= nd serialization.

thanx,
Anders

1] https://= cyberphone.github.io/doc/security/jcs.html#Normalization_and_Signature_Vali= dation

2] Well, number serialization is non-trivial so implementers probably need = to build on already written code and algorithms out there like I did.

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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--089e082be2f454d48805604508b5-- From nobody Wed Dec 13 22:51:18 2017 Return-Path: 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 8555D126DFE for ; Wed, 13 Dec 2017 22:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 KLqJxyV32QUw for ; Wed, 13 Dec 2017 22:51:15 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E2DAB126DED for ; Wed, 13 Dec 2017 22:51:14 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id t8so9185016wmc.3 for ; Wed, 13 Dec 2017 22:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oNwRbRk++ISgTNah47wNiELzdGTBspCqLK/xEJQlgfI=; b=L2BXkLF0NYieH5Clmntt+Ihqtq9mp823faStFItQTbFt4SYV2UER1ThEmOqOfJnpYr xdnmHFDqVKdtLeU1J53Ahh+TnTyA0BJswZACMvSK/KXB/RbAZLhi93ZBVx80aWe8/Rg2 2hJ0tYxDOKQLKGrEL/9+vulfep9wLVCTsi1LKFJBbs8/FNgVQE2kbJVntlpXBoqpBmL2 Rpo9lxTMzwHMjJ3SbXxGsjsSJp164PeINvkeMuj063Mm8EBSz0YYowPtpyBGmT6T4wNp 8SbNMmq9u0oB8NM3VBOJPuIqomWaX4S4NtQhDerozBT2wjeAenSqKLqC+vzCktvtAmBu xHZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oNwRbRk++ISgTNah47wNiELzdGTBspCqLK/xEJQlgfI=; b=N31T+nO6KYXLW/3nr5HSK97mo5Yua7TRjhQFeMQ9bcLvUhZubdxAHfN63tH5w36II9 g84rMZOoRWIrjb5DQCm1P0w3SW+tAp9Eo4bwJ3uBdg8j9OpS+impkQYi8TeJQKlvSLyU nzeFWVs2GWK5QamkNxZQUJnPQ/ZzmAX590EQAXH9KQaikPo8nvAd4EiyDBtNr7oLedHV ZvzZ8FgV3QZbTMjyhrE/EBDCJmZL0JFmrrCIz+UaVcclkERuX3D5Wbza8m/tMptVUJzO 47zZM+svbuatziZQ55GNkt/WTEp1gFS4EZq+6MKzTHSk9oSvyKUd3qFwSCEFpE97qWyM qdsw== X-Gm-Message-State: AKGB3mKgPoLLsNQvMrZwugXcXUQpsQeRHvuICLI5Xc3sxPOijw71Q3q9 2W5QUfxZP1EXoI21xDk9+r3yqQ== X-Google-Smtp-Source: ACJfBou5cyu6qXcGxTi7i5w1uP4VKskQAD+9wQDTStPmQ3WKamyVwZMF6ziExypmz+Xu/38374ds7w== X-Received: by 10.80.205.25 with SMTP id z25mr10991000edi.77.1513234272825; Wed, 13 Dec 2017 22:51:12 -0800 (PST) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id z5sm2386229edh.76.2017.12.13.22.51.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 22:51:11 -0800 (PST) To: Nat Sakimura Cc: "jose@ietf.org" References: From: Anders Rundgren Message-ID: <00c91be7-87ae-89c2-abc1-df4a9b487e3e@gmail.com> Date: Thu, 14 Dec 2017 07:51:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] Signed JSON for "Open Banking" - An implementation report X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 06:51:17 -0000 On 2017-12-14 05:08, Nat Sakimura wrote: > Part of the reason for people preferring non-base64ed content is the > tooling issue. The current OpenAPI tooling does not take care of the > Base64url encoded body or JWS. Dear Nat, I have no inside information on this, I only took a "Snapshot" of the current situation which nowadays also includes the W3C who in an early writeup are toying with non-base64ed signatures while still claiming to use JWS: https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card#example-1 As it appeared in the W3C document above, 2017-12-14: { supportedMethods: "https://example.com/bobpay", data: { signedData: { merchantIdentifier: "XXXX", bobPaySpecificField: true }, unsignedData: {...}, dataSecurity: { signature: {...}, signatureCertPath: "public.pem" } } } Doesn't this look like yet another "DIY standard" in progress? My suggestion is only about "Rounding Out" the suite of already very nice JOSE standards, by giving implementers a more JSON-centric signature option. ES6+ compliant JSON serialization fully addresses the once thought "unsolvable" canonicalization issues. Best regards, Anders Once the support comes, the pain will be much less. > > On Fri, Nov 17, 2017 at 3:53 PM Anders Rundgren > wrote: > > Dear List, > Here is a list of the three most well-known APIs for Open Banking and their take on "Signed JSON": > > http://openid.net/specs/openid-financial-api-part-2.html#request > In-line JWS (base64url-encoded messages) > > https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56 > HTTP-Signatures (clear text messages using a not yet standardized signature scheme) > > https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant-illustrative-interactions-payment-setup > Detached JWS (clear text messages signed by a JWS in a specific HTTP header) > > I believe this supports my view that base64-encoded JSON will continue to be a hard sell no matter how good it may be. > > Other "uncool" side-effects include lookup services providing signed responses in base64url > https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2.1 > and security protocols needing artificial outer layers in order to make objects recognizable > https://tools.ietf.org/html/draft-pei-opentrustprotocol-01#section-8.2.1.1 > > May I propose a JOSE2 effort based on ES6.JSON serialization [1] to end the current proliferation of "DIY standards" and reducing the need for [ugly] workarounds like used by UK's Open Banking? > > Making JOSE more Browser/JS friendly wouldn't be a terrible idea, either. > > Availability of ES6.JSON compatible tools isn't really a showstopper, we are talking about < 2000 lines of pretty simple [2] code for parsing and serialization. > > thanx, > Anders > > 1] https://cyberphone.github.io/doc/security/jcs.html#Normalization_and_Signature_Validation > > 2] Well, number serialization is non-trivial so implementers probably need to build on already written code and algorithms out there like I did. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation >