Innovative Phishing-Resistant Cardholder Authentication and Payment Confirmation Method
Introducing a method for cardholder authentication and secure payment confirmation that is phishing-resistant, requires no interaction with the issuing bank at transaction time, and provides merchants with a non-repudiable cryptographic signature on transactions. This innovative approach leverages the Service Worker API of the W3C, offering simplicity, enhanced security, and ease of implementation compared to existing methods like 3DS2 and SPC.
- Phishing-Resistant
- Cardholder Authentication
- Payment Confirmation
- Innovative Method
- Secure Transactions
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Cardholder Authentication and Cardholder Authentication and Payment Confirmation without Payment Confirmation without Interaction with the Issuing Bank Interaction with the Issuing Bank Francisco Corella fcorella@pomcor.com
Strong cardholder authentication is still an open problem 3-D Secure 2 (3DS2) was introduced in 2016 but has not yet been deployed at scale The EBA opinion of 23 June 2022 decries unprecented delays in the implementation of the SCA requirement of PSD2 3DS2 will not provide phishing resistance The same EBA opinion notes that further improvements in the legal framework are needed to address phishing attacks The Secure Payment Confirmation (SPC) protocol being developed by the World Wide Web Consortium (W3C) provides phishing resistance, but it requires the issuing bank to delegate credential access to the merchant, and hence prior relationship between the merchant and the bank All solutions being considered require the issuing bank to interact with the merchant for every transaction, which puts a high burden of availability and performance on the bank
We propose a method of cardholder authentication and secure payment confirmation that Is phishing-resistant Requires no interaction between the issuing bank and the merchant at transaction time Provides the merchant with a non-repudiable cryptographic signature on the transaction Is simpler, more secure, and easier to implement and deploy than 3DS2 and SPC
We achieve all this by making innovative use of the well-known Service Worker API of the W3C 1. The cardholder gets a credit card certificate from the web site of the issuing bank with a single click 2. The JavaScript front-end of the bank registers a Service Worker with the browser 3. At transaction time the merchant sends a payment confirmation request to a URL within the domain of the issuing bank, but the request is intercepted in the browser by the service worker 4. The service worker responds to the request with a page that asks the cardholder for confirmation 5. The page signs the confirmation with the private and sends the signature and the credit card certificate to the merchant
Practical considerations There is no need for the credit card certificate to be revocable, since the credit card is revocable. There is no need for the credit card networks to be involved in the development or deployment of cardholder authentication. Banks could form a consortium for the purpose of maintaining a public database mapping the IIN of each bank to the URL to be used for sending the confirmation request and the public key to be used for verifying the credit card certificate. Any merchant could obtain transaction confirmations by using the public database to look up URLs and public keys, and using open software to verify transaction certificate signatures, without having to register with the consortium.
Open question I have a demo that stores the certificate and its private key in localStorage Could the cryptographic credential be carried in an unmodified FIDO2 authenticator and accessed via the unmodified WebAuthn API? The private key would be resident or exported as the credential ID The certificate would be stored in a largeBlob The description of the transaction would be used as the WebAuthn challenge Two difficulties WebAuthn doesn t sign the challenge. It signs a complex data structure containing the challenge, which has to be validated as part of the authenticator response The user experience of payment confirmation would have to be different than the user experience of web authentication
The difficulties might be solvable The data structure could be broken up into pieces The pieces other than the challenge could be combined with the cryptographic signature and viewed as an extended, FIDO-specific, signature A verification function for the extended signature could be provided to the merchant The merchant would not have to validate the authenticator response and the authentication user experience would have to be modified for payment confirmation
Collaboration proposal I have started working on this I would welcome collaborators with deep knowledge of authenticators and WebAuthn Pomcor has been granted a patent family comprising US patents 10,825,025 and 11,263,638 on cardholder authentication and payment confirmation that I would be happy to license to collaborators
