jogu
commented
4 months ago Hi Ranjiva, thanks for opening this.
This flow is quite difficult to follow - do you have a sequence diagram that shows it?
We are already thinking about potentially referencing https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps-01 for cases people have raised where it is only possible for a native app wallet (and not a website) to collect information that an issuer needs - e.g. an issuer website generally can't read a document such as a passport via NFC - I'm not sure if we got as far as opening an issue for that though.
ranjivaprasadvisa
Sakurann
vincentkelleher
cre8
Problem Statement:
A user holds a financial account with a payment service provider (PSP). They also hold a European Digital Identity wallet (EUDIW). They would like to use their EUDIW instance to authenticate transactions made against their account, in line with European PSD2 Secure Customer Authentication (SCA) regulation. To do so their PSP must issue a credential into their EUDIW instance for that account. This will be presented back to the PSP when the user is requested to authenticate a transaction made against the account at a later point in time.
Before the PSP issues the credential, it may wish to verify that the wallet holder is the account holder and whether the user’s EUDIW instance has the technical capabilities to act as an authenticator.
The user may start the credential issuance flow from their EUDIW instance or from their PSP app / portal. To simplify implementation, we would like to use an authorisation code flow for both, rather than using a pre-authorised code flow when the journey starts in the PSP. In both cases, the authorisation code flow requires credential issuance with a dynamic credential request.
The PSP can only make the dynamic credential request after it receives an authorisation request from the wallet. This creates a UX challenge when the authorisation code flow starts in the PSP app / portal. In this scenario, the user has authenticated into the PSP app / portal and selected the account(s) for which they wish a credential(s) to be issued. To make the dynamic credential request, the PSP must open the EUDIW instance (by sending a credential offer) before the EUDIW instance can send the user agent to the PSP authorisation request end point. The PSP can then make the dynamic credential request by returning the user to the EUDIW instance.
In the process, the user is taken from the PSP app / portal to the EUDIW instance and then to the PSP authorisation end point before returning to the EUDIW instance. Given that the user has already authenticated to the PSP and already provided consent for the credential by selecting account(s), there is no further user action required at the PSP authorisation end point. The user may therefore be confused as to why they have returned to the PSP and so managing user expectations at the authorisation end point will be challenging. Furthermore this sequence of steps is particularly cumbersome for the user to follow in a cross-device scenario.
Possible solution approach:
This issue can be avoided by removing the requirement for the EUDIW instance to send the user agent to the authorisation end point before the PSP can make a dynamic credential request. Instead, the PSP should provide a “native” implementation of the authorisation end point that the EUDIW instance can call directly without any change to the user agent’s location. The following draft may offer such a native implementation.
https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps-01
The draft describes the concept of an intermediate request which appears to be a mechanism for implementing the dynamic credential request. In this implementation, the PSP authorisation end point returns an insufficient authorisation error that informs the EUDIW instance on which credentials are needed by the PSP. The insufficient authorisation error could contain an authorisation request object that describes the credentials required.