Testing and Onboarding — Relying Party Developer Guide

1. Demo Client ID Data

For a quick start, or if you just want to try out some functionality, you can use the client data for our Demo Sandbox Client provided here.

This client has permissive settings regarding claims and is set up with default redirection URIs, listed below. It can only be used for the identity service. If you need different settings or the signing or payment initiation services, please register a sandbox client as described below.

By clicking the button below, you confirm that you have read and that you agree to the Terms and Conditions.

Sandbox Demo Client Data

Client ID: sandbox.yes.com:e85ff3bc-96f8-4ae7-b6b1-894d8dde9ebe
OpenID Connect Redirect URI (Authorization Response): http://localhost:3000/yes/oidccb
Account Chooser Redirect URI: http://localhost:3000/yes/accb

Certificate (cert.pem):

                        certificate placeholder

Secret Key (key.pem):

                        certificate placeholder

Since this client does not have customized settings and cannot be used for the signing or payment initiation services. In any case, testing with your own sandbox client is REQUIRED before you can proceed to production.

2. Testing in the Sandbox

For testing in the sandbox, you can use the Test IDP and CADI.

To reset the account chooser cookie for testing and development, go to https://accounts.sandbox.openbanking.verimi.cloud/cookie.

2.1. Test IDP (Sandbox Test Banks)

In the Sandbox environment, the identity service provides a number of instances of the ‘Test IDP’ for you to test your implementation against.

The Test IDPs are the official reference implementation for testing and integration in the Sandbox environment. Your requests to the Test IDP are handled and answered just as they would be at a real bank.

There are ten instances of the Test IDP with the issuer URIs https://testidp.sandbox.openbanking.verimi.cloud/issuer/10000001 to https://testidp.sandbox.openbanking.verimi.cloud/issuer/10000010.

They can be found in the account chooser using the search string testidp.

In the IDP UI you can use the nicknames of the users to log in (without password), for example, Test001, Peter, or Anna. The whole list of users, including the base data from which the provided claims will be derived, can be found here (view formatted on jsonformatter.org).

This JSON is in the internal configuration format of the Test IDPs; these are not user info objects.

2.2. Conformance Test, Acceptance Test, and Debug IDP (CADI)

CADI is a new service that enables you to test your implementation on conformance with the specifications, and it helps you debugging any problems with your integration. It will also be used during the technical and UI/UX review that your implementation will have to pass before going to production.

CADI helps you in debugging and testing your implementation, but it does not always behave like a real bank. For example, it might deliver less or more user data than requested. It will accept requests that would not work with a real bank and will let you know what was wrong.

How to use CADI:

Go to https://openbanking-cadi.azurewebsites.net/ and type your sandbox client ID into the input field.
In a new window, start a new flow using your implementation.
In the account chooser, select CADI as the bank. If you don’t use the account chooser, run a flow with this issuer URL: https://openbanking-cadi.azurewebsites.net/
You will be greeted by the CADI interface. You can click on Continue or select special test cases to check your implementation in detail. Complete the flow with your integration.
Reload the page in the first window to see test results.

Since CADI is in beta, don’t hesitate to contact our support if you suspect a bug or if you have any questions!

CADI works well with the identity service, but is (currently) limited for signing and payment initiation. In the latter two, it can be used to check the pushed authorization request and the authorization request, but signing and payment initiation processes cannot be completed.

3. Onboarding

While it is quite easy and straightforward to enter the sandbox environment, the go-live process needs a bit more interaction and information, mainly due to legal regulations.

3.1. Entering the Sandbox

The first step is to test your integration in our sandbox. While we provide a pre-configured client ID for you (see above), you need to set up your own sandbox client ID before going into production. This is also needed if you want to test all customization features of clients (custom texts, links, etc.).

To receive a sandbox client ID, we need from you:

Your account master data (mainly company name and address). Please send this data to partner-service-openbanking@verimi.com.
The requested configuration of the client, see Creating Client IDs.
```
 We will then issue a
client ID and send it to you.
```

3.2. Entering Production

For the production environment, we have a few more requirements. The legal/commercial steps can run in parallel with the technical steps below.

3.2.1. Legal/Commercial Onboarding

Please provide to your key account at the identity service or your Relying Party Agent (RPA) that is responsible for your onboarding:

The signed License Agreement and Price List
The signed identification sheet
Your billing master data

3.2.2. Technical Onboarding

Your technical contact is either partner-service-openbanking@verimi.com when you are contracting directly with the identity service, or otherwise a different contact at your Relying Party Agent (RPA). It will help you with the following steps:

Testing: Make sure you have tested your implementation both with the Test IDP and CADI.
Joint technical and UI/UX review of your sandbox implementation: A review the conformance with our specifications and guidelines - you can either provide your technical contact with access to your sandbox integration or arrange for a review via screen sharing during a video call. During the review, both the Test IDP and CADI will be used for various checks.
Configuration of client ID(s) for production: You request creation of a client ID as described in Creating Client IDs below. You will receive a new client ID for the production environment.

After all legal/commercial and technical steps are complete, your client ID will be activated and can be used. Each client_id only works for the RP service and environment it was created for and only together with the certificate that you registered. The format is as follows: sandbox.yes.com:3630bf72-e979-477a-a8ff-8a338f058932 (for the sandbox) and yes.com:4d30bf72-e571-bcde-a8ff-12348f05ffff (for production). Note that it is no problem to create more than one client ID, e.g., for mobile and desktop clients, or staging environments.

3.3. Creating Client-IDs with the identity service

If you are onboarding directly with the identity service, please use this form to request creation of a new client ID. Otherwise, please provide the same data to your Relying Party Agent. If you need to make any changes to the client ID later on, reach out to your technical contact (by default partner-service-openbanking@verimi.com).

We have a pre-configured sandbox client ID for you - see above!

After registration, we will provide you with a client_id for the sandbox or production environment.

3.3.1. Certificate

For mutual TLS we need a self-signed certificate from you. You may provide it in PEM format or as a JWKS or a URL from which the JWKS can be securely accessed. The JWKS must have an "x5c" parameter whose first certificate’s key must match the public key represented by other members of the JWK according to Sec 4.7 of RFC 7517.

The certificate can be created as follows:

openssl req -x509 -newkey rsa:4096 \
    -keyout secret-key_do-not-send-to-yes.pem -out cert.pem \
    -days 1096 -subj '/CN=***Name of your RP***' -nodes

This certificate will have the recommended lifetime of three years.

Ensure that an internal process exists to renew this certificate before it expires. Expired certificates will cause service disruptions and have caused even major internet services to fail in the past.

Keeping the key.pem file secret is vital to protect your user’s data. Never send it to us or anybody else!

To ensure a smooth key rollover, you can register a second certificate once the first one nears expiration.

3.3.2. What the End-User Will See

The name and optionally the logo will be displayed in the account chooser

Some of the data will be used by the IDPs when asking the user to consent to a specific transaction. The following is an example of such a screen, based on the identity service.

A: The client name.
B: The 'purpose' - unless a custom purpose is provided for the transaction, the default consent purpose will be used.
C: The optional terms of service link, designated by the custom label.
D: The mandatory privacy policy link, with a static label provided by the IDP.
E: The type of data requested is limited by the claims registered for your client.

Screens will look differently in practice depending on the IDP and the type of transaction, and they can be in a different language (German by default), but the overall semantics will be similar.