WSO2 Open Banking UK | DCR with self-signed SSAs
Open banking is a growing area in the current fin-tech industry. A major reason for it can be identified as the increase in the number of individuals that have access to the internet. During the covid-19 pandemic, the importance and value of open banking has been clearly understood and experienced. The ability to securely access bank accounts and bank services through different fin-tech applications has helped to reduce the need of carrying and exchanging physical money for day to day payments.
For open banking to work, registering a TPP(Third Party Provider) application in a bank’s API store is a critical requirement. For this, there are two main procedures followed in the current WSO2 open banking UK solution
Those are as follows
- Dynamic Client Registration(DCR) — A user with an authority issued SSA can use that and generate an API call to the DCR register endpoint, with a request body structured as a JWT
- Signup flow — Manually registering a client using the web UI in the application store.
From these two methods, let’s take a look at the DCR approach.
For an application to be registered via DCR, a TPP has to obtain a software statement assertion(SSA) from OBIE(the directory). The obtained SSA contains all the necessary information required to successfully register an application in the API store. SSA is in the form of JWT and is signed by the issuing directory. The issuer will also provide a URL that can be used to validate the SSA during the registration process.
UK Open Banking spec v3.2 has opened the possibility of using a self-signed SSA to register a TPP via DCR. The guideline goes as follows, “An ASPSP may opt to accept SSAs that are issued directly by a TPP without a central issuer. In such situations, the ASPSP may accept SSAs that are not signed (indicated by a JOSE claim of alg set to none). Where ASPSPs accept self-signed SSAs, they must specify this on their Developer Portal along with the claims that it expects to be included in the SSA”.
As explained in the guidelines, an ASPSP (Account Servicing Payment Service Provider, ex : Bank) can accept an SSA generated directly by a certain TPP, to register an application of the same TPP. But the open banking specification has not issued an exact guideline to follow in this except for their guideline mentioned above.
WSO2 Open Banking UK 1.5.0 has facilitated this requirement by introducing a WSO2 specific SSA format. A TPP with valid pairs of TLS and signing certificates can use those certificates and generate a JWT token and include a TPP generated(self-signed) SSA to register an application in the API store.
The TPP will have to sign the certificate request JWT with a valid signing certificate and include the public key of the signing certificate in the JWKs of the SSA with the use mentioned as ‘sig’, and use a transport certificate and its respective certificate.pem in the SSA JWKs with the use mentioned as ‘tls’. The same TLS certificate should be used when the DCR API is invoked. A fact to note is that a TPP can have only one signing certificate and one transport certificate. Adding certificate chains in the JWKS is not acceptable. The required SSA claims, request JWT claims and configuration changes are mentioned in the bottom of the article.
As of now, a user can use the DCR API to register, read, update and delete an application created using a self-signed SSA. However, a complication can arise in a scenario where a pair of certificates are expired. The exact problem would be the inability to update the certificate using DCR on such an occasion for application with self-signed SSAs. However, there are few tips that are useful in avoiding such a scenario. A TPP can be mindful of the expiry date of the certificates used in the application creation process and update them with the new pair using the same update flow, prior to the expiration date. That is understood as the most feasible option. But in case of a sudden revoke in the certificates due to some malicious act, a system administrator should be able to change the specific certificates manually and the application will be safe, secure and usable.
The following gist will provide a sample of the claims needed for the request JWT, SSA JWT and the configuration changes required in the apimanager.xml and open-banking.xml in WSO2 Open Banking 150 UK.
