Hi all, I'm working with financial APIs - APIs to initiate payments and APIs to retrieve balances and transactions.
May of these APIs are protected by OAuth 2.0 profiles, however there is a requirement to support the signing of API requests and responses for non-repudiation purposes. For example a bank may want to record an API request from a third party that is used to set-up the details for a payment. If there is a dispute with the payment, the bank can retrieve the signed API request as proof that the third party set-up the payment. On the response side, a third party may want to record an API response from a bank that contains a list of transactions. Eventually such a signed payload could be used as part of a loan application (rather than the existing method of scanned in paper statements). In Europe we have a number of standards groups who are defining these APIs on behalf of banks. Unfortunately they are all taking different approaches to this problem - including the use of a draft that I understand isn't on a standards track. Berlin Group (https://www.berlin-group.org/nextgenpsd2-downloads) requires the use of the individual "Signing HTTP Messages" draft - https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ STET (https://www.stet.eu/en/psd2/) also requires the use of the same "Signing HTTP Messages" draft. OpenBanking UK specifies the use of RFC7515 (JWS) & RFC7797 (JWS Unencoded Payload Option) - specifically with the detached payload option. However they require a custom header: `x-jws-signature` and custom private header parameter names that replicate `iat` and `iss` keys that are normally in the JWT body. ( https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0#AccountandTransactionAPISpecification-v1.1.0-Non-repudiation ) I have a number of questions that it would be great to hear your views on: 1. Does anyone have further information about the draft-cavage-http-signatures spec - I am concerned about an individual draft being used for these high value APIs? 2. Are there any views on a better way to solve this problem, for example: https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 The reason I've heard against just returning a JWT is that it means that APIs are essentially just serving blobs of encoded data which could make them harder to develop against or debug. I don't like the idea of a detached signature in the header as it makes the process of storing the data for later non-repudiation purposes harder and more error prone (when compared to a message with a self-contained signature). While in some ways tangential to OAuth, I believe that this working group is well placed to solve this problem. I am concerned that as things stand we will end up without any interoperability for this problem due to the lack of appropriate standards. Thanks Dave
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
