Authentication Interoperability

Transcription

1 Authentication and Payment Solutions DRAFT RELEASE Authentication Interoperability Verified by Visa and MasterCard SecureCode At a glance Through a series of questions and answers this fact sheet provides a brief overview of the new developments for interoperability of the online authentication protocols: 3-D Secure, CAVV, Secure Payment Application (SPA) and UCAF. GPayments Pty Ltd Pittwater Business Park Suite 8, 5 Vuko Place Warriewood NSW 2102 Australia Telephone: Facsimile: info@gpayments.com Website: Copyright 2001 by GPayments - This work is copyright. Other than as permitted by law, no part of this document may be reproduced, stored in a retrieval system or transmitted in any form or by any process without prior written permission. While GPayments has taken all reasonable care in preparing this whitepaper, the information, figures and details contained within are presented in good faith. No warranty or guarantee (express or implied) is given by GPayments as to the completeness or accuracy of the whitepaper or any information provided in connection with it.

2 Authentication Interoperability Explain the background In 1996, Visa and MasterCard attempted to introduce an Internet authentication standard, Secure Electronic Transaction (SET), to reduce online credit card fraud. Unfortunately it failed to gain critical mass in the fast growing Internet payments market and was unsuccessful. The result was an increase in online credit card fraud as ecommerce began to flourish. In November 2000, Visa formed the 3-D Secure Forum to create a new Internet authentication framework, 3-D Secure. This was a front-end solution for credit card issuers and online merchants which did not require any changes to back-end systems at credit card issuers or acquirers. 3-D Secure did not provide an end-toend security model for authenticated Internet transactions but was better than what was in the market at the time for the authentication of Internet purchases, which was nothing. In early 2001, MasterCard developed a new Internet authentication framework consisting of Secure Payment Application (SPA) and Universal Cardholder Authentication Field (UCAF). SPA was a front-end solution. UCAF was a backend solution which required changes to back-end systems at credit card issuers and acquirers. SPA and UCAF were independent of each other but formed an end-to-end security model for authenticated Internet transactions when used together. SPA was less convenient during first-time enrolment in that it required cardholders to install an applet on their PC to perform password authentication. The strengths of SPA on the front-end were security, performance and convenience during purchasing. 3-D Secure only required cardholders to have an Internet browser to perform password authentication. 3-D Secure still required an applet to be installed on the cardholder s PC for stronger forms of authentication such as chip. 3-D Secure was less focused on security, performance or convenience during purchasing. The strength of 3-D Secure password authentication was a convenient first-time enrolment process. 3-D Secure and SPA were competing approaches that were fundamentally incompatible with each other. Due to pressure from the online merchant community and reluctance to adopt two incompatible standards by credit card issuers and acquirers, Visa and MasterCard re-entered discussions on interoperability of 3-D Secure and SPA/UCAF in early As a result Visa introduced CAVV into 3-D Secure D Secure altered and placed a new emphasis on Cardholder Authentication Verification Value (CAVV). CAVV is a back-end solution which requires changes to existing systems run by credit card issuers and acquirers. When CAVV is used in conjunction with 3-D Secure it can form an end-to-end security model for authentication Internet transactions. As a result, MasterCard decided to recognize 3-D Secure for online MasterCard purchases on the front-end when 3-D Secure is used in conjunction with UCAF on 2

3 the back-end. This provides an alternative, rather than a replacement, for a transaction using a SPA applet on the front-end and UCAF on the back-end. What are the different versions of 3-D Secure? Protocol Version Release Date Status 3-D Secure 0.0 January 3, 2001 Pilot production release (basically every issuer and online merchant that was testing in a live environment until Q3 2002). 3-D Secure 1.0 May , Re-issued: June 12, 2001 Cancelled as a production release in favour of 3-D Secure D Secure November 1, 2001 Intended to be a production release but later abandoned as a production release in favour of 3-D Secure D Secure July 16, 2002 Production release designed to facilitate end-to-end security by providing a new CAVV algorithm. 3-D Secure Protocol Specifications 1.02 Minor Errata September 30, clarification and error correction points which apply to 3-D Secure and What are the different versions of SPA/UCAF? SPA and UCAF 1.00 April 3, 2001 Pilot production release UCAF and SPA 1.01 April 2, 2002 Production release SPA Algorithm for August 6, 2002 Initial draft 3-D Secure 1.00 SPA Algorithm for 3-D Secure 1.01 August 29, 2002 Updated draft SPA Algorithm for 3-D Secure 1.02 October 8, 2002 Production release What are the target dates for back-end upgrades? UCAF April, 2002 Target date for production upgrade on MasterCard Banknet CAVV April, 2003 Target date for production upgrade on Visanet (region specific) What are the target dates for liability shift from merchants? UCAF November, 2002 Merchant can shift liability if issuer is participating and cardholder is enrolled. 3-D Secure April, 2003 Merchant can shift liability regardless of whether issuer is participating or whether cardholder is enrolled. Are Visa and MasterCard creating a new authentication standard? Visa and MasterCard are not creating another new authentication standard. Visa and MasterCard are leveraging the work, which they have done over the past two years in developing 3-D Secure/CAVV and SPA/UCAF. Visa and MasterCard have now 3

