Open Banking Brazil DCR Request Validation

Financial-grade and Open Banking systems have high security requirements. The technical requirements commonly rely on a Public Key Infrastructure implemented by an authority that ensures and monitors the compliance of all actors. Therefore, mutual TLS and asymmetric JWTs are widely adapted user and client authentication methods within Open Banking or Financial-grade systems. It is of great importance to only allow trusted and verified clients to integrate with the system and finally access sensitive data. For the latter the user normally needs to grant permission. However, before any client can integrate and benefit from Open Banking it needs to get approved by the authority and become certified. Only then it can also register at the Account Servicing Payment Service Provider (ASPS), e.g. the bank. This is commonly implemented via the Dynamic Client Registration protocol, DCR.

Dynamic Client Registration in Open Banking

As mentioned above the client commonly authenticates using a mechanism based on public key cryptography such as mutual TLS or asymmetric JWTs. Client authentication alone does not guarantee that the data presented by the client is the same that it provided during its certification through the common authority. The Open Banking Brazil Dynamic Client Registration Profile addresses this issue.

The OAuth 2.0 Dynamic Client Registration specification defines the software statement as follows:

A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle. [...] When presented to the authorization server as part of a client registration request, the software statement MUST be digitally signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement.

The software_statement is used within the Open Banking Brazil Dynamic Client Registration to provide the Authorization Server of the ASPS the data that the client is certified for. As a result, the Authorization Server can verify that the data included in the DCR request matches the data included in the software statement that is signed by the authority. In particular the specification states that:

• shall validate that the request contains software_statement JWT signed using the PS256 algorithm issued by the Open Banking Brazil directory of participants
• shall validate that the software_statement was issued (iat) not more than 5 minutes prior to the request being received;
• shall require and validate that the jwks_uri matches the software_jwks_uri provided in the software statement;
• shall require and validate that redirect_uris match or contain a sub set of software_redirect_uris provided in the software statement;
• shall validate that requested scopes are appropriate for the software's authorized regulatory roles;
• should where possible validate client asserted metadata against metadata provided in the software_statement;

Advanced Request Validation using a Pre-Processing Procedure

Pre-processing procedures at the DCR endpoint are scripts that can validate and manipulate an incoming DCR request before it is processed by the server. Consequently, they are the perfect tool for verifying a software statement and populating default values before accepting and forwarding the DCR request. DCR pre-processing procedures can access the incoming request data and make use of key material configured in the Curity Identity Server for signature verification. This feature was introduced in version 6.5.

The following components are involved in the setup:

• An authority that governs a directory of trusted clients and manages the Public Key Infrastructure that is the foundation of the trust in technical terms. Among others, it publishes the key for verifying any software statement. This key is added as a signature verification key in the Curity Identity Server.
• A client that gets certified by the authority for one or several roles within the ecosystem. The client retrieves a certificate for client authentication as well as a software statement from the authority.
• The Curity Identity Server has a pre-processing procedure configured that validates the software statement in the incoming DCR request. It also performs some sanity check of the request data and if necessary, it populates default values from within the software statement. The Curity Identity Server then processes the DCR request according to the DCR specification and responses accordingly to the client.

The client starts with requesting a software statement from the authority. The software statement is a simple JWT that is signed by the authority and included in the DCR request to the bank's Authorization Server. Then the client needs to authenticate via mutual TLS to the DCR endpoint. Only client certificates issued by the authority are accepted.

The pre-processing procedure at the DCR endpoint will retrieve the software statement from the request data and validate it against the requirements. It will also verify claims presented in the DCR request against the claims in the software statement and perform other simple validation checks. It will if necessary populate default values based on the values within the software statement.

When the pre-processing is done the request is accepted, the Curity Identity Server processes it further and returns the DCR response. The Curity Identity Server is configured to support mutual TLS client authentication.

This approach requires the Curity Identity Server to support and enforce mutual TLS client authentication on the DCR endpoint. A pre-processing procedure on the same is necessary that enforces compliance with the specification. Read up on how to validate a dcr request in a pre-processing procedure and get technical insight.

Advanced Request Validation in an API Gateway

The Curity Identity Server supports the Dynamic Client Registration and even the Dynamic Client Registration Management protocol. It does not, however, support software statements as part of the DCR request and will ignore any as specified by the DCR standard. As for versions prior 6.5, an API gateway or reverse proxy needs to intercept the DCR request to comply with the Open Banking Brazil Dynamic Client Registration Profile. In that way the gateway can verify the software statement, validate the data and populate defaults from values within the software statement. In other words, it is within the gateway's responsibility to implement the requirements listed above.

Signature validation operations are resource-intensive and limitations in the cryptographic capabilities of the gateway will eventually lead to an external validation service. This service checks the signing algorithm, lifetime, expected issuer and signature of the software statement and returns the validation result to the gateway.

The approach presented in this section contains the following roles:

• An authority that governs a directory of trusted clients and manages the Public Key Infrastructure that is the foundation of the trust in technical terms. Among others, it publishes the key for verifying any software statement. This key is required by the software-statement-validation service to verify the signature of the software statement.
• A software-statement-validation service that takes the software statement, checks the lifetime of the JWT, validates the expected issuer and verifies the signature with the key of the authority.
• A client that gets certified by the authority for one or several roles within the ecosystem. The client retrieves a certificate for client authentication as well as a software statement from the authority.
• A gateway that validates the DCR request from the client, extracts the software statement that it forwards to the validation service. If the statement is valid, the gateway then performs further validation checks, populates any default values from the software statement and forwards the request together with the client certificate to the Curity Identity Server.
• The Curity Identity Server that processes the DCR request and responses accordingly to the client.

The client starts with requesting a software statement from the authority. The software statement is a simple JWT that is signed by the authority and included in the DCR request to the bank's Authorization Server. Then the client needs to authenticate via mutual TLS to the DCR endpoint. The DCR endpoint in turn is protected by an API gateway or reverse proxy. Thus, the TLS session is terminated at the gateway. Only client certificates issued by the authority are accepted.

The gateway will parse the data in the DCR request, retrieve the software statement and forward it to an external service to validate the signature. If the statement is valid and verified, the gateway will decode it.

The gateway will also verify claims presented in the DCR request against the claims in the software statement and perform other simple validation checks. It will if necessary populate default values based on the software statement.

At the end the gateway forwards the request to the Curity Identity Server that processes it further and returns the DCR response. The Curity Identity Server is configured to support mutuals TLS client authentication with proxy termination (mutual-tls-by-proxy).

This approach requires configuration and customization of the API gateway or reverse proxy using technologies such as a LUA script. Also, the software-statement-validation service will most likely be a custom implementation. Checkout the example for Open Banking Brazil compliant DCR request validation in nginx for technical insight.