/TECHNICAL GUIDE

Enabling the UK Open Banking

Specification
A ForgeRock Technical Solution Guide

Table of Contents
Three Key Requirements for Open Banking     2
Supporting the Three Requirements and the UK Open Banking Specifications   3
Consent   3
Authorization   3
OAuth   3
OpenID Connect   5
Financial API Specification   8
Two Stage Request   8
Mutual Authentication TLS   9
Authentication   9
Consent   10
Remote Consent Service   10
Onboarding   10
The Directory   10
Certificates   11
Software Statement Assertions and Dynamic Client Registration   11
Json Web Key   13
Mutual Authentication TLS   13
Access   14
Mutual Authentication TLS   14
FAPI   14
Summary   14
Learn More About ForgeRock Open Banking for Your Organization   14
Glossary   15

Copyright © 2018 ForgeRock, All Rights Reserved. 1

Enabling the UK Open Banking Specification There are three key requirements that apply to
securing any Open Banking ecosystem architecture.

A ForgeRock Technical Solution Guide 1. Consent: Banks need a way to confirm that a user
The business of banking is undergoing a major shift has granted consent to data being shared which in
with users demand for increased account access turn means they need a way to:
and the sharing of account information. To protect »» Allow users to authorize a third party to access
consumers, regulations have been written to mandate their data.
how financial data can be created, accessed, and
»» Authenticate that the third party is who they
shared.
claim to be.
In this paper, we discuss at a technical level 2. Onboarding: Banks need a way to onboard and
how ForgeRock enables the UK Open Banking verify that third parties are to be trusted with
Specification through the ForgeRock Identity personal account data.
Platform™ and the delivery of both the reference bank 3. Access: Third parties need a way to access user
and the new ForgeRock directory sandbox. account data, and banks need a way to protect that data
This paper primarily focuses on Security Profile and and enforce that it is only accessed with our consent.
the Open Banking Directory.

Throughout this document we have provided links to In essence, these requirements are a means of
ForgeRock documentation for further explanation of establishing both consent and trust. All must be met for
the Open Banking functionality being discussed. 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
Three Key Requirements for Open Banking of how the overall UK Open Banking ecosystem works
Open Banking is all about users sharing their banking and the key interactions between all participants.
data through APIs. Of course, the more third-party
access, the higher the risk.

Copyright © 2018 ForgeRock, All Rights Reserved. 2

Within the UK Open Banking ecosystem, ForgeRock The specifications are extremely detailed and we
powers two components with the following: highly recommend them to help you understand how
UK Open Banking works.
»» ForgeRock Model Bank: A fully compliant model
bank that provides a Reference Bank Application,
The intent of this paper however, is to draw out what
used by leading banks and third parties to build
we at ForgeRock believe are the key elements of the
their own applications in accordance with Open
specifications and to explain how they and ForgeRock
Banking standards. (See announcement here.)
address the three requirements discussed earlier.
»» ForgeRock Open Banking Directory: A new, fully
compliant version of the UK Open Banking Directory Again, we primarily focus upon the Security Profile and
underpinning the testing and integration sandbox. the Open Banking Directory in this paper. Consent is
Unlike the Open Banking live directory, ForgeRock the first key requirement we’ll cover, as onboarding is a
Open Banking Directory does not require participants to direct result of how consent is collected and enforced.
be FCA approved, reducing a significant barrier to entry.

Consent
Supporting the Three Requirements and Consent is a complex concept. Requesting, capturing,
the UK Open Banking Specifications and enforcing that the owner of bank account data
has granted permission to the bank to share that data
The UK has published the Open Banking Read/Write
are pivotal mechanisms. These mechanisms rely on
Specifications. The Specifications define the following
authorization and authentication.
important components that are integral for consent,
onboarding, and access:
»» Account and Transaction API: The endpoints, requests Authorization
and responses for account requests.
OAuth
»» Payment Initiation API: The endpoint requests and OAuth 2.0 is the leading security standard for
responses for payment requests. delegated authorization and UK Open Banking has
»» Security Profile: The security standards that underpin determined it is the right solution for Open Banking.
the APIs. OAuth solves the problem of enabling a user to allow a
third party to act on their behalf.
»» Open Banking Directory: The trust framework for
participants in the Open Banking ecosystem.

Copyright © 2018 ForgeRock, All Rights Reserved. 3

