Mobile Master Card PayPass TSM Functional Requirements v1-0

Mobile MasterCardPayPass TSM

FunctionalRequirements

November 2009 - Version 1.0

©2009 MasterCardMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Proprietary Rights

The information contained in this document is proprietary and confidential toMasterCard International Incorporated, one or more of its affiliated entities (collectively“MasterCard”), or both.

This material may not be duplicated, published, or disclosed, in whole or in part, withoutthe prior written permission of MasterCard.

Trademarks

Trademark notices and symbols used in this manual reflect the registration status ofMasterCard trademarks in the United States. Please consult with the CustomerOperations Services team or the MasterCard Law Department for the registration statusof particular product, program, or service names outside the United States.

All third-party product and service names are trademarks or registered trademarks oftheir respective owners.MasterCard Worldwide2200 MasterCard BoulevardO’Fallon MO 63368-7263USA

1-636-722-6100

www.mastercard.com

Table of Contents

© 2009 MasterCardiMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Using this Manual

Scope ............................................................................................................................................... 1

Audience ......................................................................................................................................... 1

Reader Guidance ........................................................................................................................... 1

Abbreviations and Acronyms...................................................................................................... 1

Related Information...................................................................................................................... 2

Terminology ................................................................................................................................... 3

Revision History ............................................................................................................................ 4

Chapter 1 Introduction

1.1 Background...........................................................................................................................1-1

1.2 Who Needs to Implement these Requirements? ............................................................1-1

1.3 When Must these Requirements be Implemented?........................................................1-1

Chapter 2 Basic Requirements

2.1 Approval Compliance .........................................................................................................2-1

2.1.1 Component ID Lookup ...........................................................................................2-1

2.1.2 Approval Cross-check ..............................................................................................2-1

2.1.2.1 Contactless Module Within Mobile Device............................................2-1

2.1.2.2 Secure Element (SE)...................................................................................2-2

2.2 User Verification ..................................................................................................................2-3

2.2.1 Personalization Initiation .........................................................................................2-3

2.2.2 De-personalization on Request (Issuer or User Initiated) ..................................2-3

2.2.3 De-personalization for Lost/Stolen (Without Request) .....................................2-4

2.2.4 Disable Application for Lost/Stolen (Without Request)....................................2-4

2.2.5 Disable Code Mandatory (Generated or User Defined).....................................2-4

2.2.6 Enable Code Mandatory (Generated or User Defined)......................................2-4

2.3 User Opt-In for Default Update .......................................................................................2-5

2.4 Load Balancing.....................................................................................................................2-5

Table of Contents

ii© 2009 MasterCard

November 2009 - Version 1.0 Mobile MasterCard PayPass TSM Functional Requirements

2.5 Issuer/TSM Interface Security...........................................................................................2-5

2.6 SE Cryptographic Requirements .......................................................................................2-6

Chapter 3 Mobile Client Functional Requirements

3.1 Deactivated Features/Functions .......................................................................................3-1

3.2 Confirmation/Verification Code.......................................................................................3-1

3.2.1 Verification Code Mandatory for All Personalization.........................................3-1

3.2.2 Code Creation ............................................................................................................3-1

3.2.2.1 User Defined................................................................................................3-1

3.2.2.2 TSM/Issuer Generated..............................................................................3-1

3.2.3 Verification Code Entry during Personalization ..................................................3-2

3.2.4 Verification Code Length.........................................................................................3-2

3.2.5 Verification Code UI Appearance ..........................................................................3-2

3.3 Disruption Resistance .........................................................................................................3-2

3.3.1 Rejected Incoming Calls during Personalization..................................................3-2

3.3.2 Accepted Incoming Calls during Personalization ................................................3-3

3.3.3 Non-viewed Incoming SMS/MMS during Personalization ...............................3-3

3.3.4 Viewed Incoming SMS/MMS during Personalization........................................3-3

3.3.5 Non-viewed Incoming Email during Personalization.........................................3-3

3.3.6 Viewed Incoming Email during Personalization..................................................3-4

3.4 Tearing Recovery .................................................................................................................3-4

3.4.1 Disrupted Connection Recovery ............................................................................3-4

Chapter 4 In-field Personalization Update Requirements

4.1 Personalization Updates Allowed......................................................................................4-1

4.2 Denial of Duplicate Personalization Request..................................................................4-1

4.3 Personalization Update Error if No Payment Application Present.............................4-1

4.4 Payment Application Upgrade...........................................................................................4-2

4.5 De-personalization Supported ...........................................................................................4-2

Table of Contents

© 2009 MasterCardiiiMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Annex A Requirements Summary

A.1 Basic Requirements............................................................................................................A-1

A.2 Mobile Client Requirements.............................................................................................A-3

A.3 Personalization Update Requirements............................................................................A-5

©2009 MasterCardiMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Using this Manual

This chapter contains information that helps you understand and use this manual.

Scope .........................................................................................................................................1

Audience ...................................................................................................................................1

Reader Guidance......................................................................................................................1

Abbreviations and Acronyms..................................................................................................1

Related Information.................................................................................................................2

Terminology .............................................................................................................................3

Revision History.......................................................................................................................4

Using this Manual

Scope

©2009 MasterCard1Mobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Scope

