Transactions in mobile electronic commerce

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



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



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



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)



5

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



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



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.



8

Customer-to-business E-

Commerce

– 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


9


Commerce

– 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



10


Commerce

– 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

Invited talk at TDD’99, Dagstuhl, the customer;


11


Commerce

– 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.w3.org)

– as we will see, standardization would probably be needed also if “ec”-transactions would be used



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



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.



• 2. Tilaus astuu voimaan:

14


•

• 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:



15


• 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:



16


• Merita Osuuspankki Leonia

• Eräpäivä:

•

• Viite 860761 mk 35,-

HETI

• Tilaushinta sisältää arvonlisäveron (22%).



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



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: 22092588INW20698

Yhteysnumero: 23531920 sivu 3 tehty 22.

09.1999 19:05:30 © Copyright Merita

Pankki Invited talk at TDD’99, Dagstuhl,


19

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



20

Keltainen pörssi: the overall scheme (interactions HTTP or

HTTPS)

– Customer Keltainen pö 3rd 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 order to the customer

Confirm the payment order with a PIN

Confirm the payment and ask the customer to press end butt

Press end button

Conf. Payment to merchant

Confirm service



21

Keltainen pörssi: some analysis

– The regulatory framework is “providing services”; therefore, the customer cannot cancel it through a normal procedure



22


– 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)



23


– 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

24



– 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



25


– 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



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



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

28


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



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.



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.



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 30mk muistutusmaksu ja vuotuisena viivästyskorkona 10%.



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.



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.



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



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



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



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



38

Bokus: Canceling an order in the normal case

– 6.1 The consumer can 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



39

Bokus: Returning the book without costs

– Comment1: it remains unclear, when the book should be returned if email is used to cancel

– comment2: it also remains unclear what will be charged and when if the book is not faultless when returned

– comment3: from transactional point of view, should cancellation be part of the ordering transaction or a separate one? When does canceling transaction end?



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



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)



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: varis22099



43

Bokus: Receipt of the order: delivery address

•

•

•

• Osoite:

• Jari Veijalainen

Rantatie 2 B 6

40900 Jyväskylä

Suomi



44

Bokus: Confirmation of the order by email two days later

» Date sent: Fri, 24 Sep 1999 08:18: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: varis220999.

» Vahvistamme, että tilauksesi seuraavista kirjoista on vastaanotettu:

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.co

m

» 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.



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



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



48

Bokus: ec-transactions?

• Customer

7 days

Bokus

Order (WWW)

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

21 days

Payment (through banking system)

Process payment



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;



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



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)



52

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



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



54

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.



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.



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.



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.



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.



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?



60

Amazon.com:choose your payment method.

• credit card (Visa, MasterCard, 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)



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.



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%)



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.



64

Amazon.com: 6. entering the credit card information

• Credit card number:

• Type of credit card: Visa MasterCard 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:



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



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.



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:



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, message).


69

Amazon.com: confirmation of the shipment: email 14 hours

– From: later orders@amazon.com

– To: veijalainenj@acm.org

– Subject: Your Amazon.com order (#002-

4352468-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



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 ….



71

Amazon.com: the overall scheme

– Customer Amazon.com 3rd party (VISA)

Order (WWW)

Ask for authorization

Order proc.

Ack

Confirm order (email)

Request payment

Confirm shipment (email)

Ship the book (DHL)

Ack/

30 days

Return the book

(possibly)



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”



73


– 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 my IP-address for a moment)


74



– 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?



75

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

76


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

77


Distributed ec-transactions

– Customer Merchant 3rd party (VISA)

Order (WWW)

Order proc.

30 days

Confirm order (email) Request payment

Ask for shipment permission

Ack/Nack

Grant permission

Ship the goods (DHL)

Conf reception

Return the book



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



79

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



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



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



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

83



– 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



84


– 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

85


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



86

Mobile terminals in E-commerce: one of the access technologies

PC

TV set

PC

Mobile terminal

WAP gateway

IP Network

Merchant server

Content provider-


Germany, Sept. 27 1999 server

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 R320, Nokia 7110

– already hundreds of services (Sonera)



88


– 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



89


– 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



90


– 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)



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

92


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



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



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/a3807c5b4823c53f852565610

06324be/5615a8b7981dd8d9852566f3004f

95


References

• Results of ACTS project SEMPER (AC026) http://www.semper.org/

• Distributed and Parallel Databases

An International Journal

Volume 7, Issue 2, April 1999 (Special issue on Electronic Commerce)



96

References

• EDI for B-To-B: see www.swift.com

• W3C on Ecommerce see http://www.w3.org/Ecommerce

• SET specifications: see http://www.setco.org



97

R&D at W3C for XML/EDI

• W3C encourages independent work aimed to encode the UN/EDIFACT EDI standard in XML.

• http://www.w3.org/ECommerce/Overviewxmledifact



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



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

100


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



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



102


• 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?



103


• 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



104


– 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?



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 standards Invited talk at TDD’99, Dagstuhl,


106

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 (WfMC) -> concrete standard business process descriptions for the Virtual Enterprises



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)



108

Transactions in mobile electronic commerce

Related documents

Products

Support

Transactions in mobile electronic commerce

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib