[PayReq]
[PayExch]
[Cancel]
Consumer Payment Handler
[PayExch]
[Cancel]
[PayReq]
Consumer Payment Handler
[Cancel]
Fig.14: TheMSC forcancelledPayment exchanges.
state space report for the Purchase transaction model has been generated. The statistical
informationshows that thestate space (OCC)has244 nodesand 490 arcs.
Table1showsthehomeandthelivenesspropertiesandhasbeenextractedfromthestate
space report. There are ve dead markings representing the terminal states of a Purchase
transaction.Table2liststhecorresponding statesofeach tradingroleintheve dead
mark-ings. Marking 164 and 243 represent the two possible successful executions of a Purchase
transaction. Inmarking164, thePurchase transactionis completedat theendofa Payment
oraPaymentwithDelivery exchangebetweentheConsumerand thePaymentHandler.The
Inmarking243,the purchase iscompletedwitha Delivery exchange afterthepayment. The
cancelledPurchasetransactions are representedbythe other three deadmarkings. Marking
57 correspondsto the state inwhich thetransaction is cancelledduring the Authentication
exchange or one of the two Oer exchanges betweenthe Consumer and the Merchant. The
transaction can also be cancelledduring thePayment exchangeor the Payment with
Deliv-ery exchange, asindicated by marking 126. Finally,marking 244 represents the state where
thetransaction iscancelledduringthe Deliveryexchange. Carefullinspectionof Table2 also
shows thatthe stateswhichthe tradingroles areinupon terminationof thetransaction are
consistent. Therefore, investigating all the dead markings shows that the Purchase
transac-tion terminates properly. The set of dead markings also constitutes a home space, i.e. it is
always possible during the execution of the Purchase transaction to reach one of the dead
markings.Thishasbeenchecked usingthequeryfunctionsHomeSpaceandListDeadMarkings
of thestate space tool.
Table 1:Home andlivenessproperties.
HomeMarkings None
DeadMarkings [57,126,164,243,2 44 ]
DeadTransitionsInstances None
LiveTransitions Instances None
Table 2:Tradingrole states inthedeadmarkings.
Tradingrole Deadmarking
[57] [126] [164] [243] [244]
Consumer 1`cancel 1`cancel 1`stop 1`stop 1`cancel
Merchant 1`cancel 1`stop 1`stop 1`stop 1`stop
PaymentHandler 1`ready 1`cancel 1`stop 1`stop 1`stop
DeliveryHandler 1`ready 1`ready 1`ready 1`stop 1`cancel
Table 3 listsupperand lower integer boundsof theplaces modellingthemessage buers
(see Fig. 3). The boundedness results show that the minimal number of messages in each
of thebuers is zero, which corresponds to the terminal states of the Purchase transaction.
The maximum number of messages is 1 except that both the Consumer receiving buer
(ConRecMsg ) and the Merchant sending buer(MerSendMsg ) maycontain 2 at a time. The
corresponding markings can be identiedusingthePredAllNodesquery functionof thestate
space tool, and an execution of the transaction leading to such marking can be found using
the NodesInPath function. To understand why these two buers may contain two messages
at the same time considerthe MSC inFig. 12. The events 3 and 4 show that theMerchant
sends theTPO message ([TPO]) directly after the successful Authentication status message
([AuthStatus(ComletedOk)]) with no conrmation message from the Consumer in between.
The Consumer mayreceive thesecond message beforeprocessing therst one. Inspectionof
the multi-set bounds in the state space report shows that the trading roles do enter their
expected states during thetransaction, and that the messages exchanged between them are
as expected.
Place Upper Lower Place Upper Lower
ConRecMsg 2 0 MerRecMsg 1 0
ConSendMsg 1 0 MerSendMsg 2 0
DHRecMsg 1 0 PHRecMsg 1 0
DHSendMsg 1 0 PHSendMsg 1 0
7 IOTP Protocol Architecture
The RFC for IOTP does not contain a precise and detailed specication of the protocol
architectureand theinternal organisation ofthe individuallayers.In thissectionwe present
our initial proposal fora protocol architecture of IOTP.The proposedprotocol architecture
is derivedfrom theconstructedCPN modelsof thetradingtransactions.
IOTP is clearly an application protocol in the context of the OSI reference model [2]
possiblyoperatingacrossdierent transportprotocolservicesfortransmissionofIOTP
mes-sages. Thisisalso evidentfrom theprimepageof theCPNmodel showninFig.3.Fromthe
hierarchy page of the CPN model shown in Fig. 2, IOTPitself can be seen as consisting of
two layers: a transaction layer and a exchange layer, where the transaction layer uses the
services provided bythe exchange layerto implement thetradingtransactions.
IOTP protocol entities are not designed to work solely as stand alone applications. An
IOTPprotocol entitywilltypicallybe embeddedinother applicationssuchasHTTP clients
and HTTP servers when, e.g., the Consumer tradingrole entity is implementedin a HTTP
web browser and the Merchant trading role entity is implemented in a HTTP web server
for trading across the Internet. Moreover, IOTP will in mostcases operate across the same
transport service as the application it is part of. This transport service will typically vary
dependingon theapplication and theunderlyingcommunicationmedium. Thissuggests the
existence of a transport adaption layer.This layer makes it possibleto adapt the transport
service ofthe specicapplication to theservice requiredby IOTP.
Figure15 shows theproposedprotocol architectureofIOTPwith thefourmainprotocol
layersasidentiedabove.Inthefollowingwediscusstheserviceprovidedbyindividuallayers
as wellastheirinternalorganisation inmore detail.
Transactions Layer. Thislayerimplements theIOTP tradingand infrastructure
transac-tions. For baselineIOTP thislayer implementsDeposit, Withdrawal, Purchase, Refund,
Value Exchange,Inquiry,and Ping transactions.
Exchange Layer. ThislayerimplementstheIOTPexchanges.ForbaselineIOTPthislayer
implementsAuthentication,BrandDependentOer,BrandIndependent Oer,Payment,
Delivery, and Payment with Delivery exchanges. The CPN model presented in this
pa-per species in detail how the individual trading transactions can be implemented as
combinations ofthese exchanges.
Payment Sublayer. IOTPcansupportdierentpaymentinstruments(suchasVISA,
Mas-terCard,and Mondex Card)byencapsulatingtheunderlyingpayment protocols(suchas
been dened as a sublayer embedded in the exchange layer since the payment scheme
component denedinIOTPwillbeusedtoencapsulatethepaymentprotocoldata,e.g.,a
SETmessage,duringaPaymentexchange. Onecomponentofthepaymentsublayeristhe
so-calledIOTPpaymentbridgesspeciedintheInternetDraftforIOTPPaymentAPI[6].
ThesepaymentbridgesspecifytheinterfaceandinteractionbetweenIOTPexchangesand
thepayment system.
Application Transport Adaption Layer. This layer interfaces IOTP to the underlying
transport layer and transport service. This layer will ensure that the IOTP messages,
which arewell-formedXML documents,are carriedsuccessfully betweenthetrading role
entities. Typically, the application transport adaptation layer includes the mechanisms
which support themapping of theIOTP data format to the underlyingtransport layer,
e.g.,an XML to HTTP mapping.
Application Transport Layer. This is the basic transport service on top of which the
IOTP entities are operating. This layer could be TCP/IP as well as other higher level
transportprotocols such asHTTPand SMTP.It mightalso bethe WirelessApplication
Protocol (WAP) [5] transport service if IOTP is used in wireless e-commerce such as
mobile commerce (m-commerce) applications. This layer can also provide session layer
services such asthose providedbySecureSocketLayer (SSL)forencryption.