A Formal and Executable Specification of the Internet Open Trading ...

A Formal and Executable Specification of the Internet Open Trading Protocol Chun Ouyang, Lars Michael Kristensen
, and Jonathan Billington Computer Systems Engineering Centre School of Electrical and Information Engineering University of South Australia, SA 5095, AUSTRALIA [email protected] {Lars.Kristensen,Jonathan.Billington}@unisa.edu.au

Abstract. The Internet Open Trading Protocol (IOTP) is being developed by the Internet Engineering Task Force for electronic commerce (e-commerce) over the Internet. The core of IOTP is a set of trading transactions that reflects the most common trading activities in the real world. We apply the formal method of Coloured Petri Nets (CP-nets) to construct an abstract executable specification of IOTP’s trading transaction protocols. The formal semantics of CP-nets allows us to investigate the termination properties of the transactions using state space techniques. This investigation has revealed deficiencies in the termination of IOTP trading transactions, demonstrating the benefit of applying formal methods to the specification and verification of e-commerce protocols.

1

Introduction

The Internet Open Trading Protocol (IOTP) [2] focuses on business-to-consumer trading transactions. A main design goal of IOTP is the encapsulation of different payment protocols such as the Secure Electronic Transaction (SET) protocol [19] and the Mondex Value Transfer Protocol (VTP) [9]. The development of IOTP is in an early stage with research groups and companies working on the first trial implementations of IOTP [5,17] based on the informal protocol specification given in RFC 2801 [2]. No complete implementation of IOTP currently exists, and there are still several open research issues concerning IOTP. One of these is to validate and verify the functional correctness of IOTP. Ensuring the correctness of complex e-commerce protocols is a challenging task, and informal methods are in most cases inadequate. Formal methods [4] have proven to be a powerful tool for investigating the correctness of communication protocols, including e-commerce protocols. The main advantage of using formal methods in protocol engineering is that they result in unambiguous protocol specifications amenable to computer-aided verification. Related work on applying formal methods to the modelling and analysis of e-commerce protocols and trading procedures can be found in [15,20,14,8]. None of them address the formal specification and analysis of IOTP.


Supported by the Danish Natural Science Research Council.

K. Bauknecht, A M. Tjoa, G. Quirchmayr (Eds.): EC-Web 2002, LNCS 2455, pp. 377–387, 2002. c Springer-Verlag Berlin Heidelberg 2002


378

C. Ouyang, L.M. Kristensen, and J. Billington

Coloured Petri Nets (CP-nets or CPNs) [6,7] are a formal method for the specification, design, simulation, and verification of concurrent systems. CP-nets are a graphically oriented modelling language capable of expressing concurrency, synchronization, non-determinism, and system concepts at different levels of abstraction. CP-nets are a combination of Petri Nets [16] and the functional programming language Standard ML (SML) [18]. Petri Nets are used to model concurrency, synchronization, and resource sharing, whereas SML is used for modelling data manipulation, and for creating compact and parameterisable models. CP-nets have previously been successfully applied for modelling and analysis of a wide range of communication protocols [1]. In this paper we apply CP-nets and the supporting Design/CPN computer tool [10] to construct an executable specification of the trading transactions that are the core of IOTP. The model is analysed for correctness. Our initial work [12] modelled and analysed just the IOTP Deposit transaction. In [11] we proposed a simplified protocol architecture for IOTP. The contribution of this paper is an improved modelling approach towards developing a formal protocol specification for IOTP, together with a detailed investigation of the termination properties of the trading transactions. Section 2 gives a brief introduction to IOTP using a purchase transaction as an example. Section 3 presents selected parts of the CPN model, and Sect. 4 presents the verification results. Finally, in Sect. 5 we summarize our contribution and discuss future work.

2

The Internet Open Trading Protocol