This document lists the basic requirements that must be met in order for all SecureElement related subcomponent identifiers to be retrieved during to be approved.

Audience

This document is aimed at the following audiences:

Secure element module manufacturers/providers (e.g. SIM card manufacturers)

Secure element operating system developers

Payment application developers

Reader Guidance

This document lists the basic requirements that secure element sub-components that areused in implementations of Mobile MasterCard PayPass must adhere to.

Abbreviations and Acronyms

The following abbreviations and acronyms are used in this manual:

Acronym Meaning

CAST Compliance Assessment and Security Testing

MNO Mobile Network Operator

MOTAPS MasterCard Over The Air Provisioning Service

OTA Over The Air

SE Secure Element

SIM Subscriber Identity Module

TSM Trusted Service Manager

UI User Interface

USIM Universal Subscriber Identity Module

Using this Manual

Related Information

2©2009 MasterCard


Related Information

The following documents and resources provide information related to the subjectsdiscussed in this manual.

Note MasterCard reserves the right to release new versions of documentsreferenced by this document. TSMs should therefore check for the latestdocumentation versions and the impact of any amendments they contain whendeveloping or updating their services.

Title Description

PayPass on Mobile Requirements Mobile MasterCard PayPass – Requirements

Mobile MasterCard PayPass Testingand Approval Guide

Approval process guide for all components of MobileMasterCard PayPass implementations

Security Requirements for MobilePayment Provisioning

Security Requirements

Personalization Card Personalization Validation Guide

CAST Compliance Assessment and Security Testing Program

EMV EMV Integrated Circuit Card Specifications for PaymentSystems

Book 1 Application Independent ICC to TerminalInterface Requirements, Version 4.1

Book 2 Security and Key Management

Book 3 Application Specification

Book 4 Cardholder, Attendant, and Acquirer InterfaceRequirements

Mobile MasterCard PayPass UserInterface Application FunctionalRequirements

Functional requirements document for all User Interfaceapplications that are designed for use in MobileMasterCard PayPass implementations.

Mobile MasterCard PayPass UserInterface Application Approval Guide

Approval process guide for User Interface Applicationsused in Mobile MasterCard PayPass implementations

Using this Manual

Terminology

©2009 MasterCard3Mobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

Terminology

This section explains a number of key terms and concepts used in this manual.

Term Meaning

Assembly A combination of components that, when brought together, canperform the basic function of making a contactless payment andcan therefore be tested for functional compliance with MobileMasterCard PayPass requirements. This does not include anyOTA component.

CAST The process that tests whether the chip, operating system andapplication(s) meet the security requirements as documented in[CAST].

Compliance Assessment andSecurity Testing Certification

Acknowledgement by MasterCard that the chip, operatingsystem and application(s) meet the CAST requirements.

Component Any product, part or combination of parts used in a MobileMasterCard PayPass implementation (e.g. mobile device orpayment application).

Mobile Device Any mobile phone, smartphone or handheld PDA orcommunications device that includes NFC functionality and canbe used as part of a Mobile MasterCard PayPass implementation.

Mobile Device Manufacturer The manufacturer of the mobile device; the scope of the role ofthis entity can range from simply manufacturing the hardwarethat will house the other key components to providing a devicethat incorporates SE and/or payment application and/or UserInterface or Wallet application.

mPIN Mobile Personal Identification Number

On-device PersonalizationApplication

Software that provides interaction between the PayPassapplication within the Secure Element and the mobile networkfor over-the-air personalization. It also enables downloading ofthe PayPass application over-the-air to the Secure Element. Maybe implemented in a number of ways, for example a JavaMIDlet.

OTA Over-The-Air (OTA) refers to any process that involves thetransfer of data (including applications) to the mobile handset orany component within the mobile handset via the mobilenetwork.

Over-the-air (OTA)personalization

Personalization (see definition below) carried out in such a waythat the mobile handset Secure Element to be personalized isconnected to the associated personalization data servers via awide-area network, such as a mobile network or the Internet.

Using this Manual

Revision History

4©2009 MasterCard


Term Meaning

Payment Application The software implemented within the secure memory domain ofa Mobile MasterCard PayPass implementation (e.g. on the secureSIM card) covering the requirements of the PayPass or MobileMasterCard PayPass Specification.

Payment Application Provider A legal entity that has signed a PayPass Specification LicenseAgreement, is entitled to use PayPass brands and supply PayPassapplications and whose name will be stated on the MasterCardMobile MasterCard PayPass Implementation -Letter of Approval.

SE Provider A legal entity that provides any form of Secure Element for usein a Mobile MasterCard PayPass implementation, and whosename will be stated on the MasterCard PayPass Implementation -Letter of Approval.

User Interface/WalletApplication Provider

A legal entity that has signed a PayPass UI/Wallet DeveloperLicense Agreement, is entitled to use PayPass brands and supplyPayPass UI/Wallet applications and whose name will be statedon the MasterCard Mobile MasterCard PayPass Implementation -Letter of Approval.

Revision History

MasterCard periodically will issue revisions to this document as and whenenhancements, new developments, corrections or any other changes are required.

Each revision includes a summary of changes which is added to the revision historybelow, describing what has changed and how. Revision markers (vertical lines in theright margin) indicate where the text changed. The month and year of the revisionappear at the right of each revision marker.

