2007 11 - emv mobile contactless payment technical issues version 1.0 final

EMV Mobile Contactless Payment Technical Issues and Position Paper

Version 1.0 October 2007

EMV Mobile Contactless Payment Technical Issues and Position Paper

Version 1.0 October 2007

© 1994-2007 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Specifications (“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at http://www.emvco.com/specifications.cfm.


Contents 1 Introduction......................................................................................................... 1

1.1 Document Purpose and Scope...................................................................... 1

1.2 References..................................................................................................... 2

1.3 Definitions .................................................................................................... 2

1.4 Mobile Device Architecture.......................................................................... 4

1.4.1 Logical Architecture .............................................................................. 4

1.5 Proximity Payment Architecture................................................................. 6

1.6 Implementation Options for the Secure Element....................................... 7

1.6.1 Embedded Hardware Secure Element ................................................. 8 1.6.2 Secure Element on UICC ...................................................................... 8 1.6.3 Removable Hardware Secure Element................................................. 8 1.6.4 Secure Element in Mobile Device Baseband Processor....................... 8

2 Provisioning and Personalization ...................................................................... 9

2.1 Introduction .................................................................................................. 9

2.2 Possible Options for Device Provisioning and Personalisation.................. 9

2.3 Provisioning and Personalisation of the Secure Element ........................ 10

2.3.1 Embedded Hardware SE..................................................................... 10 2.3.2 SE on UICC.......................................................................................... 10 2.3.3 Removable Hardware Security Element............................................ 11 2.3.4 SE in baseband processor.................................................................... 11 2.3.5 Summary.............................................................................................. 11 2.3.6 Separation of Provisioning and Personalisation................................ 12 2.3.7 Pre-distribution personalization......................................................... 12

2.4 Post-distribution Payment Application Provisioning Process Issues...... 12

2.4.1 Payment Application / Credentials Installation Process................... 12 2.4.2 Update of Payment Application and Credentials .............................. 14 2.4.3 Payment Application and Credentials Deletion ................................ 15 2.4.4 Device Change with Embedded Secure Element............................... 16 2.4.5 Device Change with Removable Secure Element .............................. 16 2.4.6 User Interface Application Provisioning............................................ 17

3 Customer Care .................................................................................................. 19

4 Usability ............................................................................................................ 21

4.1 Introduction ................................................................................................ 21

4.2 Transaction Experience Usability Issues.................................................. 21

4.2.1 User Authentication / Cardholder Verification.................................. 21 4.2.2 Multiple payment applications on single device................................ 22 4.2.3 Payment Credential Selection Process............................................... 23 4.2.4 Payment Credential Availability with Device Off ............................. 24

October 2007 © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. Page iii


4.3 Branding .....................................................................................................26

4.3.1 Branding via the User Interface.........................................................26

Page iv © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. October 2007


Tables

Table 1 Summary of Provisioning and Personalization Options for Secure Elements 11

October 2007 © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. Page v


Figures

Figure 1: Logical Architecture of a Mobile Device 4 Figure 2: Example implementation of logical interfaces 5 Figure 3: Another example implementation of logical interfaces 6 Figure 4: Mobile Contactless Payment Architecture 7

October 2007 © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. Page vii


1 Introduction

1.1 Document Purpose and Scope The increased deployment of contactless payment infrastructure, combined with the increased interest in adding contactless capability to mobile devices leads to the natural combination of contactless payment in mobile devices. This document sets out the EMVCo position on technical issues related to implementing contactless payment in a mobile device. The document identifies technical issues and the response EMVCo will make to address these issues. Specifically, the document will address identified mobile contactless payment ecosystems issues in the following categories:

• Provisioning and Personalization of the secure element on a mobile platform with the contactless payment application.

o The entire processes of pre-distribution, post-distribution application installation, update, and deletion will be reviewed; and,

o Additionally, topics of device changes with embedded or removable secure elements, as well as considerations associated with the provisioning of the User Interface Application will also be reviewed.

• Possible technical assistance to help address Customer care will be reviewed.

• Usability of mobile device for contactless payment including: o User Authentication and Cardholder Verification; o Multiple payment applications on a single mobile device; o Payment Credential selection process; o Payment Credential availability with device off; and, o Branding via the User Interface.

The document confines itself to technical discussion, and does not address issues such as business relationships which may need to be formed to support the deployment of contactless payment in mobile devices. This document draws from many of the issues identified in the Mobile Payment Forum document, “Mobile Proximity Payment Issues and Recommendations” [MPIR], considering them in an EMVCo context. Additional issues and concerns are also documented.

October 2007 © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. Page 1


1.2 References

[14443] ISO/IEC 14443: Identification cards -- Contactless integrated circuit(s) cards -- Proximity cards, www.iso.org

[MPAF] Mobile Payments Architectural framework and Use Cases, Version 1.0, Mobile Payment Forum, www.mobilepaymentforum.org

[NFC] ISO/IEC 18092: Information technology -- Telecommunications and information exchange between systems -- Near Field Communication -- Interface and Protocol (NFCIP-1), www.iso.org

[PPTA] Proximity Payment Technology Assessment, Version 1.0, Mobile Payment Forum, www.mobilepaymentforum.org

[RADP] Requirements for Application Download and Personalization, Mobile Payment Configuration and Maintenance, Version 1.0, Mobile Payment Forum, www.mobilepaymentforum.org

[SATS] Security and Trust Services API (SATSA) for Java™ 2 Platform, Micro Edition, Version 1.0, JSR 177 Expert Group, Java Community Process (JCP), www.jcp.org

[STIP] STIP Core Framework Technology, A Technical Specification, Version 2.2, GlobalPlatform, www.globalplatform.org

[GPCS] GlobalPlatform Card Specification, versions 2.1.1 & 2.2, GlobalPlatform, www.globalplatform.org

[MPIR] Mobile Proximity Payment Issues and Recommendations, Version 1.0, Mobile Payment Forum, www.mobilepaymentforum.org

1.3 Definitions API Application Program Interface

ATM Automated Teller Machine

BIP Bearer Independent Protocol

CDMA Code Division Multiple Access

CLWG EMVCo Contactless Working Group

Contactless RF Generic term for multiple varieties of short-range RF communication technology

CPS EMV Card Personalisation Specification

GP GlobalPlatform

GPRS General Packet Radio System

GSM Global System for Mobile communications

Page 2 © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. October 2007

http://www.iso.org/

http://www.mobilepaymentforum.org/

http://www.iso.org/



http://www.jcp.org/

http://www.globalplatform.org/

http://www.globalplatform.org/



JCP Java Community Process

JSR Java Specification Request

LAN Local Area Network

MMI Man-Machine Interface

MMS Multimedia Messaging

MNO Mobile Network Operator

NFC Near-Field Communication

OMA Open Mobile Alliance

OTA Over-the-Air

PAN Personal Area Network

PDA Personal Digital Assistant

PIN Personal Identification Number

POS Point of Sale

PPSE A list of all Combinations supported by the Contactless Card. PPSE (Proximity Payment System Environment) is used in Entry Point Selection Process.

Proximity Payment A payment where the consumer is physically present at the point of sale.

RF Radio Frequency

RFID Radio Frequency IDentification

RUIM Removable Universal Identity Module

SATSA Security And Trust Services API

SE Secure Element

SIM Subscriber Identity Module

SSO Single Sign On

STIP Small Terminal Interoperability Platform

STK SIM Tool Kit

SMC Secure Multimedia Card

UI User Interface

UICC Universal Integrated Circuit Card

UMTS Universal Mobile Telephone System

URL Uniform Resource Locator

USIM Universal Subscriber Identity Module



WLAN Wireless Local Area Network

1.4 Mobile Device Architecture

1.4.1 Logical Architecture The logical architecture assumed for the mobile device is shown in Figure 1.

Sec

ure

Ele

men

t

Sec

ure

Ele

men

t

Figure 1: Logical Architecture of a Mobile Device

The mobile device consists of the following logical components, a mobile platform, and one or more secure elements. The secure element is where one or more payment applications are hosted, and provides a secure area for the execution of the applications and protection of the payment assets (e.g. payment data, keys, the payment application code). The secure element may also host applications which are not related to payment.



The mobile platform is the device in which the secure element is hosted, and also contains other components such as a user interface (UI) for both input and output, an application environment (such as a Java or other virtual machine, or the native operating system of the mobile device), a proximity modem (based on EMV contactless level 1 or other compatible standard), and a wide-area modem. In the context of this document, the wide-area modem is likely to be a cellular modem, however it could also be a wired modem, or wireless LAN. The secure element and the mobile platform provide logical interfaces between the payment application and the user interface, between the payment application and the application environment, between the payment application and proximity modem, and between the payment application and the wide area modem. In practice, the logical interfaces may be implemented via other elements within the mobile platform. For example, the payment application to UI interface may be implemented via a user interface application present in the application environment on the mobile platform. This situation is illustrated in Figure 2: where the interfaces between the payment application and the user interface and payment application and wide area modem are established via applications running in the application environment.

Figure 2: Example implementation of logical interfaces

In the example given in Figure 2: the user interface application needs to be installed on the mobile platform. Another example given in Figure 3 is the secure element includes the contactless modem, e.g. a NFC chip incorporating a secure element or a secure element directly handling the contactless protocol and directly connected to the contactless antenna.



Mobile Platform

User InterfaceWide area

modem

Secure Element

Payment application

Payment application

Application Environment

Contactless modem

Figure 3: Another example implementation of logical interfaces

1.5 Proximity Payment Architecture A block diagram showing the architecture of a mobile contactless payment system is given in Figure 4: .



Mobile device

Issuer

Merchant Point of Sale Device

Acquirer

Authorization and clearing network

Provisioning /Personalisation

Contactless Interface

Side channel

Figure 4: Mobile Contactless Payment Architecture

The mobile device holds a contactless payment application. The payment account issuer will provision and personalise the contactless payment application on the mobile device. There may also be a side channel link between the issuer and the mobile device for updating of payment application information (such as EMV scripts). The mobile device communicates with a merchant point of sale device over the contactless interface to allow the contactless payment application to perform a transaction. The merchant is connected to an acquirer, and through an authorization and clearing network to the issuer. EMVCo standards will ensure that the merchant POS infrastructure for accepting mobile contactless payment converges with the EMV Common Contactless Communications Protocol and so are not considered further in this document.

1.6 Implementation Options for the Secure Element Four implementation options for the secure element have been identified at this point. It is possible that additional implementation options will be available to device implementers in the future; if so, these additional implementations will need to provide appropriate security services for supporting proximity payment.



1.6.1 Embedded Hardware Secure Element The secure element may be a hardware tamper resistant module which is embedded in the mobile device. For example this may be a component such as a smartcard chip which is soldered on the circuit board of the mobile platform or a secure core on an NFC chip.

1.6.2 Secure Element on UICC The secure element may be in the UICC, the smartcard which hosts the application used for identification for mobile telephony purposes (such as the USIM or RUIM).

1.6.3 Removable Hardware Secure Element The secure element may be a removable hardware element, such as smartcard, or a secure core on a multimedia card. In many ways this is similar to the removable UICC option described above, however it is not associated with the particular mobile subscription, nor does it need to support telephony services for the mobile device.

1.6.4 Secure Element in Mobile Device Baseband Processor

The secure element may be hosted as part of the baseband processor (that is, the multipurpose processor which powers the mobile device) using portions of secure memory and processing. This is potentially a longer term solution. It is expected that the options described in sections 1.6.1 Embedded Hardware Secure Element and 1.6.2 Secure Element on UICC will be the dominant options in the short term, with the option described in section 1.6.4 Secure Element in Mobile Device Baseband Processor being a longer term opportunity.



2 Provisioning and Personalization

2.1 Introduction Traditionally cards and other tokens carrying an EMV payment application are single purpose tokens1, provided to the user by an issuer with the express intent that the token is used for payment. Such tokens are typically provisioned and personalised before the personalised token is delivered to the cardholder. As the token is provided by the issuer, the issuer knows the characteristics of the token (such as token type, operating system, and provisioning method) as the issuer has specified these to the supplier. A mobile device on the other hand is a general purpose device, one of its uses possibly being mobile proximity payment. Typically the mobile device is not provided by an issuer, and the lifecycle of the mobile device is separate from that of any payment application or payment data. As the issuer may not have been involved in the procurement of the mobile device, the issuer may have little influence on the characteristics of the mobile device, such as operating system, and will likely have to support provisioning and personalisation of a range of devices which may have differing characteristics. A new factor in the provisioning and personalisation of mobile devices is that the mobile device may have a user interface application, which also needs to be provisioned, and which needs to interact with the payment application. This user interface application will need to adapt to different mobile device characteristics such as application environment and screen capabilities. Device provisioning involves the delivery of the contactless payment application and personalization credentials necessary for a mobile device to be used as an instrument for making contactless payments, as well as any User Interface application. To provision a mobile device with the necessary information, a variety of security- and privacy-related issues must be addressed, in addition to other issues related to the process of managing the lifecycle of the payment credentials.

2.2 Possible Options for Device Provisioning and Personalisation

There are a number of approaches to provisioning and personalisation of the secure element. There are four main processes:

1 The token may be a multi-application token, however the other applications are generally known beforehand.



• The first is to provision the payment application code on the secure

element. • The second is to personalise the payment application with account details. • The third is provisioning the user interface application on the mobile

device. • The fourth is personalising the user interface application with any

account specific details. These processes may occur separately or together. They may also occur before or after the distribution of the mobile device and secure element. In considering provisioning and personalisation of a mobile device, it needs to be remembered that before the issuing of the mobile device it may be unknown whether the device will be used for payment, and which issuer(s) may need to personalise the device.

2.3 Provisioning and Personalisation of the Secure Element

The sections below consider the different options of the secure element, and whether they are suited to provisioning and personalisation before or after distribution.

2.3.1 Embedded Hardware SE Provisioning of the payment application may occur before distribution (provided the payment application is suitable for candidate issuers, and is sufficiently likely to be used to justify the costs of doing so), or may occur after the mobile device is provided to the end user. Unless issuers are prepared to provide cardholders with mobile devices, the personalisation of the mobile device will need to be performed after the device is provided to the end user.

2.3.2 SE on UICC The UICC is a removable element, which provides for provisioning and personalisation to be done either before the distribution of the USIM to the cardholder, or after the distribution. A UICC is provided by the cardholder’s mobile network operator, thus if it is to be provisioned and/or personalised for payment before the UICC is distributed to the user by the MNO, then agreements must be in place between the MNO and payment issuers before the UICC is sent out.



2.3.3 Removable Hardware Security Element A removable hardware security element is not controlled by the MNO in the same way that a UICC is. It may be controlled by a payment issuer in much the same way as any other contactless payment form-factor. This makes the removable hardware secure element a candidate for provisioning and personalisation before distribution, although it may also be provisioned or personalised after distribution.

2.3.4 SE in baseband processor Implementing a secure element inside a baseband processor is in many ways similar to having an embedded hardware secure element in terms of provisioning and personalisation. Provisioning may be performed before distribution, or after distribution. Personalisation will need to be performed post-distribution.

2.3.5 Summary

Table 1 Summary of Provisioning and Personalization Options for Secure Elements

Provisioning of Payment Application

Personalisation of Account Information

Pre-distribution

Post-distribution

Pre-distribution

Post-distribution

Embedded Hardware SE

SE on UICC

SE on removable hardware

SE in baseband processor



2.3.6 Separation of Provisioning and Personalisation Provisioning and personalisation may occur simultaneously or separately. For example, an issuer may load both the payment application and personalisation information into a secure element. On the other hand, a secure element may have the payment application installed before distribution (for example, burnt into ROM), and then be instantiated and personalised after distribution. It should be possible to have a single application in ROM which could be used by a range of issuers.

EMVCo Planned Action: EMVCo to consider a functional requirement that provisioning and personalisation of the contactless payment application can be in a single or separate sessions. Additionally, the EMVCo CLWG is to ensure there is a standard mechanism to personalise a contactless payment application based on EMV CPS.

2.3.7 Pre-distribution personalization The processes for personalisation which occurs pre-distribution are very similar to those currently used for cards and other similar form-factors such as key fobs, and so is not considered in further detail in this document.

2.4 Post-distribution Payment Application Provisioning Process Issues

This section details the issues related to the process of managing the lifecycle of the payment credentials, apart from those directly related to security.

2.4.1 Payment Application / Credentials Installation Process

Description Provisioning and personalisation of the payment application post-distribution require a connection from the issuer personalisation bureau to the mobile device. This may be provided over a number of different media. Examples include:

• Using the wide area cellular network, with an appropriate mobile client application to route the provisioning and personalisation data to the secure element.

• Using the contactless interface at a provisioning point. The provisioning point provides the connectivity to the personalisation bureau. Such provisioning points could be placed in a bank branch, at an ATM or other such locations.



• Using a connected device such as a PC to establish a connection with a

personalisation bureau and to transfer the data via a conduit to the mobile device (similar to synchronising phone book or email data with a PC).

Regardless of the medium used to transfer the provisioning and personalisation data, there are a number of common elements that need to be considered. The personalisation bureau needs a protocol to provision the payment application on the secure element. This protocol is likely to be tied to the operating system of the secure element. As post-distribution personalisation will not occur in the same physically secure environment as that provided by a traditional personalisation bureau, this protocol must provide sufficient security for carrying the data over open networks. A number of such protocols exist, and may be reused. GlobalPlatform provides such protocols and GSM 03.48 provides secure messaging for USIM based secure elements. These may be used in conjunction with EMV CPS in order to provide a secure delivery mechanism.

EMVCo Planned Action EMVCo will consider how EMV CPS may be used with secure messaging protocols such as those of GP and GSM 03.48 in a mobile environment. If necessary, EMVCo will consider enhancing CPS to provide the necessary capabilities for the mobile environment, and providing best practice guidelines as appropriate. Once a payment application is loaded on the secure element there may be a need to register the application in some way in order to make it available for selection, for example, it may need to be registered with the PPSE.

EMVCo Planned Action EMVCo to consider developing requirements of standard methods for registering a new application on a Secure Element, and collaborating with other bodies such as GlobalPlatform to define the appropriate method and mechanism for registration. Determining the level of user interaction that should be required/allowed during the provisioning process, particularly during account or application updates - asking for user acknowledgement or approval during an update might cause a delay in the process, while not doing so could result in the user contacting customer service to inquire about the nature of the change. Assuring the user that a valid payment application and payment credentials have been installed on the device – since an OTA transfer of payment information is largely invisible to the user, some mechanism will be needed to inform the user that the payment credentials are ready to use, and that the credentials are authentic and valid.



EMVCo Planned Action EMVCo to consider developing User Interface requirements to assist the user in securely managing and monitoring the processes for provisioning, personalisation and update of the payment application on a Secure Element in a mobile device. A number of the standard operating systems which may be used for secure elements have a number of implementation options. Payment associations or other service providers (including those outside of the payment area) may require specific configurations of the operating system. In the traditional card world this can be catered for by using a particular configuration based on the application to be placed on the card. In the case of mobile payment, the secure element will be shared by many applications, and cannot be customised to a particular application.

EMVCo Planned Action EMVCo to consider identifying the requirements of a standard configuration of operating systems to support contactless payment applications, and to work with other industries to develop a de-facto standard.

2.4.2 Update of Payment Application and Credentials As with traditional credit cards, the payment instruments installed in mobile devices for proximity payment will need to be updated as their expiration date nears. Parameters within the payment application may also need to be reset. The process should be able to be made transparent to the user, although user notification may be desirable for certain updates. EMV Scripts and post-distribution personalisation mechanisms such as EMV CPS should be used for updating data objects. In order to apply these mechanisms, there must be a mechanism for the payment application to interact with the issuer host system. Periodically there may be a need to update the payment application to a new version, whether due to a change in the specifications, to offer enhanced functionality, to fix bugs or provide additional security. In this case removal and reprovisioning and personalisation of the payment application is necessary.

EMVCo Planned Actions EMVCo to consider the use of EMV Scripts and EMV CPS in the mobile environment, in particular for post issuance and post distribution updating of the payment application and its counters and parameters; additionally, EMVCo to develop best practice guidelines and User Interface requirements for the management of post-distribution provisioning mechanisms, such as those offered by GlobalPlatform. Enhancements to the PPSE will also be considered as appropriate (also see section 4.2.2).



2.4.3 Payment Application and Credentials Deletion

Description There needs to be a mechanism for deleting the payment credentials, and possibly even the payment application, from the mobile device after distribution. Such a deletion might be initiated by the user (“cutting up a credit card”), or it may be a revocation initiated by the account issuer. Another (tricky) scenario is a deletion at the request of the MNO e.g. due to discontinuation of the mobile service to the end-user or due to business disagreements between the MNO and account issuer. Deletion of the payment information is an important aspect in the lifecycle of a payment instrument. There needs to be mechanism for the account issuer to remotely revoke the payment credentials, and even delete the complete payment application, if needed. This “push deletion” could be invoked for a variety of reasons, including the mobile device being reported lost or stolen, or due to the payment history of the account holder. Whatever the reason, a mechanism for push deletion needs to be defined, to allow the payment instrument to be deleted by the account issuer as needed. However, the requirements for user interaction during a push deletion need to be considered. If the deletion is because the phone was lost or stolen, then requiring user interaction defeats this as a security measure. On the other hand, deletion without informing the user may also cause confusion, and so user notification after the event may be the best option. There may also be a desire to provide the user with a mechanism for removing their payment credentials from the mobile device if so desired. Such a mechanism would need to provide the user with the means to select the specific payment credentials that they want to delete, and to even delete the payment application in its entirety, if the user no longer wants to have access to the proximity payment functionality. On the other hand, providing the user with a mechanism to delete their payment credentials or application could result in accidental deletion, which could certainly lead to customer service issues. In order to get payment credentials restored which have been accidentally deleted, it may be unclear to the user whether they need to call their account issuer, or their mobile network operator. The level of visibility that a mobile operator has into what applications the user has on their device can vary on the model that is in use for allowing downloads. For example, some operators allow the user to download any application, while others allow it only through their portal. So support from the mobile network operator for reinstalling a deleted payment application may be limited. An alternative to allowing the user to delete their payment credentials is to provide the user with the necessary contact information to request the deletion of the credentials, and then to have the deletion initiated by the account issuer, or other responsible party.



EMVCo Planned Actions EMVCo to consider best practices guidelines that the methods used to provision the payment application in a secure element also be able to remove the payment application. In the event that the secure element application environment does not allow for the deletion of the payment application, EMVCo to consider User Interface requirements and mechanisms to allow for the disablement of the payment application and the deletion of the payment credentials. EMVCo to consider developing requirements and collaborating with standards bodies such as GlobalPlatform to provide application deletion/disablement capabilities to the user, account issuer or possibly the MNO.

2.4.4 Device Change with Embedded Secure Element A device change could occur for a variety of reasons, including the user upgrading to a new mobile device, or replacing a device which has been lost or stolen. In some cases, this change could also include a change of mobile subscription, as detailed above. If the secure element is embedded in the mobile device, then such a change may require the entire personalisation process to be repeated for the new mobile device, including both the payment application, and the payment credentials issued to the device user. This would follow the personalisation process described above. Under ideal circumstances, any information related to the payment credentials will be deleted from a mobile device before any attempt is made to reinstall them on a replacement mobile device. This should be done according to the processes for deletion above.

EMVCo Planned Actions EMVCo to consider a best practices guideline that the standard processes for deletion and provisioning and personalisation should be used to transfer the credentials from one mobile device secure element to another mobile device secure element.

2.4.5 Device Change with Removable Secure Element

Description Mobile devices utilizing a removable secure element are also subject to routine replacement/upgrading, but because the secure element is removable, in some instances it can be transferred by the user to the new mobile device, assisting in the transition. Of course, if a device is lost, the situation would be similar to a device change with a non-removable secure element, e.g. loss of both the mobile device and the secure element. This section discusses the situation where the mobile device itself is being changed, and the secure element is being transferred to the new device.



The advantage of having a removable secure element is that a complete re-personalization of the mobile device may not be required when a device change is made. However, any time the secure element is transferred from one device to another, the compatibility of the new device will need to be verified. Compatibility includes not only physical and electrical compatibility of the removable element with the new phone, but also compatibility of the user interface application with the payment application. If the user interface application has been personalised or customized by the user2, then this personalisation or customisation may also need to be transferred. Device management, such as that defined by the Open Mobile Alliance, provides tools to enable a new device to replicate the set up of a previous device by means of data (for example, branding elements, user preferences etc.) stored on a device management server.

EMVCo Planned Actions In order to enable interoperability between removable secure elements, EMVCo to consider the development of requirements of standardised commands from the user interface application and the payment application along with standard application labels which may be used to store customised information associated with the payment application. These requirements will also consider the security between the user interface application and payment application. EMVCo to consider development of requirements for management of customised elements on a mobile device and collaborate with standards bodies such as the Open Mobile Alliance to define appropriate device management mechanisms.

2.4.6 User Interface Application Provisioning The user interface application will need to be provisioned and possibly personalised on the mobile platform or the secure element3. As with the payment application, the user interface application may be provisioned either pre-distribution of the mobile device, or post-distribution. Standardisation of the API between the user interface application and the payment application would allow for greater flexibility in pre-distribution provisioning. Most mobile application environments provide standard methods of provisioning applications on the mobile platform.

EMVCo Planned Actions EMVCo to consider defining the API between the user interface application and the payment application (see also section 2.4.5).

2 This may include user defined names for accounts, priorities or preferences of accounts and so on. 3 For example, if the user interface application makes use of USIM Application Toolkit, it would reside on the UICC.



Additionally, EMVCo to consider a best practices guideline that the standard methods of provisioning applications on the mobile platform should be used and/or enhanced for provisioning the user interface application.



3 Customer Care

Customer care for mobile devices is most commonly handled by the MNO, who has the primary relationship with the mobile device user. Mobile manufacturers may also provide customer care for hardware issues. If payment is introduced on a mobile device, users may still associate customer care with the MNO, or may address concerns to the account issuer or payment association. In any case, it should be assumed that users will not always know the correct point of contact, nor understand whether the problem is a hardware or software problem, or an account related problem such as lack of funds. While relationships and agreements may be in place between issuers and MNOs to handle customer care, in general MNOs may not be aware of the payment accounts a user has installed on his or her device, and issuers may not be aware of the model and configuration of the user’s mobile device. The mobile contactless payment application should not prevent support for customer care enquires, such as providing identifiers to allow a user’s issuer and account to be identified, and also to provide information about the configuration of payment application and mobile device.

EMVCo Planned Actions To assist with customer care interactions, EMVCo to consider defining standard application labels and/or application commands which may be used to assist in customer care.



4 Usability

4.1 Introduction Usability addresses concerns with the experience of the user who wants to use a mobile device for proximity payment. Many aspects of the proximity payment process, from provisioning and personalization of the mobile device to selecting the desired credentials for payment, to performing the payment transaction, have usability concerns associated with them. The goal in identifying these issues, and in making recommendations to address these issues, is to ensure ease-of-use, minimize confusion regarding device functionality, and to in general achieve a level of consistency in the proximity payment user experience that will help promote broad acceptance.

4.2 Transaction Experience Usability Issues Transaction experience issues are those issues which involve the user interaction with the mobile device when making a proximity payment. These include the process for selecting and managing payment credentials, and how the device will function when interacting with the POS terminal.

4.2.1 User Authentication / Cardholder Verification

Description To prevent unauthorized use of a mobile device for proximity payment, it is expected that some type of authentication process will be optionally available for enabling the proximity payment functionality. This authentication may be for cardholder verification, or it may be to lock or unlock the payment application for use. Although it is likely that most users may not make extensive use of this lock/unlock process to secure their proximity payment credentials, just having it available will provide the user with peace of mind that their device can be secured. One likely solution for user authentication would be through the entry of a passcode set by the user, which would enable the payment application. Using a numeric passcode as the authentication mechanism to enable the proximity payment application is something that many users of today’s mobile devices would already be familiar with. Depending upon the requirements of the primary actors in the proximity payment transaction (account issuers, merchants, card associations, etc), authentication of the user could be required at different frequencies, including:

• Rarely, to simply enable use of the payment application



• Each time the user enables a particular set of payment credentials for

making payments • On a transaction by transaction basis

However, while this type of authentication process is certainly desirable, if it is too complex, or requires the user to authenticate themselves to their device too often, then it could be a disincentive for using the mobile device as a payment device. Also, the authentication process must utilize a secure entry method, and the secure element as needed, to ensure that the authentication information can not be recorded by another application running on the mobile device. STIP could be a good answer to secure the passcode entry and its transfer to the secure element.

EMVCo Planned Actions EMVCo to consider user interface requirements and application commands that enable the locking and unlocking of a proximity payment application. These commands should provide for convenient and secure application usage management of multiple accounts contained on secure elements, including options for locking policies such as frequency of application locking and locking per application or for all applications.

4.2.2 Multiple payment applications on single device

Description Many of the existing proximity payment systems have been designed around the payment credentials being stored on a dedicated device, such as contactless payment cards, key fobs or tags. These devices are supplied by the issuer, and hence the number of payment credentials on the device is constrained in a well defined manner. Typically there will only a single set of credentials, or possibly a very small number (for example, debit and credit), and these will be issued by a single issuer for a single payment association. Under these conditions, payment credential selection is performed by the user presenting a particular device to the reader. The POS may cycle through the payment brands which are accepted at the merchant until that available on the device is encountered. In the cases where multiple credentials exist, these will usually be selected on the POS device. This method of selection will not work in the case where multiple credentials exist on a single device. Conceptually, the mobile device now acts like a physical wallet in which multiple cards are stored. Bringing the mobile device into proximity with the POS terminal is analogous to putting a wallet in proximity and expecting the POS to correctly choose the correct card.



The mobile device needs to convey to the POS terminal information regarding which of the payment credentials has been selected. One method of achieving this is to present the available credentials, with an indication of the selection priority. This would assist where not all of the available payment credentials on the device are accepted by the merchant. The POS may select the highest priority credentials which are accepted. This however requires that the POS terminal currently expects the possibility of a multiplicity of credentials, and also that the method of selection between the different payment applications and brands is compatible. If protocols for exchange of the transaction credentials differ greatly between payment applications it may be that if the presence one payment application (or set of payment credentials) has been identified by the POS it will be impossible to select a different payment application (or payment credentials). In this case, the mobile device may need to implement a filter in order to only make the selected payment credentials visible to the POS terminal.

EMVCo Planned Action The contactless payment application must have a mechanism to enable the POS to interact with the chosen payment application. It is expected that the PPSE mechanism defined by the EMV Contactless Working Group should provide this capability. This should include considerations of enhancing the PPSE as appropriate to support the mobile payment environment. EMVCo to consider defining commands for a user interface application to manage the PPSE appropriately in order to reflect the user selection of the payment instrument (see section 4.2.3 for more details).

4.2.3 Payment Credential Selection Process

Description While the first mobile devices which are enabled for contactless payment will contain only a single set of payment credentials, in future implementations it is expected that each device will be able to hold multiple sets of payment credentials. These multi-credential implementations will require some mechanism for allowing the user to select which set of credentials to use for completing a specific transaction. This mechanism will likely involve the user interface application in conjunction with the PPSE to allow the user to choose which set of credentials is to be used, either on a transaction-by-transaction basis, or based on a preconfigured set of user preferences. If so desired, this sort of digital wallet application could possibly be enabled to perform a variety of automatic credential selection functions on behalf of the user, based on the amount of information available for each specific transaction, the types of payment credentials accepted by the merchant, and a set of predefined user preferences. For example, the user could set preferences such as:

• Default set of credentials to be used • Priority order in which to use credentials for payment



The behaviour of the POS terminals needs to be defined so that it respects this application selection mechanism, including in the case where the PPSE is not present or does not contain the expected data.

EMVCo Planned Actions EMVCo to account for the following set of considerations in the development of User Interface requirements and best practices guidelines:

• Any payment application supporting multiple payment credentials should provide the user with the ability to select the set of credentials to be used on a transaction-by-transaction basis. It would also be desirable to allow the user to select a default set of credentials to be used, unless an alternate set of credentials is selected for a particular transaction.

• The interaction between the mobile device and the POS should not allow the merchant to override the user preferences and the behaviour of POS devices needs to be defined to respect the user preferences.

• Malicious readers seeking to attack the payment application need not follow the behaviour specified for a POS terminal, so mechanisms to prevent the activation of non-selected applications should be explored.

• It would also be useful if the payment application allows for the selection of a default set of credentials, to be used for any transaction in which the user has not chosen a specific set of credentials for completing that transaction.

• The mechanism for selection of a particular account when multiple contactless payment applications are available should be specified, but not the user interface (beyond “guidelines” and recommendations from EMVCo).

• The API which the mobile device must send to the contactless payment application for account selection should be standardised for interoperability between user interface applications and the payment application.

4.2.4 Payment Credential Availability with Device Off

Description One key issue with using a mobile device as a proximity payment instrument is whether the payment functionality could be available even if the device is powered off, and whether or not operation should be allowed in this case. Technically, it is feasible to support proximity payment when the mobile device is not powered; the nature of the proximity modem technology is such that the POS device can provide the power necessary to enable a transaction to be completed. Whether or not such operation should be allowed, however, is a more contentious issue, with arguments being made both for and against doing so. Potential concerns and issues that have been identified regarding having the mobile device proximity payment capabilities operational when the device is not powered include:



• Since off-network lost or stolen device credentials can’t be deleted OTA,

the user could have concerns that unauthorized transactions could be made, even if the liability is limited, which might cause them to avoid using the device as a payment instrument. This could be a valid concern for off-line POS transactions.

• If the device is powered off, there would be no way for a user to designate that a specific set of payment credentials be used (in multi-credential systems); unless a default set of credentials has been previously selected for use, the device would not be usable as a payment instrument.

• There may be account issuers who want more control over the management of credentials stored in a mobile device, who may argue against allowing credentials to be used unless the device is on-line, and some level of routine authentication is performed.

• It would not be possible to immediately indicate to the user that a transaction has taken place (e.g. no sound or flashing lights), so the user would need to rely on only the indication from the POS device that the transaction was successful.

• Any related branding opportunity that relied on the mobile device being powered up would be lost.

• There may be risk issues if powering down the phone bypasses security settings (such as a lock code) that the user has selected.

Arguments for having the proximity payment capabilities enabled even when the device is powered down include:

• If the mobile device cannot be used if powered down, then users will not rely on it as a payment instrument; instead, they will rely on more traditional payment mechanisms, rather than having to worry about whether their mobile device will “work” if power is lost.

• Other form factors used for proximity payment are passive, so the user’s expectation might be that the same should be possible with mobile devices.

EMVCo Planned Actions There is not a hard requirement that proximity payment functionality must work when the device is powered off. However EMVCo to consider requirements for the mobile contactless payment application operating when the device is powered down. Such considerations include:

• Having a default application selection method, possibly based on the power state of the mobile device;

• Detection of power state and restricting functionality accordingly.



4.3 Branding The brands associated with the issuer and payment scheme are an important element in deploying a mobile proximity payment solution. It is expected that branding will primarily be through the user interface, rather than physical branding on the mobile device or secure element.

4.3.1 Branding via the User Interface

Description Service providers (banks, petrol stations, etc.) have two possible opportunities to dialog with the user and display their brands:

• During the operation of the application (e.g. loading of tickets, reloading of the e-purse, checking of the loyalty points left).

• During the contactless transaction itself. Some action by the user may be needed, depending on the application (selecting a payment instrument, enter PIN code). At the end of the transaction, a brand could be displayed to the user via the UI. There could also be different branding requirements from different service providers. For example, branding could be visual and/or audio. Depending on the technology used for the UI, it may or may not be possible to display a brand. For example, the USIM Toolkit is very limited, and might not support the display of a brand, whereas a browsing solution or Java solution provides better ergonomic ability for branding.

EMVCo Planned Actions EMVCo to consider how the mobile contactless payment application should provide a mechanism to the mobile device to indicate when branding should be displayed, and what branding should be displayed. This may include flags to indicate the success of the transfer of information from the mobile device to the POS terminal and standard elements to identify which branding element should be displayed.



<<< END OF DOCUMENT >>>