IOTP [2] defines five trading transactions 1 : Purchase, Refund , Deposit, Withdrawal , and Value Exchange, where the Value Exchange transaction supports the conversion of one currency to another. Below we use the Purchase transaction to illustrate the basic operation of IOTP. Purchase transaction. Figure 1 shows a possible sequence of messages exchanged between the parties involved in a Purchase transaction. Each column of the message sequence chart corresponds to one of the four2 IOTP trading roles: Consumer , Merchant, Payment Handler , and Delivery Handler . The Payment Handler (intuitively a bank) receives money from the Consumer on behalf of the Merchant and the Delivery Handler (intuitively a courier firm) delivers the goods to the Consumer on behalf of the Merchant. IOTP defines three trading phases: Offer , Payment, and Delivery, as shown in Fig. 1. The first phase is the Trading Protocol Options (TPO) Offer (events 1-4). The Consumer decides to buy goods, and sends an Offer Request for purchasing (event 1) to the Merchant. Upon receiving the Offer Request, the Merchant starts the transaction by offering the Consumer a list of TPO (event 2). This includes the available payment methods and associated payment protocols. The Consumer 1 2

These are referred to as Payment-related IOTP transactions in [2]. IOTP defines a fifth trading role called Merchant Customer Care Provider, but this trading role is currently not used in any transactions.

A Formal and Executable Specification Phase

Offer

Payment

Delivery

379

Event Consumer Merchant No. Offer Request (for Purchase) 1 Trading Protocol Options (TPO) 2 TPO Selection 3 Offer Response 4 Payment Handler Payment Request 5 Payment Protocol Data 6 Payment Response 7 Delivery Handler Delivery Request 8 Delivery Response 9 IOTP message exchanges

Outside the scope of Baseline IOTP

Fig. 1. A possible message flow in a Purchase transaction.

chooses one of the options, and sends it back as a TPO Selection (event 3). The Merchant uses the selection to create and send back an Offer Response (event 4), which contains details of the goods to be purchased together with payment and delivery instructions. The second phase concerns Payment (events 5-7). After checking the Offer Response, the Consumer sends the Payment Handler a Payment Request (event 5). The Payment Handler checks the Payment Request, and if valid, the payment is conducted using Payment Protocol Data exchanges (event 6) as determined by the encapsulated payment protocol (e.g., SET). The Payment Handler then sends a Payment Response (event 7) containing the payment result (e.g., a receipt). The third phase is Delivery (events 8-9). After checking the Payment Response, the Consumer sends the Delivery Handler a Delivery Request (event 8). The Delivery Handler schedules the delivery and sends the Consumer a Delivery Response (event 9) containing details of the delivery, and possibly the actual delivery if the goods are electronic (e.g., an e-journal). Trading exchanges and transactions. We call the three phases Offer, Payment, and Delivery trading exchanges 3 which may occur in different variants. For example, event 3 may or may not take place in an Offer exchange, which results in the distinction between a Brand Dependent Offer and a Brand Independent Offer . The Brand Dependent Offer occurs when the Merchant offers some additional benefit (e.g., price discount) in the Offer Response, depending on the specific payment brand chosen in the Consumer’s TPO Selection. In the Brand Independent Offer, the Offer Response is independent of the payment brand selected by the Consumer, and the Merchant can send a combined TPO and Offer Response message since the Consumer’s TPO Selection is not required. IOTP also supports an Authentication exchange allowing one trading role (the Authenticator ) to verify the bona fides of another trading role (the Authenticatee). All IOTP trading transactions can be expressed as combinations of these trading exchanges. A Purchase transaction consists of an optional Authentication, an Offer, a Payment, and optionally a Delivery. The Deposit, Withdrawal, and 3

This is defined according to the concept of document exchanges given in [2].

380

C. Ouyang, L.M. Kristensen, and J. Billington

Refund transactions start with an optional Authentication followed by an Offer and a Payment. Finally, a Value Exchange transaction starts with an optional Authentication followed by an Offer and two Payment exchanges in sequence.

3

IOTP Trading Transaction CPN Model

