The Preferred Payment Architecture Technical Documentation

Transcription

1 Mobey Forum / LK /45 The Technical Documentation Requirements for manufacturers and standardisation bodies Version 1.0 Approved by the Mobey BoD on Editor: Liisa Kanniainen Workgroup Executive, Mobey Forum Legal Notice This document is designed to provide a general overview of Mobile Payment Architecture. It is released and delivered with the understanding that the recommendations and opinions in this document shall not be regarded as legally binding opinions or recommendations. In addition no country specific regulation is included in this document. Readers are advised to review this information and check the country specific or payment system specific rules separately. No legal responsibility will be accepted by Mobey Forum Mobile Financial Services Limited (the Mobey Forum) or by the authors for the opinions appearing in this document.

2 Mobey Forum / LK /45 The copyright of all matter and content appearing in this document is reserved by Mobey Forum Mobile Financial Services Limited. No matter contained herein may be reproduced, duplicated or copied without the prior consent of Mobey Forum Mobile Financial Services Limited.

3 Mobey Forum / LK /45 Table of Contents 1 INTRODUCTION THE CONSOLIDATED MOBEY REQUIREMENTS EVALUATION OF THE PAYER S PAYMENT ARCHITECTURE TECHNICAL BACKGROUND The WAP PKI Model SIM Application Toolkit (SAT) Introduction to Personal Trusted Device (PTD) Security Element (SE) Maintenance of the Security Element Core Functions END USER AUTHENTICATION AND NON-REPUDIATION Selection of the authentication method MAIN HANDSET ALTERNATIVES AND THEIR ENROLMENT PROCESSES ALTERNATIVE HANDSET SE IMPLEMENTATIONS Security on Dual Chip Security via Dual Slot Security on SIM Card (SIM/WIM) Security in Terminal Software or Hardware Password Authentication TECHNICAL ANALYSIS OF THE HANDSET SE IMPLEMENTATION ALTERNATIVES Analysis Conclusions MAPPING THE ALTERNATIVEHANDSET SE IMPLEMENTATIONS WITH THE MOBEY REQUIREMENTS CONCLUSIONS CONCERNING THE PREFERRED PAYER S ARCHITECTURE EVALUATION OF THE PAYEE S PAYMENT MODELS THE WALLET INCLUDING THE PAYMENT PRODUCTS Server Based e-purse Server-based credit cards Account-based payments Local e-purse Local credit or debit card THE PAYMENT PROTOCOLS Mail Order / Telephone Order (MoTo) Interoperability Domain Security Protocols Ebpp (electronic bill presentment and payment) One-time credit card number EMV TECHNICAL ANALYSIS OF PAYMENT PRODUCTS AND PROTOCOLS Technical analysis of Remote Payments Technical analysis of Local Payments MAPPING OF PAYEE S PAYMENT MODELS WITH THE MOBEY REQUIREMENTS Payee s requirements for Remote Payments Payee s requirements for Local Payments Evaluation against the given criteria CONCLUSIONS CONCERNING THE PREFERRED PAYEE S ARCHITECTURE... 34

4 Mobey Forum / LK /45 4 THE MOBEY PREFERRED PAYMENT ARCHITECTURE INTRODUCTION TO THE PREFERRED PAYMENT ARCHITECTURE PTD with SE in the Preferred Architecture THE PREFERRED ARCHITECTURE FOR REMOTE PAYMENTS The Proposed Purchase Process Process Details THE PREFERRED ARCHITECTURE FOR LOCAL PAYMENTS An EMV-based model with a dual chip phone Proposed Purchase Process Process Details... 44

5 Mobey Forum / LK /45 1 Introduction The objective of the Mobey Forum is to enhance the use of mobile technology in the financial services market, including banking, payments and brokerage. The methods of Mobey to achieve this are by creating business and technical requirements, evaluating potential business models and technical solutions, and then making recommendations to standardisation bodies, handset manufacturers, payment schemes and technology suppliers to implement the required solutions. The scope of this document is to align the Mobey Forum s consolidated view on the technical aspects of mobile payments for a mass-market solution. The user experience for the enrolment process of the handset alternatives is likely to differ somewhat by the main alternatives; the main differences are explained in the following section (1.1). Next the most important joint requirements of Mobey banks for a preferred solution answering these requirements are explained (Chapter 2). The requirements are studied in more detail in Mobey Forum s (PPA) Business Document. The alternative mobile payment solutions are evaluated from a payer s (Chapter 3) and payee s (Chapter 4) point of view. A preferred architecture is then described for Remote and Local payments (Chapter 5). In addition, the needed actions to achieve and implement the preferred architecture are described (Chapter 6). The target audience for this document are members of standardisation bodies, handset and middleware manufacturers, financial services providers, network operators and other companies or fora/forums interested in mobile commerce. It is suggested, that this document is read in connection with the Mobey PPA Executive Summary Document and Business Document. All conclusions, based on both Business and Technical Documents are explained in the Executive Summary Document. Many different technology fora/forums have suggested that the mobile phone will become an accepted method of payment for goods and services. There are obvious reasons for this; the number of people carrying mobile phones in the world is growing rapidly, and in many places (e.g., in 3 rd world countries) there is already many more mobile phones than payment cards. Although usage of mobile phones for payments has been suggested a number of times in the past, to date there have been no agreements as to how this would work particularly when taking into account the large number of different channels and payment methods that currently exist. This document looks at the payment models that have been suggested; the business, trust and technical requirements of such a system, along with the proposed payment scenarios. By mapping these together a workable overall payment model will be recommended. 1.1 The Consolidated Mobey Requirements In this chapter, the top 20 consolidated requirements of the Mobey Forum are presented. These requirements form a basis for selecting the technical architecture, and are therefore presented here as relevant background information. A more thorough description of these and other requirements defined by Mobey banks are available in the Mobey Forum s Business document. The top 20 requirements of the Mobey Forum for mobile payments are as follows: 1 Ease-of-use 2 Protection against fraud 3 Speed/transaction time

6 Mobey Forum / LK /45 4 Price (for customer) 5 Confidence that data will not be forwarded 6 Customer and merchant authentication 7 Assurance of genuine payment destination 8 SIM change independence 9 Standards based (interoperable) 10 Transaction level security 11 Merchant acceptance 12 Not operator-specific 13 Use of existing or planned infrastructure 14 Set-up costs per consumer 15 Customer enrolment 16 Cost to implement (merchant) 17 Cost to implement (consumer) 18 Existing solution availability 19 Support of multiple payment products 20 Potential to add brand The customer proposition was considered to be the most important major category of requirements; simply on the understanding that if a mobile payment service was not easy-touse, did not provide value-for-money, was not convenientand was not appealing to the user, then it would not succeed. In addition to the high level of perceived and technical security, the main business requirement is the concept of personal trust along with ease-of-use for customers. It also includesthe belief that the customer should not be forced to select a specific operator to take advantage of the service. As every bank cannot be expected to forge bilateral agreements with all operators in their specific markets, operator-independence is a necessity for a global solution architecture. All of the Mobey consolidated requirements are described in detail in the Mobey Preferred Architecture Business documentation.

7 Mobey Forum / LK /45 2 Evaluation of The Payer s Payment Architecture The aim of this Chapter is to evaluate the alternative ways to implement the payer s end of the preferred payment architecture. First, we would like to highlight the technical background and explain some necessary terms and concepts (section 2.1). Secondly, we study the implications of the different choices of handset (security element) implementations (section 2.2), such as a single chip (SIM/WIM), dual chip, dual slot and a non-removable hardware or software security module solutions. In addition, password-based authentication mechanisms are considered. The third section (2.3) is formed of an evaluation of the payer s handset implementation alternatives against the requirements set forth by the Mobey Business workgroup. 2.1 Technical Background The relevant background technologies that need to be comprehended are the WAP PKI model, particularly the WIM and WTLS specification by the WAP Forum, and SIM Application Toolkit (SAT). They are explained in this chapter to provide an overall picture of the technical background. More information of the detailed technologies is available from the respective sources (see References). Other relevant technologies are handset and the trust token related concepts such as the Personal Trusted Device (PTD) and the Security Element, both of which are defined by the Mobile electronic Transactions initiative (MeT). There are several issues such as the way the user is authenticated to the SE and management of the SE, which are also explained here. Finally, the core functionality is explained The WAP PKI Model This section provides an overview of the PKI model being used and includes a partial walkthrough of the processes involved when a WAP client registers a new PKI. WAP Domains It is envisaged that there will be a number of trust domains implemented in WAP, which can be segregated as follows: 1. Manufacturers 2. Network operators 3. Wireless service providers 4. Content/services providers (e.g., banking domain) 5. Trusted third party domains 6. Device owner (fleet operator domain) It is expected that different domains will have different rights associated with them. Domains will be classified as follows:! We define a primary domain to be a high trust system domain. The domains likely to be primary are manufacturer, service provider and/or operator.! Secondary domains are domains existing on the device for general operation that may be administered by a primary domain. Certificates come in the form of 3 different levels of trust, taken from the system perspective:

