Electronic Commerce Transactions in a Mobile Computing Environment

1. Electronic Commerce Transactions in a Mobile Computing Environment Jari Veijalainen, Aphrodite Tsalgatidou Univ. of Jyväskylä, Finland JV: Currently: GMD-FIT,GERMANY jari.veijalainen@gmd.de http://www.cs.jyu.fi/~veijalai see also: http://www.cs.jyu.fi/~mmm AT: Currently: Univ. of Athens, Greece afrodite@di.uoa.gr

2. Presentation Outline • Introduction • Basic Definitions • Transactional Requirements for Mobile E-Commerce • Open Issues and Conclusions

3. Introduction • Mobile e-commerce (MEC) is linked with wireless Internet and proliferation of Internet-ready telecom terminals (GSM,I-mode) • one billion mobile phone subscribers by 2002 • the estimates on the number of Internet-ready telecom handsets by 2003 on the market vary from 134 millions (Strategy Analyst) to 330 millions (IGI Consulting) and to 600 millions by 2004-2005 • in a few years the number of Internet-ready handsets exceeds the number of stationary terminals (PCs) in the world

4. Introduction • The prerequisites for mobile e-commerce • global backbone network based on IP called commonly „Internet“ (whatever it excatly means) • WWW-technology with HTML and HTTP, soon cheap/free browsers and WWW servers, and later Java, Javascript, applets and servlets, XML • Business-to-customer e-commerce based on WWW technology and home computers => already a huge potential customer base

5. Introduction • wireless digital voice communication networks, esp. GSM networks that support global roaming • Wireless Application Protocol (WAP) development (since 1997) whose goal it is to facilitate access from wireless telecom network terminals to Internet, i.e. to make the wireless terminals „Web-enabled“ (Nokia, Ericsson etc.) and simultaneous development on I-mode • one application class in these „Web-enabled“ telecom terminals is e-commerce ; hence mobile e-commerce (MEC) or „m-commerce“

6. Introduction: „All-IP“ vision • Access PC PC Mobile terminal TV set IP Backbone Network Mobile NW Operator sphere E-commerce server CA server Service provider server Community server

7. Definitions: Mobile e-commerce (or m-commerce or MEC) • We assume that there is the e-commerce infrastructure on Internet (and/or on telecom network) and that it can be accessed through mobile portable terminals (e.g. WAP, I-mode) • M-commerce transaction: Any type of transaction of an economic value having at least at one end a mobile terminal and thus using the telecommuni-cations network for communication with the e-commerce infrastructure

8. Definitions:Mobile e-commerce (or m-commerce or MEC) • Mobile e-commerce = e-commerce based on m-commerce transactions • MEC is thus Internet-based e-commerce performed using mobile portable (telecom) terminals + all location-related commercial activities • the location-related activities are the unique feature of MEC, because they make much sense for mobile terminals but no sense for stationary terminals • otherwise the question is: what are the differences to wireline e-commerce, why do they exist, and how are they solved

9. Requirements for MEC Applications and Services

10. Requirements: Invariants for the portable wireless terminals • The outlook of these terminals, Personal Trusted Devices (PTD), is determined by two conflicting factors • maximal portability => small physical dimensions, lightness (ca 100-200 g, fits into pocket, can be carried easily, one gadget) • maximal usability=> large display, big and heavy battery, large enough keyboard for writing, big enough to be used as a phone, powerful radio tranceiver, effective processor, big fast memory

11. Requirements: Invariants for the portable wireless terminals • Claim: • portability does not increase substantially below the pocket size and ca. 100 g (or do women or children disagree?) but usability suffers • portability of two gadgets is worse than that of one integrated device, 3 is worse than 2 etc.=> • the terminals will converge towards the above dimensions and usability increases due to the faster, smaller technologies within these limits

12. Requirements: Invariants for the portable wireless terminals • Further, the claim holds even if UI technologies would be totally replaced by new ones (voice interface instead of keyboard, hologram display etc.), or batteries would store 10 or 100 times more energy/cm3 as the current ones, because each of the factors increasing the usability alone sets a lower limit for the size and/or weight and it is highly improbable that all factors would radically change=> • the above device size/weight class sets the limiting factors within which the computational properties are improved

13. Small screen,low pixel resol,UI,restricted I/O limited mem.&storage capacity &comp.power, Communication autonomy Issues to be considered in Applications for Mobile E-Commerce • The characteristics of hand held terminals • The peculiarities of the wireless environment • The vulnerability of hand-held devices and enhanced hostility as compared to wireline environment • The different usage of hand-held devices • conditions of usage (out-door, in hostile environments, in foreign countries) • locality, • personalisation, • instantaneous delivery, • cheap services => micropayment, etc. Lower bandwidth C-autonomy, less connection stability

14. Classification of Requirements • Usability Requirements • Requirements for New Applications and Services • Quality of Service and other non-functional Requirements • Security Requirements • Transactional Requirements

15. Transactional Requirements • Transactional requirements can be seen from e-commerce protocol perspective, i.e. they are requirements for the protocol specifications and executions • Atomicity: is the key requirement for executions, i.e. the protocol must run to an acceptable end state, where all necessary actions at different participants have been performed or all so-far performed actions have been compensated; (money moved iff goods received) • Consistency: Atomicity guarantees this transaction-internally, no global permanent consistency constraints • Durability: the effects of actions must be durable so that all participants know to what he/she has committed and this can be checked later should disputes arise • Serializability: can be provided at the action implementation level, but not a central issue

16. Transactional requirements • The new aspects come from the vulnerability and hostility of the environment, as well as from the properties of the PTD and legal requirements • security and transactions specifications and executions must go tightly hand-in-hand • Authentication and non-repudiation, Integrity, Confidentiality, Message Authentication are thus relevant aspects of transactions • techniques like the asymmetric cryptographic algorithm are used to achieve these results together with a Certification Authority and a WPKI

17. Transactional Requirements • Transactional mechanisms for security at both ends • Transaction Protocols for dispute handling, handling adversarial attacks • Security level to be specified by customer • Failure resiliency and capacity to recover “crashed” processes into a consistent state • Transactional mechanisms should • not assume continuous connection and communication (C-autonomy, loss of field, battery dies) • take into account that processes may run several days or weeks at the merchants side

18. Transactional requirements • The transaction model must facilitate dispute handling resolution=> all parties must store audit trails in a resilient way • possibly an arbitrator must be involved in the protocol as a party • The small memories, non-resiliency of the terminals, C-autonomy and other typical properties make the implementation different transactional and security mechanisms different and more difficult than in a laptop or PC environment

19. Transactional Requirements: MET forum • http://www.mobiletransaction.org/pdf/MeT_White_Paper.pdf • basis technologies taken as a starting point (WAP, Bluetooth) • first comprehensive specification at the end of 2000

20. Open Issues and Conclusions • The legal framework should be global but currently it is fragmented and partially inadequate (EU: E-commerce directive 7/2000, USA?, Japan?) • Different merchants and other players and countries might require different protocols => protocol heterogeneity and usage problems • Easier accessibility of applications and services • at the moment heavily dependent on operator, gateway, terminal type, location ...

21. Open Issues and Conclusions (cont.) • Solve open billing issues, e.g. • Billing of roaming customers • Billing of not received services (partially a transaction issue: protocol not performed properly) • Language heterogeneity (different natural languages) • CA multiplicity and hetoergeneity: which certificates to use in different countries, while on the move?

22. Open Issues and Conclusions (cont.) • Transactions are pervasive in the MEC environment, i.e. they are a central concept • requirements and limitations come from the mobility, legislation, properties of the hand-sets, and the those of the wireless networks • The exact properties of MEC transactions are still not explored enough • too early introduction of too simple MEC transaction might lead to abandonment of the services by the customers