Device Identification & Authentication
Download the white paperExecutive Summary
In today’s connected environment, consumers use a variety of devices (e.g., computers, tablets, mobile phones) to transact online. The consistent and reliable identification of a consumer’s device and association of that device to the legitimate consumer are key tools in creating a more secure environment for online commerce. For example, when an attempt is made to purchase from a device that has been previously used with a given merchant, and that device has a known track record of valid, approved transactions, the merchant may assign a high degree of confidence that the person attempting the purchase is truly the customer of record with the merchant. This white paper provides an overview of the data that can be collected to identify a device, the challenges of collecting that data, and methods for authenticating the consumer with EMV® 3-D Secure and network tokenization use cases.
EMV 3-D Secure (3DS) is an authentication model that leverages three domains to exchange device, transaction, and cardholder data and perform consumer authentication. The three domains are the merchant/acquirer domain, the issuer domain, and the interoperability domain. These domains exchange data and perform authentication through a set of request and response messages. The device data collected will depend on whether the transaction is performed using a browser or conducted in-app. In addition to the data collected, 3-D Secure also allows the issuer to present a challenge where the consumer may enter a one-time passcode, provide a biometric, or perform another form of authentication.
Approximately a dozen primary device data elements are collected for authentication performed in a browser, including a “Device ID.” However, the Device ID may not be consistent for all transactions with the same device. For example, if two merchants use different vendors, those vendors may generate different IDs for the same device. EMVCo has defined a set of over 150 data elements that can be collected for in-app authentication. The data elements collected will vary by operating system, and as there are multiple versions of the specification, the data elements collected can vary among implementations. Additionally, even when using the same device, the Device ID for browser-based transactions will differ from the Device ID for app-based transactions.
Network tokenization replaces a payment card’s sensitive primary account number (PAN) with a surrogate value. The underlying PAN cannot be reverse engineered from the token as there is no mathematical or logical relationship between the PAN and the token. Multiple techniques (such as cryptogram validation and domain restrictions) are used in combination to prevent the provisioning of a token to, and the use of a token by, an unauthorized party. Issuer validation and approval can help ensure tokens are only provisioned for legitimate cardholders. Network tokenization supports a number of use cases such as device tokens, card-on-file tokens, and browser tokens. Similar to EMV 3DS, the device information that can be collected varies based on the use case, and may be limited to a few or even no data elements.
Beyond the challenges of collecting device and other transaction-related data, the payments ecosystem has challenges with sharing that data. Merchants, processors, acquirers, networks, and issuers all collect data, that while useful to the entity collecting the data, would have a much greater impact on detecting and deterring fraudulent activities if the data could be shared among all of the stakeholders.
Please note: The information and materials available on this web page (“Information”) is provided solely for convenience and does not constitute legal or technical advice. All representations or warranties, express or implied, are expressly disclaimed, including without limitation, implied warranties of merchantability or fitness for a particular purpose and all warranties regarding accuracy, completeness, adequacy, results, title and non-infringement. All Information is limited to the scenarios, stakeholders and other matters specified, and should be considered in light of applicable laws, regulations, industry rules and requirements, facts, circumstances and other relevant factors. None of the Information should be interpreted or construed to require or promote the establishment of any solution, practice, configuration, rule, requirement or specification inconsistent with applicable legal requirements, any of which requirements may change over time. The Identity & Access Forum assumes no responsibility to support, maintain or update the Information, regardless of any such change. Use of or reliance on the Information is at the user’s sole risk, and users are strongly encouraged to consult with their respective payment networks, acquirers, processors, vendors and appropriately qualified technical and legal experts prior to all implementation decisions.