Automatic Generation of Reliable E Commerce Payment Processes

Transcription

1 Infomation Systems Engineeing (WISE 2000), Hong Kong, China, June Automatic Geneation of Reliable E Commece Payment Pocesses Heiko Schuldt Andei Popovici Hans-Jög Schek Institute of Infomation Systems Swiss Fedeal Institute of Technology (ETH) ETH Zentum, CH 8092 Züich, Switzeland fschuldt,popovici,schekg@inf.ethz.ch Abstact The most impotant phase in E Commece inteactions is the payment, due to the tansfe of sensitive infomation (e.g., cedit cad numbes). A couple of equiements exist both fom the point of view of a custome and fom the mechant s pespective. This set of equiements is even enlaged when complex inteactions ae consideed in which a custome puchases goods oiginating fom diffeent mechants within one single E Commece tansaction. In this pape, we show how all these diffeent equiements of payment inteactions can be seamlessly integated in tansactional payment pocesses. These pocesses ae geneated automatically based on the custome s specification of the E Commece tansaction (involved paticipants, means of payment, etc.). We pesent the basic stuctue of such payment pocesses, how the equiements ae mapped into these pocesses and how they can be geneated automatically. Futhemoe, we pesent the achitectue of a payment coodinato that has been implemented within the INVENT poject. This payment coodinato contols the execution of tansactional payment pocesses, theeby keeping tack of the inteactions with the vaious paticipants. 1 Intoduction The accomplishment of payments is the cucial pat in business to custome Electonic Commece (E Commece) inteactions since this phase does not only detemine the success o failue but also equies sensitive infomation to be tansfeed. Fom a geneal point of view, aside of the basic peequisite of secue communication, a couple of equiements fo coect payment inteactions exist, such as diffeent levels of atomicity in the exchange of money and goods between customes and mechants [25, 26]. Futhemoe, since faudulent behavio of paticipants has to be Pat of this wok has been funded by the Swiss National Science Foundation unde the poject INVENT (Infastuctues fo Vitual Entepises). consideed, the ability to legally pove the pocessing of a payment tansaction is equied. Remakably, E Commece is a vey intedisciplinay eseach aea. As existing appoaches ae poweed by diffeent communities (i.e., cyptogaphy, netwoking, etc.), they ae vey heteogeneous in natue and thus always focus on diffeent special poblems. Howeve, it has to be noted that in cuently exploited appoaches, suppot fo at least one of the above mentioned poblems is limited. All equiements ae even moe impotant when a custome inteacts not only with one mechant but with multiple mechants within one single E Commece tansaction. In these cases, distibution and heteogeneity additionally have to be consideed. Thus, taditional bilateal communication between the paticipants does no longe povide a feasible solution. The notion of atomicity, fo instance, has to be extended when such moe complex inteactions ae suppoted in that atomicity may be equied fo the puchase of seveal goods oiginating fom diffeent, possibly independent and autonomous souces (w..t. the exchange of money and all goods). Howeve, all cuently existing payment potocols lack suppot fo simultaneous atomic puchases fom multiple souces. To this end, we popose to implement business to custome E Commece payments by a tansactional pocess encompassing the divese inteactions between all paticipants [20]. A stingent equiement of such pocesses is that they ae eliable in that they povide the basic guaantees (e.g., atomicity) fo all paticipants; since ou appoach concentates on complex distibuted puchases and maco payments, the suppot of these guaantees is extemely impotant. A payment coodinato then contols the execution of payment pocesses and enfoces thei inheent execution guaantees even in the pesence of failues and concuency. The payment coodinato has to be located at the site of a tustwothy and eliable instance. In the Intenet age, howeve, this does not impose unsolvable estictions since such institutions ae aleady established, fo instance in the fom of cetification authoities o cleaing houses. 1

