Transactions in mobile electronic commerce Jari Veijalainen University of Jyväskylä Finland www. cs. jyu. fi/~veijalai Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 1
Contents – Some history of electronic commerce – Modern times: WWW and its impact – Three examples of E-commerce – Distributed “ec”transactions for E-commerce – Mobility in E-commerce – Conclusions – Appendix: Autonomy issues Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 2
Some invariants • Technology serves organization not vice verso - but it functions at the same time as a limiting factor • Any new technology becomes old technology as the time goes by; thus it is impossible to get rid of legacy systems as long as new technologies keep emerging Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 3
Prerequisites of Electronic Commerce – Business data processing started during fifties and has grown ever since => lots of digitized business data in computers that could be used – global computer networking in the strong sense started with ARPANET in 1969 => potential global connectivity of the computers and data and possibility to make business Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 4
Business-to-Business Ecommerce: S. W. I. F. T. – one of the first commercial special-purpose global networks was S. W. I. F. T. ’s network in 1977 – it had its own protocol stack, own terminals and huge computing centres to process transactions 24 hours a day every day of the year – the data modeling capabilities were based on Message Types that were both human and machine readable (9 main groups of MTs around 1985)Invited talk at TDD’ 99, Dagstuhl, 5 Germany, Sept. 27 1999
Business-to-business Ecommerce: EDI – The term Electronic Data Interchange (EDI) was coined to describe a situation, where business transactions are performed automatically by computers by exchanging “pieces of data”, I. e. messages over a computer network - or using magnetic tapes – in 1986 EDIFACT language to describe the “pieces of data” above to be exchanged was standardized building on similar principles as the above S. W. I. F. T. Message Types Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 6
Business-to-business Ecommerce: EDI – EDIFACT is actually a language to describe data structures, i. e. atomic pieces of data, and compositions of them (cf. Pascal or ASN. 1) – thus it is one abstraction level higher than SWIFT MTs that are at the type level – EDIFACT does not support specification of processing rules or any other way of defining business semantics, but it must be given using a natural or a (semi)formal language Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 7
Inherent problems with EDI and DTD: s – Even if initially adequate, the DTD scope and specifics must be updated to include technology advances and other changes. Here, time again becomes an issue: if users wait for agreement on DTD changes, this does not support the pace of commerce; if individuals generate modified DTDs, there is soon divergence from an unambiguous standard and point-to-point solutions result. This is the present predicament with EDI. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 8
Customer-to-business ECommerce – PC: s penetrated home since the beginning of eighties => a huge potential customer base – Internet with TCP/IP+HTTP and HTML and browsers makes global connectivity actual starting about 1994 -1995 – each vendor can define HTML-pages of their own and forms to be filled that they find appropriate – each customer can view the pages and fill the Invited talk at TDD’ 99, Dagstuhl, forms provided proper HTML is used Germany, Sept. 27 1999 9
Customer-to-business ECommerce – The latter issue is revolutionary as compared to the EDIFACT world; the customer does not need to invest any modeling effort in order to achieve interoperability with any partner; just run TCP/IP and a HTML browser on top of that and the customer and merchant are in business Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 10
Customer-to-business ECommerce – The problem lies in the fact that there are thousands and thousands of different forms at the EC server sites and there is no way of automating the processing at the customer end; only manual way of working is possible – another problem is C-autonomy of the customer: if the service or product cannot be delivered during one session, there is no way to inform customer about the order status => one resorts to email as another channel to inform the Invited talk at TDD’ 99, Dagstuhl, 11 Germany, Sept. 27 1999 customer;
Customer-to-business ECommerce – With “unstructured” emails again, only manual processing is possible at the customer end – therefore, this way of proceeding is inappropriate for B-TO-B => standardize the forms using e. g. XML/EDI (see http: //www. w 3. org) – as we will see, standardization would probably be needed also if “ec”-transactions would be used Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 12
Some examples on ec • I tried three services – Keltainen pörssi (an electronic market place) – Bokus. com (a book store in Finland) – Amazon. com (another bookstore in USA) – the first and last have explicit three-party structure (customer - merchant - payment mediator), the one in the middle has two-party structure Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 13
Example: WWW-based market place “Keltainen pörssi”: server • 1. Tilausaika. Valitse yksi seuraavista: • 1 kk 35, - (31 päivää), n. 1, 13 mk/päivä • 2 kk 65, - (61 päivää), n. 1, 06 mk/päivä • 3 kk 90, - (91 päivää), n. 99 penniä/päivä • 6 kk 160, - (182 päivää), n. 88 p/päivä • 12 kk 300, - (365 päivää), n. 82 p/päivä • Kaikki hinnat sisältävät arvonlisäveron. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 14
Example: WWW-based market place “Keltainen pörssi”: server • 2. Tilaus astuu voimaan: • -- pp. kk. yyyy • Muuta päivämäärää mikäli haluat tilauksesi alkavan myöhemmin. Solo-maksun päivämäärä on 22. 09. 1999 • 3. Tilauksen maksu. Valitse maksutapa: Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 15
Example: WWW-based market place “Keltainen pörssi”: server • • Merita Pankki 158430 -19766 Osuuspankki 573008 -2111579 Saaja: Infosto Mediat Oy Viesti: Keltainen Pörssi Online tilaus Tilaus alkaa: 22. 09. 1999 Lukupäiviä: 31 Maksaja: veijalainen jari Siirry pankin maksupalveluun: Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 16
Example: WWW-based market place “Keltainen pörssi”: server • Merita Osuuspankki Leonia • Eräpäivä: • HETI • Viite 860761 mk 35, • Tilaushinta sisältää arvonlisäveron (22%). Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 17
Example: The WWW-banking application at Merita: end box, return to the service provider • Jatka Palaa myyjän palveluun -valinnalla, jolloin ostoksesi rekisteröityy varmasti myös myyjälle. Jos tämän jälkeen tarvitset kopion maksamastasi Solo-maksusta, saat sen Solo-pankista maksutilisi tapahtumakyselyllä. Saajan tilinumero, saaja 158430 -19766 INFOSTO MEDIAT OY Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 18
Example: The WWW-banking application at Merita • Viesti Keltainen Pörssi Online tilaus, Tilaus alkaa: 22. 09. 1999, Lukupäiviä: 31 • Maksaja: VEIJALAINEN JARI • Tililtä 223456 -12345 Viite 8 60761 Eräpäivä Heti; Määrä 35, 00 mk • Arkistotunnus: 22092588 INW 20698 Yhteysnumero: 23531920 sivu 3 tehty 22. 09. 1999 19: 05: 30 © Copyright Merita Invited talk at TDD’ 99, Dagstuhl, 19 Pankki Germany, Sept. 27 1999
Example: back to the server at “Keltainen pörssi” • Tilauksesi (31 päivää) on talletettu ja lukuoikeutesi on tullut voimaan. • Siirry lukemaan ilmoituksia pääosastoille. • Siirry "Oma sivuni" -sivulle, jossa voit muuttaa omia tietojasi ja näet palvelun uudet käyttömahdollisuudet. Copyright © 1996 -1999. Infosto Group. All rights reserved Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 20
Keltainen pörssi: the overall scheme (interactions HTTP or HTTPS) – Customer Keltainen pö 3 rd party (Merita) Order service Ask for funds transfer Contact the bank application Ask the customer to log in Login information Generate and send the payment Confirm the payment order with a PIN Press end button Confirm service order to the customer Confirm the payment and ask the customer to press end butt Conf. Payment to merchant Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 21
Keltainen pörssi: some analysis – The regulatory framework is “providing services”; therefore, the customer cannot cancel it through a normal procedure Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 22
Keltainen pörssi: some analysis – The merchant and bank must have standardized the information content and format sent between them (via customer and directly); otherwise an application could not process it – the merchant can be very sure that it got the money if the bank acknowledges the transaction (it is moved immediately from the customer account to the merchant account) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 23
Keltainen pörssi: some analysis – from transactional point of view the system is rather vulnerable, because if the customer would not exit the service of the bank with “end button” it would be highly probable that the merchant would not consider the payment to have succeeded and would deny the service, although it was paid – the same holds if it does not get the confirmation from the bank about the payment although it got the end-button confirmation from the customer at TDD’ 99, Dagstuhl, Invited talk 24 Germany, Sept. 27 1999
Keltainen pörssi: some analysis – The latter situation occurs when the customer either did not go at all to the bank and tries to cheat the merchant or when the customer contacted the bank that made the funds transfer but failed before it was able to confirm the payment to the merchant – the merchant would probably assume the first case and would deny the service - until the status of the payment is maybe manually checked Invited talk at TDD’ 99, Dagstuhl, 25 Germany, Sept. 27 1999
Keltainen pörssi: some analysis – In general, the activities between merchant, customer and the bank should be seen as one distributed transaction that should be run in an atomic way: – the atomicity condition covering the situation: the service must be granted by the merchant iff the customer pays the service Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 26
Bokus: registration: name, e- and snail mail address, birth time – Ensimmäisen tilauksen yhteydessä asiakkaan a) on ollessaan Kuluttaja, rekisteröitävä itsensä Bokuksen asiakasrekisteriin ja ilmoitettava nimensä, sähköpostiosoitteensa, osoitteensa ja syntymäaikansa. – Comment: all this information can be wrong (e. g. wrong identity); existence of an address can be checked in Finland, though, as well as who lives there; but probably they do not do it Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 27
WWW. bokus: choose a userid and password and allow registering the info • c) tulee valita itselleen käyttäjätunnus ja salasana, joita käytetään tilausten yhteydessä d) tulee antaa suostumuksensa siihen, että Bokus kirjaa henkilötiedot asiakasrekisteriinsä. • Comment: I did not check what happens if I do not want my data to be stored at their customer registertalk at TDD’ 99, Dagstuhl, Invited 28 Germany, Sept. 27 1999
Www. bokus: take good care of the userid and password, do not let others use them – 1. 3 Asiakkaan on´huolehdittava käyttäjätunnuksestaan ja salasanastaan. Asiakas ei saa luovuttaa näitä tietoja henkilölle, jolla ei ole oikeutta tehdä tilauksia asiakkaan puolesta. – Comment: there is no actual sanction if a customer hands over his or her userid and password further; evidently, bokus would consider the customer liable Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 29
WWW. bokus: read always the valid conditions from the web • 1. 2 Asiakas sitoutuu jokaisen tilauksen yhteydessä kulloinkin voimassa olevaan Bokuksen kotisivulla (www. bokus. com) ilmeneviin sopimusehtoihin, jotka koskevat toimituksia Suomessa. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 30
Bokus: Customer register: confidental, no further obligations as what is said in the terms (contents not explained) • 1. 4 Bokuksen asiakasrekisteri on luottamuksellinen. Bokus sitoutuu olemaan luovuttamatta siinä olevia tietoja ulkopuolisille kaupallisiin tarkoituksiin. • 1. 5 Rekisteröiminen ei aiheuta asiakkaalle muita kuin näissä sopimusehdoissa mainittuja velvollisuuksia. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 31
Bokus: terms and conditions: payments based on invoice: due date 21 days • Maksu suoritetaan laskua vastaan. • 3. 2 Kuluttajan tulee suorittaa maksu 21 päivän kuluessa laskun päivämäärästä. 3. 3 Yritysasiakkaan tulee suorittaa maksu 30 päivän kuluessa laskun päivämäärästä. • 3. 4 Maksusuorituksen myöhästyessä peritään 30 mk muistutusmaksu ja vuotuisena viivästyskorkona 10%. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 32
Bokus: ownership of the books: bokus owns the books until paid 100 % • 3. 5 Kaikki toimitetut kirjat ovat Bokuksen omaisuutta siihen asti, kunnes kirjat on kokonaan maksettu. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 33
Bokus: How to order: only through www. bokus. com, information exchange: email • 4. 1 Tilaus voidaan suorittaa ainoastaan internetin välityksellä osoitteessa • www. bokus. com. • 4. 2 Kommunikointi asiakkaan ja Bokuksen välillä tapahtuu sähköpostitse. • 4. 3 Asiakkaan tulee tarkistaa, että Bokuksen sähköpostitse lähettämä tilausvahvistus on saapunut. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 34
Bokus: confirmation of the order: an email in 3 working days after the placement of the o. • Mikäli vahvistus ei saavu kolmen arkipäivän kuluessa tilauksesta, asiakkaan on otettava yhteyttä Bokukseen osoitteessa info. suomi@bokus. com • if the confirmation does not arrive in 3 days the customer has to contact bokus by email • bokus. com is committed to the order only if it sends the confirmation by email Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 35
Bokus: comments to the confirmation procedure – This way of working is quite strange, the process within Bokus seems to be as in a mail order business – what does Bokus use the 3 days for after the order is placed? Do they check the credibility of the customer? Or their stock? – the customer has to remind the company, if there is no confirmation in 3 days! Otherwise the customer is in doubt Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 36
Bokus: delivery of the books: in 7 working after the placement of the order – 5. 1 Bokus delivers books only to Finland – 5. 2 The books are delivered mainly in 7 days after the placement of the order – 5. 3 Should the delivery most probably take more than seven days, Bokus will inform this to the customer, as soon as possible, by email – comment: there is no definite promise to deliver in 7 days or inform the customer in any fixed time=> the customer is uncertain 7 days Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 37
Bokus: Canceling an order due to late delivery • If Bokus has informed the customer about delayed delivery, the customer has right to cancel the order • comment: it is not said how fast the customer should react to the delayed delivery notification Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 38
Bokus: Canceling an order in the normal case – 6. 1 The consumer cancel the transaction in 7 days after he/she has got the book. This can happen either by sending a canceling email to info. suomi@bokus. com within the above time period, or the consumer can return the book to Bokus com Oy, PL 1660, 01531 Vantaa. The customer will not be charged provided he/she uses the general form available in post offices and the book is faultless Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 39
Bokus: Returning the book without costs – Comment 1: it remains unclear, when the book should be returned if email is used to cancel – comment 2: it also remains unclear what will be charged and when if the book is not faultless when returned – comment 3: from transactional point of view, should cancellation be part of the ordering transaction or a separate one? When does canceling transaction end? Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 40
Bokus: end of my transaction • Keskiviikko 22. syyskuuta 1999 • Kiitos tilauksestasi! Olet kirjautunut ulos järjestelmästämme. Tässä kuittisi, tilauksesi on välittynyt bokus. comille. Jos sinulla on kysyttävää pyydämme sinua ystävällisesti lähettämään meille sähköpostia osoitteeseen info. suomi@bokus. com Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 41
Bokus: eot: receipts of my order: the book and price • Olemme vastaanottaneet tilauksesi seuraavista kirjoista: • Tippaleipä Kaalipadassa Ja Muita Ilmiöitä : Kirjoituksia Vuo 1 156. 00 Kokonaissumma: FIM 156. 00 (josta alv. 11. 56) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 42
Bokus: Receipt of my order: userid, date, payment method (inv) order#, customer#, ref#, • Käyttäjätunnus: veijalainenj Päivämäärä: Keskiviikko 22. syyskuuta 1999 kl 19. 02 • Maksutapa: Lasku (maksuehdot 21 päivää) • Tilausnumero: 479556735 • Asiakasnumero: 192890 • Tilauksen viite: varis 22099 Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 43
Bokus: Receipt of the order: delivery address • Osoite: • Jari Veijalainen • • • Rantatie 2 B 6 40900 Jyväskylä Suomi Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 44
Bokus: Confirmation of the order by email two days later » Date sent: Fri, 24 Sep 1999 08: 12 +0200 » From: "bokus. com" <info. suomi@bokus. com> » To: "Jari Veijalainen" <veijalai@jytko. jyu. fi> » Subject: Tilausnumero/Order nr 479556735 » Viite/Referens: tilausnumero/ordernr 479556735. » Tilauksesi viite/Orderreferens: varis 220999. » Vahvistamme, että tilauksesi seuraavista kirjoista on vastaanotettu: » Arvioitu toimitusaika on 7 arkipäivää. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 45
Bokus: Confirmation of the order by email two days later » * 1 kpl/ex av Tippaleipä Kaalipadassa Ja Muita Ilmiöitä : Kirjoituksia Vuo - Varis, Tuula-Liina » Jos sinulla on kysymyksiä, otamme mielellämme vastaan sähköpostia osoitteeseen: info. suomi@bokus. com » Ystävällisin terveisin, bokus. com » Om du har frågor är du välkommen att skicka epost till <info. suomi@bokus. com>. » Med vänlig hälsning, bokus. com. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 46
Bokus: some analysis – How certain is the customer identity? They can actually check my real address by calling a certain general service number in Finland – they will get the creditworthiness information from the bank association if they want – they probably have my IP# stored – if I pay the book, they will get my banking information and probably will store it into their customer register Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 47
Bokus: some analysis – Regulatory framework: clearly the mail order business legislation applies here; in this case the company grants credit to the customer for 21 days - and hopes that the customer pays after he/she has got the book(s) – this is two-party business, there is no explicit third party securing information or guaranteeing that the customer is creditworthy – cancellation of the order is a normal part of the business Invited talk at TDD’ 99, Dagstuhl, 48 Germany, Sept. 27 1999
Bokus: ec-transactions? • Customer 7 days 21 days Order (WWW) Bokus Process order (3 days) Confirmation (email) Send the books(s) The book(s)+invoice Wait: cancel|payment Cancel (email, optional) The book(s) returned Process cancellation Payment (through banking system) Process payment Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 49
Bokus: ec-transactions? – At Bokus, the right-hand side is conceptually one (ec-)transaction; simplified it has the steps – 1. take an order through WWW 2. process order(check stock&cust. , sendconf) 3. send the book(s) to the customer 4. if cancellation (check its validity; check the returned book; send a bill to the customer) 5. if time-out, send a reminder to the customer 6. process the payment; Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 50
Bokus: ec-transactions? What properties does such ectransactions have? – An appealing way to model the above set of steps as a workflow at Bokus and view its execution as a special kind of “ec”-transaction – The ec-transaction is long-lasting (>21 days) – it has real steps (sending and receiving physical books) – not clear what should be done in certain exceptional cases => exception handling – it must be decided when to end the ectransaction if books neither paid nor returned Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 51
Bokus: ec-transactions? – Atomicity condition “the customer must get the books he/she ordered and Bokus the payment or if the customer cancels the order properly, Bokus must get the book(s) back and perhaps money as compensation for the damages” – it is clear that a system can guarantee the above rule only to certain degree, because the customer cannot be forced to pay or send back the book(s) Invited talk at TDD’ 99, Dagstuhl, 52 Germany, Sept. 27 1999
Bokus: ec-transactions – How about durability? It is mandatory that the states, like order accepted and confirmed, book sent, order canceled, etc. of the ec-transaction (I. e. workflow) at Bokus are stored in a durable way => the states must be stored into a database and committed separately at the end of each step (this can be a property of a WFMS) – that the transaction (I. e. workflow) description must be stored in a durable way Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 53
Bokus: ec-transactions – Isolation? Different ec-transaction instances (order processing) must be isolated from each other and also steps that update the same data items => normal database concurrency control is needed at the lower system level – Consistency: two levels: the individual step level, where each state must be consistently as a whole recorded into a db: at higher level it is required that certain steps have been performed - possibly in a certain order Invited talk at TDD’ 99, Dagstuhl, 54 Germany, Sept. 27 1999
Amazon. com: check-out window – (to Buy Later) – You can save items here to buy later. – When you're ready to buy any of your saved items, just move them to your cart. – Items remain in your Shopping Cart for 90 days. – Learn more about the Shopping Cart and how to buy items at Amazon. com. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 55
Amazon. com – Ordering Online at Amazon. com Is Safe and Easy -– Guaranteed! – Click here to continue your order on our secure server. – If you received an error message when you tried to use our secure server, continue your order on our standard server. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 56
Amazon. com: Safe Shopping Guarantee – We guarantee that every transaction you make at Amazon. com will be 100% safe. This means you pay nothing if unauthorized charges are made to your card as a result of shopping at Amazon. com. – Guarantee Details: Under the Fair Credit Billing Act, your bank can not hold you liable for more than $50. 00 of fraudulent charges. If your bank does hold you liable for any of this $50. 00, Amazon. com will cover the entire liability for you, up to the full $50. 00. Amazon. com will only cover this liability if the unauthorized use of your credit card resulted through no fault of your own from purchases made at Amazon. com while using the secure server. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 57
Amazon. com – In the event of unauthorized use of your credit card, you must notify your credit card provider in accordance with its reporting rules and procedures. – Continue with your order on our secure server. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 58
Amazon. com: entering customer information • Completing Your Order Is Easy • We encourage you to enter your credit card number online (why this is safe). However, you also have the option of phoning us with the number after completing the order form. If you have any problems or questions, see the bottom of the page for details on our toll-free (800) customer support number. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 59
Amazon. com: enter emailaddress • Welcome. • Please enter your e-mail address: • Please check your e-mail address for accuracy; one small typo and we won't be´able to communicate with you about your order. • I am a first-time customer. (You will be asked to create a password later on. ) • I am a returning customer, and my password is. • Have you forgotten your password? Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 60
Amazon. com: choose your payment method. • credit card (Visa, Master. Card, Discoverm American Express, JCB, or Diners Club only) (why this is safe) gift certificate (or gift certificate and credit card, or balance on account) (how this works) • check or money order (why this takes longer) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 61
Amazon. com: enter address • Enter the shipping address. • Enter a new US address. This includes Puerto Rico, USVI, Guam, APO/FPO, etc. • Enter a new international address for anywhere else in the world. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 62
Amazon. com: 5. Check your order. • Please verify that the items and quantities shown below are correct. Put a 0 (zero) in the Quantity • field to remove a particular item from your order. • Quantity and Item Information: • Usually ships in 24 hours • • Memoirs of a Geisha; By Arthur S. Golden; • List: $14. 00 ~ Our Price: $7. 00 ~ You Save: $7. 00 (50%) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 63
Amazon. com: 6. entering the credit card information • We recommend that you enter your full credit card number. ( Why this is safe. ) Even if you're a returning customer, please re-enter your credit card number. ( Here's why. ) If you prefer to phone in your credit card, enter only the last five digits. After you have submitted your order, we'll give you the phone number to call. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 64
Amazon. com: 6. entering the credit card information • Credit card number: • Type of credit card: Visa Master. Card Discover American Express JCB Diners Club • Credit card expiration date (only month and year required): • Cardholder's name as it appears on the credit card: • Zip or postal code of the billing address for this card: Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 65
Amazon. com: re-entering the credit card number • When placing a new order as a returning customer (your second or later order), we automatically fill in the credit card information for you so that you won't have to reconfirm the card with us. There is, however, an important exception to this rule: • If you request shipment to a new address (one you haven't used with us before with this credit card) or, for gift certificates, send an e-mail gift certificate to an e-mail address that you haven't used before, we ask you to reconfirm the credit card for your own security. This way, should some third party guess Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 66
Amazon. com: re-entering the credit card number • your password and attempt to order items for themselves on your account, the attempt would fail. • We hope you'll understand that this is a valuable security precaution designed to protect our customers. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 67
Amazon. com: Enter password • When you come back to Amazon. com in the future, you can use your e-mail address and the • password you choose here to access your account. This means: you won't need to type in your address again you won't need to give us your credit card number again unless you enter a new shipping address • you'll be able to check the status of your orders from the Your Account page • Enter a password of your choice: • Confirm this password: Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 68
Amazon. com: confirmation of order by email: immediate • From: orders@amazon. com • Date sent: Thu, 23 Sep 1999 05: 50: 45 0700 (PDT) • To: veijalainenj@acm. org • Subject: Your Order with Amazon. com (#002 -4352468 -0391217) • Thank you for ordering from Amazon. com! • Your order information appears below. If you need to get in touch with us about your order, send an e-mail message to orders@amazon. com (or just reply to this Invited talk at TDD’ 99, Dagstuhl, 69 message). Germany, Sept. 27 1999
Amazon. com: confirmation of the shipment: email 14 hours later – From: orders@amazon. com – To: veijalainenj@acm. org – Subject: Your Amazon. com order (#0024352468 -0391217) – Date sent: Thu, 23 Sep 1999 19: 04: 50 -0700 (PDT) – We thought you'd like to know that the following item has been – shipped to: Jari Veijalainen – Rantatie 2 B 6 – Jyvaskyla 40900 – Finland Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 70
Amazon. com: order canceling policy – Within 30 days of receipt of your order, you may return any book in its original condition, any book we recommended (and you didn't enjoy) in any condition, and any unopened music CD, DVD, VHS tape, or software and any toy, electronics, or any other merchandise in new condition, with its original packaging and accessories. See our …. Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 71
Amazon. com: the overall scheme – Customer Amazon. com 3 rd party (VISA) Order (WWW) Order proc. Ask for authorization Ack Confirm order (email) Request payment Confirm shipment (email) Ship the book (DHL) 30 days Ack/ Return the book (possibly) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 72
Amazon. com: some analysis – The regulatory framework is based on USA legislation and differs from the EU framework in that Amazon. com is entitled to charge the customer before the book is received – Basically, the same conclusions can be drawn as for Bokus as concerns the properties of ectransactions; it is a workflow at Amazon. com – atomicity rule in this case could read “Amazon. com keeps the payment iff the customer keeps the book” Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 73
Amazon. com: some analysis – Amazon. com does not ask whether they may store some of my information to their customer register and how to use it – they have stored my IP address and actually allow orders to be placed based only on it => this is a security flaw because anybody could go to my room, take contact at Amazon. com with my computer and place an order in my name using my credit card; it would be a gift to him or her (or use. Invited talk at TDD’ 99, Dagstuhl, a moment) 74 my IP-address for Germany, Sept. 27 1999
Amazon. com: some analysis – Another thing is that I do not know how securely my credit card and other information has been stored at Amazon. com; there has been some information about security problems – they accept a virtual email address for which they cannot acquire the real mapping (in my case veijalainenj@acm. org); they would probably become suspicious, if the messages they send bounce back; but would they cancel or suspend the shipment? Dagstuhl, Invited talk at TDD’ 99, 75 Germany, Sept. 27 1999
Can distributed “ec”-transactions help to increase security and privacy? – First, it is always question of the how big values are in stake: the larger values, the higher and more expensive security required – e. g. S. W. I. F. T. s system transfers billions of $/day and it is highly secure; a message used to cost 17 BFR (ca. 50 cents) – in the current e-commerce systems there are security holes and also privacy of the customers might be jeopardized ; is the security too low as compared to Invited values at. Dagstuhl, the talk at TDD’ 99, stake? 76 Germany, Sept. 27 1999
Can distributed EC-transactions help to increase security and privacy? – in the current e-commerce systems is the customer identity check is not very reliable; done only once when the (first) order is placed and that after that the customer does not need to acknowledge anything during a transaction – what if the customer should acknowledge the announcement that the shipment is ready to go and possibly also that he/she has got the books – additionally, the identity of the customer could be required also at these stages Invited talk at TDD’ 99, Dagstuhl, 77 Germany, Sept. 27 1999
Distributed ec-transactions – Customer Merchant 3 rd party (VISA) Order (WWW) Order proc. Confirm order (email) Request payment 30 days Ack/Nack Ask for shipment permission Grant permission Ship the goods (DHL) Conf reception Return the book Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 78
Distributed ec-transactions: some problems and solutions – To which extent does the customer want to take part in several phases of the protocol? He or she must comply with one or two additional phases, otherwise the merchant’s process is stopped – technical problems: an email containing free text as a confirmation to the customer is fine; but if the customer confirms with a message containing freely chosen text, it will be rather difficult to automate the processing at merchant’s server => standardize the confs Invited talk at TDD’ 99, Dagstuhl, 79 Germany, Sept. 27 1999
Distributed ec-transactions: some problems and solutions – Standardization of the customer confirmation can be done in several ways – the obvious one is based on forms at merchant’s server that the user should fill after having got the request for confirmation by email and after having got the book – another solution is based on the ec-transaction’s state information at customer’s workstation, based on browser, applet, and email Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 80
Distributed ec-transactions: checking identity of the customer and merchant – Another solution is to use rigorous identity check during order processing so that the probability that the customer or the merchant use false identity becomes very low – typically, public key infrastructure and digital signatures can be used for this purpose – protects the merchant against repudiation and customer against forged orders and dishonest merchants Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 81
Distributed ec-transactions: checking identity of the customer and merchant: SET • Secure Electronic Transaction Specification (SET) www. setco. org – can be used to authenticate parties and encrypt messages – relies on Public Key infrastructure and Certificate Authority (CA) – leads to four-party scheme: customer, merchant, payment mediator, CA Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 82
Concluding remarks about ectransactions in wireline networks • Two dimensions: – local workflow running at the merchants server, consisting of interrelated steps: main problems are how to guarantee atomicity and durability for the workflow during weeks of running – interoperation of the above workflow with a customer somewhere in the world: here the problem is mainly to guarantee that the customer identity is not faked and that the messages are. Invited talk at TDD’ 99, Dagstuhl, not faked 83 Germany, Sept. 27 1999
Concluding remarks about ectransactions in wireline networks – The former problems could be dealt with in the context of transactional workflows, – the latter are actually a new aspect in transaction processing: how to combine security and transactions in a distributed hostile open environment – further, these aspects should be combined in a smooth way using existing standards as much as possible Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 84
Concluding remarks about ectransactions in wireline networks – The user should be able to specify him/herself how high a security level is appropriate e. g. – the current level, where the identity is not really checked and confirmations not asked – level, where the major steps of the workflow must be acknowledged by the customer – level, where customer and merchant identity are rigorously checked when order is placed – level, where at each major step identity is checked and acknowledgement required Invited talk at TDD’ 99, Dagstuhl, 85 Germany, Sept. 27 1999
Mobility in E-commerce • There are two different but related concepts of mobility: – people move physically and change the access point to a network or change the network; they do not need to carry any access devices with them – people move and carry physical access devices, typically mobile phones, and possibly portable computers or PDAs with them Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 86
Mobile terminals in E-commerce: one of the access technologies PC TV set PC Mobile terminal WAP gateway IP Network Merchant server Content providerserver Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 87
Mobile terminals in E-commerce – Laptop+radio modem (e. g. GSM phone) work in principle like a workstation at wireline network; the transmission speed is low, though – Wireless Application Protocol (WAP) makes access from weak GSM terminals to Internet possible – The first terminals are about to come to the market place; Ericsson R 320, Nokia 7110 – already hundreds of services (Sonera) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 88
Mobile terminals in E-commerce – Natural new services for mobile terminals are location-based services that will probably be target of trading in the future – Otherwise, if a mobile terminal is used in Ecommerce, it should do the same things as a workstation – If a laptop is in game, then this is rather realistic, but with the hand-held devices the problems are resource scarcity - and thefts Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 89
Mobile terminals in E-commerce – The resource scarcity means that – the terminal cannot display pages with a lot of graphics (small displays, slow data transmission), cannot store large amounts of data, cannot compute complicated functions that require many processor cycles (battery) – if transactional mechanisms are used they should be so light-weight that such a terminal can run them Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 90
Mobile terminals in E-commerce – The security mechanisms should be designed in such a way that stealing portable terminal (WAP phone or laptop) would not make possible to start e-commerce transactions at the merchant servers using the stolen device (for instance storing the private key in the terminal memory is probably not a good idea; SIM-card might be a better place, but it is still protected only by a PIN) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 91
Mobile terminals and Bluetooth technology in payments – Currently Bluetooth technology is developed to support short-range radiolinks between all kinds of devices like phones, cash registers, printers, busses etc – payments could be done e. g. using a WAP phone over Bluetooth to the cash register – in this case it is rather open, what kind of transactional services and security measures would be needed; see http: //www. bluetooth. com/ Invited talk at TDD’ 99, Dagstuhl, 92 Germany, Sept. 27 1999
Conclusions – “EC”-transactions have two dimensions, transactional workflow and distribution – they should be tightly integrated with security, authorization, and privacy – transactional mechanisms should be adaptable to the protected value: the higher value, the more phases and identity checks – different regulatory frameworks require different transactional structures Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 93
Conclusions – The existing and emerging technology should be adopted or adapted in this context (like, SET, XML, etc. ) – Mobile terminals pose special requirements also for transactional services (C-autonomy, scarce resources, possible debts ) – Completely new technologies like Bluetooth might require again rethinking Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 94
References • Several references at http: //domino. watson. ibm. com/library/cyber dig. nsf/Home ; see e. g. • Michael Waidner: Open Issues in Secure Electronic Commerce (10/98) at http: //domino. watson. ibm. com/library/CYB ERDIG. NSF/a 3807 c 5 b 4823 c 53 f 852565610 06324 be/5615 a 8 b 7981 dd 8 d 9852566 f 3004 f 8 bf 7? Open. Document. TDD’ 99, Dagstuhl, Invited talk at 95 Germany, Sept. 27 1999
References • Results of ACTS project SEMPER (AC 026) http: //www. semper. org/ • Distributed and Parallel Databases An International Journal Volume 7, Issue 2, April 1999 (Special issue on Electronic Commerce) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 96
References • EDI for B-To-B: see www. swift. com • W 3 C on Ecommerce see http: //www. w 3. org/Ecommerce • SET specifications: see http: //www. setco. org Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 97
R&D at W 3 C for XML/EDI • W 3 C encourages independent work aimed to encode the UN/EDIFACT EDI standard in XML. • http: //www. w 3. org/ECommerce/Overviewxmledifact Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 98
Some other problems: very cheap goods and micropayments – With the rising importance of intangible (e. g. information) goods in global economies and their instantaneous delivery at negligible cost, "conventional" payment methods tend to be more expensive than the actual product. On the other hand, billing for small portions of a product or service reduces the need of security* * security is defined here to be the ratio of security cost to protected value Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 99
SWIFT: More semantics into message types (B-to-B EDI) • standards for message types will be complemented by processing rules and will take the entire transaction chain into consideration. • based on existing market practices, the principal business scenarios of a particular transaction will be documented. Stricter and more formal standards definitions will help reduce the risk TDD’ 99, Dagstuhl, Invited talk at of misinterpretation. 100 Germany, Sept. 27 1999
SWIFT: More semantics into message types (B-to-B EDI) • sponsors of several industry standards will be consulted to move towards a single industry standard. • See http: //www. swift. com Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 101
Autonomy and control in EC – Organizational autonomy means that an organization can freely make choices irrespective of the will of other organizations – organizational autonomy manifests itself in many ways in the technical infrastructure, especially in the information and communication systems; one can separate e. g. Design, Communication, Management, and Execution autonomy attributed to systems Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 102
Autonomy and control in EC • In EC diverse participants take part that have a separate identity, O-autonomy and thus often heterogeneous systems – how can they agree upon the common process(es) to set up and dissolve a VE? – How can the actual inter-organizational business processes be defined? – How can the technical standards that make communication, cooperation, and coordination possible between their systems be specified? Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 103
Autonomy and control in EC • The above issues require a Global Designer, a group of humans that settle them – the work of a GD can be organized in many ways like using an international standardization body, special consortium, a group selecting suitable existing standards and options etc. and it largely depends on the nature of the domain and its size; the work can be supported by IT (e. g. groupware), but this is conceptually not important Invited talk at TDD’ 99, Dagstuhl, 104 Germany, Sept. 27 1999
Autonomy and control in EC – The more external control the less autonomy and vice verso – In an extreme case a powerful company can function as a GD and dictate to small subcontractors and individual customers the business processes and standards to be obeyed – who controls a EC? How? Is it the customer base? Or some big companies ? Or is there a “democratic” control with appropriate structures of the GD, like CEC? Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 105
Some fallacies • Existence of good IT standards is sufficient for EC (cf. heterogeneity) – no, because there are usually more than one standard that can be used at different levels of system architecture (e. g. protocol stacks) and different participants might push different solutions – no, because standards are often metastandards (like EDIFACT, XML, HTML, IDL) and GD must agree also upon the instance level Dagstuhl, 106 standards Invited talk at TDD’ 99, 1999 Germany, Sept. 27
Some fallacies – EDIFACT ->concrete message types – IDL -> the concrete interfaces with exact functions and parameters – HTML -> the forms to be used in cooperation – XML: the language to be used in cooperation (like WML) and subsequently the WML pages – process description languages (Wf. MC) -> concrete standard business process descriptions for the Virtual Enterprises Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 107
Some fallacies • Competing companies cannot participate in the same ec-transaction – this is not true, e. g. international banks compete but they cooperate through S. W. I. F. T. to transfer money and provide other financial services – both Nokia and Ericsson take part in WAPforum although they compete in the world (common vs. conflicting interests) Invited talk at TDD’ 99, Dagstuhl, Germany, Sept. 27 1999 108
Скачать презентацию Transactions in mobile electronic commerce Jari Veijalainen University
52991680bb7fc863f52f5bcb331862d3.ppt