Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Also, we note that paragraph 31 seems in contradiction with the definition of ‘independence’ of channels as it says: “For strong customer authentication the PSCs can be either a valid combination of these elements themselves or something which is only generated when all the elements have been provided (e.g. an algorithm in a chip produces a one-time password or cryptogram, based on a challenge responses where the PSU is asked for a PIN)”.
This would mean that the PSP only needs to validate a single factor for authentication if the second can be ‘presumed’. If this is the case, this would validate the usage of soft tokens and pin/private key technologies on the device as second factor and also satisfy the independence of authentication elements requirement.
If the intention of the dynamic linking is simply to ensure that a transaction/change cannot be repudiated once it has been authorized by a PSU (but this link information doesn’t have to be shown to the PSU), then the challenge would be to implement this dynamic linking for bulk transactions (e.g. a PSU initiate payments with different amounts to different accounts at the same time).
If the intention of the dynamic linking is to provide the PSU with an additional insurance that they are authorizing a specific transaction/change by showing them the changed/transaction values before (and/or after?) authorizing the change/transaction (e.g. via a pop-up message or a notification via another channel), then the challenge would be to display this information using current technology/device. This is especially a challenge for changes of fields that only contain textual information (e.g. mailing address), as the amount of information to be shown could be quite large. In case this intent is confirmed, a gradual transition from non-compliant devices to compliant devices should be allowed in order to avoid any disruption of service for the PSU.
Further explanations in regards with dynamic linking would be appreciated when drafting regulatory technical standards.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
The biometric behavior-based characteristics are appropriate, if all given security guidelines are taken into consideration. It is important that the final decision as to which form of credentials should be used for customer authentication, lies with the ASPSPs. If this is not the case, the question arises as to how ASPSPs can verify information given to them by TPPs and how the liability is regulated in the case of unauthorized transactions.4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
The current interpretation of the text of the directive implies that the authentication must be performed via different authentication channels to ensure independence (“the breach of one element does not compromise the reliability of the other”). However, having different authentication elements would limit the use of mobile banking as the PSU (Payment Service User) might not have access to other devices than the phone. It is therefore beneficial that the authentication factors are sent to a single device (e.g. mobile phone) rather than to multiple channels. It would be possible to separate the authentication factors at a software level to ensure security is not compromised.Also, we note that paragraph 31 seems in contradiction with the definition of ‘independence’ of channels as it says: “For strong customer authentication the PSCs can be either a valid combination of these elements themselves or something which is only generated when all the elements have been provided (e.g. an algorithm in a chip produces a one-time password or cryptogram, based on a challenge responses where the PSU is asked for a PIN)”.
This would mean that the PSP only needs to validate a single factor for authentication if the second can be ‘presumed’. If this is the case, this would validate the usage of soft tokens and pin/private key technologies on the device as second factor and also satisfy the independence of authentication elements requirement.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We see challenges with respect to customer authentication using the dynamic linking feature. However, the extent of the challenge is unclear and depends upon clarity of Article 97(2).If the intention of the dynamic linking is simply to ensure that a transaction/change cannot be repudiated once it has been authorized by a PSU (but this link information doesn’t have to be shown to the PSU), then the challenge would be to implement this dynamic linking for bulk transactions (e.g. a PSU initiate payments with different amounts to different accounts at the same time).
If the intention of the dynamic linking is to provide the PSU with an additional insurance that they are authorizing a specific transaction/change by showing them the changed/transaction values before (and/or after?) authorizing the change/transaction (e.g. via a pop-up message or a notification via another channel), then the challenge would be to display this information using current technology/device. This is especially a challenge for changes of fields that only contain textual information (e.g. mailing address), as the amount of information to be shown could be quite large. In case this intent is confirmed, a gradual transition from non-compliant devices to compliant devices should be allowed in order to avoid any disruption of service for the PSU.
Further explanations in regards with dynamic linking would be appreciated when drafting regulatory technical standards.