...
This chapter covers the key considerations of for security that would be essential from an for the Bahrain Open Banking ecosystem and applicable to ASPSPs and AISPs/PISPs. The PDPL provides and the CBB Rulebook provide direction on multiple internal security controls, processes and rules for adherence by ASPSPs and AISPs/PISPs. The objective of the chapter is to provide additional guidance and best practices on leveraging globally accepted and widely adopted security standards to help create a more robust/secure Open Banking ecosystem in Bahrain.
...
Further, penetration and vulnerability testing may be additionally conducted by AISPs/PISPs/ASPSPs based on the Open Banking release cycle, i.e. every time a major release related to the entityentities' s OB Open Banking systems, and any minor release that may potentially directly impact/expose any sensitive or personal data of users/customers.
...
OpenID Connect (OIDC) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of simplifying things and works over the existing HTTP standard
OpenID Connect enables developers to create an authentication mechanism across websites and applications without creating a separate username/ password file combination of their own
OpenID has the capability to manage multiple types of clients including browser based JavaScript and native mobile applications. Apps designed using OpenID are able to utilise sign-in workflows and receive confirmable assertions about the identity of the user (Identity, Authentication + OAuth 2.0 = OpenID Connect)
This can be used for accessing the APIs from multiple devices including mobile apps, desktops, etc. in a manner similar to how Google/Facebook single sign-on works across other websites. This can be modified to include the UID as the access token against which an individual or an organisation can be authenticated
Further details on the OIDC specifications can be found on their website
...
While the participants are required to adhere to TLS 1.2 MA at minimum, they may additionally they might consider adopting the latest available TLS version.
...
The API must provide support for out-of-band (OOB) authentication:
Out-of-band OOB 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
OOB 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, Geolocation) 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
...