FAPI Specifications

The OpenID Foundation is busy as always, and the Financial-grade API (FAPI) family of specifications are moving at a high pace. We looked at a lot of this in last week’s webinar, and I thought I’d summarize what we discussed.

FAPI 1.0 Parts 1 and 2 are Final Specifications

Earlier this year, the working group accepted the FAPI 1.0 Part 1 and 2 as final specifications, making them ready for prime time. The FAPI specifications are profiles of the OAuth and OpenID specifications, turning some of the words SHOULD and MAY into MUST. The idea is to make the implementation of a financial grade platform easier, by specifying what parts of the specs you should focus on.

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. Some highlights:

• Confidential clients must use mTLS to the token endpoint

• Public clients must use Proof Key for Code Exchange (PKCE)

• Native apps to support BCP 212, i.e AppAuth

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, and some of the highlights are:

• No public clients

• Signed request objects (using JWT Secured Authorization Requests, JAR)

• Sender-constrained tokens using mTLS

• Only Hybrid flow or Code flow with JWT Secured Authorization Response Mode (JARM) are supported flows

The Curity Identity Server is certified against the Implementers' draft and will soon undergo the certification process for the final version of the spec. As of now, we support all protocols mentioned above. For reference, the FAPI 1 specs can be found here:

• https://openid.net/specs/openid-financial-api-part-1-1_0-final.html

• https://openid.net/specs/openid-financial-api-part-2-1_0-final.html

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, since they couldn’t be pulled into 1.0 without having breaking changes towards earlier drafts. 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. Like the first spec, FAPI 2.0 is divided into two parts: baseline and advanced. At the time of writing, some of the differences to highlight are:

PKCE + Pushed Authorization Requests(PAR) instead of Hybrid Flow

FAPI 1 uses the hybrid flow for integrity protection, using the ID token as a detached signature in the front channel. This enables the client to validate that the code was issued by a trusted source, and removes the possibility of code injection attacks. PAR and PKCE protect against the same things, without having the client perform the validation.

PAR adds an additional endpoint to the Authorization Server (AS) that is used by the clients to POST the parameters of their authorization request. The AS responds with a reference that is used in the usual authorization request by the client. This enables the AS to authenticate the client and parameters prior to the authorization request happening. A benefit of this is that any authorization details can be checked beforehand, for instance by looking up the contents of a transaction according to the lodging intent pattern. Since the client is authenticated, the AS might allow any redirect_uri. PAR is currently at draft 10 at the IETF’s OAuth working group.

Sender constrained tokens with Demonstration of Proof-of-Possession (DPoP)

FAPI 1 only allowed sender constraining tokens using the mTLS protocol. In 2.0, the DPoP method is allowed as well. DPoP has the benefit of not using certificates for the proof, but instead using raw keys. So there is no requirement for a PKI for using DPoP. More about it can be found in our overview of DPoP

JAR and JARM

The advanced profile is still at an early stage, but it already specifies the use of signed request objects (JAR) at the PAR endpoint. It also mandates the use of signed JWT responses (JARM). This ensures that the entire flow has full message-level integrity, which is a requirement for some national level identity providers.

JAR is RFC 9101

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. The specification was just recently published as RFC 9101.

Open Banking Brazil Certification Testing Open

The Open Banking work in Brazil is moving on nicely, and the specifications have come to the stage where they can allow clients and servers to start the certification tests.

Client Initiated Back Channel Authentication (CIBA) is Final

CIBA is a specification that defines a protocol between the client and AS, 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. 

The core CIBA specification has been voted final and can be considered done. But there is also a FAPI profile that is still in Implementers’ Draft, soon to be voted on. The Curity Identity Server supports both CIBA Core and the FAPI profile.

Read our article on CIBA in detail.

Upcoming specifications

The FAPI working group is working on specifying some more use cases still, and references specifications that are not yet done. 

Grant Management

The different Open Banking legislations all have the need for third parties to manage the consent they have with their users. This has typically been solved by creating an API for the third parties to use, which differs between the open banking types. The Grant Management specification is about standardizing this. Grant Management specifies an API for querying a grant and revoking it. It also adds parameters to the authorization request to update a grant. The specification is currently a draft, but is already mentioned in the FAPI 2 Baseline profile.

Rich Authorization Requests (RAR)

The Lodging Intent pattern is a popular pattern for payment transactions. In it, the client makes an API call, creating the “intent” of a transaction. An ID is returned by the API which is then referenced in the authorization request by using it in a prefix scope. The AS can then look up the intent from the ID, ask for consent and issue a token containing claims from the intent. RAR replaces this pattern by adding the contents of the intent to the authorization request in a parameter called authorization_details. Combining this with PAR keeps the sensitive information out of the browser, and allows the AS to verify that the client is allowed to perform such a request, before asking the user to authenticate. The specification has been debated since the same type of information could already be added to the claims parameter from OpenID. Regardless, it seems like RAR will make it into the FAPI suite of specifications, but perhaps not in the advanced profile.

FAPI 2.0 Advanced Authorization

In addition to the baseline and advanced profiles, the working group has started the work on a new document: the Advanced Authorization profile. This will likely reference things such as Grant Management and RAR, but is currently merely a skeleton at the moment. Expect some work happening on this specification in the near future.

Summary

With Brazilian Open Banking and other high-security scenarios pushing things forward, it really is exciting times in the Open Banking space. Specifications that have been worked on for a long time are getting into the final stages, and new interesting ones are emerging. For a standard-driven company like Curity, it means a lot of great new features making their way into the product. So, look out for coming releases and certifications!

We recorded the webinar version of this and you can watch it at your leisure here.