FAPI Working Group - Overview

The FAPI working group provides JSON data schemas, security and privacy recommendations and protocols to enable applications to utilize the data stored in a financial account, to enable applications to interact with a financial account, and enable users to control the security and privacy settings.

FAPI Working Group
OVERVIEW

FAPI Working Group
CHARTER
FAPI Working Group
SPECIFICATIONS

FAPI Working Group
REPOSITORY

What is FAPI Working Group?

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.

In many cases, Fintech services such as aggregation services use screen scraping and stores user passwords. This model is both brittle and insecure. To cope with the brittleness, it should utilize an API model with structured data and to cope with insecurity, it should utilize a token model such as OAuth [RFC6749, RFC6750].

This working group aims to rectify the situation by developing a REST/JSON model protected by OAuth. Specifically, the FAPI WG aims to provide JSON data schemas, security and privacy recommendations and protocols to:

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

Both commercial and investment banking account as well as insurance, and credit card accounts are to be considered.

Whitepapers

“Open Banking, Open Data, and the Financial Grade API,” March 2022
A primer for markets looking at enabling Open Banking and Open Data, covering the origins of “user-consent” based data sharing, global adoption, key standards, implementation considerations, and application across industry verticals.

“Open Banking and Open Data: Ready to Cross Borders?”, July 2022, working draft
The whitepaper offers an overview of the global open data landscape and makes a hypothesis that the next stage of open data development will be focused on global interoperability.

“Financial-grade API (FAPI) Profiles”, July 2022
This paper provides a comparison of available FAPI profiles and recommendations for new markets looking to implement FAPI as their security profile.

Working Group Chairs

  • Nat Sakimura (NAT Consulting)
  • Anoop Saxena (Intuit)
  • Anthony Nadalin
  • Dave Tonge (Moneyhub)


The chairs can be reached at openid-specs-fapi-owner@lists.openid.net

Participation

To monitor progress and connect with working group members, join the mailing list.

To participate in or contribute to a specification within the working group requires the submission of an Intellectual Property Rights (IPR) contribution agreement.  You can complete this electronically or by paper at openid.net/intellectual-property.
 
Be sure to specify, in the working groups box, the exact name:

Meeting Schedule

Regular Meetings

  • Pacific zone call: Bi-weekly Thursday Call @ 11pm UTC
  • Atlantic zone call: Weekly Wednesday Call @ 2pm UTC
  • Zoom software is available on Mac, PC, iPhone, and Android Phone.
  • Join Meeting
  • Meeting Minutes

Frequently asked Questions

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.

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.

Not yet, but work is planned to implement tests for FAPI 2.0 Basic during 2021.

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

 Open Banking, UKConsumer Data Rights, Australiayes® QES Scheme
Specifications available athttps://standards.openbanking.org.uk/https://consumerdatastandardsaustralia.github.io/standards/https://yes.com/docs/qes/2.5/index.html
Date2018-01-132020-07-012020-09-24
VersionFAPI 1.0FAPI 1.0FAPI 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 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:

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:

 Security LevelNon-Repudiation
FAPI 1.0 BaselineMediumNone
FAPI 1.0 Advanced
FAPI 2.0 Baseline
HighLimited
FAPI 2.0 AdvancedHighComprehensive

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

 

 FAPI 1.0FAPI 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

Currently 15 UK banks have 31 FAPI certifications of 16 deployments:

Barclays (Barclays OB TIAA)
Cater Allen (CA Open Banking v1.3.0)
Coutts & company (F23)
First Direct (Open Banking Read-Write API version 3.1.3)
Hargreaves Lansdown Savings Limited (Open Banking 3.1 FAPI)
HSBC RBWM (Open Banking Read-Write API version 3.1.3)
HSBC Business (Open Banking Read-Write API version 3.1.3)
ICICI Bank UK Plc (Open Banking v 3.1.2)
Marks and Spencer (Open Banking Read-Write API version 3.1.3)
National Westminster Bank Plc (Open Banking 3.1 FAPI)
Sainsbury’s Bank PLC (Sainsbury’s Bank Digital IAM Platform (version 19.8.8))
The Royal Bank Of Scotland Plc (Open Banking 3.1 FAPI)
TSB Bank PLC (CA API Gateway 9.4)
Ulster Bank Limited   (Open Banking 3.1 FAPI)
Vanquis Bank Ltd (Open Banking 3.1 FAPI)
WSO2 (UK) Limited (Openbanking v1.4.0)

 
AU CDR (Data 61)

https://consumerdatastandardsaustralia.github.io/standards/#future-dated-obligations 

https://consumerdatastandardsaustralia.github.io/standards/#security-profile

Initial AU FAPI outreach workshops confirmed with AU DSB team for April 20th and May 4th

 
Berlin Group  
STET  
Mexico  
Bahrain  
Brazilhttps://openbanking-brasil.github.io/areadesenvolvedor-fase2/#padroes 
yes Scheme yes QES service is based on FAPI 2.0 Baseline

FAPI Liaison Relationships

Financial Data Exchange (FDX) - USA

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.

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.

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.

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.

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.

Updates and Presentations