This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Accounts Information Service Provider Flow v1.3.6

This document explains the flow of events related to the Account Information Service that an Account Information Service Provider (AISP) tries. For the Berlin specific solution, the Account Information Service is exposed as an API resource in NextGenPSD2XS2AFramework of WSO2 Open Banking. In the Account Information Service, an AISP can access and retrieve account information of a Payment Services User (PSU) and the PSU authorises the AISPs to access and retrieve their account, transactions, and balances information.

Before you begin,

You need to deploy the NextGenPSD2XS2A API v1.3.6.  

 Click here to see how to deploy the API...

  1. Sign in to the API Publisher Portal (https://<WSO2_OB_APIM_HOST>:9443/publisher).

  2. In the APIs tab, select CREATE NEW API > I Have an Existing REST API

  3. Set the Input Type to OpenAPI File
  4. Click BROWSE FILE TO UPLOAD and select the <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/berlin-group.org/PSD2API_1.3.6/psd2-api_1.3.6_20200327.yaml Swagger definition (.yaml file).
  5. Click Next
  6. Leave the Endpoint field empty as it is.
  7. Set the Context value as follows: 

    xs2a
  8. Set the business plan to Unlimited : Allows unlimited  requests unless you want to limit the requests. 
  9. Click Create to create the API.
  10. Once you get the message that the API is successfully updated, go to Runtime Configurations using the left menu panel.
  11. Click the edit button under Request > Message Mediation
  12. Now, select the Custom Policy option.
  13. Upload the <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/berlin-group.org/PSD2API_1.3.6/dynamic-endpoint-insequence-1.3.6.xml file and click SELECT.   
  14. Scroll down and click SAVE.
  15. Go to  Endpoints using the left menu panel.
  16. Select Dynamic Endpoint
  17. Select the endpoint types; Production Endpoint/Sandbox Endpoint.
  18. Click Save.
  19. Now, go to Properties using the left menu panel.
  20. Click Add New Property.
  21. Add the API Properties according to your API and click  the Add button.  

    Property Name

    Property Value

    ob-specberlin
    ob-api-typepsd2

    For example: 

  22. Click SAVE.
  23. Go back to Overview using the left menu panel. 
  24. Click PUBLISH.
  25. The published API is available in the Developer Portal at https://<WSO2_OB_APIM_HOST>:9443/devportal.

You can try out the Account Information Service flow in WSO2 Open Banking using the following steps:


Step 1 - Sign up as a TPP

In this step, the TPP registers its TPP application in the WSO2 Open Banking Developer portal.

 Click here to see how it is done...
  1. Navigate to the WSO2 Open Banking Developer portal at https://<WSO2_OB_APIM_HOST>:9443/devportal.

  2. Select Applications in the menu. 
  3. In the Sign-in form, click Create Account.
  4. Provide a username and click Proceed Self Register.
  5. Fill the Create New Account form to complete registration.

  6. Read terms and conditions. Click the checkbox to agree to the terms and conditions.

  7. Click Register.




Step 2 - Sign in to the Developer Portal as the TPP

Users can sign in to WSO2 Open Banking Developer portal with the authentication details created during sign up.

 Click here to see how it is done...
  1. Sign in to the Developer portal as the TPP at https://<WSO2_OB_APIM_HOST>:9443/devportal.

  2. Enter the username and the password you entered when signing up as a TPP.  
  3. Click Continue

The homepage of the Developer Portal is now displayed along with the published APIs.




Step 3 - Create an application

The TPP with a CBPII application needs to create an application using WSO2 Open Banking Developer portal. The application created via the Developer portal allows to observe statistics of APIs, subscribe to APIs, and access the subscribed APIs.

 Click here to see how it is done...
  1. Go to the Applications tab in the Developer Portal.  

  2. Click ADD NEW APPLICATION.

  3. Enter application details.

    • WSO2 Open Banking currently authenticates the TPP applications using the Reference (Opaque) method.
    • For the Application Certificate, you need to upload the QSealC certificate obtained from a Qualified Trust Service Provider (QTSP).

    You can validate the Organization Identifier field according to  a custom regex you provide:

    This is available only as a WSO2 Update and is effective from August 11, 2021 (08-11-2021). For more information on updating WSO2 Open Banking, see Updating WSO2 Products.

     Click here to see how it done...
    1. Open the <WSO2_OB_APIM_HOME>/repository/deployment/jaggeryapps/devportal/site/public/theme/settings.js file.
    2. Inside the openbanking element, add the orgIdRegex and maxAllowedInputLength tags as follows: 

      openbanking: {
              spec: 'BERLIN',
              grantTypes: {
                  authorization_code: 'Code',
                  implicit: 'Implicit',
                  refresh_token: 'Refresh Token',
                  client_credentials: 'Client Credentials',
              },
              orgIdRegex: '^OB:[A-Z]{2}-[A-Z]{3}-[a-zA-Z0-9]*$',
              maxAllowedInputLength: 20
      }
      
      1. orgIdRegex: Organization Identifier is validated against this regex value.
      2. maxAllowedInputLength: The maximum length allowed for an Organization Identifier.
    3. orgIdRegex and maxAllowedInputLength are optional configurations and if they are not configured, the default regex value will be used without input length validation. the default regex value is as follows:

      ^PSD[A-Z]{2}-[A-Z]{2,8}-[[a-zA-Z0-9]*$
    4. You can customize the error message that is displayed when the above validation fails. 
      1. Open the <WSO2_OB_APIM_HOME>/repository/deployment/jaggeryapps/devportal/site/public/locales/en.js file.
      2. Update the following fields as required:
        • Shared.AppsAndKeys.OBConfiguration.org.id.content.helper
        • Shared.AppsAndKeys.OBConfiguration.org.id.content.helper.error

  4. Click SAVE

An application can be used to subscribe to multiple APIs. See Subscribe to an API for the instructions.



Step 4 - Subscribe to API

The TPP user needs to subscribe to the NextGen PSD2 XS2A Framework API in order to access the API resources. Once subscribed, the users can access all the supported services of the API resources.

 Click here to see how it is done...
  1. Go to the APIs tab in the Developer portal.

  2. Select the NextGenPSD2XS2A Framework API. 

  3. Go to Subscriptions at the bottom of the API and select SUBSCRIBE.
  4. Select an Application from the drop-down list, set the Throttling Policy and click SUBSCRIBE.
  5. Once you subscribe, you can find the list of subscriptions in the bottom.

Now that you have subscribed to the API, generate access tokens and invoke the API.




Step 5 - Create and upload certificates

The TPP user needs to create certificates to validate whether the TPP is registered in a governing entity. It is verified in the TPP Onboarding process. eIDAS root certificates obtained from the Qualified Trust Service Providers must be added to the client trust stores of the WSO2 Open Banking Identity and Access Management and WSO2 Open Banking API Management modules. For testing purposes, create a self-signed root certificate following the instructions given below:

 Click here to see a self-signed certificate is created...

In order to use self-signed certificates as mentioned in the below steps, disable the certificate revocation validation in the <WSO2_OB_IAM_HOME>/repository/conf/deployment.toml and <WSO2_OB_APIM_HOME>/repository/conf/deployment.toml files as follows:

[open_banking.cert_mgt.cert_revocation_proxy]
enable = false
  1. A keystore file is used to store the trusted certificates of the TPP in the WSO2 Open Banking solution. Use the commands given below in a command-line interface in order to create a keystore file as a TPP.

    Make sure to update the following placeholders:

    <alias>A preferred alias for the keystore file.
    <filename>A preferred name for the keystore file.
    keytool -genkey -alias <alias> -keyalg RSA -keystore <filename>.jks

    During the command execution, the TPP user requires to;

    1. Set a password for the keystore.
    2. Provide information, acquired when registering with a governing entity.
    3. Set a password for user-defined alias (<alias>).
  2. Convert the keystore from the .jks format to .PKCS12.  Make sure to update the following placeholders:

    <keyStoreName>This is the name of the <filename>, given above.
    <PKCS12FileName>This is the name of the keystore in the .PKCS12 format.
    keytool -importkeystore -srckeystore <keystoreStoreName>.jks -destkeystore <PKCS12FileName>.p12 -deststoretype PKCS12

    During the command execution, the TPP user requires to;

    1. Set a password for the destination keystore.
    2. Enter the source keystore password, as defined in the above step .
  3. Create the application certificate (.pem) file in the PKCS12 format using the keystore. e.g: tpp.p12.

    Make sure to update the following placeholders:

    <PKCS12FileName>This is the name of the keystore in the PKCS12 format, as mentioned above for the <PKCS12FileName>.
    <PEMFileName>This is the name of the application certificate that is created in the .pem format.
    openssl pkcs12 -in <PKCS12FileName>.p12 -nokeys -out <PEMFileName>.pem

    During the command execution, the TPP user requires to;

    1. Set a password to import the .pem file.

Once you create a self-signed root certificate, upload it to the client trust stores of WSO2 OB APIM and WSO2 OB IAM. 

  • Locate the client trust stores in WSO2 OB APIM and WSO2 OB IAM in the following directory paths:
    • <WSO2_OB_APIM_HOME>/repository/resources/security/client-truststore.jks
    • <WSO2_OB_IAM_HOME>/repository/resources/security/client-truststore.jks
  • Use the following command to upload the self-signed certificate:

    keytool -import -alias <alias> -keystore cacerts -file <PEMFileName>.pem



Step 6 - Generate keys

The TPP user requires a Client ID (Consumer Key) to access the subscribed APIs.

 Click here to see how it is done...
  1. Sign in to WSO2 Open Banking Developer portal as a TPP user.

  2. Go to the Applications tab and select the application you used to subscribe to the NextGen PSD2 Framework API.

  3. Scroll down and select either of the following types of keys:
    1. Production Keys: Generates access tokens in the production environment.

    2. Sandbox Keys: Generates access tokens in the sandbox environment.

  4. Click Manage at the bottom of the page.
  5. Provide the requested information as defined below:  

    Field

    Description

    Grant Types

    These determine the credentials that are used to generate the access token.

    • Code: This relates to the authorisation code grant type and is applicable when consuming the API as a user.
    • Implicit: This is similar to the code grant type, but instead of generating code, this directly provides the access token.
    • Refresh Token: This is to renew an expired access token.
    • Client Credential: This relates to the client credentials grant type and is applicable when consuming the API as an application.

    Callback URL

    This is the URL used by the TPP to receive the authorisation code sent from the Account Servicing Payment Service Provider (ASPSP), e.g: bank. The authorisation code can be used later to generate an OAuth2 access token.

    Application Certificate

    This is the content between the BEGIN CERTIFICATE and END CERTIFICATE strings of the application certificate (.PEM).  

    For testing purposes, you may use the here to download a sample application certificate, if you have configured the OB certificates.

    Organization IDThe Organization Identifier as provided in the eIDAS certificate. For example. PSDUK-NCA-OrganizationID

  6. Click GENERATE KEYS to generate production or sandbox keys. It generates consumer key and consumer secret.



Step 7 - Generate application access token

When invoking APIs in the NextGenPSD2XS2A framework, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the API.

 Click here to see how it is done...
  1. Once the client is successfully registered, sign in to WSO2 Open Banking Developer Portal and go to the Applications tab.

  2. Select your client application from the Application List. 

  3. You can view the keys you generated at the bottom of this page:

  4. The Consumer Key shown above is the client ID of your application.

  5. Now, generate the client assertion by signing the following JSON payload using the supported algorithms. 

    If you have configured the OB certificates, you may use the attached certificate and keys for signing and transports layer security testing purposes.

    The value of the aud claim should contain the same value as the Identity Provider Entity ID.

     Click here to view the Identity Provider Entity ID:
    1. Sign in to the Identity and Access Management console at  https://<WSO2_OB_IAM_HOST>t:9446/carbon
    2. In the Main menu, go to Home > Identity > Identity Providers > Resident.
    3. View the value in Resident Identity Provider > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration > Identity Provider Entity ID. By default this value is set to  https://<WSO2_OB_APIM>:8243/token .
  6. Run the following cURL command in a command prompt to generate the access token. Update the placeholders with the relevant values.

    curl -X POST \
      https://<WSO2_OB_APIM_HOST>:8243/token \
      -H 'Cache-Control: no-cache' \
      -H 'Content-Type: application/x-www-form-urlencoded'   \
      --cert <PUBLIC_KEY_FILE_PATH> --key <PRIVATE_KEY_FILE_PATH> \
      -d 'client_id=<CLIENT_ID>&grant_type=client_credentials&scope=accounts+openid&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION_JWT>&redirect_uri=<APPLICATION_CALLBACK_URL>'

    The access token is now generated.

    You can use the same cURL command to regenerate the access token.




Step 8 - Initiate account consents

In this step, the TPP creates a request to get the consent of the PSU to access the accounts and its information from the bank. The Bank sends the request to the PSU stating the accounts and information that the TPP wishes to access. Upon the user approving or denying the account consent, the TPP is now eligible to access the user's account details.

 Click here to see how it is done...

POST / consents - Create consent

First, the TPP must state the accounts and permissions in the account initiation request and send it to the bank. Then, the bank responds with a URL that redirects the PSU to provide the consent for the accounts that the TPP wishes to access. The request and the response are as follows:

  • The above initiation request may contain the TPP-Brand-Logging-Information header. This is an optional header, which can be used by TPPs to inform the ASPSP about the brand used by the TPP towards the PSU. This information is meant for logging entries to enhance communication between ASPSP and PSU or ASPSP and TPP.
  • To create a multiple recurring consent:  

     Click here to expand...

    This is available only as a WSO2 Update and is effective from August 10, 2021 (08-10-2021). For more information on updating WSO2 Open Banking, see Updating WSO2 Products.

    1. Open the <WSO2_OB_IAM_HOME>/repository/conf/deployment.toml file and add the following configurations to enable the multiple consents service: 

      [open_banking.berlin.aspsp_multiple_consent_support]
      enable = true
    2. Save the changes and restart the Identity Server. 
    3. To try out the AISP flow, initiate a consent. 
    4. When you enable the multiple recurring consent service, it adds the following header to the response of the initiated account consent.

      -H ASPSP-Multiple-Consent-Support: true
      • The value of the ASPSP-Multiple-Consent-Support header is a boolean and the value of this header depends on the above deployment.toml configuration.
      • If the service is not enabled, the default value for this header is false.

Users can call any API resource at any time once the TPP creates a consent and the PSUs grants access to relevant accounts.

 Click here to find the consent related API calls that can be invoked at any time...

GET /consents/{consentId} - Get consent request

The TPP can retrieve information of the account initiation request using the following request. It generates a sample response as below:

GET / consents/{consentId}/status - Consent status request

Once the consent is granted by the PSU, the TPP can retrieve the status of the consent using the sample request given below. It generates a sample response as follows:

DELETE /consents/{consentId} - Delete consent

The TPP can delete a consent that PSU has granted. See below for a sample request and response:


Step 9 - Initiate an authorisation flow for an account consent

WSO2 Open Banking for Berlin Implementation supports both implicit and explicit authorization flows for account authorization. In both cases, TPP generates the authorization URL using the well-known configuration that is received from the ASPSP as scaOAuth link in the response.

Implicit authorisation

In this approach,

  1. ASPSP creates authorization sub-resources after the account consent is received
  2. ASPSP replies with the well-known configuration of the Identity and Access Management module in the links section of the response
  3. TPP generates the authorization URL using the well-known URL
  4. PSU goes through the authorisation flow with that authorisation URL

Explicit authorisation

In this approach,

  1. TPP initiates the authorization flow by invoking the POST /consents/{consentId}/authorisations API resource
  2. At this point, the ASPSP creates authorization sub-resources and reply with the well-known configuration of the Identity and Access Management module in the links section of the response
  3. TPP has to generate the authorization URL, which the PSU uses to go through the authorization flow later 
 Click here to see how it is done...

POST /consents/{consentId}/authorisations - Start the authorisation process for a consent

The sample request shown below is seeking access to PSU's account. In this case, the TPP is creating an authorisation subresource, that the PSU can use to authorise.

Users can call any API resource at any time once the TPP creates a consent, and PSUs grant access to relevant accounts.

 Click here to find the consent related API calls that can be invoked at any time...

Following API resources can be followed by the consent authorisation step mentioned  here.

GET /consents/{consentId}/authorisations - Get Consent Authorisation Sub-Resources Request

The TPP can use GET / consents/{consentId}/authorisations API resource to retrieve the list of subresource IDs that are created. A sample request and response are given below:

GET /consents/{consentId}/authorisations/{authorisationId} - Read the SCA (Strong Customer Authentication) status of the consent authorisation

The TPP can check the status of a particular authorisation using the sample request given below:

Authorisation URL
The TPP uses the well-known URL regardless of the authorisation followed (Implicit/Explicit) to authorise an account as below:
 Click here to see how it is done...
  • The open banking solution sends the authorisation URL that was generated under scaOAuth link of the response. The response the TPP uses differs according to the authorisation as follows:

    Implicit authorisationThe response the TPP gets when initiating an account consent.
    Explicit authorisationThe response the TPP gets when invoking POST /consents/{consentId}/authorisations API resource.

    A sample well-known URL under scaOAuth parameter looks as below:

    {
       "scaOAuth":{
          "href":"https://<WSO2_OB_APIM_HOST>:8243/.well-known/openid-configuration"
       }
    }
  • Paste the authorisation URL in the web browser. The format for the authorisation URL looks as follows:

    Sample URL Format
    https://<WSO2_OB_APIM_HOST>:8243/authorize/?scope=<YOUR_SCOPES>&response_type=code&redirect_uri=<REDIRECT_URI>&state=<DYNAMICALLY_SET_VALUE>&code_challenge_method=<YOUR_CODE_CHALLENGE_METHOD>&client_id=<ORGANIZATION_ID>&code_challenge=<YOUR_CODE_CHALLENGE>

    Use the following table to find the descriptions for the parameters:

    ParameterDescription

    scope

    This is the reference to the consent resource for account access. It is in the form of ais:<consentId>
    response_typecode is recommended.
    redirect_uriThe TPP's URI that the OAuth2 server redirects the PSU's user agent after the authorisation.
    statePrevents XSRF attacks by TPP setting a dynamic value.

    code_challenge_method

    Code verifier transformation method. It is recommended in the Berlin specification to use S256.
    client_idAs provided in the eIDAS certificate, the organization_Identifier must contain the following information in it: - "PSD" as 3 character legal person identity type reference - 2 character ISO 3166 country code representing the NCA country - hyphen-minus "-" and - 2-8 character NCA identifier (A-Z uppercase only, no separator - hyphen-minus "-" - PSP identifier (authorization number as specified by NCA)

    code_challenge

    This is used to avoid code injection attacks using the PKCE challenge in the cryptographic RFC 7636. Go to https://tools.ietf.org/html/rfc7636 for more information on the cryptographic RFC 7636.
  • The authorisation URL points to the Consent page. 

  • Upon the user approving or denying the account consent, the user can invoke consent/authorization API resource of the authentication endpoint. By invoking this API resource, the user retrieves the consent approval/denial, that is displayed on the consent web-app.


Step 12 - Generate user access token

The TPP must obtain a user access token to invoke the APIs mentioned under Invoke Account Information Service APIs section.

 Click here to see how it is done...

Use the following sample request in order to generate the user access token:


Step 13 - Invoke Account Information Service APIs

Following are the API functionalities available for the Account Information Service in 1.3:

GET /accounts - Read account lists

The user can retrieve a list of accounts (bulk accounts) of a PSU. Following are the sample request and the response to call Get /accounts API resource.

GET /accounts/{account-id} - Read account details

The user can retrieve details of an account that consent is already granted by the PSU and stored in the ASPSP system. Use the sample request to generate a sample response as given below.

GET /accounts/{account-id}/balances - Read balances

The user can retrieve account data for a consent-granted account. Use the sample request to generate a sample response as follows:

The account addressed by the account-id is constant until the consent granted to that specific account expires.

GET /accounts/{account-id}/transactions - Read transaction list of an account

The user can retrieve transaction reports and transaction lists for a consent-granted account using the sample request given below. Users can choose the type of transaction using the booking status parameter. For a given account, a user can specify dateFrom and dateTo parameters.

The allowed values for the booking status parameter are booked, pending, both and information.

  • The value both is to request transaction reports where the booking status is either booked or pending.
  • Currently, booking status information only covers standing orders.

GET /accounts/{account-id}/transactions/{transactionId} - Read transaction details

The user can retrieve transaction information for a specific transaction.

This call generates responses for the transactions that are reported in the JSON format.

Use the sample request and generate a response as follows:

GET /card-accounts - Read a list of card accounts

The TPP can retrieve a list of card accounts. You can specify PSU ID to check the card-accounts that the PSU have consented. Additionally, you can retrieve balances of card accounts in the response. See below for a sample request and response.

GET /card-accounts/{account-id} - Read details of a card account

Retrieves information of a specific card account that the PSU has consented. See below for sample request and response information:

GET /card-accounts/{account-id}/balances - Read balances of card accounts

The TPP can retrieve balance information for a specific account by calling this API resource.