Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Specific, but obvious example. If the mobile phone has a role in the process, will others forms of use of the smart phone (internet functions sharing files on the phone) pose a risk for the payment process? Will there be dual use for a specific chip in the phone, will there be dual use for biometric authentication, which means data will be stored outside the payment community, etc.
For other authentication factors using inheritance the main questions if these are tamper proof in situations, where there is no physical control how someone is authenticating with or without fake attributes. Contrary to iris scan for access control at locations where there are guards. The guards or other visual control will prevent abuse.
- an open standard requires that an implementer or user of the standard doesn’t need to pay fees for intellectual property rights and alike.
- The standard should require that any addition to the services made by a service provider doesn’t force the users of the servers and the other partners in the chain to change something in their interfaces to get the service, unless they deliberately choose to use the added service/information. This way added functionality shouldn’t force changes to others in the chain.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
In the way the questions handle risks it misses one important point. Also to ask: for every instrument, which will be used in the authentication process, are there forms of use of the instrument which cause risks for the authentication and the transaction?Specific, but obvious example. If the mobile phone has a role in the process, will others forms of use of the smart phone (internet functions sharing files on the phone) pose a risk for the payment process? Will there be dual use for a specific chip in the phone, will there be dual use for biometric authentication, which means data will be stored outside the payment community, etc.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
NA3. 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?
I haven’t evaluate the scientific research about behavior based authentication. However I see another drawback of this. These are based on things like the way people are typing texts or are moving the mouse. These options for authentication are not device independent.For other authentication factors using inheritance the main questions if these are tamper proof in situations, where there is no physical control how someone is authenticating with or without fake attributes. Contrary to iris scan for access control at locations where there are guards. The guards or other visual control will prevent abuse.
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)?
NA5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
NA6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
NA7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
NA8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
NA9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
NA10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
NA11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
NA12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
NA13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
NA15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
In general open and common standards are difficult to define in an evolving environment. I suppose it should comprise amongst others:- an open standard requires that an implementer or user of the standard doesn’t need to pay fees for intellectual property rights and alike.
- The standard should require that any addition to the services made by a service provider doesn’t force the users of the servers and the other partners in the chain to change something in their interfaces to get the service, unless they deliberately choose to use the added service/information. This way added functionality shouldn’t force changes to others in the chain.