In financial APIs, especially when making payments, there is a requirement to pass a lot more information than a simple “scope” from the client to the bank in order for the bank to gain consent from the end user. For example rather than asking for access to a user’s profile, the client is asking for permission to make a specific payment to a specific payee for a specific amount. Current approaches to this are:
A custom endpoint on the resource server that requires an access token issued with client credentials grant (i.e. scoped to the client and not any particular user). The client can lodge a payment initiation details at that endpoint and receive back an “intent id”. This intent id is then passed in a request object as a custom claim parameter back to the bank. The intent id is long lived and the client can interrogate the status of the payment initiation via restful endpoints.
A custom endpoint is provided that allows the client to lodge payment initiation details and receive back a payment id. For the OAuth flows, the payment id is passed as a scope value back to the bank. The payment id is long lived and the client can interrogate the status of the payment initiation via restful endpoints.
A custom parameter is included in a standard OAuth flow: scope_details. This contains a JWT with all the “intent” details.
FAPI Part 2
A request object endpoint is defined that allows clients to lodge request objects (with any number of custom claims) and receive back a request_uri (that could be a urn). This is compliant with OIDC and OAuth JAR.
My personal preference is for what we have in FAPI Part 2 - however I recognise that there are potential complications about the integration points between a vendor supplied IAM solution and a banks own systems.
Should we specify (or provide guidance) around an approach similar to UK Open Baking, Berlin Group or the Polish API?
I strongly believe we need to push for standardisation of one of the above or another approach to this problem.
I'd be interested in @b_c and @josephheenan views on this from a vendor perspective.