Deep Linking for App-to-App Redirection

ProblemStatement

As provided in the P3/P4 Evaluation letter, the OBIE definition of App-to-App is:

‘App-to-App’ redirection allows the TPP to redirect a PSU from the TPP application (in a mobile web browser or mobile app) to the ASPSP’s mobile app, installed on the PSU’s device, where the TPP is able to transmit details of the request along with PSU preferences (e.g. product type, one-step authentication) and deep link the PSU into the ASPSP app login screen or function. The PSU is then authenticated through their app using the same credentials/methods as normally used when the PSU directly accesses their account using the app (typically biometric). This must not involve any additional steps (such as being redirected first to a web page to select which ASPSP app to use) and must not require the PSU to provide any PSU identifier or other credentials to the ASPSP if their current ASPSP app does not require this. Where the PSU does not have the ASPSP’s mobile app, they should experience a redirection flow which should not involve additional steps than would be the case when the PSU authenticates with the ASPSP directly (e.g. be redirected to the ASPSP’s mobile website).

There have been a number of technical and security challenges regarding the implementation of App-to-App. These are addressed below.

This document does not cover the standards nor implementation of de-coupled flows.

How the Redirect Flow Works

When using a service based on the OBIE API standard for redirection, the PSU will be re-directed twice:

1. From the TPP interface to the ASPSP interface (to authenticate and authorise). The authorisation server URI is specified by each ASPSP in their well-known endpoint.

2. Back from the ASPSP interface to the TPP interface (to complete any transaction with the TPP). This redirect is specified by the TPP as part of the first redirect.

Implementation of DeepLinks

A seamless journey for the PSU, which bypasses the built in browser (e.g. Safari) on their mobile device, can be implemented for any URL, ie BOTH a) for the initial redirect which the TPP sends the PSU to on the ASPSP’s servers, AND b) the redirect URL which the ASPSP sends the PSU back to after authentication/authorisation.

Both ASPSPs and TPPs should follow the guidance from Apple and Google below:

iOS: https://developer.apple.com/ios/universal-links/ (covers over 99% of all iOS users1, who are on iOS 9 or greater).

Android: https://developer.android.com/training/app-links/index.html (covers 65% of all Android users2, who are on Android 6.0 or later).

In the event that a PSU does not have the app installed on their device, or if they have an older (or non iOS/Android, e.g. Windows Mobile) operating system, these methods will allow the PSU to be re-directed to a mobile web page.

Open Banking Directory Implications

In order to support multiple apps for a given brand (e.g. Brand X Personal App, Brand X Business App), ASPSPs will need to configure multiple ‘virtual‘ well-known configuration endpoints for each physical authorisation server listed on the Open Banking Directory. The Open Banking Directory will be updated to facilitate this functionality.

SecurityConsiderations

Security considerations are addressed here: https://tools.ietf.org/html/rfc8252

You can find the most updated paper version of this here: Deep linking for App-to-App redirection