App2App redirect is known to have a positive impact on the Strong Customer Authentication user journey initiated from Mobile, being part of the standard since 3.1.6.
The UX reports I have seen all point out that App2App provides a superior user experience, being simpler and faster, as opposed to normal mobile browser-based authorisation redirects but also to decoupled authorisation.
This is mainly because App2App redirect allows for the ASPSP to use the existing device biometrics to authenticate the PSU. Biometrics is most probably is available in the mobile application provided by the ASPSP authorisation server, eliminating the need for a more friction-full SCA based on OTP or PIN.
App2App redirect is really, in my opinion, the âno-obstacleâ desired end-state one could expect for #openbanking, bot the AIS and PIS scenarios.
Technically, the ASPSP mobile app acts as the user-agent actor in the OIDC flow, if I may call it like this to oversimplify the integration. Wondering if multiple OIDC provider configurations are required for this, that is to expose two different set of well know endpoints, would need to read more on this.
Both ASPSPs and TPPs should follow the guidance from Apple and Google below:
iOS: Universal Links - Apple Developer (covers over 99% of all iOS users1, who are on iOS 9 or greater).
For Android a similar feature exists called app-links that covers 65% of all Android users, on Android 6.0 or later.
I think supporting App2App with the Secure API Gateway for Open Banking (SAPI-G) should be quite straight-forward, planning to write a follow up on this in the coming weeks.
Appreciate thoughts if anyone else tried this before or if other consideration are required.