FAPI for Berlin Group openFinance Framework

[api.adorsys]

I am working on this document to support the FAPI adoption in the Berlin Group ecosystem. Please for review and feedbacks:

https://docs.google.com/document/d/1e5M5aLgNgiu4kkPIt3BjSHBt2mZL9DkcQ7bfL4Zqdgw/edit

[Torsten Lodderstedt]

If I get it right, the document suggests to split BG into API and security/authz part as a preparation to adopt FAPI as is. I support this direction as it allows BG to benefit from existing work, expertise and future innovation in this area and implementors could use existing conformant products.

[Anders Rundgren]

Separating the core API and authorization is a very good idea.

However, I would be cautious about adopting FAPI “as is” because FAPI does not address the fact that banks (those who actually pay for the party), do not see Open Banking as something reserved to regulated TPPs.

That you (as far as I can tell) cannot build a “Swish” or “Saturn” on top of FAPI is an indication of that something is missing.  If banks are forced building special purpose solutions, the value of FAPI and similar decreases, which in the long run may prove to be is detrimental for all parties.

Before progressing this item, I would like the FAPI experts (I am not one), describing how FAPI can (or should) be used with EMV (the POS payment authorization scheme used by several billions of people).

@Dave Tonge @Torsten Lodderstedt @Joseph Heenan @Ralph Bragg @Francis Pouatcha

[Anders Rundgren]

Taken from the draft:

Regarding the separation I (still) consider as a problem because it (in an actual implementation) mixes an hopefully rather clean Banking API with proprietary AuthX API code. I believe it is technically possible creating a fully separated Banking API that in turn is invoked by locally trusted services implementing whatever AuthX solutions needed. This arrangement would make OAuth2 access tokens the auth method of choice for a “purified” Banking API. From the outside (for TPPs and other services), everything would look the same as today.

Many services would only use the OAuth2 access tokens internally since their associated locally trusted service would typically expose an entirely different interface, like EMV.

The separation between the Banking API and services permits flexible deployment and development options including clouds and sandboxes. Services may build on different platforms than the Banking APIs, enabling a single implementation of a service targeting any number of banks.

is just a note that there may be enterprise solutions where user authentication is dealt with by the enterprise making a PSU optional.

[Anders Rundgren]

@Francis Pouatcha

By merging your excellent separation proposal with the direct mode concept we could get something like this:

In this model the Open Banking API would be similar to a File API in an operating system. Locally trusted client certificates assure authority while access tokens indicate which user (or user group) the call is referring to.

The Proxy Service would probably be able to reuse substantial parts of the existing authz code, rather than requiring a major rewrite. With the exception of authorization and consents, the Proxy Service is effectively a reverse proxy performing URL rewrites and such.

A Payment System Specific API and Service may or may not be PSD2 compliant. Such a service is also a “proxy” but in most cases in a rather abstract way since the external API may be quite different to the Open Banking API.

In Saturn, PSD2 authorize (Berlin Group OAuth pre-auth) is used during user enrollment to acquire access tokens, while the rest is handled by proprietary services.

[Anders Rundgren]

There is still something missing: whatever PSU authentication or authorization scheme a service uses, the succeeding operations depend on the PSU id but in the form of an access token. It seems that a generic but privileged method for getting an access token from a PSU id could be useful. The method would also verify that the PSU id exists.

Alternative

Maybe this is completely backward? The purpose of access tokens is to provide secure, time-limited, cookie-like handles to PSUs, while eliminating the need for exposing PSU ids, right?

However, locally trusted services do not gain functionality or become security-wise “stronger”, by converting access tokens and PSU ids back and forth. Proposal: use PSU ids as input to the Open Banking API instead of access tokens. For PSD2 and similar services where access tokens come from the less trusted world, access tokens would need to be converted into PSU ids. That is, there is a need for a privileged method going in the other direction as well.

For maintaining sanity, the Open Banking API would still be required to verify the authenticity of supplied PSU ids and their relation to specified accounts.

To make this work, the longevity of access tokens and scoping would be confined to the locally trusted services. That is, policy would (as much as is possible…), be out of scope for the Open Banking API.

[api.adorsys]

@Anders Rundgren the final decision on whether or not to trust the token and service the request is left to the Banking API (as a resource server).

[Anders Rundgren]

From the draft:

The core banking business API will focus solely on aspects associated with the banking business API. This API will always assume that an authorization layer has dealt with the legitimation of the TPP and the authorization of the PSU.

To me this sounds very similar to what I am proposing.

@api.adorsys @Francis Pouatcha The “purified” Open Banking API and Proxy Server inside of the depicted dashed container represent the Open Banking API of today but “decomposed”. No matter what you do, you will at one point need to trust a preceding step like a token verification. In the proposed scheme, externally provided access tokens are exclusively created and validated by the Proxy Server while the “purified” Open Banking API is only exposed internally. It is essentially a layered security system.

Although this may at first sight appear a bit strange, it becomes more logical when you add Embedded SCA to the pudding since the outcome of a successful Embedded SCA validation is (AFAICT….) just a PSU id, an operation, and associated data.

The assumption here is that the Proxy Server and ”purified” Open Banking API enjoy the same level of trust although they do not necessarily run on the same box.

[Anders Rundgren]

I updated the image so that it better matches the draft and my alternative path:

The Banking API is obviously not open; it can only be accessed by privileged services. The latter may run on dedicated boxes, use any suitable programming platform, and even be provided by another party than the one responsible for the Banking API.

[Anders Rundgren]

Missing from the draft:

Berlin Group openFinance adds standardised extensions beyond the regulatory PSD2 scope that enable bank customers (consumer or corporate account owners), directly or via a Third Party Provider (TPP), to access bank accounts for commercial premium services and data.

That is, this specification-to-be, potentially also targets bank-driven payment systems like “Swish”, that effectively competes with PSD2-based schemes.

[Anders Rundgren]

This proposal currently has the priority set to “minor”.

However, for an implementer or API designer something along these lines would be anything but minor. Could we begin by settling if this is an issue for FAPI or not?

Cheers,
Anders

[Nat Sakimura]

Updated the priority to major to surface this issue.

[Nat Sakimura]

Francis reported the current situation on Apr. 21 call.

[Anders Rundgren]

To me this seems like a really big issue and I believe we are not particularly much on the same page.

In my vision (FWIW) it is about a revised Open Banking [security] architecture, and not about new APIs. In this architecture OAuth2/OpenID would represent a class of applications, but not the only one. EMV would (still in my vision) probably use another security model.

Berlin Group intend to build-in EMV into the core, which I’m opposed to. I see it like a file API in an OS. There are a bunch of quite different applications that can call the file API but they are outside of the core and they all build on trusted applications using specific security solutions often involving an initial authentication. The file API does not know how the calling application got the security handle, it has to trust the OS and applications. Although a 1-2-1 mapping to an OS is not possible, there are approaches that would achieve similar results.

This may sound like my previous “Direct Mode” proposal but it is not. I’m now suggesting a cleaner and more universal approach than “patching” OAuth2.

[Dave Tonge]

stale issue - I have reached out to Berlin Group to get a status update