Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
- Adding a device to the list of authorized devices (“something you have”)
- Adding an account to the list of authorized accounts — if I have a wallet application and I want to add access to my bank account.
Alternatively, PSUs and TPPs could be allowed to offer behaviour-based characteristics authentication methods on an opt-in basis and where they assume the risk.
Secondly, and most importantly, the EBA should allow digital signatures on a payment authorization to satisfy any “dynamic code” requirement. Digital signatures are orders of magnitude safer than dynamic codes and they also provide non-repudiation A properly designed payment system should never have dynamic codes, but should rely exclusively on digital signatures. The PSD2 legislation omits any reference to digital signatures which is disappointing. Digital signatures should always be an alternative to using dynamic codes as it is more secure and provides a better customer experience.
Finally, we prefer to specify “end-to-end security”. Payments should be secure all the way from the PSU to the payee in order to to greatly reduce fraud. Dynamic codes is a poor choice in this regard as they do not meet the end-to-end security requirement. The way to achieve an end-to-end secure payment system is by using digital signatures.
In our opinion, systems that are end-to-end secure and completely eliminate the use of any shared secrets should be the goal and any system that meets that goal should not be required to employ methods such as traditional dynamic codes that simply add friction and discourage use.
The test is simple: if an attacker steals my phone, what are the chances he can successfully complete a 2FA transaction? If the answer is very low (such as 1 in 10000), we consider it safe. OneID is an example of an identity/authorization system that meets this test.
In summary, the use of dynamic codes on a mobile phone is arguably a one-factor solution. However, there are ways to create 2 factors on a mobile phone such as the technique described above.
For example, if a PSU is annoyed at the low euro limits for 2FA, and they are willing to accept the risk of loss, they should be permitted to change the limit as long as they are warned of the risk they are accepting. From our research, many PSUs are willing to opt-in to a higher limit.
Another way to approach this issue is to look at transaction fraud rates. If it is below a certain threshold, then you may allow a PISP to be exempt from 2FA. It’s better to focus on the goal (minimize fraud) rather than over prescribe how it should be done. Therefore, an exemption if you can meet a very low fraud rate would be a good as it would provide great flexibility and innovation while still achieving the goal of high security.
There is no need to share login credentials any more. Modern technology provides alternative approaches that are far more secure and convenient. We recommend consideration of a security model based on “digitally secured identity”, where each participant has an identity (some form of universal identifier) that can be publicly known by all parties, and has associated with it a set of private/public cryptographic keys. Under this approach, transaction between parties is established using the parties’ identities, and verified using digital signature technology.
In our system, we have eliminated the use of shared secrets. There are no shared payment credentials; only public keys are exchanged. This not only creates an improved user experience, but it is also incredibly secure.
For example, if a PSU wants to add a new bank account to her PISP, she sends her public key to the bank and approves it in her banking app. The PISP never learns the PSU’s bank login. Anyone can listen in on the transaction and there is no harm. It is end-to-end secure. The PISP cannot initiate a payment that the PSU didn’t authorize. It is very safe.
Similarly, any approach in which a TPP stores “bearer security tokens” must be avoided, as that database could be compromised leading to a potential attack on all the underlying accounts.
In general, use of oauth tokens, API keys, etc. are all shared secrets, insecure and should be avoided, or at a minimum be noted as highly undesirable.
This satisfies multiple goals: only the user will be able to initiate transactions under the user’s identity, and the larger community can now securely interact with that user without requiring any sharing of PSC, such as email/password.
Token is an example of what we are suggesting. Token has designed a system whereby the PISP can access a PSU’s bank accounts to make payments but the PISP cannot change the instructions approved by the user. This eliminates the need to certify PISPs all together, because PISPs cannot change transactions or reveal any secrets.
- place of entry
- place of storage
- place of verification
- use of and storage of API keys and oauth tokens
These risks can be eliminated by eliminating the use of shared secrets and digitally signing all API requests. This is what Token’s system does and it is what bitcoin does.
With bitcoin, there are no mass breaches or theft despite the fact that there are no rules comparable to PCI and there are no certifications.
With the right system architecture, there is no need to certify PISPs or be concerned about these places of compromise. The APIs can be fully open without risk because the key secure pieces are all locked down.
It may be helpful and efficient while developing a to f for EBA to get a briefing on how Token works because it is an advanced, secure architecture for payments. As a to f is developed, EBA does not want to overspecify the requirements in such a way that innovative, award-winning solutions such as ours are forced to “dumb down” the security to meet requirements based on old-fashioned security methodologies.
b) Token recommends that all parties including PISPs and AISPs identify themselves to other parties via a common cryptographically-secure identity mechanism. If all incoming calls to an ASPSP must be signed by a private key owned by the TPP, then the ASPSP can ensure that the requests are legitimate and non-repudiable. For example, each payment transaction can be linked directly to a PISP “payment instruction” that can only have been issued by that PISP. This technical foundation is both strong and flexible, mandating only the minimum commonality for parties to communicate securely and reliably. It does not, for example, define or restring the actual type or function of specific API calls.
c) Again, Token recommends that a common, simple and secure communication protocol should be standard. In the context of digitally-signed API calls, simple & secure communications can be done using HTTPS connections on the Internet, a common technology available to all parties.
d) This section is addressing the next level of “commonality” of standards and practices: whether there should be standards for the actual functional operations of the APIs and the data formats that will be used. It will be beneficial to all parties if minimum standards can be established for the types and formats of common data (e.g. ASPSP accounts, transaction lists, etc.) Guidance on the semantics of key transaction types (e.g. all payment transactions are “good funds” and non-reversible) across all possible APIs is needed.
e) Token feels this is the key to the whole framework. The use of digital signatures as a foundation will eliminate many of the greatest sources of fraud, as well as providing a digital record for each transaction including the non-repudiable signature of the initiating party.
f) The EBA specification of the minimum standards for identity, security, communication can provide a basic framework for interoperability between TPPs and ASPSPs, even if individual ASPSPs provide their own proprietary specific APIs. EBA should consult with industry to determine how far down the “common standard” should extend, keeping in mind the balance between the benefits of interoperability and the inhibition of innovation
In general, having technical standards that are advisory in nature (“should” do), rather than prescriptive (“shall” and “must” do) eliminate most of the risk of being too prescriptive.
It might be helpful to separate out the guidance by system type. For example, Token is a client-server system that was architected to be end-to-end secure and eliminates the use of shared secrets. For systems like this, less regulation is required. Bitcoin is an example of this in practice...the secure architecture of the system meant that no standards had to be mandated on users. Bitcoin, like Token, is a true open API...anyone can call the API...you do not have to be certified. That is the right approach and one that the EBA should recommend.
In general, an API that requires qualification and certification of the users of the API, is a system that will not be secure. For example, payment cards: Very insecure, the API is tightly controlled, and you have to be PCI compliant to use the API. Token and bitcoin are the opposite. Anyone can use the API and the systems are virtually unbreakable and no standards for the users of the SDK are required.
We also recommend the use of standard API infrastructure, such as the use of the HTTPS protocol and RESTful API framework to help ensure interoperation and easy adoption. Note that this is not a requirement that all parties implement the same API, just that all APIs be expressed in the context of a common framework, a common communications technology, and a common identity/security model.
Again, Bitcoin is a good example. The transactions are public, yet private and no PSP-like standards had to be created.
Token is developed in a similar vein, but was designed by bankers to work seamlessly with banks, use the bank’s own ledger, and provide transaction privacy (there is no public ledger), and each transaction is digitally signed using private keys controlled by the bank but stored on user devices in a way inaccessible to the bank and other PSPs.
- cryptographically-secured identity system for all parties
(says nothing about communication protocols, just how parties identify each other)
- digitally-signed transactions between parties
(again, nothing about transport, data formats, specific API elements, just verification)
- communication via near-real-time API calls between systems
(defining system-to-system access method, nothing about data formats API structure)
- communication via RESTful APIs - use of standard HTTP protocol. JSON data representation
(defines common API engagement model, not what specific APIs offer)
- standard JSON data formats for shared items (e.g. account info, transaction history)
(enables limited interoperability among independently-defined APIs)
- enumeration of minimum required set of operations for each party:ASPSP, PISP, AISP
(not specific API definitions, detailing arguments, etc.)
- detailed definition of a specific minimum API supported by all parties
Again, Token doesn’t endorse the concept of the use of the ASPSP’s PSC by other parties. Schemes that rely on third party access to PSC and storage of “bearer tokens”. Digital signature verification can be used to confirm that a request made by a ASPSP user at a PISP is genuine.
But we shouldn’t preclude the use of even stronger approaches.
At Token we are developing something similar, but with no central infrastructure; all the signing is on the user’s device so it is end-to-end secure and there is no use of SAML. SAML is problematic because the SAML server is a man in the middle, vulnerable to attacks.
The benefits of Token’s approach are:
- no central server
- no SAML
- end-to-end secure for all banks
- does not use PKI (PKI isn’t end-to-end secure because the certificate-authority (CA) can be compromised)
- Uses Ed25519 signatures which are much safer and simpler than earlier crypto like ECDSA and RSA used in other systems.
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.
There are two additional cases:- Adding a device to the list of authorized devices (“something you have”)
- Adding an account to the list of authorized accounts — if I have a wallet application and I want to add access to my bank account.
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?
A possession element can be data such as a private key used to create a digital signature. For example, I can have a browser with a private key stored in my browser’s local storage. That is data and can be used to uniquely identify my device. It is not known to the user. This model was used at OneID and has never been cracked.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?
Behaviour-based characteristics methods are problematic as they are subjective and subject to attack. They are not suitable for strong authentication where any factor should be deterministic. In general, Token suggests that each “factor” should have a 1 in 1000 rate of false positive/false negatives. That way, with 2 factors, the chance of an attack would be 1 in 1 million. Token recommends that behaviour-based characteristics methods are optional and used in addition to 2FA, but not as a factor themselves.Alternatively, PSUs and TPPs could be allowed to offer behaviour-based characteristics authentication methods on an opt-in basis and where they assume the risk.
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)?
While mobile phones can be attacked that compromise more than one factor, these attacks are hard and very rare and are becoming more rare over time as mobile phone vendors tighten their security. Mobile phones are no different than MFA on a laptop or desktop. More important is to answer the opposite question which is “Is 2FA satisfied if the user confirms a push notification on a normally locked phone?” It is absolutely critical that the answer to this question be “Yes” because the only possible way to confirm such a notification is by possession and knowledge of the unlock code or a fingerprint. We strongly recommend that the guidance be limited to “two factors are required” and leave any additional security recommendations as advisory, rather than mandatory.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
A PSU should be able to create a “payment authorization” that lets a service provider (e.g., Spotify) to pull up to some pre-approved amount, e.g., €10 per month directly from account at the PSU’s ASPSP. This authorization should be able to be created directly by the PSU, instantly, and without any “legal authorization” needed. The underlying identity and security technology should enable the user to create such an authorization with no fear that anyone but the designated payee can access funds. In this case, the “dynamic linking” should only be required at the time of creation of the authorization, not every time a payment is made.Secondly, and most importantly, the EBA should allow digital signatures on a payment authorization to satisfy any “dynamic code” requirement. Digital signatures are orders of magnitude safer than dynamic codes and they also provide non-repudiation A properly designed payment system should never have dynamic codes, but should rely exclusively on digital signatures. The PSD2 legislation omits any reference to digital signatures which is disappointing. Digital signatures should always be an alternative to using dynamic codes as it is more secure and provides a better customer experience.
Finally, we prefer to specify “end-to-end security”. Payments should be secure all the way from the PSU to the payee in order to to greatly reduce fraud. Dynamic codes is a poor choice in this regard as they do not meet the end-to-end security requirement. The way to achieve an end-to-end secure payment system is by using digital signatures.
In our opinion, systems that are end-to-end secure and completely eliminate the use of any shared secrets should be the goal and any system that meets that goal should not be required to employ methods such as traditional dynamic codes that simply add friction and discourage use.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
OneID is a great example of a system that provides independence. If an attacker got possession of my phone and could unlock it, he would still be unable to perform two-factor authentication with it because the phone credentials would be disabled after a few PIN entry attempts. Because of the unique design of OneID , the PIN cannot be brute force calculated as the PIN is not a shared secret; it is hashed with a private salt to form a private key which is then used to sign a challenge to prove knowledge.The test is simple: if an attacker steals my phone, what are the chances he can successfully complete a 2FA transaction? If the answer is very low (such as 1 in 10000), we consider it safe. OneID is an example of an identity/authorization system that meets this test.
In summary, the use of dynamic codes on a mobile phone is arguably a one-factor solution. However, there are ways to create 2 factors on a mobile phone such as the technique described above.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, well done. In addition, we believe that you should allow more flexibility in the exemptions that can be applied for. For example, Token uses a push notification that can only be confirmed if the PSU has possession of the phone and knows the unlock code (or fingerprint). It may appear as one factor, but is clearly two-factor. The key test for an exemption is whether the method being proposed can be shown (or argued) to be equal to requiring at least 2 factors.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
The EBA should consider issuing guidelines that encourage PSPs to allow the user to select their own “risk tolerance” within the mandatory limits set by any regulation. That is, if there is some mandatory limit such as “payments over €100 must be confirmed using two independent elements from two different categories”, PSPs should allow users to define their own threshold: “I require my PSP to obtain two-factor authorization for any payment over €150. The regulations should consider under what conditions individual PSUs could “opt in” to higher limits if they so desire.For example, if a PSU is annoyed at the low euro limits for 2FA, and they are willing to accept the risk of loss, they should be permitted to change the limit as long as they are warned of the risk they are accepting. From our research, many PSUs are willing to opt-in to a higher limit.
9. 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?
Risk analysis requires the collection of data that may not be compatible with privacy regulations. Real-time risk analysis introduces latency and may negatively impact customer experience. Batch processing of risk analyses should be sufficient. Upon authentication, lookup to see if the PSU has the “risk flag” set in which case strong customer authentication should be required.Another way to approach this issue is to look at transaction fraud rates. If it is below a certain threshold, then you may allow a PISP to be exempt from 2FA. It’s better to focus on the goal (minimize fraud) rather than over prescribe how it should be done. Therefore, an exemption if you can meet a very low fraud rate would be a good as it would provide great flexibility and innovation while still achieving the goal of high security.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Token strongly believes that the EBA regulations for identity and security should completely eliminate the use of “shared secrets”. That is, any scheme that relies on one party having a persistent “secret” (such as a password or account number) that must be kept secret from the world at large, but must be provided to a partner in order to initiate a transaction. Storage and management of shared secrets in the financial industry is the source of fraud and identity theft and mass breaches.There is no need to share login credentials any more. Modern technology provides alternative approaches that are far more secure and convenient. We recommend consideration of a security model based on “digitally secured identity”, where each participant has an identity (some form of universal identifier) that can be publicly known by all parties, and has associated with it a set of private/public cryptographic keys. Under this approach, transaction between parties is established using the parties’ identities, and verified using digital signature technology.
In our system, we have eliminated the use of shared secrets. There are no shared payment credentials; only public keys are exchanged. This not only creates an improved user experience, but it is also incredibly secure.
For example, if a PSU wants to add a new bank account to her PISP, she sends her public key to the bank and approves it in her banking app. The PISP never learns the PSU’s bank login. Anyone can listen in on the transaction and there is no harm. It is end-to-end secure. The PISP cannot initiate a payment that the PSU didn’t authorize. It is very safe.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Token believes that any approach that requires the sharing of PSC between organizations must be avoided. For example, requiring a PSU to verify their identity at a TPP by entering the PSC for their AS-PSP is fundamentally insecure. The TPP could capture the PSC, could store them insecurely, opening the user and the AS-PSP to risk.Similarly, any approach in which a TPP stores “bearer security tokens” must be avoided, as that database could be compromised leading to a potential attack on all the underlying accounts.
In general, use of oauth tokens, API keys, etc. are all shared secrets, insecure and should be avoided, or at a minimum be noted as highly undesirable.
12. 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?
Yes, Token has developed an innovative method for enrolment that we’d be happy to share privately with the EBA. It is simple for PSUs to use, and does not use any shared credentials or secrets. It is all done by exchanging a public key for a token, but the token is not a shared secret — it can be freely disclosed without harm.This satisfies multiple goals: only the user will be able to initiate transactions under the user’s identity, and the larger community can now securely interact with that user without requiring any sharing of PSC, such as email/password.
13. 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?
The alternative is to use a security model that doesn’t rely on “shared secrets”. PCI-style requirements have proven costly and ineffective as has been demonstrated too many times at mass breaches.Token is an example of what we are suggesting. Token has designed a system whereby the PISP can access a PSU’s bank accounts to make payments but the PISP cannot change the instructions approved by the user. This eliminates the need to certify PISPs all together, because PISPs cannot change transactions or reveal any secrets.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Typical risk points include:- place of entry
- place of storage
- place of verification
- use of and storage of API keys and oauth tokens
These risks can be eliminated by eliminating the use of shared secrets and digitally signing all API requests. This is what Token’s system does and it is what bitcoin does.
With bitcoin, there are no mass breaches or theft despite the fact that there are no rules comparable to PCI and there are no certifications.
With the right system architecture, there is no need to certify PISPs or be concerned about these places of compromise. The APIs can be fully open without risk because the key secure pieces are all locked down.
15. 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?
We believe that topics (a to f) are a good statement of the issues to be clarified and addressed. The EBA has identified the key tension between broad interoperability through mandated standards and the independence of action and freedom to innovate through weaker “guidelines”.It may be helpful and efficient while developing a to f for EBA to get a briefing on how Token works because it is an advanced, secure architecture for payments. As a to f is developed, EBA does not want to overspecify the requirements in such a way that innovative, award-winning solutions such as ours are forced to “dumb down” the security to meet requirements based on old-fashioned security methodologies.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
a) no opinion on specific definitions of common and openb) Token recommends that all parties including PISPs and AISPs identify themselves to other parties via a common cryptographically-secure identity mechanism. If all incoming calls to an ASPSP must be signed by a private key owned by the TPP, then the ASPSP can ensure that the requests are legitimate and non-repudiable. For example, each payment transaction can be linked directly to a PISP “payment instruction” that can only have been issued by that PISP. This technical foundation is both strong and flexible, mandating only the minimum commonality for parties to communicate securely and reliably. It does not, for example, define or restring the actual type or function of specific API calls.
c) Again, Token recommends that a common, simple and secure communication protocol should be standard. In the context of digitally-signed API calls, simple & secure communications can be done using HTTPS connections on the Internet, a common technology available to all parties.
d) This section is addressing the next level of “commonality” of standards and practices: whether there should be standards for the actual functional operations of the APIs and the data formats that will be used. It will be beneficial to all parties if minimum standards can be established for the types and formats of common data (e.g. ASPSP accounts, transaction lists, etc.) Guidance on the semantics of key transaction types (e.g. all payment transactions are “good funds” and non-reversible) across all possible APIs is needed.
e) Token feels this is the key to the whole framework. The use of digital signatures as a foundation will eliminate many of the greatest sources of fraud, as well as providing a digital record for each transaction including the non-repudiable signature of the initiating party.
f) The EBA specification of the minimum standards for identity, security, communication can provide a basic framework for interoperability between TPPs and ASPSPs, even if individual ASPSPs provide their own proprietary specific APIs. EBA should consult with industry to determine how far down the “common standard” should extend, keeping in mind the balance between the benefits of interoperability and the inhibition of innovation
In general, having technical standards that are advisory in nature (“should” do), rather than prescriptive (“shall” and “must” do) eliminate most of the risk of being too prescriptive.
It might be helpful to separate out the guidance by system type. For example, Token is a client-server system that was architected to be end-to-end secure and eliminates the use of shared secrets. For systems like this, less regulation is required. Bitcoin is an example of this in practice...the secure architecture of the system meant that no standards had to be mandated on users. Bitcoin, like Token, is a true open API...anyone can call the API...you do not have to be certified. That is the right approach and one that the EBA should recommend.
In general, an API that requires qualification and certification of the users of the API, is a system that will not be secure. For example, payment cards: Very insecure, the API is tightly controlled, and you have to be PCI compliant to use the API. Token and bitcoin are the opposite. Anyone can use the API and the systems are virtually unbreakable and no standards for the users of the SDK are required.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
The use of cryptographically-secured identity provides strong foundation of secure interoperability between systems, even those supporting different APIs. Such an identity scheme maximizes privacy, as it requires no sharing of PSU personal information (including PSCs) between parties, and yet allows every ASPSP to verify that any payment or information-access request from a TPP was approved or initiated by the specific authorized user.We also recommend the use of standard API infrastructure, such as the use of the HTTPS protocol and RESTful API framework to help ensure interoperation and easy adoption. Note that this is not a requirement that all parties implement the same API, just that all APIs be expressed in the context of a common framework, a common communications technology, and a common identity/security model.
Again, Bitcoin is a good example. The transactions are public, yet private and no PSP-like standards had to be created.
Token is developed in a similar vein, but was designed by bankers to work seamlessly with banks, use the bank’s own ledger, and provide transaction privacy (there is no public ledger), and each transaction is digitally signed using private keys controlled by the bank but stored on user devices in a way inaccessible to the bank and other PSPs.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
As with most such systems, the standards should be defined as a set of layers, each responsible for its own, independent aspect of the total standard. For example, a bottom-to-top standard might look something like the following. The EBA and industry could discuss how far down the stack a standardization effort should go. The further down, the easier for all parties to interoperate.- cryptographically-secured identity system for all parties
(says nothing about communication protocols, just how parties identify each other)
- digitally-signed transactions between parties
(again, nothing about transport, data formats, specific API elements, just verification)
- communication via near-real-time API calls between systems
(defining system-to-system access method, nothing about data formats API structure)
- communication via RESTful APIs - use of standard HTTP protocol. JSON data representation
(defines common API engagement model, not what specific APIs offer)
- standard JSON data formats for shared items (e.g. account info, transaction history)
(enables limited interoperability among independently-defined APIs)
- enumeration of minimum required set of operations for each party:ASPSP, PISP, AISP
(not specific API definitions, detailing arguments, etc.)
- detailed definition of a specific minimum API supported by all parties
Again, Token doesn’t endorse the concept of the use of the ASPSP’s PSC by other parties. Schemes that rely on third party access to PSC and storage of “bearer tokens”. Digital signature verification can be used to confirm that a request made by a ASPSP user at a PISP is genuine.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Yes, it’s one approach. A good example is BankID in Sweden.But we shouldn’t preclude the use of even stronger approaches.
At Token we are developing something similar, but with no central infrastructure; all the signing is on the user’s device so it is end-to-end secure and there is no use of SAML. SAML is problematic because the SAML server is a man in the middle, vulnerable to attacks.
The benefits of Token’s approach are:
- no central server
- no SAML
- end-to-end secure for all banks
- does not use PKI (PKI isn’t end-to-end secure because the certificate-authority (CA) can be compromised)
- Uses Ed25519 signatures which are much safer and simpler than earlier crypto like ECDSA and RSA used in other systems.