MasterCard may publish revisions to this document in a MasterCard bulletin, anotherMasterCard publication, or on MasterCard OnLine, within the Mobile Partner Programsection: www.mastercard-mobilepartner.com.

A subsequent revision is effective as of the date indicated in that publication or onMasterCard OnLine and replaces any previous edition.

Version Date History Impact

1.0 November 09 First complete version

©2009 MasterCard1-iMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

1 Introduction

This document lists the basic functional requirements for any MasterCard

accredited TSM Service in the context of Mobile MasterCard PayPass

implementations, including the functional requirements for any User Interface

Application that may be part of a TSM solution.

1.1 Background..................................................................................................................... 1-1

1.2 Who Needs to Implement these Requirements?......................................................... 1-1

1.3 When Must these Requirements be Implemented? .................................................... 1-1

Introduction

Background

©2009 MasterCard1-1Mobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

1.1 Background

MasterCard has developed a comprehensive test and validation process for MobileMasterCard PayPass implementations and components used in implementations that arederived from the existing processes that are applied in the context of issuing PayPasscard products. This enables world-wide interoperability as well as quality, reliability andsecurity assurance at acceptable levels of time and cost.

All components and sub-components used in an implementation of Mobile MasterCardPayPass must go through a test and validation process. All approved products; services,components and subcomponents are documented and held in a database by MasterCard.Information relating to approved products and services is made available to issuers viathe Mobile Partner Program website (www.mastercard-mobilepartner.com). Theinformation is provided to enable issuers to ensure that only approved implementationsare brought to market.

As most implementations of Mobile MasterCard PayPass will utilize an OTA solution ofsome description (especially for personalization), the engagement of a third party whohas access to the relevant keys allowing access to the payment domain within the SecureElement (SE) is required. These organizations are referred to as a Trusted ServiceManager (TSM). This document describes the requirements that need to be met byTSMs when delivering the service in a convenient and secure manner.

1.2 Who Needs to Implement these Requirements?

The requirements need to be met by any Trusted Service Manager wishing to gainapproval from MasterCard to provide their TSM solution to MasterCard issuinginstitutions in the context of Mobile MasterCard PayPass issuance.

Banks that wish to set up and run their own mobile provisioning services using theirown technology infrastructure do so at their own risk and need not therefore requestapproval from MasterCard for doing so.

1.3 When Must these Requirements be Implemented?

The basic requirements apply to all TSM solutions and must be implemented by theTSM in all their deployments.

Requirements relating to the User Interface Application and OTA functionality onlyapply to solutions that make use of a User Interface Application of some description.This will therefore generally apply to all scenarios where ad hoc personalization occurs orinstant issuance applies.


2 Basic Requirements

This chapter describes the basic requirements for the approval of TSM solutions.

2.1 Approval Compliance.................................................................................................... 2-1

2.1.1 Component ID Lookup ...................................................................................... 2-1

2.1.2 Approval Cross-check ......................................................................................... 2-1

2.1.2.1 Contactless Module Within Mobile Device............................................. 2-1

2.1.2.2 Secure Element (SE).................................................................................. 2-2

2.2 User Verification ............................................................................................................ 2-3

2.2.1 Personalization Initiation .................................................................................... 2-3

2.2.2 De-personalization on Request (Issuer or User Initiated)................................ 2-3

2.2.3 De-personalization for Lost/Stolen (Without Request)................................... 2-4

2.2.4 Disable Application for Lost/Stolen (Without Request) ................................. 2-4

2.2.5 Disable Code Mandatory (Generated or User Defined)................................... 2-4

2.2.6 Enable Code Mandatory (Generated or User Defined) ................................... 2-4

2.3 User Opt-In for Default Update .................................................................................. 2-5

2.4 Load Balancing............................................................................................................... 2-5

2.5 Issuer/TSM Interface Security...................................................................................... 2-5

2.6 SE Cryptographic Requirements .................................................................................. 2-6

Basic Requirements

Approval Compliance


2.1 Approval Compliance

At the centre of the requirements for the approval of TSM solutions, the TSM mustoffer maximum protection to the cardholder details by ensuring that provisioning onlyoccurs on handsets containing MasterCard approved components.

The TSM must establish the approval status of the handset and all other keycomponents that are relevant to the implementation of Mobile MasterCard PayPass atthe earliest point within the provisioning process. Should any of the components withinthe handset not be recognized as approved, the TSM must be able to terminate theprocess immediately without compromising the cardholder assets.

2.1.1 Component ID Lookup

The TSM Service must be configured to send ID requests to the components in ahandset that is initiating the personalization process. In order to comply with therequirement set out in section 2.1 these requests should be performed at the firstopportunity within the provisioning process.

In the event of a non-response to any of the ID requests, the TSM must assume that thecomponent being interrogated has not attained the relevant level of approval. A relevantuser notification message should be sent to the handset in question as agreed with theIssuing bank (who has engaged the TSM).

Note The potential for ID request retries or re-attempts by the Customer to initiateprovisioning are at the discretion of the TSM. However, the policy employed bythe TSM should not provide a “back door” for provisioning of unidentified ornon-approved components.

2.1.2 Approval Cross-check