8 Mobey Forum / LK /45 low trust medium trust high trust Low trust certificates are those not mapping back to any recognised trusted root, i.e., personal certificates. Medium trust certificates are those mapping back to (authorised by) a system that is a recognised and trusted third party certifier. High trust certificates are those mapping back to one of the primary domains. [WPKI] WAP Identity Module (WIM) WIM is included in the WAP 1.2 specification and is defined as a tamper-resistant and independent chip card application. The WIM can be used to protect the certificates and their associated private keys. The WAP Identity Module (WIM) is used in performing WTLS (see below) and application level security functions, especially to store and process information needed for user identification and authentication. An example of a WIM implementation is chip card, which can be the SIM or an additional chip card. [WAP WIM] A WIM provides private key storage and digital signature computation. Wireless Transport Layer Security (WTLS): The primary goal of the WTLS layer is to provide privacy (encryption), data integrity (message authentication codes) and authentication (certificates) between two communicating applications. WTLS Class 2 provides the capability for the client to authenticate the identity of the gateway it is communicating with. In WTLS Class 3 (client authentication) the client's private key is used to sign a "challenge" from the WTLS server, as explained in the WAP Forum's WPKI specifications. [WPKI] The WIM MUST be used for WTLS Class 3 operations and SHOULD be used for WTLS Class 1 and 2 operations (e.g., secure session creation and storage and/or CA certificate storage), if applicable. [WAP WIM] SignText: One method for transaction authorisation is to associate a digital signature with the data generated as the result of a transaction, such as a purchase order or other financial document.to support this requirement, the WAP browser provides a WMLScript function, Crypto.signText, that asks the user to sign a string of text. A call to the signtext method displays the exact text to be signed and asks the user to confirm. After the data has been signed and both the signature and the data have been sent across the network, the server can extract the digital signature and validate it, and possibly store it for accountability purposes. [WMLScript Crypto Library] SIM Application Toolkit (SAT) SIM Application Toolkit (SAT) is a proprietary technology enabling development of additional applications residing on the SIM card. The applications made with SAT are under control of the SIM application. SAT applications are card specific, i.e., every chip card manufacturer has their own implementation of the SAT meaning an application written for one manufacturer s cards has to be rewritten for the other manufacturer s cards. SAT is specified in GSM specifications and In a SIM/WIM card, SAT applications may have access to WIM data. It may be allowed to download native (binary) SAT applications. All existing dual slot implementations are based on SAT. Many major mobile phone manufacturers have indicated their unwillingness to produce dual slot phones, mainly because of the size and usability issues. Thus, in practice the only access method for a third party dual slot accessory is to use SAT.

9 Mobey Forum / LK / Introduction to Personal Trusted Device (PTD) This section defines the mobile phone as a PTD, and its interface with relevant entities. In considering the Personal Trusted Device (PTD), the following aspects are relevant: It fulfils the requirements put on devices qualified to make legally binding digital signatures, such as the European Electronic Signature Standards Initiative. It is personal, controlled and used by one person and carried by that person most of the time. It has an application platform with associated user interfaces for transaction related services such as banking, payment, bonus programs and ticketing. It has the security functionality required for transaction related services: secure sessions, authentication and authorisation. The PTD contains a Security Element, which is used for protecting its most critical data, such as private keys. A PTD employs a mechanism for user verification (to verify the person to whom the PTD belongs). Only upon successful user verification may the PTD be used for transactions. The Security Element executes the user verification (e.g., a chip card that performs cryptographic operations only after receiving a PIN entered by the user). In order to access multiple services, the PTD uses a certificate database for service specific certificates. It contains actual certificates or pointers to certificate locations (certificate URLs). Additionally, the PTD may contain a transaction database (for contracts and receipts/tickets) Security Element (SE) Using a Security Element (SE) is essential in the Mobey Architecture, since strong authentication with a mobile PKI solution is required to be included in the architecture as an important option. The SE is used to store cryptographic keys and perform operations using these keys. The Security Element can be removable or non-removable. A removable SE can be based on an open chip card or implemented according to [WIM]. It may be implemented as an chip card or other removable hardware element. The chip card based SE functionality may contain a WIM chip card application and other applications such as EMV application for payments. According to WIM specifications it can reside in a card used for wireless network subscriber identification such as the GSM SIM card [GSM11.11], USIM card [USIM-101], [USIM-102] or an auxiliary card. A non-removable SE is implemented as an embedded hardware module or as a software module with cryptographic processing. Figure 1: Security Element implementation options

10 Mobey Forum / LK /45 Security Element Removable Non-removable Open Chip Card Other WIM Module Flash Card Embedded HW Module SW Module WIM application EMV application Other Application WIM application EMV application Other Application Maintenance of the Security Element SE management covers actions that are taken both before and after the SE is delivered to the user. There are several functions that need to be performed. The security element needs to be ordered from the supplier and the order registered, personalisation information needs to be provided and the key management and generation need to be agreed. Certificates need to be manufactured and downloaded to the SE. The SE needs to be registered and activated. Status of the SE needs to be known to the issuer at all times. When there is one card issuer in a multi-service provider environment, application management can be difficult. One solution to the problem would be to have a trusted third party to manage the applications securely. Another, perhaps a more realistic solution, would be to organise an agreement between the banks on either one-to-one basis or with an umbrella agreement. Application administration consists include application revocation, revocation of the whole card, adding and deleting applications, as well as unblocking the card or applications on it. The complexity and processes are the same as in today s card infrastructure, but added with the complexity of a multiapplication and multi-service provider environment. The processes and authorisations for the described functions above vary from country to country and also by different issuers. It is therefore essential that the issuer has the ability to securely manage the SE. Unblocking PINs In case the user has lost their PIN (or otherwise blocked the SE), the user can receive an unblocking code from the SE provider service centre afterconfirming user identity verification. User identity verification is based on either physical presence or being able to answer to a series of question. The issuer of the security solution, a bank in most cases, must be able to define the details of this process. Revocation If the SE (or entire PTD) has been stolen, the user should be able to contact the SE Provider for revocation. The SE Provider may or may not offer a revocation service to be used by service providers. If this revocation service is available, service registration providers can revocate service certificates issued for keys in the SE. If this revocation service is not available, the user is then instructed to contact each service registration provider separately. [MeTPTDSec] Core Functions Initialisation PTD initialisation means equipping a Security Element with the initial private public key pairs and root CA certificates necessary to execute secure transactions. Keys may be provided externally

11 Mobey Forum / LK /45 through a removable Security Element or the keys may be generated internally in an embedded Security Element. Root CA certificates may be provided as a part of the initialisation process. Registration Registration is the means by which a service provider associates the user s identity with a service account. This is done by issuing a user service certificate for the key to be used when engaging in mobile commerce transactions with this service. Issuing service certificates can be done over the air. This process can utilise existing manufacturer certificates installed in the PTD s SE during manufacturing together with authenticating the user by means of a PIN for example. The process of registration personalises the PTD for the user. Secure Session Establishment A secure session has the following components: confidentiality, data integrity and server authentication. Ideally the secure session is between the PTD and the content server. Authentication User authentication is the means by which a service provider determines the identity of a user. It allows the service provider to verify that the user is entitled to use the service. WTLS class 3 provides the highest standard for performing user authentication. This allows the WAP gateway to establish the identity of the user by means of the user service certificate related to the private key stored in the PTD s Security Element. PTD authentication is established by the server s sending the PTD a challenge, which the PTD signs and returns. User Authorisation Authorisation is the means by which a service provider ensures that the user has viewed and accepted a transaction contract. Usually issuing bank authorises the user and takes the liability of the transaction thereafter. Authorisation is achieved by digitally signing the transaction contract using a private key associated with a user service certificate. The service provider may store the signed transaction contract as a record of the transaction authorisation. The WAP WMLScript signtext function provides highest standard today available for authorisation. The details of the signtext function are described in [WMLSCrypt]. Key Generation: Case 1: Outside of the Device In this case, the key pair is generated outside the device and then saved in the device. In this case the generation procedure and saving needs to be highly secure. The advantage in this method is that the device need not support key generation, which may be demanding for a low-end device while maintaining the high-quality of the key. The disadvantage is that the generation procedure must be highly secure which may be administratively difficult to achieve. Case 2: Key Generation by the User In this case, the key pair is generated inside the device after the manufacturing process, when the module is already in the possession of the user. In this case, the device has an initial management key pair (an individual key per device) that has been issued a device certificate (created as described in the case 1 or 2). This key can only be used internally by the device to certify newly generated keys (i.e., the device does not allow this key to be used for ordinary purposes). [WPKI] Key and User Certificate storages: A mobile terminal stores only a certificate URL, the actual certificate is processed by the network. Note: A WIM offers a very secure storage for certificates and keys. The emerging legislation, related to legally binding digital signatures, needs to be followed up. Note: Legal requirements to certify handsets, to qualify them for making such signatures emerge, may need to be defined or legislated.

12 Mobey Forum / LK /45 The EMV-related core functions are yet to be specified once the EMV-based solution is available. 2.2 End User Authentication and Non-repudiation There are various options that banks can use for authenticating the end user. At least the following authentication methods exist and should be considered as potential options: MSISDN /CLI, i.e., the calling phone number Static password / username based authentication Use of shared secret, e.g., symmetric keys for signing the message One time password lists / challenge-response solutions Authentication based on mobile PKI, e.g., WIM The decision, as to which authentication method is to be used, depends on the issuer. The issuer makes this decision usually based on certain facts and requirements. The study of the decisions based on these requirements is not included in the scope of this documentation. However, it is requested that different levels of authentication must be enabled, ranging from lightweight to strong security. At the same time other key requirements, including end user convenience, have to be kept in mind. Most of users find passwords as a good way to get access to confidential data and to secure their privacy. A regular mobile terminal, even without mobile e-commerce applications, already has several codes that may confuse the user. Therefore the number of codes should be minimised. Although the codes make the user feel secure, too many different codes will more than likely discourage the use of mobile e-commerce applications. It is therefore preferable to unify some of the codes if possible. Digital signing may be used for authentication or non-repudiation purposes, e.g., to sign a document or to confirm a transaction. For non-repudiation, the user is requested to enter authentication information, PIN for example, for every signature made. Using a PIN code is a commonly used user verification method. For security elements there are codes, which are required for some operations and in some situations. After the correct code is entered, the PTD may operate on security element data, which is protected by these codes. The user must always be aware of the source of the each prompt displayed in PIN queries, i.e., the user must know if the prompt is from the PTD or if it is received from an external source. [MeTCUE] Selection of the authentication method Most of the above-mentioned authentication methods will be enabled by the Mobey Forum s preferred payment architecture: Lightweight authentication can be based on CLI, medium level authentication needs could employ static passwords that are already in use in many solutions and for an even better level of security, one-time password lists can be used. While convenience is the most important requirement, a high level of security is a prerequisite (e.g., strong authentication has to be supported by the solution). Combining these two requirements is not easy task; long passwords are not easy to remember or to write in the small display and one time password lists are cumbersome to carry. However, both of the above mentioned requirements are fulfilled with WIM based authentication. That is therefore the preferred solution and the long-term migration path for end user authentication.

