ScaStatus "psuIdentified" in Redirect-Approach

[benmoeARZ]

Place where bug appeared

• de.adorsys.psd2.consent.service.AisAuthorisationServiceInternal.saveNewAuthorization
• de.adorsys.psd2.consent.service.PisCommonPaymentServiceInternal.saveNewAuthorisation

Current behavior

• When PSU-Data is given in initiiation of Payment/Consent, then the created Authorisation is set to Status psuIdentified, even in Redirect-Appoach

Expected behavior

• We are not sure but we think, that status psuIdentified should only be used in Embedded or Decoupled Approach. In Redirect-Approach the default status should be received

Steps to reproduce

• Create new Consent or Payment in an Environment where Redirect Approach is default or only Redirect-Approach is active
• Make a GET on the created Authorisation /authorisations/{{id}}
• => Status will be psuIdentified

SCA approach

• [x ] Redirect
• [ ] Embedded
• [ ] Decoupled

XS2A version(s):

• 3.10

[DG0lden]

Hello benmoeARZ,

Although, the NextGenPSD2 Spec doesn't provide full workflow information for authorisation, we believe, that actual behaviour here is correct. The authorisation status depends not on the approach, but on the information, provided to this authorisation. Status description is taken from Section 14.15 "SCA Status" of Implementation guidelines. There is a difference between psuIdentified and psuAuthenticated. Thus, if PSU-ID is provided in initial request, we suppose that the PSU related to the authorisation resource has been identified (not Authenticated!). This allows depending on systems, like Online Banking, to show the actual screens to the user during the authorisation. If the PSU-ID is not provided in the initial request, then the status will be received. Once the user was authorized by online-banking, status to be changed to psuAuthenticated.

I'd be glad to compare our opinions, if you can provide some references, why you think this is not correct?

[benmoeARZ]

Hi,

I'm sorry, i just got this advice from our PO. Now he is absent for holiday... We discussed it in the team and the only reason would be that a TPP can then easyly check if a PSU exists. We kick/ignore the PSU-Headers when PSU is invalid, we do not want to throw an Error because it would also make it possible to scan for possible PSUs. So this flag would also signalize the TPP that a PSU exists. So we just thought that it is not really relevant for Redirect Approach. I made the adaption in our fork for the moment, and i will discuss it with our PO when he is back.

But sure your points also make sense.

If you think that your way is correct you can close this issue and i will just reopen it when our PO has a knock-down argument for you to change.

Thank you for your time

[DG0lden]

Well TPP gets Information about PSU anyway, most of our integration will reject initial request if PSU is not applicable for the bank. Since TPPs are identified by certificate and controlled by NCA, there is a low risk, that such behaviour would be inappropriate: ASPSPs are required to report about Fraud and XS2A usage by TPPs to NCA Ok, feel free to reopen it again, if question still appears