During the specific ID request checks, a structured approach to the mechanism toensure provisioning of approved Assembly or Components is advised. Two logicalphases of approval are suggested:

Mobile Device identification including Contactless Module

The Secure Element (SE) identification

2.1.2.1 Contactless Module Within Mobile Device

It is important to identify the mobile device in combination with the specific contactlessmodule that makes up the working assembly to ensure that the assembly meets the

Basic Requirements

Approval Compliance

2-2©2009 MasterCard


functional and performance requirements. The key sub-components that are of interestare:

Contactless Signal Processing Component (e.g. the NFC chip)

Contactless Antenna

Both of the identified items must have passed through the approval process within thesame assembly.

2.1.2.2 Secure Element (SE)

The Secure Element (SE) will contain both the PayPass payment application and thecardholder credentials and therefore functional and security compliance are of thehighest concern. The following items must have been approved within the sameassembly:

Integrated Circuit

The chip product name (as referenced in MasterCard CAST or EMVCo approval)must be queried and cross-checked against an up-to-date list of approved ICs.

Operating System

Every MasterCard approval of a Secure Element product will also take intoconsideration a specific Operating System which will have a unique name andversion. This in turn will also be referenced in the list of approved products. TheOS name and version will therefore also need to be queried and cross-checkedagainst the approval list.

Payment Application

The final sub-component that is part of a MasterCard approval is the PaymentApplication. In cases where the TSM is personalizing a Payment Application that iseither pre-loaded on the device to be personalized, or is being provided by anotherthird party, the TSM must query the payment application name and version numberas referenced in the approval documentation. Details of the Payment Applicationand its version will always be included in all SE product approvals. The TSM willtherefore need to query the application name and version and can then cross checkagainst an up-to-date database.

In cases where a TSM is provisioning the payment application themselves, theymust ensure that an application is used, which has been approved as part of a SecureElement Approval.

Note The TSM is expected to have some form of database to check approvedproducts during live personalization requests. MasterCard will make a list ofapproved components available to vendors via the Mobile Partner Program(www.mastercard-mobilepartner.com).

Basic Requirements

User Verification


Note The approval process cannot guarantee that an individual component that hasbeen approved within one assembly will attain the required service standardswithin another combination.

2.2 User Verification

To ensure that the handset (to be provisioned) is in possession of the account holder atthe time of personalization, the TSM is required to issue an authentication step withinthe provisioning actions.

This requires user interaction by the cardholder to enter a Verification Code that is ashared secret known by the Cardholder and the TSM provisioning the handset. Thecode could be created by the cardholder (when they register for Mobile MasterCardPayPass), assigned by the Issuer on registration or generated by the TSM on behalf of theIssuer.

Where the User Verification Code is generated by the TSM on behalf of the Issuer, theTSM must have a secure method of notifying the cardholder of this code.

When entering the Verification Code, the exchange of this code through the air mustnever take place in the clear. Therefore a transfer key must be employed to ensureencrypted communication of the Verification Code between the cardholder and theTSM during the provisioning.

Note The interface specification between the Issuer and the TSM must include anattribute to allow the transport of the cardholder Verification Code. It should benoted that this code does not represent any PINs that are associated with thecard for use during the transaction process.

The following requirements relate to the specific provisioning actions available.

2.2.1 Personalization Initiation

In order to initiate the Personalization of the cardholder details, the request of theVerification Code from the cardholder is Mandatory.

2.2.2 De-personalization on Request (Issuer or User Initiated)

The TSM must allow the Issuer or the Cardholder to request the de-personalization ofthe handset.

Basic Requirements

User Verification



It is necessary to ensure that the consumer who is requesting the action is confirmed asthe same consumer who is carrying out the action on the handset.

This can be achieved using a verification code as per the personalization process. Werecommend that this is a one-time code which is generated at the time of the request(either by the issuer or by the TSM acting on behalf of the issuer).

2.2.3 De-personalization for Lost/Stolen (Without Request)

Due to the nature of this process, it must execute without any interaction by the user orentry of the Verification Code.

2.2.4 Disable Application for Lost/Stolen (Without Request)

Due to the nature of this process, it must also execute without any interaction by theuser or entry of the Verification Code.

2.2.5 Disable Code Mandatory (Generated or User Defined)

The TSM must provide the ability to temporarily disable the service on the handset atthe Issuer’s request.



2.2.6 Enable Code Mandatory (Generated or User Defined)

The TSM must provide the ability to enable the service on the handset (that haspreviously been disabled) at the Issuer’s request.

Entry of the User Verification Code is mandatory for the successful execution of theenable function.

Note The interface specification must include attributes to allow recognition of theprovisioning action required of the TSM.

Basic Requirements

User Opt-In for Default Update


2.3 User Opt-In for Default Update

When a new account is being personalized onto a Secure Element on a Mobile Deviceand there are existing accounts present on the Secure Element the TSM may implementan update mechanism to change the default account to the new account.

However if this is implemented the TSM must clearly state to the user that this change isbeing proposed and offer the user a means of either accepting this change (Opt-In) orrefusing the change to keep the existing default setting.

2.4 Load Balancing

Multiple concurrent provisioning processes must be possible without impact on thereliability or speed of individual personalization on different devices.