4 worked out an interoperable model, which will allow 3-D Secure to work in conjunction with UCAF. Can issuers get a single Access Control Server for online authentication? Some third party vendors have already developed modular systems which support 3-D Secure and SPA in a single system for issuers. Issuers which are already using these systems will be able to upgrade to get support for SPA over 3-D Secure. These access control servers currently detect whether an authentication request originates from: a) a merchant plug-in in the case of 3-D Secure b) an applet in the case of SPA If an access control server receives a request from a merchant plug-in it will be able to detect whether it is a Visa or a MasterCard card, based upon the card number. If it is a Visa card the system will generate a CAVV and send it back to the merchant plug-in in the 3-D Secure CAVV field. The 3-D Secure transaction will continue as a 3-D Secure/CAVV transaction. If it is a MasterCard card it will generate a special Accountholder Authentication Value (AAV) and send it back to the merchant plug-in in the 3-D Secure CAVV field. The 3-D Secure transaction will continue as a 3-D Secure/UCAF transaction. If the access control server receives an authentication request from an applet, it will generate an AAV and send this back to the applet. The SPA transaction will continue as a normal SPA/UCAF transaction. Will issuers be required to store the CAVV they receive from Visanet for Visa transactions? Yes, but only in certain regions. The whole point of an end-to-end security model for an authenticated Internet transaction revolves around the ability for an issuer to create an authentication token at the time of purchase and ensure that the authentication token is not tampered with during the course of the transaction. When the issuer receives the authentication token from the merchant s acquirer they should store this for future reference in case a dispute arises over the transaction. At this time it can be compared to provide for non-repudiation. Will issuers be required to validate CAVV in real-time for Visa transactions? No. Implementing changes to issuer authorization processes to validate that the CAVV received from Visanet is the same as the CAVV that was generated and sent to the merchant plug-in is currently a costly process. Host systems are likely to provide this as standard functionality in the medium term which will make real-time CAVV validation more viable. 4

5 What is the benefit of validating CAVV in real-time for Visa transactions? The benefit is that fraudulent Internet transactions can be detected and rejected prior to authorization. What is the relationship between CAVV and the ECI indicator? The electronic commerce indicator indicates the type of online transaction performed (e.g. MOTO, Internet etc) and the security level of the transactions (e.g. using SSL, 3-D Secure etc). The CAVV not only indicates that a 3-D Secure transaction was initiated through an online channel but also provides evidence of the 3-D Secure transaction. Will issuers be required to store AAV for MasterCard transactions? The whole point of an end-to-end security model for an authenticated Internet transaction revolves around the ability for an issuer to create an authentication token at the time of purchase and ensure that the authentication token is not tampered with during the course of the transaction. When the issuer receives the authentication token from the merchant s acquirer they should store this for future reference in case a dispute arises over the transaction. At this time it can be compared to provide for non-repudiation. Will issuers be required to validate AAV in real-time for SPA over 3-D Secure transactions? No. Implementing changes to issuer authorization processes to validate that the AVV received from BankNet is the same as the AVV that was generated and sent to the merchant plug-in is currently a costly process. Host systems are likely to provide this as standard functionality in the medium term which will make real-time AVV validation more viable. What is the benefit of validating AVV in real-time for SPA over 3-D Secure transactions? The benefit is that fraudulent Internet transactions can be detected and rejected prior to authorization. Will issuers be required to validate AAV in real-time for SPA transactions? Issuers do not have to validate AAV in real-time immediately if they are prepared to take the liability shift from merchants as an interim measure. Once issuers have implemented real-time AAV validation for SPA transactions they will be able to shift liability to cardholders. Will MasterCard allow MasterCard BIN ranges to be stored in the Visa Directory? No. If MasterCard BIN ranges were stored in the Visa Directory, Visa would be able to perform data mining on the details of online MasterCard transactions. 5

