...

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.

...

1. From the TPP interface to the ASPSP interface (to authenticate and authorise). The authorisation server URI is specified by each ASPSP in their .wellknown 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.

...

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.

For the initial redirect to the ASPSP app, there are two things the ASPSP's developers would need to do: a) configure the redirect URL on their web server b) configure their mobile app to accept the redirects. For the redirect back to the TPP, this is entirely in the competitive space for the TPP, as they may wish to redirect back to a 4th party or merchant.

The method for deep links is covered here for iOS and Android.Both ASPSPs and TPPs should follow the guidance from Apple and Google below:

• iOS: https://developer.apple.com/ios/universal-links/
• Android: https://developer.android.com/training/app-links/index.html

In the event that a PSU does have the app installed on their device, 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.

Security considerations

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

...