2 Aside of the eliability of the payment coodinato, the possibility to validate the coectness of each payment pocess is also equied. Theefoe, we intoduce a mechanism to geneate pocesses at the payment coodinato s site based on a geneic payment pocess template that is filled with the custome s desciption of he special E Commece tansaction. Futhemoe, we pesent the payment coodinato developed within the INVENT poject encompassing a tansactional pocess management system, a geneato fo payment pocesses, and a client application that allows the combination of diffeent inteactions into one E Commece tansaction which is invoked at the payment coodinato. This pape is stuctued as follows: In Section 2, we pesent elated wok addessing E Commece tansactions and payment inteactions. Then, we povide an oveview of the basic equiements imposed in E Commece payments (Section 3). Afte an intoduction of the basic concepts of tansactional pocess management (Section 4), the stuctue of the geneic payment pocess which is used to encompass all steps of payment inteactions is pesented (Section 5). In Section 6, we discuss the payment coodinato and identify the key aspects in which this payment coodinato exceeds the standad functionality of a tansactional pocess suppot system. Section 7 concludes the pape. 2 Related Wok Although E Commece ove the Intenet is a athe new but heavily evolving aea, a couple of appoaches addessing this new fom of tade exist. In geneal, a distinction is made between business to business (b2b) and business to custome (b2c) E Commece. While b2b focuses on component based integation of existing sevices into business pocesses of (vitual) entepises (e.g., [2, 8]) and data exchange [1], b2c E Commece mainly addesses coectness issues w..t. the inteactions of the vaious paticipants. In the b2c aea, initial wok by Doug Tyga povides a fist and geneal oveview of equiements of E Commece fom a customes pespective [4, 25, 26], mainly addessing atomic inteactions but with the estiction that only one custome and one mechant at a time is consideed. Accoding to [15], tade inteactions between customes and mechants can be classified in thee phases: pe-sales, sales and post-sales. The sales phase has a well-defined stuctue, which is in geneal not the case fo the pe-sales and the post-sales phase. Theefoe, pocesses ae a highly appopiate means to implement the inteactions that have to be pefomed fo payment puposes. In the context of E Commece payments, also seveal agent-based appoaches exist, e.g., [12, 27]. Howeve, all these appoaches eithe lack suppot fo distibution (which is in geneal pesent in the negotiation phase but not duing payment [27]) o they do not povide appopiate suppot fo tansactional execution guaantees in distibuted envionments [17]. 3 Requiements of E Commece Payments Seveal citeia seve as chaacteistics of electonic payments. We distinguish between secuity aspects, technical aspects and economical aspects. Secuity aspects encompass payment atomicity, povability, anonymity, and cyptogaphic secuity. Technical aspects conside the issues of scalability, efficiency, hadwae independence, and flexibility. Economical aspects finally focus on the fitness of a payment potocol to penetate in the E Commece maket. These ae, fo instance, tansaction costs and the inteaction between the client and the payment softwae (simplicity). The citical aspects of E Commece payments ae the secuity aspects. Theefoe, we will discuss these popeties in moe detail. 3.1 Atomicity One key equiement in E Commece payments is to guaantee atomic inteactions between the vaious paticipants. As E Commece and thus also payments take place in a highly distibuted and heteogeneous envionment, vaious aspects of atomicity can be identified Money Atomicity The basic fom of atomicity in E Commece is associated with the tansfe of money fom the custome to the mechant. This is denoted by the tem money atomicity [25, 26]. As no viable E Commece payment solution can exist without suppoting this atomicity popety, multiple solutions have been poposed o ae aleady established. Fo all account-based potocols (such as FistVitual [23], o NetCheque [16]) and fo all potocols based on payments by cedit cad (e.g., SET [22], o CybeCash [6]), money atomicity is guaanteed by the paticipating institutions of the financial wold. Fo payments based on electonic cash (e.g., ecash T M [7], o MilliCent [14]), money atomicity is tightly coupled with the potocol achitectue and design Goods Tansfe Atomicity Aside of the money tansfe, also the tansfe of the mechandise has to be pefomed atomically. Except fo [25], all cuently exploited payment potocols do not addess goods tansfe atomicity. Howeve, they do not teat goods tansfe atomicity independently fom the money tansfe. Both aspects ae athe captued jointly unde the notion of goods atomicity, although they ae not elated in geneal Distibuted Payment Atomicity In many E Commece applications, inteaction of customes is not limited to a single mechant. Conside, fo in-