In addition to this, the performance of the provisioning process (from the TSM point ofview) should not vary from handset to handset. However, it is accepted that whilst theperformance of the servers residing within the TSM is under the control of the TSM, theperformance of the personalization within the NFC handset itself cannot be guaranteedby the TSM.

2.5 Issuer/TSM Interface Security

The interface between the Issuer and the TSM may take the form of a web service or abatch file, submitted at agreed points within the business day. This is at the discretion ofthe Issuer and TSM, dependant on the volume of cardholders and the service beingprovided by the TSM.

The interface will carry personal cardholder details therefore an encryption method mustbe agreed for the transport of the messaging or file.

Usual industry practices will dictate a key exchange ceremony takes place between theIssuer and the TSM.

The security requirements for TSMs are documented in [Security Requirements forMobile Payment Provisioning].

Basic Requirements

SE Cryptographic Requirements



2.6 SE Cryptographic Requirements

The initial keys that protect the Secure Element (or specifically the banking domainwithin a Secure Element) are dependant on who is the owner of the SE real estate. Thiswill vary based on the architecture used and in all cases the TSM will need to buildrelationships with the relevant parties in order to act as a trusted party.

In order to secure the cardholder details from attack or corruption by a third party, theTSM must replace the original keys that secure the SE (or specific domains within theSE) with others which are specific to their implementation as part of the firstprovisioning process.

The TSM may replace this key with:

The TSM’s own specific encryption key for the Issuer service

An encryption key provided by the Issuer and securely stored by the TSM

An individualized key (per Secure Element) derived from either of the two abovearrangements

The TSM must prove (on inspection) that their installation meets industry standards forthe retention of cryptographic data.


3 Mobile Client Functional Requirements

For TSM Services that include a mobile client application (such as a Java MIDlet, a

Symbian application or a native application specific to a proprietary platform on any

particular handset) the following requirements apply.

MasterCard may require the TSM to submit the client for functional evaluation when

the TSM registers their service for approval.

3.1 Deactivated Features/Functions .................................................................................. 3-1

3.2 Confirmation/Verification Code.................................................................................. 3-1

3.2.1 Verification Code Mandatory for All Personalization ...................................... 3-1

3.2.2 Code Creation ...................................................................................................... 3-1

3.2.2.1 User Defined.............................................................................................. 3-1

3.2.2.2 TSM/Issuer Generated ............................................................................. 3-1

3.2.3 Verification Code Entry during Personalization ............................................... 3-2

3.2.4 Verification Code Length.................................................................................... 3-2

3.2.5 Verification Code UI Appearance...................................................................... 3-2

3.3 Disruption Resistance.................................................................................................... 3-2

3.3.1 Rejected Incoming Calls during Personalization............................................... 3-2

3.3.2 Accepted Incoming Calls during Personalization ............................................. 3-3

3.3.3 Non-viewed Incoming SMS/MMS during Personalization ............................. 3-3

3.3.4 Viewed Incoming SMS/MMS during Personalization ..................................... 3-3

3.3.5 Non-viewed Incoming Email during Personalization ...................................... 3-3

3.3.6 Viewed Incoming Email during Personalization............................................... 3-4

3.4 Tearing Recovery ........................................................................................................... 3-4

3.4.1 Disrupted Connection Recovery ........................................................................ 3-4

Mobile Client Functional Requirements

Deactivated Features/Functions


3.1 Deactivated Features/Functions

Some TSMs may choose to implements a generic or “vanilla” User Interface or WalletApplication which supports a broad set of features and functions. In such cases theTSM must ensure that any implementations where any of these features are not madeuse of (due to limited functionality of the mobile device, payment application or otherreasons) such features are made “invisible” or are hidden (i.e. they must be deactivatedsuch that they are not visible to the end-user).

Failure to support this will cause confusion to the end-user.

3.2 Confirmation/Verification Code

3.2.1 Verification Code Mandatory for All Personalization

The entry of a Verification Code is mandatory for the initial personalization of thehandset.

Verification code entry is mandatory for any user initiated provisioning actions against afully personalized handset.

3.2.2 Code Creation

3.2.2.1 User Defined

The user may create the Verification Code when they register for the Mobile PayPassservice.

The TSM must retain attributes within their interface with the issuer/registration sourceto accommodate a user defined Verification Code.

The Verification Code must not be exchanged between the handset and the TSM(during provisioning) without industry-recognized encryption being in place.

3.2.2.2 TSM/Issuer Generated

The TSM or the Issuer may create the Verification Code on behalf of the user.

The TSM’s or Issuer’s Verification Code generation utility must not be sequential innature, nor should it be easy to predict.

The TSM or Issuer must have a secure facility for communicating the Verification Codeto the user prior to personalization.


Disruption Resistance



3.2.3 Verification Code Entry during Personalization

The UI must request correct entry of the Verification Code prior to the transfer of anycardholder credentials to the Secure Element (SE).

A threshold of unsuccessful entries by the cardholder should be instated on the TSM’sservice. It is recommended that this threshold is configurable per installation.

3.2.4 Verification Code Length

The minimum length of Verification Code should be four (4) characters. The maximumlength is at the discretion of the service provider. However, this needs to besynchronized with the registration screens (in the event of user creation of theVerification Code) and the TSM or Issuer’s Verification Code generation facility.