A CPN model has been constructed for each of the five IOTP trading transactions. All five CPN models have a similar structure and share a common set of modules. Due to space limitations, we focus on selected parts of the Purchase transaction CPN model, and only informally introduce the concepts of CP-nets [6,7]. The Purchase transaction involves all four trading roles and all types of trading exchanges, and is thus a representative example. Overview. The hierarchy page of Fig. 2 provides an overview of the pages (modules) constituting the CPN model. Each node in Fig. 2 represents a page labelled with its page name and page number . An arc between two page nodes indicates that the destination page is a subpage (submodule) of the source page. The Purchase page (top of Fig. 2) provides the most abstract view of a Purchase transaction and has five subpages. Four of these subpages: Consumer, Merchant, PHandler and DHandler correspond to the four trading roles involved in a Purchase transaction, and they specify the Purchase transaction protocol for each of the trading roles. We refer to these pages as trading role pages. The last subpage of Purchase is Transport (bottom of Fig. 2). It models the transport medium over which the trading roles communicate, e.g., HTTP. Each subpage of a trading role page specifies a trading exchange used by that trading role. As an example, the page Consumer has six subpages modelling the six different exchanges at the Consumer side. The subpage Authenticatee models an Authentication exchange where the Consumer acts as the Authenticatee. The subpages BrdDepOffer C and BrdIndepOffer C specify the Brand Dependent Offer and Brand Independent Offer for the Consumer. The subpages Payment C and Delivery C correspond to a Payment and a Delivery, respectively. The subpage PayDelivery C specifies a Payment with Delivery exchange that supports Purchase#1 Consumer

Merchant

Consumer#2

PHandler

Merchant#3

AuthExch

DHandler

PHandler#4

DHandler#5

AuthExch

Authenticatee#6

Authenticator#7

BrdDepOffer_C#8

BrdDepOffer_M#9

BrdIndepOffer_C#10

BrdIndepOffer_M#11

BDOExch

BDOExch

BIOExch

BIOExch

PayExch

PayExch

Payment_C#12

Payment_PH#13

PayDelivery_C#14

PayDelivery_PH#15

PDlvExch

PDlvExch

DlvExch

DlvExch

Delivery_C#16

Delivery_DH#17 Transport

Transport#18

Hierarchy# 10010

Declaration#19

Analysis#20

Fig. 2. The hierarchy page of the Purchase transaction CPN model.

A Formal and Executable Specification

381

combined payment and delivery. Since a trading exchange involves two trading roles, we have modelled each exchange as a pair of subpages - one for each trading role. For example, the subpages PayDelivery C and PayDelivery PH represent a Payment with Delivery exchange between the Consumer and Payment Handler. Transaction Level Modelling. The transaction level is specified by the four trading role pages. We illustrate our approach with the Consumer page, since the Consumer is the only trading role involved in all trading exchanges. The other three trading role pages Merchant, PHandler, and DHandler are similar to the Consumer page. Because of space limitations, we cannot present our exchange level models. Figure 3 depicts the page Consumer that models the Purchase transaction at the Consumer side. It is the subpage corresponding to the Consumer page node in Fig. 2. The ellipses in Fig. 3 are places, used to model message buffers and Consumer states. The places named Send and Receive model message buffers through which the Consumer sends and receives messages from the other trading roles. The two Send places conceptually represent the same place, but have been drawn as two to reduce the number of arc crossings. A similar remark applies to the two Receive places. The remaining six places are used to model the control flow and the internal state of the trading role entity. The state of a CPN model is determined by the distribution of tokens on the places of the CPN model. Each place has an associated colour set (type) that determines the kind (colour) of tokens that can reside on that place. A state of a CPN model is also called a idle

Start Status idle HS

idle

NoAuthentication

Authentication Exchange

(Merchant, m)

[m=[TPO] orelse m=[TPO, OfferResp]]

s

skipped completed

Authentication Status s HS

s HS

Brand Dependent Offer Exchange