6 Will MasterCard provide a MasterCard Directory Service? When is the MasterCard Directory Service likely to become available? November/December What is the current MasterCard authentication solution prior to the MasterCard Directory Service coming online? Issuers can implement SPA now using an applet. When SPA over 3-D Secure becomes available the issuer will be able to utilize both browser and applet authentication methods. Will Visa allow their Visa BIN ranges to be stored in the MasterCard Directory? No. If Visa BIN ranges were stored in the MasterCard Directory, MasterCard would be able to perform data mining on the details of online Visa transactions. Will Visa support SPA for 3-D Secure in their access control server managed services for issuers? TBA Will Visa support SPA applet authentication in their access control server managed services for issuers? Not likely. Visa have shown a reluctance to support applets for online authentication schemes such as SPA and pseudo card numbers. If 3-D Secure can work with UCAF, can SPA work with CAVV? Using an SPA applet to transfer CAVV to an SPA merchant is technically possible. However, this would require support and endorsement from Visa. Can a cardholder enroll for 3-D Secure, SPA over 3-D Secure and SPA in a single enrolment process? 6

7 Can a cardholder use an applet at their primary PC and default to browser authentication at different locations? Can a cardholder enroll for SPA over 3-D Secure and upgrade to SPA with an applet without re-enrolling? Can a cardholder use the same password with SPA over 3-D Secure and SPA with an applet? Is MasterCard dropping applets altogether? No. MasterCard has provided support for both applets and browser-based authentication mechanisms. This is a clear advantage over standard 3-D Secure which does not have support for applets beyond EMV. Use of EMV applets within 3- D Secure does not improve transaction security or performance as it still uses browser redirects as the communication method. MasterCard s support for applets provides them with a multi-tier approach to online authentication which provides additional security, flexibility and improved performance. Do applets have a future in online authentication? The answer to this question is probably best described by the answers to the following questions. Is password authentication in an applet more secure than password authentication using a browser? Is an applet required for stronger forms of authentication such as EMV chip card? Will applets be able to support other authentication schemes such as Liberty Alliance? Is applet authentication faster than browser authentication from a performance perspective? Will card companies start to look for differentiation mechanisms once the basic authentication is in place? 7

8 What does an online merchant have to do? Online merchants will be able to implement a single merchant plug-in supporting 3-D Secure , SPA and SPA Algorithm for 3-D Secure which will process 3-D Secure, SPA over 3-D Secure and SPA transactions. If a Visa card is being used for the transaction the merchant plug-in will contact the Visa Directory and initiate a 3-D Secure transaction with the issuer s access control server. The merchant plug-in will receive a CAVV from the issuer s access control server in the 3-D Secure CAVV field. If a MasterCard card is being used the merchant can detect whether an applet is present. If an applet is present the merchant plug-in will communicate with the applet and receive the AAV directly from the applet. If a MasterCard card is being used through a browser the merchant plug-in will contact the MasterCard Directory and initiate a SPA over 3-D Secure transaction with the issuer s access control server. The merchant plug-in will then receive an AVV from the issuer s access control server in the 3-D Secure CAVV field. What will the future of online authentication look like? The issue of browser or applet authentication is more of an industry issue rather than a cardholder issue. Browser authentication has not yet faced challenges such as man-in-the-middle attacks and pop-up killers which it must overcome to be successful. Both Visa and MasterCard have now attempted to simplify the basic requirements for online authentication so that issuers and merchants will be inclined to implement the standards sooner rather than later. Once the basic infrastructure is in place the main issues of security and usability will start to emerge. What solutions does GPayments provide? ActiveAccess: A modular access control server for issuers supporting 3-D Secure and SPA. Support for SPA over 3-D Secure will be available soon. ActiveMerchant: A merchant plug-in supporting 3-D Secure and SPA. Support for SPA over 3-D Secure will be available soon. ActiveCheckout: An applet that supports SPA, for distribution to online cardholders. 8