3 stance, a custome who wants to puchase specialized softwae fom a mechant. In ode un this softwae, she also needs an opeating system which is only available fom a diffeent mechant. As both goods individually ae of no value fo the custome, she needs the guaantee to pefom the puchase tansaction with the two diffeent mechants atomically in ode to get all poducts o none. The poblem of distibuted puchase atomicity in geneal goes along with the fact that diffeent heteogeneous intefaces ae involved and diffeent communication potocols ae suppoted by the paticipating mechants. Although thee is a eal need to suppot distibuted E Commece tansactions, this aspect of atomicity is not yet consideed by any of the existing payment potocols. Ou appoach addesses atomicity in distibuted payments, yet in combination with money atomicity and goods tansfe atomicity. 3.2 Anonymity A custome wants to emain unknown against the mechant o a bank afte an electonic puchase. Potecting the custome and he spending pattens against othe paticipants in the payment is addessed by anonymity. We distinguish between patial anonymity and total anonymity. In the case of patial anonymity, the mechant does not get any pesonal infomation about the custome. Total anonymity, in contast, is chaacteized by the impossibility of both mechant and payment seve to captue any infomation about the custome. Futhemoe, the payment seve is not able to map any puchase to any custome identity. Since total anonymity imposes vey stict limitations and may even violate legislation, we will only conside patial anonymity. 3.3 Veification and Povability All paticipants, custome and mechants, must be able to pove that the goods sent (eceived) ae those both paties ageed upon in the initial negotiation phase (cetified delivey [25]). This equiement stems fom the fact that, in contast to taditional distibuted database tansactions whee only technical failues have to be addessed, also faudulent behavio of paticipants may aise in E Commece. Secondly, all paticipants have to be suppoted by appopiate mechanisms to veify the popeties of a payment potocol with espect to the peviously identified chaacteistics. Such a veification can eithe positively epot that a paticula potocol does not allow any of the paticipants to cheat, o, in the negative case, povides infomation about which paticipant may act faudulent (that is, violate one of the peviously mentioned equiements). In existing appoaches, veification is not pesent in this fom but is athe hidden in extensive potocol specifications. Aside of povability, veification is a main featue of ou appoach. 3.4 Cyptogaphic Secuity The tansfe of sensitive data, such as electonic cash o cedit cad numbes, equies cyptogaphic mechanisms and algoithms in ode to avoid thid paty attacks. Futhemoe, appopiate authentication mechanisms have to be povided. Since the Intenet is the medium connecting custome and mechants in E Commece, a tempoaily established faudulent stoe-font with a nice web inteface cannot be distinguished fom eliable mechants. Thus, each custome must be able to validate the identity of the mechants she inteacts with (e.g., by signing all messages that ae tansfeed [24]). While all peviously identified equiements ae inheently pat of ou pocess-based E Commece payment tansactions, cyptogaphic secuity is othogonally povided by the undelying infastuctue. 4 Tansactional Pocess Management In this section, we intoduce the concepts of tansactional pocess management which will be exploited fo the definition and the enactment of payment pocesses. 4.1 Pocess Model A pocess is a patially odeed collection of activities, which coespond to invocations of application sevices. These activities can be chaacteized in tems of thei temination guaantees: they ae eithe compensatable, etiable, o pivot [13, 28]. Compensatable activities can be semantically undone afte they have committed, pivot activities ae those which ae not compensatable (when no appopiate compensation is available o when compensation is too expensive and thus has to be avoided), and etiable activities ae the ones that ae guaanteed to successfully teminate. Futhemoe, the added stuctue of a tansactional pocess is eflected by diffeent odes: a pecedence ode specifies the egula execution of activities and a pefeence ode indicates altenative executions in case of failues [19]. Based on the diffeent temination popeties of activities and the pecedence and pefeence odes, it can be validated whethe a single pocesses is defined coectly. This is the case when only compensatable activities pecede the fist pivot activity and when an altenative execution is associated with each pivot consisting only of etiable activities [28]. Fo these pocesses, all possible failues can be handled by eithe undoing all activities (when only compensatable activities have committed) o by executing a safe altenative consisting only of etiable activities. Thus, they ae called pocesses with guaanteed temination. This inheent coectness popety of tansactional pocesses is a genealization of the all-o-nothing semantics of taditional