Brand Independent Offer Exchange

s

s

Offer Status completed HS

completed

Payment with Delivery Exchange

HS

Payment Exchange

s

s

PayDelivery Status

Payment completed

Status

HS

Delivery Exchange s

Send TRxMsg

Receive TRxMsg

Delivery Status

Send TRxMsg

Fig. 3. Purchase transaction – Consumer trading role.

Receive TRxMsg

382

C. Ouyang, L.M. Kristensen, and J. Billington Table 1. Colour sets for modelling trading role states and IOTP messages.

1 2 3 4

color color color color

Status = with idle | completed | skipped | cancelled | stop; TradingRole = with Consumer | Merchant | PHandler | DHandler; ProcessState = with CompletedOk | Failed; TradingBlk = union AuthReq + AuthResp + AuthStatus: ProcessState + TPO + TPOSelection + OfferResp + PayReq + PayExch + PayResp + DelivReq + DelivResp + Cancel; 5 color IotpMsg = list TradingBlk; 6 color TRxMsg = product TradingRole ∗ IotpMsg;

marking. The colour set of a place is by convention written below a place. Table 1 lists the definition of the colour sets used in Fig. 3. The colour set Status is an enumeration type containing five values. The value idle is used for modelling the state where the trading role is idle, skipped when the transaction skips an optional trading exchange, completed when a trading exchange is completed, cancelled when the transaction is cancelled, and stop when the transaction has terminated. TradingRole is also an enumeration type with a value for each trading role, and IotpMsg models the set of IOTP messages exchanged between trading roles. The declarations are written in Standard ML [18] and derived from [2]. The rectangles in Fig. 3 are transitions, used to model the actions of the Consumer. Transitions with an HS-tag in the upper left corner are substitution transitions. A substitution transition represents a compound action, and has an associated subpage which models the compound action in detail. The Consumer page has six substitution transitions corresponding to the six trading exchanges of a Purchase transaction. As an example, the substitution transition Authentication Exchange (upper left) abstractly represents the Authentication exchange at the Consumer side. The details of Authentication are modelled in the subpage Authenticatee (see Fig. 2) which is the subpage associated with the Authentication Exchange substitution transition. The other five substitution transitions abstractly represent the corresponding trading exchanges at the Consumer side in a similar way. The execution of a CPN model consists of occurrences of enabled ordinary (i.e., non-substitution) transitions removing tokens from places connected to incoming arcs, and adding tokens to places connected to outgoing arcs. The tokens required on input places for a transition to be enabled are specified by arc expressions associated with input arcs of the transition. When an enabled transition occurs, the tokens required for the transition to be enabled are removed from input places, and tokens are added to output places according to the arc expressions on the output arcs of the transition. Page Consumer has one ordinary transition: NoAuthentication. In the initial state of the Consumer (i.e., before execution of the transaction starts) place Start contains the token idle. This is specified by the inscription to the upper right of the Start place. The other places initially contain no tokens. When the transaction starts a token will become available on place Receive indicating an incoming message. If this token has the form (Merchant, m) (indicating a message from the Merchant) and m is either a Trading Protocol Options (TPO) or a combined TPO and Offer Response message, the transition NoAuthentication will be enabled. The requirement on m is expressed by the boolean guard expression in square brack-

A Formal and Executable Specification

383

ets positioned next to the NoAuthentication transition. The occurrence of this transition will remove the idle token from place Start, and add a skipped token to place Authentication modelling that the Purchase transaction starts without an Authentication exchange. If m does not satisfy the above requirement, then transitions on the subpage of Authentication Exchange will be enabled, and their occurrences will correspond to the execution of an Authentication exchange. The output arc of the substitution transition Authentication Exchange is annotated by the variable s of type Status. If the Authentication is successful, a completed token will be bound to s and put into place Authentication. Otherwise a cancelled token will be bound to s and put into place Authentication modelling that the transaction is cancelled. The output arcs from place Start to Authentication Exchange and NoAuthentication therefore model the choice of whether or not an Authentication exchange occurs at the beginning of the transaction. A skipped or a completed token on place Authentication signals that the Offer phase can commence. Here there is a choice between a Brand Dependent Offer and a Brand Independent Offer. Depending on whether the Offer exchange is successful or has been cancelled, a completed or a cancelled token will be put into place Offer. Similarly, there is also a choice between a Payment exchange and a Payment with Delivery exchange. In the course of executing the transaction, tokens will be added and removed from the places Send and Receive, according to the messages being sent and received by the Consumer.

