...
Authentication and Authorisation;
Data Encryption; and
Fraud detection and monitoring.
4.1 Authentication and Authorisation
...
In the context of data-sharing with a third-party, a principle of informed consent should be adopted. The user should clearly understand the authorisation they are being asked to provide, including:
Who they are providing authorisation to
What they are providing authorisation for (i.e. what the authorisation will permit the third party to do)
How long the authorisation will last for
To ensure accurate adoption of OAuth 2.0 and OpenID Connect (OIDC) frameworks while developing new API profiles, ASPSPs and AISPAISPs/PISPs can leverage security structures and rules set by the OpenID Foundation’s (OIDF) Financial-grade API (FAPI) profile. The Financial-grade API security profile can be applied to online services in order to augment OAuth 2.0 or OpenID Connect. The Bahrain OBF use case API specifications are built keeping the FAPI and OAuth 2.0 principles in mind.
...
TLS was designed with the goal of providing privacy and ensuring data integrity between two communicating applications
This has two layers:
The first layer uses TLS Record Protocol to encapsulate other higher level protocols; and
The second layer uses the TLS Handshake Protocol which allows the server and client to authenticate each other. The protocol allows negotiation and agreement of a cryptographic algorithm and keys prior to transmission or receipt of any data.
This is a basic level of security which rides on the TCP protocol and HTTPS. All RESTful APIs by default are created to use this as an encryption mechanism.
In order to achieve full FAPI compliance, all Open Banking stakeholders may run an additional layer of AES 128/256-bit encryption of signatures.
...
Note: The APIs require TLS 1.3 Mutual Authentication and this may be used as a means of non-repudiation. However, it would be difficult to maintain digital records and evidence of non-repudiation if the API only relied on TLS 1.3. A solution for non-repudiation that does not rely on TLS, would be achieved by providing a JWS with detached content (as defined in RFC 7515 - Appendix F) in the HTTP header of each API request. The HTTP body would form an un-encoded payload as defined in RFC 7797. The JWS would be signed using an algorithm that supports asymmetric keys. A request would be signed by an AISP’s/PISP’s private key and a response would be signed by the ASPSP's private key. Digital signatures are used to provide non-repudiation and authenticity by using public key algorithms. Private and public key is used to encrypt/decrypt the hash of the content. Encrypted hash is called a digital signature. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The certificate is digitally signed by the trusted Certificate Authority (CA) – the hash of the certificate is encrypted with the private key of the trusted CA.
Further inputs of the OBC and industry discussions may be submitted to the CBB for further considerations to changes to the security guidelines.
...
[1] Streaming APIs enables a subscription for receiving events in near real time using push technology. Streaming APIs invert the conversational nature of REST and enables the ASPSP server to send information to an AISP/PISP when an update is ready. While the AISP/PISP can, in theory, request an update, the streaming server of the ASPSP should pre-empt this with updates as ready. Streaming API reduces the load on the system by reducing the number of API calls thereby improving performance.
4.3 Fraud detection and monitoring
...
The API must provide support for out-of-band (OOB) authentication:
Out-of-band (OOB): Out-of-band authentication is a type of authentication that requires a secondary verification method through a separate communication channel along with the typical ID and password. Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process;
Forms of OOB authentication include codes sent to a mobile device via SMS, authentication via a voice channel, codes sent to a mobile app via push notifications, and codes sent to or received from a trusted execution environment connected to the host device that is trying to establish an authenticated connection; and
Out-of-band is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity "Examples include secure authenticator mobile applications"
ASPSPs must notify the user/customer asynchronously/OOB when significant actions have occurred (e.g. a change to a payee)
The ASPSP API response should inform the third party that an OOB process is underway so that, where appropriate, they can inform the user/customer
ASPSP and AISP/PISP should include fraud-relevant information (e.g. IP addresses, Geo location) in the API messages
The reporting of incidents and the process to handle it shall be covered as per the existing guidelines related to cyber risk in the CBB Rulebook
...