It is recommended that this code is numeric only (for usability reasons). It should alsobe of a manageable size to ensure that:

The user can easily remember this code.

It provides sufficient security.

It is acknowledged that there is always a trade off between convenience and security.

3.2.5 Verification Code UI Appearance

The Verification Code should not appear “in the clear” on the user’s handset screenwhen it is entered. A masking technique should be used to preserve the security of thiscode.

For example, the entry of a four-character Verification Code may appear as fourasterisks.

3.3 Disruption Resistance

The personalization process must not have a negative impact on normal functions of thehandset.

The personalization process must not be impacted by usual handset functions.

The following sections state the requirements of these concurrent actions.

3.3.1 Rejected Incoming Calls during Personalization

During the personalization process, an incoming call must not cause automatictermination of the provisioning action.


Disruption Resistance


It must also be possible to reject the call using the normal handset functions withoutterminating the provisioning action.

3.3.2 Accepted Incoming Calls during Personalization

As stated within the previous section, an incoming call must not automatically terminatethe provisioning process.

It must also be possible to accept the call and allow the provisioning process to continuein the background, uninterrupted. The provisioning process must also wait for any userinteraction required.

Note Whilst the service must await a response, a timeout threshold may be put inplace by the TSM.

3.3.3 Non-viewed Incoming SMS/MMS during Personalization

Reception of an SMS or MMS to the handset must not terminate the provisioningprocess. The provisioning process must be able to complete while a received SMS orMMS is retained within the inbox for viewing at a later time.

3.3.4 Viewed Incoming SMS/MMS during Personalization

It must be possible for the user to view an incoming SMS/MMS during the provisioningprocess. The reception of the message must not terminate the provisioning process norshould the viewing of the incoming SMS/MMS. The provisioning process must alsowait for any user interaction required.


3.3.5 Non-viewed Incoming Email during Personalization

Where the handset includes an email function, the reception of an email on the handsetduring the provisioning process must not terminate the personalization.

The email must be stored within the email reception area (a.k.a. inbox) for action by theuser at a later time.


Tearing Recovery



3.3.6 Viewed Incoming Email during Personalization

It must be possible for the user to view a received email during the provisioning process.The reception of the email must not terminate the provisioning process nor should theviewing of the received email. The provisioning process must also wait for any userinteraction required.


3.4 Tearing Recovery

3.4.1 Disrupted Connection Recovery

The completion of the provisioning is dependant on the strength and continuity of thenetwork signal.

From time to time, this signal will fail, causing a disconnection from the session.

When the user recommences a session following disconnection during personalization,the TSM service should recommence the personalization process at the point that itfailed or as close as possible to that point and should not restart from the beginning.

However this must be a secure resumption and the user must be requested to re-entertheir Verification Code to ensure that they remain in control of the handset.

Note Disruption recovery mechanism must remain compliant with the SecurityRequirements to the same extent as the original personalization session, asdefined in [Security Requirements for Mobile Payment Provisioning].


4 In-field Personalization Update Requirements

The TSM’s service needs to accommodate all of the usual events that occur within

the lifecycle of a card. This section deals with the actions that occur later within the

lifecycle, after the initial personalization. All of these actions are initiated by the

Issuer’s submission of personalization requests to the TSM.

4.1 Personalization Updates Allowed................................................................................. 4-1

4.2 Denial of Duplicate Personalization Request .............................................................. 4-1

4.3 Personalization Update Error if No Payment Application Present........................... 4-1

4.4 Payment Application Upgrade...................................................................................... 4-2

4.5 De-personalization Supported ...................................................................................... 4-2

In-field Personalization Update Requirements

Personalization Updates Allowed


4.1 Personalization Updates Allowed

Following the initial personalization of the SE within the handset, the followingpersonalization events must be supported by the TSM service:

Card replacement

Card renewal

De-personalization

Upgrade of the payment application

The interface specification between the Issuer and the TSM must support attributes thatwill allow the identification of the action that the provisioning process needs to take.

4.2 Denial of Duplicate Personalization Request

As a safeguard against overwriting valid card details that already reside within the SE, theTSM must be able to distinguish whether an initial personalization request is being madeagainst a handset that already has already been personalized and the card is in an activestate.

During the first phase of the initial personalization, the TSM should establish whetherthe SE already holds a valid card. If the action being requested is for an initialpersonalization, the TSM should terminate the process immediately.

An error response message should be supplied to the Issuer to allow them to takeremedial action.

Note The TSM definition of a card in an active state is where the details reside withinthe SE and are available for transaction purposes.

4.3 Personalization Update Error if No PaymentApplication Present

During any of the actions available within the TSM service to update the cardholderdetails (replacement, renewal, payment application upgrade, de-personalization), theTSM must undertake a check for an existing payment application.

If a payment application is absent from the handset, the personalization update processmust be terminated immediately.

In-field Personalization Update Requirements

Payment Application Upgrade



An error response message should be provided to the Issuer to alert them to theanomaly.

4.4 Payment Application Upgrade

From time to time, new versions of payment applications may become available (bugfixes, feature enhancements etc).

The TSM must provide the facility to send the latest versions of payment applicationsdirectly to the cardholder’s handset.

This process does not require the entry of the Verification Code by the user (cardholderdetails will not be replaced).

