1. Version Control

2. Introduction

The purpose of this How To Guide is for participants who want to onboard their software with the Open Banking Directory Sandbox. It is aimed at Primary Technical Contacts (PTC) and Secondary Technical Contacts (STC).

This guide describes the technical steps for creating and maintaining Software Statements, access tokens and ASPSP authorisation servers on the Directory Sandbox environment of the Open Banking Directory.

This guide is structured into these sections:

• Log in to the Directory Front End Interface (DFI)
• Accessing Participant records
• Creating Software Statements
• Creating a Certificate Signing Request (CSR) for OB ETSI like and OB non-ETSI certificates 
• Managing Transport and Signing Test Certificates including QWACs and QSeals (eIDAS certificates)
• Managing signing and encryption keys
• Creating Software Statement Assertions (SSA)
• Creating ASPSPs’ lists of Authorisation Servers 
• Acquiring Access Tokens to consume API services
• Acquiring the list of Authorisation Servers
• Creating Software Statement Assertions (SSA) via API
• Using DFI features via API

The guide is intended for Primary Technical Contacts (PTC) and Secondary Technical Contacts (STC) in the following domains:

• ASPSPs
• TPPs
• TSPs
• Crown Dependencies 

3. Getting Started Checklist

Before you begin, it is highly recommended you go through this section first to ensure that you have all the relevant details;

1. You have been added to the Open Banking Directory as a Primary Technical Contact or Secondary Technical Contact.
2. You have installed node.js (latest build): https://nodejs.org/en/download/
3. You have the ability to run git on your computer. Git is available for all major operating systems. Git is available from https://git-scm.com/downloads and as a package for all major Open Source operating systems.
4. You have read the following:

4.  Log in to the Directory Front End Interface (DFI)

This section describes how to log in to the Directory Front End Interface using two-factor authentication.

Before you start you must check the following:

• You have been enrolled as a participant for one or more authorisation domains (PSD2 or Confirmation of Payee) in the Open Banking Directory. Please refer to the guide to complete enrolment - How To Guide: Enrolling Onto Open Banking.
• You have received a link to the DFI web application. The link should have been sent to the Primary Technical Contact’s (PTC) email address supplied to Open Banking as part of the onboarding process.
• Use either Chrome or Firefox web browsers to login to DFI for the best experience.
• For two-factor authentication, you will need a mobile phone (iOS or Android) with the Ping ID app installed. You can download the app from the Apple App Store or Google Play Store.

Steps to log in to the DFI

Step 1: Click on the link sent by Open Banking. (Note: this access is for the Primary Technical Contact specified in the submitted enrolment form)

Step 2: Go through the “Setting up your password” screens as described in the document - How To Guide: Enrolling Onto Open Banking.

Step 3: Follow the instructions on the screen to log in to the DFI web application.

5.  Access your Records

Once you've logged in to the DFI, you will see a search tool on the left hand side of your screen and the list of your organisations on the right hand side. Where participants feature in one or more domains, they will be listed twice with a label denoting which authorisation domain each entry belongs to (i.e. Pay.UK or PSD2).

Steps to identify your participant

Step 1: Once you log in to the DFI you will see a list of ASPSP/TPP. 

Step 2: Click on the "Organisation Details" button for the participant you are interested in. This will open up the Organisation details page for your organisation. 

The tabs at the top of page can be used to navigate each profile:

1. Organisation Details - this page displays the business information for the selected organisation.
2. Software Statements - this page displays software statements along with supporting functionality to create, activate and deactivate them. Participants can also create obtransport and obsigning certificates on this page.
3. Certificates - this page displays organisation level certificates only and provides supporting functionality to create, upload and revoke them. This tab is only visible in the PSD2 domain. To view software statement level certificates, go to the Software Statements tab.
4. Authorisation Servers - this page displays the list of established authorisation servers for an ASPSP organisation. Participants can also create new authorisaton servers on this page.

Searching for a Participant

If the organisation you want to view is not listed, you can search for it by entering the organisation name or ID using the search tool on the left side of your screen.

Select the authorisation domain (Pay.UK or PSD2) to refine your search criterion. 

From the search results click on the row for your organisation. This will open up the Organisation details page for your organisation.