4 ACID tansactions since it ensues that one of eventually many valid executions (specified by altenatives) is effected. 4.2 Pocess Coodinato Each activity of a pocess coesponds to a sevice invocation in a subsystem. The main components of tansactional pocess management thus consist of a pocess coodinato contolling the pocess execution and seveal tansactional coodination agents (TCAs), one fo each subsystem [21], adding tansactional popeties to sevice invocations. Stating with the coect specification of single pocesses having guaanteed temination popety, the pocess coodinato s task is to enfoce the coect execution of tansactional pocesses even in the pesence of failues and concuency. The key aspects of the tansactional pocess coodinato can be biefly summaized as follows: it acts as a kind of tansaction schedule that is moe geneal than a taditional database schedule in that it i.) knows about semantic commutativity of activities, ii.) knows about the temination popeties of activities, and iii.) exploits the egula pecedence ode of pocesses when executing activities and knows about altenative executions paths in case of failues. 5 Tansactional Payment Pocesses The payment pocesses we conside ae extensions of anonymous atomic tansactions descibed in detail in [4]. They ely on electonic cash token as means of payment and ae pimaily designed fo the puchase of digital goods. These ae tansfeed pio to the payment in an encypted way. Due to this encyption, the mechandise is not utilizable until the key tansfe which is an integal pat of the payment pocess is effected successfully. Howeve, the puchase of taditional goods that ae shipped by egula mail is also possible. In this case, a legally binding digital contact is subject to the exchange (again, the contact is sent in an encypted way and the keys equied fo decyption ae tansfeed within the payment pocessing). 5.1 Stuctue of Tansactional Payment Pocesses The vaious inteactions that have to take place between all paticipants in (distibuted) E Commece payments ae combined within one single entity, a tansactional payment pocess. Each payment pocess is invoked by the custome at a cental payment coodinato, i.e. the pocess coodinato specialized to payments. The oveall stuctue of a tansactional payment pocess can be seen in Figue 1. The pecedence ode is depicted by solid acs; dotted acs ae used fo the pefeence ode. When a payment pocess is invoked, the custome fist has to specify the payment infomation P I she is willing to use within this E Commece payment tansaction (Receive Payment Infomation). The payment infomation can eithe be a cedit cad numbe o some ecash token. In the next step, the validity of this payment infomation is checked by invoking an appopiate sevice at the coesponding bank (Check Validity of Payment Infomation). This check is equied in ode to ensue that eithe the balance of the cedit cad account coves the amount of payment o, in the case of ecash token, that double spending is pevented. Afte positive validation, all mechants ae equested to send the keys needed to decypt the peviously encypted goods to the payment coodinato (Receive Key). When non-digital goods ae subject to a puchase (which ae in geneal available with a limited quality-on-hand), by tansfeing the key, the mechant guaantees the subsequent shipment afte the commit of the tansactional payment pocess. Afte all keys fom all mechants have been eceived, a timeoutcheck is pefomed (Check Timeout). This activity checks whethe all time fames of all mechants ae espected (they ae in geneal not willing to hold esevations on thei goods fo unlimited peiods). c Send Keys to Custome Money Tansfe (@Bank) Confimation to Mechants c Receive Payment Infomation c Check Validity of Payment Infomation (@Bank) Receive Key... c (fom Mechants) p p... Commit Check Timeout Abot Notify Custome Notify Bank... Notify Mechants Figue 1. Stuctue of a Payment Pocess If all constaints ae satisfied, the payment coodinato detemines the success of the payment tansaction. To this end, all keys ae sent to the custome (Send Keys to Custome). These keys ae equied to decypt the peviously deliveed encypted goods and make them usable fo the custome. Subsequently, a money tansfe activity is issued in the bank application in ode to cedit the mechant s accounts (Money Tansfe), and finally a confimation on the successful temination of the payment is sent to all mechants (Send Confimation to Mechant). If the timeout check fails, an abot of the payment pocess is issued. To this end, an altenative execution path is taken which encompasses notifications to all paticipants about the failue of the pocess. This altenative execution path has also to be

