1. Overview

There are three main ways or methods of carrying out the authentication procedure of the User through a dedicated interface, and APIs in particular, namely redirection, decoupled approaches, and embedded approaches (or a combination thereof).

These approaches are categorized based on the device and the application where the consumption of User-facing TPP service and authentication with the LFI takes place

1. Redirection - The User consumes the User-facing TPP service and authenticates with the LFI on separate applications on the same device. The authentication data is exchanged only between User and LFI through the LFI application and the User-facing TPP has no visibility of this. Redirection uses the principle of deeplinking when the User’s action within the User-facing TPP app/website invokes the LFI app/website.

2. Decoupled - The User consumes the User-facing TPP service and authenticates with the LFI on separate applications on separate devices. The authentication data is exchanged only between User and LFI through the LFI application and the User-facing TPP has no visibility of this. A Decoupled experience on the two devices can be achieved by

   1. using Redirection where the User uses a deeplink within the User-facing TPP app/website on one device to invoke their LFI app/website on another device

   2. using Client-Initiated Backchannel Authentication(CIBA) Flow where User-facing TPPs can obtain a valid identifier for the User they want to authenticate. They will be able to initiate an interaction flow to authenticate the User with their LFIs without having end-user interaction from the consumption device. The flow involves direct communication from the User-facing TPP to the LFI without redirecting the User through the User’s browser (consumption device).

3. Embedded - The User consumes the User-facing TPP service and authenticates with the LFI within the User-facing TPP application on a single device. The authentication data is exchanged directly between a User-facing TPP and LFI through the User-facing TPP application.

1.1. UAE Standard Support and Requirements

The UAE Open Banking Standard (the Standard) will support redirection, decoupled redirection, and decoupled CIBA to allow a User of a TPP to use the same authentication mechanisms as they do when accessing their LFI directly.

The general principles relating to authentication that apply are:

1. LFIs authenticate: The User MUST go through Multi-Factor Authentication (MFA) at their LFI for a User-facing TPP request (i.e. Service Initiation or Data Sharing) to be actioned by the LFI.

2. Availability of normal authentication methods: The User MUST be able to use the elements they prefer to authenticate with their LFI if supported when interacting directly with their LFI.

3. Parity of experience: The experience available to a User when authenticating a journey via a User-facing TPP SHOULD involve no more steps, delays or friction in the customer journey than the equivalent experience they have with their LFI when interacting directly.

4. No unnecessary additional authentication: It is not expected that MFA would be required more than once when facilitating authentication for a single session of data sharing request, or Service Initiation request.

5. No Obstacles: LFIs MUST not create unnecessary delay or friction during authentication including unnecessary or superfluous steps, attributes, or unclear language, e.g. advertising of LFI products or services, language that could discourage the use of User-facing TPP services or additional features that may divert the User from the authentication process.

2. Redirection

Redirection-based authentication has a range of possible experiences for a User based on whether the User has a LFI app or not and the device on which the User is consuming the User-facing TPP service.

When using a User-facing TPP for Data Sharing Requests(DSR) and Service Initiation Requests(SIR) User MUST be able to authenticate with the LFI using the same authentication methods they are accustomed to using when accessing the LFI directly.

We have used one example of a User-facing TPP and DSR journey to demonstrate how a redirection flow MUST work. (The same applies to SIR and service requests)

2.1 App-to-App

User authentication with the LFI using the LFI mobile app installed on the same device on which the User is consuming the User-facing TPP service. The User starts the journey from a User-facing TPP app.

2.1.1 User Journey

Open

2.1.2 Wireframes

Open

This enables the User to authenticate with the LFI while using a User-facing TPP for an Open Banking services (i.e. DSR, SIR, & Service Request) using the same LFI app-based authentication method which they use when accessing the LFI mobile channel directly.

User-facing TPP service COULD be web-based or app-based. The redirection MUST directly invoke the LFI app to enable the User to authenticate and MUST not require the User to provide any User identifier or other credentials to the User-facing TPP.

To demonstrate an app-based redirection part of the journey, we have used the User-facing TPP initial setup as one example.

2.2 Browser-to-App

Conversely, User-facing TPP may be browser based only. However, if the User:

then the User-facing TPP website MUST redirect the User’s browser to the LFI. The LFI on receiving the redirection request MUST invoke the LFI app for authentication on the User’s device. Following authentication, the User MUST be redirected back to the User-facing TPP browser on the mobile device.

2.3 Browser-to-Browser

If a User is using a desktop browser to access the User-facing TPP, then under the redirection model the journey MUST be completed on the LFI browser channel.

Browser-to-Browser Redirection is also applicable when:

It is imperative in these circumstances that the LFI browser channel has been optimized for mobile browser and device type.

2.3.1 User Journey

2.3.2 Wireframes

2.4 App-to-Browser

It is possible that a User is using the User-facing TPP app on a mobile device which does not have their LFI mobile app installed, or their LFI does not provide an app at all.

In these instances, the User-facing TPP app MUST redirect the User to use the default mobile browser to present the User with their LFI's web channel to authenticate.

The browser for the User authentication MUST not be an embedded view within the User-facing TPP app.

Again, in these circumstances, it is imperative that the LFI browser channel has been optimized for mobile browser and device type.

3. Decoupled Redirection

In “Decoupled” authentication, typically the User uses a separate secondary device to authenticate with the LFI. This model allows for several innovative solutions and has the added benefit of allowing a User to use their mobile phone to authenticate taking advantage of biometrics for MFA, where they are engaging with a User-facing TPP through a separate device, such as a desktop/laptop of a point of sale (POS) device.

In a Decoupled Redirection flow the User uses a deeplink within the User-facing TPP app/website on one device to invoke their LFI app/website on another device using the same redirection mechanism as in [TBC]

The following User experiences are available using Decouple Redirection:

3.1 Selection of LFI on First Device

An authentication flow in which a dynamic link (e.g. via a QRCode or NFC) is generated by the User-facing TPP on one device (e.g. desktop/laptop or kiosk) and is scanned by User on another device (e.g. User’s mobile device). This dynamic link will invoke the LFI’s mobile banking app which uses the information from the dynamic link to then redirect User to process the request after authenticating the User.

This journey does not introduce any changes in the redirection flow between the User-facing TPP and the LFI.

3.1.1 User Journey

3.1.2 Wireframes

To demonstrate a Redirection flow on different devices, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

We have illustrated an example where the dynamic identifier is a QR code. The code SHOULD contain a DeepLink (as within the Redirection flow) supported by the LFI which SHOULD invoke the LFI app when the User scans the QRCode.

3.2 Selection of LFI on Second Device

This journey is a variation of the User-facing TPP flow within the standard redirection journey which could be triggered from a non interactive interface of the User-facing TPP (e.g. advertising board) which then progresses on the User’s mobile device. The LFI selection and consent request happens on the User's mobile device which then invokes the LFI app/webpage on the same device to complete the authorization using a redirection flow.

This journey does not introduce any changes in the redirection flow between the User-facing TPP and the LFI.

3.2.1 User Journey

3.2.2 Wireframes

To demonstrate a Redirection flow on different devices, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

We have illustrated an example where the static code on an advertisement board is a QR code. The code SHOULD contain a deepLink supported by the User-facing TPP which SHOULD invoke the User-facing TPP app/webpage on scanning.

4. Decoupled CIBA

There are several other possible Decoupled authentication flows as listed below which use the CIBA Flow.

In this authentication flow the User-facing TPPs can obtain a valid identifier for the User they want to authenticate. They will be able to initiate an interaction flow to authenticate the User with their LFIs without having end-user interaction from the consumption device. The flow involves direct communication from the User-facing TPP to the LFI without redirecting the User through the User’s browser (consumption device).

4.1 Decoupled Model A: Static User Identifier

An authentication flow in which the User provides a static identifier provided by their LFI to the User-facing TPP which is then used by the LFI to identify the User and initiate an authentication journey on the consumer’s LFI app which is on a device separate to the one on which they are consuming the User-facing TPP service.

4.1.1 User Journey

This enables the User to use the same app-based authentication method with the LFI that they use when accessing the LFI mobile app directly.

This model is best suited to User-facing TPP apps with good user input options (e.g. website on PC/laptop) but also where terminals can scan something that has the User identifier(e.g. debit card) and automatically resolve the LFI .

The exact type of identifier supported by the LFI MUST be published by the LFI.