OAuth is commonly used for permitting websites to OAuth uses scopes to model the permissions being
share data with one another, such as allowing Twitter requested by the resource server, the access token
to post to Facebook. Instead of sharing usernames and issued is then linked to these scopes.
passwords, an OAuth access token is issued that the
third party can then present to access a user’s data. Scopes are relatively coarse. Typical examples of
scopes could be: profile, picture, post. They are
OAuth defines four key roles: not fine grain and a set of scopes are usually pre-
configured in the authorization server.
»» Resource Owner: the actor who owns the resource
that is being accessed
OAuth is just a framework and Open Banking does not
»» Resource Server: the server that protects the resource define many aspects of how OAuth should be securely
»» Client: the application wanting to access the resource implemented. In addition, the use of OAuth scopes

»» Authorization Server: the server that issues access presents a problem for Open Banking.
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.

Copyright © 2018 ForgeRock, All Rights Reserved. 4

As you can see above, because scopes have to OpenID Connect enables a relying party to defer to
be pre-configured, it is not appropriate to model an identity provider to authenticate users, such as
payments using them. We will address this with logging in with Facebook. The relying party does not
OpenID Connect. have to be concerned with managing usernames and
passwords, instead they trust the identity provider to
OAuth: https://tools.ietf.org/html/rfc6749 do that. The identity provider then returns an ID token
ForgeRock Docs: https://backstage.forgerock.com/ that the relying party can use to assert the user’s
docs/am/6/oauth2-guide/index.html identity.

OpenID Connect Note that as before, the client must be registered with
OpenID Connect (OIDC) is a standard built on top of the authorization server before initiating the flow. We
OAuth for delegated authentication. In OIDC there are will cover this in onboarding later.
three key roles:
Open ID Connect: http://openid.net/specs/openid-
»» Relying Party: the party that is delegating
connect-core-1_0-final.html
authentication to an OpenID provider
ForgeRock Docs: https://backstage.forgerock.com/
»» OpenID Provider: the party responsible for docs/am/6/oidc1-guide/index.html
authentication of the end user
»» End-User: the user themselves

Copyright © 2018 ForgeRock, All Rights Reserved. 5

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.

Copyright © 2018 ForgeRock, All Rights Reserved. 6

Below is what the claims parameter looks like in the UK Open Banking flow:

{
“alg”: “RS256”,
“kid”: “GxlIiwianVqsDuushgjE0OTUxOTk”
}
.
{
“aud”: “https://api.alphanbank.com”,
“iss”: “s6BhdRkqt3”,
“response _ type”: “code id _ token”,
“client _ id”: “s6BhdRkqt3”,
“redirect _ uri”: “https://api.mytpp.com/cb”,
“scope”: “openid payments accounts”,
“state”: “af0ifjsldkj”,
“nonce”: “n-0S6 _ WzA2Mj”,
“max _ age”: 86400,
“claims”:
{
“userinfo”:
{
“openbanking _ intent _ id”: {“value”: “urn:alphabank-intent-58923”,
“essential”: true}
},
“id _ token”:
{
“openbanking _ intent _ id”: {“value”: “urn-alphabank-intent-58923”,
“essential”: true},
“acr”: {“essential”: true,
“values”: [“urn:openbanking:psd2:sca”,
“urn:openbanking:psd2:ca”]}}
}
}
}

The important part of the claims parameter is the openbanking_intent_id. This is how we solve the scope problem.

Copyright © 2018 ForgeRock, All Rights Reserved. 7

We mentioned earlier that OIDC is concerned with ForgeRock Docs: https://backstage.forgerock.com/
delegated authentication, however that is not the docs/am/6/oidc1-guide/index.html#global-oauth-oidc-
problem we are trying to solve with Open Banking. advanced-openid-connect
In the context of Open Banking, we are not relying
on the ID token to authenticate a user. Instead we Financial API Specification
are using the token as a detached signature to the The Financial API Specification (FAPI) is a draft
authorization response as per the FAPI (Financial API) standard for configuring financial API security
specification. This is an elegant solution to our earlier solutions. It defines recommended flows, configuration
problem with scopes and allows us to align with the parameters, and signing and encryption algorithms for
FAPI model for financial API security, which makes OAuth and OIDC implementations to enhance security
extensive use of OIDC. and mitigate known risks and attacks. It also adds
additional security controls around all Open Banking
The ForgeRock Identity Platform offers full support for requests and responses.
OAuth and OIDC, including the request parameter, OOTB.
FAPI Headers: https://openid.net/specs/openid-
FAPI: http://openid.net/wg/fapi/ financial-api-part-1.html
Detached Signature: http://openid.net/specs/openid-
financial-api-part-2-wd-02.html Two Stage Request
Claims Parameter: http://openid.net/specs/openid- Open Banking uses a two stage request mechanism
connect-core-1_0.html#ClaimsParameter where a payment or account request is first staged
before being authorized.

