The FAPI Working Group is a working group at the OpenID Foundation. FAPI was previously known as the Financial-grade API but there was consensus within the working group to update the name to just FAPI to reflect that the specification is appropriate for many high-value use-cases requiring a more secure model beyond just financial services.

The group has expert members from the Identity and Access Management sector. The working group was initially formed to help develop security profiles and API standards for financial APIs. Over time the group has focussed its efforts on security profiles that while applicable for financial APIs, can be used in other industries and ecosystems.

The security profiles developed by the working group are based on the OAuth 2.0 and OpenID Connect suite of standards. OAuth 2.0 is an authorization framework which can be used for both low and high value operations. The standards produced by the FAPI WG contain much less optionality than the general OAuth 2.0 framework and require implementers to use modern security best practices.

The major benefits of the FAPI specifications are:

1. Clear point-by-point specifications that implementers can use as a “check list”
2. Exhaustive conformance tests to allow implementers to ensure their software is secure and interoperable
3. Standards based approach to securing complex interactions (e.g. decoupled authZ flows via CIBA, grant management, pushed request objects).

The FAPI WG does not work on data models or standards for financial or other APIs. These are ecosystem specific.

Please reference the normative changes documentation: https://bitbucket.org/openid/fapi/src/master/FAPI_1.0/changes-between-id2-and-final.md 

FAPI 2.0 has a broader scope than FAPI 1.0. It aims for complete interoperability at the interface between client and authorization server as well as interoperable security mechanisms at the interface between client and resource server.

As a consequence, FAPI 2.0 provides mechanisms for obtaining fine-grained and transactional authorization for API access and security mechanisms for replay detection and non-repudiation on both interfaces in addition to the mechanisms already defined in FAPI 1.0 focusing on the security of the authorization flow.

The working group also evolved the profile to be easier to use for developers based on the results of an analysis of various open banking implementations, the recommendations of the latest OAuth Security BCP, and a comprehensive security threat model.

Both FAPI 1.0 as well as FAPI 2.0 define two compliance levels, but the FAPI 2.0 levels are aligned with different protection levels (baseline vs advanced) rather than API access modes (read vs read-write) in FAPI 1.0. The baseline level aims to be secure against all threats captured in the security threat model, the advanced level adds non-repudiation.

FAPI 2.0 provides a higher degree of interoperability and is easier to use while maintaining a comparable security level. FAPI 2.0 aims at on-the-wire compatibility between compliant implementations and to this end removes optional and alternative features.

The specifications are under development and are currently in ‘draft’ status.

The OpenID Foundation process for specification development is involves publishing one (or more) Implementers Drafts that have public review periods and are approved by the membership, then another review period / vote for ‘Final’ status.

For FAPI 1.0, the dates were:

First Implementers Draft: July 2017
Second Implementers Draft: October 2018
Conformance testing launched: April 2019
Final: March 2021

The working group intends to move FAPI 2.0 forward at a faster pace.

You are very welcome to join the working group and propose changes.

Anyone can join the WG and contribute to the specifications after the submission of an IPR Agreement.

FAPI 2.0 conformance tests were launched in March 2023. The first set of FAPI 2.0 self-certifications have been published and can now be viewed on the Certification Listings.

We congratulate Authlete, Cloudentity, ConnectID, Ping Identity, and Raidiam for achieving compliance with the current FAPI 2.0 certifications and for being thought leaders on the leading edge of this important work. We are grateful to ConnectID in Australia who adopted FAPI 2.0 for their ecosystem and funded the FAPI 2.0 conformance test suite development.

Here are some examples of ecosystems that have implemented FAPI 1.0:

The Financial Data Exchange is also working closely with the FAPI WG to implement the specs in North America.

Here is a list of FAPI 1.0 certified implementations: https://openid.net/certification

FAPI 2.0 as an OAuth profile utilizes OAuth features and extensions that are available in existing implementations or can be implemented on top of existing implementations.

In detail:

• PKCE – https://tools.ietf.org/html/rfc7636
  • This security mechanism is already widely supported by vendors.
