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

Page ii © 2007 EMVCo, LLC (“EMVCo”). All rights reserved. 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


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.
Secure Element
Secure Element

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

Application Environment
Wide area
User Interface modem

Secure Element

Payment Contactless
application
Payment modem
application

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: .



Contactless Interface Merchant Point of
Mobile device
Sale Device

Provisioning /
Side channel
Personalisation

Issuer Acquirer

Authorization and
clearing network

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:

1The 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 Personalisation of
Application Account Information

Pre- Post- Pre- Post-
distribution distribution distribution 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 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 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 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 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 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.

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 to consider defining the API between the user interface application and
the payment application (see also section 2.4.5).

2This may include user defined names for accounts, priorities or preferences of
accounts and so on.
3For 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.

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 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.

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 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.

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 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 >>>


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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

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

Similar to 2007 11 - emv mobile contactless payment technical issues version 1.0 final (20)

More from Boni

More from Boni (20)

Recently uploaded

Recently uploaded (20)

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