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

[Anders Rundgren <[e-mail]>]

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.