Copyright © 2018 ForgeRock, All Rights Reserved. 8

The third party sends a payment or account intent that they are who they claim to be. The UK Open Banking
represents the request that the user will be asked to consent specification does not state how this is to be achieved.
to in the following authorization step. The bank can then PSD2 however, expects Strong Customer Authentication.
present this information to the user at the time of consent Although we have turned this off in our reference
so they clearly understand what it is they are agreeing to. environment to simplify the developer experience, in
reality you will require a robust and reliable approach for
Mutual Authentication TLS authenticating customers using at least two of the three
The OAuth endpoint used to issue access tokens to the third elements of knowledge: possession and inherence.
party is protected by Mutual Authentication TLS (MATLS).
Third parties must use the transport certificate issued to Intelligent Authentication in the ForgeRock Identity Platform
them by the directory in order to exchange an authorization satisfies this requirement and enables you to go beyond it
code for an access token. The bank will also ensure the TLS and take into account a range of contextual, behavioural,
certificate being used matches that of the OAuth client. and risk based factors during the authentication process.
ForgeRock Intelligent Authentication Flow

Authentication ForgeRock Docs: https://backstage.forgerock.com/docs/

When the bank receives an OAuth/OIDC request to authorize am/6/authentication-guide/#sec-configure-authentication-trees
a payment, they first need to identify the user and verify

Copyright © 2018 ForgeRock, All Rights Reserved. 9

Consent the third parties who want to access account data.
This is where the directory comes into play.
Finally the user must be asked to consent. The bank
needs to be clear about what the user is consenting to
The Directory
and offer them the option to approve or deny consent.
The Open Banking Directory serves as the central
This information needs to be clear and concise.
platform for verifying the banks and third parties who
are approved to partake in the UK Open Banking
Remote Consent Service
ecosystem. Registration on the live version of the Open
The ForgeRock Identity Platform OOTB offers a
Banking directory is contingent on being approved by
standard OAuth consent screen. Being actively
the Financial Conduct Authority (FCA). However, the
engaged with banks to deliver Open Banking solutions,
new directory sandbox that ForgeRock provides has
ForgeRock realised this basic screen would not be
no such restrictions and is a fully compliant solution.
sufficient. As a result, we introduced the concept of
a Remote Consent Service (RCS) into the ForgeRock
The Open Banking Directory fulfills several key
Identity Platform. The RCS enables the platform to
functions for the Open Banking ecosystem, such as:
defer to another service to present a consent request
and collect the result, enabling a richer consent »» Allowing third parties and banks to register their details
interface that, for example, can allow a customer to and OAuth parameters, such as redirect_url’s and well
choose which bank account to use for a payment. known endpoints
»» Issuing signing, encryption, and transport keys for use
Upon collecting consent, the RCS returns the result by third parties when onboarding with banks, making
to the ForgeRock Identity Platform, which issues an authorization requests, and accessing data
authorization code as per the OAuth flow.
»» Issuing Software Statement Assertions (SSAs), the
Documentation: https://backstage.forgerock.com/docs/ items of proof that third parties will present to banks to
am/6/oauth2-guide/#oauth2-implement-remote-consent onboard as verified participants
»» Hosting the JSON Web Key (JWK) endpoints used to
Onboarding verify JSON Web Signatures (JWS)
Now that we have a mechanism for collecting consent, »» Downloading of keys in several formats: JWK, PEM
what we need is a way to securely onboard and verify or .key

Copyright © 2018 ForgeRock, All Rights Reserved. 10

Certificates
Three different types of certificates are issued by the directory:

1. Signing: Signing certificates are used to create JWSs to sign JSON Web Token (JWT) payloads during both the onboarding
and authorization processes.
2. 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.

JOSEHeader: JSON Object Signing and Encryption Header

json: The Content of the JWT to sign and encrypt
privateKey: The private key

payload = base64Encode ( JOSEHeader ) + “.” +base64Encode(json)

