The original post was written by Daniel Lindau and published in the Curity blog. Read it here for a fuller and more detailed overview.
It is a very exciting time in the financial sector with open banking expanding across the globe. Open banking is disruptive and innovation-driving, making the whole industry address existing technological and market demands.
For organizations, open banking means the need to adapt to regulatory and customer demands for access to sensitive data. This is primarily driven by APIs, and they need to achieve an extremely high-security standard to protect the sensitive data being exchanged.
Such safe APIs are created with the Financial-grade API (FAPI) family of specifications. Let’s look at their present state and see what developments we should expect in the near future.
FAPI 1.0 Parts 1 and 2
Earlier this year, the working group accepted the FAPI 1.0 Part 1 and 2 as final specifications, making them ready for prime time.
Part 1 is the baseline profile, specifying the lowest security level acceptable for a financial grade platform. In this profile, there are mostly instructions to use for your servers and clients to keep your data private.
Part 2 is the advanced profile recommended for APIs containing highly sensitive data needing a higher level of security. An example could be an API that allows for payments. The advanced profile extends the basic profile with stronger requirements.
FAPI 2.0
Even though FAPI 1.0 just got into its final stage, FAPI 2.0 is already being heavily worked on. The reason for this is to include the newer specifications into the profile. Using the newer specifications with privacy and integrity built into the protocol allows the specifications to be less strict on the requirements for encrypted requests and JWT response modes. This makes client implementations easier as well. At the time of writing, some of the differences to highlight are:
- PKCE + Pushed Authorization Requests (PAR) instead of Hybrid Flow
- Sender constrained tokens with Demonstration of Proof-of-Possession (DPoP)
- JAR and JARM
JAR
The JAR specification defines the way to send request objects in the authorization request. This was already supported in OpenID Connect, but JAR specifies the same sort of thing without requiring the use of OpenID Connect.
Client-Initiated Back Channel Authentication (CIBA)
CIBA is a specification that defines a protocol between the client and authorization server, to allow for authentication to happen out of band. This can be used, for instance, on terminal devices, where the user can be allowed to authenticate using an authentication app on their mobile phone instead of on the terminal which might have limited input options.
Upcoming specifications
With Brazilian Open Banking and other high-security scenarios pushing things forward, the Open Banking space is rapidly developing. Specifications that have been worked on for a long time are getting into the final stages, and new interesting ones are emerging.
The FAPI working group is working on specifying some more use cases. These are some references specifications that are not yet done but the ones we are looking for:
- Grant Management
- Rich Authorization Requests (RAR)
- FAPI 2.0 Advanced Authorization
_____________________________
To learn more about Open Banking specifications, check out these resources:
