All Payment Service Providers (PSPs) are required to communicate securely when providing access to account services. There is also an expectation that those who provide access services do so in an interoperable way, to reduce the difficulty of using the Application Programming Interface (API) or other secure channels.
This survey looks at how the security of communications has been defined by different API communities and what requirements have driven them to design their security solutions.
Key Findings
Whilst there are differences in the approach taken by the different API communities, there is much in common. They all use Transport Layer Security (TLS) with mutual TPP/ASPSP authentication to provide basic security. However, there are many identified limitations in the use of TLS as the only method of securing the communications between ASPSPs and TPPs (see Appendix B on page 16). These limitations are overcome through also supporting Digital Signatures carried in the HTTP header.
Different communities have made different choices when it is necessary to apply digital signature to PSD2 requests and responses, and what data needs to be protected. However, given that all API communities take the same general approach in securing PSD2 communication this should not prohibit interoperable security.
A key difference is the technical protocol used for carrying digital signatures, with some communities adopting HTTP Signatures (Cavage v10) whilst others using JSON Web Signatures (JWS RFC 7515).
This could potentially divide the overall PSD2 communities into two non-interoperable groups. However, Open Banking Europe (OBE), working with the API communities and the ETSI European Standards Organisation, are working on standard solution which is based on JWS but has the capability to protect HTTP header information as in HTTP Signatures (Cavage v10).
