Financial-grade API (FAPI) FAQ
What is the FAPI Working Group?
The Financial-grade API Working Group is a working group at the OpenID Foundation. 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:
- Clear point-by-point specifications that implementers can use as a “check list”
- Exhaustive conformance tests to allow implementers to ensure their software is secure and interoperable
- 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.
What are the differences between the FAPI RW Implementers Draft 2 and FAPI 1.0 Advanced Final?
Please reference the normative changes documentation: https://bitbucket.org/openid/fapi/src/master/FAPI_1.0/changes-between-id2-and-final.md
What are the differences between FAPI 1.0 and FAPI 2.0?
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.
What are the advantages of FAPI 2.0?
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.
What is the current status of the FAPI 2.0 specifications?
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.
How can I suggest improvements to the FAPI 2.0 specifications?
You are very welcome to join the working group and propose changes: https://openid.net/wg/fapi/
Anyone can join the WG and contribute to the specifications after the submission of an IPR Agreement.
Are there conformance/certification tests for FAPI 2.0?
Not yet, but work is planned to implement tests for FAPI 2.0 Basic during 2021.
Which versions of FAPI are implemented (live) and where?
Here are some examples of Ecosystems that have implemented FAPI 1.0:
|Open Banking, UK||Consumer Data Rights, Australia||yes® QES Scheme|
|Specifications available at||https://standards.openbanking.org.uk/||https://consumerdatastandardsaustralia.github.io/standards/||https://yes.com/docs/qes/2.5/index.html|
|Version||FAPI 1.0||FAPI 1.0||FAPI 2.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_OPs
Are there FAPI 2.0 implementations?
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.
- 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
- 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.
Is FAPI 2.0 backwards compatible with FAPI 1.0?
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.
Is FAPI 2.0 more secure than FAPI 1.0?
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:
|FAPI 1.0 Baseline||Medium||None|
|FAPI 1.0 Advanced
FAPI 2.0 Baseline
|FAPI 2.0 Advanced||High||Comprehensive|
What is the current status of the FAPI 1.0 specifications?
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.
I’m creating a new ecosystem, should I adopt FAPI 1.0 or 2.0?
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.
Should all FAPI 1.0 ecosystems migrate to FAPI 2.0?
For the same reason as the above answer, this is an ecosystem specific decision.
Will FAPI 1.0 be maintained
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.
Can my authorization server support FAPI 1.0 and 2.0 at the same time to make migration easier?
This may be possible. FAPI 1.0 Advanced allows the use of PAR and PKCE. These are both required by FAPI 2.0.
Does a FAPI 1.0 Certified AS need to be OpenID Connect Certified
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.
Has there been a security review of FAPI?
Yes. the analysis of FAPI 1.0 was led by Daniel Fett is found at https://arxiv.org/pdf/1901.11520.pdf
FAPI Global Adoption References
|FAPI 1.0||FAPI 2.0|
|UK Open Banking||Open Banking UK FAPI Adoption Announcement
Most of the CMA9 have certified and OIDF anticipates OBIE requiring CMA9 to recertify annually
Barclays (Barclays OB TIAA)
|AU CDR (Data 61)||https://consumerdatastandardsaustralia.github.io/standards/#future-dated-obligations
Initial AU FAPI outreach workshops confirmed with AU DSB team for April 20th and May 4th
|yes Scheme||yes QES service is based on FAPI 2.0 Baseline|
FAPI Liaison Relationships
Financial Data Exchange (FDX) — USA
How does the FDX and OIDF collaboration work?
All FAPI work is done in the OIDF FAPI Working Group. The OpenID Foundation actively encourages participation in and contributions to all its working groups. FDX work groups operate under their own IP and membership rules. FDX makes independent assessments of normative references and certification requirements.
How does the FDX and OIDF liaison agreement work?
The FDX/OIDF agreement clarifies FDX’s usage of OIDF trademarks. The Liaison Agreement describes the common interests of the two organizations and how they might work together.
Can individuals and organizations be members of and contribute to both organizations?
Yes. OpenID Foundation recognizes the importance of diverse views and encourages robust community engagement. OIDF thanks organizations like Ping Identity, Intuit, Authlete and others for membership of both organizations and their contributions to FDX Work Groups as well as the OpenID Foundation’s Financial-Grade API Working Group.