Note: PTC and STC details can only be seen by PTCs or STCs of the same organisation.  PTCs and STCs will only see listed the organisation they have access to in the respective domains.

6.  Create Software Statements

In order for TPPs and ASPSPs to communicate with each other they need to create Software Statements that uniquely identify their application. This section explains the steps to create Software Statements.

Before you start

• Click on the "Software Statements" button for the organisation on the main Directory page. Alternatively, select the Software Statements tab at the top of your screen if you already have the organisation details displayed on your screen.

Steps to Create Software Statements

Step 1: Select the Software Statement tab.

Step 2: Click the Add new Software Statement button. 

Step 3: Complete the Add new Software Statement form shown below:

Step 4: Verify that the new Software Statement has been created. It should appear on the summary page for the ASPSP or TPP.

7.  Create a Certificate Signing Request (CSR) for Open Banking non-ETSI certificates

ASPSPs and TPPs need to create digital certificates to encrypt messages over the public network, and sign requests. In order to create certificates, ASPSPs and TPPs need to create certificate signing requests. This section explains the steps to create a certificate signing request for Open Banking non-ETSI certificates, which are often referred to as OB Legacy certs.

Before you start

• Check you have created a Software Statement for your Organisation.
• Check you have the Software Statement Id as shown on the software statements screen to hand
• If you are using openssl, ensure you are running  v1.1.1 or above. 

• You know the Organisation ID of your organisation as shown on the Business Information screen.

Steps to create CSR

Using your own key generation and management policies, a public private key pair must be created. The following is an example using OpenSSL  to manually create a CSR. This is for illustration purposes only. 

Unix and Mac Users

• Open the text terminal window (command line) on your computer and run the following command:
  openssl req -new -newkey rsa:2048  -sha256 -nodes -out <software_statement_id>.csr -keyout <software_statement_id>.key -subj "/C=GB/O=OpenBanking/OU=<organisation_id>/CN=<software_statement_id>"

  Note: Keep O set to OpenBanking

The DN should be "/C=GB/O=OpenBanking/OU=<organisation_id>/CN=<software_statement_id>". There should not be any other fields in the DN.

Windows Users

• Install a bash shell emulater.
• goto the directory you want to create the CSR.

• Open the text terminal window (command line) on your computer and run the following command:
  openssl req -new -newkey rsa:2048  -sha256 -nodes -out <software_statement_id>.csr -keyout <software_statement_id>.key -subj "//C=GB\O=OpenBanking\OU=<organisation_id>\CN=<software_statement_id>"

  Note: Keep O set to OpenBanking

The DN should be windows escaped "//C=GB\O=OpenBanking\OU=<organisation_id>\CN=<software_statement_id>".

All Users

You will need to create two private keys and two CSRs - one for the transport certificate and the other for signing certificate.

Assign the roles in your configuration file, the Directory will prepopulate the remaining fields. The table below lists which should be set in your configuration file. If additional fields are included in the file,  (eg. State), the CSR will be rejected on upload.

Auto-generated CSR

As an alternative to manually creating a CSR file, you also have the option to use the Directory to auto-generate a CSR on your organization's behalf. To do so, please follow the steps below:

1. Navigate to the Add Certificate section within the DFI and select the certificate and file types to be created.

2. Select the roles granted to your organization, to be included in your certificate.

   Including the SAN 

   Participants have the option of including the subject alternative name (SAN) in the CSR. Please note the following configuration rules applied to this attribute below:

• Once a SAN is included as part of a submitted csr, the details are stored against the participant profile with the CA service provider. Subsequent requests to mint a csr will include the SAN by default.
• If a CSR with a different SAN is submitted, it replaces the previous one stored with the CA.
• A config change is required to disable default inclusion of the SAN. If the participant requires this, a service desk request can be submitted.

3. Review the properties which will be auto-populated to the CSR by the Directory.

4. Generate and save the CSR file to later upload and obtain your certificate.

8.  Generate and manage Transport and Signing Certificates for Open Banking non-ETSI certificates - ASPSPs only

Participants operating within the PSD2 domain may need to create digital certificates to support encryption and authentication within the ecosystem and Open Banking's network. This section explains the steps to create digital Open Banking non-ETSI certificates. TPPs operating in the PSD2 domain should only create Open Banking ETSI certifcates (see next section below):