5 taken when the payment coodinato decides to commit the pocess but is not able to tansfe the keys to the custome. 5.2 Popeties of Tansactional Payment Pocesses Reasoning about the coectness of payment pocesses has to conside two diffeent aspects: fistly, each pocess itself has to be coect with espect to the guaanteed temination popety. Secondly, coectness also encompasses the compliance of all peviously discussed guaantees equied fo payments (Section 3) Guaanteed Temination of Payment Pocesses In ode to veify the inheent popety of guaanteed temination equied fo each tansactional payment pocess, the temination popeties of all activities have to be identified. Since the eception of the payment ode and the eception of the keys can be tivially undone by deleting these infomation, all these activities ae compensatable. Additionally, the validation of payment infomation can also be undone (e.g., by wiping out esevations on the ecash token used). The timeout check, howeve, whee the oveall outcome of the payment tansaction is detemined (eithe commit o abot) has to be teated as pivot which enfoces the pocess to teminate in fowad diection. All subsequent steps ae guaanteed to succeed (etiable) except fo the key tansfe to the custome which is pivot. The unavailability of the custome must also lead to an abot of the whole pocess by issuing the altenative execution labeled with abot. The temination popety of each activity (compensatable, pivot, etiable) is also depicted in Figue 1. Based on the pecedence and pefeence odes as well on the temination popeties of each activity, it can be shown that this tansactional payment pocess is coectly defined and thus povides guaanteed temination Compliance of Payment Pocess Requiements The inheent coectness of single pocesses has to be extended about the equiements imposed by E Commece payments. Theefoe, it has to be shown that the desied semantics of payment inteactions with espect to all equiements is povided in all coect teminations of pocesses. Atomicity The atomicity equiement jointly includes money tansfe, goods delivey, and distibuted puchase atomicity. It is pesent when all possible outcomes of a pocess guaantee that eithe money and goods ae tansfeed jointly fo all puchases that ae pat of a payment o that neithe money no goods ae exchanged fo any of them. Wheneve a failue occus pio to the timeout check, all pevious steps ae compensated and no infomation is tansfeed. Similaly, in the case of an abot, payment infomation is eleased and no keys ae tansfeed to the custome. In case of successful temination, the pocess stuctue guaantees that eal money flow is pefomed only in the case whee all keys have been sent to the custome. Theefoe, money tansfe is initiated jointly fo all puchases; the basic equiement of enfocing money atomicity must also be povided by all paticipating financial institutions (as it is the case in taditional payment inteactions). Goods tansfe atomicity is met by the combination of the tansfe of encypted goods and the key tansfe which is pefomed togethe with the money tansfe. Since the tansfe of keys and money is pefomed via the payment coodinato, no paty is able to cheat (which could be the case, fo instance, when the custome sends payment infomation to a malicious mechant who then efuses to ship the odeed goods). Instead of keys, the payment coodinato could also suppot the tansfe of the mechandise itself; howeve, this would not only incease the communication ovehead but would also decease the degee of anonymity (note that the mechandise is in geneal not known to the payment coodinato). Distibuted puchase atomicity, finally, is pesent fo two easons. Fistly, the sepaation of initial negotiation and subsequent payment pocessing povides the basis fo this kind of atomicity. When the initial step would aleady conside legally binding odes (these odes would have to be pefomed seially when seveal mechants ae consideed), then, when some mechandise would not be available, the all-o-nothing semantics of distibuted puchase atomicity would be violated. Secondly, the combination of key and money tansfe is enfoced fo each puchase of a distibuted payment within the payment pocess. Anonymity Since the identity of a custome (e.g., the IP addess of the host she is using) may not be evealed to the mechant by applying anonymizing techniques (e.g., [3]), anonymity is given at least in the patial fom. In ode to hide the identity of the custome to the bank when issuing electonic cash token, cyptogaphic blinding techniques [5] can be applied. Total anonymity of a custome against the payment coodinato is not possible since the latte one needs to contact the custome fo the key tansfe. Veification and Povability Due to the combination of all inteactions within one centally contolled pocess, its coectness can be veified by all paticipants. This would not be the case in an execution of a payment whee pats of the potocol ae distibuted among all paticipants (e.g., in agent-based appoaches). A basic peequisite is, howeve, that all paticipants tust in the eliability of this payment coodinato which is supposed to eside at the site of a cleaing house o cetification authoity, espectively.