4

Transaction Termination Properties

In this section we apply the state space technique of CP-nets to investigate and formally reason about the termination properties of the Purchase transaction. In state space analysis we compute all reachable states and state changes of the CPN model, and represent these as a directed graph (called a state space). Nodes in the state space represent states (markings), and arcs represent occurrences of transitions. This is essentially model checking [3] of finite-state systems, with the exception that in the Design/CPN tool, query functions written in ML are used for investigating properties of the system instead of temporal logic formulae. The full state space of the Purchase transaction CPN model has 116 nodes and 136 arcs, and is generated automatically in less than five seconds on a standard PC. Inspection of Terminal States. The first step is to determine the possible states in which the Purchase transaction may terminate. A dead marking of a CPN model is a marking (state) with no enabled transitions. The set of dead markings therefore represents the terminal states of a Purchase transaction. The CPN model of the Purchase transaction has 12 dead markings. Table 2 lists the corresponding states of each trading role in the 12 dead markings. For each dead marking, the state of each trading role (i.e., idle, wait, cancel, and stop) was obtained from the tokens present on the places modelling the internal states of the trading role. The subscript of a state specifies the trading exchange in question, e.g., Authentication (A), Offer (O), Payment (P), Delivery (D), and

384

C. Ouyang, L.M. Kristensen, and J. Billington Table 2. Trading role states in the dead markings. Dead marking 106 107 115 23 35 70 76 101 104 72 74 116

Consumer stopP stopPD stopD cancelledA cancelledO cancelledP cancelledPD waitP waitPD cancelledP cancelledPD cancelledD

Trading role Merchant Payment Handler stopO stopP stopO stopPD stopO stopP cancelledA idle cancelledO idle stopO cancelledPD stopO cancelledP stopO stopvP D stopO stopP stopO cancelledP stopO cancelledPD stopO stopP

Delivery Handler idle idle stopD idle idle idle idle idle idle idle idle cancelledD

Payment with Delivery (PD). The state wait is used where the trading role is waiting to receive a message within a trading exchange. No subscript is used for idle as it represents the idle state of a trading role before execution of the transaction starts. In the following, marking n is written as Mn . M106 , M107 and M115 represent the three possible successful terminations of a Purchase transaction. In M106 and M107 , the Purchase transaction is completed at the end of a Payment or a Payment with Delivery exchange, respectively. The Delivery Handler is therefore never active and is in state idle at the end of the transaction. In M115 , the Purchase transaction is completed with a Delivery exchange after the Payment, and all trading roles terminate in state stop. M23 and M35 are expected and correspond to the transaction being cancelled during an Authentication or an Offer exchange between the Consumer and the Merchant. Problem 1: Lack of Synchronization between Consumer and Payment Handler. The 4 undesired terminal states, represented by M70 , M76 , M101 , and M104 , show that the Consumer and the Payment Handler execute different trading exchanges, when they should be executing the same exchange. For example, the path in the state space leading to M70 reveals that the Consumer is executing a Payment exchange, while the Payment Handler is executing a Payment with Delivery exchange. Similar lack of synchronization is revealed by the paths leading to M76 , M101 and M104 . M101 and M104 also reveal an unspecified reception, where the Consumer is still in state wait since it cannot process the message sent from the Payment Handler that is executing a different exchange. The reason for this lack of synchronization is that IOTP does not specify how the Payment Handler is notified about which of the trading exchanges (a Payment or a Payment with Delivery) is to be executed. According to [2], a Payment or Payment with Delivery exchange is initiated by the Consumer sending a Payment Request message to the Payment Handler. This message however does not specify whether a Payment or a Payment with Delivery is to take place. Upon receiving such a message, the Payment Handler thus cannot tell whether a Payment or a Payment with Delivery is initiated by the Consumer. The result is the lack of synchronization in IOTP when executing either a Payment or a Payment with Delivery exchange between Consumer and Payment Handler.

