When it comes to Open Banking, the challenge is to translate regulatory requirements into technical ones. And, it seems there are thousands of specifications and drafts within the OAuth and OpenID world that aim to implement those requirements. OAuth 2.0 and OpenID Connect are so much more than their core specifications. While there may not be thousands of standard extensions, there is undoubtedly a lot going on. Starting with version 6.3, the Curity Identity Server supports even more standards that focus on Open Banking.

When facing a complex security challenge, intelligent people usually gather to find a solution, write it down, and share it with others to adopt. Inevitably, standard bodies have generated a myriad of specifications to address different aspects of security, each with its own abbreviation. There's PKCE, DPoP and J-W-T, RSA, MFA, and SCA. Not to forget mTLS. It may be hard to have a serious conversation when people think you are imitating a pirate when mentioning PAR(RRRR), RAR(RRRR), and JAR(RRRR).

It's easy to feel overwhelmed by all the information available. And it can indeed be hard to navigate this jungle of specifications. Luckily there are now specifications for a common baseline! Profile specifications define how and when to use some of the other specifications. That is why you often find references to the FAPI 1.0 profile. Version 2.0 of FAPI is coming and includes even more OAuth 2.0 and OpenID specifications!

Lately, I've been wrapping my head around the security profile of the Open Banking Brazil (OBB) working group. In particular, I've been studying their Dynamic Client Registration profile (OBB DCR Profile)*. The Open Banking Brazil profile is, of course, very tailored to the Brazilian use-case, but has some similarities with the European PSD2. For example, both emphasize central trust management. There is some sort of regulatory authority that monitors the actors of the ecosystem. Only trusted clients should be able to benefit from the open market. Often, there is some sort of certificate involved — in a technical and broader meaning.

In the OBB DCR Profile, the client proves its certification by presenting a "software statement;" a JWT containing metadata about the client's certification, signed by the regulatory authority. I think the OBB working group created an excellent use case for this field. The Curity Identity Server has a lot of customization options and can be adapted to individual use cases to a great extent. Unfortunately, when it comes to DCR requests, those options are currently limited. Nevertheless, if you follow the best practices for deploying the Curity Identity Server and use a reverse proxy in front of it, then you already have all the parts in place to add a pre-processing step for validating the software statement. Just do it in the gateway! Well, it turned out to be a bit more advanced than I thought. However, in the end, I managed to validate a DCR request in NGINX.

Some specifications, such as the FAPI 2.0 and the OBB profile, are still under development, and the source available is a draft. Keep in mind that such documents are subject to change as they are discussed publicly. Even when a specification is finalized, errata may be published. So, stay alert so that you do not get lost in the jungle! And if you do, read our new resource article about how to implement financial-grade security. Also, be on the lookout for the next version of our product that will hopefully include more options around handling DCR requests in a way that should remove the need for a gateway's pre-processing of software statements.

You can also learn more in our webinar Financial-Grade APIs Now and in the Future.

* The original link was outdated and has been replaced with the new version.