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:

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.

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.

Polish API

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.

[Brian Campbell]

While there is a lot of conceptual similarity with the UK OB and Berlin group endpoints and the request object endpoint, I tend to think of them as serving distinct purposes. The OB/Berlin endpoints are for setting up the payment info. And the request object endpoint is for setting up the OAuth/OIDC protocol request details. And I do believe that trying to put the payment initiation details together with the request object details into a single endpoint will make integration with vendor supplied IAM solutions quite cumbersome or prohibitive.

While a common or standard way of doing things is nice, I think the ship has already sailed on this one. I think it's highly unlikely that any of those groups will change at this point, even if FAPI had some guidance.

Furthermore, there's this push to generalize FAPI so that it (or whatever it will be called in the future) can have wider applicability of the security profiles beyond only financial APIs. So FAPI probably shouldn't be trying to define how to set up financial transactions. But rather focus on the general security profile of the protocols.

[Torsten Lodderstedt]

there was a discussion on that topic on the OAuth mailing list: https://www.ietf.org/mail-archive/web/oauth/current/msg18125.html

[Torsten Lodderstedt]

I believe we could specify a pattern how resources could be used to stage authorization transactions and how the link to such a resource could by conveyed into a authorization transaction. That would be very helpful for protocol/API designers.

[Dave Tonge]

We discussed this issue on the call yesterday. Australia is also working through this design decision. We discussed that passing an id as a scope value was valid OAuth and that this pattern was starting to be implemented by vendor products.

We agreed that it would be helpful to either specify something to do with this or at least provide guidance on it.

[Dave Tonge]

We briefly discussed this on the call, Torsten will propose some text around this

[Torsten Lodderstedt]

Added new document describing the pattern to the repp https://bitbucket.org/openid/fapi/pull-requests/90/new-document-describing-the-lodging-intent

[Dave Tonge]

Thanks Torsten - we discussed on the call a couple of days ago and agreed that the doc should be merged in. I will close this issue and we can open new issues to help improve the document.