Subject: Re: [jose] Signed JSON for "Open Banking" - An implementation report

From: Nat Sakimura <[email-masked]>
Date: Thu, 14 Dec 2017 04:08:01 +0000

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 <
[email-masked]> 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
> <https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56HTTP-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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 14 Dec 2017 07:51:09 +0100

On 2017-12-14 05:08, Nat Sakimura wrote:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Dear List,
>     Here is a list of the three most well-known APIs for Open Banking and their take on "Signed JSON":
> 
>     HTTP-Signatures <https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56HTTP-Signatures> (clear text messages using a not yet standardized signature scheme)
> 
>     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
>     and security protocols needing artificial outer layers in order to make objects recognizable
>     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?
> 
>     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.
> 
>     [email-masked] <mailto:[email-masked]>