6 Since the pocess coodinato stoes all pocess infomation pesistently, the paticipation of a custome in a tansaction and the sevice odeed in this tansactions can a posteioi be poven (this coesponds to cetified delivey descibed in [4]). Appaently, a conflict between anonymity and povability occus hee. Geneally speaking, thee is no eason fo the custome to povide eal identity infomation in a payment tansaction as long as it completes successfully. If the custome ejects the outcome of the tansaction, she has to give up he mask to pove he coect inteactions. Theefoe, anonymity can no longe be potected in case a payment tansaction fails. Cyptogaphic Secuity This aspect is not eflected in the payment pocess but is povided by the undelying pocess suppot infastuctue (i.e., the payment coodinato). Handling of System Failues Reliability does not only include the coect specification of payment pocesses but also encompasses high availability of the pocess coodinato. To this end, mechanisms have to be consideed to incease availability, e.g., by eplication techniques applied to pocess management systems [10]. System failues at the mechant s site, howeve, cannot be coveed. In these cases, the custome is only able to pove the mechant s paticipation in a distibuted E Commece tansaction and also based on the pesistent log managed by the payment coodinato to pove the mechant s violation of the initial ageement which allows he to take legal steps. 6 INVENT: A Pocess-Based Payment Coodinato In this section, we pesent the achitectue of ou pototype system, the INVENT payment coodinato and descibe the main components that ae needed fo the geneation and execution of tansactional payment pocesses. 6.1 Achitectue A feasible infastuctue fo pocess based E Commece payments must be able to integate abitay applications established by mechants and banks, espectively, and must also minimize the equiements imposed on customes to paticipate. The goal of the INVENT payment coodinato is to make existing banking applications o mechant stoe fonts available by small adaptes (coodination agents) and to povide a client side application to define and initiate distibuted E Commece tansactions. The main components of the whole payment system togethe with the inteactions between the vaious paticipants ae depicted in Figue 2. All pats belonging to the payment coodinato ae coloed in dak gey while the emaining components povided by the othe paticipants ae depicted in light gey. Custome Web Bowse (3) INVENT Shopping Assistant (1) (1 0 ) (2) (2 0 ) INVENT Payment Coodinato Web Seve (4) (8) (7) (7 0 ) f(oi c; M ) jg; P I (10) (10 0 ) Payment Pocess Geneato (5) WISE Pocess Engine Mechant Application Mechant App. TCA (6) (9) Mechant Bank TCA Bank Application Bank Figue 2. INVENT Payment System 6.2 Execution of Distibuted Payment Tansactions The execution of distibuted E Commece tansactions consists of two phases: the fist phase is based on bilateal negotiation between a custome and multiple mechants which ae offeing thei sevices, electonic goods, o digital contacts (in the case of non-digital goods) though thei electonic stoe fonts (steps 1 and 1 0 in Figue 2). In this initial phase, also encypted goods ae tansfeed (steps 2 and 2 0 ). Fo the geneation of cyptogaphic keys, abitay mechant applications can be exploited. A ealistic assumption is that these keys ae stoed in a database on the mechant s site. Afte the custome has eceived all encypted goods, she can decide which ones to encompass into one E Commece tansaction using a special client tool, the Shopping Assistant (step 3). The second phase is the actual payment coodinated by the INVENT payment coodinato. Fo this, the custome sends a desciption of the E Commece tansaction to the INVENT payment coodinato (step 4). Based on this infomation, a payment pocess is geneated by the Payment Pocess Geneato (PPG) which is then loaded into the Pocess Engine (step 5). This pocess follows the stuctue of a tansactional payment pocess as pesented in Section 5.1. All following steps (6 to 10 0 ) then coespond to the activities of this payment pocess executed by the coe pocess engine. 6.3 Payment Coodinato In what follows, we discuss all components of the payment coodinato, that is, the Shopping Assistant, the Payment Pocess Geneato, and the Pocess Engine in detail.