Before you start

You need to have,

1. a transport certificate CSR
2. a signing certification CSR, and
3. both the CSRs are generated from two different private keys

Steps to Create Certificates

Step 1: On the Organisation details page click on the > symbol to the right of the newly created Software Statement.

Step 2: Scroll down to the Add certificates section and upload the CSR to generate the Transport certificate. On upload the generated transport certificate appears in the Certificates section.

Step 3: Upload the file for the OB Transport Certificate.

Step 4: Click on the 3 dots on the right, and then click on Get PEM to download the certificates.

If you need to revoke a certificate, click on the Revoke button to revoke the certificate.

The steps outlined above can also be used to generate obsigning certificates.

9.  Generate and manage Transport and Signing Certificates for Open Banking ETSI certificates (OBWAC and OBSeal)

The Open Banking Certificate Authority allows the generation and management of transport and signing certificates that have an ETSI profile, consistent with the structure of their equivalent eIDAS certificates (QWACs and QSeals).

Before you start

• You are viewing the Organisation details page for your ASPSP or TPP. Unlike Open Banking non-ETSI certificates, the OB ETSI certificates are not generated at the software statement level/screen, they are generated at the organisation level on the Organisation details screen. 

Steps to create CSR

To generate a valid CSR for an OBWAC or OBSeal please follow the instructions in the OpenSSL eIDAS PSD2 Certificate Signing Request Profiles 2.6 

Please note:

• If you use the obdatat tool referred to in Section 12 to successfully acquire an access token: '-nodes' must be added to the Openssl CSR generation command.
• If you copy and paste a QcStatement DER encoded line into your config file: line breaks or whitespaces may be introduced, which may invalidate your CSR.

Generate and manage OBWAC and OBSeal certificates

On the Organisation details page for your ASPSP or TPP, scroll down to the Organisation Certificates sections and upload your CSR for either an OBWAC or OBSeal. The following shows the Organisation Certificates section with several OBWACs and OBSeals.

To the right of each certificate is a menu option (three stacked dots). Click on these and three options appear:

• JWKS - a link to the JWKS file
• Get PEM - a link to the PEM file
• Revoke - click to revoke the certificate

To associate an OBWAC or OBSeal certificate to a Software Statement select it to navigate to the Software Statement's detail screen. In the above case, the Keys/certificates section appears as follows:

The certificates can be associated by selecting the check box for them. OBWAC and OBSeal certificates can be associated to one or more software statements. To dissociate a certificate from a software statement simply uncheck the Associated check box.  

10.  Upload and manage QWAC and QSeal (eIDAS) certificates 

The Open Banking Certificate Authority allows the upload and management of QWAC and QSeal certificates. 

Before you start

• Ensure you are viewing the Organisation details page for your organisation
• Ensure you can upload QWAC and QSEAL certificates using Dynamic Client Registration  (TPPs only) or via the DFI. 

Manage QWAC and QSeal certificates

To associate a QWAC or QSeal certificate to a Software Statement select it to navigate to the Software Statement's detail page. The certificates can be associated and dissociated in the same way OBWACs and OBSeals in the section above. 

11.  Upload and manage signing and encryption keys

Instead of the signing certificates mentioned above, signing keys can be used. On the Software Statement's detail page for your organisation, scroll down to the Keys/certificates section and upload your signing key. The certificates can be associated and dissociated in the same way OBWACs and OBSeals in the section above. Note, signing keys can only be associated to one Software Statement.

Encryption keys can be associated and dissociated in the same way as signing keys.

12.  Create a Software Statement Assertion (SSA) signed by Open Banking

As a TPP you will need to create a software statement assertion and submit it to ASPSP to receive valid client credentials. These credentials are then used to access any Payment Service User (PSU) resource from the ASPSP. SSAs are essentially JSON Web Tokens (JWT) issued and signed by Open Banking.

There are two ways to generate Software Statement Assertions:

1. SSA generation using DFI Portal, described in this section
2. Dynamic SSA generation using the API, described in section 13. Create a Software Statement Assertion (SSA) using an API call

Before you start

• You have created a Software Statement for TPP software that you want to register with an ASPSP.
• You have loaded an organisation level certificate (e.g. OBWAC/OBSEAL or eIDAS).

Steps to create a Software Statement Assertion