A Formal and Executable Specification

385

One solution to this problem is to define a message that would be sent from the Merchant to notify the Payment Handler which exchange is to occur. This requires server-to-server communication, which is beyond the scope of the current version of IOTP (version 1.0) [2]. Another solution is to add a Delivery Component into the Payment Request message sent from the Consumer to the Payment Handler. The Delivery component is defined [2] in the Offer Response message. It contains the information about the delivery to be made, and has an attribute named DelivAndPayResp indicating whether or not a Payment with Delivery exchange is to occur. This solution is within the scope of IOTP version 1.0, and we have modified the original CPN model to reflect this solution. The full state space of the modified CPN model has 88 nodes and 104 arcs. In this CPN model the 4 undesired terminal states are not present, and only the other 8 dead markings remain. Hence this lack of synchronization no longer occurs. We can also show that the Purchase transaction will eventually terminate in one of these 8 dead markings, demonstrating the absence of livelock. Problem 2: Inconsistent Terminal States. The transaction can also be cancelled during a Payment or a Payment with Delivery exchange, as indicated by M72 and M74 , respectively. M116 represents the state where the transaction is cancelled during a Delivery exchange. These three dead markings exhibit deficiencies related to cancellation of a Purchase transaction. As indicated by M72 and M74 , the Merchant is not informed when a cancellation occurs between the Consumer and the Payment Handler during a Payment or a Payment with Delivery exchange (the Merchant is still in the stop state). In this case, the Merchant may purchase goods from the manufacturer but unexpectedly cannot sell these goods to the Consumer, resulting in an inventory problem. Similarly in M116 , neither the Merchant nor the Payment Handler is notified of a cancellation between the Consumer and the Delivery Handler during a Delivery exchange. In this case, the Consumer will not receive the goods that have been paid for, and may not be able to receive a refund. A possible solution is to inform the Merchant and Payment Handler about the final outcome of the transaction, i.e., whether the transaction is successfully completed or has been cancelled. We plan to model and analyse this solution in the future.

5

Conclusions

We have presented a hierarchical CPN model of the IOTP trading transactions based on RFC 2801 [2]. The analysis has revealed deficiencies in the Purchase transaction procedure in terms of 1) lack of synchronization of a Payment exchange and a Payment with Delivery exchange by Consumer and Payment Handler, and 2) inconsistent states of the trading roles upon termination in the case of cancellation. The former problem is specific to a Purchase transaction, whereas the second problem is also present in other IOTP trading transactions. In the former case we have proposed a solution, modified the CPN model accordingly and proved it to be correct. This demonstrates that the CPN model can be used to effectively evaluate modifications to IOTP transactions.

386

C. Ouyang, L.M. Kristensen, and J. Billington

In the current model of IOTP trading transactions, we have made some simplifying assumptions, which are primarily related to IOTP error handling. For example, we have only investigated the situation where all IOTP messages are well-formed. Besides error handling, arbitrary cancellation during a transaction has not yet been taken into consideration. As part of future work we plan to include error handling and arbitrary cancellation into our CPN model. IOTP requires improvement due to the identified deficiencies related to cancellation (Problem 2). Investigating additional properties such as atomicity, fairness, and non-repudiation of IOTP transactions is also part of future work. In parallel with the development of the protocol specification presented in this paper, we have also proposed a formal service specification for IOTP using CP-nets [13]. A challenging part of future work is to investigate whether the CPN protocol specification of IOTP presented in this paper formally conforms to, i.e., is a faithful refinement of, the CPN service specification for IOTP.

