Dynamic client registration allows trusted third-parties to register themselves with the Account Services Payment Services Providers (ASPSP) dynamically. The process is as follows:
The Third Party Provider (TPP) sends a registration request,
This is a POST request including an SSA (Software Statement Assertion) as a claim in the payload.
The SSA is sent as a signed JWT, which is obtained from the Open Banking (OB) directory. This contains the client metadata.
The ASPSP validates the SSA based on the specifications provided in the Open Banking OpenID Dynamic Client (OIDC) Registration specification.
The ASPSP registers the client application using the metadata sent in the SSA.
The ASPSP returns the response (success or error if the validation fails) based on the open banking UK specification.
The automated Dynamic Client Registration (DCR) process is carried out by calling a synapse API in the gateway.
An example request sent to the DCR registration endpoint is shown below:
The payload JWT should be in the format given below and must be signed using the signing certificate issued by the Open Banking directory. The kid parameter of the header should match the values in the kid of the signing certificate provided by the Open banking directory.
The TPP should be enrolled in the Open Banking directory and should upload the Certificate Signing Request (CSR) in order to obtain the public transport and signing certificates.
Include the following claims in the body of the request payload;
Claim Description Source Specification Optional Comments iss Request issuer (the TPP) [RFC7519] NO iat Time of issuance of request [RFC7519] NO exp Request expiration time [RFC7519] NO aud Request audience (the ASPSP) [RFC7519] NO jti The JWT ID [RFC7519] NO redirect_uris Registered URIs the TPP uses to interact with the ASPSP AS [OIDC-R] NO Must match or be a subset of the software_redirect_uris claim in the SSA. token_endpoint_auth_method Specifies which token endpoint authentication method the TPP wants to use [RFC7591] NO private_key_jwt: If requested, the OP should extract the TPPs JWKS location from the included software statement assertion. grant_types A JSON array specifying what the TPP can request to be supplied to the token endpoint as exchange for an access token [RFC7591] NO response_types A JSON array specifying what the TPP can request to be returned from the ASPSP authorization endpoint [RFC7591] YES ASPSPs may reject anything other than code. software_id The application name that is mentioned as
software_client_idin the SSA.
[RFC7591] YES If specified, the software_id in the request must match the software_id specfied in the SSA. ASPSPs can choose to allow multiple registrations for a given software client name and may take the software_id from either the SSA or the TPP as a hint. scope The scopes requested by the client (if not specificed, default scopes are assigned by the AS) [RFC7591] YES Minimum scope should be openid + whatever scopes are appropriate for the PSD2 role of the software. software_statement The SSA issued by Open Banking identifier [RFC7519] NO application_type Specifies whether the application type is web or mobile [OIDC-R] NO Must be web, if specified. id_token_signed_response_alg The algorithm with which the TPP expects to sign the id_token if an id_token is returned [OIDC-R] NO Supported values must comply with [FAPI-RW] Section 8.6. request_object_signing_alg The algorithm with which the TPP expects to sign the request object if a request object is part of the authorization request sent to the ASPSP. [OIDC-R] NO Supported values must comply with [FAPI-RW] Section 8.6.
- The software statement should be obtained from the Open Banking directory by the TPP. This is a signed JWT issued by the Open Banking directory.
A sample response is given below:
You need to get the latest product updates for the current version of WSO2 Open Banking. This fix is available as a product update from April 8, 2019 (04-08-2019) onwards. Changes affects to the sample response as follows.
Configure dynamic registration
Follow the steps below to configure dynamic registration.
Upload certificate to the client trust store
The ASPSP can upload the OB root and issuer certificates found from the following locations to the r
epository/resources/security/client trust store of both
In sandbox environment, upload certificates from https://openbanking.atlassian.net/wiki/spaces/DZ/pages/252018873/OB+Root+and+Issuing+Certificates+for+Sandbox.
In production environment, upload certificates from https://openbanking.atlassian.net/wiki/spaces/DZ/pages/80544075/OB+Root+and+Issuing+Certificates+for+Production
Use the commands to add the certificate to the client trust store as follows:
Edit the o
<WSO2_OBAM_HOME>/repository/conf/financefolder, open the o
pen-banking.xmlfile and add the following parameters:
- The token endpoint authentication methods indicate the authentication methods supported by WSO2. The registration validation will fail if the TPP requests a different authentication method.
ReadTimeoutvalues are needed when verifying the signatures for the request JWT and software statement JWT.
ReadTimeoutvalues are set to a default value of 3000.
- The values can be increased in case the signature validation fails with a time-out.
- The endpoint URLs are used to access the REST APIs of the API Manager in order to create the application and service provider, and to generate keys for the application.
Add the following configuration under
You need to get the latest product updates to use
software_idas the application name in the current version of WSO2 Open Banking. This feature is available as a product update from June 7, 2019 (06-07-2019) onwards.
Edit the a
<WSO2_OBAM_HOME>/repository/conf/axis2 folder, open the
axis2.xml file and add the following configurations to support the application/JWT content type:
To store any properties retrieved from the SSA, make sure you add the server level configuration to the
api-manager.xml file in the
<OB_AM_HOME>/repository/conf folder as explained here. For example, if you want to store the
software_client_id retrieved from the SSA created in the sandbox environment, the property name should look like:
software_client_id_sandbox. Similarly, to store the
software_client_id retrieved from the SSA created in a production environment, the property name should be:
software_client_id_production. Make sure you add these properties as false, as required.
In addition to these, make sure you include the
software_jwks_endpoint included in the SSA. This is necessary in order to obtain an access token for the application.
Ensure that the following values are accurately configured in the
api-manager.xml file in order to retrieve the above-configured properties through a soap service.