PCI Watch

Tracking changes across the Payment Card Industry

EMVCo CDCVM Solution ID and Database Use cases

v1.0
Mobile

CDCVM Solution ID and Database Use cases

Introduction

The purpose of this document is to illustrate how the CDCVM Solution ID may be used as an aid to understanding the area. EMVCo does not define the use cases, and this is not an exhaustive list. The use cases in this document describe a hypothetical CDCVM Solution ID database and a set of hypothetical use cases for how entries in the database may be used. Actual usage of identifiers is not being defined by EMVCo and all usage of these identifiers is implementation dependent. Database The following table contains a sample set of entries in the CDCVM Solution ID database. CDCVM solution identifier Solution description Type Sensor Operating System 1 Generic OEM_I fingerprint Fingerprint Fingerprint I_OS 2 Generic OEM_I facial Facial Camera I_OS 7 Generic OEM_I CDCVM All Multiple I_OS 3 Generic Platform_A fingerprint Fingerprint Fingerprint A_OS 4 Generic Platform_A unlock Passcode / Keyboard / A_OS passcode/password Password Touchscreen 5 Generic Platform_A unlock Pattern Touchscreen A_OS pattern 8 Generic Platform_A CDCVM All Multiple A_OS 6 Wearable_F passcode Passcode Touchscreen F_OS 9 Wallet_S Passcode Passcode Touchscreen A_OS 10 Flagship OEM_S Iris Iris Camera A_OS 11 Generic Platform_A biometric biometric unknown A_OS Managing the database The following is a set of use cases describing how entries in the database could be managed:

  • Registered vendors add their CDCVM solution information to the database and each solution is assigned a CDCVM solution identifier. In the above example database:
  • A platform provider has registered with EMVCo and has added a number of CDCVM solutions supported by their platform and has been assigned identifiers 3, 4, 5 and 8.
  • A wearable OEM has registered with EMVCo and has added the single CDCVM solution supported by their product and has been assigned identifier 6.
  • An OEM has registered with EMVCo and added an OEM specific CDCVM solution supported by their flagship product and has been assigned identifier 10. This same registered OEM also has an OEM specific wallet that itself supports a wallet CDCVM which they have also added and has been assigned an identifier of 9.
  • A registered vendor updates one of their CDCVM solution entries. For example, a previously registered CDCVM solution has received a certificate of security evaluation or FIDO Biometric certification.
  • Registered vendor/EMVCo updates CDCVM solution entry to indicate that the solution has been identified as being susceptible to attack or is no longer in use.
  • EMVCo secretariat adds generic CDCVM solution information to the database and each solution is assigned a CDCVM solution identifier. In the above example database, for a vendor that has not registered [or does not wish to register] with EMVCo, the secretariat in consultation with the CDCVM TF has added entries and each of these solutions has been assigned identifiers 1, 2 and 7. Accessing the database Registered Token Service Providers and Issuers may periodically download the full database and maintain a database mirror. Usage of identifiers Use case 1 – The CDCVM solution identifier is available to mobile applications through the platform level APIs When checking whether consumer authentication has occurred, or prompting for consumer authentication, the platform APIs return the CDCVM solution identifier of the solution used to authenticate the consumer. For example, a wallet that uses the same fingerprint (1, 3) used to unlock the device to also authorize contactless transactions. Use case 2 – A single CDCVM solution identifier is hardcoded in the mobile application The solution provider hardcodes a single CDCVM solution identifier into their mobile application. For an example, a wallet on a wearable that uses a single passcode (6) to authorize contactless transactions. Use case 3 – Multiple CDCVM solution identifiers are hardcoded in the mobile application The solution provider hardcodes multiple CDVM solution identifiers into their mobile application. For example, a wallet on a mobile device that uses either fingerprint used to unlock the device (3) or a passcode (9) to authorize contactless transactions. Use case 4 – Multiple device specific CDCVM solution identifiers are hardcoded in the mobile application The solution provider hardcodes multiple device specific CDCVM solution identifiers into their mobile application. During installation the mobile application can recognize device characteristics and configure the correct identifier(s) for subsequent actions. For example, a wallet can recognize that it is being installed on a flagship device from OEM_S and will use iris (10) to authorize contactless transactions. If the wallet cannot recognize the specific device but can determine that the device supports fingerprint it will use fingerprint (3) to authorize contactless transactions. Use case 5 – Multiple CDCVM solution identifiers are managed by the solution provider and are configured to the mobile application during installation and setup of the mobile application This is a variant of the above use cases (3 and 4), where the wallet will return device information to the solution provider and the solution provider will indicate which identifier(s) should be used. Use case 6 – CDCVM solution identifiers are set during transaction processing. During provisioning and based on device, wallet, solution provider information received by the Token Service Provider/Issuer, a determination can be made as to the most likely CDCVM solutions that will be used to authorize transactions. These CDCVM solution identifiers can be linked to the token by the Token Service Provider. For example, when a token is being provisioned to a Wallet_S solution, the Token Service Provider can make the determination that one of the CDCVM solutions that will be used is a wallet passcode (9). Additionally, if the Token Service Provider receives information that the wallet is installed on a flagship device from OEM_S it can also make the determination that another CDCVM solution that will be used is iris (10). Use case 7 – Provisioning During provisioning, the wallet can indicate [or a determination can be made as to] which CDCVM solution identifier(s) will be used to authorize payment on the device. (i) The Token Service Provider/Issuer can make a determination based on the identifier(s) as to whether the credentials should be provisioned to the device. For example, an issuer may have a rule that does not allow a token to be provisioned to a wallet that does not support a biometric mechanism for authorizing a transaction. (ii) Based on the identifier(s), the Token Service Provider/Issuer can indicate that the token being provisioned cannot be used with a subset of the CDCVM solutions. For example, an issuer may indicate to a wallet that supports both a passcode and a biometric, that transactions can only be authorized with the biometric and not with the passcode. (iii) The Token Service Provider/Issuer can store the identified CDCVM solution identifier(s) along with the token. For example, if the Token Service Provider/Issuer is aware that CDCVM solution identifiers are not provided during transaction processing. Use case 8 – Payment messages containing CDCVM solution identifiers. (i) During payment, the wallet will follow payment system guidance to include the CDCVM solution identifier in the relevant transaction messages. On receipt of the transaction messages, the Token Service Provider and Issuer can make a determination based on this identifier as to whether the transaction should be authorized or not. For example, in conjunction with other risk factors, an issuer may decide to decline a transaction that was authorized with a CDCVM solution that is known to be compromised. (ii) During payment, a Token Service Provider/Issuer may indicate that the CDCVM solution used is not sufficient to authorize the transaction and another CDCVM solution should be used to authorize the transaction. For example, in a 3DS like transaction, if a passcode was initially used to authorize a high value transaction and the issuer is aware that a biometric is also present on the device being used, the issuer can indicate that the biometric should be used. Use case 9 – Payment messages not containing CDCVM solution identifiers. During payment, if the CDCVM solution identifier is not present in the transaction message, the Token Service Provider/Issuer can use a stored or derived CDCVM solution identifier to make a determination based on this identifier as to whether the transaction should be authorized or not. For example, in conjunction with other risk factors, an issuer may decide to decline a transaction that was authorized on a device type that is known to be compromised. Use case 10 – Post transaction monitoring This is a derivative of use cases 8(i) and 9 above where the Token Service Provider or issuer can do post transaction analysis to monitor for suspicious behavior based on the CDCVM solution identifier(s) used.