Getting Started – Open Banking API Security Profile

The Open Banking Standard 

Getting started with FAPI

As FAPI builds upon a number of existing specifications it is recommended that implementers adopt a certified product.  OpenID maintain a list of providers who have passed certification and can be found here: https://openid.net/certification/

It is important to note that FAPI introduces new security features over and above OAuth which require the use of certificates for both transport layer and message signing.

The Open Banking Directory provides PSD2 (and UK Payment Services Regulations 2017) compliant certificates for both purposes.

Additional considerations

• JWT Secured Authorization Response Mode (JARM) was not adopted in the original UK security profile, nor mandated in FAPI 1 Advanced and is out of scope for UK implementations.
• Client-Initiated Backchannel Authentication (CIBA) allows for decoupling the authorisation code flow to allow PSUs to authenticate consent out-of-band. Implementing CIBA is currently optional for ASPSPs in the UK and TPPs are advised to check ASPSP Transparency calendars for information on live implementations.

Implementation advice

The UK Open Banking Ecosystem requires an intent ID to be pre-generated using the POST /{API-TYPE}-Consents API endpoint.  This endpoint uses the client credentials grant.

Additionally, ecosystem specific ACR values are used, these are:

• urn:openbanking:psd2:sca: To indicate that secure customer authentication must be carried out as mandated by the FCA’s SCA-RTS
• urn:openbanking:psd2:ca: To request that the customer is authenticated without using SCA (if permitted)

FAPI 1 Advanced allows requests without an acr value to be specified however we encourage all TPPs to continue sending the acr claim in requests.  An ASPSP receiving a request without this claim should determine the appropriate level of auth required of the user and the activity being requested  

Clock Skew 

The FAPI 1 spec is silent on the approach participants should take to clock skew. Participants should determine what level of clock skew they are willing to accept and publish details on their developer portal.   

The following has been proposed for inclusion in FAPI 2: 

• Accept requests with up to 10 seconds difference
• May accept requests with up to 60 seconds difference
• Should reject requests with over 60 seconds difference 

We encourage participants use this as a starting point to determine appropriate values for their organisations. 

TPPs

Open Banking maintains a model bank implementation, TPPs are advised to test their FAPI implementation against the model bank before connecting to ASPSPs in the ecosystem.

Information on integrating with the model bank can be found here

TPPs should refer to ASPSPs /.well-known file and developer portals for ASPSP specific implementation information

ASPSPs

OpenID provide a FAPI conformance tool.  This is open source, can be downloaded freely and run against an implementation to validate compliance with the FAPI 1 specification is being met.

Certification

ASPSPs can certify their FAPI implementations with OIDF to demonstrate conformance with the specification. Please note this service is provided by OIDF and a fee is required for certification.

Migration from FAPI 1 ID2 to FAPI 1 Advanced Final 

FAPI 1 Advanced has a few key differences from Implementers Draft 2, and TPP’s should pay close attention to both the nbf claim (mandatory in the final spec) and the exp claim to ensure alignment of dates/times. 

There is no single migration approach which will address all FAPI 1 ID2 implementations and participants should identify what options are available to them based on their current infrastructure/implementation. The following guidance should be used as a baseline for understanding key steps in the migration and adapted for a participant’s specific implementation where possible: 

Migration to FAPI 1 Advanced should be done in two stages, in order to ensure minimal disruption. Due to a lack of versioning in key URLS and complexities in merging new infrastructure with the migration it is recommended that if an ASPSP dual-runs v3.1.X and v4.0 that FAPI 1 Advanced is introduced on the v3 implementation at the same time as v4. 

Stage 1: 

ASPSPs validate their current infrastructure supports FAPI 1 Advanced’s core requirements and publish a switch over date on their developer portal. After this date requests not meeting the FAPI 1 Advanced spec will be rejected. 

TPPs include nbf claims in requests to 3.1.X APIs.  Clients must ensure the lifetime of their request objects is under 60 minutes. 

ASPSPs should validate the nbf claim if present.

Stage 2 (date of switch over): 

ASPSPs should enable DNSSEC, HTTP STS and remove any keys with duplicate kids (following usual procedures for key rotation). 

ASPSP must reject any requests without a valid nbf claim after the switch over date. 

ASPSPs must accept requests without an acr claim, determining the appropriate level of authentication to use based on the activity being requested.

Security Profiles Previous

Guidelines Next