The process must not overwrite the existing cardholder details held within the SE, normust it render the handset unavailable for transactions.

4.5 De-personalization Supported

De-personalization is removal (logical or physical) of the cardholder details from the SE.The TSM must support this function within their service.

This facility is on the request of the cardholder and is passed between the Issuer and theTSM within a specific request record.



The de-personalization process must render the cardholder details unavailable to thepayment application.

It must be possible to re-personalize the SE following successful de-personalization.

©2009 MasterCardA-iMobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

A Requirements Summary

This section provides a summary of the TSM requirements.

A.1 Basic Requirements...................................................................................................... A-1

A.2 Mobile Client Requirements........................................................................................ A-3

A.3 Personalization Update Requirements ....................................................................... A-5

Requirements Summary

Basic Requirements

©2009 MasterCardA-1Mobile MasterCard PayPass TSM Functional Requirements November 2009 - Version 1.0

A.1 Basic Requirements

Table A.1—Section 2.1 Approval Compliance

REQ 1Approved handsetprovisioning

TSM must offer maximum protection to thecardholder details by ensuring that provisioning onlyoccurs on handsets containing MasterCard approvedcomponents.

REQ 2 Component approvalThe TSM must establish the approval status of thehandset components at the earliest point within theprovisioning process.

REQ 3Unrecognizedcomponent

Should any of the components within the handset notbe recognized as approved, the TSM must be able toterminate the process immediately withoutcompromising the cardholder assets.

Table A.2—Section 2.1.1 ID Lookup

REQ 4Component IDRequests

The TSM Service must be configured to send IDrequests to the components in a handset that isinitiating the personalization process.

REQ 5Non-response bycomponent

In the event of a non-response to any of the IDrequests, the TSM must assume that the componentbeing interrogated has not attained type approval.

Table A.3—Section 2.1.2 Approval Cross-check

REQ 6Contactless Modulevalidation

The Contactless Signal Processing Component andContactless Antenna must have passed through theapproval process within the same assembly.

REQ 7 SE ValidationThe silicon manufacturer and the silicon type must berecognizable and must have passed through functionaland security approval by MasterCard.

REQ 8Operating systemvalidation

The operating system and its version number mustreside on a list of MasterCard approved operatingsystems.

REQ 9Payment applicationvalidation

The TSM must query the payment application nameand version number as referenced in the approvaldocumentation.

REQ 10Payment applicationvalidation

In cases where the TSM is provisioning the paymentapplication themselves, they must ensure that anapplication is used, which has been approved as partof a Secure Element Approval


Basic Requirements

A-2©2009 MasterCard


Table A.4—Section 2.2 User Verification

REQ 11TSM Verification Codegeneration

Where the User Verification Code is generated by theTSM on behalf of the Issuer, the TSM must have asecure method of notifying the cardholder of thiscode.

REQ 12Secure transfer ofVerification Code fromhandset

A transfer key must be employed to ensure encryptedcommunication of the Verification Code between thecardholder and the TSM during the provisioning.

REQ 13Personalisationinitiation viaVerification Code

In order to initiate the Personalisation of thecardholder details, the request of the VerificationCode from the cardholder is Mandatory.

REQ 14De-personalizationoption availability

The TSM must allow the Issuer or the Cardholder torequest the de-personalization of the handset.

REQ 15Verification code entryon de-personalization

In order to complete execution of the de-personalization, the user confirmation via theVerification Code is Mandatory.

REQ 16 Disable payment optionThe TSM must provide the ability to temporarilydisable the service on the handset at the Issuer’srequest.

REQ 17Verification Code entryon disable option

Entry of the User Verification Code is mandatory forthe successful execution of the disable function.

REQ 18 Enable payment optionThe TSM must provide the ability to enable theservice on the handset (that has previously beendisabled) at the Issuer’s request.

REQ 19Verification Code entryon enable option

Entry of the User Verification Code is mandatory forthe successful execution of the enable function.

Table A.5—Section 2.3 User Opt-In for Default Up-Date

REQ 20User Opt-In for DefaultUp-Date

If during a perso the TSM solution includes an updatefeature to set the new account as the default on aSecure Element, this must be based on a user opt-in.An automatic update without the user’s knowledge oracceptance is not allowed.

Table A.6—Section 2.4 Load Balancing

REQ 21Concurrentpersonalization

Multiple concurrent provisioning processes must bepossible without impact on the reliability or speed ofindividual personalization on different devices.


Mobile Client Requirements


Table A.7—Section 2.4 Issuer/TSM Interface Security

REQ 22 Message encryptionThe interface will carry personal cardholder detailstherefore an encryption method must be agreed forthe transport of the messaging or file.

Table A.8—Section 2.5 SE Cryptographic Requirements

REQ 23Protection of assetswithin the SE

The TSM must replace the original keys that securethe SE with others which are specific to theirimplementation as part of the original provisioningprocess.

REQ 24Standards ofcryptographicprotection

The TSM must prove (on inspection) that theirinstallation meets industry standards for the retentionof cryptographic data.

A.2 Mobile Client Requirements

Table A.9—Section 3.1 Deactivated Features/Functions

REQ 25Disablement ofDeactivatedFeatures/Functions