• mTLS – https://datatracker.ietf.org/doc/rfc8705/
  • A standard for client authentication and sender-constraining of access tokens that is also recommended by the OAuth Security BCP.
• DPoP – https://tools.ietf.org/html/draft-ietf-oauth-dpop-02
  • A standard for sender-constraining access tokens at the application layer
• Pushed Authorization Requests – https://tools.ietf.org/html/draft-ietf-oauth-par
  • IETF specification awaiting publication
  • Wide adoption by open source projects and commercial vendors
• Rich Authorization Requests (RAR) – https://tools.ietf.org/html/draft-ietf-oauth-rar
  • RAR can be implemented on top of OAuth 2.0 implementations as an extension parameter. Existing implementations demonstrate the feasibility.
• Authorization Server Issuer Identifier in Authorization Response
  • https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp
  • Can be implemented on top of existing OAuth 2.0 implementations.

The working group has been informed that the following organisations have implemented FAPI 2:

• yes QES Scheme Signing API (implemented by three different authorization servers), uses PKCE, mTLS, PAR, RAR, iss authorization response parameter
• Authlete: Supports PKCE, mTLS, PAR, RAR and the iss response parameter.

The working group is not endorsing these organisations or their products, we are simply reporting information that we have received.

There are similarities between FAPI 1.0 and FAPI 2.0 (e.g., response type code + PKCE in FAPI 1.0/read and FAPI 2.0/baseline) but the scope is different so there is no full backwards compatibility.

The reason for work on the 2.0 draft is not a more secure specification than 1.0, but rather FAPI 2.0 aims to be:

• simpler to implement (less requirement on message signing without reducing security),
• more interoperable (through reduced optionality),
• closer aligned to the OAuth Security BCP,
• wider in scope – covering fine grained and transactional authorization, which was out of scope of FAPI 1.0.

Regarding security, FAPI 1.0 has been analyzed using an in-depth formal analysis. FAPI 2.0 provides a more clearly defined attacker model with the aim to make the standard easier amenable to this kind of analysis and to make the security-related decisions in the specification more transparent.

It is worth noting that FAPI 2.0 Baseline aims to protect against a similar attacker model as FAPI 1.0 Advanced. FAPI 2.0 Advanced further extends the scope of FAPI 1.0 by bringing “non-repudiation” to all exchanges. This table gives a rough comparison:

The final version of the 1.0 specifications were published in March 2021.

A final spec is one that has gone through multiple rounds of review by many industry experts and has multiple live implementations.

There are valid reasons for adopting 1.0 or 2.0.

• If vendors in an ecosystem already support FAPI 1.0, this could be a valid reason to use it.
• If an ecosystem is already using OpenID Connect for identity claims, it may be harder to use FAPI 1.0.
• FAPI 1.0 is a mature and widely supported security profile.
• FAPI 2.0 requires less use of message signing which may make it easier to implement (especially for clients).
• FAPI 1.0 does not cover complex authorization requests and grant lifecycle management, so you might need to implement a custom solution. FAPI 2.0 covers these aspects. Although the specifications are still in development they already represent the experience gathered by the WG and others who have implemented such solutions.

For the same reason as the above answer, this is an ecosystem specific decision.

Yes, if there are any security issues, or major interoperability issues found with FAPI 1.0 the working group is likely to update the FAPI 1.0 specs. However the specs have been used in production in multiple ecosystems for some time, so the working group does not expect many (if any) changes to FAPI 1.0.

No new features are planned to be added to FAPI 1.0.

This may be possible. FAPI 1.0 Advanced allows the use of PAR and PKCE. These are both required by FAPI 2.0.

The FAPI and OpenID Connect certifications are orthogonal. In order to pass OpenID Connect certifications servers would have to support various lower security methods (like client_secret_basic for client authentication) that would generally not be enabled in FAPI compliant servers.

Yes. the analysis of FAPI 1.0 was led by Daniel Fett is found at https://arxiv.org/pdf/1901.11520.pdf