I've been getting a lot of questions lately about how security profile conformance testing is (and will be) working in the UK OpenBanking ecosystem, so I thought it'd be helpful to write up a bit more detail about what has and will be happening.
There are 3 certifications currently available that are relevant to the security profile. I'll expand on each one below. I wrote this blog in July 2018; as this is a fast moving space it's very possible things have changed since.
Note that this is a completely separate topic to functional conformance; ASPSPs will generally want to certify for both functional and security conformance.
Background
A reasonable amount of confusion arose because OpenBanking largely adopted the FAPI-RW specification, but in order to allow all CMA9 ASPSPs to launch a service on the 13th January 2018 a number of concessions were made in a UK OpenBanking Security Profile.The main two areas of difference were:
- Client authentication: Whilst FAPI requires the use of OAuth MTLS or private_key_jwt client authentication, OpenBanking's deprecated security profile chose to also allow (but not recommend) client_secret_basic and client_secret_post as interim measures - albeit also requiring that matching MTLS certificates are also presented.
- Response Type: FAPI only allows response_type=code id_token. OpenBanking's deprecated security profile decided to also allow response_type=code "as an interim measure if not yet able to support code id_token"; the expectation would be that (due to known security flaws) any support for response_type=code would be removed shortly after an ASPSP has been able to update their software to support response_type=code id_token.
There are some other differences too, but the other changes are generally more minor.
On 23 August 2018, OBIE's Technical Design Authority (TDA) agreed a decision to switch from the Open Banking Security Profile to the Financial Grade API (FAPI) Profile.
The Open Banking Security Profile is hence essentially obsolete, and only still an option due to some legacy systems.
Available Conformance Tests
1. OpenID Connect Core tests
These test basic core opened connect behaviours. They do NOT support mutual tls of any form, and hence they cannot be run against an ASPSP production system.
ASPSPs may be able to run these tests against a development version of their system where all mutual TLS functionality has been disabled. If the version of any underlying vendor product in use already has an OpenID Connect Core certification then the value gained from running these tests again may be limited, so you should check with your vendor to see if they already have a certification.
2. OpenBanking security conformance suite
You can read more about this on the OpenBanking confluence. The server is at https://fintechlabs-fapi-conformance-suite.fintechlabs.io/.
These tests should only be used if the ASPSP has not yet adopted FAPI-RW (see the 'Background' section above for more explanation about this).
As you will see written in many places, this server and certification with these tests will not be available after 14th September 2019. These tests are already deprecated and are only still alive because a few ASPSPs have not yet managed to migrate to FAPI.
3. OpenID Foundation FAPI conformance suite
The instructions can be found here.
This suite is based on the OpenBanking Security Profile conformance suite, which OpenBanking donated to the OpenID Foundation. The suite has been updated to fully test FAPI-RW implementors draft 2 (currently the latest version of the spec, and the version of FAPI OpenBanking adopted).
This is the security conformance suite that OpenBanking recommend is used. In order to use this suite, ASPSPs must align to FAPI as explained in the above 'Background' section
In due course it is hoped that this test will cover all appropriate parts of the OpenID Connect Core tests, removing the need to run the 'Core' conformance suite.
It's important to also remember that ASPSPs should aim to test all the applicable software. In most ASPSPs this will mean running security conformance against:
- All production deployments
- All sandboxes
- All iOS applications (that implement 'app2app')
- All Android applications (that implement 'app2app')
Conclusion
Most ASPSPs should be looking to run the OIDF FAPI conformance suite, as going forward this is the only option on the table that will allow them to demonstrate security conformance to the Financial Conduct Authority. This will require that the ASPSPs align to the FAPI standard and support one of the FAPI mandated client authentication methods.
I'm happy to explain this in more detail to anyone and to assist with decisions in this area, please drop me an email at joseph.heenan@fintechlabs.io if you'd like to know more.