Any features that are part of a UI or WalletApplication that are not usable in a particularimplementation must be hidden or made invisible toavoid confusion to the end user.

Table A.10—Section 3.1.1 Verification Code Mandatory for all Personalization

REQ 26Verification Code oninitial personalization

The entry of a Verification Code is mandatory for theinitial personalization of the handset.

REQ 27Verification Code foruser initiatedprovisioning actions

Verification code entry is mandatory for any userinitiated provisioning actions against a fullypersonalized handset.

Table A.11—Section 3.1.2 Code Creation

REQ 28Interface requirementfor Verification Code

The TSM must retain attributes within their interfacewith the issuer/registration source to accommodate auser defined Verification Code.

REQ 29 Interface security

The Verification Code must not be exchangedbetween the handset and the TSM (duringprovisioning) without industry-recognized encryptionbeing in place.


Mobile Client Requirements



REQ 30TSM/IssuerVerification Codegeneration

The TSM’s or Issuer’s Verification Code generationutility must not be sequential in nature, nor should itbe easy to predict.

REQ 31Secure communicationof Verification Code touser

The TSM or Issuer must have a secure facility forcommunicating the Verification Code to the userprior to personalization.

Table A.12—Section 3.1.3 Verification Code Entry during Personalization

REQ 32UI requests forVerification Code

The UI must request correct entry of the VerificationCode prior to the transfer of any cardholdercredentials to the Secure Element (SE).

REQ 33Unsuccessful attemptthreshold

A threshold of unsuccessful entries by the cardholdershould be instated on the TSM’s service

Table A.13—Section 3.1.4 Verification Code Length

REQ 34Verification Codedimensions

The minimum length of Verification Code should befour (4) characters.

Table A.14—Section 3.1.5 Verification Code UI Appearance

REQ 35Verification Codemasking within UI

The Verification Code should not appear “in theclear” on the user’s handset when it is entered. Amasking technique should be used to preserve thesecurity of this code.

Table A.15—Section 3.2 Disruption Resistance

REQ 36Personalization impacton handset functions

The personalization process must not have a negativeimpact on normal functions of the handset.

REQ 37Handset functionimpact onpersonalization

The personalization process must not be impacted byusual handset functions.

REQ 38Incoming call duringprovisioning (ignore)

During the personalization process, an incoming callmust not cause automatic termination of theprovisioning action.

REQ 39Incoming call duringprovisioning (answer).

It must also be possible to accept a call and allow theprovisioning process to continue in the background,uninterrupted.

REQ 40Incoming SMS/MMsduring provisioning(ignore)

The provisioning process must be able to completewhile a received SMS or MMS is retained within theinbox for viewing at a later time.


Personalization Update Requirements


REQ 41Incoming SMS/MMsduring provisioning(view)

It must be possible for the user to view an incomingSMS/MMS during the provisioning process.

REQ 42Incoming email duringprovisioning (ignore)

Where the handset includes an email function, thereception of an email on the handset during theprovisioning process must not terminate thepersonalization.

REQ 43Incoming email duringprovisioning (view)

It must be possible for the user to view a receivedemail during the provisioning process.

Table A.16—Section 3.3 Tearing Recovery

REQ 44Resumption followingdisconnect duringprovisioning session

When the user recommences a session followingdisconnection during personalization, the TSM serviceshould recommence at the point that it failed andshould not restart from the beginning.

REQ 45Security considerationfor resumption

The recommencement must be a secure resumptionand the user must be requested to re-enter theirVerification Code to ensure that they remain oncontrol of the handset.

A.3 Personalization Update Requirements

Table A.17—Section 4.1 Personalization Updates Allowed

REQ 46Personalization eventsfollowing initialprovisioning

The following, additional personalization events mustbe supported by the TSM service:

Card replacement

Card renewal

De-personalization

Upgrade of the payment application

REQ 47Interface attributes foractions required

The interface specification between the Issuer and theTSM must support attributes that will allow theidentification of the action that the provisioningprocess needs to take.


Personalization Update Requirements



Table A.18—Section 4.2 Denial of Duplicate Personalization Request

REQ 48Duplicatepersonalization

During the first phase of the initial personalization,the TSM should establish whether the SE alreadyholds a valid card and terminate the process if this istrue.

Table A.19—Section 4.3 Personalization Update Error if No Payment Application Present

REQ 49Personalization withoutpayment application

If a payment application is absent from the handset,the personalization update process must beterminated immediately.

Table A.20—Section 4.4 Payment Application Upgrade

REQ 50Payment Applicationversion update

The TSM must provide the facility to send the latestversion of the payment application directly to thecardholder’s handset.

REQ 51Continuity of servicefollowing versionupdate

The process must not overwrite the existingcardholder details held within the SE, nor must itrender the handset unavailable for transactions.

Table A.21—Section 4.5 De-personalization Supported

REQ 52User verification for de-personalization

The de-personalization process must request entry ofthe Verification Code from the cardholder.

REQ 53Outcome of de-personalization

The de-personalization process must render thecardholder details unavailable to the paymentapplication.

REQ 54 SE legacyIt must be possible to re-personalize the SE followingsuccessful de-personalization.

Mobile Master Card PayPass TSM Functional Requirements v1-0

Documents

Transcript of Mobile Master Card PayPass TSM Functional Requirements v1-0