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 [email protected] https://www.ietf.org/mailman/listinfo/jose
