Whether you believe the hype or not, open banking still elicits an incredible amount of coverage in the financial services and computing press. However, there is also a huge amount of variance in different regions. The UK is seemingly taking pause for thought, standards bodies like the Berlin Group are looking towards open finance, and regions like Brazil are rapidly accelerating with new market-wide standards and regulations.

However, one area that is becoming increasingly consistent is security for open banking APIs. Where an API does not fall into the remit of open data — where the data should be freely available and accessible — an increasing number of regions and standards bodies are looking towards the Financial Grade API (FAPI) standard. We’ve covered FAPI on the blog before, but as open banking becomes more ubiquitous, the scope and protections offered by FAPI are maturing.

The changes being engineered by the FAPI Working Group have brought about a new version of the standards: FAPI 2.0. In this post, we outline what’s new and uncover why FAPI 2.0 improves what’s gone before.

Overview

Like FAPI 1.0 before it, the continued goal of FAPI 2.0 is to provide significant protection for financial services APIs through standards built on OAuth. The working group website outlines the following three high-level objectives:

• enable applications to utilize the data stored in the financial account.
• enable applications to interact with the financial account.
• enable users to control security and privacy settings.

These objectives have been consistent since FAPI 1.0. However, clear themes are emerging in the development of FAPI 2.0:

• Cohesion: The FAPI 1.0 profiles grew organically in many cases, with some elements being taken from the now-defunct UK Open Banking Security Profile. From its inception, FAPI 2.0 is a product of the FAPI Working Group, with clear goals and objectives for the Profile.
• Representation: The new requirements are based on a formalized Attacker Model that provides a well-defined representation of the threats that the Profile aims to address. This creates an improved baseline for implementers trying to understand the standards.
• Richness: As open banking evolves into open finance, there is a need to support a greater level of sophistication in the authorization requests that can be made, with support for more fine-grained authorization metadata.

These themes will become apparent as we walk through each FAPI 2.0 profile, namely:

• Baseline
• Advanced
• Grant Management

Each of the profiles above is still evolving, with Grant Management now approved as an Implementers Draft. Like FAPI 1.0, the Baseline Profile forms the entry-level to FAPI compliance and is based on OpenID Connect Core. The Baseline and Advanced Profiles relate to the gradual hardening of API security, while Grant Management relates to formalizing the management of consent.

Baseline Profile

The Baseline Profile nominally replaces the Advanced (renamed from Read-Write) Profile from FAPI 1.0 and sets the minimum requirements for a FAPI-compliant Authorization Server, Resource Server, and Client. The Baseline Profile outlines some of the significant changes and improvements from the equivalent FAPI 1.0 profile. The changes include:

• More secure transmission of authorization requests: FAPI 1.0 leveraged the existing OpenID Connect Core mechanism for sending authorization requests as signed JSON Web Tokens, with the most typical approach to send the request via the browser when the End User is sent to the Authorization Server. Pushed Authorization Requests (PAR) replaces this mechanism entirely. PAR mandates that authorization requests be sent by a protected backchannel to the Authorization Server, ensuring the request stays confidential. The Authorization Server returns a URI in response, which is passed at the Authorization Endpoint instead of the request object. This significantly improves the protection of the integrity of the authorization request.
• Increased richness in authorization metadata: The Baseline Profile references Rich Authorization Requests (RAR), a standard that adds the authorization_details parameter to an authorization request that “allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures“. This will allow both Authorization Servers and Resource Servers to ensure they explicitly enforce user consent, only serving data that the user has agreed to share. RAR also allows consent to become an explicit part of the API security standards. Before consent, APIs often have been implemented separately to the security stack. Security vendors can now increase the reach of their offering, extending it to cover consent where previously they — and the organizations implementing their solutions — may have chosen to implement a consent API in API management.
• Increased flexibility in the security implementation: The Profile includes the “Demonstrating Proof-of-Possession at the Application Layer” (DPoP) standard as a means for binding access tokens to a given private key. This allows implementers to move away from Mutual TLS (MTLS) as the sole means for constraining access token usage.
• General improvements to the security posture: Various features are introduced to harden security, such as the mandatory use of Proof Key for Code Exchange for all Authorization Servers and Clients. ID Tokens are also no longer returned via the browser — through the restriction of the response_type parameter to code — and are only returned via a backchannel.

The Baseline Profile, therefore, provides a cohesive set of measures that are designed to increase both the security and usability of the FAPI standards. The Advanced Profile then builds on these to provide greater protections for read/write operations.

Advanced Profile

The Advanced Profile is currently still being created, but as with FAPI 1.0, it serves to harden security for operations such as making a payment. The features are not necessarily new, but like the Baseline Profile, the Profile reflects the Attacker Model in addressing a suite of well-defined risks. Highlights in the current draft include:

• Mandating signing for PAR for purposes of non-repudiation.
• Mandating the use of JWT Secured Authorization Response Mode (discussed in our post on FAPI 1.0) to protect the integrity of the Authorization Code inflight.

As with the Baseline Profile, these features serve to bring together aspects of underlying standards in a cohesive fashion, ensuring that existing implementation efforts can be built upon effectively.

Grant Management

The final profile FAPI 2.0 introduces is Grant Management. This standard aims to replace the variety of consent management APIs that have been created in open banking markets around the world with a unified set of capabilities based on grants (the permissions granted by the End User based on their consent).

These capabilities include:

• Granting access and returning a grant_id.
• Querying the details of a grant through a GET.
• Update of a grant.
• Deletion of a grant.

These capabilities may seem trivial, but they serve to formalize grant management behaviors for FAPI implementers. The standard also uses RAR to underpin the definition with the metadata typically found in existing consent management APIs. This brings together a cohesive and rich mechanism for performing grant management activities in a single implementation that reduces complexity for implementers.

Final Thoughts

In our original post on FAPI 1.0, we stated that the standard is “only as good as its adoption“. To that end, we are seeing increasing numbers of open banking markets and standards opting to use FAPI, and many implementations certifying their implementation as FAPI OpenID Providers with the OpenID Foundation. This groundswell of implementers certifying their stack, along with the increasing number of country-specific profiles such as the UK, Australia, and Brazil, lends credence to the fact that FAPI is the market-leading security profile.

However, open banking is still, relatively speaking, in its infancy. Mistakes are being made, and kludges are being kludged together. It’s also imperative that standards can evolve and improve. Therefore, it stands to reason that the FAPI Working Group seeks to evolve the standards towards FAPI 2.0. Implementers might balk at the fact that a new standard is being created. However, only by embracing continuous improvement throughout the ecosystem can the promise of open banking — and its evolution into open finance — be realized.