Step 1: Go back to the ASPSP or TPP Organisation details page and click on the newly created Software Statement.

Step 2: Scroll down to the Software Statement Assertion section and click Generate

Step 3: The SSA is displayed and can be copied to the clipboard. It can be used to on-board the associated Software Statement with an ASPSP. The plain text contents are also displayed.

Notes:

• Open Banking Ltd.’s signature can be verified using the JWKs store located at  https://keystore.openbankingtest.org.uk/keystore/openbanking.jwks
• Open Banking’s Root and Issuing Certificates can be found at OB Root and Issuing Certificates for Directory Sandbox
• If your certificate is missing in your software JWKS, it is most likely because you have not associated the certificate with the particular software statement

13.  Acquiring an Access Token to access Open Banking Directory APIs

To access Open Banking Directory APIs you will need an access token. This section describes the steps required to acquire access tokens.

Before you start

• Latest Long Term Support (LTS) version of Node.js and git installed on the computer used to acquire the access token.
• You have read the obdatat Readme file on git  https://github.com/OpenBankingUK/obdatat/tree/env-sandbox. For Directory Sandbox please make sure you clone or download the env-sandbox branch.
• Run the following command from the command line:
  • git clone git@github.com:OpenBankingUK/obdatat.git
• Run the following command from the command line:
  • cd obdatat
• Run the following commands from the command line:
  • npm install

Steps to acquire access tokens

Step 1: Make sure you are in the obdatat directory.

Step 2: Copy the two private keys generated in Create Certificate Signing Request (CSR) – one for the signing certificate, one for the transport - to the relevant files in obdatat config folder replacing their empty equivalents (privateKeySigning.key, privateKeyTransport.key).

Step 3: Download the PEM files from the DFI for the signing and transport certificates. Upload them into the config folder replacing their empty equivalents (certSigning.pem, certTransport.pem)

Step 4: Edit obdatat/config/config.json and set the values of its keys as follows:

• SoftwareStatementId — the Software Statement ID (software_id) of the software statement created in Create Software Statements.
• Client Scopes — one of the following, matching the type of your organisation:
  • for a TPP, use ASPSPReadAccess TPPReadAccess AuthoritiesReadAccess
  • for an ASPSP, use ASPSPReadAccess TPPReadAll AuthoritiesReadAccess
• Key ID (K ID in image below) — the value of the kid parameter associated with the signing certificate generated in Generate a Transport/Signing Certificate Pair. (Please note that you need to use the signing certificate kid)

• TokenUrl — https://matls-sso.openbankingtest.org.uk/as/token.oauth2
• tppTestUrl — https://matls-api.openbankingtest.org.uk/scim/v2/OBAccountPaymentServiceProviders/

Example

{

"softwareStatementId": "6Rj1EIORw6cRB3q3x1YVgg",

"client Scopes": "AuthoritiesReadAccess ASPSPReadAccess TPPReadAll",

"keyId": "tH9CjyQ-kbJBZpPx81cp-CVny-o",

"tokenUrl": "https://matls-sso.openbankingtest.org.uk/as/token.oauth2",

"tppTestUrl":https://matls-api.openbankingtest.org.uk/scim/v2/OBAccountPaymentServiceProviders/

"aud": https://matls-sso.openbankingtest.org.uk/as/token.oauth2

}

Note: MATLS connections require the use of the host name; using the IP address will not result in a successful connection.

Step 5: Run the following command from the command line:

• npm start

       The command will return an access token that can be used to access Open Banking Directory Services’ APIs. (see screenshot below)

        Please note that Open Banking have provided the obdatat tool to help you understand how to acquire an access token. You can use any HTTP client that supports HTTPS and MATLS.

14.  Create a Software Statement Assertion (SSA) using an API call

Software Statement Assertions can also be created using APIs provided by Open Banking, an alternative to manual SSA creation via the DFI. This section explains the steps to create SSAs using the API.

Before you start

• You have created a Software Statement.
• You have a HTTP client that supports HTTPS with MATLS.

Steps to create a Software Statement Assertion using API

Acquire an Access Token (see section 10. Acquiring Access Token).

Make a HTTP GET call using the access token and relevant scope to:

https://matls-ssaapi.openbankingtest.org.uk/api/v1rc2/tpp/<org_id>/ssa/<software_id>

