1. Overview
This section covers redirection, decoupled redirection, and decoupled CIBA supported by the UAE Open Banking Standard (the Standard) to allow a User of a TPP to use the same authentication mechanisms as they do when accessing their 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)
These flows apply to other variations based on Use Cases covered in detail under the sections: Use Cases
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.
...
To demonstrate an app-based redirection part of the journey, we have used the User-facing TPP initial setup as one example.
| Rules & Guidelines |
|---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
2 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen( User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
3 | If the User has an LFI app installed on the same device the redirection MUST invoke the LFIs app for authentication purposes only without introducing any additional screens. The LFIs app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI app (biometric, passcode, credentials) and offer the same authentication method(s) available to the User when authenticating in their LFIs direct channels |
4 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access. |
5 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
6 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
7 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR, SIR). |
2.2 Browser-to-App
Conversely, User-facing TPP may be browser based only. However, if the User:
...
2.3.1 User Journey
...
2.3.2 Wireframes
...
| Rules & Guidelines |
|---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
2 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen(User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
3 | The redirection MUST take the User to the LFI web page (desktop/mobile) for authentication purposes only without introducing any additional screens. The web-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the web-based LFI channel (desktop/mobile). |
4 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access to. |
5 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
6 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
7 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR, SIR). |
2.4
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 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] https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/54526002/Authentication+by+LFI#2.-Redirection
The following User experiences are available using Decouple Redirection:
...
This journey does not introduce any changes in the redirection flow between the User-facing TPP and the LFI.
...
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.
Guidelines | |
|---|---|
| 1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 2 | User-facing TPPs MUST present Users with the authentication options supported by the LFI which in turn can be supported by the User-facing TPP device/channel (e.g. A User-facing TPP kiosk that can only support authentication by LFI mobile app). |
| 3 | The User-facing TPPs MUST display a code which is scannable or readable ( QRCode/NFC) by another User device. The User-facing TPP MUST present the information on how to use the code with their mobile device (e.g. scan QR code with the mobile phone camera). NOTE: The QRcode MUST be a deep link (as within the Redirection flow) supported by the LFI which MUST invoke the LFI app on scanning. |
| 4 | User MUST be able to easily scan the code (e.g. scan the code from the Kiosk in this instance) without much friction (like manually entering any URLs). |
| 5 | After the User scans the code from the User-facing TPP with a device camera, the LFI app MUST be invoked to perform the MFA. |
| 6 | The LFI app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI mobile app (biometric, passcode, credentials). |
| 7 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 8 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 9 | For this experience it is essential that the User-facing TPPs MUST have a web page where the LFI can redirect the control back to the User-facing TPP on the second device. The User-facing TPP must confirm on this mobile web page the successful completion of the request and informs the User to continue on the other device(Kiosk/desktop) where they had started their journey. |
3.2 Selection of LFI on Second Device
...
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.
Guidelines |
|---|
Guidelines
| 1 | The Call to Action (CTA) COULD be a static QRCode/NFC tag. Scanning of the static code by the User SHOULD invoke a User-facing TPP page/app deep linking them to the service represented by the code. |
| 2 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs data group and/or service initiation capabilities. |
| 3 | User-facing TPPs SHOULD make the User aware on the inbound redirection screen(User-facing TPP to LFI) that they will be taken to their LFI for authentication for data sharing. |
| 4 | If the User has an LFI app installed on the same device the redirection MUST invoke the LFIs app for authentication purposes only without introducing any additional screens. The LFIs app-based authentication MUST have no more than the number of steps that the User would experience when directly accessing the LFI app (biometric, passcode, credentials) and offer the same authentication method(s) available to the User when authenticating in their LFIs direct channels |
| 5 | After authentication, the User MUST be deep linked within the app to confirm the account(s) to which they would like the User-facing TPP to have access. |
| 6 | LFIs SHOULD have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
| 7 | LFIs SHOULD inform the User on the outbound redirection screen that their session with the LFI was closed. |
| 8 | User-facing TPPs SHOULD confirm the successful completion of the Open Banking Service Request (DSR & SIR). |
4. Effective Use of Redirection Screens
Within a typical redirection journey, a User is presented with two redirection screens:
The redirection screens are a useful part of the process, providing User trust. The following reasons are noted:
The messaging on the redirection screens serves to reassure the User that they are in control and helps engender trust. For example, Users will be more willing to trust the process if they feel there is a partner (User-facing TPP or LFI) on their side that is known and reputable (use language such as ‘we’, ‘our’). In this sense, the use of words that indicate that the User is in control and taking the lead is key, as these are indications that the User-facing TPP or the LFI is working with or for the User. | 
|
...
5. Error Scenarios During Redirection
As per OIDC, there are 2 main scenarios when an error occurs at the LFI side during the authorization process:
...