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

[Anders Rundgren <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/jose
> 
> -- 
> 
> Nat Sakimura
> 
> Chairman of the Board, OpenID Foundation
>