13 Mobey Forum / LK / Main handset alternatives and their enrolment processes The dual chip solution refers to a mobile handset equipped with an additional SIM-size chip card including one or multiple applications, issued by a bank or another trusted third party. There can be multiple applications from various service providers on the same chip card. When using the service, the user selects the required payment method from the internal card. For the dual chip solution enrolment, the user experience is such that the user buys a handset as usual and receives a SIM card from the network operator when making the service agreement as normal. The user then obtains another chip card from their bank or other trusted service provider when making the banking service agreement (or as an amendment to it). Users may later download over the air (OTA) new applications to the second chip card. The dual slot solution refers to a concept where the consumer has multiple cards in their (physical) wallet and the handset is equipped with a full-size card reader. When using services, the user selects the required card from the wallet, inserts it into the slot in the phone, makes the transaction and removes the card. The dual slot enrolment user experience is such that the user buys a handset as usual and receives a SIM card from the network operator when making the service agreement as normal. The user receives other chip cards from multiple service providers, for example their bank when making the respective service agreements. If a SIM Application Toolkit (SAT) dual slot phone is considered, only cards from service providers having a commercial agreement in place with the network operator providing the SIM card may be used. In this case the network operator may also be in a position to distribute these other cards. The SIM/WIM solution refers to a concept, where the bank-issued security credentials are stored on the network operator issued SIM card. When using the service, the user authenticates him/herself by inputting a PIN-code, which the WIM application on the SIM card validates. Since it is not possible to put (local) payment applications on the operator-issued SIM card, new protocols have to be defined if local payments are to be made. The user experience for SIM/WIM enrolment is such that the user buys a handset as usual and receives a SIM card from the network operator when making the service agreement (as normal). The user then contacts the bank or other service provider to get the banking service activated. If there is an agreement in place, concerning the use of the SIM card between the bank and the particular network operator, a banking service can be activated. The bank can then authenticate the user with an existing method. Depending on the implementation chosen, it may or may not be required that the user goes to the bank personally. The bank may download it s own keys to the SIM card, it may put there its certificates (on top of the operator keys) or it may trust the certificates of a third party which may reside on the SIM card already and allow access to banking services based on them. Software / hardware based concepts mean that the security credentials (e.g. private keys) are stored in the phone memory, either only in software or in a tamper-proof hardware embedded into the phone. WIM specifications by WAP Forum does not recognise a software based WIM implementation, and also note that a phone hardware based implementation has not been evaluated by the WAP Forum. Since the manufacturing processes of mobile phones and chip cards, are rather different using the phone hardware for storing confidential data to allow access to banking services would cause requirements from banks to audit the manufacturing processes of phones. There are also additional issues, which make these solutions more complicated: the management of bank issued applications, especially security related, in the phone hardware or software mean two separate concerns that are dependent on each other (the banking relationship and potential change of handset). The enrolment user experience in the hardware / software scenario would be such that the end user purchases their phone as usual, receives the SIM card as normal, and downloads the banking application OTA to the handset or visits the bank branch to receive it, depending on the deployed solution.

14 Mobey Forum / LK /45 The payment protocols evaluated may apply to a range of devices but for simplicity we refer to mobile phones only throughout this document. 2.4 Alternative Handset SE Implementations The purpose of this chapter is to describe the various possibilities in the mobile handsets to fulfil the requirements set forth in earlier chapters. This section describes alternatives for implementing the security functionality (SE) in the mobile terminal. Five different security implementation methods are covered: (i) Dual chip (ii) Dual slot and external chip card reader (iii) SIM card and (iv) Handset software or hardware. The following figure shows the major alternative handset implementation options of the Security Element. The SE implementation options were already explained in earlier chapters. Figure 2: Alternative handset implementations of the Security Element Security Element Removable Non-removable Dual Chip SIM/WIM Dual Slot Embedded HW Module SW Module Plug-in Size Chip Card (bank-issued) Flash Memory Card Plug-in Size Chip Card (white label) Integrated Chip Card Reader (SAT-based) External Chip Card Reader (e.g. Bluetooth connected) Security on Dual Chip The dual chip implementation uses a second chip in addition to the SIM to provide the security functionality. This implementation alternative is further divided into three categories depending on the nature of this second (dual) chip, i.e., whether it is realised as a (i) standard chip card, issued by a bank, (ii) secure Flash Card, issued usually by a bank or (iii) a white chip card, in which case the chip is issued by another third party Standard Smart Card (Dual Chip) The security functionality such as key generation, key storage, and certificate storage is integrated into a standard chip card. This plug-in sized chip card is located inside the terminal and can be removed by the user.

15 Mobey Forum / LK /45 This alternative is backed by the following advantages: I For the customer High level of convenience and usability - easy to use with one hand when on the move. No additional gadgets, password lists or loose cards needed. More secure than an ordinary wallet as the use is protected by a PIN code. Multiple functionalities can be put on the same chip - fewer cards needed. Serves multiple needs, for example, m-banking, m-payments and e-identification; where the mobile phone becomes a generally accepted identification tool. Only way to make independent m-payments with leading card brands (Visa and Mastercard products cannot be put on non-bank issued cards). High trust as the familiar bank issues the payment chip. Imports customised and personalised services to mobile terminal from the e-bank. End-to-end security guarantee, since the bank controls the security application. II For the merchant New business opportunities both for local and remote payments. Opportunity to have a very large customer base carrying bank association cards. Acquiring agreements in place no need to make any new commercial agreements. Existing payment infrastructure in place (invested), only m-commerce gateway upgrade is needed for remote payments. New customers due to a convenient service. Faster checkout in proximity payments (not server based - direct EMV-based solution). Further link to bank-hosted e/m-commerce market places. Potential to link to other mobile services offered by the merchant. III For the mobile terminal manufacturer More value delivered with the easier use of the terminal for m-banking and m-payments. Support from strong bank and card brands in promotion process. Element of trust added to terminal - generally accepted identification tool Very large sales as there is a large number of bank branches and high volume direct mail to promote the additional chip Tools for enabling new services in the handset IV For the operators More traffic (increased revenue) as m-banking becomes easier and common place Less risks as payments are administered by banks Less investments in card management systems Better security and trust V For the banks A network operator independent solution - enables non-operators to provide security functionality Payment applications can be defined by the bank Exceptional branding opportunity for banks Better value proposition for customers with a larger service scope More convenience in m-banking and card payments for customers Better volumes in banking and more card payments - less cash New income from multi-application card services New customers Added value to the customers and cost savings for banks since card management can be achieved over the air - new applications can be downloaded to the card.

16 Mobey Forum / LK /45 Fewer card products to support - lower cost in long term (with multi-application cards debit, credit and e-purse applications will eventually reside on the same card). Less fraud - payments signed by PIN. Lower cost for e- and m-banking access codes. Availability of the pilot terminals expected in the near future. Conforms to the WIM requirements. Suitable for providing a high level of security. The disadvantages of the standard dual chip solution are Issues related to multi-application chip issuing to be solved; management of multiple applications from various providers on the same chip is problematic and an inter-bank acceptance structure needs to be created. Additional costs to banks since payment service providers must issue an extra chip dedicated for use in wireless terminals. Some additional size to the mobile phone due to the second card reader. Changes in the handset architecture possibly required. Cost of extra chip card reader and new hardware in the handset Secure Flash Card (Dual Chip) The security functionality is implemented in a removable Secure Flash Card security token located inside the terminal. Flash Cards are memory cards that can be inserted into several of today s highend phones. As the amount of content handled by mobile phones grows constantly as we head towards 3G services, there is an increasing need for additional memory in the phones. It is thus expected, that in future phones there will be wider adoption of Flash Card type memory. In today s Flash Cards there can be up 64MB of memory on one card. The development of Secure Flash Cards is on-going. This means, that a chip card level secure architecture will be implemented on the Flash Card. It is expected, that this development work will still take a couple of years before Secure Flash Cards are in wider commercial use. Advantages of the Secure Flash Card: Provided that the bank issues the Flash Card, this solution s advantages are mostly the same as above, however the following may also be added: Enables the issuer of the token (e.g., banks) new business opportunities; a lot of space available for additional applications Flash Cards will be available for mobile handsets for other reasons as the slot will already be there A wide installed base of handsets are already available today Processing of applications is faster than in the chip card environment 3G proof concept in future handsets a much more content/information will be handled Enables thick mobile client concept The corresponding disadvantages comprise Payment providers must issue a new type of token dedicated for use in wireless terminals. Secure Flash Cards are not yet in the market and not yet approved for bank use (early part on adoption curve).

17 Mobey Forum / LK /45 Potential high costs of secure Flash Cards with a lot of memory (e.g., how to organise selling the memory to the end user?) White Smart Card (Dual Chip) The security functionality is implemented in a generic security chip card located inside the terminal. A neutral third party such as a government authority issues this generic security chip card. This solution is supported by the following advantages (in addition to the above): Opportunity for a neutral third party to provide security functionality and to set the rules for multi-application chip cards Provides a solution to the multiple cards problems (dual slot) and to the issues with multiservice provider and one card only cases (standard dual chip or SIM/WIM). The corresponding disadvantages comprise of Requires heavy marketing and currently it is still a project laden with risk since the service concept is totally new. Doesn t suit all markets. Who bears the cost of issuing and managing white chip cards what is the issuer s business operandi (if any?) Banks won t control the security token in this case, but a trusted third party controls it. The token cannot be controlled by the end user; since nobody controls the security of it and therefore who is responsible for the consumer if something happens? Banks need to trust and be able to audit the third party service providers security standards Security via Dual Slot In this solution a reader for external chip cards is integrated into the phone. Since it is not likely that there will be dual slot implementations based on open standards, the existing solutions (SAT based) are evaluated here. The advantages are following: I For the customer Concept is an obvious one and easy to comprehend - the bank chip card is tangible and a familiar payment tool. Analogy to the existing usage models. Greater perceived security as payment function is separated from the payment tool. The trustworthy card scheme brands are easily and traditionally visible. High level of perceived trust; the card is still issued by a familiar bank. For the consumer perception operator services and bank services are separated. Same payment tool can be used with multiple channels; not restricted to the mobile handset (POS, ATM). Allows the use of multiple payment cards (as long as there are agreements in place between the payment service providers and the network operator). Thus allowing the customer to have, in a convenient manner, multiple banking relations. II For the merchant Support strong authentication and non-repudiation for electronic transactions (limit fraud). Secure way of managing e- and m-commerce transactions.

18 Mobey Forum / LK /45 Possibility to use existing global interoperable payment infrastructure (m-payment gateway needed for remote payments). Acquiring agreements already in place. Access to a large customer base carrying bank association cards. New business opportunities in the remote environment. III For the mobile handset manufacturer Benefits from strong bank and card brands in promotion process. Access to large sales force as bank branches and direct mail can promote handsets and the payment scheme. IV For the operators Operator in full control of the bankcard usage in addition to the SIM card usage. Liability and financial risks still covered by the financial industry. No need to build infrastructure for managing several applications and certificates in one secure device (SIM/WIM). Less investment in card management systems. More traffic and access to new customers (m-payments). Possible access to bank s sales force. New sources of revenue form banks. Added value to operator as m-payments can be provided. V For the banks Reinforcing the role as a trusted third party. Present invested secure payment structure is retained (card present). No multiparty management problems. Increased revenue due to increased volume in card payment transactions. Access to new customers. Added value to the customers and cost savings for banks since card management can be achieved over the air - new applications can be downloaded to the card. No need to issue additional small-sized chip cards; supports existing full-sized chip cards. Reinforces the brand. Facilitates the use of many cards. Suitable for providing high level of security conforms to WIM requirements. The list of disadvantages includes Since the major phone manufacturers (e.g., Nokia, Ericsson, Siemens) have indicated that they will not produce dual slot phones, the only realistic way to acquire them in volumes would be to use third party implementations with SAT. Doesn t guarantee the independent provision of security services for banks, because of existing solutions and future ones as well (see previous) are implemented with SAT, i.e., the second card is controlled by the SIM. Is not based on open standards. The mobile phone cannot be used as a generic identification device. Significantly increased size and affect on design of the handset. Significantly increased production cost of the handset. Usability concerns: User has to insert a card when making a transaction and take it away after the transaction one hand operation not possible. Using the phone for other purposes (like answering a call) is difficult when the card is inserted. Does not enable the offering of intelligent services (see Chapter 3.3, the face-to-face use case). Additional complexity to the handset architecture due to the need to support different chip cards.

19 Mobey Forum / LK /45 Vulnerability to faults (dirt and wear) Security via External Smart Card Reader This implementation alternative relies on an external chip card reader. This reader can be connected to the terminal by cable, infrared or Bluetooth. This solution's advantages are Enables non-operators to provide security functionality Suitable for providing a high level of security Supports the use of multiple cards Card reader can be used with other terminals such as PCs Conforms to the WIM requirements Its disadvantages comprise of An external device requires large volumes to manufacture and distribute to be cost effective. External reader is still dependent of phones and phone design issues (such as Bluetooth, software to communicate with etc.). Cost of readers: nobody wants to pay extra for the readers. Consumers do not like the idea of carrying multiple devices. Usability concerns: to make a transaction, a user has to first take a card, insert it into the card reader, ensure that the reader is connected to the mobile phone, conduct the transaction, take the card away from the reader, store it back to the (physical) wallet and the reader to a case. Low convenience if the device does not support Bluetooth: concept fully depends on rollout of Bluetooth technology Security on SIM Card (SIM/WIM) The security functionality such as key generation, key storage, and certificate storage is integrated into the mobile terminal's SIM card. The advantages are in detail I For the customer Convenient for the end user all functionality is integrated into the handset. II For the merchant Support strong authentication and non-repudiation for electronic transactions (limit fraud). Secure way of managing e- and m-commerce transactions. Access to a large customer base carrying handsets with identification mechanisms. New business opportunities in the remote environment. III For the mobile handset manufacturer An inexpensive solution no additional development costs. IV For the operators Operator in control of the security solution usage in addition to the SIM application usage. Liability and financial risks would still be covered by the financial industry, as long as banks know how and by which rules the SC has been manufactured. However, the device certificate on the SIM/WIM card will solve this.