org_id must be the Id of the TPP/ASPSP for which you want to generate an SSA.

software _id must be set to the Id of the Software Statement for which you want to generate an SSA; this is displayed under the Software Statement title at the top of the page (see below).

Client Scopes — use one of the following, matching the type of your organisation:

• for a TPP use TPPReadAccess
• for an ASPSP use ASPSPReadAccess 

15.  Creating and managing ASPSP Authorisation and Resource Servers

As an ASPSP you can add URIs so that TPPs can find your authorisation servers and other end points. This can be done by using the “Add well-known URI” feature provided to ASPSPs. This section details the steps required to create and manage authorisation servers.

Before you start

• You are an ASPSP. You are viewing the Organisation details page for your ASPSP.

Steps to add well-known URI

Step 1: Login to the system, select your ASPSP and scroll down to the Well-known URI section.

Step 2: Click on the Add new URI

Step 3: Enter the details.

Step 4: Click Submit button.

Notes:

• To edit the details click Edit URI button. (You can edit individual URIs.)
• To delete the details click Delete URI button. (You can delete individual URIs.)
• ASPSPs that have multiple brands can enter a Well-known URI per brand.
• ASPSPs can also enter a URL that defines their functional APIs using the input field labelled API Resource Discovery Endpoint.
• For ASPSPs who have created a discovery file using the discover file specification or the OBIE Functional Conformance Tool, please see this guide (https://bitbucket.org/openbankingteam/conformance-discovery/src/master/) on how to use this file as an API Resource Discovery Endpoint.

16.  Acquiring the List of ASPSP Authorisation and Resource Servers

As a TPP you can get access to the authorisation servers of individual ASPSPs. This section explains how to retrieve ASPSP authorisation servers using Open Banking APIs.

Before you start

• You have acquired an access token - see Step 10 above (Acquiring Access Token).

Steps to acquire ASPSP authorisation servers

Step 1: Send a HTTP GET request to:

              https://matls-api.openbankingtest.org.uk/scim/v2/OBAccountPaymentServiceProviders/

              using Authorization: Bearer <access_token>

              Bearer goes into the Authorisation header to obtain the list of ASPSPs

Step 2: Iterate over the response and filter for the AuthorisationServers

Notes:

• ASPSPs may provide a URL that defines their functional APIs using the input field labelled API Resource Discovery Endpoint.
• This information will be returned with the AuthorisationServers data.

17.  Obtaining an Organisation level OAuth Client

Below are the necessary steps needed to create, configure and update an Organisation level OAuth Client.

After the user selects a group of certificates for organisation level OAuth Client configuration, the system sends the certificates to the authorisation server. The subjectDN and issuerDN are extracted from the certificate, which are used to configure the new OAuth Client.

Before you start

• Lists of certificates will now be grouped in the DFI (and in edit mode) by issuerDN and subjectDN
• Details (subjectDN, issuerDN, organisation ID and organisation name) from the first certificate from the chosen group of certificates will be sent to the authorisation server and the API to update the OAuth Client. The API will also be accessible externally
• Having an organisation OAuth Client will allow you to interact with DIR-API

Steps to create and configure an Organisation level OAuth Client

Step 1: Log-in to the DFI and navigate to the Organisation Details tab to see the Organisation level OAuth Client section.

Step 2: Click "Create" to open up a window. Here, you will see that there are currently no organisational OAuth Client certificates in use, and you will need to select a certificate group for Organisational OAuth Client:

Step 3: Select a group of certificates from the Eligible Certificates Groups section. Note: certificates will be grouped by issuerDN and subjectDN.

Step 4: Click "Save" to continue.

Step 5: A success notification will appear and your successfully configured organisational OAuth Client will appear in the Organisation Details tab alongside updated validity dates.

Steps to update an Organisational level OAuth Client

Step 1: Log-in to the DFI and navigate to the Organisation Details tab to see the Organisation level OAuth Client section.

Note: A blue tooltip will appear when some, not all, certificates are due to expire soon. The tooltip will indicate which certificates are due to expire soon.

Step 2: In the Organisation OAuth Client section, click "Edit" to open a modal window. 

In it you will see organisation OAuth Client certificates currently in use and eligible certificate groups:

Step 3: Select a group of certificates from the Eligible Certificates Groups section to update the configuration. Note: certificates will be grouped by issuerDN and subjectDN.

Step 4: Click "Save" to continue

Step 5: A success notification will appear and your successfully updated organisation OAuth Client will appear in the Organisation Details tab alongside updated validity dates.

Steps to update soon-to-expire Organisation level OAuth Client certificates

Step 1: Log-in to the DFI and navigate to the Organisation Details tab to see the Org-level OAuth Client section.

Note: A red tooltip will appear when all certificates are due to expire soon. 

Note: A yellow tooltip will replace the blue tooltip next to each certificate to indicate that they are all due to expire soon.  

Step 2: In the Organisation OAuth Client section, click "Edit" to open a modal window. In it you will see organisation OAuth Client certificates currently in use and eligible certificate groups.

Step 3: Select a group of certificates from the Eligible Certificates Groups section to update the configuration.

Note: certificates will be grouped by issuerDN and subjectDN, and expired certificates will be automatically revoked and will not appear in the list of eligible certificate groups:

Step 4: Click "Save" to continue.

Step 5: A success notification will appear and your successfully updated organisation OAuth Client will appear in the Organisation Details tab with updated validity dates.

Note: In the event that there are no eligible certificates available to reconfigure the Organisation level OAuth Client, the notification below will appear upon clicking the "Edit" function:

When an Organisation level OAuth Client has expired and there are no eligible certificates available to update the configuration

Users must log-in to the DFI and navigate to the Organisation Details tab to see the Organisation OAuth Client section. If all certificates have expired a notification will appear highlighting this.

Note: the organisation OAuth Client cannot be used without a valid certificate being configured.

On clicking “Edit” the notifications below will be visible in the modal window if there are no eligible certificates available to reconfigure the Organisation level OAuth Client:

Note: Users must navigate to the Certificates tab to mint a new transport certificate and then configure the organisational OAuth Client to use it. 

Constraints on the API:

• The OAuthDomain must be set to PSD2
• The certificate as a request body and MIME type must be set to application/x-pem-file, and can only be OBWAC or QWAC type
• Authorization is based on JWT  

Additionally, to modify an organisation OAuth Client, the user must have at least one of the following scopes in JWT:

• ASPSPFullAccess
• ASPSPManage
• TPPFullAccess
• TPPManage

To retrieve information about an organisation OAuthClient, the user must have at least one of the following scopes in JWT:

• ASPSPReadAccess
• ASPSPFullAccess
• TPPReadAccess
• TPPFullAccess

Notes:

In the participant's Organisation OAuth Client certificate list on the Organisation Details tab, if a certificate has less than 30 days left until expiration a yellow warning tooltip will appear informing the participant of the upcoming expiration. 

If all certificates have less than 30 days remaining, a red tooltip will appear with a call-to-action.

18.  Using the Open Banking Directory APIs

Functionality that was previously only available via the DFI can now be accessed via Open Banking APIs:

• manage organisation contacts (CRU)
• manage software statements (CRU)
• generate software statement assertions
• upload/manage signing keys
• upload/manage encryption keys
• generate/manage OB non-ETSI certs
• generate OBWAC/OBSeal certs
• upload eIDAS QWAC/QSeal certs

The above require the generation of an organisational OAuth client.  The Dynamic Client Registration (DCR) service generates an organisational OAuth client. A full list of services is available on the Technical Directory Services page.

To understand how to use the API, please read the Directory API Swagger specification. This is an attachment to the Directory 2.0 Technical Overview DRAFT 1.2.

19.  Support

All queries, issues or support requests need to be routed through JIRA Service Desk (JSD) (see Open Banking JIRA Service Desk for guidance on how to report a query or issue). 

JSD will be monitored throughout each day - Monday to Friday, 8am to 6pm UK time - and issues raised will be responded to as follows:

1. Urgent Support Requests:   As they occur depending upon priorities 
2. Queries: Daily morning triage will assign and respond according to priorities
3. Bugs: Daily triage will assign and respond according to priorities

Any critical blocking bugs will be addressed as they occur depending upon priorities.

20. Definition of Terms

For further information on the terms used within this document please refer to the Glossary on the Open Banking website at www.openbanking.org.uk