signedAndEncodedPayload = base64Encode (encrypt(privateKey, payload))

JSW = payload + “.” + signedAndEncodedPayload

3. 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.

Copyright © 2018 ForgeRock, All Rights Reserved. 11

This is what an SSA looks like when decoded:

JWT Header
{
“kid”: “e0f8da35-05c4-42a5-96ee-bf48a4924fa2”,
“alg”: “RS256”
}
JWT Claims
{
“org _ jwks _ endpoint”: “TODO”,
“software _ mode”: “TEST”,
“software _ redirect _ uris”: [
“http://example.com/redirect”
],
“org _ status”: “Active”,
“software _ client _ id”: “5b11771fdecdcd0648d063e3”,
“iss”: “ForgeRock”,
“software _ tos _ uri”: “http://example.com/terms.html”,
“software _ client _ description”: “Third Party Description”,
“software _ jwks _ endpoint”: “https://service.directory.integ-ob.
forgerock.financial/directory-services/api/software-statement/5b11771fdecdc
d0648d063e3/application/jwk _ uri”,
“software _ policy _ uri”: “http://example.com/policy.html”,
“software _ id”: “5b11771fdecdcd0648d063e3”,
“org _ contacts”: [],
“ob _ registry _ tos”: “https://directory.integ-ob.forgerock.financial/
tos/”,
“org _ id”: “5b117707decdcd0648d063e2”,
“software _ logo _ uri”: “http://example.com/logo.jpg”,
“software _ jwks _ revoked _ endpoint”: “TODO”,
“software _ roles”: [
“AISP”,
“PISP”
],
“exp”: 1528476229,
“org _ name”: “[email protected]”,
“org _ jwks _ revoked _ endpoint”: “TODO”,
“iat”: 1527871429,
“jti”: “24a4f5f6-e85d-4654-b288-e3eaa132587f”
}

Copyright © 2018 ForgeRock, All Rights Reserved. 12

Example of a Decoded SSA:

Creating an SSA Using ForgeRock Open Banking Directory for sharing multiple keys is called jwk_uri. A good
Creating an SSA is a necessary step for interacting example of this format is the directory jwk_uri. Like any
with the Open Banking ecosystem. If you would like to application, the directory also publishes its keys as a
create one yourself, you can use the new ForgeRock jwk_uri: https://service.directory.ob.forgerock.financial/
Open Banking Directory to do exactly that: https:// directory-services/api/directory/keys/jwk_uri
directory.ob.forgerock.financial/
Publishing your public keys in a jwk_uri format is
Dynamic Client Registration: required as a third party would need to verify JWTs
https://tools.ietf.org/html/rfc7591 you have signed or use your public keys to encrypt
Registering a TPP: JWTs that can only be read by you. At this time the
https://backstage.forgerock.com/knowledge/ directory manages this on behalf of TPPs.
openbanking/article/a39093356
ForgeRock Docs: Mutual Authentication TLS
https://backstage.forgerock.com/docs/am/6/oauth2- The banks endpoints are protected by MATLS. This
guide/#register-oauth2-client-dynamic
means that if you need to use an API that requires a
certain level of permissions, you will need to make sure
Usually, in order to commence an OAuth or OIDC
you have setup your transport certificate accordingly.
flow, the third party must have a set of credentials.
MATLS is the same mechanism we have chosen to
Typically with OAuth clients, a client ID and a secret
implement for protecting our directory REST API and
is issued to the third party. However, this is one of
JWKMS (JWK Management Service) REST API.
several authentication mechanisms that are available
in the OIDC specification. In our reference bank
Further security checks would be done by the ASPSP
implementation we have chosen the private_key_jwt
when required, using your transport certificate. For
authentication method.
example, when you register your application using an
SSA, the RS would verify that the transport certificate
With private_key_jwt, rather then use an explicit client
matches the SSA claims.
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
ForgeRock Open Banking Directory: The
link your JWK URI with the new OIDC client. When directory is a key component of the Open
future OIDC requests are received, the authorization Banking ecosystem, however the live directory
server verifies the signature of the JWT matches and requires that the third party registers and
the “subject” claim in your request. works through approval from the Financial
Conduct Authority (FCA), which can take a
Json Web Key number of weeks and presents a significant
Json Web Key (JWK) is the format used in OIDC barrier to entry for third parties who want to
to publish your public keys to a third party. When develop Open Banking services.
publishing your keys as a JWK, the format used