References 1. J. Billington, M. Diaz, and G. Rozenberg, editors. Application of Petri Nets to Communication Networks: Advances in Petri Nets, Volume 1605, Lecture Notes in Computer Science, Springer-Verlag, Berlin, 1999. 2. D. Burdett. Internet Open Trading Protocol IOTP Version 1.0. IETF Trade Working Group, April 2000. Available via: http://www.ietf.org/rfc/rfc2801.txt. 3. E. Clarke, O. Grumberg, and D. Peled. Model Checking. The MIT Press, 1999. 4. E. M. Clarke and J.M Wing. Formal Methods: State of the Art and Future Directions. ACM Computing Surveys, 28(4):626–643, December 1996. 5. JOTP Open Trading Protocol Toolkit For Java. URL: http://www.livebiz.com/. 6. K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Vol 1-3. Monographs in Theoretical Computer Science. Springer-Verlag, 1997. 7. L.M. Kristensen, S. Christensen, and K. Jensen. The Practitioner’s Guide to Coloured Petri Nets. International Journal on Software Tools for Technology Transfer, 2(2):98–132, 1998. Springer-Verlag. 8. R.M. Lee. Documentary Petri Nets: A Modelling Representation for Electronic Trade Procedure. In Business Process Management, Volume 1806, Lecture Notes in Computer Science, pages 259–375. Springer-Verlag, 2000. 9. Mondex. URL: http://www.mondexusa.com/html/content/technolo/technolo.htm. 10. Design/CPN Online. URL: http://www.daimi.au.dk/designCPN/. 11. C. Ouyang, L.M. Kristensen, and J. Billington. An Improved Architectural Specification of the Internet Open Trading Protocol. In Proceedings of 3rd Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools (CPN’01), pages 119–137. DAIMI PB-554, University of Aarhus, ISSN 0105-8517, 2001. 12. C. Ouyang, L.M. Kristensen, and J. Billington. Towards Modelling and Analysis of the Internet Open Trading Protocol Transactions using Coloured Petri Nets. In Proc of 11th Annual International Symposium of the International Council on System Engineering (INCOSE), 2001. CD-ROM 6.7.3.

A Formal and Executable Specification

387

13. C. Ouyang, L.M. Kristensen, and J. Billington. A Formal Service Specification of the Internet Open Trading Protocol. In Proceedings of 23rd International Conference on Application and Theory of Petri Nets, Volume 2360, Lecture Notes in Computer Science, Springer-Verlag, 2002. To appear. 14. M. Papa, O. Bremer, J. Hale, and S. Shenoi. Formal Analysis of E-commerce Protocols. In Proceedings of 5th. International Symposium on Autonomous Decentralized Systems, pages 19–28. IEEE Computer Society, 2001. 15. I. Ray and I. Ray. Failure Analysis of an E-commerce Protocol using Model Checking. In Proceedings of 2nd International Workshop on Advanced Issues of ECommerce and Web-Based Information Systems, pages 176–183. IEEE Computer Society, 2000. 16. W. Reisig and G. Rozenberg, editors. Lectures on Petri Nets: Advances in Petri Nets. Volume I: Basic Models, Volume 1491, Lecture Notes in Computer Science, Springer-Verlag, Berlin, 1998. 17. Hitachi SMILEs. URL: http://www.hitachi.co.jp/Div/nfs/whats new/smiles.html. 18. J. D. Ullman. Elements of ML Programming. Prentice-Hall, 1998. 19. Visa and MasterCard. SET Secure Electronic Transaction Specification. Version 1.0. Vol 1-3, May 1997. URL: http://www.setco.org/set specifications.html. 20. P. Yolum and M. P. Singh. Commitment-based enhancement of e-commerce protocols. In Proceedings of IEEE 9th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, pages 278–283, 2000.