7 6.3.1 Shopping Assistant All payment infomation captued duing the initial negotiation phase is collected in the Shopping Assistant. The Assistant uns at the custome s site and is plugged into he web bowse. Data is exchanged by special MIME types that ae tailoed to the kind of infomation gatheed in the negotiation phase. Figue 3 shows a sceen shot of the Shopping Assistant duing a distibuted puchase encompassing two mechants. The Shopping Assistant also contains a wallet to manage electonic cash tokens and stoes afte eceipt the keys needed fo decyption. good to be encompassed in a payment tansaction as well as the payment infomation P I. The PPG then ceates a pocess desciption encompassing the appopiate numbe of Receive Key, Send Confimation, and Notify Mechant activities which can at un-time then be instantiated with the paametes (mechant addesses, ode infomation) given by the custome. Moeove, all activities inteacting with the bank have to be paameteized accoding to the payment infomation specified by the custome. Afte the geneation phase, the pocess desciption is sent to the pocess engine fo execution. The geneation, howeve, only affects the build-time of a payment pocess; once a payment pocess is instantiated, no dynamic stuctual changes (e.g., [18]) ae applied Pocess Engine Figue 3. INVENT Shopping Assistant In the taditional case whee a custome inteacts only with one mechant, she has to send all payment infomation diectly to this mechant who then issues a veification and a subsequent eal money tansfe. In the case of distibuted E Commece tansactions encompassing multiple mechants, the custome is esponsible to initiate the subsequent steps. This diffeence is, howeve, not of fundamental natue since the tansfe of infomation is pefomed by the Shopping Assistant and is hidden to the custome Payment Pocess Geneato (PPG) A cucial aspect in the execution of E Commece payment pocess is the geneation of payment pocesses which have to eflect the outcome of the initial negotiation phase (e.g., numbe and addesses of mechants, infomation about all goods, etc.). Since these pocesses have to be eliable, they have to be geneated by the payment coodinato, the only instance tusted by all paticipants. Each pocess has to contain the infomation gatheed by the custome duing the negotiation phase. Theefoe, she has to povide a typed epesentation of he E Commece tansaction which can then be tanslated into a pocess. The tansfomation task is handled by the Pocess Payment Geneato which is plugged into the pocess engine. The infomation that is sent to the PPG via the Shopping Assistant. It consists of the custome s view of the ode infomation OIc and a mechant infomation M fo each The execution of tansactional payment pocesses must povide cetain execution guaantees. Even in the pesence of failues and concuent access of pocesses to shaed esouces, coect pocess execution must be guaanteed. The fault-toleant execution is equied in ode to enfoce all inheent guaantees (atomicity, etc.) of single pocesses. But also concuency contol at pocess level has to be povided. Conside, fo instance, two mechants A and B offeing non-digital goods a and b, espectively, of limited availability and assume futhe that the quantity on hand (qoh) of both goods is 1. When two concuent distibuted E Commece tansactions ae executed by the payment coodinato and each of these tansactions aims in buying both a and b, then exactly one pocess should succeed while the othe one would have to fail. Howeve, when concuency contol would not be espected by the payment coodinato, one pocess may fist successfully issue a key equest fom mechant A (this key is equied to decypt the peviously shipped digital contact and goes along with a legally binding ageement of A to subsequently ship the equested good) while the othe pocess successfully pefoms a key equest fom B. In this case, both pocesses would wongly fail since at least one mechandise would not be available. These popeties ae povided by the WISE pocess engine (Wokflow based Intenet SEvices), a pocess suppot system which has been developed at ETH [2, 9]. This pocess engine implements appopiate potocols to suppot the coect paallel and fault-toleant execution of tansactional pocesses [19]. The integation of all extenal components is pefomed by so-called Tansactional Coodination Agents (TCAs) [21] acting as advanced wappes and allow the invocation of sevices in the mechant and bank applications. By exploiting cyptogaphic libaies [11] within the WISE system, communication between the pocess engine and all applications is made secue.