20 Mobey Forum / LK /45 More traffic and access to new customers (m-payments). Possible access to bank s sales force. New sources of revenue from banks. Adds value to the operator s service as an m-payment service can now be provided. V For the banks Reinforcing the role as a trusted third party. Suitable for providing a high level of security - conforms to the WIM requirements. No need to issue additional payment cards. Huge installed base of potentially appropriate handsets (SIMs exist in all GSM handsets; however, SIM doesn t necessarily include WIM). Time to market; there are already handsets on the market supporting SIM/WIM. SIMs are standardised and included in 3 rd generation mobile standards. The disadvantages of SIM/WIM solution include Service responsibility confusion for the end user who is responsible for the banking service? For example, whom should the consumer call if they lose their PIN code for banking services? Perceived security is not very high for the consumer, because sensitive information and applications (e.g., payment capability, access to money) are stored on a non-bank issued chip (i.e., the SIM). For operators a need to build infrastructure for managing several applications and certificates on the SIM/WIM. Key management between the parties need to be agreed; it is required for global acceptance. Thus there is a requirement to make new rules by card institutions. Additional investments by operators in card management systems. Requires making commercial co-operation agreements and sharing of sensitive information between the operators and banks on a one-to-one basis. Strengthened role of operators as gatekeepers for all mobile services. Pricing of the bank-issued WIM application on the SIM may not be agreed. Independency of providing banking services is not guaranteed (for banks). Bank s trust approval problematic: applet, keys, personalisation, manufacturing site & processes, etc., need to be audited in order to guarantee the security level. Banks relationships to corporate and private customers become problematic. Not a business opportunity for banks. Not suitable for phones and networks which do not have a wireless subscription card. Solution is impossible to be used in the local environment with the current standards (EMV application cannot be put on a non-bank issued card, e.g., a SIM card. Furthermore, EMV and SIM are not technically compliant. => Totally new protocols would need to be created. SAT based solutions do not utilise the full capability of handsets Security in Terminal Software or Hardware This implementation alternative is further divided into (i) hardware and (ii) software implementations. These differ in the common trade-off between security and ease of implementation, cost, etc. Software Solution The security functionality such as key generation, key storage, and certificate storage is integrated into the mobile handset software. The inherent advantages of a software implementation are

21 Mobey Forum / LK /45 I For the customer Relatively convenient for the end user all functionality is integrated into the handset. II For the merchant Increased security than today for managing e- and m-commerce transactions. Access to large customer base carrying handsets with identification mechanisms. New business opportunities in the remote environment. III For the mobile handset manufacturer A relatively cheap solution only reasonable additional development costs. Relative ease and speed of implementation. Relative ease of adapting modifications and upgrades. In most cases no special hardware required. Only a small increase in terminal size (additional memory, CPU or battery life may be required in certain cases). IV For the operators Liability and financial risks still covered by the financial industry. More traffic and access to new customers (m-payments). Added value to operator as m-payments can now be provided. V For the banks Huge installed base of potentially appropriate handsets. Time to market. Only marginal additional investments required. These advantages, which make it suitable for rapid development, are obtained at the expense of following Disadvantages: Not tamper-proof. Since the solution is not tamper proof, it is not suitable for mission critical applications such as electronic purse or payments. Not conforming to the requirements of WIM standard (tamper proof hardware). Not providing additional business opportunities for banks. Hardware Solution The security functionality is integrated into the mobile terminal hardware. This solution shares some of the advantages and disadvantages with the software solution (see previous section), e.g., high usability, but largely reflects the reversed security/cost trade-off. The advantages (in addition to the above) comprise of Suitable for providing a high level of security. May conform to WIM requirements. No additional size requirements to the handset if functionality is integrated into the hardware. These are opposed by the following disadvantages Requirement for changes in the handset architecture. Expensive and complex integration into the handset manufacturing and distribution process.

22 Mobey Forum / LK /45 Built in security scheme cannot be exchanged if broken. Impossible to move from user to user or from phone to phone. High level of security at the expense of high cost Password Authentication Calling line identity (CLI) can be used for user authentication for information services, not for end user non-repudiation purposes. Username / password authentication with, e.g., a server wallet, is an alternative way to authenticate the user, but it is not ideal for situations where end user nonrepudiation is a requirement. There are also additional usability issues in the password-based authentication compared to, e.g., digital signatures with WIM: a method such as one time passwords is required in order to gain an adequate security level. In this case the end user has to carry password list (on paper or other device) and insert long usernames and passwords. Also, remembering these additional passwords and usernames is burdensome. 2.5 Technical analysis of the handset SE Implementation alternatives Analysis At first glance, thinking purely from the technical side, there are not so many differences in the handset implementation alternatives from the security point of view as long as the WIM is included in the implementation. The software/hardware solutions are the only implementations where this isn t the case. From an architectural point of view, there are constraints in all implementations; dual chip requires multi-provider management infrastructure, so does SIM/WIM. However, dual slot doesn t, but it does require agreements on a one-to-one basis, as well as a SIM/WIM. Software and hardware based solutions require new kinds of logistical arrangements and have other architectural constraints as well. In terms of conformance to standards, dual chip and SIM/WIM are best alternative; dual slot is in practice based on SAT, software-based solutions don t comply with WIM requirements and hardware-based have not been evaluated against them. In terms of support to a variety of payment applications, dual chip has the potential to support both remote and local payments. The dual slot solution also supports this, but in use it is not so well suited for local payments. The SIM/WIM solution doesn t support local payments based on current standards (or standards easily derivable from the current standards). The software / hardware based solutions make it difficult in getting support for bank-defined payment standards and therefore are suitable mainly for authentication (and for remote payments through a server wallet) Conclusions In terms of other technical constraints, there are some issues in each alternative. The dual chip alternative requires issuing new dedicated chip cards and building of additional infrastructure to some extent (e.g. for the multi-application management). The dual slot solution is problematic due to SAT dependency. It makes the solution non-standards based and may cause interoperability problems. Dual slot is also more complex to manage from the handset design point of view than the dual chip solution. It is also more vulnerable to mechanical faults than the integrated concepts.

23 Mobey Forum / LK /45 In the SIM/WIM approach the building of multi-application management infrastructure is required, to also include cross-industry support, which is more challenging. The SIM/WIM approach is more difficult to get supporting a variety of business opportunities, for example, local payments. Creation of new protocols would be required if local payments were to be offered with the SIM/WIM solution. Last but not least: banks may have a problem with taking responsibility of the security application, since the issuer of the keys (i.e., a bank) cannot audit and be in full control of all the phases in the enrolment and management of the security element issued by an operator. The software-based solution doesn t comply with the WIM specifications, which makes it weaker for security. Furthermore, it doesn t enable all business opportunities. The hardware-based solution causes logistical problems, takes rather longer time to implement and doesn t enable all business opportunities. However, since there are obvious advantages in both of these concepts, they should both be evaluated more thoroughly in the future especially with current proposals, the hardwarebased concept may well have technical solutions within a reasonable timeframe. Password authentication fits well with certain payment opportunities defined by the Mobey Forum, but it isn t sufficient for all use cases. Passwords are currently used by many of the Mobey Forum banks, and are considered to be a good fit for certain applications. However, they don t fulfil all of the business requirements (offering non-repudiation and not very convenient). However, as a practical and widely used method, this option is included in the preferred payment architecture as one shortterm alternative solution for authenticating the user to enable access to the server wallet. 2.6 Mapping The AlternativeHandset SE Implementations With The Mobey Requirements The purpose of this chapter is to evaluate the alternative handset implementations suitable for the payer s end of the infrastructure against the given requirements and assess the suitability of the different implementation options. When performing the ranking, the suitability of each concept has been assessed both for remote and local payments separately. Certain assumptions were taken for the purpose of this ranking. For remote payments it was assumed, that 3D SET is used for payments, and for local payments EMV is the assumed payment protocol. The target of the exercise was to evaluate the suitability of the handset alternatives against the business requirements. The goal was not to rate or evaluate the suitability of the payment models, which has been previously done elsewhere. The dual slot implementation is here understood to be the current implementation, i.e., based on the SIM Application Toolkit (SAT). Since the use of EMV or any other bank-issued payment products is impossible with the SIM/WIM and SW/HW based concepts, it is assumed that a new EMV-type standard would be created for these alternatives; thus a concept such as "EMV Server Wallet" is assumed in these cases. This evaluation was performed by managed voting. Each member institution of the Mobey Forum had one vote and was requested to fill in the evaluation matrix. The responses were consolidated and weighted against the evaluation criteria created and prioritised. Please note that password based authentication is not included in this evaluation, since the main target was to evaluate the new implementation options against each other.

24 Mobey Forum / LK /45 Table 1: Evaluation of the handset implementation alternatives against the top 20 Business requirements defined by the Mobey Forum. Re-Ranki DC/ DC/ ng Remote Local Business quirement DS/SA DS/SAT T Re-Locamote SIM/WIM/ Remote SIM/WIM/ HW/SW/ Local Remote HW/SW/ Local 1Ease of use Protection against fraud Speed / transaction time Price (for customer) Confidence - data not forwarded Customer and merchant auth Assurance of genuine payment dest SIM change independence Standards based (interoperable) Transaction level security Merchant acceptance Not operator-specific Use of existing or planned infrastr Set-up costs per consumer Customer enrolment Cost to implement (merchant) Cost to implement (consumer) Existing solution availability Supports multiple paym. products Potential to add brand TOTAL For both remote and local payments the dual chip solution seems to best fulfil the Mobey requirements, dual slot being the second preferred option. Solutions based on phone software or hardware also scored well. The greatest advantages of a dual slot solution would be use of existing infrastructure (i.e., full sized cards) in remote payments and the potential to add brand in a traditional format. However, it has to be noted, that the preferred architecture cannot be built totally on existing solutions, since mobile payments will require new kinds of solutions in order to take-off and become successful. Thus building some new infrastructure cannot be avoided, but the negative impact of this should be minimised. Biggest differences between the dual chip and dual slot solutions are convenience and operator independence. Other important factors are speed of transaction, price for customer and assurance of genuine payment destination, i.e., perceived security for the end user. Solutions based on phone hardware or software need further evaluation. With current technologies the software solutions cannot be made tamper-proof. The logistical problems related to the hardware concept are to be evaluated. Due to the cost- and space savings these concepts offer a clear advantage compared to the other concepts.

25 Mobey Forum / LK /45 The clear advantage of the SIM/WIM solution is the price and use of existing infrastructure in remote payments area. When compared to the dual chip scenario, the latter scores better especially due to the operatorindependency factor, being based on open interoperable standards and supporting multiple payment products. The last two are especially important for local payments; SIM/WIM solution is not directly suitable for providing local payments with the available technical and business solutions. Furthermore, in a SIM/WIM case the operator is in control of the security solution, which may cause problems such as preventing access to banking services if the operator decides to change the nonrepudiation keys, another drawback is service confusion, meaning that the end user won t know whom to contact when they have lost their PIN code for banking services. Also the perceived trust for the consumer is higher in the dual chip method. Since the SIM/WIM is not an open solution, it requires one-to-one agreements between banks and network operators along with sharing customer information between them, and due to the other not-fulfilled requirements described above, it is not an acceptable solution for Mobey Forum. 2.7 Conclusions Concerning The Preferred Payer s Architecture When evaluated against the consolidated Mobey criteria, from the available payer s solution alternatives the dual chip solution today best fulfils the Mobey requirements. The main requirements where it scores better than the dual slot are Ease of use Transaction time Price for the customer Operator independence The last point above is due to the fact that it is not realistic to expect operator independent dual slot phones coming to market. When compared to the SIM/WIM alternative, in dual chip there is the assurance for consumer, that their payments are handled with their bank and no other party is able to see his confidential payment data, i.e., there is no service confusion in the end user s mind. In addition, the dual chip concept is the only one that provides banks the opportunity to offer banking services independently from other parties. Thirdly, if the payment application resides on the SIM card (SIM/WIM) or is dependent on the SIM (e.g. SAT dual slot), the payment application cannot automatically be used any more if the SIM card is changed. If the payment application resides in the mobile phone s memory (HW/SW based concept), with current technologies the user is not able to continue using the application smoothly if he purchases a new handset. Dual chip has its drawbacks as well, such as the need for banks to issue dedicated small-size multiapplication chips for mobile payments. To guarantee interoperability between banks, open CA solutions should be studied further. However, the dual chip phone has the best potential to become a widely used next generation payment tool. Based on this evaluation it can be concluded, that a dual chip solution best fulfilthe Consolidated Requirements set by the Mobey Forum, both for the remote and for the local payments. The secondbest solution seems to be the dual slot concept. Since for business reasons it is not realistic to ex-

26 Mobey Forum / LK /45 pect independent (or any) dual slot phones coming to market in large scale, the Mobey Forum clearly prefers the dual chip solution, where banks would have the control over the security solution. A third party may issue the Security Element (SE), if the service issuing bank so requires. Since it is known that the Secure Flash Card solution has fundamental unsolved problems, due to the high cost of the additional memory and due to the fact that it will be taking more time to emerge than the standard chip card, it is thus seen only as a potential future alternative. The immediate solution must be based on an open chip card as the SE.

27 Mobey Forum / LK /45 3 Evaluation of The Payee s Payment Models 1 The purpose of this Chapter is to describe the alternative payment models suitability for the payee s end of the infrastructure, considered from a technical viewpoint. 3.1 The Wallet including the Payment Products The wallet may contain different kinds of information, e.g., receipts, payment products, other information. The wallet is likely to contain several payment products in order to support credit, debit, account and E-purse based payments. In this documentation we are focusing on the payment products in the wallet. The Wallet can either be located on a server (SBW) or in the SE in the handset. A bank usually operates the SBW. It is also possible that a third party, if so requested by the issuing bank, hosts the SBW. If the Wallet resides locally in the handset, the payment products issued by the bank must be on a bank-issued SE, if not otherwise defined by the bank. There are exceptions: for instance in the case of a user accessing banking services and authenticating him/herself with WIM, the certificate may reside in the handset memory. E-purse is one viable product option for remote payments, especially for micro transactions. Both server- and chip-based e-purses are included in the architecture Server Based e-purse Customer uses an electronic purse stored on a bank server. A wake up message including the merchant details is sent to the purse, and following authentication of the customer, money is transferred to the merchant Server-based credit cards Customer uses a credit card (number) stored on a bank server. A wake up message including the merchant details is sent to the SBW, and following authentication of the customer, credit card transaction is initiated and money is transferred to the merchant Account-based payments Account based payment is an on-line payment link from e/m-commerce site to a bank s site with a pre-filled payment form, which is paid via the bank online to the e/m-commerce site. The merchant receives the information when the payment is cleared. The payment can also be made with a debit card instead of from an account.

28 Mobey Forum / LK / Local e-purse Transaction details are sent to the mobile handset that holds the local purse. Customer authorises the transaction. The payment details are sent from the phone to the merchant, and then forwarded to the merchant acquirer to capture the payment Local credit or debit card Transaction details are sent to the PTD that holds the locally stored credit or debit card. The customer authorises the transaction. The payment details are sent from the phone to the merchant, and then forwarded to the merchant acquirer to capture the payment. 3.2 The Payment Protocols Mail Order / Telephone Order (MoTo) The customer sends the card number to the merchant over the phone. Merchant performs an authorisation request through the acquirer and receives an authorisation. The merchant confirms the purchase to the customer, and settlement is progressed through the normal card payment route. It is suggested that using technologies, such as ECML, are further evaluated with MoTo payments for usability reasons Interoperability Domain Security Protocols The selection of the interoperability domain security protocol - 3D Secure, 3D SET, SPA or others is up to the issuer and may vary depending on the situation. SPA is not evaluated within this document, since the SPA documentation was available only after the evaluation was completed. However, this doesn t mean that SPA couldn t be used with the Mobey preferred payment architecture. The issuer also selects the end user authentication method, and the requirements for the level of security, varying depending on the purchase in question. This authentication method may well involve a password-based mechanism at the beginning, the upgrade path and preferred solution being a dual chip phone with a WIM and digital signature capability D Secure The cardholder submits a checkout page using SSL as normal. The merchant checks the Issuer Directory to obtain the URL for the specific card. The merchant redirects the cardholder to the issuer and provides a payment request message. The issuer displays the payment details to the user and requests entry of a secret code. The cardholder enters the secret code. If successful, the issuer will sign the payment message. The issuer redirects the cardholder to the merchant and provides a signed response message. The merchant validates and stores the issuer s signature and processes the transaction as normal D SET The cardholder submits a checkout page by hitting the pay with SET button. The merchant sends a predefined Wake-Up message to the Wallet. The cardholder authenticates them self to the wallet. The wallet sends an SET purchase initiation request to the merchant and receives a response. The wallet sends an SET purchase request to the merchant, payment authorisation is requested and received. The cardholder receives confirmation message. A receipt is generated and stored in the wallet.

29 Mobey Forum / LK / Ebpp (electronic bill presentment and payment) Two steps have to be distinguished: Bill Generation (when the merchant and customer agree on the transaction content). The customer selects EBPP as the payment instrument and a bill is generated by the merchant and forwarded to the bank (consolidator). Transaction step (occurs later). The customer logs in, the bill is presented and then accepted by the customer and the settlement initiated. Payment is confirmed One-time credit card number The cardholder makes a connection to the bank s WAP site (SBW) to download a one-time number representing his credit card. This number is submitted to the retailer as part of the transaction. The retailer then requests authorisation through the standard payment scheme network. Authorisation is received, completing the payment, and a confirmation message is sent to the cardholder EMV EMV is a payment protocol designed mainly for local card payments. There are two implementation alternatives of EMV: static and a dynamic. In the static EMV, the signature is verified by symmetric means, i.e., a DES-based Authorisation Request Cryptogram (ARQC) is sent to the issuer for verification. In the dynamic version a PKI system is being used, and the digital signature is sent to the issuer for verification. Technically it is possible to use EMV with the dynamic implementation option for remote payments but the feasibility of that option is yet to be evaluated. The process of EMV follows: Cardholder informs the POS of the preferred payment mechanism (EMV application). The merchant s POS device then requests consumer authentication from the EMV application on the SE. Authentication response comes from the EMV application on the SE. An Authorisation Request (via the standard payment scheme network) is sent. Merchant receives an authorisation response. The Cardholder receives a confirmation message. In off-line use the process differs in that no authorisation request is sent automatically but the chip contains profile information, and based on that the POS either authorises the transaction or sends an on-line request Set - Local Certificate (variation of EMV) This operates in the same way as EMV, but uses the locally stored Set certificate to generate the authorisation rather than the EMV protocol. 3.3 Technical Analysis of Payment Products and Protocols The technical suitability of the presented payment models for remote and local mobile payments is assessed in this chapter Technical analysis of Remote Payments All of the payment products can be used for remote payments. The suitability of a payment product for a transaction depends on several factors, the amount of transferred being one of them. E-purses suit best for micro transactions (below 10 EUR). Whether a chip card based local purse or a serverbased e-purse is used, depends on local preferences and market situation.

30 Mobey Forum / LK /45 The payment models suitable for remote payments are Mail Order / Telephone Order (MoTo), 3D Secure, 3D SET, One-time use number and Ebpp (electronic bill presentment and payment). MoTo payment model is used considerably in today s Internet world. There is no certain monetary limit in the use of MoTo. It doesn t require very high security standards, but on the other hand, it doesn t bring the liability shift with card present rules for the merchant. MoTo is widely used today, and it is assumed to have its future as well in certain applications. 3D SET and 3D Secure are Interoperability Domain Security Protocols specified by Visa International. They are suitable for mini- and macro transactions and assume the use of credit cards as payment products. Since a liability shift is offered via use of these protocols, banks are widely in the process of taking them into use. Ebpp is not so widely used today, but may well become more widely used when electronic billing becomes more popular. One time use number is a new and considerable secure way of making credit card payments over the Internet. Customer gets a one-time credit card number after authenticating to the bank s server. It doesn t benefit the fraudsters to try to steel the card number during the transaction, since the same number cannot be used twice. However, the system is a bit cumbersome to use, since the user has to log into the bank web site (e.g., for banking passwords) to get the one time number and then go back to the merchant page and insert the one-time number there. The most relevant alternatives for remote payments seem to be from the technical point of view the interoperability domain security protocols, 3D SET and 3D Secure, and the MoTo model which might be suitable for certain cases. The e-purse schemes are also estimated to have their market share in the segment of micro payments Technical analysis of Local Payments The payment protocols suitable for local payments are EMV and the Set - Local Certificate. There are also other methods for local payments, but since these are not yet standardised nor thoroughly evaluated by the Mobey Forum, they are excluded from this version of the document. Significant development needs to happen in the EMV certification concepts and processes (towards once-off self-certification) before EMV certification meets the key requirements of mobile phone manufacturing and the Mobey Forum. Further study is needed on the required content of the mobileoptimised EMV protocol and processes.additionally, usage of External Functionality Interface (EFI) is required to access the EMV application on the card. It is hard to imagine, that the Set - Local Certificate would be used in the mobile environment, since it would require implementation of SET into the mobile handsets. Implementation of SET itself is already a rather heavy process, not to mention the local variation. Ebpp is not so widely used today, but may well become more widely used when electronic billing becomes more popular. EMV protocol is best suited for local payments and available today for evaluation. The further actions needed in implementation of this option are described later in this document. 3.4 Mapping of Payee s Payment Models with the Mobey Requirements

31 Mobey Forum / LK /45 In the first part of this chapter the most important requirements for remote and local payments are evaluated from Payee s point of view. Then the alternative payment models suitability for the payee s end of the infrastructure is evaluated against the consolidated Mobey requirements. It is also assessed whether the payment models fulfil as many use cases as possible (versatility). This section explains how the payment models fulfil the Payment opportunities described in the Chapter 2 and the requirements expressed in Chapter 3 of the business documentation Payee s requirements for Remote Payments There is a requirement for an underlying trust infrastructure covering merchant, acquirer, issuer and user such as a three-domain model, such as 3D Secure. It is essential to integrate mobile payments into existing merchant infrastructure. Security. The most effective standard of customer authentication and encryption is based on WIM and wireless PKI. Non-repudiation can be achieved by using digital signatures generated within the WIM and confirmed by the user s PIN-code. Micro- and mini payments will not usually require such a high level of security. The mobile payment must be independent of the mobile operator. The operator-issued security module (SIM) cannot be used for providing bank-issued payment products. The cost for a merchant to implement the solution must be reasonable considering the expected revenues. The main cost factor for the merchant are implementation cost of the payee s security solution Payee s requirements for Local Payments The merchant s current infrastructure for local card payments should be used whenever possible. However, a new or upgraded POS terminal or additional modules will be required to communicate with the mobile phone. Bluetooth is the preferred link to the POS terminal but other technologies like Infrared are likely to be used in the near term. POS terminals will be upgraded for EMV within the next years. In order to maximise the leveraging of existing infrastructure, a payment protocol like EMV should be used in local mobile payments. The same level of security as for remote payment should be established with effective customer authentication and encryption. Non-repudiation should also be achieved, and the preferred method for this is to use digital signatures generated within a chip card application like the WIM and confirmed by the user s PIN-code. Micro- and mini payments will usually not require such a high level of security. The cost for a merchant to implement the solution must be in reasonable considering the expected revenues. The main cost factor for the merchant are implementation cost of the Payee s security solution including POS terminals enabled to communicate with the mobile phone Evaluation against the given criteria The Mobey Forum workgroups have also evaluated the Payee s payment models against the consolidated requirements explained in the business documentation. Only the most relevant payment models, that passed the technical evaluation, were weighted against the criteria. When the evaluation was completed, choices were made regarding the handset implementations in order to get a common basis. The following were the main choices for evaluation:

32 Mobey Forum / LK /45 For MoTo payments in this evaluation use of dual slot phones is assumed. This does not mean that MoTo payments wouldn t be usable with other handset implementations; the assumption was done purely for evaluation reasons. 3D SET is evaluated both with password authentication and with WIM-based authentication with a dual chip phone. 3D Secure is evaluated both with password authentication and with WIM-based authentication with a dual chip phone. EMV is evaluated both with dual slot and dual chip phones. The following table describes the evaluation of payment models against the consolidated criteria produced by Mobey workgroups Table 2: Evaluation of Payment Models against business criteria MoTo + SMS + DS 3D-SET + PSW 3D-SEC + PSW 3D-SET + WIM + DC 3D-SEC + WIM + DC EMV + DS EMV + DC 1. CUSTOMER PROPOSITION Convenience Customer enrolment Price Ease of use Speed/transaction time Enhancement of consumer experience Scalability across all use cases Renewal change of certificate 4NA NA Renewal change of operator Renewal change of card 4NA NA Renewal change of bank Form-filling Security Protection against fraud Assurance of genuine payment destination Privacy Confidence that data will not be forwarded Total BUSINESS PRIORITES Security Customer and merchant authentication Transaction level security Versatility

33 Mobey Forum / LK /45 Use case - remote purchase at e-shop Use case - face to face shopping Use case vending (confectionary) Use case - vending (petrol) Use case public transport ticketing Use case - continuous payments Use case - voice (MOTO) shopping Use case download of e-cash Use case taxi (mobile to trusted mobile) Use case - P2P payments Use case ticketing (event) Support of multiple payment products Support of other banks/payment schemes Acceptance by all Parties Not operator-specific Merchant acceptance Merchant integration into existing systems Potential to add brand Fit within proprietary e-payment Strategy Consumer to Issuer Control Merchant protection against repudiation Total TECHNICAL CONSIDERATIONS SIM change independence Gateway change independence Handset independence Standards based (interoperable) Reusability (multi-channel) Technical confidence Security (CIAN) Use of existing or planned infrastructure Total IMPLEMENTATION ISSUES Costs Cost to implement (consumer) Cost to implement (merchant) Distribution costs Set-up costs per consumer Cost to run (issuer) Speed to Market Existing solution availability Speed of roll-out

34 Mobey Forum / LK /45 International Total Total All It can be concluded from the evaluation, that for remote payments 3D SET and 3D Secure with WIMbased authentication and a dual chip phone seem to fulfil best the Mobey requirements. The existing 3D-SET process has been designed to assist with the security of remote payments by verifying the cardholder in cardholder not present situations. This transfers the liability for the transaction from the retailer to the financial institution. This is a good intermediary solution as the majority of the necessary infrastructure is already in place. However, 3D SET doesn t fulfil all requirements set fort in the business documentation. For instance, the cost to implement is not in the range of an optimal solution and therefore 3D SET cannot be considered as the optimal solution. From the existing models 3D Secure is considered to be a better solution in this sense and is therefore suggested by Mobey Forum as the long-term preferred solution. However, the Mobey Forum recognises, that the interoperability domain security protocols are specified elsewhere (other industry bodies), and the Mobey Forum would only like to ensure thatthe key requirements of Mobey banks are taken into consideration and fulfilled. From the Mobey perspective it is very important to guarantee interoperability between the card schemes and to achieve common standards with the interoperability domain security protocols as well. For local payments the use of EMV protocol with a dual chip implementation is preferred. In the vast majority of face-to-face payments speed is an important requirement as other customers may be waiting in a queue for the payment to finalise. It is also important that the infrastructure exists not only to transfer the information between the phone and the point of sale, but also between the transaction authorisation function and the POS itself so that the sale can be completed. It is also crucial to understand the importance of existing systems, for example, clearing and settlement infrastructure and charge back along with reclamation rules included into the EMV standard. The EMV protocol, even when optimised for mobile usage, is well suited for this type of purchases as it uses much of the existing payment infrastructure and is backed by the major card schemes, i.e., it also delivers inter-bank interoperability. It must also be emphasised, that creating a new global process for local payments is too heavy a process and won t fulfil the market needs within the required timeframes. Thus the optimal solution would be to leverage the EMV standard and implement it into the handsets with self certification rules. 3.5 Conclusions Concerning The Preferred Payee s Architecture Based on the requirements stated and the technical analysis, the use of a server based wallet with an interoperability domain security protocol, such as 3D Secure, is suggested for remote payments and an EMV-based solution for local payments. The Mobey Forum suggests WIM to be used for authentication in the remote environment towards the server wallet, as required by the issuer, with a dual chip solution. In the local environment EMV should be used for payments, since it is the local payment standard. It is already specified with a long process; if it were to be replaced by something totally new, a long

35 Mobey Forum / LK /45 lead-time would be required. It is expected, that the current issues with optimising the EMV standard for mobile use and handset certification will be solved in the near future. The concept of Wallet should be further evaluated. For instance, the access methods towards the server-based Wallet has to be further evalueated. It cannot be expected that consumers would type in long input data to the small user interface; more intelligent access methods need to be found. In addition, in this documentation the concept of Wallet is considered only from the payment products point of view.

36 Mobey Forum / LK /45 4 The Mobey The preferred technical architecture, which fulfils the consolidated Mobey requirements, is presented within this Chapter. 4.1 Introduction to the The preferred payment architecture consists of Payer s and Payee s architectures. Furthermore, this architecture consists of various components, such as the handset implementation and different payment models suiting to different usage scenarios such as remote and local payments. The Mobey preferred payment architecture for local and remote mobile payments includes three main items: 1. Wallet containing the payment product 2. Payment protocol transmitting the actual payment 3. Method for authenticating the end user. Figure 3: Main Components of the Issuing bank 1. Server Based Wallet or bank backend system 3. Interoperability Domain Security Protocol or EMV Acquiring bank End user 2. authentication method, preferably WIM issued to the customer 2. Authorization 3. Interoperability Domain Security Protocol or EMV All payments are sent to the issuer for settlement PTD communicates with the merchant system Customer with the PTD 1. Wallet in the handset PTD (preferably dual chip) including a SE, which contains bank-issued payment applications, e.g., credit, debit or e-purse Merchant Please note, that the Wallet can physically reside either on the bank server (SBW) or in the handset (SE including a Wallet). Both of these are explained in the previous Chapter from the payment product s point of view. Both options are enabled by the preferred architecture. The wallet can be considered to be part of the Payee s mobile payment solution, even when it resides in the handset. Payment protocols are also described in the previous Chapter.

37 Mobey Forum / LK /45 The authentication methods are explained as part of the Payer s architecture solution (Chapter 2) PTD with SE in the Preferred Architecture Personal Trusted Device (PTD) is personal, controlled and used by one person and carried by that person most of the time. It has an application platform with associated user interfaces for transaction related services such as banking, payment, bonus programs and ticketing. The PTD contains a Security Element, which is used for protecting its most critical data, such as private keys. A PTD employs a mechanism for user verification (to verify the person to whom the PTD belongs). Only upon successful user verification may the PTD be used for transactions. The Security Element executes the user verification (e.g. a chip card that performs cryptographic operations only after receiving a PIN entered by the user). Using a PTD with Security Element (SE) is essential in the Mobey Architecture, since strong authentication with a mobile PKI solution is required to be included in the architecture as the preferred solution. The SE is used to store cryptographic keys and perform operations using these keys. The preferred option is to implement the SE as a removable ID 2 size chip card element, i.e. as a dual chip solution. 4.2 The Preferred Architecture for Remote Payments The preferred architecture for Remote payments includes a Server Based Wallet (SBW), an interoperability domain security protocol and an end user authentication method. A bank usually operates the SBW - or a third party if so requested by the issuing bank. E-purse is one viable product option for remote payments, especially for micro transactions. Both server- and chip-based e-purses are included in the architecture. The chip-based e-purse will reside in the SE-based Wallet. The selection of the interoperability domain security protocol - 3D Secure, 3D SET, SPA or another is up to the issuer and may vary depending on the situation. Although 3D Secure is the preferred protocol, usage of other protocols is enabled by the architecture. The Mobey Forum stresses the need to create standards for this area, which should happen with a cross-industry effort, including all relevant organisations. The issuer also selects the end user authentication method, and the requirements for the level of security that vary depending on the purchase in question. This authentication method may well be a password-based mechanism at the beginning, the upgrade path and preferred solution being a dual chip phone with a WIM and digital signature capability. The following picture describes the preferred architecture for remote payments in high level. This architecture is explained in detail within this chapter. Figure 4: The Preferred Architecture for Remote Payments

38 Mobey Forum / LK /45 End user authentication method, i.e., WIM issued to the customer; Optionally SEbased Wallet issued to the user Issuing bank Server Based Wallet (SBW) containing e.g. Customer s * Credit card account *Direct debit account * E-purse Authorization Interoperability Domain Security Protocol Acquiring bank Interoperability Domain Security Protocol All payments are sent to the issuer for settlement Customer with the PTD PTD communicates with the merchant system over a WTLS session Dual Chip PTD including a SE-based Wallet (optional) which contains bank-issued applications for example: * Credit or debit card, E-purse and a WIM for authentication towards the SBW Merchant The Proposed Purchase Process Note: The following are assumed The user s wallet is already in existence and configured with payment and fulfilment data. There is a known association between a mobile phone and the wallet location. A standard wallet wakeup MIME content-type message is agreed and a method exists of interpreting that message to contact the wallet server. One mechanism for this would be to embed the wallet URL within an application onboard the mobile phone that is launched by the wallet wakeup. A second possibility is the use of a redirection server. HTTP is used as the transport protocol. PROCESS A. User shops on merchant s site & confirms purchase by selecting pay with wallet. B. Merchant responds with wallet wakeup message (WWM). C. WWM is redirected to wallet server. Starts wallet session & stores WWM. D. User is required to authenticate (ID&V). On success wallet is opened. E. Purchase details are transferred from merchant in to wallet via XML document. F. User selects payment brand & if appropriate, fulfilment options (e.g., delivery address). G. If applicable destination details are transferred from wallet to merchant (e.g. ECML, XML). H. Payment processing is performed I. If applicable merchant and/or credit card receipt details are transferred (e.g., via XML). J. Purchase completion message sent to mobile phone. K. Mobile Phone connection redirected to merchant site. Figure 5: Overview of the remote purchase process

39 Mobey Forum / LK /45 Mobile Environment Merchant Wallet Server Wallet A. Select goods Pay with wallet B. C. D. F. WWM (wallet wakeup message) WWM (merchant purchase handler URL) Authentication form (Session ID) Authentication (Session ID) Get Purchase Detail E. Purchase Detail XML Payment brand and fulfillment options Payment brand and fulfillment selections. Sign purchase Start session - store WWM Open wallet Store purchase XML G. H. I. [ Fulfillment (e.g. ECML) ] Fulfillment OK [ Payment (e.g. SET) ] Payment OK [ Get Receipt Detail ] Receipt Detail (e.g. XML) Close wallet J. K. Purchase complete (merchant return URL) Redirect to merchant Continue shopping End session Process Details The figure above shows the sequence requests and responses involved with a server wallet transaction from a mobile phone. This section describes each process step in more detail A. - Shop The mobile phone user selects goods on the eshop merchant site in the usual fashion building up the contents of their shopping basket. At checkout the merchant site offers a pay with wallet option. Note: Merchants must be wallet-aware and are required to provide the pay with wallet option. For the purpose of this document it is assumed a plug-in with be used B. - Pay with wallet (WWM) When the user selects pay with wallet, the merchant system generates a unique purchase identifier. The merchant system responds to the mobile phone with a wallet-wakeup message (WWM). The WWM is a standardised MIME content-type message containing: A purchase handler URL A failure URL

40 Mobey Forum / LK /45 The purchase handler URL is used for interaction between the merchant and the SBW. The unique purchase identifier is encoded within the handler URL that is accessed later in the process via an HTTP GET request. The mobile phone connection is redirected to the failure URL (if possible) when a connection or other technical error occurs C. - Redirect WWM to wallet server Where a redirection server is in use the WWM is intercepted and redirected to the wallet server. Without a redirection server, the WWM arrives at the mobile phone. On receiving the WWM, the phone launches an onboard application. The application may be pre-configured with one or more SBW URLs. The user selects a wallet or enters a full URL. Note: The implementation method of associating the user with their wallet(s) is beyond the scope of this document. One possibility would be a wallet directory service based on caller-line-identity. A connection to the wallet server is established. A session is started and a session identifier (SID) generated. Details of the WWM are retained in the session. This stage can be thought of as a wallet open request, the wallet is not opened until successful completion of the ID&V stage. Note: This model assumes a stateful wallet server D. - Authentication The SBW responds to the WWM with an authentication (ID&V) form. The ID&V process is wallet specific; however there must be a method of accessing the previously created session, for example hiding a session ID within the form. The user enters the authentication details, which are posted to the SBW E. - Purchase detail transfer On successful authentication, the user s wallet is opened. A connection is established between the SBW and the merchant s purchase handler URL. The location is obtained from the WWM within the session. The SBW issues a request to the purchase handler URL. The handler URL that originated from the merchant is encoded to uniquely identify the specific purchase. The purchase handler responds with a document containing the purchase details. Existing and emerging standards, for example, XML and ECML, are to be supported. The purchase details include the merchant ID, price and provision for a brief description of the purchase. In addition this document also specifies which purchase stages are required and which protocol is to be used. For example, the fulfilment stage is unnecessary if the transaction is to pay a credit card balance F. - Sign purchase, select payment brand The SBW presents the user with a summary of the purchase, including merchant and total price, with confirm or cancel options. Depending on the nature of the purchase and the wallet configuration the user is prompted for additional information. For example, select a payment card if the wallet contains several and a ship to address if applicable. Details of the chosen options are posted to the SBW on confirmation of the purchase.

41 Mobey Forum / LK /45 Note: It is assumed that options available at this point do not affect the price G. - Fulfilment detail transfer Arranging delivery is optional depending on the nature of the goods or service being purchased. The purchase detail document specifies whether fulfilment is required and if so the protocol to be used for data transfer. The document also specifies where to send the data, i.e. the fulfilment handler s location. (See E. Purchase detail transfer). This mechanism allows for an extensible framework, the participants, merchant and wallet vendors are able to support existing and emergent standards (ECML, ITOP, XML, etc.). The merchant could indicate support for several protocols allowing the wallet to choose. The fulfilment data is gathered from details held within the wallet according to the user s choice at the Confirm purchase stage. The data is packaged and sent to the merchant s fulfilment handler URL in the appropriate format. A status response is required to indicate success or failure of the fulfilment data transfer H. - Payment processing Payment is managed in a similar fashion to fulfilment. The purchase detail document specifies whether the payment stage is required, if so the protocol and the payment handler URL. (See E. Purchase detail transfer). This mechanism allows for an extensible framework, the participants, merchant and wallet vendors are able to support existing and emergent standards (ECML, SET, 3D-SECURE, etc.). The merchant could indicate support for several protocols allowing the wallet to choose. The payment data is gathered from details held within the wallet according to the user s choice at the Confirm purchase stage. Included is the actual payment method (e.g. credit/debit card or wallet stored value). The data is packaged and sent to the merchant s payment handler URL in the appropriate format. A status response is required to indicate success or failure of the payment data transfer. A record of the payment is stored in the SBW I. - Receipt detail transfer Receipt processing is the third optional stage of the purchase process. The availability of a receipt is specified within the purchase detail document. The exact format of receipts (both merchant and credit card) is beyond the scope of this document. Receipt standardisation and protocols for data transfer are subject to further investigation. After all of the required stages are complete the wallet is closed and the session ended J. - Purchase complete On completion of all the previous stages (fulfilment, payment and receipt) a result message is sent from the SBW to the PTD confirming to the user their purchase has been concluded. This is the SBW response to the confirm purchase and selection of payment and shipping options. The user interface is wallet vendor specific, typically it will allow the user to perform further wallet operations whilst it is open and offer a return to merchant option.

42 Mobey Forum / LK / K. - Redirect to merchant site Selection of the return to merchant closes the wallet and then sends an auto-refresh page or card to the PTD that redirects the device to the merchant site. The return URL is part of the purchase detail document originally sent from the merchant. 4.3 The Preferred Architecture for Local Payments The preferred architecture for Local payments is a solution based on a bank-issued EMV-card within a dual chip handset, residing on the SE. E-purse is one viable payment application option for local payments, mainly in the form of a chipbased e-purse ( residing on the SE), since local transactions may be off-line and a server-based solution would then not full-fill the requirement of a fast and cheap transaction. The following picture describes the preferred architecture for local payments in high level. The architecture is explained in more details within this chapter. Figure 6: The Preferred Architecture for Local Payments Issuing bank Local Payment Application, i.e. EMV Card End user authentication method, e.g. WIM or EMV with PIN codes Bank s back end containing e.g. Customer s * Credit card account * Direct debit account Authorization EMV infrastructure Acquiring bank EMV infrastructure All payments are settled through normal EMV mechanisms Customer with the PTD PTD communicates with the merchant system with a local payment protocol over, e.g.,bluetooth Mobile Wallet within the SE in the Dual chip PTD containing bank-issued payment applications like * (EMV-based) Credit or debit card or e-purse Merchant An EMV-based model with a dual chip phone Please note, that the suitability of the EMV protocol for mobile use is not yet fully evaluated. Mobey Forum looks forward to a speedy evaluation of this issue; the whole specification has to be reviewed in order to optimise it for usage in mobile phones and over wireless connections. This work has to happen with a cross-industry effort, involving all relevant parties.

43 Mobey Forum / LK /45 Mobile phones need to be certified for relevant parts of the EMV. Since certification would otherwise be too costly and complicated for the manufacturing process of mobile phones, self-certification rules have to be created. Also this work has to be started immediately by the relevant parties. Note: The following are assumed A mechanism is in place to allow the POS to communicate with the mobile phone (Bluetooth, infrared etc.). A standard message set is agreed to allow transaction information to be passed backwards and forwards between the POS and the mobile phone; i.e. a standard local payment protocol needs to be created. It is a key requirement for this protocol that it needs to be transparent to the transport layer, i.e. it should work as well on top of at least Bluetooth and IrDA Proposed Purchase Process Underlying assumption is that the issuing bank supplied the customer with an EMV chip application in the SE of the handset. User is shopping in the store: A. The customer informs a sales clerk that they wish to pay via mobile phone. B. The sales clerk selects mobile payment. C. The POS terminal initiates the communication to the mobile phone with a handshake message. The handset provides the POS terminal with EMV application details. D. The POS terminal sends the payment details to the handset. E. The user checks the details on the screen of the phone and approves the transaction by entering the PIN. The SE verifies the PIN. The handset sends the purchase request message to the POS terminal. F. Card details, amount and an Authorisation Request Cryptogram (ARQC) made by the EMV application may be sent to acquiring bank for authorisation if it is an online transaction. G. The POS terminal receives an authorisation response from the acquirer. H. The POS terminal informs the handset about the status of the transaction. I. The POS terminal informs the handset that the session has ended. J. The transaction will be settled with the issuing bank. Figure 7: Description of the purchase process with an EMV-based solution and a dual chip mobile phone

44 Mobey Forum / LK /45 User Handset (EMV chip application) Merchant POS terminal A. Inform merchant that user wishes to pay via mobile phone Select mobile payment B. C. The user verifies the POS and selects the EMV application Handshake message Provide the POS terminal with EMV application details Initiate communication to handset D. Send the payment details The user checks the details on the screen of the phone Payment details E. The user approves the transaction by entering the PIN.The SE verifies the PIN The handset sends the purchase request message to the POS terminal Authorize transaction F. Card details, amount and an Authorization Request Cryptogram (ARQC) made by the EMV application may be sent to acquiring bank for authorisation if it is an online transaction G. The POS terminal receives an authorisation response from the acquirer H. Transaction authorized The POS terminal informs the handset about the status of the transaction I. The POS terminal informs the handset that the session has ended End session J. The transaction will be settled with the issuing bank. Settle transaction Process Details A - Checking out process On completion of the checking out process the user informs the sales clerk that he/she wishes to pay using a mobile phone. The user would possibly enable the phone to accept communication from the POS depending on the communication method that was selected (i.e. if infrared is used the user needs to turn on infrared reception) B - Preparing the POS and handset communication On agreeing to accept payment by this method, the sales clerk would select mobile payment on his POS terminal. If infrared were selected, the operator would need to indicate that the customer should place her phone in the cradle to ensure good communication. If Bluetooth, the customer may need to be prepared to confirm that she is handshaking with the correct POS C - Purchase initialisation request A handshake message will be sent from the POS terminal to the phone. If the shop has several POS devices communicating over Bluetooth, the user confirms the right one. If the user has more than one EMV payment application on the SE than he/she can select one. The user would e.g. scroll down to the required application and click OK. The handset sends the EMV application information, such as account-number and payment scheme brand to the POS terminal D - Purchase initialisation response The POS terminal sends all transaction details to the handset. These details would be: date; time; till no; merchant no; transaction id; and transaction total. The total for the transaction would appear on the screen, with options to accept or reject. If the total were rejected, the transaction ends and the payment process would need to start again.

45 Mobey Forum / LK / E- Purchase request The user is requested to enter his PIN to approve the transaction. The PIN will be checked by the EMV application in the phone. The phone sends the purchase transaction message to the POS terminal F - Authorisation request The POS terminal may decide to accept the transaction offline, or to request authorisation of it from the acquiring bank. The grounds to decide upon are given by the EMV application in the handset and POS terminal parameters. The ARQC, card no and other transactions details are composed into an authorisation message that is then sent to the merchant acquirer either over a phone-line or through a central system G - Authorisation response The acquirer will inform the POS terminal on the result H - Purchase response The POS sends a confirmation message to the phone. The phone stores this confirmation in memory. The POS also prints a paper receipt and the operator gives this to the user I - End of session The POS terminal informs the handset that the session has ended J - Settlement The transaction will be settled with the issuing bank using existing payment infrastructure. Note: The final payment would either be captured via an overnight batch process along with other card payment transactions, or the authorisation message could double as the payment capture as well.