Copyright © 2018 ForgeRock, All Rights Reserved. 13

ForgeRock Open Banking Directory was developed to »» Stateless: If a stateless access token is being used,
solve this problem. It is a fully compliant directory with then the API gateway would make use of the JWK_
the same functionality as the live directory, however, URI to verify the signature of the token.
it is immediately accessible to anyone who wants to
access it. In addition we have augmented the directory
Mutual Authentication TLS
with a number of useful services to aid developers in
Mutual Authentication TLS (MATLS) is again used
testing their integrations, such as the JWKms.
when a third party accesses the API. The API gateway
needs to also check that the details of the third party
JWKms
included in the transport certificate used to access the
JWKms: The JWKms is a service adjacent to the
API endpoints matches the details of the third party in
directory. Using the keys generated for you by the
the certificate used to sign the access token.
directory, it allows you to manipulate JWTs on your
behalf and provides the following functionality:
FAPI
»» Test your MATLS setup FAPI recommendations are enforced when making
»» Provide your keys in a JWK_URI format requests to the API. FAPI defines a number of
additional headers that should be set and help to
»» Sign claims as a JWS provide a consistent identifier across the whole
»» Sign and then encrypt claims as JWE (JWS) interaction, whilst capturing additional data such as
the IP address the customer is logging in from and
»» Decrypt a JWE
the last time they logged in, which is important from a
»» Validate a JWT security and audit perspective.
»» Rotate keys
»» Reset keys
Summary
In addition to the above, the JWKms also implements a In this document we have touched upon the key
key rotation mechanism which is required for any OIDC ForgeRock security features that enable consent
setup that makes use of asymmetric keys. and trust in the UK Open Banking specification.
The ForgeRock Identity Platform, which includes
All of the above JWKms functionality has been the ForgeRock Model Bank and ForgeRock Open
exposed through APIs and, as a result of this Banking Directory, allow third parties and banks
functionality, we can offer a developers a completely to test and integrate within the Open Banking
code free experience as they learn their way around ecosystem. With a high level understanding of how
the Open Banking APIs. the ecosystem works, you can create a third party,
onboard with the directory, and test the open banking
flows in the ForgeRock directory sandbox.

Access
Now we have a secure, standards-based mechanism Learn More About ForgeRock
for authorizing consent and onboarding third parties
to a very high level of assurance. The final piece of the
Open Banking for Your Organization
puzzle is providing a means by which the third parties ForgeRock is the leader in digital identity and trust —
can actually access payment and account APIs. designed to support Open Banking, secure the enterprise,
Typically, this is provided by an API Gateway which will build customer trust and loyalty, and grow business
validate the access token issued in the authorization opportunities and revenue today and well into the future.
request flow.
Contact us to learn more about how ForgeRock can
Gateways have two ways to validate access tokens help your organization support Open Banking.
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.

Copyright © 2018 ForgeRock, All Rights Reserved. 14

Glossary /ABOUT FORGEROCK
AISP - Account Information Service Provider
ASPSP - Account Servicing Payment Service Provider
API - Application Programming Interface
ForgeRock® is the Digital Identity
FAPI - Financial API Working Group
Management company transforming the
FCA - Financial Conduct Authority
way organizations interact securely with
JWE - JSON Web Encryption
customers, employees, devices, and things.
JWK - JSON Web Key
Organizations adopt the ForgeRock Identity
JWKMS - JWK Management Service
Platform™ as their digital identity system of
JWS - JSON Web Signature
record to monetize customer relationships,
JWT - JSON Web Token
address stringent regulations for privacy and
MATLS - Mutual Authentication TLS
consent (GDPR, HIPAA, FCC privacy, etc.),
OB - Open Banking
and leverage the internet of things.
OIDC - OpenID Connect
ForgeRock serves hundreds of brands,
PISP - Payment Initiation Service Provider
including Morningstar, Vodafone, GEICO,
PSD2 - Payment Services Directive 2
Toyota, and Pearson, as well as
TLS - Transport Layer Security
governments like Norway, Canada, and
TPP - Third Party Provider
Belgium, securing billions of identities
REST - Representational State Transfer
worldwide. ForgeRock has offices across
RS - Resource Server
Europe, the USA, and Asia.
SSA - Software Statement Assertion

www.forgerock.com

Copyright © 2018 ForgeRock, All Rights Reserved. 15