Network Working Group D. Burdett Request for Comments: 2801 Commerce One Category: Informational April 2000 Internet Open Trading Protocol - IOTP Version 1.0 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure Channel Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. Table of Contents 1. Background .....................................................7 1.1 Commerce on the Internet, a Different Model .................7 1.2 Benefits of IOTP ............................................9 1.3 Baseline IOTP ..............................................10 1.4 Objectives of Document .....................................10 1.5 Scope of Document ..........................................11 1.6 Document Structure .........................................11 1.7 Intended Readership ........................................13 1.7.1 Reading Guidelines ...................................13 2. Introduction ..................................................14 2.1 Trading Roles ..............................................16 2.2 Trading Exchanges ..........................................18 2.2.1 Offer Exchange .......................................19 2.2.2 Payment Exchange .....................................21 2.2.3 Delivery Exchange ....................................24 2.2.4 Authentication Exchange ..............................26 2.3 Scope of Baseline IOTP .....................................28 Burdett Informational [Page 1] RFC 2801 IOTP/1.0 April 2000 3. Protocol Structure ............................................31 3.1 Overview ...................................................32 3.1.1 IOTP Message Structure ...............................32 3.1.2 IOTP Transactions ....................................34 3.2 IOTP Message ...............................................35 3.2.1 XML Document Prolog ..................................37 3.3 Transaction Reference Block ................................37 3.3.1 Transaction Id Component .............................38 3.3.2 Message Id Component .................................39 3.3.3 Related To Component .................................41 3.4 ID Attributes ..............................................42 3.4.1 IOTP Message ID Attribute Definition .................43 3.4.2 Block and Component ID Attribute Definitions .........44 3.4.3 Example of use of ID Attributes ......................46 3.5 Element References .........................................46 3.6 Extending IOTP .............................................48 3.6.1 Extra XML Elements ...................................49 3.6.2 Opaque Embedded Data .................................50 3.7 Packaged Content Element ...................................50 3.7.1 Packaging HTML .......................................52 3.7.2 Packaging XML ........................................53 3.8 Identifying Languages ......................................54 3.9 Secure and Insecure Net Locations ..........................54 3.10 Cancelled Transactions .....................................55 3.10.1 Cancelling Transactions ..............................55 3.10.2 Handling Cancelled Transactions ......................56 4. IOTP Error Handling ...........................................56 4.1 Technical Errors ...........................................57 4.2 Business Errors ............................................57 4.3 Error Depth ................................................58 4.3.1 Transport Level ......................................58 4.3.2 Message Level ........................................58 4.3.3 Block Level ..........................................59 4.4 Idempotency, Processing Sequence, and Message Flow .........61 4.5 Server Role Processing Sequence ............................62 4.5.1 Initiating Transactions ..............................62 4.5.2 Processing Input Messages ............................63 4.5.3 Cancelling a Transaction .............................70 4.5.4 Retransmitting Messages ..............................70 4.6 Client Role Processing Sequence ............................71 4.6.1 Initiating Transactions ..............................71 4.6.2 Processing Input Messages ............................72 4.6.3 Cancelling a Transaction .............................74 4.6.4 Retransmitting Messages ..............................74 5. Security Considerations .......................................74 5.1 Determining whether to use digital signatures ..............74 5.2 Symmetric and Asymmetric Cryptography ......................76 5.3 Data Privacy ...............................................77 Burdett Informational [Page 2] RFC 2801 IOTP/1.0 April 2000 5.4 Payment Protocol Security ..................................77 6. Digital Signatures and IOTP ...................................77 6.1 How IOTP uses Digital Signatures ...........................77 6.1.1 IOTP Signature Example ...............................80 6.1.2 OriginatorInfo and RecipientInfo Elements ............82 6.1.3 Using signatures to Prove Actions Complete Successfully .........................................83 6.2 Checking a Signature is Correctly Calculated ...............84 6.3 Checking a Payment or Delivery can occur ...................85 6.3.1 Check Request Block sent Correct Organisation ........86 6.3.2 Check Correct Components present in Request Block ....91 6.3.3 Check an Action is Authorised ........................91 7. Trading Components ............................................93 7.1 Protocol Options Component .................................96 7.2 Authentication Request Component ...........................97 7.3 Authentication Response Component ..........................98 7.4 Trading Role Information Request Component .................99 7.5 Order Component ...........................................100 7.5.1 Order Description Content ...........................101 7.5.2 OkFrom and OkTo Timestamps ..........................101 7.6 Organisation Component ....................................102 7.6.1 Organisation IDs ....................................104 7.6.2 Trading Role Element ................................105 7.6.3 Contact Information Element .........................108 7.6.4 Person Name Element .................................109 7.6.5 Postal Address Element ..............................110 7.7 Brand List Component ......................................111 7.7.1 Brand Element .......................................113 7.7.2 Protocol Brand Element ..............................115 7.7.3 Protocol Amount Element .............................116 7.7.4 Currency Amount Element .............................117 7.7.5 Pay Protocol Element ................................118 7.8 Brand Selection Component .................................120 7.8.1 Brand Selection Brand Info Element ..................122 7.8.2 Brand Selection Protocol Amount Info Element ........122 7.8.3 Brand Selection Currency Amount Info Element ........123 7.9 Payment Component .........................................123 7.10 Payment Scheme Component ..................................125 7.11 Payment Receipt Component .................................126 7.12 Payment Note Component ....................................128 7.13 Delivery Component ........................................129 7.13.1 Delivery Data Element ...............................130 7.14 Consumer Delivery Data Component ..........................132 7.15 Delivery Note Component ...................................133 7.16 Status Component ..........................................134 7.16.1 Offer Completion Codes ..............................137 7.16.2 Payment Completion Codes ............................138 7.16.3 Delivery Completion Codes ...........................140 Burdett Informational [Page 3] RFC 2801 IOTP/1.0 April 2000 7.16.4 Authentication Completion Codes .....................142 7.16.5 Undefined Completion Codes ..........................144 7.16.6 Transaction Inquiry Completion Codes ................144 7.17 Trading Role Data Component ...............................144 7.17.1 Who Receives a Trading Role Data Component ..........145 7.18 Inquiry Type Component ....................................146 7.19 Signature Component .......................................147 7.19.1 IOTP usage of signature elements and attributes .....148 7.19.2 Offer Response Signature Component ..................150 7.19.3 Payment Receipt Signature Component .................151 7.19.4 Delivery Response Signature Component ...............152 7.19.5 Authentication Request Signature Component ..........152 7.19.6 Authentication Response Signature Component .........153 7.19.7 Inquiry Request Signature Component .................153 7.19.8 Inquiry Response Signature Component ................153 7.19.9 Ping Request Signature Component ....................153 7.19.10 Ping Response Signature Component...................154 7.20 Certificate Component .....................................154 7.20.1 IOTP usage of signature elements and attributes .....154 7.21 Error Component ...........................................154 7.21.1 Error Processing Guidelines .........................157 7.21.2 Error Codes .........................................158 7.21.3 Error Location Element ..............................162 8. Trading Blocks ...............................................163 8.1 Trading Protocol Options Block ............................166 8.2 TPO Selection Block .......................................167 8.3 Offer Response Block ......................................168 8.4 Authentication Request Block ..............................169 8.5 Authentication Response Block .............................170 8.6 Authentication Status Block ...............................171 8.7 Payment Request Block .....................................171 8.8 Payment Exchange Block ....................................173 8.9 Payment Response Block ....................................173 8.10 Delivery Request Block ....................................175 8.11 Delivery Response Block ...................................176 8.12 Inquiry Request Trading Block .............................177 8.13 Inquiry Response Trading Block ............................177 8.14 Ping Request Block ........................................179 8.15 Ping Response Block .......................................179 8.16 Signature Block ...........................................181 8.16.1 Signature Block with Offer Response .................182 8.16.2 Signature Block with Payment Request ................182 8.16.3 Signature Block with Payment Response ...............182 8.16.4 Signature Block with Delivery Request ...............182 8.16.5 Signature Block with Delivery Response ..............182 8.17 Error Block ...............................................183 8.18 Cancel Block ..............................................184 9. Internet Open Trading Protocol Transactions ..................184 Burdett Informational [Page 4] RFC 2801 IOTP/1.0 April 2000 9.1 Authentication and Payment Related IOTP Transactions ......185 9.1.1 Authentication Document Exchange ....................188 9.1.2 Offer Document Exchange .............................194 9.1.3 Payment Document Exchange ...........................203 9.1.4 Delivery Document Exchange ..........................209 9.1.5 Payment and Delivery Document Exchange ..............212 9.1.6 Baseline Authentication IOTP Transaction ............216 9.1.7 Baseline Deposit IOTP Transaction ...................218 9.1.8 Baseline Purchase IOTP Transaction ..................220 9.1.9 Baseline Refund IOTP Transaction ....................222 9.1.10 Baseline Withdrawal IOTP Transaction ................224 9.1.11 Baseline Value Exchange IOTP Transaction ............226 9.1.12 Valid Combinations of Document Exchanges ............230 9.1.13 Combining Authentication Transactions with other Transactions ........................................234 9.2 Infrastructure Transactions ...............................235 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 235 9.2.2 Baseline Ping IOTP Transaction ......................241 10. Retrieving Logos .............................................244 10.1 Logo Size .................................................245 10.2 Logo Color Depth ..........................................245 10.3 Logo Net Location Examples ................................246 11. Brands .......................................................246 11.1 Brand Definitions and Brand Selection .....................246 11.1.1 Definition of Payment Instrument ....................247 11.1.2 Definition of Brand .................................247 11.1.3 Definition of Dual Brand ............................248 11.1.4 Definition of Promotional Brand .....................248 11.1.5 Identifying Promotional Brands ......................249 11.2 Brand List Examples .......................................251 11.2.1 Simple Credit Card Based Example ....................252 11.2.2 Credit Card Brand List Including Promotional Brands..253 11.2.3 Brand Selection Example .............................254 11.2.4 Complex Electronic Cash Based Brand List ............255 12. IANA Considerations ..........................................257 12.1 Codes Controlled by IANA ..................................257 12.2 Codes not controlled by IANA ..............................263 13. Internet Open Trading Protocol Data Type Definition ..........263 14. Glossary .....................................................277 15. References ...................................................284 16. Author's Address .............................................287 17. Full Copyright Statement .....................................290 Burdett Informational [Page 5] RFC 2801 IOTP/1.0 April 2000 Table of Figures Figure 1 IOTP Trading Roles 16 Figure 2 Offer Exchange 19 Figure 3 Payment Exchange 22 Figure 4 Delivery Exchange 25 Figure 5 Authentication Exchange 27 Figure 6 IOTP Message Structure 33 Figure 7 An IOTP Transaction 34 Figure 8 Example use of ID attributes 46 Figure 9 Element References 48 Figure 10 Signature Digests 79 Figure 11 Example use of Signatures for Baseline Purchase 81 Figure 12 Checking a Payment Handler can carry out a Payment 87 Figure 13 Checking a Delivery Handler can carry out a Delivery 90 Figure 14 Trading Components 94 Figure 15 Brand List Element Relationships 113 Figure 16 Trading Blocks 164 Figure 17 Payment and Authentication Message Flow Combinations 187 Figure 18 Authentication Document Exchange 190 Figure 19 Brand Dependent Offer Document Exchange 196 Figure 20 Brand Independent Offer Exchange 198 Figure 21 Payment Document Exchange 204 Figure 22 Delivery Document Exchange 210 Figure 23 Payment and Delivery Document Exchange 214 Figure 24 Baseline Authentication IOTP Transaction 217 Figure 25 Baseline Deposit IOTP Transaction 219 Figure 26 Baseline Purchase IOTP Transaction 221 Figure 27 Baseline Refund IOTP Transaction 223 Figure 28 Baseline Withdrawal IOTP Transaction 225 Figure 29 Baseline Value Exchange IOTP Transaction 228 Figure 30 Baseline Value Exchange Signatures 230 Figure 31 Valid Combinations of Document Exchanges 231 Figure 32 Baseline Transaction Status Inquiry 238 Figure 33 Baseline Ping Messages 242 Burdett Informational [Page 6] RFC 2801 IOTP/1.0 April 2000 1. Background The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. The developers of IOTP seek to provide a virtual capability that safely replicates the real world, the paper based, traditional, understood, accepted methods of trading, buying, selling, value exchanging that has existed for many hundreds of years. The negotiation of who will be the parties to the trade, how it will be conducted, the presentment of an offer, the method of payment, the provision of a payment receipt, the delivery of goods and the receipt of goods. These are events that are taken for granted in the course of real world trade. IOTP has been produced to provide the same for the virtual world, and to prepare and provide for the introduction of new models of trading made possible by the expanding presence of the virtual world. The other fundamental ideal of the IOTP effort is to produce a definition of these trading events in such a way that no matter where produced, two unfamiliar parties using electronic commerce capabilities to buy and sell that conform to the IOTP specifications will be able to complete the business safely and successfully. In summary, IOTP supports: o Familiar trading models o New trading models o Global interoperability The remainder of this section provides background to why IOTP was developed. The specification itself starts in the next chapter. 1.1 Commerce on the Internet, a Different Model The growth of the Internet and the advent of electronic commerce are bringing about enormous changes around the world in society, politics and government, and in business. The ways in which trading partners communicate, conduct commerce, are governed have been enriched and changed forever. Burdett Informational [Page 7] RFC 2801 IOTP/1.0 April 2000 One of the very fundamental changes about which IOTP is concerned is taking place in the way consumers and merchants trade. Characteristics of trading that have changed markedly include: o Presence: Face-to-face transactions become the exception, not the rule. Already with the rise of mail order and telephone order placement this change has been felt in western commerce. Electronic commerce over the Internet will further expand the scope and volume of transactions conducted without ever seeing the people who are a part of the enterprise with whom one does business. o Authentication: An important part of personal presence is the ability of the parties to use familiar objects and dialogue to confirm they are who they claim to be. The seller displays one or several well known financial logos that declaim his ability to accept widely used credit and debit instruments in the payment part of a purchase. The buyer brings government or financial institution identification that assures the seller she will be paid. People use intangibles such as personal appearance and conduct, location of the store, apparent quality and familiarity with brands of merchandise, and a good clear look in the eye to reinforce formal means of authentication. o Payment Instruments: Despite the enormous size of bank card financial payments associations and their members, most of the world's trade still takes place using the coin of the realm or barter. The present infrastructure of the payments business cannot economically support low value transactions and could not survive under the consequent volumes of transactions if it did accept low value transactions. o Transaction Values: New meaning for low value transactions arises in the Internet where sellers may wish to offer for example, pages of information for fractions of currency that do not exist in the real world. o Delivery: New modes of delivery must be accommodated such as direct electronic delivery. The means by which receipt is confirmed and the execution of payment change dramatically where the goods or services have extremely low delivery cost but may in fact have very high value. Or, maybe the value is not high, but once delivery occurs the value is irretrievably delivered so payment must be final and non-refundable but delivery nonetheless must still be confirmed before payment. Incremental delivery such as listening or viewing time or playing time are other models that operate somewhat differently in the virtual world. Burdett Informational [Page 8] RFC 2801 IOTP/1.0 April 2000 1.2 Benefits of IOTP ELECTRONIC COMMERCE SOFTWARE VENDORS Electronic Commerce Software Vendors will be able to develop e- commerce products which are more attractive as they will inter- operate with any other vendors' software. However, since IOTP focuses on how these solutions communicate, there is still plenty of opportunity for product differentiation. PAYMENT BRANDS IOTP provides a standard framework for encapsulating payment protocols. This means that it is easier for payment products to be incorporated into IOTP solutions. As a result the payment brands will be more widely distributed and available on a wider variety of platforms. MERCHANTS There are several benefits for Merchants: o they will be able to offer a wider variety of payment brands, o they can be more certain that the customer will have the software needed to complete the purchase o through receiving payment and delivery receipts from their customers, they will be able to provide customer care knowing that they are dealing with the individual or organisation with which they originally traded o new merchants will be able to enter this new (Internet) market- place with new products and services, using the new trading opportunities which IOTP presents BANKS AND FINANCIAL INSTITUTIONS There are also several benefits for Banks and Financial Institutions: o they will be able to provide IOTP support for merchants o they will find new opportunities for IOTP related services: - providing customer care for merchants - fees from processing new payments and deposits Burdett Informational [Page 9] RFC 2801 IOTP/1.0 April 2000 o they have an opportunity to build relationships with new types of merchants CUSTOMERS For Customers there are several benefits: o they will have a larger selection of merchants with whom they can trade o there is a more consistent interface when making the purchase o there are ways in which they can get their problems fixed through the merchant (rather than the bank!) o there is a record of their transaction which can be used, for example, to feed into accounting systems or, potentially, to present to the tax authorities 1.3 Baseline IOTP This specification is Baseline IOTP. It is a Baseline in that it contains ways of doing trades on the Internet which are the most common, for example purchases and refunds. The group that has worked on the IOTP see an extended version being developed over time but feel a need to focus on a limited function but completely usable specification in order that implementers can develop solutions that work now. During this period it is anticipated that there will be no changes to the scope of this specification with the only changes made being limited to corrections where problems are found. Software solutions have been developed based on earlier versions of this specification (for example version 0.9 published in early 1998 and earlier revisions of version 1.0 published during 1999) which prove that the IOTP works. 1.4 Objectives of Document The objectives of this document are to provide a specification of version 1.0 of the Internet Open Trading Protocols which can be used to design and implement systems which support electronic trading on the Internet using the Internet Open Trading Protocols. Burdett Informational [Page 10] RFC 2801 IOTP/1.0 April 2000 The purpose of the document is: o to allow potential developers of products based on the protocol to develop software/hardware solutions which use the protocol o to allow the financial services industry to understand a developing electronic commerce trading protocol that encapsulates (without modification) any of the current or developing payment schemes now being used or considered by their merchant customer base 1.5 Scope of Document The protocol describes the content, format and sequences of messages that pass among the participants in an electronic trade - consumers, merchants and banks or other financial institutions, and customer care providers. These are required to support the electronic commerce transactions outlined in the objectives above. The protocol is designed to be applicable to any electronic payment scheme since it targets the complete purchase process where the movement of electronic value from the payer to the payee is only one, but important, step of many that may be involved to complete the trade. Payment Scheme which IOTP could support include MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton, etc. Each payment scheme contains some message flows which are specific to that scheme. These scheme-specific parts of the protocol are contained in a set of payment scheme supplements to this specification. The document does not prescribe the software and processes that will need to be implemented by each participant. It does describe the framework necessary for trading to take place. This document also does not address any legal or regulatory issues surrounding the implementation of the protocol or the information systems which use them. 1.6 Document Structure The document consists of the following sections: o Section 1 - Background: This section gives a brief background on electronic commerce and the benefits IOTP offers. Burdett Informational [Page 11] RFC 2801 IOTP/1.0 April 2000 o Section 2 - Introduction: This section describes the various Trading Exchanges and shows how these trading exchanges are used to construct the IOTP Transactions. This section also explains various Trading Roles that would participate in electronic trade. o Section 3 - Protocol Structure: This section summarises how various IOTP transactions are constructed using the Trading Blocks and Trading Components that are the fundamental building blocks for IOTP transactions. All IOTP transaction messages are well formed XML documents. o Section 4 - IOTP Error Handling: This section describes how to process exceptions and errors during the protocol message exchange and trading exchange processing. This section provides a generic overview of the exception handling. This section should be read carefully. o Section 5 - Security Considerations: This section considers from an IETF perspective, how IOTP addresses security. It includes: how to determine whether to use digital signatures with IOTP, how IOTP address data privacy, and how security built into payment protocols relate to IOTP security. o Section 6 - Digital Signatures and IOTP: This section provides an overview of how IOTP uses digital signatures; how to check a signature is correctly calculated and how the various Trading Roles that participate in trade should check signatures when required. o Section 7 - Trading Components: This section defines the XML elements required by Trading Components. o Section 8 - Trading Blocks: This section describes how Trading Blocks are constructed from Trading Components. o Section 9 - Internet Open Trading Protocol Transactions: This section describes all the IOTP Baseline transactions. It refers to Trading Blocks and Trading Components and Signatures. This section doesn't directly link error handling during the protocol exchanges, the reader is advised to understand Error Handling as defined in section before reading this section. o Section 10 - Retrieving Logos: This section describes how IOTP specific logos can be retrieved. Burdett Informational [Page 12] RFC 2801 IOTP/1.0 April 2000 o Section 11 - Brands: This section provides: an overview of Brand Definitions and Brand Selection which describe how a Consumer can select a Brand from a list provided by the Merchant; as well as some examples of Brand Lists. o Section 12 - IANA Considerations: This section describes how new values for codes used by IOTP are co-ordinated. o Section 13 - Internet Open Trading Protocol Data Type Definition: This section contains the XML Data Type Definitions for IOTP. o Section 14 - Glossary. This describes all the major terminology used by IOTP. o Section 15 - A list of the other documents referenced by the IOTP specification. o Section 16 - The Author's Address o Section 17 - Full Copyright Statement 1.7 Intended Readership Software and hardware developers; development analysts; business and technical planners; industry analysts; merchants; bank and other payment handlers; owners, custodians, and users of payment protocols. 1.7.1 Reading Guidelines This IOTP specification is structured primarily in a sequence targeted at people who want to understand the principles of IOTP. However from practical implementation experience by implementers of earlier of versions of the protocol new readers who plan to implement IOTP may prefer to read the document in a different sequence as described below. Review the transport independent parts of the specification. This covers: o Section 14 - Glossary o Section 1 - Background o Section 2 - Introduction o Section 3 - Protocol Structure o Section 4 - IOTP Error Handling Burdett Informational [Page 13] RFC 2801 IOTP/1.0 April 2000 o Section 5 - Security Considerations o Section 9 - Internet Open Trading Protocol Transactions o Section 11 - Brands o Section 12 - IANA Considerations o Section 10 - Retrieving Logos Review the detailed XML definitions: o Section 8 - Trading Blocks o Section 7 - Trading Components o Section 6 - Digital Signatures and IOTP 2. Introduction The Internet Open Trading Protocols (IOTP) define a number of different types of IOTP Transactions: o Purchase. This supports a purchase involving an offer, a payment and optionally a delivery o Refund. This supports the refund of a payment as a result of, typically, an earlier purchase o Value Exchange. This involves two payments which result in the exchange of value from one combination of currency and payment method to another o Authentication. This supports one organisation or individual to check that another organisation or individual are who they appear to be. o Withdrawal. This supports the withdrawal of electronic cash from a financial institution o Deposit. This supports the deposit of electronic cash at a financial institution o Inquiry. This supports inquiries on the status of an IOTP transaction which is either in progress or is complete Burdett Informational [Page 14] RFC 2801 IOTP/1.0 April 2000 o Ping. This supports a simple query which enables one IOTP aware application to determine whether another IOTP application running elsewhere is working or not. These IOTP Transactions are "Baseline" transactions since they have been identified as a minimum useful set of transactions. Later versions of IOTP may include additional types of transactions. Each of the IOTP Transactions above involve: o a number of organisations playing a Trading Role, and o a set of Trading Exchanges. Each Trading Exchange involves the exchange of data, between Trading Roles, in the form of a set of Trading Components. Trading Roles, Trading Exchanges and Trading Components are described below. Burdett Informational [Page 15] RFC 2801 IOTP/1.0 April 2000 2.1 Trading Roles The Trading Roles identify the different parts which organisations can take in a trade. The five Trading Roles used within IOTP are illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Merchant Customer Care Provider resolves ---------- ---------------------------------------------->| Merchant | | Consumer disputes and problems |Cust.Care.| | | Provider | | ---------- | Payment Handler accepts or makes ---------- | ------------------------------------------>| Payment | | | Payment for Merchant | Handler | | | ---------- v v ---------- Consumer makes purchases or obtains ---------- | Consumer |<--------------------------------------->| Merchant | ---------- refund from Merchant ---------- ^ | Delivery Handler supplies goods or ---------- |---------------------------------------------->|Deliverer | services for Merchant | Handler | ---------- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 1 IOTP Trading Roles Burdett Informational [Page 16] RFC 2801 IOTP/1.0 April 2000 The roles are: o Consumer. The person or organisation which is to receive and pay for the goods or services o Merchant. The person or organisation from whom the purchase is being made and who is legally responsible for providing the goods or services and receives the benefit of the payment made o Payment Handler. The entity that physically receives the payment from the Consumer on behalf of the Merchant o Delivery Handler. The entity that physically delivers the goods or services to the Consumer on behalf of the Merchant. o Merchant Customer Care Provider. The entity that is involved with customer dispute negotiation and resolution on behalf of the Merchant Roles may be carried out by the same organisation or different organisations. For example: o in the simplest case one physical organisation (e.g., a merchant) could handle the purchase, accept the payment, deliver the goods and provide merchant customer care o at the other extreme, a merchant could handle the purchase but instruct the consumer to pay a bank or financial institution, request that delivery be made by an overnight courier firm and to contact an organisation which provides 24x7 service if problems arise. Note that in this specification, unless stated to the contrary, when the words Consumer, Merchant, Payment Handler, Delivery Handler or Customer Care Provider are used, they refer to the Trading Role rather than an actual organisation. An individual organisation may take multiple roles. For example a company which is selling goods and services on the Internet could take the role of Merchant when selling goods or services and the role of Consumer when the company is buying goods or services itself. As roles occur in different places there is a need for the organisations involved in the trade to exchange data, i.e. to carry out Trading Exchanges, so that the trade can be completed. Burdett Informational [Page 17] RFC 2801 IOTP/1.0 April 2000 2.2 Trading Exchanges The Internet Open Trading Protocols identify four Trading Exchanges which involve the exchange of data between the Trading Roles. The Trading Exchanges are: o Offer. The Offer Exchange results in the Merchant providing the Consumer with the reason why the trade is taking place. It is called an Offer since the Consumer must accept the Offer if a trade is to continue o Payment. The Payment Exchange results in a payment of some kind between the Consumer and the Payment Handler. This may occur in either direction o Delivery. The Delivery Exchange transmits either the on-line goods, or delivery information about physical goods from the Delivery Handler to the Consumer, and o Authentication. The Authentication Exchange can be used by any Trading Role to authenticate another Trading Role to check that they are who they appear to be. IOTP Transactions are composed of various combinations of these Trading Exchanges. For example, an IOTP Purchase transaction includes Offer, Payment, and Delivery Trading Exchanges. As another example, an IOTP Value Exchange transaction is composed of an Offer Trading Exchange and two Payment Trading Exchanges. Trading Exchanges consist of Trading Components that are transmitted between the various Trading Roles. Where possible, the number of round-trip delays in an IOTP Transaction is minimised by packing the Components from several Trading Exchanges into combination IOTP Messages. For example, the IOTP Purchase transaction combines a Delivery Organisation Component with an Offer Response Component in order to avoid an extra Consumer request and response. Each of the IOTP Trading Exchanges is described in more detail below. For clarity of description, these describe the Trading Exchanges as though they were standalone operations. For performance reasons, the Trading Exchanges are intermingled in the actual IOTP Transaction definitions. Burdett Informational [Page 18] RFC 2801 IOTP/1.0 April 2000 2.2.1 Offer Exchange The goal of the Offer Exchange is for the Merchant to provide the Consumer with information about the trade so that the Consumer can decide whether to continue with the trade. This is illustrated in the figure below. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer | Merchant STEP | | 1. Consumer decides to trade and sends information about the transaction (requests an offer) to the Merchant e.g., using HTML. C --> M Data: Information on what is being purchased (Offer Request) - outside scope of IOTP 2. Merchant checks the information provided by the Consumer, creates an Offer optionally signs it and sends it to the Consumer. C <-- M OFFER RESPONSE. Components: Status; Organisation(s) (Consumer, DelivTo, Merchant, Payment Handler, Customer Care); Order; Payment; Delivery; TradingRoleData (optional) Offer Response Signature (optional) that signs other components 3. Consumer checks the information from the Merchant and decides whether to continue. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 2 Offer Exchange An Offer Exchange uses the following Trading Components that are passed between the Consumer and the Merchant: o the Status component is used to indicate to other parties that a valid Offer Response has been generated o the Organisation Component contains information which describes the Organisations which are taking a role in the trade: - the consumer provides information, about who the consumer is and, if goods or services are being delivered, where the goods or services are to be delivered to Burdett Informational [Page 19] RFC 2801 IOTP/1.0 April 2000 - the merchant augments this information by providing information about the merchant, the Payment Handler, the customer care provider and, if goods or services are being delivered, the Delivery Handler o the Order Component contains descriptions of the goods or services which will result from the trade if the consumer agrees to the offer. This information is sent by the Merchant to the consumer who should verify it o the Payment Component generated by the Merchant, contains details of how much to pay, the currency and the payment direction, for example the consumer could be asking for a refund. Note that there may be more than one payment in a trade o the Delivery Component, also generated by the Merchant, is used if goods or services are being delivered. This contains information about how delivery will occur, for example by post or using e-mail o the Trading Role Data component contains data the Merchant wants to forward to another Trading Role such as a Payment Handler or Delivery Handler o the "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity. The exact content of the information provided by the Merchant to the Consumer will vary depending on the type of IOTP Transaction. For example: o low value purchases may not need a signature o the amount to be paid may vary depending on the payment brand and payment protocol used o some offers may not involve the delivery of any goods o a value exchange will involve two payments o a merchant may not offer customer care. Information provided by the consumer to the merchant is provided using a variety of methods, for example, it could be provided: o using [HTML] pages as part of the "shopping experience" of the consumer. Burdett Informational [Page 20] RFC 2801 IOTP/1.0 April 2000 o Using the Open Profiling Standard [OPS] which has recently been proposed, o in the form of Organisation Components associated with an authentication of a Consumer by a Merchant o as Order Components in a later version of IOTP. 2.2.2 Payment Exchange The goal of the Payment Exchange is for a payment to be made from the Consumer to a Payment Handler or vice versa using a payment brand and payment protocol selected by the Consumer. A secondary goal is to optionally provide the Consumer with a digitally signed Payment Receipt which can be used to link the payment to the reason for the payment as described in the Offer Exchange. Payment Exchanges can work in a variety of ways. The most general case where the trade is dependent on the payment brand and protocol used is illustrated in the diagram below. Simpler payment exchanges are possible. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer Pay Handler | Merchant | STEP | | | 1. Consumer decides to trade and sends information about the transaction (requests an offer) to the Merchant e.g., using HTML. C --> M Information on what is being paid for (outside scope of IOTP 2. Merchant decides which payment brand, payment protocols and currencies/amounts to offer, places then in a Brand List Component and sends them to the Consumer C <-- M Components: Brand List 3. Consumer selects the payment brand, protocol and currency/amount to use, creates a Brand Selection