OpenBanking UK knowledge base
The business of banking is undergoing a major shift with users demand for increased account access and the sharing of account information. To protect consumers, regulations have been written to mandate how financial data can be created, accessed, and shared.
In this paper, we discuss at a technical level how bankIO enables the UK Open Banking Specification through the bankIO Link.
Three Key Requirements for Open Banking
Open Banking is all about users sharing their banking data through APIs. Of course, the more third-party access, the higher the risk.
There are three key requirements that apply to securing any Open Banking ecosystem architecture.
1. Consent: Banks need a way to confirm that a user has granted consent to data being shared which in turn means they need a way to:
a. Allow users to authorize a third party to access their data.
b. Authenticate that the third party is who they claim to be.
- Onboarding: Banks need a way to onboard and verify that third parties are to be trusted with personal account data.
- Access: Third parties need a way to access user account data, and banks need a way to protect that data and enforce that it is only accessed with our consent.
In essence, these requirements are a means of establishing both consent and trust. All must be met for any Open Banking (or open API) ecosystem to succeed. Understanding the Open Banking ecosystem can be complex. The two diagrams below give a high level view of how the overall UK Open Banking ecosystem works and the key interactions between all participants.
Supporting the Three Requirements and the UK Open Banking Specifications
The UK has published the Open Banking Read/Write Specifications. The Specifications define the following important components that are integral for consent, onboarding, and access:
- Account and Transaction API: The endpoints, requests and responses for account requests.
- Payment Initiation API: The endpoint requests and responses for payment requests.
- Security Profile: The security standards that underpin the APIs.
- Open Banking Directory: The trust framework for participants in the Open Banking ecosystem.
The specifications are extremely detailed and we highly recommend them to help you understand how UK Open Banking works.
The intent of this paper however, is to draw out what we at bankIO believe are the key elements of the specifications and to explain how they and bankIO address the three requirements discussed earlier.
Again, we primarily focus upon the Security Profile and the Open Banking Directory in this paper. Consent is the first key requirement we’ll cover, as onboarding is a direct result of how consent is collected and enforced.
Consent
Consent is a complex concept. Requesting, capturing, and enforcing that the owner of bank account data has granted permission to the bank to share that data are pivotal mechanisms. These mechanisms rely on authorization and authentication.
Authorization
OAuth
OAuth 2.0 is the leading security standard for delegated authorization and UK Open Banking has determined it is the right solution for Open Banking. OAuth solves the problem of enabling a user to allow a third party to act on their behalf.
OAuth is commonly used for permitting websites to share data with one another, such as allowing Twitter to post to Facebook. Instead of sharing usernames and passwords, an OAuth access token is issued that the third party can then present to access a user’s data.
OAuth defines four key roles:
- Resource Owner: the actor who owns the resource that is being accessed
- Resource Server: the server that protects the resource
- Client: the application wanting to access the resource
- Authorization Server: the server that issues access tokens to the client
Note that the client must be registered with the authorization server before initiating the flow, we will cover this later in onboarding.
OAuth uses scopes to model the permissions being requested by the resource server, the access token issued is then linked to these scopes.
Scopes are relatively coarse. Typical examples of scopes could be: profile, picture, post. They are not fine grain and a set of scopes are usually pre-configured in the authorization server.
OAuth is just a framework and Open Banking does not define many aspects of how OAuth should be securely implemented. In addition, the use of OAuth scopes presents a problem for Open Banking.
Because scopes have to be pre-configured, it is not appropriate to model payments using them. We will address this with OpenID Connect.
OpenID Connect
OpenID Connect (OIDC) is a standard built on top of OAuth for delegated authentication. In OIDC there are three key roles:
- Relying Party: the party that is delegating authentication to an OpenID provider
- OpenID Provider: the party responsible for authentication of the end user
- End-User: the user themselves
OpenID Connect enables a relying party to defer to an identity provider to authenticate users, such as logging in with Facebook. The relying party does not have to be concerned with managing usernames and passwords, instead they trust the identity provider to do that. The identity provider then returns an ID token that the relying party can use to assert the user’s identity.
Note that as before, the client must be registered with the authorization server before initiating the flow. We will cover this in onboarding later.
Open ID Connect: http://openid.net/specs/openid-connect-core-1_0-final.html
The OpenID Connect (OIDC) specification defines an element called the claims request parameter. The parameter can be used to request that specific claims are returned in the ID token. Crucially, the OIDC specification also allows for the request to specify the properties of the claims being requested. This allows us to solve the scope problem discussed above because we can now use the OIDC claims request parameter to request authorization for specific properties. The request parameter also allows us to sign the request, which ensures that we can detect if it has been tampered with.
Below is what the claims parameter looks like in the UK Open Banking flow:
The important part of the claims parameter is the openbanking_intent_id.
We mentioned earlier that OIDC is concerned with delegated authentication, however that is not the problem we are trying to solve with Open Banking. In the context of Open Banking, we are not relying on the ID token to authenticate a user. Instead we are using the token as a detached signature to the authorization response as per the FAPI (Financial API) specification. This is an elegant solution to our earlier problem with scopes and allows us to align with the FAPI model for financial API security, which makes extensive use of OIDC.
FAPI: http://openid.net/wg/fapi/
Detached Signature: http://openid.net/specs/openid-financial-api-part-2-wd-02.html
Claims Parameter: http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
Financial API Specification
The Financial API Specification (FAPI) is a draft standard for configuring financial API security solutions. It defines recommended flows, configuration parameters, and signing and encryption algorithms for OAuth and OIDC implementations to enhance security and mitigate known risks and attacks. It also adds additional security controls around all Open Banking requests and responses.
FAPI Headers: https://openid.net/specs/openid-financial-api-part-1.html
Two Stage Request
Open Banking uses a two stage request mechanism where a payment or account request is first staged before being authorized.
The third party sends a payment or account intent that represents the request that the user will be asked to consent to in the following authorization step. The bank can then present this information to the user at the time of consent so they clearly understand what it is they are agreeing to.
Mutual Authentication TLS
The OAuth endpoint used to issue access tokens to the third party is protected by Mutual Authentication TLS (MATLS). Third parties must use the transport certificate issued to them by the directory in order to exchange an authorization code for an access token. The bank will also ensure the TLS certificate being used matches that of the OAuth client.
Authentication
When the bank receives an OAuth/OIDC request to authorize a payment, they first need to identify the user and verify they are who they claim to be. The UK Open Banking specification does not state how this is to be achieved. PSD2 however, expects Strong Customer Authentication. Although we have turned this off in our reference environment to simplify the developer experience, in reality you will require a robust and reliable approach for authenticating customers using at least two of the three elements of knowledge: possession and inherence.
Intelligent Authentication in the bankIO Link satisfies this requirement and enables you to go beyond it and take into account a range of contextual, behavioural, and risk based factors during the authentication process.
Consent
Finally the user must be asked to consent. The bank needs to be clear about what the user is consenting to and offer them the option to approve or deny consent. This information needs to be clear and concise.
Remote Consent Service
The bankIO Link OOTB offers a standard OAuth consent screen. Being actively engaged with banks to deliver Open Banking solutions, bankIO realised this basic screen would not be sufficient. As a result, we introduced the concept of a Remote Consent Service (RCS) into the bankIO Link. The RCS enables the platform to defer to another service to present a consent request and collect the result, enabling a richer consent interface that, for example, can allow a customer to choose which bank account to use for a payment.
Upon collecting consent, the RCS returns the result to the bankIO Link, which issues an authorization code as per the OAuth flow.
Onboarding
Now that we have a mechanism for collecting consent, what we need is a way to securely onboard and verify the third parties who want to access account data. This is where the directory comes into play.
The Directory
The Open Banking Directory serves as the central platform for verifying the banks and third parties who are approved to partake in the UK Open Banking ecosystem. Registration on the live version of the Open Banking directory is contingent on being approved by the Financial Conduct Authority (FCA). However, the new directory sandbox that bankIO provides has no such restrictions and is a fully compliant solution.
The Open Banking Directory fulfills several key functions for the Open Banking ecosystem, such as:
- Allowing third parties and banks to register their details and OAuth parameters, such as redirect_url’s and well known endpoints
- Issuing signing, encryption, and transport keys for use by third parties when onboarding with banks, making authorization requests, and accessing data
- Issuing Software Statement Assertions (SSAs), the items of proof that third parties will present to banks to onboard as verified participants
- Hosting the JSON Web Key (JWK) endpoints used to verify JSON Web Signatures (JWS)
- Downloading of keys in several formats: JWK, PEM or .key
Certificates
Three different types of certificates are issued by the directory:
- Signing: Signing certificates are used to create JWSs to sign JSON Web Token (JWT) payloads during both the onboarding and authorization processes.
- Encryption: Encryption certificates are used to encrypt the JWT payloads and for ID token encryption. For example, if you want to receive an encrypted ID token, the bank will use your encryption certificate to encrypt the JWS.
JWS Creation Process
- Transport: Mutual TLS is used to encrypt requests and responses between third parties and banks using transport certificates issued by the directory.
Software Statement Assertions and Dynamic Client Registration
Software Statement Assertions (SSAs) are part of the OAuth 2.0 Dynamic Client Registration Protocol. Dynamic Client Registration is a mechanism that allows OAuth clients to be registered and created automatically upon receipt of an item of proof (SSA). This enables third parties to rapidly onboard with banks and receive a client ID they can use for later on.
This is what an SSA looks like when decoded:
With private_key_jwt, rather then use an explicit client ID and a secret, the key with which you sign your JWT actually serves as your credential. Upon successful onboarding with an SSA, the authorization server will link your JWK URI with the new OIDC client. When future OIDC requests are received, the authorization server verifies the signature of the JWT matches and the “subject” claim in your request.
Json Web Key
Json Web Key (JWK) is the format used in OIDC to publish your public keys to a third party. When publishing your keys as a JWK, the format used for sharing multiple keys is called jwk_uri. A good example of this format is the directory jwk_uri. Like any application, the directory also publishes its keys as a jwk_uri: https://service.directory.ob.bankIO.financial/directory-services/api/directory/keys/jwk\_uri
Publishing your public keys in a jwk_uri format is required as a third party would need to verify JWTs you have signed or use your public keys to encrypt JWTs that can only be read by you. At this time the directory manages this on behalf of TPPs.
Mutual Authentication TLS
The banks endpoints are protected by MATLS. This means that if you need to use an API that requires a certain level of permissions, you will need to make sure you have setup your transport certificate accordingly.
MATLS is the same mechanism we have chosen to implement for protecting our directory REST API and JWKMS (JWK Management Service) REST API.
Further security checks would be done by the ASPSP when required, using your transport certificate. For example, when you register your application using an SSA, the RS would verify that the transport certificate matches the SSA claims.
Access
Now we have a secure, standards-based mechanism for authorizing consent and onboarding third parties to a very high level of assurance. The final piece of the puzzle is providing a means by which the third parties can actually access payment and account APIs. Typically, this is provided by an API Gateway which will validate the access token issued in the authorization request flow.
Gateways have two ways to validate access tokens depending on the token architecture. The specification is not prescriptive here:
- Stateful: If stateful access tokens are being used then the API gateway will need to invoke an endpoint on the authorization server to validate the token.
- Stateless: If a stateless access token is being used, then the API gateway would make use of the JWK_URI to verify the signature of the token.
Mutual Authentication TLS
Mutual Authentication TLS (MATLS) is again used when a third party accesses the API. The API gateway needs to also check that the details of the third party included in the transport certificate used to access the API endpoints matches the details of the third party in the certificate used to sign the access token.
FAPI
FAPI recommendations are enforced when making requests to the API. FAPI defines a number of additional headers that should be set and help to provide a consistent identifier across the whole interaction, whilst capturing additional data such as the IP address the customer is logging in from and the last time they logged in, which is important from a security and audit perspective.
Summary
In this document we have touched upon the key bankIO security features that enable consent and trust in the UK Open Banking specification. The bankIO Link, which includes the bankIO Model Bank and bankIO Open Banking Directory, allow third parties and banks to test and integrate within the Open Banking ecosystem. With a high level understanding of how the ecosystem works, you can create a third party, onboard with the directory, and test the open banking flows in the bankIO directory sandbox.
Glossary
AISP - Account Information Service Provider
ASPSP - Account Servicing Payment Service Providers, e.g. banks
API - Application Programming Interface
FAPI - Financial API Working Group
FCA - Financial Conduct Authority
JWE - JSON Web Encryption
JWK - JSON Web Key
JWKMS - JWK Management Service
JWS - JSON Web Signature
JWT - JSON Web Token
MATLS - Mutual Authentication TLS
OB - Open Banking
OIDC - OpenID Connect
PISP - Payment Initiation Service Provider
PSD2 - Payment Services Directive 2
REST - Representational State Transfer
RS - Resource Server
SSA - Software Statement Assertion
TLS - Transport Layer Security
TPP - Third Party Provider