1、ETSI TR 102 071 1.2.1 (2002-10) Technical Repor Mobile Commerce (M-COMM); Requirements for Payment Methods for Mobile Commerce 2 ETSI TR 102 071 VI .2.1 (2002-1 O) Reference RTR/M-COMM-007 Keywords commerce, mobile, payment ETSI 650 Route des Lucioles F-O6921 Sophia Antipolis Cedex - FRANCE Tel.: +3
2、3 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Important notice Individual copies of the present document can be downloaded from: http:lwmv.etsi .arq The present document may be made av
3、ailable in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on
4、 a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at ha p:/pa rta I. etsi I a rgltbistat uslstatus .as p If
5、 you find errors in the present document, send your comment to: Cori vriaht Notifica tion No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. O European Telecommunications Standards Institute 2002. All
6、 rights reserved. DECTTM, PLUGTESTSTMand UMTSTMare Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members a
7、nd of the 3GPP Organizational Partners. ETSI 3 ETSI TR 102 071 VI .2.1 (2002-1 O) Contents Intellectual Property Rights . .4 Foreword . 4 1 Scope 5 2 References . .5 3 Definitions and abbreviations. . .5 Definitions 5 3.1 3.2 Abbreviations . 6 4 Payment systems in a mobile commerce environment. 6 4.
8、1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.1.1 4.2.1.2 4.2.2 4.2.2.1 4.2.2.2 4.2.3 4.2.3.1 4.2.3.2 4.2.4 4.2.4.1 4.2.4.2 4.2.5 4.2.5.1 4.2.5.2 4.2.6 4.2.6.1 4.2.6.2 5 5.1 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.3 Generic model . . . . . . Definition Authentication . Definition Requirements Requirements Requirements No
9、n repudiation Requirements Definition 9 Requirements 9 10 Definition 10 Requirement 10 Definition Definition Secure mode indication . Scenarios for a mobile payment system . 10 Dual SIM/dual slot . Confidentiality in a system . Authentication in a dual SIM system in a singleSIM system Small payment/
10、electronic wallet (proxy payment). . Authentication in a single SIM system . Annex A: A.l A.2 Annex B: Bibliography 15 Examples of possible mobile payment scenarios 12 Example of an m-payment using 3D model . 12 Example of an M-Payment via payment provider 13 History . .16 ETSI 4 ETSI TR 102 071 VI
11、.2.1 (2002-1 O) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR O00 314: “Intel
12、lectual Property Rights (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (5). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, ha
13、s been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR O00 3 14 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Pro
14、ject M-Commerce (M-COMM). ETSI 5 ETSI TR 102 071 VI .2.1 (2002-1 O) 1 Scope The present document specifies the requirements which are necessary to be fulfilled by a telecommunications system in order to support a payment system in a mobile commerce environment. 2 Re fe re nces For the purposes of th
15、is Technical Report (TR), the following references apply: il ECBS ORG.9003: “ECBS Terminology“. 21 IS0 7498-2: “Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture“. 3 3.1 Definitions and abbreviations De fi nit ions For the purposes
16、of the present document, the following terms and definitions apply: customer trusted environment: architecture consisting of a network and a set of hardware and software used by a customer to perform a transaction JAVA: object oriented programming language developed by Sun Microsystems designed to b
17、e platform independent mobile payment: payment as part of a commercial transaction between the customer and the service/goods provider or other customer NOTE: The payment is effected through a mobile device. M-payments may be bank card-based or non-card-based, in both the real and virtual worlds. mo
18、bile banking: range of traditional banking services, including push payments, where a customer gives an order to a bank to execute a transfer of funds, conducted via a mobile device Mobile Commerce: electronic commerce using a mobile device as a customer device e.g. a mobile phone mobile device: per
19、sonal communication device (e.g. PDA, mobile phone etc) capable of communicating either locally (e.g. Bluetooth) or through a network (e.g. GSM) payment enabler: provides infrastructure for generating an m-commerce transaction, but does not handle the transaction itself (e.g. a network operator or e
20、lectronic wallet) payment provider: processor of m-commerce transactions NOTE: A payment provider can be a bank, credit card institution, or other third party payment provider. pull: schema where the client retrieves a document from a server by calling it (the destination of the information is the i
21、nitiator of the communication) pull payment (debit payment): request to transfer funds initiated by the beneficiary push: schema where the client receives a document without having explicitly asked for it (the originator of the information is the initiator of the communication) push payment (credit
22、payment): funds transfer requested by the customer (paying party) ETSI 6 ETSI TR 102 071 VI .2.1 (2002-1 O) 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CLI EMV GSM os OTA PDA PED PIN SET SIM SMS SSL WAP WIM WTLS Calling Ring Identity Eurocard Master
23、card Visa General System for Mobile communication Operating System Over The Air Personal Digital Assistant PIN Entry Device Personal Identification Number Secure Electronic Transaction Service Identity Module Short Message Service Secure Socket Layer Wireless Application Protocol WAP Identity Module
24、 Wireless Transport Layer Security 4 Payment systems in a mobile commerce environment To fully understand how payments work in a mobile environment, this clause describes a generic model and identifies the different actors and the systems involved in m-payments. 4.1 Generic model The model in figure
25、 4.1.1 illustrates the interactions between a customer, their mobile device, and a payment application. The merchant may be a physical merchant, trading on the high street, or a virtual merchant, trading via the Internet. The issue for the payment provider is how to assure their customers that they
26、are engaging in “trusted“ payments over open networks. Clauses 4.1.1 to 4.1.3 describe the stages of a possible m-payment transaction: the pre-payment dialogue, the payment dialogue and the post-payment dialogue. These three stages are necessary to complete a full transaction. ETSI 7 ETSI TR 102 071
27、 VI .2.1 (2002-1 O) Network or local link Merchant (Commerce) - Mobile Phone Customer Payment provider Payment enabler Device or Application Figure 4.1 .I : Generic model: dialogue before payment 4.1.1 Dialogue before payment The fiist step in a mobile payment transaction is when the customer commun
28、icates using the mobile device. The customer connects with the expected party (e.g. a service or content provider, a merchant, a public or private institution, etc.). Here security services (e.g. privacy, integrity or authentication services) may be required. Customer registration for a specific ser
29、vice might be required in order to veriSl personal data. 4.1.2 Payment dialogue In the second step, the customer selects the goods/contents/service to be purchased. The customer and the expected party (e.g. a service or content provider, a merchant, a public or private institution, etc.) may agree o
30、n a contract related to the goods/contents/service to be purchased (mutual confirmation of goods to be purchased). Then the customer communicates via the mobile device to the payment enabler. The customer selects the means of payment (brand, type of payment, etc.) and communicates with the payment p
31、rovider. At this stage, the payment provider and the customer need to be assured that they are communicating securely. The security needs to be appropriate to the transaction. The customer will need to have to an appropriate perception of security to be reassured to use the system. The payment is in
32、itiated and the parties are informed whether the payment has been terminated (authorized or rejected), with identification if appropriate. 4.1.3 Processing after payment In the fiial stage, the payment provider processes the payment within the financial institutions (i.e. merchant acquirer) as it is
33、 done today. ETSI 8 ETSI TR 102 071 VI .2.1 (2002-1 O) 4.2 Requirements of a payment system 4.2.1 Confidentiality 4.2.1 .I Def i n it ion Confidentiality The property that information is not made available or disclosed to unauthorized individuals, entities or processes. See ECBS ORG.9003 i, IS0 7498
34、-2 2. 4.2.1.2 Req u ire men ts The following information shall be confidential: Payment card identification. PINS. NOTE: Identity of user (and his contact information). This list is not exhaustive, and may include the content, the shopping experience, delivery information. In certain cases the confi
35、dentially content may be required, for example: Content covered by copyright. 4.2.2 Aut hen t i ca t i o n 4.2.2.1 Def i n it ion The term is used in different contexts: authentication: process used between a sender and a receiver to provide data origin verification, see i. data origin authenticatio
36、n: corroboration that the source of data received is as claimed, see i. NOTE 1 : The source of data may be the user or a device. NOTE 2: The cardholder authentication process can be made combining the information on the message originator (e.g. the CLI) and verification of a defiied quantity (e.g. a
37、 PIN, the answer to a challenge, biometrics) known only by the cardholder himself. NOTE 3: In each transaction, the user is authenticated, and also his intention to initiate the transaction. 4.2.2.2 Req u ire men ts In each transaction, it shall be possible to authenticate the user and the transmitt
38、ed data. The degree of accuracy shall be as good as non-mobile transactions. The system shall provide proof of authentication for each transaction to the payment provider. NOTE: Authentication at the beginning of a session (e.g. at power on) may be sufficient for some types of transactions. ETSI 9 E
39、TSI TR 102 071 VI .2.1 (2002-1 O) 4.2.3 Integrity 4.2.3.1 Def i n it ion The property of ensuring that information is not altered in any way, either by accident or with fraudulent intent, see i. NOTE: Any alteration shall be detectable on the receiver side. 4.2.3.2 Req u ire men ts The transmission
40、system shall provide a mechanism for data integrity, and shall be able to demonstrate the integrity of each transaction and of stored data. Integrity requirements apply both to the information provided to the payment provider and to the information provided to the user. EXAMPLE: The amount of a tran
41、saction seen on a user screen needs to be the same as the amount contained in the transaction. 4.2.4 Non repudiation 4.2.4.1 Def i n it ion non-repudiation: a process that involves delivering data in such a way that the receiver can not deny receipt and the sender can not deny sending it, see i. non
42、-repudiation of origin: the property that the originator of a message is not able to subsequently deny, with an accepted level of credibility (defined either in legislation or in a contract between the customer and the payment provider), having originated the message. non-repudiation of receipt: the
43、 property that the receiver of a message is not able to subsequently deny, with an accepted level of credibility (defined in a contract between the customer and the service provider), having received the message. NOTE: This assumes the integrity of the original message. 4.2.4.2 Req u ire men ts A tr
44、ansaction which has been properly authenticated, it shall be considered to be non-repudiable. The payment provider shall receive a report sufficient to demonstrate the non-repudiability of each transaction. EXAMPLE: A signature given by the payment device, indicating that the card was present and th
45、e PIN was entered, to the merchant may fulfil this requirement. 4.2.5 PIN entry 4.2.5.1 Def i n it ion Personal Identification Number (PW: A code or password the customer possesses for verification of identity, see i. PIN Entry Device (PED): Any device into which the cardholder inputs the PIN. A PED
46、 may also be called a PIN pad, see i. 4.2.5.2 Req u ire men ts It shall be possible for the user to modiSl his PIN. ETSI 10 ETSI TR 102 071 VI .2.1 (2002-1 O) 4.2.6 Secure mode indication 4.2.6.1 Def i n it ion An indication to the user that he is operating in a protected environment when entering s
47、ensitive data (e.g. PIN). 4.2.6.2 Req u ire ment Payment applications shall provide an indication of security at the user interface. NOTE: Security requirement is that the mobile has to provide some form of secured access between payment application and display and keyboard, in order to prevent some
48、 possibility of frauds like capture of the PIN through the network or display a different amount from what is sent to the payment provider. This secured access mode has to be shown to the user through some unambiguous indication on the mobile via for example display, led, etc. 5 Scenarios for a mobi
49、le payment system 5.1 Dual SIM/dual slot In this scenario, the mobile device is provided with two physical SIM cards: one identiSling the customer to the telecommunications operator; the second as a payment card to the payment provider. 5.1 .I Confidentiality in a dual SIM system May be provided through the SIM/WIM chip (WTLS on the OTA link) and relevant SSL protocol between WAP Gateway and payment provider server or through a process at application level involving the payment cardchip. 5.1.2 Authentication in a dual SIM system Payment data signature is provi