4.1.2 Wireframes

To demonstrate a Model A-based decoupled journey, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

4.2 Decoupled Model B: LFI Generated Identifier

An authentication flow in which the User provides a dynamic identifier, generated by their LFI, to the User-facing TPP which is then used by the LFI to identify the User and authenticate with the LFI app.

4.2.1 User Journey

This model is best suited to a User-facing TPP app that can “capture” the code from the LFI app (e.g. by scanning a QR code).

Alternatively, the User can be prompted to type in an identifier in the User-facing TPP App. This may be a long series of characters and may result in a sub-optimal customer experience.

4.2.2 Wireframes

To demonstrate a Model B-based decoupled journey, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

4.3 Decoupled Model C: User-facing TPP Generated Identifier

An authentication flow in which a dynamic identifier generated by the User-facing TPP, is used by the User through their LFI app which is then used by the LFI to process the request after authenticating the User.

4.3.1 User Journey

This model is best suited to a LFI app that can “capture” the code from the User-facing TPP app (e.g. by scanning a QR code). Alternatively, the User can be prompted to type in an identifier in the LFI App. This may be a long series of characters and may result in a sub-optimal customer experience.

4.3.2 Wireframes

To demonstrate a Model C-based decoupled journey, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

We have illustrated an example where the dynamic identifier is a QR code and is scannable by the LFI app. Ideally, the code SHOULD be part of a DeepLink (as within the Redirection flow) supported by the LFI which SHOULD invoke the LFI app on scanning.

The general requirement is that the use of the code within the LFI app MUST not introduce friction in the journey.

4.4 Decoupled Model D: User With a User-facing TPP Account

A decoupled authentication flow in which the User-facing TPP provides the LFI with a stored User identifier from a previous transaction. This is used by the LFI to enable the User to authenticate using their LFI app on a separate device.

4.4.1 User Journey

This model is ideally suited where the services offered by the User-facing TPP involve POS, telephony, or where User interaction with the User-facing TPP is not possible through a user interface (IoT devices), or even when the User may not be present within the User-facing TPP channel.

4.4.2 Wireframes

To demonstrate a Model D-based decoupled journey, we have used one variation of the DSR journey as an example where the LFI receives all the details of the request from the TPP.

The voice commands are an example of how the User interacts with the User-facing TPP.

5. Effective Use of Redirection Screens

Within a typical redirection journey, a User is presented with two redirection screens:

6. Error Scenarios During Redirection

As per OIDC, there are 2 main scenarios when an error occurs at the LFI side during the authorization process:

• Malformed Authorization Request: The authorization request may be malformed when submitted by the User-facing TPP. For example, it may include an invalid redirection URL, invalid parameters, invalid signature on the request object etc. OAuth2 and OIDC define a whole list of potential errors. These are abnormal situations which indicate a significant technical issue at the User-facing TPP's end or even an attacker trying to act as a User-facing TPP. For safety (and as per the Standard) the LFI MUST not redirect the User back to the User-facing TPP in such situations. The LFI MUST display an error message and stop the execution at this point. It is at the LFIs’ discretion to display to the User the message they find most appropriate for this error case, however, an error message MUST be displayed.

  In this situation, User-facing TPPs do not receive a response from the LFIs about the malformed authorization request. Therefore, User-facing TPPs are not able to display any message to the User in this situation.

  The User relies completely on the LFI to be notified about the occurrence of an error.

• User interaction error: An error occurred during user interaction, for example, users click on cancel or are unable to validate their credentials, the debtor account in the authorization request does not belong to the User etc. In this case, the LFI MUST redirect the User back to the User-facing TPP and provide in the response the appropriate OIDC error message.

The LFI COULD potentially display an error message to the User before redirecting back to the User-facing TPP, but it is solely at their discretion. The User-facing TPP SHOULD check the OIDC error code and display additional messages to the User with further information messages.

Error responses are documented as below:

• For OIDC: Final: OpenID Connect Core 1.0 incorporating errata set 2

• For OAuth 2: RFC 6749: The OAuth 2.0 Authorization Framework

Please note that both of the above scenarios are strictly checked by the FAPI conformance suite from OIDF.

Following the above requirements in the case of these error scenarios will prevent occurrences of bad customer experience due to errors managed insufficiently.