8 7 Conclusion This pape povides a detailed analysis of equiements paticipants impose in distibuted E Commece payments. Using the notion of tansactional pocesses, it has been shown that all payment inteactions can be embedded into a single payment pocess inheently poviding aside of povability and patial anonymity also all aspects of atomicity guaantees. With the payment coodinato implemented within the INVENT poject, we have pesented a system allowing a custome to i.) encompass diffeent independent inteactions with diffeent mechants into one single E Commece tansaction, ii.) dynamically geneate a pocess desciption eflecting the outcome of the initial negotiation with multiple mechants, and iii.) invoke this tansactional payment pocess at the payment coodinato which contols the execution and enfoces coect temination of the payment pocess. Futhemoe, when ochestating E Commece payment pocesses by a centalized payment coodinato, the monitoing of the state of a payment inteaction is facilitated compaed with the distibution and complexity found in cuent payment potocols. Based on this initial wok, we will extend and genealize the idea of dynamically geneating payment pocesses by allowing to use diffeent payment methods fo diffeent goods within one single pocess (e.g., payment by cedit cads, tansfe of account infomation, etc.). To this end, building blocks fo each payment method have to be identified. Additionally, since the usage of diffeent payment methods fo diffeent pats of a distibuted payment tansaction may have influences on the execution guaantees that can be povided, an additional component will be implemented that analyzes the degee of possible execution guaantees and pesents them to the custome pio to the instantiation of a payment pocess. Refeences [1] S. Abiteboul, B. Amann, S. Cluet, A. Eyal, L. Mignet, and T. Milo. Active Views fo Electonic Commece. In Poc. of the 25 th Int l Conf. on Vey Lage Databases (VLDB 99), pages , Edinbugh, Scotland, Sept [2] G. Alonso, U. Fiedle, C. Hagen, A. Lazcano, H. Schuldt, and N. Weile. WISE: Business to Business E-Commece. In Poc. of the 9 th Int l Wokshop on Reseach Issues in Data Engineeing (RIDE-VE 99), pages , Ma [3] Anonymize.com, [4] J. Camp, M. Hakavy, D. Tyga, and B. Yee. Anonymous Atomic Tansactions. In Poc. of the 2 nd Usenix Wokshop on Electonic Commece, pages , Nov [5] D. Chaum, A. Fiat, and M. Nao. Untaceable Electonic Cash. In Poc. of Advances in Cyptogaphy (CRYPTO 88), pages Spinge, [6] CybeCash, [7] ecash, [8] A. Geppet, M. Kadolfe, and D. Tombos. Maket-Based Wokflow Management. Int l Jounal on Coopeative Infomation Systems (IJCIS), 7(4): , Dec [9] C. Hagen. A Geneic Kenel fo Reliable Pocess Suppot. PhD thesis, ETH Züich, [10] C. Hagen and G. Alonso. Highly Available Pocess Suppot Systems: Implementing Backup Mechanisms. In Poc. of the 18 th Symposium on Reliable Distibuted Systems (SRDS 99), pages , Oct [11] IAIK. Cypto-Toolkit. Technical Univesity of Gaz, Austia. [12] L. Keschbeg and S. Banejee. An Agency-Based Famewok fo Electonic Business. In Poc. f the Int l Wokshop on Coopeative Infomation Agents, July [13] S. Mehota, R. Rastogi, A. Silbeschatz, and H. Koth. A Tansaction Model fo Multidatabase Systems. In Poc. of the 12 th Int l Conf. on Distibuted Computing Systems (ICDCS 92), pages 56 63, Yokohama, Japan, June [14] MilliCent, [15] P. Muth, J. Weissenfels, and G. Weikum. What Wokflow Technology can do fo Electonic Commece. In Poc. of the EURO-MED NET Confeence, Ma [16] C. Neumann and G. Medvinsky. Requiements fo Netwok Payment: The NetCheque T M Pespective. In Poc. of the 40 th IEEE Compute Society Int l Conf., pages 32 36, [17] M. Papazoglou. The Role of Agent Technology in Business to Business Electonic Commece. In Poc. CIA 99, [18] M. Reichet and P. Dadam. ADEPT flex Suppoting Dynamic Changes of Wokflows Without Losing Contol. Jounal of Intelligent Infomation Systems, 10(2):93 129, [19] H. Schuldt, G. Alonso, and H.-J. Schek. Concuency Contol and Recovey in Tansactional Pocess Management. In Poc. of the 18 th ACM Symposium on Pinciples of Database Systems (PODS 99), pages , [20] H. Schuldt, A. Popovici, and H.-J. Schek. Execution Guaantees in Electonic Commece Payments. In Poc. TDD 99, Spinge LNCS 1773, pages , Sept [21] H. Schuldt, H.-J. Schek, and G. Alonso. Tansactional Coodination Agents fo Composite Systems. In Poc. of the 3 d Int l Database Engineeing and Applications Symposium (IDEAS 99), pages , Aug [22] SET, [23] M. Stolpmann. Electonic Cash in the Intenet Basics, Concepts, Pespectives. O Reilly, In Geman. [24] L. Tang. Veifiable Tansaction Atomicity fo Electonic Payment Potocols. In Poc. of the 16 th Int l Conf. on Distibuted Computing Systems, pages , May [25] D. Tyga. Atomicity in Electonic Commece. In Poc. of the 15 th Annual ACM Symposium on Pinciples of Distibuted Computing, pages 8 26, May [26] D. Tyga. Atomicity vesus Anonymity: Distibuted Tansactions fo Electonic Commece. In Poc. of the 24 th Conf. on Vey Lage Databases (VLDB 98), Aug [27] X. Wang, X. Yi, K. Lam, C. Zhang, and E. Okamoto. Secue Agent-Mediated Auctionlike Negotiation Potocol fo Intenet Retail Commece. In Poc. CIA 99, July [28] A. Zhang, M. Nodine, B. Bhagava, and O. Bukhes. Ensuing Relaxed Atomicity fo Flexible Tansactions in Multidatabase Systems. In Poc. ACM SIGMOD, pages 67 78, May 1994.