[Openid-specs-fapi] Issue #142: Standardising ‘lodging intent” (openid/fapi)

[Dave Tonge]

New issue 142: Standardising ‘lodging intent”
https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent

Dave Tonge:

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:

1. UK OpenBanking

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.

2. Berlin Group

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.

3. Polish API

A custom parameter is included in a standard OAuth flow: scope_details. This contains a JWT with all the “intent” details. 

4. 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.