TRADE Working Group David Burdett Internet Draft Mondex International draft-ietf-trade-iotp-v1.0-protocol-03.txt Expires: 28 August 1999 Internet Open Trading Protocol - IOTP Version 1.0 David Burdett et al. [Page 1] Internet Draft IOTP/1.0 28 Feb 1999 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the TRADE working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the TRADE working group are archived at http://www.elistx.com/archives/ietf-trade. David Burdett et al. [Page 2] Internet Draft IOTP/1.0 28 Feb 1999 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, 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. David Burdett et al. [Page 3] Internet Draft IOTP/1.0 28 Feb 1999 Table of Contents Status of this Memo..................................................2 Abstract.............................................................3 1. Background.......................................................10 1.1 Commerce on the Internet _ a Different Model.................11 1.2 Benefits of IOTP.............................................12 1.3 Baseline IOTP................................................13 1.4 Objectives of Document.......................................14 1.5 Purpose......................................................14 1.6 Scope of Document............................................14 1.7 Document Structure...........................................15 1.8 Intended Readership..........................................16 1.8.1 Reading Guidelines ......................................17 1.9 History......................................................17 2. Introduction.....................................................19 2.1 Trading Roles................................................20 2.2 Trading Exchanges............................................21 2.2.1 Offer Exchange ..........................................23 2.2.2 Payment Exchange ........................................25 2.2.3 Delivery Exchange .......................................29 2.2.4 Authentication Exchange .................................31 2.3 Scope of Baseline IOTP.......................................33 3. Protocol Structure...............................................38 3.1 Overview.....................................................40 3.1.1 IOTP Message Structure ..................................40 3.1.2 IOTP Transactions .......................................42 3.2 IOTP Message.................................................43 3.2.1 XML Document Prolog .....................................45 3.3 Transaction Reference Block..................................45 3.3.1 Transaction Id Component ................................46 3.3.2 Message Id Component ....................................48 3.3.3 Related To Component ....................................49 3.4 ID Attributes................................................51 3.4.1 IOTP Message ID Attribute Definition ....................52 3.4.2 Block and Component ID Attribute Definitions ............53 3.4.3 Example of use of ID Attributes .........................54 3.5 Element References...........................................55 3.6 Brands and Brand Selection...................................56 3.6.1 Definition of Payment Instrument ........................57 3.6.2 Definition of Brand .....................................58 3.6.3 Definition of Dual Brand ................................58 David Burdett et al. [Page 4] Internet Draft IOTP/1.0 28 Feb 1999 3.6.4 Definition of Promotional Brand .........................59 3.6.5 Identifying Promotional Brands ..........................59 3.7 Extending IOTP...............................................62 3.7.1 Extra XML Elements ......................................62 3.7.2 Opaque Embedded Data ....................................63 3.7.3 Values for IOTP Codes ...................................63 3.8 Packaged Content Element.....................................66 3.8.1 Packaging HTML ..........................................68 3.9 Identifying Languages........................................69 3.10 Secure and Insecure Net Locations...........................70 3.11 Cancelled Transactions......................................70 3.11.1 Cancelling Transactions ................................70 3.11.2 Handling Cancelled Transactions ........................71 4. IOTP Error Handling..............................................73 4.1 Technical Errors.............................................73 4.2 Business Errors..............................................74 4.3 Error Depth..................................................74 4.3.1 Transport Level .........................................75 4.3.2 Message Level ...........................................75 4.3.3 Block Level .............................................76 4.4 Idempotency, Processing Sequence, and Message Flow...........78 4.4.1 Server Role Processing Sequence .........................78 4.4.2 Client Role Processing Sequence .........................84 5. Security Considerations..........................................90 5.1 Digital Signatures and IOTP..................................90 5.1.1 IOTP Signature Example ..................................92 5.1.2 OriginatorInfo and RecipientInfo Elements ...............94 5.1.3 Symmetric and Asymmetric Cryptography ...................95 5.1.4 Mandatory and Optional Signatures .......................95 5.1.5 Using signatures to Prove Actions Complete Successfully .95 5.2 Checking a Signature is Correctly Calculated.................96 5.3 Checking a Payment or Delivery can occur.....................97 5.3.1 Check the Action Request was sent to the Correct Organisation ..................................................99 5.3.2 Check the Correct Components are present in the Request Block ........................................................103 5.3.3 Check an Action is Authorised ..........................103 5.4 Data Integrity and Privacy..................................105 6. Trading Components..............................................106 6.1 Protocol Options Component..................................108 6.2 Authentication Data Component...............................110 6.3 Authentication Response Component...........................112 6.4 Order Component.............................................113 6.4.1 Order Description Content ..............................115 David Burdett et al. [Page 5] Internet Draft IOTP/1.0 28 Feb 1999 6.4.2 OkFrom and OkTo Timestamps .............................115 6.5 Organisation Component......................................116 6.5.2 Trading Role Element ...................................119 6.5.3 Contact Information Element ............................122 6.5.4 Person Name Element ....................................123 6.5.5 Postal Address Element .................................124 6.6 Brand List Component........................................125 6.6.1 Brand Element ..........................................127 6.6.2 Protocol Amount Element ................................130 6.6.3 Currency Amount Element ................................132 6.6.4 Pay Protocol Element ...................................133 6.7 Brand Selection Component...................................135 6.7.1 Brand Selection Brand Info Element .....................137 6.7.2 Brand Selection Protocol Amount Info Element ...........138 6.7.3 Brand Selection Currency Amount Info Element ...........138 6.8 Payment Component...........................................139 6.9 Payment Scheme Component....................................141 6.10 Payment Receipt Component..................................142 6.11 Payment Note Component.....................................144 6.12 Delivery Component.........................................145 6.12.1 Delivery Data Element .................................147 6.13 Delivery Note Component....................................149 6.14 Status Component...........................................151 6.14.1 Offer Completion Codes ................................154 6.14.2 Payment Completion Codes ..............................154 6.14.3 Delivery Completion Codes .............................155 6.14.4 Authentication Completion Codes .......................157 6.15 Trading Role Data Component................................158 6.15.1 Who Receives a Trading Role Data Component ............159 6.16 Inquiry Type Component.....................................159 6.17 Signature Component........................................160 6.17.1 IOTP usage of signature elements and attributes .......164 6.17.2 Offer Response Signature Component ....................166 6.17.3 Payment Receipt Signature Component ...................167 6.17.4 Delivery Response Signature Component .................168 6.17.5 Authentication Request Signature Component ............168 6.17.6 Authentication Response Signature Component ...........168 6.17.7 Ping Request Signature Component ......................169 6.17.8 Ping Response Signature Component .....................169 6.18 Certificate Component......................................169 6.18.1 IOTP usage of signature elements and attributes .......170 6.19 Error Component............................................170 6.19.1 Error Processing Guidelines ...........................173 6.19.2 Error Codes ...........................................174 6.19.3 Error Location Element ................................178 7. Trading Blocks..................................................180 David Burdett et al. [Page 6] Internet Draft IOTP/1.0 28 Feb 1999 7.1 Trading Protocol Options Block..............................183 7.2 TPO Selection Block.........................................184 7.3 Offer Response Block........................................185 7.4 Authentication Request Block................................186 7.5 Authentication Response Block...............................187 7.6 Authentication Status Block.................................187 7.7 Payment Request Block.......................................188 7.8 Payment Exchange Block......................................190 7.9 Payment Response Block......................................190 7.10 Delivery Request Block.....................................191 7.11 Delivery Response Block....................................193 7.12 Inquiry Request Trading Block..............................194 7.13 Inquiry Response Trading Block.............................194 7.14 Ping Request Block.........................................195 7.15 Ping Response Block........................................196 7.16 Signature Block............................................198 7.16.1 Offer Response ........................................199 7.16.2 Payment Request .......................................199 7.16.3 Payment Response ......................................199 7.16.4 Delivery Request ......................................199 7.17 Error Block................................................199 7.18 Cancel Block...............................................201 8. Internet Open Trading Protocol Transactions.....................202 8.1 Authentication and Payment Related IOTP Transactions........202 8.1.1 Authentication Document Exchange .......................205 8.1.2 Offer Document Exchange ................................212 8.1.3 Payment Document Exchange ..............................222 8.1.4 Delivery Document Exchange .............................228 8.1.5 Payment and Delivery Document Exchange .................231 8.1.6 Baseline Authentication IOTP Transaction ...............234 8.1.7 Baseline Deposit IOTP Transaction ......................236 8.1.8 Baseline Purchase IOTP Transaction .....................238 8.1.9 Baseline Refund IOTP Transaction .......................240 8.1.10 Baseline Withdrawal IOTP Transaction ..................242 8.1.11 Baseline Value Exchange IOTP Transaction ..............244 8.1.12 Valid Combinations of Document Exchanges ..............248 8.1.13 Combining Authentication Transactions with other Transactions .................................................252 8.2 Infrastructure Transactions.................................253 8.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...254 8.2.2 Baseline Ping IOTP Transaction .........................258 9. Retrieving Logos................................................262 9.1 Logo Size...................................................262 9.2 Logo Color Depth............................................263 9.3 Logo Net Location Examples..................................263 David Burdett et al. [Page 7] Internet Draft IOTP/1.0 28 Feb 1999 10. Brand List Examples............................................265 10.1 Simple Credit Card Based Example...........................265 10.2 Credit Card Brand List Including Promotional Brands........266 10.3 Brand Selection Example....................................269 10.4 Complex Electronic Cash Based Brand List...................269 11. Open Trading Protocol Data Type Definition.....................274 12. Glossary.......................................................289 13. Copyrights.....................................................298 14. References.....................................................299 15. Author's Address...............................................303 David Burdett et al. [Page 8] Internet Draft IOTP/1.0 28 Feb 1999 Table of Figures Figure 1 IOTP Trading Roles ........................................20 Figure 2 Offer Exchange ............................................23 Figure 3 Payment Exchange ..........................................26 Figure 4 Delivery Exchange .........................................30 Figure 5 Authentication Exchange ...................................33 Figure 6 IOTP Message Structure ....................................41 Figure 7 An IOTP Transaction .......................................42 Figure 8 Example use of ID attributes ..............................54 Figure 9 Element References ........................................56 Figure 10 Server Role Processing Sequence ..........................80 Figure 11 Client Role Processing Sequence ..........................86 Figure 12 Signature Digests ........................................91 Figure 13 Example use of Signatures for Baseline Purchase ..........93 Figure 14 Checking a Payment Handler can carry out a Payment ......100 Figure 15 Checking a Delivery Handler can carry out a Delivery ....102 Figure 16 Trading Components ......................................107 Figure 17 Brand List Element Relationships ........................127 Figure 18 Trading Blocks ..........................................181 Figure 19 Payment and Authentication Message Flow Combinations ....204 Figure 20 Authentication Document Exchange ........................208 Figure 21 Brand Dependent Offer Document Exchange .................214 Figure 22 Brand Independent Offer Exchange ........................217 Figure 23 Payment Document Exchange ...............................224 Figure 24 Delivery Document Exchange ..............................229 Figure 25 Payment and Delivery Document Exchange ..................232 Figure 26 Baseline Authentication IOTP Transaction ................235 Figure 27 Baseline Deposit IOTP Transaction .......................237 Figure 28 Baseline Purchase IOTP Transaction ......................239 Figure 29 Baseline Refund IOTP Transaction ........................241 Figure 30 Baseline Withdrawal IOTP Transaction ....................243 Figure 31 Baseline Value Exchange IOTP Transaction ................246 Figure 32 Baseline Value Exchange Signatures ......................247 Figure 33 Valid Combinations of Document Exchanges ................250 Figure 34 Baseline Transaction Status Inquiry .....................257 Figure 35 Baseline Ping Messages ..................................259 David Burdett et al. [Page 9] Internet Draft IOTP/1.0 28 Feb 1999 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. David Burdett et al. [Page 10] Internet Draft IOTP/1.0 28 Feb 1999 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. 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 David Burdett et al. [Page 11] Internet Draft IOTP/1.0 28 Feb 1999 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. 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 David Burdett et al. [Page 12] Internet Draft IOTP/1.0 28 Feb 1999 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 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. The team working on the IOTP see an extended versions of this specification being developed as needs demand but at this stage feel a need to develop a limited function but usable specification in order that technology providers can develop pathway-pilot products that will be placed in the market in order to understand the real _market place_ demands and requirements for electronic trading or electronic commerce. To proceed otherwise would be presumptuous, time consuming, expensive and foolish. Accordingly the IOTP Baseline specification has been produced for pathway-pilot product development, expecting to transact live trades David Burdett et al. [Page 13] Internet Draft IOTP/1.0 28 Feb 1999 to prove the interoperability of solutions based on this specification by end '98. 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 which prove that the basic concepts work. 1.4 Objectives of Document The objectives of this document are to provide a functional specification of version 1.0 of the Open Trading Protocols which can be used to design and implement systems which support electronic trading on the Internet using the Open Trading Protocols. An overview of IOTP is provided the IOTP Business Description which explains the Business Requirements for IOTP. 1.5 Purpose The purpose of the document is: o to allow potential developers of products based on the protocol to start development of 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.6 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. David Burdett et al. [Page 14] Internet Draft IOTP/1.0 28 Feb 1999 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, DigiCash, 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.7 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. 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 David Burdett et al. [Page 15] Internet Draft IOTP/1.0 28 Feb 1999 a generic overview of the exception handling. This section should be read carefully. o Section 5 - Security Considerations: This section describes security considerations and digital signatures for the XML elements exchanged between the Trading Roles. o Section 6 - Trading Components: This section defines the XML elements required by Trading Components. o Section 7 - Trading Blocks: This section describes how Trading Blocks are constructed from Trading Components. o Section 8 - 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 9 - Retrieving Logos: This section describes how IOTP specific logos can be retrieved. o Section 10 - Brand List Examples: This section gives some examples for Brand List. o Section 11 - XML Overview: This section gives brief introduction to XML. o Section 12 - Open Trading Protocol Data Type Definition: This section contains the XML Data Type Definitions for IOTP. o Section 12 - Glossary. This describes all the major terminology used by IOTP. 1.8 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. David Burdett et al. [Page 16] Internet Draft IOTP/1.0 28 Feb 1999 1.8.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 12 - Glossary o Section 1 - Background o Section 2 - Introduction o Section 3 - Protocol Structure o Section 4 - IOTP Error Handling o Section 8 - Open Trading Protocol Transactions o Section 10 - Brand List Examples o Section 4 - IOTP Error Handling o Section 9 - Retrieving Logos Review the detailed XML definitions: o Section 11 - XML Overview (if the reader does not know XML) o Section 7 - Trading Blocks o Section 6 - Trading Components 1.9 History Version 0.1 20 February 1997 Initial draft for comment Version 0.2 14 April 1997 Revised draft including changes arising from comments David Burdett et al. [Page 17] Internet Draft IOTP/1.0 28 Feb 1999 Version 0.2a 24 April 1997 Same as version 0-2 with typographic corrections Version 0.3 9 October 1997 Revised draft for comment including revised encoding approach using [XML] Version 0.4 31 October 1997 Published draft for limited public review by groups working within the OTP consortium Version 0.9 12 January 1998 Revisions following limited public review _ draft for public comment only. Version 0.9.1 20 May 1998 Revisions following public review - internal IOTP Consortium review. Version 0.9.9 17 August 1998 Draft published for submission to IETF for information. Version 1.0 23 October 1998 Draft published incorporating comments received on version 0.9.9. Version 1.0 28 February 1998 Revised draft published incorporating comments received on version 1.0 David Burdett et al. [Page 18] Internet Draft IOTP/1.0 28 Feb 1999 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 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 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. David Burdett et al. [Page 19] Internet Draft IOTP/1.0 28 Feb 1999 Trading Roles, Trading Exchanges and Trading Components are described below. 2.1 Trading Roles The Trading Roles identify the different parts which organisations can take in a trade. The six 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 ---------- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 1 IOTP Trading Roles 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 David Burdett et al. [Page 20] Internet Draft IOTP/1.0 28 Feb 1999 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. 2.2 Trading Exchanges The 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 David Burdett et al. [Page 21] Internet Draft IOTP/1.0 28 Feb 1999 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. David Burdett et al. [Page 22] Internet Draft IOTP/1.0 28 Feb 1999 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 IOTP MESSAGE MERCHANT 1. Consumer decides to ----------------------> 2. Merchant checks trade and sends Information on what is the information information about the being purchased (Offer provided by the transaction (requests Request) (outside scope Consumer, creates an an offer) to the of IOTP) Offer and sends it Merchant, e.g using to the Consumer| HTML v 3. Consumer checks the Components: Organisation(s) information from the (Consumer, DeliverTo, Merchant, Merchant and decides <---------- Payment Handler, Delivery whether to continue Offer Handler, Cust Care); Order; Pay Response Amount; Delivery; Signature (Offer Response)(which signs other components) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 2 Offer Exchange An Offer Exchange uses the following Trading Components that are passed between the Consumer and the Merchant: 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 - 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 David Burdett et al. [Page 23] Internet Draft IOTP/1.0 28 Feb 1999 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 "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. 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. David Burdett et al. [Page 24] Internet Draft IOTP/1.0 28 Feb 1999 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 IOTP MESSAGE MERCHANT 1. Consumer decides to 2. Merchant decides trade and sends Information on what is which payment information about the being paid for brand, payment transaction (requests an ----------------------> protocols and offer) to the Merchant, (outside scope of IOTP) currencies/amounts e.g using HTML to offer, places them in a Brand List Component and sends them to the Consumer | v 3. Consumer selects the payment <----------------- Brand List brand, protocol and currency/amount Brand List Component to use, creates a Brand Selection Component and sends it to the Merchant | v Brand Selection ----------------> 4. Merchant checks Brand Brand Selection Selection, creates Payment Amount information, optionally signs it to authorise payment and sends it to the Consumer | v 5. Consumer checks the Components: Payment Amount information <-------- Pay Amount; Auth data; and if OK requests that the Payment Organisation(s) (Merchant & payment starts by sending Information Payment Handler); Signature David Burdett et al. [Page 25] Internet Draft IOTP/1.0 28 Feb 1999 information to the Payment (Offer) (signs other Handler components) | | ======================================== v PAYMENT HANDLER Components: Pay Scheme; Auth 6. Payment Handler checks Data; Brand List; Pay Amount; information including Brand Selection; ----------> optional signature and if Organisation(s) (Merchant & Payment OK starts exchanging Pay Payment Handler); Signature Request Scheme Components using (Offer) (signs all other messages for selected ----- components except payment brand and payment | Pay Scheme) protocol | | | | v v | Component: Pay Scheme <------------------> Component: Pay Scheme | Payment Exchange | | | v | 7. Eventually payment protocol messages ----------- finish so Payment Handler sends Pay | Receipt and optional signature to | Consumer as proof of payment | | | v 8. Consumer checks Pay Components: Pay Receipt; Pay Receipt is OK <------- scheme; Signature (Offer); Payment Signature (Pay Receipt) (signs Pay Response Receipt and Signature (Offer) components) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 3 Payment Exchange A Payment Exchange uses the following Trading Components that are passed between the Consumer, the Merchant and the Payment Handler: o The Brand List Component contains a list of payment brands (for example, MasterCard, Visa, Mondex, GeldKarte), payment protocols (for example SET Version 1.0, Secure Channel Credit Debit (SCCD - the name used for a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL) as well as currencies/amounts that apply. The Merchant sends the Brand List to the Consumer. The consumer compares the David Burdett et al. [Page 26] Internet Draft IOTP/1.0 28 Feb 1999 payment brands, protocols and currencies/amounts on offer with those that the Consumer supports and makes a selection. o The Brand Selection Component contains the Consumer's selection. Payment brand, protocol, currency/amount and possibly protocol-specific information is sent back to the Merchant. This information may be used to change information in the Offer Exchange. For example, a merchant could choose to offer a discount to encourage the use of a store card. o The Organisation Components are generated by the Merchant. They contain details of the Merchant and Payment Handler Roles: - the Merchant role is required so that the Payment Handler can identify which Merchant initiated the payment. Typically, the result of the Payment Handler accepting (or making) a payment on behalf of the Merchant will be a credit or debit transaction to the Merchant's account held by the Payment Handler. These transactions are outside the scope of this version of IOTP - the Payment Handler role is required so that the Payment Handler can check that it is the correct Payment Handler to be used for the payment o The Payment Component contains details of how much to pay, the currency and the payment direction o The "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity. Note that the Brand List and Brand Selection Components are not signed until the payment information is created (step 4 in the diagram) o The Payment Scheme Component contains messages from the payment protocol used in the Trade. For example they could be SET messages, Mondex messages, GeldKarte Messages or one of the other payment methods supported by IOTP. The content of the Payment Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols. o The Payment Receipt Component contains a record of the payment. The content depends upon the payment protocol used. o The "Payment Receipt" Signature Component provides proof of payment by digitally signing both the Payment Receipt Component and the Offer Response Signature. The signature on the offer digitally signs the Order, Organisation and Delivery Components contained in the Offer. This signature effectively binds the payment to the offer. David Burdett et al. [Page 27] Internet Draft IOTP/1.0 28 Feb 1999 The example of a Payment Exchange above is the most general case. Simpler cases are also possible. For example, if the amount paid is not dependent on the payment brand and protocol selected then the payment information generated by step 3 can be sent to the Consumer at the same time as the Brand List Component generated by step 1. These and other variations are described in the Baseline Purchase IOTP Transaction (see section Baseline Purchase IOTP Transaction). David Burdett et al. [Page 28] Internet Draft IOTP/1.0 28 Feb 1999 2.2.3 Delivery Exchange The goal of the Delivery Exchange is to cause purchased goods to be delivered to the consumer either online or via physical delivery. A second goal is to provide a "delivery note" to the consumer, providing details about the delivery, such as shipping tracking number. The result of the delivery may also be signed so that it can be used for customer care in the case of problems with physical delivery. The message flow is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE MERCHANT 1. Consumer decides to ------------> 2. Merchant checks the trade and sends Information information provided by the information about what on what is Consumer, adds information to deliver and who is being about how the delivery will to take delivery, to delivered occur, information about the the Merchant, using for (outside organisations involved in the example, HTML scope of delivery and optionally signs IOTP) it | v 3. Consumer checks the Components: delivery information is OK, Delivery; obtains authorisation for <----------------- Organisation(s) the delivery, for example by Delivery Delivery Handler, making a payment, and sends Information Deliver To; Order; the delivery information to Signature (Offer) the Delivery Handler. | v Components: Delivery; 4. Delivery Handler checks Organisation(s), Merchant, information and Delivery Handler, DelivTo; --------> authorisation. Starts or Order; Signature (Offer); Delivery schedules delivery and Signature (Pay Receipt) Request creates and then sends a (from Payment Exchange) delivery note to the Consumer which can optionally be signed | v 5. Consumer checks delivery <--------- Component: Delivery note is OK and accepts or waits Delivery Note; Signature for delivery as described in Response (Delivery Response) the Delivery Note *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* David Burdett et al. [Page 29] Internet Draft IOTP/1.0 28 Feb 1999 Figure 4 Delivery Exchange A Delivery Exchange uses the following Trading Components that are passed between the Consumer, the Merchant and the Delivery Handler: o The Organisation Component(s) contain details of the Deliver To, Delivery Handler and Merchant Roles: - the Deliver To role indicates where the goods or services are to be delivered to - the Delivery Handler role is required so that the Delivery Handler can check that she is the correct Delivery Handler to do the delivery - the Merchant role is required so that the Delivery Handler can identify which Merchant initiated the delivery o The Order Component, contains information about the goods or services to be delivered o The Delivery Component contains information about how delivery will occur, for example by post or using e-mail. o The "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity. o The "Payment Receipt" Signature Component provides proof of payment by digitally signing the Payment Receipt Component and the Offer Signature. This is used by the Delivery Handler to check that delivery is authorised o The Delivery Note Component contains customer care information related to a physical delivery, or alternatively the actual "electronic goods". The Consumer's software does not interpret information about a physical delivery but should have the ability to display the information, both at the time of the delivery and later if the Consumer selects the Trade to which this delivery relates from a transaction list o The "Delivery Response" Signature Component, if present, provides proof of the results of the Delivery by digitally signing the Delivery Note and any Offer Response or Payment Response signatures that the Delivery Handler received. David Burdett et al. [Page 30] Internet Draft IOTP/1.0 28 Feb 1999 2.2.4 Authentication Exchange The goal of the Authentication Exchange is to allow one organisation, for example a financial institution, to be able to check that another organisation, for example a consumer, is who they appear to be. It uses a "challenge-response" mechanism. An Authentication Exchange involves: o an Authenticator - the organisation which is requesting the authentication, and o an Authenticatee - the organisation being authenticated. This is illustrated in the diagram below. David Burdett et al. [Page 31] Internet Draft IOTP/1.0 28 Feb 1999 +*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* ORGANISATION 1 IOTP MESSAGE ORGANISATION 2 (AUTHENTICATEE) (AUTHENTICATOR) 1. First organisation, 2. The second e.g a consumer, takes an organisation generates action (for example by ----------------> Authentication Data pressing a button on an Need for containing challenge HTML page) which Authentication data, the method of requires that the (outside scope of authentication to be used organisation is IOTP) and optionally a request authenticated for Organisation information then sends it to the first organisation | v 3. The first organisation Component: optionally checks any signature <------------ Authentication Data associated with the Authentication Authentication request then Request uses the challenge data with the specified authentication method to generate an Authentication Response which is sent back to the second organisation together with details of any Organisation information requested | v Component: 4. The Authentication Response is Authentication -------------> checked against the challenge data to Response Authentication check that the first organisation is Response who they appear to be and the result recorded in a Status Component which is then sent back to the first organisation | v 5. The first organisation then Component: Status optionally checks the results <------------ of the Status and any Authentication associated signature and takes Status the appropriate action or stops. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* David Burdett et al. [Page 32] Internet Draft IOTP/1.0 28 Feb 1999 Figure 5 Authentication Exchange An Authentication Exchange uses the following Trading Components that are passed between the two organisations: o the Authentication Data Component which contains the challenge data to be used in the "challenge-response" mechanism, indicates the authentication method to be used and optionally request Organisation data about the first organisation, for example a ship to or billing address. It is sent by one organisation to the other. o The Authentication Response Component which contains the challenge response generated by the recipient of the Authentication Data Component. It is sent back to the first organisation for verification together with Organisation Components requested o the Status Component which contains the results of the second party's verification of the Authentication Response. 2.3 Scope of Baseline IOTP This specification describes the IOTP Transactions which make up Baseline IOTP. As described in the preface, IOTP will evolve over time. This section defines the initial conformance criteria for implementations that claim to _support IOTP._ The main determinant on the scope of an IOTP implementation is the roles which the solution is designed to support. The roles within IOTP are described in more detail in section 2.1 Trading Roles. To summarise the roles are: Merchant, Consumer, Payment Handler, Delivery Handler and Customer Care Provider. Payment Handlers who can be of three types: o those who accept a payment as part of a purchase or make a payment as part of a refund, o those who accept value as part of a deposit transaction, or o those that issue value a withdrawal transaction David Burdett et al. [Page 33] Internet Draft IOTP/1.0 28 Feb 1999 The following table defines, for each role, the IOTP Transactions and Trading Blocks which must be supported for that role. Merchants ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler TRANSACTIONS Purchase Must Must Refund Must b) Depends Authentication May Must May b) Depends Value Exchange May Must Withdrawal Must b) Depends Deposit Must b) Depends Inquiry Must Must Must Must Must Must Ping Must Must Must Must Must Must David Burdett et al. [Page 34] Internet Draft IOTP/1.0 28 Feb 1999 Merchants ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler TRADING BLOCKS TPO Must Must Must Must TPO Selection Must Must Must Must Auth-Request a) a) a) Depends Depends Depends Auth-Reply a) a) a) Depends Depends Depends Offer Response Must Must Must Must Payment Must Must Request Payment Must Must Exchange Payment Must Must Response Delivery Must Must Request David Burdett et al. [Page 35] Internet Draft IOTP/1.0 28 Feb 1999 Merchants ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler Delivery Must Must Response Inquiry Must Must Must Must Must Must Request Inquiry Must Must Must Must Must Must Response Ping Request Must Must Must Must Must Must Ping Response Must Must Must Must Must Must Signature Must Must Must Limited Must Must Error Must Must Must Must Must Must In the above table: o _Must_ means that a Trading Role must support the Transaction or Trading Block. o _May_ means that an implementation may support the Transaction or Trading Block at the option of the developer. o _Depends_ means implementation of the Transaction or Trading Block depends on one of the following conditions: a) if Baseline Authentication IOTP Transaction is supported; David Burdett et al. [Page 36] Internet Draft IOTP/1.0 28 Feb 1999 b) if required by a Payment Method as defined in its IOTP Supplement document. o "Limited" means the Trading Block must be understood and its content manipulated but not in every respect. Specifically, on the Signature Block, Consumers do not have to be able to validate digital signatures. An IOTP solution must support all the IOTP Transactions and Trading Blocks required by at least one role (column) as described in the above table for that solution to be described as "supporting IOTP". David Burdett et al. [Page 37] Internet Draft IOTP/1.0 28 Feb 1999 3. Protocol Structure The previous section provided an introduction which explained: o Trading Roles which are the different roles which organisations can take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler and Customer Care Provider, and o Trading Exchanges where each Trading Exchange involves the exchange of data, between Trading Roles, in the form of a set of Trading Components. This section describes: o how Trading Components are constructed into Trading Blocks and the IOTP Messages which are physically sent in the form of [XML] documents between the different Trading Roles, o how IOTP Messages are exchanged between Trading Roles to create an IOTP Transaction o the XML definitions of an IOTP Message including a Transaction Reference Block - an XML element which identifies an IOTP Transaction and the IOTP Message within it o the definitions of the XML ID Attributes which are used to identify IOTP Messages, Trading Blocks and Trading Components and how these are referred to using Element References from other XML elements o an overview of Brands and Brand Selection which describes how a Consumer can select a Brand from a list provided by the Merchant o how extra XML Elements and new user defined values for existing IOTP codes can be used when Extending IOTP, o how IOTP uses the Packaged Content Element to embed data such as payment protocol messages or detailed order definitions within an IOTP Message o how IOTP Identifies Languages so that different languages can be used within IOTP Messages David Burdett et al. [Page 38] Internet Draft IOTP/1.0 28 Feb 1999 o how IOTP handles both Secure and Insecure Net Locations when sending messages o how an IOTP Transaction can be cancelled. David Burdett et al. [Page 39] Internet Draft IOTP/1.0 28 Feb 1999 3.1 Overview 3.1.1 IOTP Message Structure The structure of an IOTP Message and its relationship with Trading Blocks and Trading Components is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* IOTP MESSAGE <---------- IOTP Message - an XML Document which is | transported between the Trading Roles |-Trans Ref Block <----- Trans Ref Block - contains information which | | describes the IOTP Transaction and the IOTP | | Message. | |-Trans Id Comp. <--- Transaction Id Component - uniquely | | identifies the IOTP Transaction. The Trans Id | | Components are the same across all IOTP | | messages that comprise a single IOTP | | transaction. | |-Msg Id Comp. <----- Message Id Component - identifies and | describes an IOTP Message within an IOTP | Transaction |-Signature Block <----- Signature Block (optional) - contains one or | | more Signature Components and their | | associated Certificates | |-Signature Comp. <-- Signature Component - contains digital | | signatures. Signatures may sign digests of | | the Trans Ref Block and any Trading Component | | in any IOTP Message in the same IOTP | | transaction. | |-Certificate Comp. < Certificate Component. Used to check the | signature. |-Trading Block <------- Trading Block - an XML Element within an IOTP | |-Component Message that contains a predefined set of | |-Component Trading Components | |-Component | |-Component <-------- Trading Components - XML Elements within a | Trading Block that contain a predefined set |-Trading Block of XML elements and attributes containing | |-Component information required to support a Trading | |-Component Exchange | |-Component | |-Component | |-Component *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* David Burdett et al. [Page 40] Internet Draft IOTP/1.0 28 Feb 1999 Figure 6 IOTP Message Structure The diagram also introduces the concept of a Transaction Reference Block. This block contains, amongst other things, a globally unique identifier for the IOTP Transaction. Also each block and component is given an ID Attribute (see section 3.4) which is unique within an IOTP Transaction. Therefore the combination of the ID attribute and the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component. David Burdett et al. [Page 41] Internet Draft IOTP/1.0 28 Feb 1999 3.1.2 IOTP Transactions A predefined set of IOTP Messages exchanged between the Trading Roles constitute an IOTP Transaction. This is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER MERCHANT Generate first IOTP Message --- | | | v Process incoming | I | ------------- IOTP Message & <------------- | | -------------- | IOTP Message | generate next IOTP | | ------------- Message | N | | | | v | | ------------- | T | Process incoming | IOTP Message | -------------- | | -------------> IOTP Message & ------------- | | generate next | E | IOTP Message | | | | | v Process incoming | R | ------------- IOTP Message <------------- | | -------------- | IOTP Message | generate last IOTP | | ------------- Message & stop | N | | | | v | | ------------- | E | Process last | IOTP Message | -------------- | | -------------> incoming IOTP ------------- | | Message & stop | | T | | v | | v STOP --- STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 7 An IOTP Transaction In the above diagram the Internet is shown as the transport mechanism. This is not necessarily the case. IOTP Messages can be transported using a variety of transport mechanisms. David Burdett et al. [Page 42] Internet Draft IOTP/1.0 28 Feb 1999 The IOTP Transactions (see section 8) in this version of IOTP are specifically: 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 the remote authentication of a Consumer by another Trading Role using a variety of authentication methods, and the provision of an Organisation Component about a Consumer to another Trading Role for use in, for example the creation of an offer 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 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. 3.2 IOTP Message As described earlier, IOTP Messages are [XML] documents which are physically sent between the different Trading Roles that are taking part in a trade. The XML definition of an IOTP Message is as follows. David Burdett et al. [Page 43] Internet Draft IOTP/1.0 28 Feb 1999 Content: TransRefBlk This contains information which describes an IOTP Message within an IOTP Transaction (see section 3.3 immediately below) AuthReqBlk, These are the Trading Blocks. AuthRespBlk, DeliveryReqBlk, The Trading Blocks present within an IOTP DeliveryRespBlk Message, and the content of a Trading Block ErrorBlk itself is dependent on the type of IOTP InquiryReqBlk, Transaction being carried out - see the InquiryRespBlk, definition of each transaction in section 8 OfferRespBlk, Internet Open Trading Protocol Transactions. PayExchBlk, PayReqBlk, Full definitions of each Trading Block are PayRespBlk, described in section 7. PingReqBlk, PingRespBlk, SigBlk, David Burdett et al. [Page 44] Internet Draft IOTP/1.0 28 Feb 1999 TpoBlk, TpoSelectionBlk Attributes xmlns:iotp The [XML Namespace] definition for IOTP messages. 3.2.1 XML Document Prolog The IOTP Message is the root element of the XML document. It therefore needs to be preceded by an appropriate XML Document Prolog. For example: ... 3.3 Transaction Reference Block A Transaction Reference Block contains information which identifies the IOTP Transaction and IOTP Message. The Transaction Reference Block contains: o a Transaction Id Component which globally uniquely identifies the IOTP Transaction. The Transaction Id Components are the same across all IOTP messages that comprise a single IOTP transaction, o a Message Id Component which provides control information about the IOTP Message as well as uniquely identifying the IOTP Message within an IOTP Transaction, and o zero or more Related To Components which link this IOTP Transaction to either other IOTP Transactions or other events using the identifiers of those events. The definition of a Transaction Reference Block is as follows: David Burdett et al. [Page 45] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Transaction Reference Block within the IOTP Transaction (see section 3.4 ID Attributes). Content: TransId See 3.3.1 Transaction Id Component immediately below. MsgId See 3.3.2 Message Id Component immediately below. RelatedTo See 3.3.3 Related To Component immediately below. 3.3.1 Transaction Id Component This contains information which globally uniquely identifies the IOTP Transaction. Its definition is as follows: Attributes: ID An identifier which uniquely identifies the Transaction Id Component within the IOTP Transaction. Version This identifies the version of IOTP, and therefore the structure of the IOTP Messages, which the IOTP Transaction is using. OtpTransId Contains data which uniquely identifies the IOTP David Burdett et al. [Page 46] Internet Draft IOTP/1.0 28 Feb 1999 Transaction. It must conform to the rules for Message Ids in [RFC 822]. OtpTransType This is the type of IOTP Transaction being carried out. For Baseline IOTP it identifies a "standard" IOTP Transaction and implies the sequence and content of the IOTP Messages exchanged between the Trading Roles. The valid values for Baseline IOTP are: o BaselineAuthentication o BaselineDeposit o BaselinePurchase o BaselineRefund o BaselineWithdrawal o BaselineValueExchange o BaselineInquiry o BaselinePing Values of OtpTransType are managed under the procedure described in section 3.7.3 Values for IOTP Codes which also allows user defined values of OtpTransType to be defined. In later versions of IOTP, this list will be extended to support different types of standard IOTP Transaction based on market demand. It is also likely to support the type Dynamic which indicates that the sequence of steps within the transaction are non-standard. TransTimeStamp Where the system initiating the IOTP Transaction has an internal clock, it is set to the time at which the IOTP Transaction started in [UTC] format. The main purpose of this attribute is to provide an alternative way of identifying a transaction by specifying the time at which it started. Some systems, for example, hand held devices may not be able to generate a time stamp. In this case this attribute should contain the value "NA" for Not Available. David Burdett et al. [Page 47] Internet Draft IOTP/1.0 28 Feb 1999 3.3.2 Message Id Component The Message Id Component provides control information about the IOTP Message as well as uniquely identifying the IOTP Message within an IOTP Transaction. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the IOTP Message within the IOTP Transaction (see section 3.4 ID Attributes). Note that if an IOTP Message is resent then the value of this attribute remains the same. RespOtpMsg This contains the ID attribute of the Message Id Component of the IOTP Message to which this IOTP Message is a response. In this way all the IOTP Messages in an IOTP Transaction are unambiguously linked together. This field is required on every IOTP Message except the first IOTP Message in an IOTP Transaction. SenderTradingRoleR The Element Reference (see section 3.5) of the ef Trading Role which has generated the IOTP message. It is used to identify the Net Locations (see section 3.10) of the Trading Role to which problems Technical Errors (see section 4.1) with any of Trading Blocks should be reported. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. SoftwareId This contains information which identifies the software which generated the IOTP Message. Its purpose is to help resolve interoperability David Burdett et al. [Page 48] Internet Draft IOTP/1.0 28 Feb 1999 problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software TimeStamp Where the device sending the message has an internal clock, it is set to the time at which the IOTP Message was created in [UTC] format. 3.3.3 Related To Component The Related To Component links IOTP Transactions to either other IOTP Transactions or other events using the identifiers of those events. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Related To Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. RelationshipType Defines the type of the relationship. Valid values are: o OtpTransaction. in which case the Packaged Content Element contains an OtpTransId of another IOTP Transaction o Reference in which case the Packaged Content Element contains the reference of some other, David Burdett et al. [Page 49] Internet Draft IOTP/1.0 28 Feb 1999 non-IOTP document. Values of RelationshipType are controlled under the procedures defined in section 3.7.3 Values for IOTP Codes which also allows user defined values to be defined. Relation The Relation attribute contains a phrase in the language defined by xml:lang which describes the nature of the relationship between the IOTP transaction that contains this component and another IOTP Transaction or other event. The exact words to be used are left to the implementers of the IOTP software. The purpose of the attribute is to provide the Trading Roles involved in an IOTP Transaction with an explanation of the nature of the relationship between the transactions. Care should be taken that the words used to in the Relation attribute indicate the "direction" of the relationship correctly. For example: one transaction might be a refund for another earlier transaction. In this case the transaction which is a refund should contain in the Relation attribute words such as "refund for" rather than "refund to" or just "refund". RelnKeyWords This attribute contains keywords which could be used to help identify similar relationships, for example all refunds. It is anticipated that recommended keywords will be developed through examination of actual usage. In this version of the specification there are no specific recommendations and the keywords used are at the discretion of implementers. Content: PackagedContent The Packaged Content (see section 3.8) contains data which identifies the related transaction. Its format varies depending on the value of the RelationshipType. David Burdett et al. [Page 50] Internet Draft IOTP/1.0 28 Feb 1999 3.4 ID Attributes IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading Blocks), Trading Components (including the Transaction Id Component and the Signature Component) and some of their child elements are each given an XML "ID" attribute which is used to identify an instance of these XML elements. These identifiers are used so that one element can be referenced by another. All these attributes are given the attribute name ID. The values of each ID attribute are unique within an IOTP transaction i.e. the set of IOTP Messages which have the same globally unique Transaction ID Component. Also, once the ID attribute of an element has been assigned a value it is never changed. This means that whenever an element is copied, the value of the ID attribute remains the same. As a result it is possible to use these IDs to refer to and locate the content of any IOTP Message, Block or Component from any other IOTP Message, Block or Component in the same IOTP Transaction using Element References (see section 3.5). This section defines the rules for setting the values for the ID attributes of IOTP Messages, Blocks and Components. David Burdett et al. [Page 51] Internet Draft IOTP/1.0 28 Feb 1999 3.4.1 IOTP Message ID Attribute Definition The ID attribute of the Message Id Component of an IOTP Message must be unique within an IOTP Transaction. It's definition is as follows: OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix OtpMsgIdPrefix ::= NameChar (NameChar)* OtpMsgIdSuffix ::= Digit (Digit)* OtpMsgIdPrefix Apart from messages which contain an Inquiry Request Trading Block (see section 7.12), the same prefix is used for all messages sent by the Merchant or Consumer role as follows: o "M" - Merchant o "C" - Consumer For messages which contain an Inquiry Request Trading Block, the prefix is set to "I" for Inquiry. The prefix for the other roles in a trade is contained within the Organisation Component for the role and are typically set by the Merchant. The following is recommended as a guideline and must not be relied upon: o "P" - First (only) Payment Handler o "R" - Second Payment Handler o "D" - Delivery Handler As a guideline, prefixes should be limited to one character. NameChar has the same definition as the [XML] definition of NameChar. OtpMsgIdSuffix The suffix consists of one or more digits. The suffix must be unique within a Trading Role within an IOTP Transaction. The following is recommended as a guideline and must not be relied upon: o the first IOTP Message sent by a trading role is given the suffix "1" o the second and subsequent IOTP Messages sent by the same trading role are incremented by one for each message o no leading zeroes are included in the suffix David Burdett et al. [Page 52] Internet Draft IOTP/1.0 28 Feb 1999 Put more simply the Message Id Component of the first IOTP Message sent by a Consumer would have an ID attribute of, "C1", the second "C2", the third "C3" etc. Digit has the same definition as the [XML] definition of Digit. 3.4.2 Block and Component ID Attribute Definitions The ID Attribute of Blocks and Components must also be unique within an IOTP Transaction. Their definition is as follows: BlkOrCompId_value ::= OtpMsgId_value "." IdSuffix IdSuffix ::= Digit (Digit)* OtpMsgId_value The ID attribute of the Message ID Component of the IOTP Message where the Block or Component is first used. In IOTP, Trading Components and Trading Blocks are copied from one IOTP Message to another. The ID attribute does not change when an existing Trading Block or Component is copied to another IOTP Message. IdSuffix The suffix consists of one or more digits. The suffix must be unique within the ID attribute of the Message ID Component used to generate the ID attribute. The following is recommended as a guideline and must not be relied upon: o the first Block or Component sent by a trading role is given the suffix "1" o the ID attributes of the second and subsequent Blocks or Components are incremented by one for each new Block or Component added to an IOTP Message o no leading zeroes are included in the suffix Put more simply, the first new Block or Component added to the second IOTP Message sent, for example, by a consumer would have a an ID attribute of "C2.1", the second "C2.2", the third "C2.3" etc. David Burdett et al. [Page 53] Internet Draft IOTP/1.0 28 Feb 1999 Digit has the same definition as the [XML] definition of Digit. 3.4.3 Example of use of ID Attributes The diagram below illustrates how ID attribute values are used. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1st IOTP MESSAGE 2nd IOTP MESSAGE (e.g. from Merchant to (e.g. from Consumer to Consumer Payment Handler) IOTP MESSAGE IOTP MESSAGE * |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* | |-Trans Id Comp. ID = M1. ------------->| |-Trans Id Comp. | | Copy Element | | ID=M1.2 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * | | |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* | |-Sig Comp. ID=M1.15 ---- ------------->| |-Comp. ID=M1.15 | Copy Element | |-Trading Block. ID=M1.3 |-Trading Block. ID=C1.2 * | |-Comp. ID=M1.4 --------- ---------------->|-Comp. ID=M1.4 | | Copy Element | | |-Comp. ID=M1.5 --------- ---------------->|-Comp. ID=M1.5 | | Copy Element | | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * | |-Trading Block. ID=M1.3 |-Comp. ID=M1.4 * = new elements |-Comp. ID=M1.5 |-Comp. ID=M1.6 |-Comp. ID=M1.7 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 8 Example use of ID attributes David Burdett et al. [Page 54] Internet Draft IOTP/1.0 28 Feb 1999 3.5 Element References A Trading Component or one of its child XML elements, may contain an XML attribute that refers to another Block (i.e. a Transaction Reference Block or a Trading Block) or Trading Component (including a Transaction Id and Signature Component). These Element References are used for many purposes, a few examples include: o identifying an XML element whose Digest is included in a Signature Component, o referring to the Payment Handler Organisation Component which is used when making a Payment An Element Reference always contains the value of an ID attribute of a Block or Component. Identifying the IOTP Message, Trading Block or Trading Component which is referred to by an Element Reference, involves finding the XML element which: o belongs to the same IOTP Transaction (i.e. the Transaction Id Components of the IOTP Messages match), and o where the value of the ID attribute of the element matches the value of the Element Reference. [Note] The term "match" in this specification has the same definition as the [XML] definition of match. [Note End] An example of "matching" an Element Reference is illustrated in the example below. David Burdett et al. [Page 55] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1st IOTP MESSAGE 2nd IOTP MESSAGE (e.g. from Merchant to (e.g. from Consumer to Consumer Payment Handler) IOTP MESSAGE IOTP MESSAGE |-Trans Ref Block. ID=M1.1 Trans ID |-Trans Ref Block. ID=C1.1 | |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id Comp.ID=M1.2 | | must be | | | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 | ^ | |-Signature Block. ID=M1.8 | |-Signature Block. ID=C1.5 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 | AND | |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 | | v | | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 | | and El Ref | | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 | | match--------|--> El Ref=M1.6 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 | |-Trading Block. ID=M1.3 |-Comp. ID=M1.4 |-Comp. ID=M1.5 |-Comp. ID=M1.6 |-Comp. ID=M1.7 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 9 Element References [Note] Element Reference attributes are defined as "NMTOKEN" rather than "IDREF" (see [XML]). This is because an IDREF requires that the XML element referred to is in the same XML Document. With IOTP this is not necessarily the case. [Note End] 3.6 Brands and Brand Selection One of the key features of IOTP is the ability for a merchant to offer a list of Brands from which a consumer may make a selection. This David Burdett et al. [Page 56] Internet Draft IOTP/1.0 28 Feb 1999 section provides an overview of what is involved and provides guidance on how selection of a brand and associated payment instrument can be carried out by a Consumer. It covers: o definitions of Payment Instruments and Brands - what are Payment Instruments and Brands in an IOTP context. Further categorises Brands as optionally a "Dual Brand" or a "Promotional Brand", o identification and selection of Promotional Brands - Promotional Brands offer a Consumer some additional benefit, for example loyalty points or a discount. This means that both Consumers and Merchant must be able to correctly identify that a valid Promotional Brand is being used. Also see the following sections: o Brand List Component (section 6.6) which contains definitions of the XML elements which contain the list of Brands offered by a Merchant to a Consumer, and o Brand Selection Component (section 6.7) for details of how a Consumer records the Brand that was selected. 3.6.1 Definition of Payment Instrument A Payment Instrument is the means by which a Consumer pays for goods or services offered by a Merchant. It can be, for example: o a credit card such as MasterCard or Visa; o a debit card such as MasterCard's Maestro; o a smart card based electronic cash payment instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card o a software based electronic payment account such as a CyberCash or DigiCash account. All Payment Instruments have a number, typically an account number, by which the Payment Instrument can be identified. David Burdett et al. [Page 57] Internet Draft IOTP/1.0 28 Feb 1999 3.6.2 Definition of Brand A Brand is the mark which identifies a particular type of Payment Instrument. A list of Brands are the payment options which are presented by the Merchant to the Consumer and from which the Consumer makes a selection. Each Brand may have a different Payment Handler. Examples of Brands include: o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. o promotional brands (see below). These include: - store brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK) - cobrands, for example American Advantage Visa, where an organisation uses their own brand in conjunction with, typically, a payment association Brand. 3.6.3 Definition of Dual Brand A Dual Brand means that a single payment instrument may be used as if it were two separate Brands. For example there could be a single Japanese "UC" MasterCard which can be used as either a UC card or a regular MasterCard. The UC card Brand and the MasterCard Brand could each have their own separate Payment Handlers. This means that: o the merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer, o the consumer chooses a Brand, for example either "UC" or "MasterCard, o the consumer IOTP aware application determines which Payment Instrument(s) match the chosen Brand, and selects, perhaps with user assistance, the correct Payment Instrument to use. [Note] Dual Brands need no special treatment by the Merchant and therefore no explicit reference is made to Dual Brands in the DTD. This is because, as far as the Merchant is concerned, each Brand in a Dual Brand is treated as a separate Brand. It is at the Consumer, that the matching of a Brand to a Dual Brand Payment Instrument needs to be done. [Note End] David Burdett et al. [Page 58] Internet Draft IOTP/1.0 28 Feb 1999 3.6.4 Definition of Promotional Brand A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit which can be received in two ways: o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the consumer actually pays less, o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued. Note that: o the first example (obtaining the benefit at the time of purchase), requires that: - the Consumer is informed of the benefits which arise if that Brand is selected - if the Brand is selected, the Merchant changes the relevant IOTP Components in the Offer Response to reflect the correct amount to be paid o the second (obtaining a benefit through the Payment Instrument issuer) does not require that the Offer Response is changed o each Promotional Brand should be identified as a separate Brand in the list of Brands offered by the Merchant. For example: "Walmart", "Sears", "Marks and Spencer" and "American Advantage Visa", would each be a separate Brand. 3.6.5 Identifying Promotional Brands There are two problems which need to handled in identifying Promotional Brands: o how does the Merchant or their Payment Handler positively identify the promotional brand being used at the time of purchase o how does the Consumer reliably identify the correct promotional brand from the Brand List presented by the Merchant David Burdett et al. [Page 59] Internet Draft IOTP/1.0 28 Feb 1999 The following is a description of how this could be achieved. [Note] Please note that the approach described here is a model approach that solves the problem. Other equivalent methods may be used. [Note End] 3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands Correct identification that the Consumer is paying using a Promotional Brand is important since a Consumer might fraudulently claim to have a Promotional Brand that offers a reduced payment amount when in reality they do not. Two approaches seem possible: o use some feature of the Payment Instrument or the payment method to positively identify the Brand being used. For example, the SET certificate for the Brand could be used, if one is available, or o use the Payment Instrument (card) number to look up information about the Payment Instrument on a Payment Instrument issuer database to determine if the Payment Instrument is a promotional brand Note that: o the first assumes that SET is available. o the second is only possible if the Merchant, or alternatively the Payment Handler, has access to card issuer information. IOTP does not provide the Merchant with Payment Instrument information (e.g. a card or account number). This is only sent as part of the encapsulated payment protocol to a Payment Handler. This means that: o the Merchant would have to assume that the Payment Instrument selected was a valid Promotional Brand, or o the Payment Handler would have to check that the Payment Instrument was for the valid Promotional Brand and fail the payment if it was not. A Payment Handler checking that a brand is a valid Promotional Brand is most likely if the Payment Handler is also the Card Issuer. David Burdett et al. [Page 60] Internet Draft IOTP/1.0 28 Feb 1999 3.6.5.2 Consumer Selection of Promotional Brands Two ways by which a Consumer can correctly select a Promotional Brand are: o the Consumer visually matching a logo for the Promotional Brand which has been provided to the Consumer by the Merchant, o the Consumer's IOTP aware application matching a code for the Promotional Brand which the application has registered against a similar code contained in the list of Brands offered by the Merchant. In the latter case, the code contained in the Consumer wallet must match exactly the code in the list offered by the Merchant otherwise no match will be found. Ways in which the Consumer's IOTP Aware Application could obtain such a code include: o the Consumer types the code in directly. This is error prone and not user friendly, also the consumer needs to be provided with the code. This approach is not recommended, o using some information contained in the software or other data associated with the Payment Instrument. This could be: - a SET certificate for Brands which use this payment method - a code provided by the payment software which handles the particular payment method, this could apply to, for example, GeldKarte, Mondex, CyberCash and DigiCash o the consumer making a initial "manual" link between a Promotional Brand in the list of Brands offered by the Merchant and an individual Payment Instrument, the first time the promotional brand is used. The IOTP Aware application would then "remember" the code for the Promotional Brand for use in future purchases [Note] It is not the intention of the developers of this specification to develop a prescriptive list of payment brands. It is anticipated that owners of brands will develop distinctive names for Brands which should mean that name clashes are unlikely. [Note End] David Burdett et al. [Page 61] Internet Draft IOTP/1.0 28 Feb 1999 3.7 Extending IOTP Baseline IOTP defines a minimum protocol which systems supporting IOTP must be able to accept. As new versions of IOTP are developed, additional types of IOTP Transactions will be defined. In addition to this, Baseline and future versions of IOTP will support user extensions to IOTP through two mechanisms: o extra XML elements, and o new values for existing IOTP codes. 3.7.1 Extra XML Elements The XML element and attribute names used within IOTP constitute an [XML Namespace] as identified by the xmlns attribute on the OtpMessage element. This allows IOTP to support the inclusion of additional XML elements within IOTP messages through the use of [XML Namespaces]. Using XML Namespaces, extra XML elements may be included at any level within an IOTP message including: o new Trading Blocks o new Trading Components o new XML elements within a Trading Component. The following rules apply: o any new XML element must be declared according to the rules for [XML Namespaces] o new XML elements which are either Trading Blocks or Trading Components must contain an ID attributes with an attribute name of ID. In order to make sure that extra XML elements can be processed properly, IOTP reserves the use of a special attribute, IOTP:Critical, which takes the values True or False and may appear in extra elements added to an IOTP message. The purpose of this attribute is to allow an IOTP aware application to determine if the IOTP transaction can safely continue. Specifically: David Burdett et al. [Page 62] Internet Draft IOTP/1.0 28 Feb 1999 o if an extra XML element has an "IOTP:Critical" attribute with a value of "True" and an IOTP aware application does not know how to process the element and its child elements, then the IOTP transaction has a Technical Error (see section 4.1) and must fail. o if an extra XML element has an "IOTP:Critical" attribute with a value of "False" then the IOTP transaction may continue if the IOTP aware application does not know how to process it. In this case: - any extra XML elements contained within an XML element defined within the IOTP namespace, must be included with that element whenever the IOTP XML element is used or copied by IOTP - the content of the extra element must be ignored except that it must be included when it is used in the creation of a digest as part of the generation of a signature o if an extra XML element has no "IOTP:Critical" attribute then it must be treated as if it had an "IOTP:Critical" attribute with a value of "True" o if an XML element contains an "IOTP:Critical" attribute, then the value of that attribute is assumed to apply to all the child elements within that element In order to ensure that documents containing "IOTP:Critical" are valid, it is declared as part of the DTD for the extra element as: IOTP:Critical (True | False ) #TRUE 3.7.2 Opaque Embedded Data If IOTP is to be extended using Opaque Embedded Data then a Packaged Content Element (see section 3.8) should be used to encapsulate the data. 3.7.3 Values for IOTP Codes Codes used by IOTP are registered by [IANA] so that new values can be co-ordinated based on an IETF consensus as defined in RFC 2434. The element types, attributes names to which this procedure applies is shown in the table below together with the original values for attributes which apply. For more up-to-date information on valid David Burdett et al. [Page 63] Internet Draft IOTP/1.0 28 Feb 1999 values and how these relate to versions of the IOTP specification contact IANA. Element Type Attribute Attribute Values Name AuthData AuthMethod sha1 signature pay:ppp where ppp may be set to any valid value for iotpbrand (see below) Brand BrandId SET:setbrand where setbrand is a brand which is accepted by the [SET] payment protocol IOTP:iotpbrand where iotpbrand may be: o GeldKarte o Mondex CurrencyAmount CurrCode TBD. Codes which apply when the CurrCodeType attribute is set to IOTP are to be defined CurrencyAmount CurrCodeType ISO4217 IOTP DeliveryData DelivMethod Post Web Email PackagedContent Content PCDATA MIME MIME:mimetype (where mimetype must be the same as content-type as defined by [MIME] ) XML PayProtocol ProtocolId The values of ProtocolId are to be defined by the payment scheme/method David Burdett et al. [Page 64] Internet Draft IOTP/1.0 28 Feb 1999 owners. RelatedTo Relationship OtpTransaction Type Reference Status StatusType Offer Payment Delivery Authentication TradingRole TradingRole Consumer Merchant PaymentHandler DeliveryHandler DelivTo CustCare TransId OtpTransType BaselineAuthentication BaselineDeposit BaselinePurchase BaselineRefund BaselineWithdrawal BaselineValueExchange BaselineInquiry BaselinePing Attibute Content OfferResponse (within Signature PaymentResponse Component) DeliveryResponse David Burdett et al. [Page 65] Internet Draft IOTP/1.0 28 Feb 1999 AuthenticationRequest AuthenticationResponse PingRequest PingResponse However there is still a need for developers to experiment using new IOTP codes. For this reason, "user defined codes" may be used to identify additional values for the codes contained within this specification with the need for them to be registered with IANA. The definition of a user defined code is as follows: user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)* NameChar NameChar has the same definition as the [XML] definition of NameChar Use of domain names (see [DNS]) to make user defined codes unique is recommended although this method cannot be relied upon. 3.8 Packaged Content Element The Packaged Content element supports the concept of an embedded data stream, transformed to both protect it against misinterpretation by transporting systems and to ensure XML compatibility. Examples of its use in IOTP include: o to encapsulate payment scheme messages, such as SET messages, o to encapsulate a description of an order, a payment note, or a delivery note. In general it is used to encapsulate one or more data streams. This data stream has three standardised attributes that allow for identification, decoding and interpretation of the contents. Its definition is as follows. David Burdett et al. [Page 66] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: Name Optional. Distinguishes between multiple occurrences of Packaged Content Elements at the same point in IOTP. For example: snroasdfnas934k dvdsjnl5poidsdsflkjnw45 The name attribute may be omitted, for example if there is only one Packaged Content element. Content This identifies what type of data is contained within the Content of the Packaged Content Element. The valid values for the Content attribute are as follows: o PCDATA. The content of the Packaged Content Element can be treated as PCDATA with no further processing. o MIME. The content of the Packaged Content Element is a complete MIME item. Processing should include looking for MIME headers inside the Packaged Content Element. o MIME:mimetype. The content of the Packaged Content Element is MIME content, with the following header "Content-Type: mimetype". Although it is possible to have MIME:mimetype with the Transform attribute set to NONE, it is far more likely to have Transform attribute set to BASE64. Note that if Transform is NONE is used, then the entire content must still conform to PCDATA. Some characters will need to be encoded either as the XML default entities, or as numeric character entities. o XML. The content of the Packaged Content David Burdett et al. [Page 67] Internet Draft IOTP/1.0 28 Feb 1999 Element can be treated as an XML document. Entities and CDATA sections, or Transform set to BASE64, must be used to ensure that the Packaged Content Element contents are legitimate PCDATA. Values of the Content attribute are controlled under the procedures defined in section 3.7.3 Values for IOTP Codes which also allows user defined values to be defined. Transform This identifies the transformation that has been done to the data before it was placed in the content. Valid values are: o NONE. The PCDATA content of the Packaged Content Element is the correct representation of the data. Note that entity expansion must occur first (i.e. replacement of & and ) before the data is examined. CDATA sections may legitimately occur in a Packaged Content Element where the Transform attribute is set to NONE. o BASE64. The PCDATA content of the Packaged Content Element represents a BASE64 encoding of the actual content. Content: PCDATA This is the actual data which has been embedded. The format of the data and rules on how to decode it are contained in the Content and the Transform attributes Note that any special details, especially custom attributes, must be represented at a higher level. 3.8.1 Packaging HTML The packaged content may contain HTML. In this case the following conventions are followed: o references to any documents, images or other things, such as sounds or web pages, which can affect the recipient's understanding of the data which is being packaged must refer to other Packaged Elements contained within the same parent element, e.g. an Order Description David Burdett et al. [Page 68] Internet Draft IOTP/1.0 28 Feb 1999 o if more than one Packaged Content element is included within a parent element in order to meet the previous requirement, then the Name attribute of the top level Packaged Content from which references to all other Packaged Elements can be determined, should have a value of Main. This means that the "Main" Packaged Content element must not be referred to from the HTML in any other Packaged Content o relative references to other documents, images, etc. from one Packaged Content element to another are realised by setting the value of the relative reference to the Name attribute of another Packaged Content element at the same level and within the same parent element o no external references that require the reference to be resolved immediately should be used. As this could make the HTML difficult or impossible to display completely o [MIME] is used to encapsulate the data inside each Packaged Element. This means that the information in the MIME header used to identify the type of data which has been encapsulated and therefore how it should be displayed. If the above conventions are not followed by, for example, including external references which must be resolved, then the recipient of the HTML should be informed. [Note] As an implementation guideline the values of the Name Attributes allocated to Packaged Content elements should make it possible to extract each Packaged Content into a directory and then display the HTML directly [Note End] 3.9 Identifying Languages IOTP uses [XML] Language Identification to specify which languages are used within the content and attributes of IOTP Messages. The following principles have been used in order to determine which XML elements contain an xml:lang Attributes: o a mandatory xml:lang attribute is contained on every Trading Component which contains attributes or content which may need to be displayed or printed in a particular language David Burdett et al. [Page 69] Internet Draft IOTP/1.0 28 Feb 1999 o an optional xml:lang attribute is included on child elements of these Trading Components. In this case the value of xml:lang, if present, overrides the value for the Trading Component. xml:lang attributes which follow these principles are included in the Trading Components and their child XML elements defined in section 6. 3.10 Secure and Insecure Net Locations IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types: o "Secure" Net Locations which are net locations where privacy of data is secured using, for example, encryption methods such as [SSL], and o "Insecure" Net Locations where privacy of data is not assured. Where both types of net location are present, the following rules apply: o either a Secure Net Location or an Insecure Net Location or both must be present o if only one of the two Net Locations is present, then the one present must be used o if both are present, then the either may be used depending on the preference of the sender of the message. 3.11 Cancelled Transactions Any Trading Role involved in an IOTP transaction may cancel that transaction at any time. 3.11.1 Cancelling Transactions IOTP Transactions are cancelled by sending an IOTP message containing just a Cancel Block with an appropriate Status Component to the other Trading Role involved in the Trading Exchange. David Burdett et al. [Page 70] Internet Draft IOTP/1.0 28 Feb 1999 [Note] The Cancel Block can be sent asynchronously of any other IOTP Message. Specifically it can be sent either before sending or after receiving an IOTP Message from the other Trading Role [Note End] If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the interval between sending a _request_ block and receiving the matching _response_ block) then the Cancel Block is sent to the same location as the next IOTP Message in the Trading Exchange would have been sent. If a Consumer cancels a transaction after a Trading Exchange has completed (i.e. the "response" block for the Trading Exchange has been received), but before the IOTP Transaction has finished then the Consumer sends a Cancel Block with an appropriate Status Component to the net location identified by the SenderNetLocn or SecureSenderNetLocn contained in the Protocol Options Component contained in the TPO Block for the transaction. This is normally the Merchant Trading Role. A Consumer should not send a Cancel Block after the IOTP Transaction. Cancelling a complete should be treated as a technical error. After cancelling the IOTP Transaction, the Consumer should go to the net location specified by the CancelNetLocn attribute contained in the Trading Role Element for the organisation that was sent the Cancel Block. A non-Consumer Trading Role should only cancel a transaction: o after a request block has been received and o before the response block has been sent If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient is an error. 3.11.2 Handling Cancelled Transactions If a Cancel Block is received by a Consumer at a point in the IOTP Transaction when cancellation is allowed, then the Consumer should stop the transaction. If a Cancel Block is received by a non-Consumer role, then the Trading Role should anticipate that the Consumer may go to the location David Burdett et al. [Page 71] Internet Draft IOTP/1.0 28 Feb 1999 specified by the CancelNetLocn attribute contained in the Trading Role Element for the Trading Role. David Burdett et al. [Page 72] Internet Draft IOTP/1.0 28 Feb 1999 4. IOTP Error Handling IOTP is designed as a request/response protocol where each message is composed of a number of Trading Blocks which contain a number of Trading Components. There are a several interrelated considerations in handling errors, re-transmissions, duplicates, and the like. These factors mean IOTP aware applications must manage message flows more complex than the simple request/response model. Also a wide variety of errors can occur in messages as well as at the transport level or in Trading Blocks or Components. This section describes at a high level how IOTP handles errors, retries and idempotency. It covers: o the different types of errors which can occur. This is divided into: - "technical errors" which are independent of the meaning of the IOTP Message, - "business errors" which indicate that there is a problem specific to the process (e.g. payment or delivery) which is being carried out, and o the depth of the error which indicates whether the error is at the transport, message or block/component level o how the different trading roles should handle the different types of messages which they may receive. 4.1 Technical Errors Technical Errors are those which are independent of the meaning of the message. This means, they can affect any attempt at IOTP communication. Typically they are handled in a standard fashion with a limited number of standard options for the user. Specifically these are: o retrying the transmission, or o cancelling the transaction. When communications are operating sufficiently well, a technical error is indicated by an Error Component (see section 0) in an Error Block David Burdett et al. [Page 73] Internet Draft IOTP/1.0 28 Feb 1999 (see section 7.17) sent by the party which detected the error in an IOTP message to the party which sent the erroneous message. If communications are too poor, a message which was sent may not reach its destination. In this case a time-out might occur. The Error Codes associated with Technical Errors are recorded in Error Components 6.19) which lists all the different technical errors which can be set. 4.2 Business Errors Business Errors may occur when the IOTP messages are "technically" correct. They are connected with a particular process, for example, an offer, payment, delivery or authentication, where each process has a different set of possible business errors. For example, "Insufficient funds" is a reasonable payment error but makes no sense for a delivery while "Back ordered" is a reasonable delivery error but not meaningful for a payment. Business errors are indicated in the Status Component (see section 6.14) of a "response block" of the appropriate type, for example a Payment Response Block or a Delivery Response Block. This allows whatever additional response related information is needed to accompany the error indication. Business errors must usually be presented to the user so that they can decide what to do next. For example, if the error is insufficient funds in a Brand Independent Offer (see section 8.1.2.2), the user might wish to choose a different payment instrument/account of the same brand or a different brand or payment system. Alternatively, if the IOTP based implementation allows it and it makes sense for that instrument, the user might want to put more funds into the instrument/account and try again. 4.3 Error Depth The three levels at which IOTP errors can occur are the transport level, the message level, and the block level. Each is described below. David Burdett et al. [Page 74] Internet Draft IOTP/1.0 28 Feb 1999 4.3.1 Transport Level This level of error indicates a fundamental problem in the transport mechanism over which the IOTP communication is taking place. All transport level errors are technical errors and are indicated by either an explicit transport level error indication, such as a "No route to destination" error from TCP/IP, or by a time out where no response has been received to a request. The only reasonable automatic action when faced with transport level errors is to retry and, after some number of automatic retries, to inform the user. The explicit error indications that can be received are transport dependent and the documentation for appropriate IOTP Transport supplement should be consulted for errors and appropriate actions. Appropriate time outs to use are a function of both the transport being used and of the payment system if the request encapsulates payment information. The transport and payment system specific documentation should be consulted for time out and automatic retry parameters. Frequently there is no way to directly inform the other party of transport level errors but they should generally be logged and if automatic recovery is unsuccessful and there is a human user, the user should be informed. 4.3.2 Message Level This level of error indicates a fundamental technical problem with an entire IOTP message. For example, the XML is not _Well Formed_, or the message is too large for the receiver to handle or there are errors in the Transaction Reference Block (see section 3.3) so it is not possible to figure out what transaction the message relates to. All message level errors are technical errors and are indicated by an Error Components (see section 6.19) sent to the other party. The Error Component includes a Severity attribute which indicates whether the error is a Warning and may be ignored, a TransientError which indicates that a retry may resolve the problem or a HardError in which case the transaction must fail. The Technical Errors (see section 6.19.2 Error Codes) that are Message Level errors are: David Burdett et al. [Page 75] Internet Draft IOTP/1.0 28 Feb 1999 o XML not well formed. The document is not well formed XML (see [XML]) o XML not valid. The document is not valid XML (see [XML]) o block level technical errors (see section 4.3.3) on the Transaction Reference Block (see section 3.3) and the Signature Block only. Checks on these blocks should only be carried out if the XML is valid Note that checks on the Signature Block includes checking, where possible, that each Signature Component is correctly calculated. If the Digital Signature Element is incorrectly calculated then the data that should have been covered by the signature can not be trusted and must be treated as erroneous. A description of how to check a signature is correctly calculated is contained in section 5.2 Checking a Signature is Correctly Calculated. 4.3.3 Block Level A Block level error indicates a problem with a block or one of its components in an IOTP message (apart from Transaction Reference or Signature Blocks). The message has been transported properly, the overall message structure and the block/component(s) including the Transaction Reference and Signature Blocks are meaningful but there is some error related to one of the other blocks. Block level errors can be either: o technical errors, or o business errors Technical Errors are further divided into: o Block Level Attribute and Element Checks, and o Block and Component Consistency Checks If a technical error occurs related to a block or component, then an Error Component is returned and, unless it is merely a warning, the usual response block is suppressed. David Burdett et al. [Page 76] Internet Draft IOTP/1.0 28 Feb 1999 4.3.3.1 Block Level Attribute and Element Checks Block Level Attribute and Element Checks occur only within the same block. Checks which involve cross-checking against other blocks are covered by Block and Component Consistency Checks. The Block Level Attribute & Element checks are: o checking that each attribute value within each element in a block conforms to any rules contained within this IOTP specification o checking that the content of each element conforms to any rules contained within this IOTP specification o if the previous checks are OK, then checking the consistency of attribute values and element content against other attribute values or element content within any other components in the same block. 4.3.3.2 Block and Component Consistency Checks Block and Component Consistency Checks consist of: o checking that the combination of blocks and/or components present in the IOTP Message are consistent with the rules contained within this IOTP specification o checking for consistency between attributes and element content within the blocks within the same IOTP message. o checking for consistency between attributes and elements in blocks in this IOTP message and blocks received in earlier IOTP messages for the same IOTP transaction 4.3.3.3 Block Business Errors If a business error occurs in a process such as a Payment or a Delivery, then the appropriate type of response block is returned. The Status Component (see section 6.14) within that response block indicates the error and its severity. No Error Component or Error Block is generated for business errors. David Burdett et al. [Page 77] Internet Draft IOTP/1.0 28 Feb 1999 4.4 Idempotency, Processing Sequence, and Message Flow IOTP messages are actually a combination of blocks and components as described in 3.1.1 IOTP Message Structure. Especially in future extensions of IOTP, a rich variety of combinations of such blocks and components can occur. It is important that the multiple transmission/receipt of the "same" request for state changing action not result in that action occurring more than once. This is called idempotency. For example, a customer paying for an order would want to pay the full amount only once. Most network transport mechanisms have some probability of delivering a message more than once or not at all, perhaps requiring retransmission. On the other hand, a request for status can reasonably be repeated and should be processed fresh each time it is received. Correct implementation of IOTP can be modelled by a particular processing order as detailed below. Any other method that is indistinguishable in the messages sent between the parties is equally acceptable. 4.4.1 Server Role Processing Sequence "Server roles" are any Trading Role which is not the Consumer role. They are "Server roles" since they typically receive a request which they must service and then produce a response. David Burdett et al. [Page 78] Internet Draft IOTP/1.0 28 Feb 1999 The model processing sequence for a Server role is indicated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* ------------- | Input | | IOTP Message| ------------- | v 1. Check for transport --------------> or message level errors Errors | |OK | v | 11. Generate output <-------2. More Blocks <----------------- + - message No to process? | | | |Yes | | v v | | ------------- 3. Check Block OK ---------------> | | | Output | | Errors | | | IOTP Message| |Checks OK | | ------------- v | | ---------4. Type of Block ? ------- | | | | | | | | ---------Status Action Encapsulating Error | | | Request Request Block Block | | | | | | | | | v v v | | | 6a. Action 7. Process 8.Error | | | Request - encapsulated Block ? | | | received message and | | | | before?-- generate -- v | | | | | response | STOP --- | | |Yes |No OK| | | | | v v | |Errors v | | 6b. Processing 6e. Process Action | ------> 9. Gen | | of Block Request & generate-+--------->Error | | Complete ?- response block- | Errors Block & | | | | ^ | | store | | | | | | | | | | |Yes |No | Ok or | | | | | | --- | Warning | -------- | | v v v | v | | | 5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | | Status and resend process request & | | | Response previous completion response | | | David Burdett et al. [Page 79] Internet Draft IOTP/1.0 28 Feb 1999 Block Block block | | | | | | v v | ---------------------------------------------- 10. Add block-- to output message *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 10 Server Role Processing Sequence Each of the processes in the sequence is described in more detail below. 4.4.1.1 Check for Transport or Message Level Error On receipt of an IOTP request message (step 1), first check for transport or message level errors (see sections 4.3.1 and 4.3.2). These are errors which indicate that the entire message is corrupt and can not reliably be associated with any particular transaction or, if it can be associated with a transaction, the interior information in the message can not be reliably accessed. If the OtpTransId attribute in the Transaction Id Component (see section 3.3.1) can be determined, set up a response message with an appropriate Error Component. Perform local actions such as making log entries. If the value of the OtpTransId attribute is not recognised as belonging to an IOTP transaction when other Blocks in the IOTP Message indicate that it should be recognised, then report the error using an Error Component with a Severity of HardError, an ErrorCode set to AttValNotRecog (attribute value not recognised), and an Error Location element (see section 6.19.3) that points to the OtpTransId attribute. No idempotency related actions are necessary. 4.4.1.2 Process all the blocks If there are no message level errors, process each of the blocks within the message which has not been processed (step 2). Once all the blocks have been processed, generate a response message (step 11) and send it to the requester unless there are fatal transport level problems. As recommended for the particular transport used, a limited number of automatic response retransmission attempts may be appropriate. David Burdett et al. [Page 80] Internet Draft IOTP/1.0 28 Feb 1999 It may be desirable to log the complete response message at the server. Failure of the requester to receive a response may lead to a time-out and a retransmission of the request. Following the procedures above, a duplicate request message should produce a duplicate of the previous response except for changes in status and transient error conditions that have changed. 4.4.1.3 Check the Block is OK Check the block is OK (see section 4.3.3). For each block level technical error found, an appropriate Error Component should be created to be included in the IOTP Message sent back to the Consumer. Note that some checking of the Transaction Reference Block and the Signature Block has occurred as part of Message Level error checking. If one or more of the Error Components contain a Severity attribute with a value of TransientError or HardError, then no response block need be generated and no further processing of the block, including idempotency related actions are necessary. 4.4.1.4 Determine the Type of the Block Trading Blocks that survive the above steps and thus have no errors, or at worst have added a warning error component to the response, can receive further processing. The nature of the processing depends (step 4) on whether the block is a Status Request, Action Request, an Error Block or contains an Encapsulated Message. 4.4.1.5 Status Request Blocks Status Request Blocks (step 5) are either: o Inquiry Request Trading Block (see section 7.12), or o Ping Request Block (see section 7.14). These status requests do not change state and are processed fresh to get the current status. The appropriate response block should be added to the IOTP message being composed. No idempotency actions are required. 4.4.1.6 Action Request Blocks Blocks which request an action and change state need to be subject to idempotency duplicate filtering by checking to see if the same block David Burdett et al. [Page 81] Internet Draft IOTP/1.0 28 Feb 1999 for the same transaction has been previously stored (step 6a) at the server as described later. If the Block has been received previously then: o if processing of the previously stored block is complete (step 6b) then the same IOTP Block as previously produced must be included for resending to the Consumer (step 6c). o if processing is not complete, wait until the processing is complete (step 6d) before sending the response. If the block has not been received before, the action request is processed normally (step 6e) producing a response block that is added to the response message. This might or might not indicate a business error. If there is a transient error indicated by an Error Component that contains a Severity attribute set to TransientError, then apart from sending the Error Block, no further actions should be taken so the action can be retried. If there is no Transient Error, then the transaction id, the request block, and the response block must be stored (step 6f) so they can be found as described above (step 6a) should a duplicate IOTP action request block be received for this transaction in the future. [Note] Most business errors should be labelled as a TransientError as there is usually some possibility they will be corrected over time or some user action exists that can fix them. Requesters are expected to understand business errors and the appropriate time scale for user actions for retrying. [Note End] 4.4.1.7 Encapsulating Blocks Blocks which encapsulate a payment protocol (step 7) pass along the enclosed information to the payment system involved. IOTP does not know the meaning of the enclosed information. It is thus up to the payment system involved to handle error detection and idempotency. Payment systems adapted for the Internet include idempotency handling because duplicates are always possible. Should a payment system have no idempotency handling, a layer between IOTP and the payment system must be added to take care of this. David Burdett et al. [Page 82] Internet Draft IOTP/1.0 28 Feb 1999 No IOTP level idempotency actions are required for encapsulating blocks. The payment system must return material to be encapsulated in the IOTP response message along with indications as to whether the exchange will continue or this is the final response and an indication whether an error occurred. If a payment protocol error has occurred, an Error Component is added to the response block. 4.4.1.8 Error Block Received An error block (step 8) should not occur in a request block and should be treated as an unexpected element with a Severity of HardError. Error Blocks are sent by Consumers to potentially two locations: o the _request_ location, i.e. the location from which they received the IOTP message that contained the error, and o optionally, the ErrorLogNetLocn which may be a separate location maintained for the purpose of logging errors The ErrorLogNetLocn block may be the same location as the _request_ location. In this case, the error block must not considered as a fatal error. In order to avoid loops, no Error Block should be sent to the Consumer in response to an IOTP Message received from a Consumer where the IOTP message contains an Error Block with a severity of HardError. 4.4.1.9 Generate Error Block If any of the previous steps resulted in an error being detected and an Error Component being created then generate an Error Block (step 9) containing the Error Components that describe the error(s). Unless the error is a "Transient Error", the Error Component(s) and the request block which caused the Error Components to be generated should be stored so that it can be reused if the action request is received again (step 6a). "Transient Errors" are not stored so that if the original Response Block is received again, then it can be processed as if it had never been received before. 4.4.1.10 Add Block to Output Message Any Blocks which have been created as a result of processing the block received are added to the output message. David Burdett et al. [Page 83] Internet Draft IOTP/1.0 28 Feb 1999 4.4.2 Client Role Processing Sequence The "Client role" in IOTP is the Consumer Trading Role. [Note] A company or organisation that is a Merchant, for example, may take on the Trading Role of a Consumer when making a purchase or downloading or withdrawing electronic cash. [Note End] David Burdett et al. [Page 84] Internet Draft IOTP/1.0 28 Feb 1999 The model processing sequence for a Client role is indicted in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* ------------- | Input | | IOTP Message| ------------- | v 1. Check for transport --> or message level errors |Errors |OK | v | 11.Blocks to be sent?<---------2. More Blocks <-- ------------------ | |No No to process? | ^ Yes| v |Yes | | v STOP v | | 12. Generate 3. Check Block OK - -->| | output message | |Errors | | |Checks OK | | v v | | ------------- ------ 4. Type of Block ? -----| | | Output | | | | | | | | IOTP Message| | ---- | | | | ------------- | | | | | | ------------ | | | | | | -- | | | | v v v v | | Status Action Encapsulating Error | | Request Response Block Block | | | | | | | | | v v v | | | 6a. Action 7. Process 8a.Error Block---- > Transient | | Response encapsulated severity ? | Error | | received message |Hard Error | (retry) | | before ? | | | | | | | Yes| |No Ok| | v | WAIT | | (Ig-| | | | STOP | | | | nore|) v | | v v | | | 6b. Process | -------> 9. Generate 8b. | | | Action | Errors Error Block Retrieve | | | Response --+----------> & store and resend | | | Block | Errors | previous | | | |Ok | | Block(s) | | | v v | | | David Burdett et al. [Page 85] Internet Draft IOTP/1.0 28 Feb 1999 | | 6c. New | | | | | request | | | | | required ? | | | | | No| |Yes 6d. Generate | | | | | | ---- > Request | | | | | | Block & Store v v | v | | | 10. Add Block to | ----------+-------+------------------------> output message | v v | ---------------------------------------------------> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 11 Client Role Processing Sequence Each of the processes in the sequence is described in more detail below. 4.4.2.1 Check for Transport or Message Level Error On receipt of an IOTP response message (step 1), first check for transport or message level errors (see sections 4.3.1 and 4.3.2). These are errors which indicate that the entire message is corrupt and can not reliably be associated with any particular transaction or, if it can be associated with a transaction, the interior information in the message can not be reliably accessed. Set up an error indication message with an Error Component indicating the error. If the value of the OtpTransId attribute is not recognised as belonging to an IOTP transaction when other Blocks in the IOTP Message indicate that it should be recognised, then report the error using an Error Component with a Severity of HardError, an ErrorCode set to AttValNotRecog (attribute value not recognised), and an Error Location element (see section 6.19.3) that points to the OtpTransId attribute. On failure to receive an expected response message, the time out strategy indicated in the documentation for the transport method being used should be followed. This may include some number of automatic re- transmissions of the request. If a user is present, they may be offered options of continuing to retransmit the request or of cancelling the transaction. 4.4.2.2 Process all the blocks If there are no transport or message level errors, process each of the blocks within the message which has not been processed (step 2). David Burdett et al. [Page 86] Internet Draft IOTP/1.0 28 Feb 1999 Once all the blocks have been processed, check to see if there are any blocks to be sent (step 11). There may be no blocks to send if the last response message received was the last message of the transaction. If blocks are to be sent then generate a request message (step 12) and send it to the server. It may be desirable to log the complete request message at the client. Failure of the server to receive a response may lead to a time-out and a retransmission of the request. 4.4.2.3 Check the Block is OK If there are no message level errors process each of the blocks within the message (step 2). Check the block is OK (see section 4.3.3). For each block level error found, an appropriate Error Component should be created to be included in an Error Component sent back to the Server. If one or more of the Error Components contain a Severity attribute with a value of TransientError or HardError, no further processing of the block should occur and it is likely that this will result in termination of the transaction. 4.4.2.4 Determine the Type of the Block Trading Blocks that survive the above steps and thus have no errors, or at worst have added a warning error component to the error indication message, can receive further processing. The nature of the processing depends (step 4) on whether the block is a Status Response, Action Response, an Error Block or contains an Encapsulated Message. 4.4.2.5 Status Response Blocks Status Response Blocks (step 4) are either: o Inquiry Response Trading Blocks (see section 7.13), or o Ping Response Blocks (see section 7.15) In general, such blocks should be considered a status update. The best action to take at the requester may depend on whether this is in response to a user originated or automatic status request, whether a status display that could be updated is being presented to the user, and whether the status response block shows a change in status from a previous response block for the same type of status. Thus client David Burdett et al. [Page 87] Internet Draft IOTP/1.0 28 Feb 1999 detection of duplication in successive status response blocks may be useful. 4.4.2.6 Action Response Blocks Check to determine if the Block has been received previously (step 6a). If it has then it should be ignored. These indicate an action taken at the server in response to an action request block or a business error. If the response indicates success the block should be processed (step 6b) and, if required by the transaction (step 6c), another Action Request Block generated and stored (step 6d). The Response Block should always be stored with the transaction id until the transaction is terminated. If the Response Block indicates a transient business error, appropriate manually chosen or automatic steps to fix the problem or cancel the transaction should be provided. 4.4.2.7 Encapsulating Blocks Blocks which encapsulate a payment protocol (step 7) pass along the enclosed information to the payment system involved. IOTP does not know the meaning of the enclosed information. It is up to the payment system involved to handle error detection and idempotency. Payment systems adapted for the Internet include idempotency handling because duplicates are always possible. Should a payment system have no idempotency handling, a layer between IOTP and the payment system must be added to take care of this. No IOTP level idempotency actions are required for encapsulating blocks. The payment system must return an indication of whether an error occurred. In addition, for a continuing exchange, it must return material to be encapsulated in the next IOTP request/exchange (step 6d). If the response was a final response for that payment exchange and there was an error, the payment system may optionally return material to be encapsulated in the error indication. 4.4.2.8 Error Block An error block in a response (step 8a) indicates some problem was detected by the server. If all of the error components are warnings, they may be optionally logged and/or presented to the user. Transient errors may be used to provide a manual or automatic resending (step 8b) of a block previously stored or alternatively may David Burdett et al. [Page 88] Internet Draft IOTP/1.0 28 Feb 1999 result in transaction cancellation. Hard errors will always terminate the transaction, unless they are in optional blocks, with appropriate indication to he user. 4.4.2.9 Generate Error Block If an error indication message was created above, try to send it to the unless all of the error components are of the warning severity in which case attempted transmission to the server is optional. The net locations consumers send Error Blocks to are: o the net location which sent them the IOTP Message which was in error, this is either: - the location specified by the SenderNetLocn or SecureSenderNetLocn attribute of the Protocol Options Component if the problem was contained in the TPO Block or the Offer Response Block - the location to which the Payment Request Block was sent if the problem is in either a Payment Exchange or a Payment Response Block, or - the location to which the Delivery request Block if the problems in a Delivery Response Block, and o if present, the server identified by the ErrorLogNetLocn attribute of the Trading Role element identified by the SenderTradingRoleRef the Message Id Component. 4.4.2.10 Add Block to Output Message Any Blocks which have been created as a result of processing the block received are added to the output message. David Burdett et al. [Page 89] Internet Draft IOTP/1.0 28 Feb 1999 5. Security Considerations This section considers the security associated with IOTP. It covers: o an overview of how IOTP uses digital signatures o how to check a signature is correctly calculated o how Payment Handlers and Delivery Handlers check they can carry out payments or deliveries on behalf of a Merchant. o how IOTP handles data integrity and privacy 5.1 Digital Signatures and IOTP In general, signatures when used with IOTP: o are always treated as a IOTP Components (see section 6) o contain digests of one or more IOTP Components or Trading Blocks, possibly including other Signature Components, in any IOTP message within the same IOTP Transaction o identify: - which Organisation signed (originated) the signature, and - which Organisation(s) should be the receive the signature in order to check that the Action the Organisation should take can occur. The way in which Signatures Components digest one or more elements is illustrated in the figure below. David Burdett et al. [Page 90] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* IOTP MESSAGE SIGNATURE COMPONENT IOTP MESSAGE Signature Id = P1.3 |-Trans Ref Block digest TransRefBlk |-Manifest | | ID=P1.1-----------------------------|->|-Digest of P1.1-- | |-Trans Id Comp digest TransIdComp | | | | | ID = M1.2----------------------------|->|-Digest of M1.2--| | |-Msg Id Comp. digest Signature | | | | | ID = P1 -------------------|->|-Digest of M1.5--| | | digest element | | | |-IOTPSignatures Block | -----------------|->|-Digest of M1.7--| | | ID=P1.2 | | digest element | | | | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| | |-Signature ID=M1.5---- | | | | | |-Signature ID=P1.4 | | Points to |-RecipientInfo* | | |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6 | | | | | Certs to use | SignatureValueRef| | | | | | Points|to Value El| | | | | | v | |-Trading Block. ID=P1.5 | | -Value* ID=P1.4: | | |-Comp. ID=M1.7---------- | JtvwpMdmSfMbhK<--| | | | r1Ln3vovbMQttbBI | | |-Comp. ID=P1.6 | J8pxLjoSRfe1o6k| | | | OGG7nTFzTi+/0<- | |-Comp. ID=C1.4------------ | |-Comp. ID=C1.5 Digital signature of- SignedData element using certificate identified by CertRef Elements that are digested can be in any IOTP Message within the same IOTP Transaction *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 12 Signature Digests [Note] The classic example of one signature signing another in IOTP, is when an Offer is first signed by a Merchant creating an "Offer Response" signature, which is then later signed by a Payment Handler together with a record of the payment creating a "Payment Receipt" signature. In this way, the payment in an IOTP Transaction is bound to the Merchant's offer. David Burdett et al. [Page 91] Internet Draft IOTP/1.0 28 Feb 1999 [Note End] Note that one Manifest may be associated with multiple signature "Value" elements where each Value element contains a digital signature over the same manifest, perhaps using the same (or different) signature algorithm but using a different certificate This may be used to allow each potential recipient of a signature to use different certificates. Specifically it will allow the Merchant to agreed different shared secrets with their Payment Handler and Delivery Handler. The detailed definitions of a Signature component is contained in section 6.17. The remainder of this section contains: o an example of how IOTP uses signatures o how the OriginatorInfo and RecipientInfo elements within a Signature Component are used to identify the organisations associated with the signature o how signatures may use either Symmetric or Asymmetric Cryptography o Mandatory and Optional use of Signatures by IOTP, and o how IOTP uses signatures to prove actions complete successfully 5.1.1 IOTP Signature Example An example of how signatures are used is illustrated in the figure below which shows how the various components and elements in a Baseline Purchase relate to one another. Refer to this example in the later description of how signatures are used to check a payment or delivery can occur (see section 5.3). [Note] A Baseline Purchase transaction has been used for illustration purposes. The usage of the elements and attributes is the same for all types of IOTP Transactions. [Note End] David Burdett et al. [Page 92] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK (Offer Response) Brand Selection Organisation<--- Signature Component Component | Component | | | | |BrandList -Trading Role | | | Ref Element | Originator |-Originator v (Merchant) ------------|--Info Brand List Ref | >Component | | |-Protocol ------> Organisation Recipient |-Recipient | | Amount Elem | Component <------------------|--Info | | | | | Refs | | | Pa|Protocol |Action -Trading Role | | | | Ref |OrgRef Element | | | v | (Payment Handler) | | -PayProtocol-- | | Elem ->Organisation Recipient |-Recipient | | Component <-----------------|--Info | | | Refs | | | -Trading Role | | | Element | | | (Delivery Handler) -Manifest | | ^ | OFFER RESPONSE BLOCK | | | Contains digests of:-- |BrandListRef |ActionOrgRef -Trans Ref Block (not | | shown) --Payment ---Delivery -Transaction Id Component Component Component (not shown) -Org Components (Merchant, Payment Handler, Delivery Handler -Brand List Component -Order Component -Payment Component -Delivery Component -Brand Selection Component (if Brand Dependent) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 13 Example use of Signatures for Baseline Purchase David Burdett et al. [Page 93] Internet Draft IOTP/1.0 28 Feb 1999 5.1.2 OriginatorInfo and RecipientInfo Elements The OriginatorRef attribute of the OriginatorInfo element in the Signature Component contains an Element Reference (see section 3.5) that points to the Organisation Component of the Organisation which generated the Signature. In this example its the Merchant. Note that the value of the content of the Attribute element with a type attribute set to IOTPSignatureType must match the Trading Role of the Organisation which signed it. If it does not, then it is an error. Valid combinations are given in the table below. IOTP Signature Type Valid Trading Role OfferResponse Merchant PaymentResponse PaymentHandler DeliveryResponse DeliveryHandler AuthenticationRequest any role AuthenticationResponse any role PingRequest any role PingResponse any role The RecipientRef attribute of the RecipientInfo element in the Signature Component contains Element References to the Organisation Components of the Organisations that should use the signature to verify that: o they have a pre-existing relationship with the Organisation that generated the signature, o the data which is secured by the signature has not been changed, o the data has been signed correctly, and o the action they are required to undertake on behalf of the Merchant is therefore authorised. David Burdett et al. [Page 94] Internet Draft IOTP/1.0 28 Feb 1999 5.1.3 Symmetric and Asymmetric Cryptography The Originator and Recipient of a signature may have agreed to use cryptography which is understood only by the two organisations involved. This requires that a separate RecipientInfo and Value elements are contained within the Signature Component. This approach is more likely if symmetric cryptography is being used between the Trading Roles. Equally the same cryptography may be understood by several or all of the Trading Roles. In this case the RecpientRefs attribute of one RecipientInfo element may refer to multiple Organisation Components. This is more likely if public key/asymmetric cryptography is being used. Note that one transaction may involve use of both symmetric and asymmetric cryptography. 5.1.4 Mandatory and Optional Signatures IOTP does not mandate the use of signatures. For example, if a micro payment is being made for 0.1 cents, then the cost of the cryptography required to generate the signature may be greater than the income generated from the payment. Therefore it is up to the Merchant to decide whether IOTP Messages will include signatures, and for the Consumer to decide whether carrying out a transaction without signatures is an acceptable risk. If Merchants discover that transactions without signatures are not being accepted, then they will start using signatures or accept a lower volume and value of business. Additional optional signatures, over and above the ones required by the Trading Roles may be included, for example, to identify a Customer Care Provider or so that a Merchant can sign an Offer using a certificate issued by a Certificate Authority which offers Merchant "Credentials" or some other warranty on the goods or services being offered. 5.1.5 Using signatures to Prove Actions Complete Successfully Proving an action completed successfully, is achieved by signing data on Response messages. Specifically: o on the Offer Response, when a Merchant is making an Offer to the Consumer which can then be sent to either: David Burdett et al. [Page 95] Internet Draft IOTP/1.0 28 Feb 1999 - a Payment Handler to prove that the Merchant authorises Payment, or - a Delivery Handler to prove that Merchant authorises Delivery, provided other necessary authorisations are complete (see below) o on the Payment Response, when a Payment Handler is generating a Payment Receipt which can be sent to either: - a Delivery Handler, in a Delivery Request Block to authorise Delivery together with the Offer Response signature, or - another Payment Handler, in a second Payment Request, to authorise the second payment in a Value Exchange IOTP Transaction. This proof of an action may, in future versions of IOTP, also be used to prove after the event that the IOTP transaction occurred. For example to a Customer Care Provider. 5.2 Checking a Signature is Correctly Calculated Checking a signature is correctly calculated is part of checking for Message Level Errors (see section 4.3.2). It is included here so that all signature and security related considerations are kept together. Before a Trading Role can check a signature it must identify which of the potentially multiple Signature elements should be checked. The steps involved are as follows: o check that a Signature Block is present and it contains one or more Signature Components o identify the Organisation Component which contains an OrgId attribute for the Organisation which is carrying out the signature check. If no or more than one Organisation Component is found then it is an error o use the ID attribute of the Organisation Component to find the RecipientInfo element that contains a RecipientRefs attribute that refers to that Organisation Component. Note there may be no signatures to verify o check the Signature Component that contains the identified RecipientInfo element as follows as follows: - use the SignatureValueRef, the SignatureAlgoritmRef and the SignatureCertRef attributes to identify: respectively, the Value element that contains the signature to be checked, the Algorithm element that describes the signature algorithm to be used to David Burdett et al. [Page 96] Internet Draft IOTP/1.0 28 Feb 1999 verify the Signature and the Certificate to be used by the signature algorithm, then - check that the Value Element correctly signs the Manifest Element - check that the Digest Elements in the Manifest Element are correctly calculated where Components or Blocks referenced by the Digest have been received by the organisation checking the signature 5.3 Checking a Payment or Delivery can occur This section describes the processes required for a Payment Handler or Delivery Handler to check that a payment or delivery can occur. This may include checking signatures if this is specified by the Merchant. In outline the steps are: o check that the Payment Request or Delivery Request has been sent to the correct organisation o check that correct IOTP components are present in the request, and o check that the payment or delivery is authorised For clarity and brevity the following terms or phrases are used in this section: o a "Request Block" is used to refer to either a Payment Request Block (see section 7.7) or a Delivery Request Block (see section 7.10) unless specified to the contrary o a "Response Block" is used to refer to either a Payment Response Block (see section 7.9) or a Delivery Response Block (see section 7.11) o an "Action" is used to refer to an action which occurs on receipt of a Request Block. Actions can be either a Payment or a Delivery o an "Action Organisation", is used to refer to the Payment Handler or Delivery Handler that carries out an Action o a "Signer of an Action", is used to refer to the Organisations that sign data about an Action to authorise the Action, either in whole or in part David Burdett et al. [Page 97] Internet Draft IOTP/1.0 28 Feb 1999 o a "Verifier of an Action", is used to refer to the Organisations that verify data to determine if they are authorised to carry out the Action o an ActionOrgRef attribute contains Element References which can be used to identify the "Action Organisation" that should carry out an Action David Burdett et al. [Page 98] Internet Draft IOTP/1.0 28 Feb 1999 5.3.1 Check the Action Request was sent to the Correct Organisation Checking the Action Request was sent to the correct Organisation varies depending on whether the Action is a Payment or a Delivery. 5.3.1.1 Payment In outline a Payment Handler checks if it can accept or make a payment by identifying the Payment Component in the Payment Request Block it has received, then using the ID of the Payment Component to track through the Brand List and Brand Selection Components to identify the Organisation selected by the Consumer and then checking that this organisation is itself. The way data is accessed to do this is illustrated in the figure below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* Start | v Brand List<--------------------------+-----------Payment Component BrandListRef | Component | | |-Brand<-------------------------- | | Element BrandRef | | | | Brand Selection | |Protocol Component | | AmountRefs | | | v Protocol | | |-Protocol Amount<---------------- | | Element---------- AmountRef | | | | | | |Currency |Pay | | | AmountRefs |Protocol | | v |Ref | |-Currency Amount | | | Element<---------|---------------- | | -PayProtocol<----- Element---------------------->Organisation Action Component OrgRef | -Trading Role Element (Payment Handler) David Burdett et al. [Page 99] Internet Draft IOTP/1.0 28 Feb 1999 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 14 Checking a Payment Handler can carry out a Payment Figure 14 Checking a Payment Handler can carry out a Payment The following describes the steps involved and the checks which need to be made: 1) Identify the Payment Component (see section 6.8) in the Payment Request Block that was received. 2) Identify the Brand List and Brand Selection Components for the Payment Component. This involves: a) identifying the Brand List Component (see section 6.6) where the value of its ID attribute matches the BrandListRef attribute of the Payment Component. If no or more than one Brand List Component is found there is an error. b) identifying the Brand Selection Component (see section 6.7) where the value of its BrandListRef attribute matches the BrandListRef of the Payment Component. If no or more than one matching Brand Selection Component is found there is an error. 3) Identify the Brand, Protocol Amount, Pay Protocol and Currency Amount elements within the Brand List that have been selected by the Consumer as follows: a) the Brand Element (see section 6.6.1) selected is the element where the value of its Id attribute matches the value of the BrandRef attribute in the Brand Selection. If no or more than one matching Brand Element is found then there is an error. b) the Protocol Amount Element (see section 6.6.2) selected is the element where the value of its Id attribute matches the value of the ProtocolAmountRef attribute in the Brand Selection Component. If no or more than one matching Protocol Amount Element is found there is an error c) the Pay Protocol Element (see section 6.6.4) selected is the element where the value of its Id attribute matches the value of the PayProtocolRef attribute in the identified Protocol Amount Element. If no or more than one matching Pay Protocol Element is found there is an error David Burdett et al. [Page 100] Internet Draft IOTP/1.0 28 Feb 1999 d) the Currency Amount Element (see section 6.6.3) selected is the element where the value of its Id attribute matches the value of the CurrencyAmountRef attribute in the Brand Selection Component. If no or more than one matching Currency Amount element is found there is an error 4) Check the consistency of the references in the Brand List and Brand Selection Components: a) check that an Element Reference exists in the ProtocolAmountRefs attribute of the identified Brand Element that matches the Id attribute of the identified Protocol Amount Element. If no or more than one matching Element Reference can be found there is an error b) check that the CurrencyAmountRefs attribute of the identified Protocol Amount element contains an element reference that matches the Id attribute of the identified Currency Amount element. If no or more than one matching Element Reference is found there is an error. c) check the consistency of the elements in the Brand List. Specifically, the selected Brand, Protocol Amount, Pay Protocol and Currency Amount Elements are all child elements of the identified Brand List Component. If they are not there is an error. 5) Check that the Payment Handler that received the Payment Request Block is the Payment Handler selected by the Consumer. This involves: a) identifying the Organisation Component for the Payment Handler. This is the Organisation Component where its ID attribute matches the ActionOrgRef attribute in the identified Pay Protocol Element. If no or more than one matching Organisation Component is found there is an error b) checking the Organisation Component has a Trading Role Element with a Role attribute of PaymentHandler. If not there is an error c) finally, if the identified Organisation Component is not the same as the organisation that received the Payment Request Block, then there is an error. David Burdett et al. [Page 101] Internet Draft IOTP/1.0 28 Feb 1999 5.3.1.2 Delivery The way data is accessed by a Delivery Handler in order to check that it may carry out a delivery is illustrated in the figure below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* Start | v Delivery Component | |ActionOrgRef | v Organisation Component | -Trading Role Element (Delivery Handler) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 15 Checking a Delivery Handler can carry out a Delivery The steps involved are as follows: 1) Identify the Delivery Component in the Delivery Request Block. If there is no or more than one matching Delivery Component there is an error 2) Use the ActionOrgRef attribute of the Delivery Component to identify the Organisation Component of the Delivery Handler. If there is no or more than one matching Organisation Component there is an error 3) If the Organisation Component for the Delivery Handler does not have a Trading Role Element with a Role attribute of DeliveryHandler there is an error 4) Finally, if the organisation that received the Delivery Request Block does not identify the Organisation Component for the Delivery Handler as itself, then there is an error. David Burdett et al. [Page 102] Internet Draft IOTP/1.0 28 Feb 1999 5.3.2 Check the Correct Components are present in the Request Block Check that the correct components are present in the Payment Request Block (see section 7.7) or in the Delivery Request Block (see section 7.10). If components are missing, there is an error. 5.3.3 Check an Action is Authorised The previous steps identified the Action Organisation and that all the necessary components are present. This step checks that the Action Organisation is authorised to carry out the Action. In outline the Action Organisation identifies the Merchant, checks that it has a pre-existing agreement which allows it carry out the Action and that any constraints implied by that agreement are being followed, then, if signatures are required, it checks that they sign the correct data. The steps involved are as follows: 1) Identify the Merchant. This is the Organisation Component with a Trading Role Element which has a Role attribute with a value of Merchant. If no or more than one Trading Role Element is found, there is an error 2) Check the Action Organisation's agreements with the Merchant allows the Action to be carried out. To do this the Action Organisation must check that: a) the Merchant is known and a pre-existing agreement exists for the Action Organisation to be their agent for the payment or delivery b) they are allowed to take part in the type of IOTP transaction that is occurring. For example a Payment Handler may have agreed to accept payments as part of a Baseline Purchase, but not make payments as part of a Baseline Refund c) any constraints in their agreement with the Merchant are being followed, for example, whether or not an Offer Response signature is required 3) Check the signatures are correct. If signatures are required then they need to be checked. This involves: David Burdett et al. [Page 103] Internet Draft IOTP/1.0 28 Feb 1999 a) Identifying the correct signatures to check. This involves the Action Organisation identifying the Signature Components that contain references to the Action Organisation (see 5.3.1). Depending on the IOTP Transaction being carried out (see section 8) either one or two signatures may be identified b) checking that the Signature Components are correct. This involves checking that Digest elements exist within the Manifest Element that refer to the necessary Trading Components (see section 5.3.3.1). [Note] Validation that the signature is correct and that the Digest elements within the signature are correctly calculated is described in section 4 IOTP Error Handling. This is because errors in the signature or generation of digests is considered a Message Level Error and is carried out before the Request Block is processed. [Note End] 5.3.3.1 Check the Signatures Digests are correct All Signature Components contained within IOTP Messages must include Digest elements that refer to: o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Signature Component. This binds the globally unique OtpTransId to other components which make up the IOTP Transaction o the Transaction Reference Block (see section 3.3) of the first IOTP Message that contained the signature. This binds the OtpTransId with information about the IOTP Message contained inside the Message Id Component (see section 3.3.2). Check that each Signature Component contains Digest elements that refer to the correct data required. The Digest elements that need to be present depend on the Trading Role of the Organisation which generated (signed) the signature: o if the signer of the signature is a Merchant then: - Digest elements must be present for all the components in the Request Block apart from the Brand Selection Component which is optional David Burdett et al. [Page 104] Internet Draft IOTP/1.0 28 Feb 1999 o if the signer of the signature is a Payment Handler then Digest elements must be present for: - the Signature Component signed by the Merchant, and optionally - one or more Signature Components signed by the previous Payment Handler(s) in the Transaction. 5.4 Data Integrity and Privacy The overall integrity of data in IOTP Messages is ensured by the signing of Digests of Components and Trading Blocks contained in a Signature Component (see section 6.17) in a Signature Block (see section 7.16). Privacy of information is provided by sending IOTP Messages between the various Trading Roles using a secure channel such as [SSL]. Use of a secure channel within IOTP is optional. David Burdett et al. [Page 105] Internet Draft IOTP/1.0 28 Feb 1999 6. Trading Components This section describes the Trading Components used within IOTP. Trading Components are the child XML elements which occur immediately below a Trading Block as illustrated in the diagram below. David Burdett et al. [Page 106] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* IOTP MESSAGE <----------- IOTP Message - an XML Document | which is transported between the | Trading Roles |-Trans Ref Block <----- Trans Ref Block - contains | | information which describes the | | IOTP Transaction and the IOTP Message. --------> | |-Trans Id Comp. <--- Transaction Id Component - | | | uniquely identifies the IOTP | | | Transaction. The Trans Id | | | Components are the same across | | | all IOTP messages that comprise | | | a single IOTP transaction. | | |-Msg Id Comp. <----- Message Id Component - | | identifies and describes an IOTP | | Message within an IOTP | | Transaction | |-Signature Block <----- Signature Block (optional) - | | | contains one or more Signature | | | Components and their associated | | | Certificates | ---> | |-Signature Comp. <-- Signature Component - contains | | | | digital signatures. Signatures | | | | may sign digests of the Trans Ref | | | | Block and any Trading Component | | | | in any IOTP Message in the same | | | | IOTP Transaction. | | | |-Certificate Comp. <- Certificate Component. Used to | | | check the signature. Trading |-Trading Block <-------- Trading Block - an XML Element Components | |-Component within an IOTP Message that | | | |-Component contains a predefined set of | ---> | |-Component Trading Components | | |-Component | | |-Component <--------- Trading Components - XML | | Elements within a Trading Block | |-Trading Block that contain a predefined set of --------> | |-Component XML elements and attributes | |-Component containing information required | |-Component to support a Trading Exchange | |-Component | |-Component *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 16 Trading Components David Burdett et al. [Page 107] Internet Draft IOTP/1.0 28 Feb 1999 The Trading Components described in this section are listed below in approximately the sequence they are likely to be used: o Protocol Options Component o Authentication Data Component o Authentication Response Component o Order Component o Organisation Component o Brand List Component o Brand Selection Component o Payment Component o Payment Scheme Component o Payment Receipt Component o Delivery Component o Delivery Note Component o Signature Component o Certificate Component o Error Component Note that the following components are listed in other sections of this specification: o Transaction Id Component (see section 3.3.1) o Message Id Component (see section 3.3.2) 6.1 Protocol Options Component Protocol options are options which apply to the IOTP Transaction as a whole. Essentially it provides a short description of the entire David Burdett et al. [Page 108] Internet Draft IOTP/1.0 28 Feb 1999 transaction and the net location which the Consumer role should branch to if the IOTP Transaction is successful. The definition of a Protocol Options Component is as follows. Attributes: ID An identifier which uniquely identifies the Protocol Options Component within the IOTP Transaction. Xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. ShortDesc This contains a short description of the IOTP Transaction in the language defined by xml:lang. Its purpose is to provide an explanation of what type of IOTP Transaction is being conducted by the parties involved. It is used to facilitate selecting an individual transaction from a list of similar transactions, for example from a database of IOTP transactions which has been stored by a Consumer, Merchant, etc. SenderNetLocn This contains the non secured net location of the sender of the TPO Block in which the Protocol Options Component is contained. It is the net location to which the recipient of the TPO block should send a TPO Selection Block if required. The content of this attribute is dependent on the Transport Mechanism see the Transport David Burdett et al. [Page 109] Internet Draft IOTP/1.0 28 Feb 1999 Mechanism Supplement. SecureSenderNetLocn This contains the secured net location of the sender of the TPO Block in which the Protocol Options Component is contained. The content of this attribute is dependent on the Transport Mechanism see the Transport Mechanism Supplement. SuccessNetLocn This contains the net location that the should be displayed after the IOTP Transaction has successfully completed. The content of this attribute is dependent on the Transport Mechanism see the Transport Mechanism Supplement. Either SenderNetLocn, SecureSenderNetLocn or both must be present. 6.2 Authentication Data Component This Trading Component contains data about how an Authentication within the IOTP Transaction will occur. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Authentication Data Component within the IOTP Transaction. AuthenticationId An identifier specified by the Authenticator which, if returned by the Organisation that receives the Authentication Request, will enable the Authenticator to identify which Authentication is being referred to. David Burdett et al. [Page 110] Internet Draft IOTP/1.0 28 Feb 1999 AlgorithmRefs This contains a list of the Algorithm Elements contained within the Auth Data Component from which the recipient of the AuthData Component must choose one to use to generate the Authentication Response (see section 6.3). Note there only one Algorithm may be present. TradingRoleList If present, contains a list of the Trading Roles (see the TradingRole attribute of the Trading Role Element - section 6.5.2) for which the Authenticator is requesting the Authenticatee provides Organisation Components in the Authentication Response. For example a Merchant could request that a Consumer provides Organisation Components for the Consumer and DelivTo Trading Roles. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent This contains the challenge data as one or more Packaged Content (see section 3.8) that is to be responded to using the method indicated by AuthMethod. Algorithm This contains information which describes an Algorithm (see 6.17 Signature Components) that David Burdett et al. [Page 111] Internet Draft IOTP/1.0 28 Feb 1999 may be used to generate the Authentication Response. 6.3 Authentication Response Component This Authentication Response Component contains the results of an authentication. It uses one of the Algorithms selected contained in the AuthData Component (see section 6.2). Depending on the Algorithm selected, the results of the applying the algorithm will either be contained in a Signature Component that signs the Authentication Response and other data, or in the Packaged Content element within the Authentication Response Component. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Authentication Response Component within the IOTP Transaction. SelectedAlgorithmRef An Element Reference that identifies the Algorithm used in generating the Authentication Response. It must be one of the Element References contained within the AlgorithmRefs attribute of the Authentication Data Component (see section 6.2) ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software David Burdett et al. [Page 112] Internet Draft IOTP/1.0 28 Feb 1999 It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent This may contain the response generated as a result of applying the Algorithm selected from the Authentication Data Component see section 6.2. For example, for a payment specific scheme, it may contain scheme-specific data. Refer to the scheme-specific supplemental documentation. 6.4 Order Component An Order Component contains information about an order. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Order Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. OrderIdentifier This is a code, reference number or other David Burdett et al. [Page 113] Internet Draft IOTP/1.0 28 Feb 1999 identifier which the creator of the Order may use to identify the order. It must be unique within an IOTP Transaction. If it is used in this way, then it may remove the need to specify any content for the Order element as the reference can be used to look up the necessary information in a database. ShortDesc A short description of the order in the language defined by xml:lang. It is used to facilitate selecting an individual order from a list of orders, for example from a database of orders which has been stored by a Consumer, Merchant, etc. OkFrom The date and time in [UTC] format after which the offer made by the Merchant lapses. OkTo The date and time in [UTC] format before which a Value Acquirer may accept the offer made by the Merchant is not valid. ApplicableLaw A phrase in the language defined by xml:lang which describes the state or country of jurisdiction which will apply in resolving problems or disputes. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: David Burdett et al. [Page 114] Internet Draft IOTP/1.0 28 Feb 1999 PackagedContent An optional description of the order information as one or more Packaged Contents (see section 3.8). 6.4.1 Order Description Content The Packaged Content element will normally be required, however it may be omitted where sufficient information about the purchase can be provided in the ShortDesc attribute. If the full Order Description requires it several Packaged Content elements may be used. Although the amount and currency are likely to appear in the Packaged Content of the Order Description it is the amount and currency contained in the payment related trading components (Brand List, Brand Selection and Payment) that is authoritative. This means it is important that the amount actually being paid (as contained in the payment related trading components) is prominently displayed to the Consumer. For interoperability, implementations must support Plain Text and HTML as a minimum so that it can be easily displayed. 6.4.2 OkFrom and OkTo Timestamps Note that: o the OkFrom date may be later than the OkFrom date on the Payment Component (see section 6.8) associated with this order, and o similarly, the OkTo date may be earlier that the OkTo date on the Payment Component (see section 6.8). [Note] Disclaimer. The following information provided in this note does not represent formal advice of the Open Trading Protocol Consortium, any of its members or the authors of this specification. Readers of this specification must form their own views and seek their own legal counsel on the usefulness and applicability of this information. The merchant in the context of Internet commerce with anonymous consumers initially frames the terms of the offer on the web page, and in order to obtain the good or service, the consumer must accept them. David Burdett et al. [Page 115] Internet Draft IOTP/1.0 28 Feb 1999 If there is to be a time-limited offer, it recommended that merchants communicate this to the consumer and state in the order description in a manner which is clear to the consumer that: o the offer is time limited o the OkFrom and OkTo timestamps specify the validity of the offer o the clock, e.g. the merchant's clock, that will be used to determine the validity of the offer [Note End] 6.5 Organisation Component The Organisation Component provides information about an individual or an organisation. This can be used for a variety of purposes. For example: o to describe the merchant who is selling the goods, o to identify who made a purchase, o to identify who will take delivery of goods, o to provide a customer care contact, o to describe who will be the Payment Handler. Note that the Organisation Components which must be present in an OTP Message are dependent on the particular transaction being carried out. Refer to section 8. Internet Open Trading Protocol Transactions, for more details. Its definition is as follows. David Burdett et al. [Page 116] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Organisation Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. OrgId A code which identifies the organisation described by the Organisation Component. See 6.5.1.1 Organisation IDs, below. OtpMsgIdPrefix Contains the prefix which must be used for all IOTP Messages sent by the Organisation in this IOTP Transaction. The values to be used are defined in 3.4.1 IOTP Message ID Attribute Definition. LegalName For organisations which are companies this is their legal name in the language defined by xml:lang. It is required for Organisations who have a Trading Role other than Consumer or DeliverTo. ShortDesc A short description of the organisation in the language defined by xml:lang. It is typically the name by which the organisation is commonly known. For example, if the legal name was "Blue Meadows Financial Services Inc.". Then its short name would likely be "Blue Meadows". It is used to facilitate selecting an individual David Burdett et al. [Page 117] Internet Draft IOTP/1.0 28 Feb 1999 organisation from a list of organisations, for example from a database of organisations involved in IOTP Transactions which has been stored by a consumer. LogoNetLocn The net location which can be used to download the logo for the organisation. See section 9 Retrieving Logos. The content of this attribute must conform to [RFC1738]. Content: TradingRole See 6.5.2 Trading Role Element below. ContactInfo See 6.5.3 Contact Information Element below. PersonName See 6.5.4 Person Name below. PostalAddress See 6.5.5 Postal Address below. 6.5.1.1 Organisation IDs Organisation IDs are used by one IOTP Trading Role to identify another. In order to avoid confusion, this means that these IDs must be globally unique. In principle this is achieved in the following way: o the Organisation Id for all trading roles, apart from the Consumer Trading Role, uses a domain name as their globally unique identifier, o the Organisation Id for a Consumer Trading Role is allocated by one of the other Trading Roles in an IOTP Transaction and is made unique by concatenating it with that other roles' Organisation Id, o once a Consumer is allocated an Organisation Id within an IOTP Transaction the same Organisation Id is used by all the other trading roles in that IOTP transaction to identify that Consumer. Specifically, the content of the Organisation ID is defined as follows: David Burdett et al. [Page 118] Internet Draft IOTP/1.0 28 Feb 1999 OrgId ::= NonConsumerOrgId | ConsumerOrgId NonConsumerOrgId ::= DomainName ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId ConsumerOrgIdPrefix ::= "Consumer:" ConsumerOrgId If the Organisation ID for a Consumer consists of: o a standard prefix is to identify that the Organisation Id is for a consumer, followed by o one or more characters which conform to the definition of an XML "namechar". See [XML] specifications, followed by o the NonConsumerOrgId for the Organisation which allocated the ConsumerOrgId. It is normally the Merchant role. Use of upper and lower case is significant. NonConsumerOrgId If the Role is not Consumer then this contains the Canonical Name for the non-consumer organisation being described by the Organisation Component. See [DNS]. Note that a NonConsumerOrgId may not start with the ConsumerOrgIdPrefix. Use of upper and lower case is not significant. Examples of Organisation Ids follow: o newjerseybooks.com - a merchant organisation id o westernbank.co.uk - a payment handler organisation id o consumer:1000247ABH/newjerseybooks.com - a consumer organisation id allocated by a merchant 6.5.2 Trading Role Element This identifies the Trading Role of an individual or organisation in the IOTP Transaction. Note, an organisation may have more than one Trading Role and several roles may be present in one organisation element. Its definition is as follows: David Burdett et al. [Page 119] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Trading Role Element within the IOTP Transaction. TradingRole The trading role of the organisation. Valid values are: o Consumer. The person or organisation that is acting in the role of a consumer in the IOTP Transaction. o Merchant. The person or organisation that is acting in the role of merchant in the IOTP Transaction. o PaymentHandler. The financial institution or other organisation which is a Payment Handler for the IOTP Transaction o DeliveryHandler. The person or organisation that is the delivering the goods or services for the IOTP Transaction o DelivTo. The person or organisation that is receiving the delivery of goods or services in the IOTP Transaction o CustCare. The organisation and/or individual who will provide customer care for an IOTP Transaction. Values of TradingRole are controlled under the procedures defined in section 3.7.3 Values for IOTP Codes which also allows user defined values to be defined. CancelNetLocn This contains the net location of where the Consumer should go to if the Consumer cancels the transaction for some reason. It can be used by the Trading Role to provide a response which is more tailored to the circumstances of a particular transaction. David Burdett et al. [Page 120] Internet Draft IOTP/1.0 28 Feb 1999 This attribute: o must not be present when TradingRole is set to Consumer role, o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler. The content of this attribute is dependent on the Transport Mechanism see the Transport Mechanism Supplement. ErrorNetLocn This contains the net location that should be displayed by the Consumer after the Consumer has either received or generated an Error Block containing an Error Component with the Severity attribute set to either: o HardError, o Warning but the Consumer decides to not continue with the transaction o TransientError and the transaction has subsequently timed out. See section 6.19.1 Error Processing Guidelines for more details. This attribute: o must not be present when TradingRole is set to Consumer role, o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler. The content of this attribute is dependent on the Transport Mechanism see the Transport Mechanism Supplement. ErrorLogNetLocn Optional. This contains the net location that Consumers should send IOTP Messages that contain Error Blocks with an Error Component with the Severity attribute set to either: o HardError, o Warning but the Consumer decides to not continue with the transaction o TransientError and the transaction has subsequently timed out. This attribute: o must not be present when TradingRole is set to David Burdett et al. [Page 121] Internet Draft IOTP/1.0 28 Feb 1999 Consumer role, o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler. The content of this attribute is dependent on the Transport Mechanism see the Transport Mechanism Supplement. The ErrorLogNetLocn can be used to send error messages to the software company or some other organisation responsible for fixing problems in the software which sent the incoming message. See section 6.19.1 Error Processing Guidelines for more details. 6.5.3 Contact Information Element This contains information which can be used to contact an organisation or an individual. All attributes are optional however at least one item of contact information should be present. Its definition is as follows. Attributes: xml:lang Defines the language used by attributes within this element. See section 3.9 Identifying Languages. Tel A telephone number by which the organisation may be contacted. Note that this is a text field and no validation is carried out on it. Fax A fax number by which the organisation may be contacted. Note that this is a text field and no validation is carried out on it. Email An email address by which the organisation may be contacted. Note that this field should David Burdett et al. [Page 122] Internet Draft IOTP/1.0 28 Feb 1999 conform to the conventions for address specifications contained in [RFC822]. NetLocn A location on the Internet by which information about the organisation may be obtained that can be displayed using a web browser. The content of this attribute must conform to [RFC1738]. 6.5.4 Person Name Element This contains the name of an individual person. All fields are optional however as a minimum either the GivenName or the FamilyName should be present. Its definition is as follows. Attributes: xml:lang Defines the language used by attributes within this element. See section 3.9 Identifying Languages. Title A distinctive name; personal appellation, hereditary or not, denoting or implying office (e.g. judge, mayor) or nobility (e.g. duke, duchess, earl), or used in addressing or referring to a person (e.g. Mr, Mrs, Miss) GivenName The primary or main name by which a person is known amongst and identified by their family, friends and acquaintances. Otherwise known as first name or Christian Name. Initials The first letter of the secondary names (other than the Given Name) by which a person is known amongst or identified by their family, friends and acquaintances. David Burdett et al. [Page 123] Internet Draft IOTP/1.0 28 Feb 1999 FamilyName The name by which family of related individuals are known. It is typically the part of an individual's name which is passed on by parents to their children. 6.5.5 Postal Address Element This contains an address which can be used, for example, for the physical delivery of goods, services or letters. Its definition is as follows. Attributes: xml:lang Defines the language used by attributes within this element. See section 3.9 Identifying Languages. AddressLine1 The first line of a postal address. e.g. "The Meadows" AddressLine2 The second line of a postal address. e.g. "Sandy Lane" CityOrTown The city of town of the address. e.g. "Carpham" StateOrRegion The state or region within a country where the city or town is placed. e.g. "Surrey" Country The country for the address. e.g. "UK" LegalLocation This identifies whether the address is the Registered Address for the Organisation. At least one address for the Organisation must have a value set to True unless the Trading Role is David Burdett et al. [Page 124] Internet Draft IOTP/1.0 28 Feb 1999 either Consumer or DeliverTo. 6.6 Brand List Component Brand List Components are contained within the Trading Protocol Options Block (see section 7.1) of the IOTP Transaction. They contains lists of: o payment Brands (see also section 3.6 Brands and Brand Selection), o amounts to be paid in the currencies that are accepted or offered by the Merchant, o the payment protocols which can be used to make payments with a Brand, and o the net locations of the Payment Handlers which accept payment for a payment protocol The definition of a Brand List Component is as follows. Attributes: ID An identifier which uniquely identifies the Brand List Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. ShortDesc A text description in the language defined by xml:Lang giving details of the purpose of the Brand List. This information must be displayed to the receiver of the Brand List in order to David Burdett et al. [Page 125] Internet Draft IOTP/1.0 28 Feb 1999 assist with making the selection. It is of particular benefit in allowing a Consumer to distinguish the purpose of a Brand List when an IOTP Transaction involves more than one payment. PayDirection Indicates the direction in which the payment for which a Brand is being selected is to be made. Its values may be: o Debit The sender of the Payment Request Block (e.g. the Consumer) to which this Brand List relates will make the payment to the Payment Handler, or o Credit The sender of the Payment Request Block to which this Brand List relates will receive a payment from the Payment Handler. Content: Brand This describes a Brand. The sequence of the Brand elements (see section 6.6.1) within the Brand List does not indicate any preference. It is recommended that software which processes this Brand List presents Brands in a sequence which the receiver of the Brand List prefers. ProtocolAmount This links a particular Brand to: o the currencies and amounts in CurrencyAmount elements that can be used with the Brand, and o the Payment Protocols and Payment Handlers, which can be used with those currencies and amounts, and a particular Brand CurrencyAmount This contains a currency code and an amount. PayProtocol This contains information about a Payment Protocol and the Payment Handler which may be used with a particular Brand. David Burdett et al. [Page 126] Internet Draft IOTP/1.0 28 Feb 1999 The relationships between the elements which make up the content of the Brand List is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* Brand List Component | |-Brand | Element | | | |Protocol | | AmountRefs | v |-Protocol Amount | Element---------- | | | | |Currency |Pay | | AmountRefs |Protocol | v |Ref |-Currency Amount | | Element | | | -PayProtocol<----- Element *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 17 Brand List Element Relationships Examples of complete Brand Lists are contained in section 10 Brand List Examples. 6.6.1 Brand Element A Brand Element describes a brand that can be used for making a payment. One or more of these elements is carried in each Brand List Component that has the PayDirection attribute set to Debit. Exactly one Brand Element may be carried in a Brand List Component that has the PayDirection attribute set to Credit. David Burdett et al. [Page 127] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: Id Element identifier, potentially referenced in a Brand Selection Component contained in a later Payment Request message and uniquely identifies the Brand element within the IOTP Transaction. xml:lang Defines the language used by attributes and content of this element. See section 3.9 Identifying Languages. BrandId This contains a unique identifier for the brand or promotional brand. It is used to match against a list of Payment Instruments which the Consumer holds to determine whether or not the Consumer can pay with the Brand. The syntax for a BrandId is as follows: BrandId ::= BrandIdDomain ":" BrandValue Currently the two valid values for the BrandIdDomain have been defined: o IOTP which indicates that values of BrandValue are managed under the procedure described in section 3.7.3 Values for IOTP Codes, and o SET which indicates that the BrandValue conforms to [SET] conventions Examples of BrandIds are: IOTP:Mondex, SET:MasterCard::, and SET:Visa:Gold:AmericanAirlines. The first BrandId is an example of an IOTP BrandId, and the following two are SET BrandIds. David Burdett et al. [Page 128] Internet Draft IOTP/1.0 28 Feb 1999 As values of BrandId are controlled under the procedures defined in section 3.7.3 Values for IOTP Codes user defined values may be defined. BrandName This contains the name of the brand, for example MasterCard Credit. This is the description of the Brand which is displayed to the consumer in the Consumers language defined by xml:lang. For example it might be "American Airlines Advantage Visa". Note that this attribute is not used for matching against the payment instruments held by the Consumer. BrandLogoNetLocn The net location which can be used to download the logo for the organisation. See section Retrieving Logos (see section 9). The content of this attribute must conform to [RFC1738]. BrandNarrative This optional attribute is designed to be used by the Merchant to indicate some special conditions or benefit which would apply if the Consumer selected that brand. For example "5% discount", "free shipping and handling", "free breakage insurance for 1 year", "double air miles apply", etc. ProtocolAmountRefs Identifies the protocols and related currencies and amounts which can be used with this Brand. Specified as a list of ID's of Protocol Amount Elements (see section 6.6.2) contained within the Brand List. ContentSoftwareId This optional attribute contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and David Burdett et al. [Page 129] Internet Draft IOTP/1.0 28 Feb 1999 o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Optional Packaged Content (see section 3.8) elements containing information about the brand which may be used by the payment protocol. The content of this information is defined in the supplement for a payment protocol which describes how the payment protocol works with IOTP. Examples Brand Elements are contained in section 10 Brand List Examples. 6.6.2 Protocol Amount Element The Protocol Amount element links a Brand to: o the currencies and amounts in Currency Amount Elements (see section 6.6.3) that can be used with the Brand, and o the Payment Protocols and Payment Handlers defined in a Pay Protocol Element (see section 6.6.4), which can be used with those currencies and amounts. Its definition is as follows: Attributes: Id Element identifier, potentially referenced in a Brand element; or in a Brand Selection Component contained in a later Payment Request message David Burdett et al. [Page 130] Internet Draft IOTP/1.0 28 Feb 1999 which uniquely identifies the Protocol Amount element within the IOTP Transaction. PayProtocolRef Contains an Element Reference (see section 3.5) that refers to the Pay Protocol Element (see section 6.6.4) that contains the Payment Protocol and Payment Handlers that can be used with the Brand. CurrencyAmountRefs Contains a list of Element References (see section 3.5) that refer to the Currency Amount Element (see section 6.6.3) that describes the currencies and amounts that can be used with the Brand. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Optional Packaged Content (see section 3.8) elements containing information about the protocol amount which may be used by the payment protocol. The content of this information is defined in the supplement for a payment protocol which describes how the payment protocol works with IOTP. Examples of Protocol Amount Elements are contained in10 Brand List Examples. David Burdett et al. [Page 131] Internet Draft IOTP/1.0 28 Feb 1999 6.6.3 Currency Amount Element A Currency Amount element contains: o a currency code (and its type), and o an amount. One or more of these elements is carried in each Brand List Component. Its definition is as follows: Attributes: Id Element identifier, potentially referenced in a Brand element; or in a Brand Selection Component contained in a later Payment Request message which uniquely identifies the Currency Amount Element within the IOTP Transaction. Amount Indicates the amount to be paid in whole and fractional units of the currency. For example $245.35 would be expressed "245.35". Note that values smaller than the smallest denomination are allowed. For example one tenth of a cent would be "0.001". CurrCodeType Indicates the domain of the CurrCode. This attribute is included so that the currency code may support non-standard "currencies" such as frequent flyer points, trading stamps, etc. Its values may be: . ISO4217 indicates the currency code conforms to [ISO 4217] . IOTP indicates that values of CurrCode are managed under the procedure described in section 3.7.3 Values for IOTP Codes CurrCode A code which identifies the currency to be used in the payment. The domain of valid currency codes is defined by CurrCodeType David Burdett et al. [Page 132] Internet Draft IOTP/1.0 28 Feb 1999 As values of CurrCodeType are managed under the procedure described in section 3.7.3 Values for IOTP Codes user defined values of CurrCodeType may be defined. Examples of Currency Amount Elements are contained in 10 Brand List Examples. 6.6.4 Pay Protocol Element A Pay Protocol element specifies details of a Payment Protocol and the Payment Handler that can be used with a Brand. One or more of these elements is carried in each Brand List. Attributes: Id Element identifier, potentially referenced in a Brand element; or in a Brand Selection Component contained in a later Payment Request message which uniquely identifies the Pay Protocol element within the IOTP Transaction. xml:lang Defines the language used by attributes and content of this element. See section 3.9 Identifying Languages. ProtocolId Consists of a protocol name and version. For example "SETv1.0". Values of ProtocolId are managed under the procedure described in section 3.7.3 Values for IOTP Codes. Each payment supplement defines the value to be David Burdett et al. [Page 133] Internet Draft IOTP/1.0 28 Feb 1999 used with that payment method. ProtocolName A narrative description of the payment protocol and its version in the language identified by xml:lang. For example "Secure Electronic Transaction Version 1.0". Its purpose is to help provide information on the payment protocol being used if problems arise. ActionOrgRef An Element Reference (see section 3.5) to the Organisation Component for the Payment Handler for the Payment Protocol. PayReqNetLocn The Net Location indicating where an unsecured Payment Request message should be sent if this protocol choice is used. The content of this attribute is dependent on the Transport Mechanism (such must conform to [RFC1738]. SecPayReqNetLocn The Net Location indicating where a secured Payment Request message should be sent if this protocol choice is used. A secured payment involves the use of a secure channel such as [SSL] in order to communicate with the Payment Handler. The content of this attribute must conform to [RFC1738]. See also See section 3.10 Secure and Insecure Net Locations. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is David Burdett et al. [Page 134] Internet Draft IOTP/1.0 28 Feb 1999 included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Optional Packaged Content elements (see section 3.8) containing information about the protocol which is used by the payment protocol. The content of this information is defined in the supplement for a payment protocol which describes how the payment protocol works with IOTP. An example of its use could be to include a payment protocol message. Examples of Pay Protocol Elements are contained in section 6.6 Brand List Component. 6.7 Brand Selection Component A Brand Selection Component identifies the choice of payment brand, payment protocol and the Payment Handler. This element is used: o in Payment Request messages within Baseline Purchase and Baseline Value IOTP Transactions to identify the brand, protocol and payment handler for a payment, or o to, optionally, inform a merchant in a purchase of the payment brand being used so that the offer and order details can be amended accordingly. In Baseline IOTP, the integrity of Brand Selection Components is not guaranteed. However, modification of Brand Selection Components can only cause denial of service if the payment protocol itself is secure against message modification, duplication, and swapping attacks. The definition of a Brand Selection Component is as follows. David Burdett et al. [Page 135] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Brand Selection Component within the IOTP Transaction. BrandListRef The Element Reference (see section 3.5) of the Brand List Component from which a Brand is being selected BrandRef The Element Reference of a Brand element within the Brand List Component that is being selected that is to be used in the payment. ProtocolAmountRef The Element Reference of a Protocol Amount element within the Brand List Component which is to be used when making the payment. CurrencyAmountRef The Element Reference of a Currency Amount element within the Brand List Component which is to be used when making the payment. Content: BrandSelBrandInfo, This contains any additional data that may be BrandSelProtocolAm required by a particular payment brand or ountInfo, protocol. See sections 6.7.1, 6.7.2, and 6.7.3. BrandSelCurrencyAm ountInfo The following rules apply: o the BrandListRef must contain the ID of a Brand List Component in the same IOTP Transaction David Burdett et al. [Page 136] Internet Draft IOTP/1.0 28 Feb 1999 o every Brand List Component in the Trading Protocol Options Block must be referenced by one and only one Brand Selection Component o the BrandRef must refer to the ID of a Brand contained within the Brand List Component referred to by BrandListRef o the ProtocolAmountRef must refer to one of the Element IDs listed in the ProtocolAmountRefs attribute of the Brand element identified by BrandRef o the CurrencyAmountRef must refer to one of the Element IDs listed in the CurrencyAmountRefs attribute of the Protocol Amount Element identified by ProtocolAmountRef. An example of a Brand Selection Component is included in 10 Brand List Examples. 6.7.1 Brand Selection Brand Info Element The Brand Selection Brand Info Element contains any additional data that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used. Attributes: ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the David Burdett et al. [Page 137] Internet Draft IOTP/1.0 28 Feb 1999 content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Packaged Content elements (see section 3.8) that contain additional data that may be required by a particular payment brand. See the payment method supplement for IOTP for rules on how this is used. 6.7.2 Brand Selection Protocol Amount Info Element The Brand Selection Protocol Amount Info Element contains any additional data that is payment protocol specific that may be required by a particular payment brand or payment protocol. See the IOTP payment method supplement for a description of how and when it used. Attributes: ContentSoftwareId See section 6.7.1 Brand Selection Brand Info Element. Content: PackagedContent Packaged Content elements (see section 3.8) that may contain additional data that may be required by a particular payment brand. See the payment method supplement for IOTP for rules on how this is used. 6.7.3 Brand Selection Currency Amount Info Element The Brand Selection Currency Amount Info Element contains any additional data that is payment brand and currency specific that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used. David Burdett et al. [Page 138] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ContentSoftwareId See section 6.7.1 Brand Selection Brand Info Element. Content: PackagedContent Packaged Content elements (see section 3.8) that contain additional data relating to the payment brand and currency. See the payment method supplement for IOTP for rules on how this is used. 6.8 Payment Component A Payment Component contains information used to control how a payment is carried out. Its provides information on: o the times within which a Payment with a Payment Handler may be started o a reference to the Brand List (see section 6.6) which identifies the Brands, protocols, currencies and amounts which can be used to make a payment o whether or not a payment receipt will be provided o whether another payment precedes this payment. Its definition is as follows. David Burdett et al. [Page 139] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Payment Component within the IOTP Transaction. OkFrom The date and time in [UTC] format after which a Payment Handler may accept for processing a Payment Request Block (see section 7.7) containing the Payment Component. OkTo The date and time in [UTC] format before which a Payment Handler may for processing accept a Payment Request Block containing the Payment Component. BrandListRef An Element Reference (see section 3.5) of a Brand List Component (see section 6.6) within the TPO Trading Block for the IOTP Transaction. The Brand List identifies the alternative ways in which the payment can be made. SignedPayReceipt Indicates whether or not the Payment Response Block (7.9) generated by the payment handler for the payment must be digitally signed. StartAfter Contains Element References (see section 3.5) of other Payment Components which describe payments which must be complete before this payment can start. If no StartAfter attribute is present then there are no dependencies and the payment can start immediately David Burdett et al. [Page 140] Internet Draft IOTP/1.0 28 Feb 1999 6.9 Payment Scheme Component A Payment Scheme Component contains payment protocol information for a specific payment scheme which is transferred between the parties involved in a payment for example a [SET] message. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Payment Scheme Component within the IOTP Transaction. ConsumerPaymentId An identifier specified by the Consumer which, if returned by the Payment Handler in another Payment Scheme Component or by other means, will enable the Consumer to identify which payment is being referred to. PaymentHandlerPayId An identifier specified by the Payment Handler which, if returned by the Consumer in another Payment Scheme Component, or by other means, will enable the Payment Handler to identify which payment is being referred to. It is required on every Payment Scheme Component apart from the one contained in a Payment Request Block. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software David Burdett et al. [Page 141] Internet Draft IOTP/1.0 28 Feb 1999 It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Contains payment scheme protocol information as Packaged Content elements (see section 3.8). See the payment scheme supplement for the definition of its content. 6.10 Payment Receipt Component A Payment Receipt is a record of a payment which demonstrates how much money has been paid or received. It is distinct from a purchase receipt in that it contains no record of what was being purchased. Typically the content of a Payment Receipt Component will contain data which describes: o the amount paid and its currency o the date and time of the payment o internal reference numbers which identify the payment to the payment system o potentially digital signatures generated by the payment method which can be used to prove after the event that the payment occurred. If the Payment Method being used provides the facility then the Payment Receipt Component should contain payment protocol messages, or references to messages, which prove the payment occurred. The precise definition of the content is Payment Method dependent. Refer to the supplement for the payment method being used to determine the rules that apply. Information contained in the Payment Receipt Component should be displayed or otherwise made available to the Consumer. David Burdett et al. [Page 142] Internet Draft IOTP/1.0 28 Feb 1999 [Note] If the Payment Receipt Component contains Payment Protocol Messages, then the Messages will need to be processed by Payment Method software to convert it into a format which can be understood by the Consumer [Note End] The definition of a Payment Receipt Component is as follows. Attributes: ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction. PaymentRef Contains an Element Reference (see section 3.5) to the Payment Component (see section 6.8) to which this payment receipt applies PayReceiptRefs Optionally contains Element References to other Components (potentially including Pay Scheme Components) which together make up the receipt. Note that: o each payment scheme defines in its supplement the elements which must be referenced. o each of the components must be referenced by Digests in the Payment Response signature component, if one is being used. The client software should save all the components referenced so that the payment receipt can be reconstructed when required. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: David Burdett et al. [Page 143] Internet Draft IOTP/1.0 28 Feb 1999 o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Contains payment scheme specific record of the payment which can be used for receipt purposes as Packaged Content elements (see section 3.8). Each payment scheme defines in its supplement the structure of the content. Note that either the PayReceiptRefs attribute, the PackagedContent element, or both must be present. 6.11 Payment Note Component The Payment Note Component contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer. For example, if a withdrawal or deposit were being made then it could contain information on the remaining balance on the account after the transfer was complete. The information should duplicate information contained within the Payment Receipt Component. Information contained in the Payment Note Component should be displayed or otherwise made available to the Consumer. For interoperability, the Payment Note Component should support, as a minimum, the content types of Plain/Text and HTML. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the David Burdett et al. [Page 144] Internet Draft IOTP/1.0 28 Feb 1999 Payment Receipt Component within the IOTP Transaction. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer as one or more Packaged Content elements (see section 3.8). 6.12 Delivery Component The Delivery Element contains information required to deliver goods or services. Its definition is as follows. Attributes: David Burdett et al. [Page 145] Internet Draft IOTP/1.0 28 Feb 1999 ID An identifier which uniquely identifies the Delivery Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. DelivExch Indicates if this IOTP Transaction includes the messages associated with a Delivery Exchange. Valid values are: . True indicates it does include a Delivery Exchange . False indicates it does not include a Delivery Exchange If set to true then a DeliveryData element must be present. If set to false it may be absent. DelivAndPayResp Indicates if the Delivery Response Block (see section 7.11) and the Payment Response Block (see section 7.9 ) are combined into one IOTP Message. Valid values are: o True indicates both blocks will be in the same IOTP Message, and o False indicates each block will be in a different IOTP Message DelivAndPayResp should not be true if DelivExch is False. In practice combining the Delivery Response Block and Payment Response Block is only likely to be practical if the Merchant, the Payment Handler and the Delivery Handler are the same organisation since: o the Payment Handler must have access to Order Component information so that they know what to deliver, and o the Payment Handler must be able to carry out the delivery ActionOrgRef An Element Reference to the Organisation Component of the Delivery Handler for this delivery. David Burdett et al. [Page 146] Internet Draft IOTP/1.0 28 Feb 1999 ConsumerDeliveryId An identifier specified by the Consumer which, if returned by the Delivery Handler in another Delivery Component, or by other means, will enable the Consumer to identify which Delivery is being referred to. Content: DeliveryData Contains details about how the delivery will be carried out. See 6.12.1 Delivery Data Element below. PackagedContent Contains "user" data defined for the Merchant which is required by the Delivery Handler as one or more Packaged Content Elements see section 3.8. 6.12.1 Delivery Data Element The DeliveryData element contains information about where and how goods are to be delivered. Its definition is as follows. Attributes: xml:lang Defines the language used by attributes within this component. See section 3.9 Identifying Languages. OkFrom The date and time in [UTC] format after which the Delivery Handler may accept for processing a Delivery Request Block (see section 7.10). OkTo The date and time in [UTC] format before which the Delivery Handler may accept for processing a David Burdett et al. [Page 147] Internet Draft IOTP/1.0 28 Feb 1999 Delivery Request Block. DelivMethod Indicates the method by which goods or services may be delivered. Valid values are: o Post the goods will be delivered by post or courier o Web the goods will be delivered electronically in the Delivery Note Component o Email the goods will be delivered electronically by e-mail Values of DelivMethod are managed under the procedure described in section 3.7.3 Values for IOTP Codes which allows user defined codes to be defined. DelivToRef The Element Reference (see section 3.4) of an Organisation Component within the IOTP Transaction which has a role of DelivTo. The information in this block is used to determine where delivery is to be made. It must be compatible with DelivMethod. Specifically if the DelivMethod is: o Post, then the there must be a Postal Address Element containing sufficient information for a postal delivery, o Web, then there are no specific requirements. The information will be sent in a web page back to the Consumer o Email, then there must be Contact Information Element with a valid e-mail address DelivReqNetLocn This contains the Net Location to which an unsecured Delivery Request Block (see section 7.10) which contains the Delivery Component should be sent. The content of this attribute is dependent on the Transport Mechanism must conform to [RFC1738]. SecDelivReqNetLocn This contains the Net Location to which a secured Delivery Request Block (see section 7.10) which contains the Delivery Component should be sent. A secured delivery request involves the use of a David Burdett et al. [Page 148] Internet Draft IOTP/1.0 28 Feb 1999 secure channel such as [SSL] in order to communicate with the Payment Handler. The content of this attribute is dependent on the Transport Mechanism must conform to [RFC1738]. See also Section 3.10 Secure and Insecure Net Locations. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: PackagedContent Additional information about the delivery as one or more Packaged Content elements (see section 3.8) provided to the Delivery Handler by the merchant. 6.13 Delivery Note Component A Delivery Note contains delivery instructions about the delivery of goods or services or potentially the actual Delivery Information itself. It is information which the person or organisation receiving the Delivery Note can use when delivery occurs. For interoperability, the Delivery Note Component Packaged Content should support both Plain Text and HTML. David Burdett et al. [Page 149] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Delivery Note Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. DelivHandlerDelivId An optional identifier specified by the Delivery Handler which, if returned by the Consumer in another Delivery Component, or by other means, will enable the Delivery Handler to identify which Delivery is being referred to. It is required on every Delivery Component apart from the one contained in a Delivery Request Block. An example use of this attribute is to contain a delivery tracking number. ContentSoftwareId This contains information which identifies the software which generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum: o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software It is recommended that this attribute is included if the software which generated the content cannot be identified from the David Burdett et al. [Page 150] Internet Draft IOTP/1.0 28 Feb 1999 SoftwareId attribute on the Message Id Component (see section 3.3.2) Content: DeliveryNote Contains actual delivery note information as one or more Packaged Content elements (see section 3.8). [Note] If the content of the Delivery Message is a Mime message then the Delivery Note may trigger an application which causes the actual delivery to occur. [Note End] 6.14 Status Component A Status Component contains status information about the business success or failure (see section 4.2) of a process. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Status Component within the IOTP Transaction. xml:lang Defines the language used by attributes within this component. See section 3.9 Identifying Languages. StatusType Indicates the type of process which the Status is reporting on. It may be set to either Offer, Payment, Delivery or Authentication. David Burdett et al. [Page 151] Internet Draft IOTP/1.0 28 Feb 1999 Values of StatusType are managed under the procedure described in section 3.7.3 Values for IOTP Codes which also allows user defined values of StatusType to be defined. ElRef Contains an Element Reference (see section 3.5) to the Component for which the Status is being described. It must refer to either: o a Trading Protocol Options Block (see section 7.1), if the StatusType is Offer, o a Payment Component (see section 6.8), if the StatusType is Payment, or o a Delivery Component (see section 6.12), if the StatusType is Delivery o an Authentication Data Component (see section 6.2) if the StatusType is Authentication. ProcessState Contains a State Code which indicates the current state of the process being carried out. Valid values for ProcessState are: o NotYetStarted. A Request Block has been received but the process has not yet started o InProgress. Processing of the Request Block has started but it is not yet complete o CompletedOk. The processing of the Request Block has completed successfully without any errors o Failed. The processing of the Request Block has failed because of a business error (see section 4.2) o ProcessError. This value is only used when the Status Component is being used in connection with an Inquiry Request Trading Block (see section 7.12). It indicates there was a Technical Error (see section 4.1) in the Request Block which is being processed or some internal processing error. Note that this code reports on the processing of a Request Block. Further, asynchronous processing may occur after the Response Block associated with the Process has been sent. CompletionCode Indicates how the process completed. Valid values for the CompletionCode are given below together with the conditions when it must be David Burdett et al. [Page 152] Internet Draft IOTP/1.0 28 Feb 1999 present. A CompletionCode is a maximum of 14 characters long. ProcessReference This optional attribute holds a reference for the process whose status is being reported. It may hold the following values: o when StatusType is set to Offer, it should contain the OrderIdentifier from the Order Component o when StatusType is set to Payment, it should contain the PaymentHandlerPayId from the Payment Scheme Data Component o when StatusType is set to Delivery, it should contain the DelivHandlerDelivId from the Delivery Note Component o when StatusType is set to Authentication, it should contain the AuthenticationId from the Authentication Data Component This attribute should be absent in the Inquiry Request message when the Consumer has not been given such a reference number by the IOTP Service Provider. This attribute can be used in an Inquiry Response Block (see section 7.13) to give the reference number for a transaction which has previously been unavailable. For example, the package tracking number might not be assigned at the time a delivery response was received. However, if the Consumer issues a Baseline Transaction Status Inquiry later, the Delivery Handler can put the package tracking number into this attribute in the Inquiry Response message and send it back to the Consumer. StatusDesc An optional textual description of the current status of the process in the language identified by xml:lang. David Burdett et al. [Page 153] Internet Draft IOTP/1.0 28 Feb 1999 6.14.1 Offer Completion Codes The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate. Value Description AuthError Authentication Error. The check of the Authentication Response which was carried out has failed. ConsCancelled Consumer Cancelled. The Consumer decides to cancel the transaction for some reason. This code is only valid in a Status Component contained in a Cancel Block. MerchCancelled Offer Cancelled. The Merchant declines to generate an offer for some reason and cancels the transaction. This code is only valid in a Status Component contained in a Cancel Block. Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. 6.14.2 Payment Completion Codes The CompletionCode is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used by individual payment schemes to provide further explanation where appropriate. Value Description BrandNotSupp Brand not supported. The payment brand is not supported by the Payment Handler. CurrNotSupp Currency not supported. The currency in which the payment is to be made is not supported by either the Payment Instrument or the Payment Handler. ConsCancelled Consumer Cancelled. The Consumer decides to David Burdett et al. [Page 154] Internet Draft IOTP/1.0 28 Feb 1999 cancel the payment for some reason. This code is only valid in a Status Component contained in a Cancel Block. PaymtCancelled Payment Cancelled. The Payment Handler declines to complete the payment for some reason and cancels the transaction. This code is only valid in a Status Component contained in a Cancel Block. AuthError Authentication Error. The Payment Scheme specific authentication check which was carried out has failed. InsuffFunds Insufficient funds. There are insufficient funds available for the payment to be made. InstBrandInvalid Payment Instrument not valid for Brand. A Payment Instrument is being used which does not correspond with the Brand selected. For example a Visa credit card is being used when MasterCard was selected as the Brand. InstNotValid Payment instrument not valid for trade. The Payment Instrument cannot be used for the proposed type of trade, for some reason. BadInstrument Bad instrument. There is a problem with the Payment Instrument being used which means that it is unable to be used for the payment. Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. The StatusDesc attribute should provide the explanation of the cause. 6.14.3 Delivery Completion Codes The following table contains the valid values for the CompletionCode attribute for a Delivery. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate. Value Description BackOrdered Back Ordered. The goods to be delivered are on order but they have not yet been received. David Burdett et al. [Page 155] Internet Draft IOTP/1.0 28 Feb 1999 Shipping will be arranged when they are received. This is only valid if ProcessState is CompletedOk. PermNotAvail Permanently Not Available. The goods are permanently unavailable and cannot be re- ordered. This is only valid if ProcessState is Failed. TempNotAvail Temporarily Not Available. The goods are temporarily unavailable and may become available if they can be ordered. This is only valid if ProcessState is CompletedOk. ShipPending Shipping Pending. The goods are available and are scheduled for shipping but they have not yet been shipped. This is only valid if ProcessState is CompletedOk. Shipped Goods Shipped. The goods have been shipped. Confirmation of delivery is awaited. This is only valid if ProcessState is CompletedOk. ShippedNoConf Shipped - No Delivery Confirmation. The goods have been shipped but it is not possible to confirm delivery of the goods. This is only valid if ProcessState is CompletedOk. ConsCancelled Consumer Cancelled. The Consumer decides to cancel the delivery for some reason. This code is only valid in a Status Component contained in a Cancel Block. DelivCancelled Delivery Cancelled. The Delivery Handler declines to complete the Delivery for some reason and cancels the transaction. This code is only valid in a Status Component contained in a Cancel Block. Confirmed Confirmed. All goods have been delivered and confirmation of their delivery has been received. This is only valid if ProcessState is CompletedOk. Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. The StatusDesc attribute David Burdett et al. [Page 156] Internet Draft IOTP/1.0 28 Feb 1999 should provide the explanation of the cause. 6.14.4 Authentication Completion Codes The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate. Value Description AutEeCancel Authenticatee Cancel. The organisation being authenticated declines to be authenticated for some reason. This could be, for example because the signature on an Authentication Request was invalid or the Authenticator was not known or acceptable to the Authenticatee. AutOrCancel Authenticator Cancel. The organisation requesting authentication declines to validate the Authentication Response received for some reason and cancels the transaction. NoAuthData Authentication Data Not Available. The Authenticatee does not have the data that must be provided so that they may be successfully authenticated. For example a password may have been forgotten, the Authenticatee has not yet become a member, or a smart card token is not present. AuthFailed Authentication Failed. The Authenticator checked the Authentication Response but the authentication failed for some reason. For example a password may have been incorrect. TradRolesIncon Trading Roles Inconsistent. The Trading Roles contained within the TradingRoleList attribute of the Authentication Data Component are inconsistent with the Trading Role which the Authenticatee is taking in the IOTP Transaction or is able to take. Examples of inconsistencies include: o asking a PaymentHandler for DeliveryHandler information o asking a Consumer for Merchant information David Burdett et al. [Page 157] Internet Draft IOTP/1.0 28 Feb 1999 Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. 6.15 Trading Role Data Component The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an IOTP Transaction. Trading Role Components identify: o the organisation that generated the component, and o the organisation that is to receive it. They are first generated and included in a "Response" Block, and then copied to the appropriate "Request" Block. For example a Payment Handler might need to inform a Delivery Handler that a credit card payment had been authorised but not captured. There may also be other information that the Payment Handler has generated where the format is privately agreed with the Delivery Handler which needs to be communicated. In another example a Merchant might need to provide a Payment Handler with some specific information about a Consumer so that consumer can acquire double loyalty points with the payment. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Trading Role Data Component within the IOTP Transaction. OrginatorElRef Contains an element reference to the Organisation Component of the Organisation that created the Trading Role Data Component and included it in a "Response" Block (e.g. an Offer David Burdett et al. [Page 158] Internet Draft IOTP/1.0 28 Feb 1999 Response or a Payment Response Block). DestinationElRefs Contains element references to the Organisation Components of the Organisations that are to receive the Trading Role Data Component in a "Request" Block (e.g. either a Payment Request or a Delivery Request Block). Content: PackagedContent This contains the data which is to be sent between the various Trading Roles as one or more PackagedContent elements see section 3.8. 6.15.1 Who Receives a Trading Role Data Component The rules for deciding what to do with Trading Role Data Components are described below. o whenever a Trading Role Data Component is received in a "Response" block identify the Organisation Components of the Organisations that are to receive it as identified by the DestinationElRefs attribute. o whenever a "Request" Block is being sent, check to see if it is being sent to one of the Organisations identified by the DestinationElRefs attribute. If it is then include in the "Request" block: - the Trading Role Data Component as well as, - the Organisation Component of the Organisation identified by the OriginatorElRef attribute (if not already present) 6.16 Inquiry Type Component The Inquiry Component contains the information which indicates what type of process is being inquired upon. Its definition is as follows. David Burdett et al. [Page 159] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Inquiry Type Component within the IOTP Transaction. Type Contains the type of inquiry. Valid values for Type are: o Offer. The inquiry is about the status of an offer and is addressed to the Merchant. o Payment. The inquiry is about the status of a payment and is addressed to the Payment Handler. o Delivery. The inquiry is about the status of a delivery and addressed to the Delivery Handler. ElRef Contains an Element Reference (see section 3.5) to the component to which this Inquiry Type Component applies. That is, o TPO Block when Type is Offer o Payment Component when Type is Payment o Delivery Component when Type is Delivery ProcessReference Optionally contains a reference to the process being inquired upon. It should be set if the information is available. For the definition of the values it may contain, see the ProcessReference attribute of the Status Component (see section 6.14). 6.17 Signature Component [Note] Definitions of the XML structures for signatures and certificates are described in the paper "Digital Signatures for XML - Proposal", see [XMLDSIG]. As this is an Internet Draft, it will be subject to revision. David Burdett et al. [Page 160] Internet Draft IOTP/1.0 28 Feb 1999 However there is an immediate need for a more stable version to be used with pilots of IOTP that are currently planned. Therefore, this section contains a definition of a Signature Component that closely follows the definitions contained in XMLDSIG, but has been modified to meet some specific IOTP requirements. In the future it is anticipated that future versions of IOTP will adopt a stable version of the XMLDSIG once it becomes available. [Note End] Each Signature Component digitally signs one or more Blocks or Components including other Signature Components. The Signature Component: o contains digests of one or more Blocks or Components in one or more IOTP Messages within the same IOTP Transaction and places the result in a Digest Element o concatenates these Digest elements with other information on the type of signature, the originator and potential recipients of the signature and details of the signature algorithms being used and places them in a Manifest element, and o signs the Manifest element using the optional certificate identified in the Certificate element within the Signature Block placing the result in a Value element within a Signature Component Note that there may be multiple Value elements that contain signatures of a Manifest Element. A Signature Component can be one of four types either: o an Offer Response Signature, o a Payment Response Signature, o a Delivery Response Signature, or o an Authentication Response Signature. For a general explanation of signatures see section 5 Security Considerations. David Burdett et al. [Page 161] Internet Draft IOTP/1.0 28 Feb 1999 The definition of a Signature Component is as follows: David Burdett et al. [Page 162] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 163] Internet Draft IOTP/1.0 28 Feb 1999 6.17.1 IOTP usage of signature elements and attributes Detailed definitions of the above elements and attributes are contained in [XMLDSIG]. The following contains additional information that describes how these elements and attributes are used by IOTP. SIGNATURE ELEMENT The ID attribute is mandatory. MANIFEST ELEMENT The optional LocatorHrefBase attribute contains text which should be concatenated before the text contained in the LocatorHREF attribute of all Digest elements within the Manifest. Its purpose is to reduce the size of LocatorHREF attribute values since the first part of the LocatorHREF attributes in the same signature are likely to be the same. Typically, within IOTP, it will contain all the characters in a LocatorHref attribute up to the sharp ("#") character (see immediately below). ALGORITHM AND PARAMETER ELEMENTS The algorithm element identifies the algorithms used in generating the signature. The type of the algorithm is defined by the value of the Type attribute which indicates if it is the algorithm is to be used as a Digest algorithm, a Signature algorithm or a Key Agreement algorithm. The following Digest algorithms must be implemented: o a [DOM-HASH] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:dom-hash" o a [SHA1] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:fips:sha1", and o a [MD5] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:md5" The following Signature algorithms must be implemented: o a [DSA] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:us.gov:dsa" David Burdett et al. [Page 164] Internet Draft IOTP/1.0 28 Feb 1999 o a [HMAC] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:hmac" It is recommended that the following Signature algorithm is also implemented: o a [RSA] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:rsa" In addition other payment scheme specific algorithms may be used. In this case the value of the name attribute to use is specified in the payment scheme supplement for that algorithm. One algorithm may make use of other algorithms by use of the Parameter element, for example: A2 A1 DIGEST ELEMENT The LocatorHREF attribute identifies the IOTP element which is being digitally signed. Specifically it consists of: o the value of the OtpTransId attribute of the Transaction ID Component, followed by: o a sharp character, i.e. "#", followed by o an Element Reference (see section 3.5) to the element within the IOTP Transaction which is the subject of the digest. Before analysing the structure of the LocatorHREF attribute, it must be concatenated with the value of the LocatorHrefBase attribute of the Manifest element (see immediately above). David Burdett et al. [Page 165] Internet Draft IOTP/1.0 28 Feb 1999 ATTRIBUTE ELEMENT There must be one and only one Attribute Element that contains a Type attribute with a value of IOTPSignatureType and with content set to either: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest or PingResponse; depending on the type of the signature. Values of the content of the Attribute element are controlled under the procedures defined in section 3.7.3 Values for IOTP Codes which also allows user defined values to be defined. The Critical attribute must be set to true. ORIGINATORINFO ELEMENT The OriginatorRef attribute of the OriginatorInfo element must always be present and contain an Element Reference (see section 3.5) to the Organisation Component of the Organisation that generated the Signature Component. RECIPIENTINFO ELEMENT The RecipientRefs attribute contains a list of Element References (see section 3.5), that point to the Organisations that might need to validate the signature. For details see below. 6.17.2 Offer Response Signature Component The Manifest Element of a signature which has a type of OfferResponse should contain Digest elements for the following Components: o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Offer Response Signature o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Offer Response Signature o from the TPO Block: - the Protocol Options Component - each of the Organisation Components - each of the Brand List Components o optionally, all the Brand Selection Components if they were sent to the Merchant in a TPO Selection Block David Burdett et al. [Page 166] Internet Draft IOTP/1.0 28 Feb 1999 o from the Offer Response Block: - the Order Component - each of the Payment Components - the Delivery Component - each of the Authentication Data Components - any Trading Role Data Components The Offer Response Signature should also contain Digest elements for the components that describe each of the organisations that may or will need to verify the signature. This involves: o if the Merchant has received a TPO Selection Block containing Brand Selection Components, then generate a Digest element for the Payment Handler identified by the Brand Selection Component and the Delivery Handler identified by the Delivery Component. See section 5.3.1 Check the Action Request was sent to the Correct Organisation for a description of how this can be done. o if the Merchant is not expecting to receive a TPO Selection Block then generate a Digest element for the Delivery Handler and all the Payment Handlers that are involved. 6.17.3 Payment Receipt Signature Component The Manifest Element of the Payment Receipt Signature Component should contain Digest Elements for the following Components: o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Payment Receipt Signature o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Payment Receipt Signature o the Offer Response Signature Component o the Payment Receipt Component o the Status Component o the Brand Selection Component. o any Trading Role Data Components David Burdett et al. [Page 167] Internet Draft IOTP/1.0 28 Feb 1999 6.17.4 Delivery Response Signature Component The Manifest Element of the Delivery Response Signature Component should contain Digest Elements for the following Components: o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Delivery Response Signature o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature o the Signature Components contained in the preceding Delivery Request (if any) o the Status Component o the Delivery Note Component 6.17.5 Authentication Request Signature Component The Manifest Element of the Authentication Request Signature Component should contain Digest Elements for the following Components: o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the TPO Block : - the Protocol Options Component - the Organisation Component o the following components of the Authentication Request Block: - the Authentication Data Component 6.17.6 Authentication Response Signature Component The Manifest Element of the Authentication Response Signature Component should contain Digest Elements for the following Components: David Burdett et al. [Page 168] Internet Draft IOTP/1.0 28 Feb 1999 o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the Authentication Request Block: - the Authentication Data Component o the Organisation Components contained in the Authentication Response Block 6.17.7 Ping Request Signature Component If the Ping Request is being singed (see section 8.2.2), the Manifest Element of the Ping Request Signature Component should contain Digest elements for all the Organisation Components. 6.17.8 Ping Response Signature Component If the Ping Response is being singed (see section 8.2.2), the Manifest Element of the Ping Response Signature Component should contain Digest elements fir all the Organisation Components. 6.18 Certificate Component [Note] Definitions of the XML structures for signatures and certificates are described in the paper "Digital Signatures for XML - Proposal", see [XMLDSIG]. As this is an Internet Draft, it will be subject to revision. See note at the start of section 6.17 Signature Component for more details. [Note End] A Certificate Component contains a Digital Certificate. Its structure is as follows: David Burdett et al. [Page 169] Internet Draft IOTP/1.0 28 Feb 1999 6.18.1 IOTP usage of signature elements and attributes Detailed definitions of the above elements and attributes are contained in [XMLDSIG]. The following contains additional information that describes how these elements and attributes are used by IOTP. CERTIFICATE COMPONENT The ID attribute is mandatory. VALUE ELEMENT The ID attribute is mandatory. 6.19 Error Component The Error Component contains information about Technical Errors (see section 4.1) in an IOTP Message which has been received by one of the Trading Roles involved in the trade. For clarity two phrases are defined which are used in the description of an Error Component: David Burdett et al. [Page 170] Internet Draft IOTP/1.0 28 Feb 1999 o message in error. An IOTP message which contains or causes an error of some kind o message reporting the error. An IOTP message that contains an Error Component that describes the error found in a message in error. The definition of the Error Component is as follows. Attributes: ID An identifier which uniquely identifies the Error Component within the IOTP Transaction. xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.9 Identifying Languages. ErrorCode Contains an error code which indicates the nature of the error in the message in error. Valid values for the ErrorCode are given in section 6.19.2 Error Codes. ErrorDesc Contains a narrative description of the error in the language defined by xml:lang. The content of this attribute is defined by the vendor/developer of the software which generated the Error Component Severity Indicates the severity of the error. Valid values are: o Warning. This indicates that although there is a message in error the IOTP Transaction can still continue. o TransientError. This indicates that the error in the message in error may be recovered if David Burdett et al. [Page 171] Internet Draft IOTP/1.0 28 Feb 1999 the message in error that is referred to by the ErrorLocation element is resent o HardError. This indicates that there is an unrecoverable error in the message in error and the IOTP Transaction must stop. MinRetrySecs This attribute should be present if Severity is set to TransientError. It is the minimum number of whole seconds which the IOTP aware application which received the message reporting the error should wait before re-sending the message in error identified by the ErrorLocation element. If Severity is not set to TransientError then the value of this attribute is ignored. SwVendorErrorRef This attribute is a reference whose value is set by the vendor/developer of the software which generated the Error Component. It should contain data which enables the vendor to identify the precise location in their software and the set of circumstances which caused the software to generate a message reporting the error. See also the SoftwareId attribute of the Message Id element in the Transaction Reference Block (section 3.3). Content: ErrorLocation This identifies the IOTP Transaction Id of the message in error and, where possible, the element and attribute in the message in error that caused the Error Component to be generated. If the Severity of the error is not TransientError, more than one ErrorLocation may be specified as appropriate depending on the nature of the error (see section 6.19.2 Error Codes) and at the discretion of the vendor/developer of the IOTP Aware Application. PackagedContent This contains additional data which can be used to understand the error. Its content may vary as appropriate depending on the nature of the error (see section 6.19.2 Error Codes) and at the discretion of the vendor/developer of the IOTP David Burdett et al. [Page 172] Internet Draft IOTP/1.0 28 Feb 1999 Aware Application. For a definition of PackagedContent see section 3.8. 6.19.1 Error Processing Guidelines If there is more than one Error Component in a message reporting the error, carry out the actions appropriate for the Error Component with the highest severity. In this context, HardError has a higher severity than TransientError, which has a higher severity than Warning. 6.19.1.1 Severity - Warning If an IOTP aware application is generating a message reporting the error with an Error Component where the Severity attribute is set to Warning, then if the message reporting the error does not contain another Error Component with a severity higher than Warning, the IOTP Message must also include the Trading Blocks and Trading Components that would have been included if no error was being reported. If a message reporting the error is received with an Error Component where Severity is set to Warning, then: o it is recommended that information about the error is either logged, or otherwise reported to the user, o the implementer of the IOTP aware application must either, at their or the user's discretion: - continue the IOTP transaction as normal, or - fail the IOTP transaction by generating a message reporting the error with an Error Component with Severity set to HardError (see section 6.19.1.3). If the intention is to continue the IOTP transaction then, if there are no other Error Components with a higher severity, check that the necessary Trading Blocks and Trading Components for normal processing of the transaction to continue are present. If they are not then generate a message reporting the error with an Error Component with Severity set to HardError. 6.19.1.2 Severity - Transient Error If an IOTP Aware Application is generating a message reporting the error with an Error Component where the Severity attribute is set to TransientError, then there should be only one Error Component in the message reporting the error. In addition, the MinRetrySecs attribute should be present. David Burdett et al. [Page 173] Internet Draft IOTP/1.0 28 Feb 1999 If a message reporting the error is received with an Error Component where Severity is set to TransientError then: o if the MinRetrySecs attribute is present and a valid number, then use the MinRetrySecs value given. Otherwise if MinRetrySecs is missing or is invalid, then: - generate a message reporting the error containing an Error Component with a Severity of Warning and send it on the next IOTP message (if any) to be sent to the Trading Role which sent the message reporting the error with the invalid MinRetrySecs, and - use a value for MinRetrySecs which is set by the vendor/developer of the IOTP Aware Application. o check that only one ErrorLocation element is contained within the Error Component and that it refers to an IOTP Message which was sent by the recipient of the Error Component with a Severity of TransientError. If more than one ErrorLocation is present then generate a message reporting the error with a Severity of HardError. 6.19.1.3 Severity - Hard Error If an IOTP Aware Application is generating a message reporting the error with an Error Component where the Severity attribute set to HardError, then there should be only one Error Component in the message reporting the error. If a message reporting the error is received with an Error Component where Severity is set to HardError then terminate the IOTP Transaction. 6.19.2 Error Codes The following table contains the valid values for the ErrorCode attribute of the Error Component. The first sentence of the description contains the text that should be used to describe the error when displayed or otherwise reported. Individual implementations may translate this into alternative languages at their discretion. An Error Code must not be more that 14 characters long. Value Description Reserved Reserved. This error is reserved by the vendor/developer of the software. Contact the David Burdett et al. [Page 174] Internet Draft IOTP/1.0 28 Feb 1999 Value Description vendor/developer of the software for more information See the SoftwareId attribute of the Message Id element in the Transaction Reference Block(section 3.3). XmlNotWellFrmd XML not well formed. The XML document is not well formed. See [XML] for the meaning of "well formed". Even if the XML is not well formed, it should still be scanned to find the Transaction Reference Block so that a properly formed Error Response may be generated. XmlNotValid XML not valid. The XML document is well formed but the document is not valid. See [XML] for the meaning of "valid". Specifically: o the XML document does not comply with the constraints defined in the IOTP document type declaration (see section 11 Open Trading Protocol Data Type Definition), and o the XML document does not comply with the constraints defined in the document type declaration of any additional [XML Namespace] that are declared. As for XML not well formed, attempts should still be made to extract the Transaction Reference Block so that a properly formed Error Response may be generated. ElUnexpected Unexpected element. Although the XML document is well formed and valid, an element is present that is not expected in the particular context according to the rules and constraints contained in this specification. ElNotSupp Element not supported. Although the document is well formed and valid, an element is present that: o is consistent with the rules and constraints contained in this specification, but o is not supported by the IOTP Aware Application which is processing the IOTP Message. ElMissing Element missing. Although the document is well formed and valid, an element is missing that David Burdett et al. [Page 175] Internet Draft IOTP/1.0 28 Feb 1999 Value Description should have been present if the rules and constraints contained in this specification are followed. In this case set the PackagedContent of the Error Component to the type of the missing element. ElContIllegal Element content illegal. Although the document is well formed and valid, the element PackagedContent contains values which do not conform to the rules and constraints contained in this specification. EncapProtErr Encapsulated protocol error. Although the document is well formed and valid, the PackagedContent of an element contains data from an encapsulated protocol which contains errors. AttUnexpected Unexpected attribute. Although the XML document is well formed and valid, the presence of the attribute is not expected in the particular context according to the rules and constraints contained in this specification. AttNotSupp Attribute not supported. Although the XML document is well formed and valid, and the presence of the attribute in an element is consistent with the rules and constraints contained in this specification, it is not supported by the IOTP Aware Application which is processing the IOTP Message. AttMissing Attribute missing. Although the document is well formed and valid, an attribute is missing that should have been present if the rules and constraints contained in this specification are followed. In this case set the PackagedContent of the Error Component to the type of the missing attribute. AttValIllegal Attribute value illegal. The attribute contains a value which does not conform to the rules and David Burdett et al. [Page 176] Internet Draft IOTP/1.0 28 Feb 1999 Value Description constraints contained in this specification. AttValNotRecog Attribute Value Not Recognised. The attribute contains a value which the IOTP Aware Application generating the message reporting the error could not recognise even though it should have been able to since the information had been provided in an earlier IOTP message. MsgTooLarge Message too large. The message is too large to be processed by the IOTP Aware Application. ElTooLarge Element too large. The element is too large to be processed by the IOTP Aware Application ValueTooSmall Value too small or early. The value of all or part of the PackagedContent of an element or an attribute, although valid, is too small. ValueTooLarge Value too large or in the future. The value of all or part of the PackagedContent of an element or an attribute, although valid, is too large. ElInconsistent Element Inconsistent. Although the document is well formed and valid, according to the rules and constraints contained in this specification: o the content of an element is inconsistent with the content of other elements or their attributes, or o the value of an attribute is inconsistent with the value of one or more other attributes. In this case create ErrorLocation elements which identify all the attributes or elements which are inconsistent. TransportError Transport Error. This error code is used to indicate that there is a problem with the Transport Mechanism which is preventing the message from being received. It is typically associated with a Transient Error. Explanation of the Transport Error is contained within the ErrorDesc attribute. The values which can be used inside ErrorDesc with a TransportError is David Burdett et al. [Page 177] Internet Draft IOTP/1.0 28 Feb 1999 Value Description specified in the IOTP supplement for the Transport mechanism. UnknownError Unknown Error. Indicates that the transaction cannot complete for some reason that is not covered explicitly by any of the other errors. The ErrorDesc attribute should be used to indicate the nature of the problem. This could be used to indicate, for example, an internal error in a backend server or client process of some kind. 6.19.3 Error Location Element An Error Location Element identifies an element and optionally an attribute in the message in error which is associated with the error. It contains a reference to the IOTP Message, Trading Block, Trading Component, element and attribute, which is in error. Attributes: ElementType This is the "type" (see [XML]) of the Element in the message in error where the error is located. OtpMsgRef This is the value of the ID attribute of the of the Message Id Component (see section 3.3.2) of the message in error to which this Error Component applies. BlkRef If the error is associated with a specific Trading Block, then this is the value of the ID attribute of the Trading Block where the error is located. David Burdett et al. [Page 178] Internet Draft IOTP/1.0 28 Feb 1999 CompRef If the error is associated with a specific Trading Component, then this is the value of the ID attribute of the Trading Component where the error is located. ElementRef If the error is associated with a specific element within a Trading Component then, if the element has an attribute with an "attribute type" (see [XML]) of "ID", then this is the value of that attribute. AttName If the error is associated with the value of an attribute, then this is the name of that attribute. In this case the PackagedContent of the Error Component should contain the value of the attribute. Note that as many as the attributes as possible should be included. For example if an attribute in a child element of a Trading Component contains an incorrect value, then all the attributes of ErrorLocation should be present. David Burdett et al. [Page 179] Internet Draft IOTP/1.0 28 Feb 1999 7. Trading Blocks Trading Blocks consist of one or more Trading Components and optionally one or more Signature Components. One or more Trading Blocks may be contained within the IOTP Messages which are physically sent in the form of [XML] documents between the different organisations that are taking part in a trade. This is illustrated in the diagram below. David Burdett et al. [Page 180] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* IOTP MESSAGE <----------- IOTP Message - an XML Document | which is transported between the | Trading Roles |-Trans Ref Block <----- Trans Ref Block - contains | | information which describes the | | IOTP Transaction and the IOTP | | Message. | |-Trans Id Comp. <--- Transaction Id Component - | | uniquely identifies the IOTP | | Transaction. The Trans Id | | Components are the same across | | all IOTP messages that comprise a | | single IOTP transaction. | |-Msg Id Comp. <----- Message Id Component - identifies | and describes an IOTP Message | within an IOTP Transaction |-Signature Block <----- Signature Block (optional) - | | contains one or more Signature | | Components and their associated | | Certificates | |-Signature Comp. <-- Signature Component - contains | | digital signatures. Signatures | | may sign digests of the Trans Ref | | Block and any Trading Component | | in any IOTP Message in the same | | IOTP Transaction. | |-Certificate Comp. <- Certificate Component. Used to | check the signature. ------> |-Trading Block <-------- Trading Block - an XML Element | | |-Component within an IOTP Message that Trading | |-Component contains a predefined set of Blocks | |-Component Trading Components | | |-Component | | |-Component <--------- Trading Components - XML Elements | | within a Trading Block that ------> |-Trading Block contain a predefined set of XML | |-Component elements and attributes | |-Component containing information required | |-Component to support a Trading Exchange | |-Component | |-Component | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 18 Trading Blocks David Burdett et al. [Page 181] Internet Draft IOTP/1.0 28 Feb 1999 Trading Blocks are defined as part of the definition of an IOTP Message (see section 3.1.1). The definition of an IOTP Message element is repeated here: The remainder of this section defines the Trading Blocks in this version of IOTP. They are: o Authentication Request Block o Authentication Response Block o Authentication Status Block o Cancel Block o Delivery Request Block o Delivery Response Block o Error Block o Inquiry Request Block o Inquiry Response Block David Burdett et al. [Page 182] Internet Draft IOTP/1.0 28 Feb 1999 o Offer Response Block o Payment Exchange Block o Payment Request Block o Payment Response Block o Signature Block o Trading Protocol Options Block o TPO Selection Block The Transaction Reference Block is described in section 3.3. 7.1 Trading Protocol Options Block The TPO Trading Block contains options which apply to the IOTP Transaction. The definition of a TPO Trading Block is as follows. Attributes: ID An identifier which uniquely identifies the Trading Protocol Options Block within the IOTP Transaction (see section 3.4 ID Attributes). Content: ProtocolOptions The Protocol Options Component (see section 6.1)defines the options which apply to the whole IOTP Transaction (see section 8). BrandList This Brand List Component contains one or more payment brands and protocols which may be selected (see section 6.6). Org The Organisation Components (see section 6.5) identify the organisations and their roles in the IOTP Transaction. The roles and organisations which must be present will depend David Burdett et al. [Page 183] Internet Draft IOTP/1.0 28 Feb 1999 on the particular type of IOTP Transaction. See the definition of each transaction in section 8. Internet Open Trading Protocol Transactions. The TPO Block should contain: o the Protocol Options Component o the Organisation Component with the Trading Role of Merchant o the Organisation Component with the Trading Role of Consumer o optionally, the Organisation Component with the Trading Role of DeliverTo, if there is a Delivery included in the IOTP Transaction o Brand List Components for each payment in the IOTP Transaction o Organisation Components for all the Payment Handlers involved o optionally, Organisation Components for the Delivery Handler (if any) for the transaction o additional Organisation Components that the Merchant may want to include. For example - a Customer Care Provider - an Certificate Authority that offers Merchant "Credentials" or some other warranty on the goods or services being offered. 7.2 TPO Selection Block The TPO Selection Block contains the results of selections made from the options contained in the Trading Protocol Options Block (see section 7.1).The definition of a TPO Selection Block is as follows. Attributes: ID An identifier which uniquely identifies the TPO Selection Block within the IOTP Transaction. Content: David Burdett et al. [Page 184] Internet Draft IOTP/1.0 28 Feb 1999 BrandSelection This identifies the choice of payment brand and payment protocol to be used in a payment within the IOTP Transaction. There is one Brand Selection Component (see section 6.7) for each payment to be made in the IOTP Transaction. The TPO Selection Block should contain one Brand Selection Component for each Brand List in the TPO Block. 7.3 Offer Response Block The Offer Response Block contains details of the goods, services, amount, delivery instructions or financial transaction which is to take place. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Offer Response Block within the IOTP Transaction. Content: Status Contains status information about the business success (see section 4.2) or failure of the generation of the Offer. Note that in an Offer Response Block, a ProcessState of NotYetStarted or InProgress are illegal values. Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 6.4. The Order Component must be present unless the ProcessState attribute of the Status Component is set to Failed. Payment The Payment Components contain information about the payments which are to be made see section David Burdett et al. [Page 185] Internet Draft IOTP/1.0 28 Feb 1999 6.8. Delivery The Delivery Component contains details of the delivery to be made (see section 6.12). TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an OTP Transaction (see section 6.15). The Offer Response Block should contain: o the Order Component for the IOTP Transaction o Payment Components for each Payment in the IOTP Transaction o the Delivery Component the IOTP Transaction requires (if any). 7.4 Authentication Request Block This Authentication Request Block contains the challenge data which is used to obtain information about and optionally authenticate a Consumer by another Trading Role. Its definition is as follows. Attributes ID An identifier which uniquely identifies the Authentication Request Block within the IOTP Transaction. Content AuthData If the Authentication Data Component is not present it means that the Authentication Request Block is just requesting the return of Organisation Components which describe the Trading Role that received the Authentication Request Block. If the optional Authentication Data Component (see section 6.2) is present it contains data David Burdett et al. [Page 186] Internet Draft IOTP/1.0 28 Feb 1999 which describes the different types of Authentication the consumer should provide. 7.5 Authentication Response Block The Authentication Response Block contains the response which results from processing the Authentication Request Block. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Authentication Response Block within the IOTP Transaction. Content: AuthResp The Authentication Response Component which contains the results of processing the challenge data in the Authentication Data Component - see section 6.3. Org Organisation Components which contain information corresponding to the Trading Roles as requested by the TradingRoleList attribute of the AuthData component. 7.6 Authentication Status Block The Authentication Status Block indicates the success or failure of the validation of an Authentication Response Block by an Authenticator. Its definition is as follows. Attributes: David Burdett et al. [Page 187] Internet Draft IOTP/1.0 28 Feb 1999 ID An identifier which uniquely identifies the Authentication Status Block within the IOTP Transaction. Content: Status Contains status information about the business success (see section 4.2) or failure of the authentication 7.7 Payment Request Block The Payment Request Block contains information which requests that a payment is started. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Payment Request Block within the IOTP Transaction. Content: Status Contains the Status Components (see section 6.12) of the responses of the steps (e.g. an Offer Response and/or a Payment Response) on which this step depends. It is used to indicate the success or failure of those steps. Payment should only occur of the previous steps were successful. BrandList The Brand List Component contains a list of one or more payment brands and protocols which may be selected (see section 6.6). BrandSelection This identifies the choice of payment brand, the payment protocol and the payment handler to be used in a payment within the IOTP Transaction. There is one Brand Selection Component (see David Burdett et al. [Page 188] Internet Draft IOTP/1.0 28 Feb 1999 section 6.7) for each payment to be made in the IOTP Transaction. Payment The Payment Components contain information about the payment which is being made see section 6.8. PaySchemeData The Payment Scheme Component contains payment scheme specific data see section 6.9. Org The Organisation Component contains details of organisations involved in the payment (see section 6.5). The Organisations present are dependent on the IOTP Transaction and the data which is to be signed. See section 5 Security Considerations for more details. TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an OTP Transaction (see section 6.15). The Payment Request Block should contain: o the Organisation Component with a Trading Role of Merchant o the Organisation Component with the Trading Role of Consumer o the Payment Component for the Payment o the Brand List Component for the Payment o the Brand Selection Component for the Brand List o the Organisation Component for the Payment Handler of the Payment o the Organisation Component (if any) for the Organisation which carried out the previous step, for example another Payment Handler o the Organisation Component for the organisation which is to carry out the next step, if any. This may be, for example, either a Delivery Handler or a Payment Handler. o the Organisation Components for any additional Organisations that the Merchant has included in the Offer Response Block David Burdett et al. [Page 189] Internet Draft IOTP/1.0 28 Feb 1999 o an Optional Payment Scheme Data Component, if required by the Payment Method as defined in the IOTP supplement for the payment method o any Trading Role Data Components that may be required (see section 6.15.1). 7.8 Payment Exchange Block The Payment Exchange Block contains payment scheme specific data which is exchanged between two of the roles in a trade. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Payment Exchange Block within the IOTP Transaction. Content: PaySchemeData This Trading Component contains payment scheme specific data see section 6.9 Payment Scheme Component. 7.9 Payment Response Block This Payment Response Block contains a information about the Payment Status, a Payment Receipt, and an optional payment protocol message. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the David Burdett et al. [Page 190] Internet Draft IOTP/1.0 28 Feb 1999 Payment Response Block within the IOTP Transaction. Content: Status Contains status information about the business success (see section 4.2) or failure of the payment. Note that in a Pay Response Block, a ProcessState of NotYetStarted or InProgress are illegal values. PayReceipt Contains payment scheme specific data which can be used to verify the payment occurred. See section 6.10 Payment Receipt Component. PaySchemeData Contains payment scheme specific data see section, for example a payment protocol message. See 6.9 Payment Scheme Component. PaymentNote Contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer. For example, if a withdrawal or deposit were being made then it could contain information on the remaining balance on the account after the transfer was complete. See section 6.11 Payment Note Component. TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an OTP Transaction (see section 6.15). 7.10 Delivery Request Block The Delivery Request Block contains details of the goods or services which are to be delivered together with a signature which can be used to check that delivery is authorised. Its definition is as follows. Attributes: David Burdett et al. [Page 191] Internet Draft IOTP/1.0 28 Feb 1999 ID An identifier which uniquely identifies the Delivery Request Block within the IOTP Transaction. Content: Status Contains the Status Components (see section 6.12) of the responses of the steps (e.g. a Payment Response) on which this step is dependent. It is used to indicate the success or failure of those steps. Delivery should only occur of the previous steps were successful. Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 6.4. Org The Organisation Components (see section 6.5) identify the organisations and their roles in the IOTP Transaction. The roles and organisations which must be present will depend on the particular type of IOTP Transaction. See the definition of each transaction in section 8. Internet Open Trading Protocol Transactions. Delivery The Delivery Component contains details of the delivery to be made (see section 6.12). TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an OTP Transaction (see section 6.15). The Delivery Request Block contains: o the Organisation Component with a Trading Role of Merchant o the Organisation Component for the Consumer and DeliverTo Trading Roles o the Delivery Component for the Delivery o the Organisation Component for the Delivery Handler. Specifically the Organisation Component identified by the ActionOrgRef attribute on the Delivery Component David Burdett et al. [Page 192] Internet Draft IOTP/1.0 28 Feb 1999 o the Organisation Component (if any) for the Organisation which carried out the previous step, for example a Payment Handler o the Organisation Components for any additional Organisations that the Merchant has included in the Offer Response Block o any Trading Role Data Components that may be required (see section 6.15.1). 7.11 Delivery Response Block The Delivery Response Block contains a Delivery Note containing details on how the goods will be delivered. Its definition is as follows. Note that in a Delivery Response Block a Delivery Status Element with a DeliveryStatusCode of NotYetStarted or InProgress is invalid. Attributes: ID An identifier which uniquely identifies the Delivery Response Block within the IOTP Transaction. Content: Status Contains status information about the business success (see section 4.2) or failure of the delivery. Note that in a Delivery Response Block, a ProcessState of NotYetStarted or InProgress are illegal values. DeliveryNote The Delivery Note Component contains details about how the goods or services will be delivered (see section 6.13). David Burdett et al. [Page 193] Internet Draft IOTP/1.0 28 Feb 1999 7.12 Inquiry Request Trading Block The Inquiry Request Trading Block contains an Inquiry Type Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages. Attributes: ID An identifier which uniquely identifies the Inquiry Request Trading Block within the IOTP Transaction. Content: InquiryType Inquiry Type Component (see section 6.16) that contains the type of inquiry. PaySchemeData Payment Scheme Component (see section 6.9) that contains payment scheme specific inquiry messages for inquiries on payments. This is present when the Type attribute of Inquiry Type Component is Payment. 7.13 Inquiry Response Trading Block The Inquiry Response Trading Block contains a Status Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages. Its purpose is to enquire on the current status of an IOTP transaction at a server. Attributes: ID An identifier which uniquely identifies the Inquiry Response Trading Block within the IOTP Transaction. David Burdett et al. [Page 194] Internet Draft IOTP/1.0 28 Feb 1999 LastReceivedOtpMsg Contains an Element Reference (see section 3.5) Ref to the Message Id Component (see section 3.3.2) of the last message this server has received from the Consumer. If there is no previously received message from the Consumer in the pertinent transaction, this attribute should be contain the value Null. This attribute exists for debugging purposes. LastSentOtpMsgRef Contains an Element Reference (see section 3.5) to the Message Id Component (see section 3.3.2) of the last message this server has sent to the Consumer. If there is no previously sent message to the Consumer in the pertinent transaction, this attribute should contain the value Null. This attribute exists for debugging purposes. Content: Status Contains status information about the business success (see section 4.2) or failure of a certain trading exchange (i.e., Offer, Payment, or Delivery). PaySchemeData Payment Scheme Component (see section 6.9) that contains payment scheme specific inquiry messages for inquiries on payments. This is present when the Type attribute of StatusType attribute of the Status Component is set to Payment. 7.14 Ping Request Block The Ping Request Block is used to determine if a Server is operating and whether or not cryptography is compatible. The definition of a Ping Request Block is as follows. Attributes: David Burdett et al. [Page 195] Internet Draft IOTP/1.0 28 Feb 1999 ID An identifier which uniquely identifies the Ping Request Trading Block within the IOTP Transaction. Content: Org Optional Organisation Components (see section 6.5). If no Organisation Component is present then the Ping Request is anonymous and simply determines if the server is operating. However if Organisation Components are present, then it indicates that the sender of the Ping Request wants to verify that digital signatures can be handled. In this case the sender includes: o an Organisation Component that identifies itself specifying the Trading Role(s) it is taking in IOTP transactions (Merchant, Payment Handler, etc) o an Organisation Component that identifies the intended recipient of the message. These are then used to generate a signature over the Ping Response Block. 7.15 Ping Response Block The Ping Response Trading Block provides the result of a Ping Request. It contains an Organisation Component that identifies the sender of the Ping Response. If the Ping Request to which this block is a response contained Organisation Components, then it also contains those Organisation Components. David Burdett et al. [Page 196] Internet Draft IOTP/1.0 28 Feb 1999 Attributes: ID An identifier which uniquely identifies the Ping Request Trading Block within the IOTP Transaction. PingStatusCode Contains a code which shows the status of the sender software which processes IOTP messages. Valid values are: o Ok. Everything with the service is working normally, including the signature verification. o Busy. Things are working normally but there may be some delays. o Down. The server is not functioning fully but can still provide a Ping response. SigVerifyStatusCode Contains a code which shows the status of signature verification. This is present only when the message containing the Ping Request Block also contains a Signature Block. Valid values are: o Ok. The signature has successfully been verified and proved compatible. o NotSupported The receiver of this Ping Request Block does not support validation of signatures. o Fail. Signature verification failed. Xml:lang Defines the language used in PingStatusDesc. This is present when PingStatusDesc is present. PingStatusDesc Contains a short description of the status of the server which sends this Ping Response Block. Servers, if their designers want, can use this attribute to send more refined status information than PingStatusCode which can be used for debugging purposes, for example. David Burdett et al. [Page 197] Internet Draft IOTP/1.0 28 Feb 1999 Content: Org These are Organisation Components (see section 6.5). The Organisation Components of the sender of the Ping Response is always included in addition to the Organisation Components sent in the Ping Request. [Note] Ping Status Code values do not include a value such as Fail, since, when the software receiving the Ping Request message is not working at all, no Ping Response message will be sent back. [Note End] 7.16 Signature Block The Signature Block contains one or more Signature Components and associated Certificates which sign data associated with the IOTP Transaction. For a general discussion and introduction to how IOTP uses signatures, see section 5 Security Considerations. The definition of the Signature Component and certificates is contained in the paper "Digital Signature for XML - Proposal", see [XMLDSIG]. Descriptions of how these are used by IOTP is contained in sections 6.17 and 6.18. The definition of a Signature Block is as follows: Attributes: ID An identifier which uniquely identifies the Signature Block within the IOTP Transaction. Content: Signature A Signature Component. See section 6.17. Certificate A Certificate Component. See section 6.18. The contents of a Signature Block depends on the Trading Block that is contained in the same IOTP Message as the Signature Block. David Burdett et al. [Page 198] Internet Draft IOTP/1.0 28 Feb 1999 7.16.1 Offer Response A Signature Block which is in the same message as an Offer Response Block contains just an Offer Response Signature Component (see section 6.17.2). 7.16.2 Payment Request A Signature Block which is in the same message as a Payment Request Block contains: o an Offer Response Signature Component (see section 6.17.2), and o if the Payment is dependent on an earlier step (as indicated by the StartAfter attribute on the Payment Component), then the Payment Receipt Signature Component (see section 6.17.3) generated by the previous step 7.16.3 Payment Response A Signature Block which is in the same message as a Payment Response Block contains just a Payment Receipt Signature Component (see section 6.17.3) generated by the step. 7.16.4 Delivery Request A Signature Block which is in the same message as a Delivery Request Block contains: o an Offer Response Signature Component (see section 6.17.2), and o the Payment Receipt Signature Component (see section 6.17.3) generated by the previous step. 7.17 Error Block The Error Trading Block contains one or more Error Components (see section 6.19) which contain information about Technical Errors (see section 4.1) in an IOTP Message which has been received by one of the Trading Roles involved in the trade. David Burdett et al. [Page 199] Internet Draft IOTP/1.0 28 Feb 1999 For clarity two phrases are defined which are used in the description of an Error Trading Block: o message in error. An IOTP message which contains or causes an error of some kind o message reporting the error. An IOTP message that contains an Error Trading Block that describes the error found in a message in error. An Error Trading Block may be contained in any message reporting the error. The action which then follows depends on the severity of the error. See the definition of an Error Component, for an explanation of the different types of severity and the actions which can then occur. [Note] Although, an Error Trading Block can report multiple different errors using multiple Error Components, there is no obligation on a developer of an IOTP Aware Application to do so. [Note End] The structure of an Error Trading Block is as follows. Attributes: ID An identifier which uniquely identifies the Error Trading Block within the IOTP Transaction. Content: ErrorComp An Error Components (see section 6.19) that contains information about an individual Technical Error. PaySchemeData An optional Payment Scheme Component (see section 6.9) which contains a Payment Scheme Message. See the appropriate payment scheme supplement to determine whether or not this component needs to be present and for the definition of what it must contain. David Burdett et al. [Page 200] Internet Draft IOTP/1.0 28 Feb 1999 7.18 Cancel Block The Cancel Block is used to inform a non-Consumer role such as a Merchant, Payment Handler or Delivery Handler that a transaction has been cancelled by the Consumer. It's main purpose is to allow the server to close down the transaction without a waiting for a time-out to occur. Its definition is as follows. Attributes: ID An identifier which uniquely identifies the Cancel Block within the IOTP Transaction. Content: Status Contains status information indicating that the IOTP transaction has been cancelled. David Burdett et al. [Page 201] Internet Draft IOTP/1.0 28 Feb 1999 8. Internet Open Trading Protocol Transactions The Baseline Open Trading Protocol supports four types of transactions for different purposes. These are o an Authentication IOTP transaction which supports authentication of one party in a trade by another o IOTP Transactions that involve one or more payments. Specifically: - Deposit - Purchase - Refund - Withdrawal, and - Value Exchange o IOTP Transactions designed to check the correct function of the IOTP infrastructure. Specifically: - Transaction Status Inquiry, and - Ping Although the Authentication IOTP Transaction can operate on its own, authentication can optionally precede any of the _payment_ transactions. Therefore, the rest of this section is divided into two parts covering: o Authentication and Payment transactions (Authentication, Deposit, Purchase, Refund, Withdrawal and Value Exchange) o Infrastructure Transactions (Transaction Status Inquiry and Ping) that are designed to support inquiries on whether or not a transaction has succeeded or a Trading Role's servers are operating correctly, and 8.1 Authentication and Payment Related IOTP Transactions The Authentication and Payment related IOTP Transactions consist of six Document Exchanges which are then combined in sequence to implement a specific transaction. Generally, there is a close, but not exact, correspondence between a Document Exchange and a Trading Exchange. The main difference is that some Document Exchanges implement part or all of two Trading Exchanges David Burdett et al. [Page 202] Internet Draft IOTP/1.0 28 Feb 1999 simultaneously in order to minimise the number of actual OTP Messages which must be sent over the Internet. The six Document Exchanges are: o Authentication. This is a direct implementation of the Authentication Trading Exchange o Brand Dependent Offer. This is the Offer Trading Exchange combined with the Brand Selection part of the Payment Trading Exchange. Its purpose is to provide the Merchant with information on the Brand selected so that the content of the Offer Response may be adapted accordingly o Brand Independent Offer. This is also an Offer Trading Exchange. However, in this instance, the content of the Offer Response does depend on the Brand selected. o Payment. This is a direct implementation of the Payment part of a Payment Trading Exchange o Delivery. This is a direct implementation of the Delivery Exchange o Delivery with Payment. This is an implementation of combined Payment and Delivery Trading Exchanges These Document Exchanges are combined together in different sequences to implement each IOTP Transaction. The way in which they may be combined is illustrated by the diagram below. David Burdett et al. [Page 203] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | | | -------------- | ------------- | v v v v | ------------------- ----------------- | | BRAND INDEPENDENT | | BRAND DEPENDENT | | | OFFER | | OFFER | | ------------------- ----------------- | | | | | | | --------------- | | | | | | | | | -------------- | -- | | v v v v | --------- -------------- | | PAYMENT | | PAYMENT WITH | | | (first) | | DELIVERY | | --------- -------------- | | | | ----------------------------- | | v v | | | ---------- --------- | | | | DELIVERY | | PAYMENT | | | | | | | {second)| | | | ---------- --------- | | | | | | | v ----------------------------------------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 19 Payment and Authentication Message Flow Combinations The combinations of Document Exchanges that are valid depend on the particular IOTP transaction. The remainder of this sub-section describes: o each Document Exchange in more detail including descriptions of the content of each Trading Block in the Document Exchanges, and David Burdett et al. [Page 204] Internet Draft IOTP/1.0 28 Feb 1999 o descriptions of how each IOTP Transaction uses the Document Exchange to effect the desired result. [Note] The descriptions of the Document Exchanges which follow describe the ways in which various Business Errors (see section 4.2) are handled. No reference is made however to the handling of Technical Errors (see section 4.1) in any of the messages since these are handled the same way irrespective of the context in which the message is being sent. See section 4 for more details. [Note End] 8.1.1 Authentication Document Exchange The Authentication Document Exchange is a direct implementation of the Authentication Trading Exchange (see section 2.2.4). It involves: o an Authenticator - the organisation which is requesting the authentication, and o an Authenticatee - the organisation being authenticated. The authentication consists of: o an Authentication Request being sent by the Authenticator to the Authenticatee, o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and o an Authentication Status being sent by the Authenticator to the Authenticatee to provide an indication of the success or failure of the authentication. An Authentication Document Exchange also: o provides an Authenticatee with an Organisation Component which describes the Authenticator, and o optionally provides the Authenticator with Organisation Components which describe the Authenticatee. The Authentication Request may also be digitally signed which allows the Authenticatee to verify the credentials of the Authenticator. David Burdett et al. [Page 205] Internet Draft IOTP/1.0 28 Feb 1999 The IOTP Messages which are involved are illustrated by the diagram below. David Burdett et al. [Page 206] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* ORGANISATION 1 IOTP MESSAGE ORGANISATION 2 (AUTHENTICATEE) (AUTHENTICATOR) 1. First organisation 2. The second takes an action (for organisation generates example by pressing a ---------------------> an Authentication button on an HTML Authentication Need Request Block page) which requires (outside scope of containing challenge that the organisation IOTP) data and list of the is authenticated Algorithms that may be used then sends it to the first organisation | v 3. IOTP aware application IotpMsg:Trans started. If a Signature Block <-------------------- Ref Block; is present the first TPO & Signature organisation may use this to Authentication Block; TPO check the credentials of the Request Block; Auth. second organisation. If it is Request Block; OK the first organisation selects an Algorithm then uses the challenge data and the authentication method selected from the Authentication Request Block to generate an Authentication Response Block and optional Organisation and Signature Components which are sent back to the second organisation for validation. | v IotpMsg: Trans 4. The second organisation Ref Block; ----------------------> checks the Authentication Signature Authentication Response Response against the Block; Auth challenge data in the Response Block; Authentication Request Block Organisation Block to check that the first | organisation is who they v appear to be, and sends an STOP Authentication Status Block to the first Organisation to indicate the Result then stops. David Burdett et al. [Page 207] Internet Draft IOTP/1.0 28 Feb 1999 | v 5. The first organisation IotpMsg: Trans checks the Authentication <-------------------- Ref Block; Status Block and optionally Authentication Status Signature Block; keeps information on the IOTP Auth Response Transaction for record Block keeping purposes and stops. | v v STOP STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 20 Authentication Document Exchange 8.1.1.1 Message Processing Guidelines On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either: o generate and send an Authentication Response IOTP Message back to the Authenticator, or o indicate failure to comply with the Authentication Request by sending a Cancel Block back to the Authenticator containing a Status Component with a StatusType of Authentication a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: AutEeCancel, NoAuthData, TradRolesIncon or Unspecified. On receiving an Authentication Response IOTP Message (see below), an Authenticator should send in return, an Authentication Status IOTP Message (see below) containing a Status Block with a Status Component where the StatusType is set to Authentication, and: o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or o the ProcessState attribute is set to Failed and the CompletionCode attribute is set to either: AutOrCancel, AuthFailed or Unspecified which indicates a failed authentication, On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates: David Burdett et al. [Page 208] Internet Draft IOTP/1.0 28 Feb 1999 o a successful authentication, then the Authenticatee should either: - continue with the next step in the IOTP Transaction of which the Authentication Document Exchange is part (if any), or - indicate a failure to continue with the rest of the IOTP Transaction, by sending back to the Authenticator a Cancel block containing a Status Component with a StatusType of Authentication, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to AutEeCancel. o a failed authentication, then the failure should be reported to the Authenticatee and any further processing stopped. If the Authenticator receives an IOTP Message containing a Cancel block, then the Authenticatee is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Authenticator contained in the Authentication Request Block. 8.1.1.2 TPO & Authentication Request IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of: o a Trading Protocol Options Block (see section 7.1) o an Authentication Request Block (see section 7.4), and o an optional Signature Block (see section 7.16). Each of these are described below. TRADING PROTOCOL OPTIONS BLOCK The Trading Protocol Options Block (see section 7.1) must contain the following Trading Components: o one Protocol Options Component (see Section 6.1) which defines the options which apply to the whole Authentication Document Exchange. o one Organisation Component (see section 6.5) which describes the Authenticator. The Trading Role on the Organisation Component should indicate the role which the Authenticator is taking in the Trade, for example a Merchant or a Consumer. David Burdett et al. [Page 209] Internet Draft IOTP/1.0 28 Feb 1999 AUTHENTICATION REQUEST BLOCK The Authentication Request Block (see section 7.4) must contain the following Trading Components: o one Authentication Data Component (see section 6.2), and SIGNATURE BLOCK (AUTHENTICATION REQUEST) If the Authentication Request is being digitally signed then a Signature Block must be included. It contains Digests of the following XML elements: o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the TPO Block : - the Protocol Options Component - the Organisation Component o the following components of the Authentication Request Block: - the Authentication Data Component 8.1.1.3 Authentication Response IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of: o an Authentication Response Block (see section 7.5), and o an optional Signature Block (see section 7.16). Each of these are described below. AUTHENTICATION RESPONSE BLOCK The Authentication Response Block must contain the following Trading Component: o one Authentication Response Component (see section 6.3) David Burdett et al. [Page 210] Internet Draft IOTP/1.0 28 Feb 1999 o one Organisation Component for every Trading Role identified in the TradingRoleList attribute of the Authentication Data Component contained in the Authentication Request Block. SIGNATURE BLOCK (AUTHENTICATION RESPONSE) If the AuthMethod attribute of the Authentication Data Component contained in the Authentication Request Block indicates that the Authentication Response should consist of a digital signature then a Signature Block must be included in the same IOTP message that contains an Authentication Response Block. The Signature Component contains Digest Elements for the following XML elements: o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the Authentication Request Block: - the Authentication Data Component o the Organisation Components contained in the Authentication Response Block [Note] It should not be assumed that all trading roles can support the signing of data. Particularly it should not be assumed that Consumers support the signing of data. [Note End] 8.1.1.4 Authentication Status IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of: o an Authentication Status Block (see section 7.5), and o an optional Signature Block (see section 7.16). Each of these are described below. AUTHENTICATION STATUS BLOCK The Authentication Status Block (see section 7.6) must contain the following Trading Components: David Burdett et al. [Page 211] Internet Draft IOTP/1.0 28 Feb 1999 o one Status Component (see section 6.14) with a ProcessState attribute set to CompletedOk. SIGNATURE BLOCK (AUTHENTICATION STATUS) If the Authentication Status Block is being digitally signed then a Signature Block must be included that contains a Signature Component with Digest elements for the following XML elements: o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the Authentication Status Block: - the Status Component (see section 6.14). [Note] If the Authentication Document Exchange is followed by an Offer Document Exchange (see section 8.1.2) then the Authentication Status Block and the Signature Block (Authentication Status) may be combined with either: o a TPO IOTP Message (see section 8.1.2.3), or o a TPO and Offer Response IOTP Message (see section 8.1.2.6) [Note End] 8.1.2 Offer Document Exchange The Offer Document Exchange occurs in two basic forms: o Brand Dependent Offer Exchange. Where the content of the offer, e.g. the order details, amount, delivery details, etc., are dependent on the payment brand and protocol selected by the consumer, and o Brand Independent Offer Exchange. Where the content of the offer is not dependent on the payment brand and protocol selected. Each of these types of Offer Document Exchange may be preceded by an Authentication Document Exchange (see section 8.1.1). David Burdett et al. [Page 212] Internet Draft IOTP/1.0 28 Feb 1999 8.1.2.1 Brand Dependent Offer Document Exchange In a Brand Dependent Offer Document Exchange the TPO Block and the Offer Response Block are sent separately by the Merchant to the Consumer, i.e.: o the Brand List Component is sent to the Consumer in a TPO Block, o the Consumer selects a Payment Brand, Payment Protocol and optionally a Currency and amount from the Brand List Component o the Consumer sends the selected brand, protocol and currency/amount back to the Merchant in a TPO Selection Block, and o the Merchant uses the information received to define the content of and then send the Offer Response Block to the Consumer. This is illustrated by the diagram below. David Burdett et al. [Page 213] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE MERCHANT 1. Consumer decides 2. Merchant decides which to trade and sends payment brand protocols , information that -------------------> curencies and amounts enables the Merchant Offer Information apply, places them in a to create an offer (outside scope of Brand List Component in a to the Merchant, IOTP) TPO Block, and sends to e.g. using HTML Consumer | v 3. IOTP aware application IotpMsg:Trans started. Consumer selects the <------------------- Ref Block; TPO payment brand, payment protocol TPO Block and currency/amount to use, records selection in a Brand Selection Component, and sends back to Merchant | v IotpMsg: Trans 4. Merchant uses selected Ref Block; TPO --------------------> payment brand, payment Selection Block TPO Selection protocol, currency/amount and the offer information to create an Offer Response Block containing details about the IOTP Transaction including price, etc. optionally signs it and sends to Consumer | v 5. Consumer checks Offer is OK, IotpMsg: Trans combines components from the TPO Ref Block; Block, the TPO Selection Block and <---------------- Signature the Offer Response Block to create Offer Response Block; Offer the next IOTP Message for the Response Block Transaction and sends it together with the Signature Block if present to the required Trading Role | v CONTINUED *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 21 Brand Dependent Offer Document Exchange David Burdett et al. [Page 214] Internet Draft IOTP/1.0 28 Feb 1999 Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by the absence of an Offer Response Block in the first IOTP Message. MESSAGE PROCESSING GUIDELINES On receiving a TPO IOTP Message (see below), the Consumer may either: o generate and send a TPO Selection IOTP Message back to the Merchant, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Merchant containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: ConsCancelled or Unspecified. On receiving a TPO Selection IOTP Message (see below) the Merchant may either: o generate and send an Offer Response IOTP Message back to the Consumer, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: MerchCancelled or Unspecified. On receiving an Offer Response IOTP Message (see below) the Consumer may either: o generate and send the next IOTP Message in the IOTP transaction and send it to the required Trading Role. This is dependent on the IOTP Transaction, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: ConsCancelled or Unspecified. If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant. David Burdett et al. [Page 215] Internet Draft IOTP/1.0 28 Feb 1999 If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken. 8.1.2.2 Brand Independent Offer Document Exchange In a Brand Independent Offer Document Exchange the TPO Block and the Offer Response Block are sent together by the Merchant to the Consumer, i.e. there is one IOTP Message that contains both a TPO Block, and an Offer Response Block. The message flow is illustrated by the diagram below: David Burdett et al. [Page 216] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE MERCHANT 1. Consumer 2. Merchant decides which decides to payment brand, protocols , trade and sends --------------------> currencies and amounts apply, information Offer Information places them in a Brand List that enables (outside scope of Component in a TPO Block, the Merchant to IOTP) creates an Offer Response create an offer Block containing details about to the the IOTP Transaction including Merchant, e.g. price, etc, optionally signs using HTML it and sends to Consumer | v 3. IOTP aware application IotpMsg: Trans Ref started. Consumer selects the <------------- Block; Signature payment brand and payment TPO & Block; TPO Block; protocol to use, records Offer Response Offer Response Block selection in a Brand Selection Component, checks Offer is OK, combines the Brand Selection Component with information from the TPO Block and Offer Response Block to create the next IOTP Message for the Transaction and sends it together with the Signature Block if present to the required Trading Role | v CONTINUED *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 22 Brand Independent Offer Exchange Note that a Brand Independent Offer Document Exchange always occurs when only one payment brand, protocol and currency/amount is being offered to the Consumer by the Merchant. It is also likely to, but will not necessarily, occur when multiple brands are being offered, the Payment Handler is the same, and all brands use the same set of protocols. Note that the TPO Block and the Offer Response Block can be sent in separate IOTP messages (see Brand Dependent Offer Document Exchange) David Burdett et al. [Page 217] Internet Draft IOTP/1.0 28 Feb 1999 even if the Offer Response Block does not change. However this increases the number of messages in the transaction and is therefore likely to increase transaction response times. IOTP aware applications supporting the Consumer Trading Role must check for the existence of an Offer Response Block in the first IOTP Message to determine whether the Offer Document Exchange is brand dependent or not. MESSAGE PROCESSING GUIDELINES On receiving a TPO and Offer Response IOTP Message (see below), the Consumer may either: o generate and send the next IOTP Message in the IOTP transaction and send it to the required Trading Role. This is dependent on the IOTP Transaction, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Merchant containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 6.14.1) set to either: ConsCancelled or Unspecified. If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant. 8.1.2.3 TPO IOTP Message The TPO IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of just a Trading Protocol Options Block (see section 7.1) which is described below. TPO (TRADING PROTOCOL OPTIONS) BLOCK The Trading Protocol Options Block must contain the following Trading Components: o one Protocol Options Component which defines the options which apply to the whole IOTP Transaction. See Section 6.1. o one Brand List Component (see section 6.6) for each Payment in the IOTP Transaction that contain one or more payment brands and protocols which may be selected for use in each payment David Burdett et al. [Page 218] Internet Draft IOTP/1.0 28 Feb 1999 o Organisation Components (see section 6.5) with the following roles: - Merchant who is making the offer - Consumer who is carrying out the transaction - the PaymentHandler(s) for the payment. The "ID" of the Payment Handler Organisation Component is contained within the PhOrgRef attribute of the Payment Component If the IOTP Transaction includes a Delivery then the TPO Block must also contain: o Organisation Components with the following roles: - DeliveryHandler who will be delivering the goods or services - DelivTo i.e. the person or organisation which is to take delivery AUTHENTICATION STATUS AND SIGNATURE BLOCKS If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO IOTP Message may also contain: o an Authentication Status Block (see section 7.6), and o an optional Signature Block (Authentication Status) Signature Block See section 8.1.1.4 Authentication Status IOTP Message for more details. 8.1.2.4 TPO Selection IOTP Message The TPO Selection IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of just a TPO Selection Block (see section 7.1) which is described below. TPO SELECTION BLOCK The TPO Selection Block (see section 7.2) contains: o one Brand Selection Component (see section 6.7) for use in a later Payment Exchange. It contains the results of the consumer selecting a Payment Brand, Payment Protocol and currency/amount from the list provided in the Brand List Component. David Burdett et al. [Page 219] Internet Draft IOTP/1.0 28 Feb 1999 8.1.2.5 Offer Response IOTP Message The Offer Response IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of: o an Offer Response Block (see section 7.1) and o an optional Signature Block (see section 7.16). OFFER RESPONSE BLOCK The Offer Response Block (see section 7.3) contains the following components: o one Status Component (see section 6.14) which indicates the status of the Offer Response. The ProcessState attribute should be set to CompletedOk o one Order Component (see section 6.4) which contains details about the goods and services which are being purchased or the financial transaction which is taking place o one or more Payment Component(s) (see section 6.8) for each payment which is to be made o zero or one Delivery Components (see section 6.12) containing details of the delivery to be made if the IOTP Transaction includes a delivery o zero or more Trading Role Data Components (see section 6.15) if required by the Merchant. SIGNATURE BLOCK (OFFER RESPONSE) If the Authentication Status Block is being digitally signed then a Signature Block must be included that contains a Signature Component (see section 6.17) with Digest Elements for the following XML elements: If the Offer Response is being digitally signed then a Signature Block must be included that contains a Signature Component (see section 6.17) with Digest Elements for the following XML elements: o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction David Burdett et al. [Page 220] Internet Draft IOTP/1.0 28 Feb 1999 o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction o the following components of the TPO Block : - the Protocol Options Component, and - the Brand List Component - all the Organisation Components present o the following components of the Offer Response Block: - the Order Component - all the Payment Components present - the Delivery Component if present - any Trading Role Data Components present 8.1.2.6 TPO and Offer Response IOTP Message The TPO and Offer Response IOTP Message is only used with a Brand Independent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of: o a Trading Protocol Options Block (see section 7.1) o an Offer Response Block (see section 7.1) and o an optional Signature Block (see section 7.16). TPO (TRADING PROTOCOL OPTIONS) BLOCK This is the same as the Trading Protocol Options Block described in TPO IOTP Message (see section 8.1.2.3). OFFER RESPONSE BLOCK This the same as the Offer Response Block in the Offer Response IOTP Message (see section 8.1.2.5). AUTHENTICATION STATUS If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO and Offer Response IOTP Message may also contain an Authentication Status Block (see section 7.6). SIGNATURE BLOCK This is the same as the Signature Block in the Offer Response IOTP Message (see section 8.1.2.5) with the addition that: David Burdett et al. [Page 221] Internet Draft IOTP/1.0 28 Feb 1999 o if the Offer Document Exchange is Brand Dependent then the Signature Component in the Signature Block additionally contains a Digest Element for the Brand Selection Component contained in the TPO Selection Block o if the Offer Document Exchange was preceded by an Authentication Document Exchange then the Signature Component in the Signature Block additionally contains a Digest Element for the Authentication Status Block. 8.1.3 Payment Document Exchange The Payment Document Exchange is a direct implementation of the last part of a Payment Trading Exchange (see section 2.2.2) after the Brand has been selected by the Consumer. A Payment Exchange consists of: o the Consumer requesting that a payment starts by generating Payment Request IOTP Message using information from previous IOTP Messages in the Transaction and then sending it to the Payment Handler o the Payment Handler and the Consumer then swapping Payment Exchange IOTP Messages encapsulating payment protocol messages until the payment is complete, and finally o the Payment Handler sending a Payment Response IOTP Message to the Consumer containing a receipt for the payment. David Burdett et al. [Page 222] Internet Draft IOTP/1.0 28 Feb 1999 The IOTP Messages which are involved are illustrated by the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE PAYMENT HANDLER 1. Consumer generates Pay Request Block encapsulating a payment protocol message if required and sends to Payment Handler with the Signature Block if present | v IotpMsg: Trans 2. Payment Handler processes Pay Ref Block; -------------> Request Block, checks optional Signature Block; Payment signature and starts exchanging ay Request Block Request payment protocol messages, encapsulated in a Pay Exchange Block, with the Consumer | v Consumer keeps <- ----->IotpMsg: IotpMsg: Trans on exchanging Pay Trans Ref <-----------------> Ref Block; Pay xchange Blocks with Block; Pay Payment Exchange Exchange Block Payment Handler Exchange Block | v 4. Eventually payment protocol messages finish so Payment Handler creates Pay Receipt Component inside a Pay Response Block, and an optional Signature Component inside the Signature Block, sends to Consumer and stops | v 5. Consumer checks Pay Response is IotpMsg: Trans OK. Optionally keeps information on <--------------- Ref Block; OTP Transaction for record keeping Payment Response Signature Block purposes and either stops or Pay Response creates the next IOTP Message for Block the Transaction and sends it together with the Signature Block if present to the required Trading Role *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* David Burdett et al. [Page 223] Internet Draft IOTP/1.0 28 Feb 1999 Figure 23 Payment Document Exchange 8.1.3.1 Message Processing Guidelines On receiving a Payment Request IOTP Message, the Payment Handler should check that they are authorised to carry out the Payment (see section 5 Security Considerations). They may then either: o generate and send a Payment Exchange IOTP Message back to the Consumer, if more payment protocol messages need to be exchanged, or o generate and send a Payment Response IOTP Message if the exchange of payment protocol messages is complete, or o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument or Unspecified. On receiving a Payment Exchange IOTP Message, the Consumer may either: o generate and send a Payment Exchange Message back to the Payment Handler or o indicate failure to continue with the Payment by sending a Cancel Block back to the Payment Handler containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 6.14.2) set to either: ConsCancelled or Unspecified. On receiving a Payment Exchange IOTP Message, the Payment Handler may either: o generate and send a Payment Exchange IOTP Message back to the Consumer, if more payment protocol messages need to be exchanged, or o generate and send a Payment Response IOTP Message if the exchange of payment protocol messages is complete, or o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component David Burdett et al. [Page 224] Internet Draft IOTP/1.0 28 Feb 1999 with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 6.14.2) set to either: PaymtCancelled or Unspecified. On receiving a Payment Response IOTP Message, the Consumer may either: o generate and send the next IOTP Message in the IOTP transaction and send it to the required Trading Role. This is dependent on the IOTP Transaction, o stop, since the IOTP Transaction has ended, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Merchant containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 6.14.1) set to either: ConsCancelled or Unspecified. If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken. If the Payment Handler receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Payment Handler from which any further action may take place. If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer should have completed the payment but not continuing with the transaction for some reason. In this case the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant from which any further action may take place. 8.1.3.2 Payment Request IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of: o a Payment Request Block, and o an optional Signature Block PAYMENT REQUEST BLOCK The Payment Request Block (see section 7.7) contains: David Burdett et al. [Page 225] Internet Draft IOTP/1.0 28 Feb 1999 o the following components copied from the Offer Response Block from the preceding Offer Document Exchange: - the Status Component - the Payment Component for the payment which is being carried out - the Organisation Components with the roles of Merchant and for the PaymentHandler that is being sent the Payment Request Block o the following component from the TPO Block: - the Brand List Component for the payment, i.e. the Brand List referred to by the BrandListRef attribute on the Payment Component o one Brand Selection Component for the Brand List, i.e. the Brand Selection Component where BrandListRef attribute points to the Brand List. This component can be either: - copied from the TPO Selection Block if the payment was preceded by a Brand Dependent Offer Document Exchange (see section 8.1.2.1), or - created by the Consumer, containing the payment brand, payment protocol and currency/amount selected from the Brand List, if the payment was preceded by a Brand Independent Offer Document Exchange (see section 8.1.2.2) o an optional Payment Scheme Component (see section 6.9) if required by the payment method used (see the Payment Method supplement to determine if this is needed). o zero or more Trading Role Data Components (see section 6.15). Note that: o if there is more than one Payment Components in an Offer Response Block, then the second payment is the one within the Offer Response Block that contains a StartAfter attribute (see section 6.8) that identifies the Payment Component for the first payment o the Payment Handler to include is identified by the Brand Selection Component (see section 6.7) for the payment. Also see section 5.3.1 Check the Action Request was sent to the Correct Organisation for an explanation on how Payment Handlers are identified o the Brand List Component to include is the one identified by the BrandListRef attribute of the Payment Component for the identified payment David Burdett et al. [Page 226] Internet Draft IOTP/1.0 28 Feb 1999 o the Brand Selection Component to include from the Offer Response Block is the one that contains an BrandListRef attribute (see section 3.5) which identifies the Brand List Component for the second payment. SIGNATURE BLOCK (PAYMENT REQUEST) If the either the preceding Offer Document Exchange included an Offer Response Signature (see section 8.1.2.5 Offer Response IOTP Message), or a preceding Payment Exchange included a Payment Response Signature (see section 8.1.3.4 Payment Response IOTP Message) then they should both be copied to the Signature Block in the Payment Request IOTP Message. 8.1.3.3 Payment Exchange IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of just a Payment Exchange Block. PAYMENT EXCHANGE BLOCK The Payment Exchange Block (see section 7.8) contains: o one Payment Scheme Component (see section 6.9) which contains payment method specific data. See the Payment Method supplement for the payment method being used to determine what this should contain. 8.1.3.4 Payment Response IOTP Message Apart from a Transaction Reference Block (see section 3.3), this message consists of: o a Payment Response Block, and o an optional Signature Block PAYMENT RESPONSE BLOCK The Payment Response Block (see section 7.9) contains: o one Payment Receipt Component (see section 6.10) which contains scheme specific data which can be used to verify the payment occurred o one Payment Scheme Component (see section 6.9) if required which contains payment method specific data. See the Payment David Burdett et al. [Page 227] Internet Draft IOTP/1.0 28 Feb 1999 Method supplement for the payment method being used to determine what this should contain o an optional Payment Note Component (see section 6.11) o zero or more Trading Role Data Components (see section 6.15). SIGNATURE BLOCK (PAYMENT RESPONSE) If a signed Payment Receipt is being provided, indicated by the SignedPayReceipt attribute of the Payment Component being set to True, then the Signature Block should contain a Signature Component which contains Digest Elements for the following: o the Transaction Reference Block (see section 3.3) for the IOTP Message which contains the first usage of the Payment Response Block, o the Transaction Id Component (see section 3.3.1) within the Transaction Reference Block that globally uniquely identifies the IOTP Transaction, o the Payment Receipt Component from the Payment Response Block, o the other Components referenced by the PayReceiptRefs attribute (if present) of the Payment Receipt Component, o the Status Component from the Payment Response Block, o any Trading Role Data Components in the Payment Response Block, and o all the Signature Components contained in the Payment Request Block if present. 8.1.4 Delivery Document Exchange The Delivery Document Exchange is a direct implementation of a Delivery Trading Exchange (see section 2.2.3). It consists of: o the Consumer requesting a Delivery by generating Delivery Request IOTP Message using information from previous IOTP Messages in the Transaction and then sending it to the Delivery Handler David Burdett et al. [Page 228] Internet Draft IOTP/1.0 28 Feb 1999 o the Delivery Handler sending a Delivery Response IOTP Message to the Consumer containing details about the Handler's response to the request together with an optional signature. The message flow is illustrated by the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE DELIVERY HANDLER 1. Consumer generates 2. Delivery Handler Delivery Request checks the Status and Block and sends it to ---------------------> Order Components in the the Delivery Handler Delivery Request Delivery Request and with the Signature the optional Block if present Signatures, creates a Delivery Response Block, sends to Consumer and stops | v 3. Consumer checks Delivery IotpMsg:Trans Response Block is OK, <-------------------- Ref Block; optionally keeps information Delivery Response Delivery on IOTP Transaction for Response Block record keeping purposes and stops *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 24 Delivery Document Exchange 8.1.4.1 Message Processing Guidelines On receiving a Delivery Request IOTP Message, the Delivery Handler should check that they are authorised to carry out the Delivery (see section 5 Security Considerations). They may then either: o generate and send a Delivery Response IOTP Message to the Consumer, or o indicate failure to continue with the Delivery by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Delivery, a ProcessState of Failed and the CompletionCode (see section 6.14.4) set to either: DelivCanceled, or Unspecified. David Burdett et al. [Page 229] Internet Draft IOTP/1.0 28 Feb 1999 On receiving a Delivery Response IOTP Message, the Consumer should just stop since the IOTP Transaction is complete. If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken. 8.1.4.2 Delivery Request IOTP Message The Delivery Request IOTP Message consists of: o a Delivery Request Block, and o an optional Signature Block DELIVERY REQUEST BLOCK The Delivery Request Block (see section 7.10) contains: o the following components copied from the Offer Response Block: - the Status Component (see section 6.14) - the Order Component (see section 6.4) - the Organisation Component (see section 6.5) with the roles of: Merchant, DeliveryHandler and DeliverTo - the Delivery Component (see section 6.12) o the following Component from the Payment Response Block: - the Status Component (see section 6.14). o zero or more Trading Role Data Components (see section 6.15). SIGNATURE BLOCK (DELIVERY REQUEST) If the preceding Offer Document Exchange included an Offer Response Signature or the Payment Document Exchange included a Payment Response Signature, then they should both be copied to the Signature Block. 8.1.4.3 Delivery Response IOTP Message The Delivery Response IOTP Message contains a Delivery Response Block and an options Signature Block. DELIVERY RESPONSE BLOCK The Delivery Response Block contains: David Burdett et al. [Page 230] Internet Draft IOTP/1.0 28 Feb 1999 o one Delivery Note Component (see section 6.13) which contains delivery instructions about the delivery of goods or services SIGNATURE BLOCK (DELIVERY RESPONSE) The Signature Block should contain one Signature Component that contains Digest elements that refer to o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Delivery Response Signature o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature o the Signature Components contained in the Delivery Request (if any) o the Status Component o the Delivery Note Component 8.1.5 Payment and Delivery Document Exchange The Payment and Delivery Document Exchange is a combination of the last part of the Payment Trading Exchange (see section 2.2.2) and a Delivery Trading Exchange (see section 2.2.3). It consists of: o the Consumer requesting that a payment starts by generating Payment Request IOTP Message using information from previous IOTP Messages in the Transaction and then sending it to the Payment Handler o the Payment Handler and the Consumer then swapping Payment Exchange IOTP Messages encapsulating payment protocol messages until the payment is complete, and finally o the Payment Handler sending to the Consumer in one IOTP Message: - a Payment Response Block containing a receipt for the payment, and - a Delivery Response Block containing details of the goods or services to be delivered The IOTP Messages which are involved are illustrated by the diagram below. David Burdett et al. [Page 231] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE MERCHANT 1. Consumer generates Pay Request Block encapsulating a payment protocol message if required and sends to Payment Handler with the Signature Block if present | v IotpMsg: Trans 2. Payment Handler processes Pay Ref Block; -------------> Request Block, checks optional Signature Block; Payment signature and starts exchanging ay Request Block Request payment protocol messages, encapsulated in a Pay Exchange Block, with the Consumer | v Consumer keeps <------->IotpMsg: IotpMsg: Trans on exchanging Pay Trans Ref <-----------------> Ref Block; Pay Exchange Blocks with Block; Pay Payment Exchange Exchange Block Payment Handler Exchange Block | v 4. Eventually payment protocol messages finish so Payment Handler creates Pay Receipt Component inside a Pay Response Block and an optional Signature Component, then uses information from the Offer Response Block to create a Delivery Response Block, sends both to Consumer and stops | v 5. Consumer checks Pay Response IotpMsg: Trans and Delivery Response Blocks are <--------------- Ref Block; OK, optionally keeps information Payment Response Signature Block on IOTP Transaction for record & Delivery Pay Response keeping purposes and stops Response Block; Delivery Response Block *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 25 Payment and Delivery Document Exchange David Burdett et al. [Page 232] Internet Draft IOTP/1.0 28 Feb 1999 The Delivery Response Block and the Payment Response Block may be combined into the same IOTP Message only if the Payment Handler has the information available so that she can send the Delivery Response Block. This is likely to, but will not necessarily, occur when the Merchant, the Payment Handler and the Delivery Handler Roles are combined. The DelivAndPayResp attribute of the Delivery Component (see section 6.12) contained within the Offer Response Block (see section 7.3) is set to True if the Delivery Response Block and the Payment Response Block are combined into the same IOTP Message and is set to False if the Delivery Response Block and the Payment Response Block are sent in separate IOTP Messages. 8.1.5.1 Message Processing Guidelines On receiving a Payment Request IOTP Message or a Payment Exchange IOTP Message, the Payment Handler should carry out the same actions as for a Payment Document Exchange (see section 8.1.3.1). On receiving a Payment Exchange IOTP Message, the Consumer should also carry out the same actions as for a Payment Document Exchange (see section 8.1.3.1). On receiving a Payment Response and Delivery Response IOTP Message then the IOTP Transaction is complete and should take no further action. If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken. If the Payment Handler receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Payment Handler from which any further action may take place. If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer should have completed the payment but not continuing with the transaction for some reason. In this case the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant from which any further action may take place. David Burdett et al. [Page 233] Internet Draft IOTP/1.0 28 Feb 1999 8.1.5.2 Payment Request IOTP Message The content of this message is the same as for a Payment Request IOTP Message in a Payment Document Exchange (see section 8.1.3.2) 8.1.5.3 Payment Exchange IOTP Message The content of this message is the same as for a Payment Exchange IOTP Message in a Payment Document Exchange (see section 8.1.3.3). 8.1.5.4 Payment Response and Delivery Response IOTP Message The content of this message consists of: o a Payment Response Block, o an optional Signature Block (Payment Response), and o a Delivery Response Block. PAYMENT RESPONSE BLOCK The content of this block is the same as the Payment Response Block in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 8.1.3.4). SIGNATURE BLOCK (PAYMENT RESPONSE) The content of this block is the same as the Signature Block (Payment Response) in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 8.1.3.4). DELIVERY RESPONSE BLOCK The content of this block is the same as the Delivery Response Block in the Delivery Response IOTP Message associated with a Delivery Document Exchange (see section 8.1.4.3). 8.1.6 Baseline Authentication IOTP Transaction A Baseline Authentication IOTP Transaction may occur at any time between any of the Trading Roles involved in OTP Transactions. This means it could occur: o before another IOTP Transaction David Burdett et al. [Page 234] Internet Draft IOTP/1.0 28 Feb 1999 o at the same time as another IOTP Transaction o independently of any other IOTP Transaction. The Baseline Authentication IOTP Transaction consists of just an Authentication Document Exchange (see section 8.1.1) as illustrated by the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ------------------------------------------------------- v ---------------- | AUTHENTICATION | ---------------- | | | | ------------------- ----------------- | | BRAND INDEPENDENT | | BRAND DEPENDENT | | | OFFER | | OFFER | | ------------------- ----------------- | | | | | | --------- -------------- | | PAYMENT | | PAYMENT WITH | | | (first) | | DELIVERY | | --------- -------------- | | | | ---------- --------- | | DELIVERY | | PAYMENT | | | | | {second)| | ---------- --------- | v STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 26 Baseline Authentication IOTP Transaction Example uses of the Baseline Authentication IOTP Transaction include: David Burdett et al. [Page 235] Internet Draft IOTP/1.0 28 Feb 1999 o when the Baseline Authentication IOTP Transaction takes place as an early part of a session where strong continuity exists. For example, a Financial Institution could: - set up a secure channel (e.g. using SSL) with a customer - authenticate the customer using the Baseline Authentication IOTP Transaction, and then - provide the customer with access to account information and other services with the confidence that they are communicating with a bona fide customer. o as a means of providing a Merchant role with Organisation Components that contain information about Consumer and DelivTo Trading Roles o so that a Consumer may authenticate a Payment Handler before starting a payment. 8.1.7 Baseline Deposit IOTP Transaction The Baseline Deposit IOTP Transaction supports the deposit of electronic cash with a Financial Institution. [Note] The Financial Institution has, in IOTP terminology, a role of merchant in that a service (i.e. a deposit of electronic cash) is being offered in return for a fee, for example bank charges of some kind. The term "Financial Institution" is used in the diagrams and in the text for clarity. [Note End] The Baseline Deposit IOTP Transaction consists of the following Document Exchanges: o an optional Authentication Document Exchange (see section 8.1.1) o an Offer Document Exchange (see section 8.1.2), and o a Payment Document Exchange (see section 8.1.3). The way in which these Document Exchanges may be combined together is illustrated by the diagram below. David Burdett et al. [Page 236] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | -------------- | ------------- v v v v ------------------- ----------------- | BRAND INDEPENDENT | | BRAND DEPENDENT | | OFFER | | OFFER | ------------------- ----------------- | | | | | | | ------------------- v v --------- -------------- | PAYMENT | | PAYMENT WITH | | (first) | | DELIVERY | --------- -------------- | ---------------- | ---------- --------- | | DELIVERY | | PAYMENT | | | | | {second)| | ---------- --------- | | -----------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 27 Baseline Deposit IOTP Transaction See section 8.1.12 _Valid Combinations of Document Exchanges_ to determine which combination of document exchanges apply to a particular instance of an IOTP Transaction Note that: o a Merchant (Financial Institution) may be able to accept a deposit in several different types of electronic cash although, David Burdett et al. [Page 237] Internet Draft IOTP/1.0 28 Feb 1999 since the Consumer role that is depositing the electronic cash usually knows what type of cash they want to deposit, it is usually constrained in practice to only one type. However, there may be several different protocols which may be used for the same "brand" of electronic cash. In this case a Brand Dependent Offer may be appropriate to negotiate the protocol to be used. o the Merchant (Financial Institution) may use the results of the authentication to identify not only the consumer but also the account to which the payment is to be deposited. If no single account can be identified, then it must be obtained by other means. For example: - the consumer could specify the account number prior to the Baseline Deposit IOTP Transaction starting, or - the consumer could have been identified earlier, for example using a Baseline Authentication IOTP Transaction, and an account selected from a list provided by the Financial Institution. o The Baseline Deposit IOTP Transaction without an Authentication Document Exchange might be used: - if a previous IOTP transaction, for example a Baseline Withdrawal or a Baseline Authentication, authenticated the consumer, and a secure channel has been maintained, therefore the authenticity of the consumer is known - if authentication is achieved as part of a proprietary payment protocol and is therefore included in the Payment Document Exchange - if authentication of the consumer has been achieved by some other means outside of the scope of IOTP, for example, by using a pass phrase, or a proprietary banking software solution. 8.1.8 Baseline Purchase IOTP Transaction The Baseline Purchase IOTP Transaction supports the purchase of goods or services using any payment method. It consists of the following Document Exchanges: o an optional Authentication Document Exchange (see section 8.1.1) o an Offer Document Exchange (see section 8.1.2) o either: - a Payment Document Exchange (see section 8.1.3) followed by - a Delivery Document Exchange (see section 8.1.4) David Burdett et al. [Page 238] Internet Draft IOTP/1.0 28 Feb 1999 o a Payment Document Exchange only, or o a combined Payment and Delivery Document Exchange (see section 8.1.5). The ways in which these Document Exchanges are combined is illustrated by the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | | | -------------- | ------------- | v v v v | ------------------- ----------------- | | BRAND INDEPENDENT | | BRAND DEPENDENT | | | OFFER | | OFFER | | ------------------- ----------------- | | | | | | | --------------- | | | | | | | | | -------------- | -- | | v v v v | --------- -------------- | | PAYMENT | | PAYMENT WITH | | | (first) | | DELIVERY | | --------- -------------- | | | | ----------------------------- | | v | | | ---------- --------- | | | | DELIVERY | | PAYMENT | | | | | | | {second)| | | | ---------- --------- | | | | | | v ----------------------------------------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 28 Baseline Purchase IOTP Transaction David Burdett et al. [Page 239] Internet Draft IOTP/1.0 28 Feb 1999 See section 8.1.12 Valid Combinations of Document Exchanges to determine which combination of document exchanges apply to a particular instance of an IOTP Transaction 8.1.9 Baseline Refund IOTP Transaction In business terms the refund process typically consists of: o a request for a refund being made by the Consumer to the Merchant, typically supported by evidence to demonstrate: - the original trade took place, for example by providing a receipt for the original transaction - using some type of authentication, that the consumer requesting the refund is the consumer, or a representative of the consumer, who carried out the original trade - the reason why the merchant should make the refund o the merchant agreeing (or not) to the refund. This may involve some negotiation between the Consumer and the Merchant, and, if the merchant agrees, o a refund payment by the Merchant to the Consumer. The Baseline Refund IOTP Transaction supports a subset of the above, specifically it supports: o stand alone authentication of the Consumer using a separate Baseline Authentication IOTP Transaction (see section 8.1.6) o a refund payment by the Merchant to the Consumer using the following two Trading Exchanges: - an optional Authentication Document Exchange (see section 8.1.1) - an Offer Document Exchange (see section 8.1.2), and - a Payment Document Exchange (see section 8.1.3). The ways in which these Document Exchanges are combined is illustrated by the diagram below. David Burdett et al. [Page 240] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | -------------- | ------------- v v v v ------------------- ----------------- | BRAND INDEPENDENT | | BRAND DEPENDENT | | OFFER | | OFFER | ------------------- ----------------- | | | | | | | ------------------- v v --------- -------------- | PAYMENT | | PAYMENT WITH | | (first) | | DELIVERY | --------- -------------- | ---------------- | ---------- --------- | | DELIVERY | | PAYMENT | | | | | {second)| | ---------- --------- | | -----------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 29 Baseline Refund IOTP Transaction A Baseline Refund IOTP Transaction without an Authentication Document Exchange might be used: o when authentication of the consumer has been achieved by some other means, for example, the consumer has entered some previously supplied code in order to identify herself and the refund to which the code applies. The code could be supplied, for example on a web page or by e-mail. David Burdett et al. [Page 241] Internet Draft IOTP/1.0 28 Feb 1999 o when a previous IOTP transaction, for example a Baseline Authentication, authenticated the consumer, and a secure channel has been maintained, therefore the authenticity of the consumer is known and therefore the previously agreed refund can be identified. o when the authentication of the consumer is carried out by the Payment Handler using a payment scheme authentication method. 8.1.10 Baseline Withdrawal IOTP Transaction The Baseline Withdrawal IOTP Transaction supports the withdrawal of electronic cash from a Financial Institution. [Note] The Financial Institution has, in IOTP terminology, a role of merchant in that a service (i.e. a withdrawal of electronic cash) is being offered in return for a fee, for example bank charges of some kind. The term "Financial Institution" is used in the diagrams and in the text for clarity. [Note End] The Baseline Withdrawal IOTP Transaction consists of the following Document Exchanges: o an optional Authentication Document Exchange (see section 8.1.1) o an Offer Document Exchange (see section 8.1.2), and o a Payment Document Exchange (see section 8.1.3). The way in which these Document Exchanges may be combined together is illustrated by the diagram below. David Burdett et al. [Page 242] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | -------------- | ------------- v v v v ------------------- ----------------- | BRAND INDEPENDENT | | BRAND DEPENDENT | | OFFER | | OFFER | ------------------- ----------------- | | | | | | | ------------------- v v --------- -------------- | PAYMENT | | PAYMENT WITH | | (first) | | DELIVERY | --------- -------------- | ---------------- | ---------- --------- | | DELIVERY | | PAYMENT | | | | | {second)| | ---------- --------- | | -----------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 30 Baseline Withdrawal IOTP Transaction Note that: o a Merchant (Financial Institution) may be able to offer withdrawal of several different types of electronic cash. In practice usually only one form of electronic cash may be offered. However, there may be several different protocols which may be used for the same "brand" of electronic cash David Burdett et al. [Page 243] Internet Draft IOTP/1.0 28 Feb 1999 o the Merchant (Financial Institution) may use the results of the authentication to identify not only the consumer but also the account from which the withdrawal is to be made. If no single account can be identified, then it must be obtained by other means. For example: - the consumer could specify the account number prior to the Baseline Withdrawal IOTP Transaction starting, or - the consumer could have been identified earlier, for example using a Baseline Authentication IOTP Transaction, and an account selected from a list provided by the Financial Institution. o a Baseline Withdrawal without an authentication might be used: - if a previous IOTP transaction, for example a Baseline Deposit or a Baseline Authentication, authenticated the consumer, and a secure channel has been maintained, therefore the authenticity of the consumer is known - if authentication is achieved as part of a proprietary payment protocol and is therefore included in the Payment Document Exchange - if authentication of the consumer has been achieved by some other means, for example, by using a pass phrase, or a proprietary banking software solution. 8.1.11 Baseline Value Exchange IOTP Transaction The Baseline Value Exchange Transaction uses Payment Document Exchanges to support the exchange of value in one currency obtained using one payment method with value in the same or another currency using the same or another payment method. Examples of its use include: o electronic cash advance on a credit card. For example the first payment could be a _dollar SET Payment_ using a credit card with the second payment being a download of Visa Cash e-cash in dollars. o foreign exchange using the same payment method. For example the payment could be an upload of Mondex value in British Pounds and the second a download of Mondex value in Euros o foreign exchange using different payment methods. For example the first payment could be a SET payment in Canadian Dollars followed a download of GeldKarte in Deutchmarks. The Baseline Value Exchange uses the following Document Exchanges: David Burdett et al. [Page 244] Internet Draft IOTP/1.0 28 Feb 1999 o an optional Authentication Document Exchange (see section 8.1.1) o an Offer Document Exchange (see section 8.1.2), which provides details of what values and currencies will be exchanged, and o two Payment Document Exchanges (see section 8.1.3) which carry out the two payments involved. The way in which these Document Exchanges may be combined together is illustrated by the diagram below. David Burdett et al. [Page 245] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | -------------- | ------------- v v v v ------------------- ----------------- | BRAND INDEPENDENT | | BRAND DEPENDENT | | OFFER | | OFFER | ------------------- ----------------- | | | | | | | ------------------- v v --------- -------------- | PAYMENT | | PAYMENT WITH | | (first) | | DELIVERY | --------- -------------- | ---- v ---------- --------- | DELIVERY | | PAYMENT | | | | {second)| ---------- --------- | -----------------------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 31 Baseline Value Exchange IOTP Transaction The Baseline Value Exchange IOTP Transaction occurs in two basic forms: o Brand Dependent Value Exchange. Where the content of the offer, for example the rate at which one form of value is exchanged for another, is dependent on the payment brands and protocols selected by the consumer, and David Burdett et al. [Page 246] Internet Draft IOTP/1.0 28 Feb 1999 o Brand Independent Value Exchange. Where the content of the offer is not dependent on the payment brands and protocols selected. [Note] In the above the role is a Merchant even though the organisation carrying out the Value Exchange may be a Bank or some other Financial Institution. This is because the Bank is acting as a merchant in that they are making an offer which the Consumer can either accept or decline. [Note End] The TPO Block and Offer Response Block may only be combined into the same IOTP Message if the content of the Offer Response Block does not change as a result of selecting the payment brands and payment protocols to be used in the Value Exchange. BASELINE VALUE EXCHANGE SIGNATURES The use of signatures to ensure the integrity of a Baseline Value Exchange is illustrated by the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* Signature generated IotpMsg (TPO) by Merchant ensures - Trans Ref Block integrity of the Offer --------> - - Signature Block | - TPO Block MERCHANT | - Offer Response Block | Signature generated by | the Payment Handler of | IotpMsg (Pay Resp 1) the first payment binds | - Trans Ref Block PAYMENT Pay Receipt for the first -----> -> - Signature Block ----- HANDLER payment to the Offer - Pay Response Block 1 | 1 | Signature generated by | the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT the second payment binds - Trans Ref Block | HANDLER the second payment to the -----> - Signature Block <------ 2 first payment and therefore - Pay Response Block 2 to the Offer *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 32 Baseline Value Exchange Signatures David Burdett et al. [Page 247] Internet Draft IOTP/1.0 28 Feb 1999 8.1.12 Valid Combinations of Document Exchanges The following diagram illustrates the data conditions in the various IOTP messages which can be used by a Consumer Trading Role to determine whether the combination of Document Exchanges are valid. David Burdett et al. [Page 248] Internet Draft IOTP/1.0 28 Feb 1999 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* START | v Auth Request Block in =TRUE first IOTP Message ? --------------------------------------- | = FALSE | v v Offer Response Block in ---------------- first IOTP Message ? | AUTHENTICATION | |=TRUE |=FALSE ---------------- | | | | | v | ---------------------- TPO & Offer Response ------------- | Blocks in last IOTP Msg | | |=TRUE |=FALSE | | | v | ------------- | ---- TPO Block only i | | | last IOTP Message | | | of Authentication | | | |=TRUE |=FALSE v v v v | ------------------- ----------------- | | BRAND INDEPENDENT | | BRAND DEPENDENT | | | OFFER | | OFFER | | ------------------- ----------------- | | | | v v | Offer Response Block contains | Delivery Component ? | |=FALSE |=TRUE | --- v | | Value of DelivAndPayResp | | attribute of Delivery Component ? | | |=FALSE |=TRUE | | | | | v v v | --------- -------------- | | PAYMENT | | PAYMENT WITH | | | (first) | | DELIVERY | | --------- -------------- | | | | v | | Offer and Response Block contains | Delivery Component ? | |=TRUE |=FALSE | David Burdett et al. [Page 249] Internet Draft IOTP/1.0 28 Feb 1999 | v | | Two Payment Components | | present in Offer Response Block? | | |=TRUE |=FALSE | v v | | ---------- --------- | | | DELIVERY | | PAYMENT | | | | | | {second)| | | ---------- --------- | | | | | v ----------------------------------------------> STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 33 Valid Combinations of Document Exchanges 1) If first IOTP Message of an IOTP Transaction contains an Authentication Request then: a) IOTP Transaction includes an Authentication Document Exchange (see section 8.1.1). (Note 1) b) If the last IOTP Message of the Authentication Document Exchange includes a TPO Block and an Offer Response Block then: i) IOTP Transaction includes a Brand Independent Offer Document Exchange (see section 8.1.2.2). (Note 2) c) Otherwise, if the last IOTP Message of the Authentication Exchange includes a TPO Block but NO Offer Response Block, then: i) IOTP Transaction includes a Brand Dependent Offer Document Exchange (see section 8.1.2.1). (Note 2) d) Otherwise (Authentication Status IOTP Message of the Authentication Document Exchange contains neither a TPO Block but nor an Offer Response Block) i) IOTP Transaction consists of just an Authentication Document Exchange. (Note 3) 2) Otherwise (no Authentication Request in first IOTP Message): David Burdett et al. [Page 250] Internet Draft IOTP/1.0 28 Feb 1999 a) IOTP Transaction does not include an Authentication Document Exchange (Note 2) b) If first IOTP Message contains an Offer Response Block, then: i) the IOTP Transaction contains a Brand Independent Offer Document Exchange (Note 2) c) Otherwise (no Offer Response Block in first IOTP Message): i) the IOTP Transaction includes a Brand Dependent Offer Document Exchange (Note 2) 3) If an Offer Response Block exists in any IOTP message then: a) If the Offer Response Block contains a Delivery Component then: i) If the DelivAndPayResp attribute of the Delivery Component is set to True, then: . the IOTP Transaction consists of a Payment And Delivery Document Exchange (see section 8.1.5) (Note 4) ii) otherwise (the DelivAndPayResp attribute of the Delivery Component is set to False) . the IOTP Transaction consists of a Payment Document Exchange (see section 8.1.3) followed by a Delivery Document Exchange (see section 8.1.4) (Note 4) b) otherwise (the Offer Response Block does not contain a Delivery Component) i) if the Offer Response Block contains just one Payment Component, then: . the IOTP Transaction contains just one Payment Document Exchange (Note 5) ii) if the Offer Response Block contains two Payment Components, then: . the IOTP Transaction contains two Payment Document Exchanges. The StartAfter attribute of the Payment Components is used to indicate which payment occurs first (Note 6) David Burdett et al. [Page 251] Internet Draft IOTP/1.0 28 Feb 1999 iii) if the Offer Response Block contains no or more than two Payment Components, then there is an error 4) Otherwise (no Offer Response Block) there is an error. The following table indicates the types of IOTP Transactions which can validly have the conditions indicated above. Ref IOTP Transaction Validity 1. Any Payment and Authentication IOTP Transaction 2. Any Payment and Authentication IOTP Transaction except Baseline Authentication 3. Either Baseline Authentication, or a Baseline Purchase, Refund, Deposit, Withdrawal or Value Exchange with a failed Authentication 4. Baseline Purchase only 5. Baseline Purchase, Refund, Deposit or Withdrawal 6. Baseline Value Exchange only 8.1.13 Combining Authentication Transactions with other Transactions In the previous sections an Authentication Document Exchange is shown preceding an Offer Document Exchange as part of a single IOTP Transaction with the same OTP Transaction Id. It is also possible to run a separate Authentication Transaction at any point, even in parallel with another IOTP Transaction. Typically this will be used: o by a Consumer to authenticate a Payment Handler or a Delivery Handler, or o by a Payment Handler or Delivery Handler to authenticate a Consumer. In outline the basic process consists of: o the Trading Role that decides it wants to carry out an authentication of another role suspends the current IOTP transaction being carried out David Burdett et al. [Page 252] Internet Draft IOTP/1.0 28 Feb 1999 o a stand-alone Authentication transaction is then carried out. This may, at implementer's option, be linked to the original IOTP Transaction using a Related To Component (see section 3.3.3) in the Transaction Reference Block. o if the Authentication transaction is successful, then the original IOTP Transaction is restarted o if the Authentication fails then the original IOTP Transaction is cancelled. For example, a Consumer could: o authenticate the Payment Handler for a Payment between receiving an Offer Response from a Merchant and before sending the Payment Request to that Payment Handler o authenticate a Delivery Handler for a Delivery between receiving the Payment Response from a Payment Handler and before sending the Delivery Request A Payment Handler could authenticate a Consumer after receiving the Payment Request and before sending the next Payment related message. A Delivery Handler could authenticate a Consumer after receiving the Delivery Request and before sending the Delivery Response. [Note] Some Payment Methods may carry out an authentication within the Payment Exchange. In this case the information required to carry out the authentication will be included in Payment Scheme Components. In this instance IOTP aware application will not be aware that an authentication has occurred since the Payment Scheme Components that contain authentication data will be indistinguishable from other Payment Scheme Components. [Note End] 8.2 Infrastructure Transactions Infrastructure Transactions are designed to support inquiries on whether or not a transaction has succeeded or a Trading Role's servers are operating correctly. There are two types of transaction: David Burdett et al. [Page 253] Internet Draft IOTP/1.0 28 Feb 1999 o a Transaction Status Inquiry Transaction which provides information on the status of an existing or complete IOTP transaction, and o Ping Transaction that enables one IOTP aware application to determine if the IOTP aware application at another Trading Role is operating and verify whether or not signatures can be handled. Each of these is described below 8.2.1 Baseline Transaction Status Inquiry IOTP Transaction The Baseline IOTP Transaction Status Inquiry provides information on the status of an existing or complete IOTP transaction. The Trading Blocks used by the Baseline Transaction Status Inquiry Transaction are: o an Inquiry Request Trading Block (see section 7.12), and o an Inquiry Response Trading Block (see section 7.13). [Note] Note that: o Consumer Inquiries on Authentication transaction are not supported. o Authentication of Consumers as part of an inquiry is not supported in the Baseline version of IOTP. [Note End] WHICH TRADING ROLES CAN RECEIVE INQUIRY REQUESTS The Consumer can send a Transaction Status Inquiry Block to the appropriate Trading Role after the following events have occurred: o to the Merchant, after sending TPO Selection Block, o to the Payment Handler, after sending Payment Request Block, o to the Delivery Handler, after sending Delivery Request Block. [Note] IOTP does not support sending Inquiry Requests to the Consumer since the consumer may not be on-line to receive and process them. David Burdett et al. [Page 254] Internet Draft IOTP/1.0 28 Feb 1999 [Note End] If the Consumer is inquiring on transaction that is not yet complete, it should send the Inquiry Request Block to the Trading Role to which it sent the last IOTP message. If the Consumer is inquiring on a transaction which is complete, there are two alternatives in deciding the Trading Roles that the Inquiry Request Block should be sent to: o the Consumer IOTP software can ask the end user to determine the type of inquiry they want to make, or o the Consumer IOTP software can send the inquiry request message to all the Trading Roles that were involved in the IOTP transaction. For the second case above, how the Consumer IOTP Aware Application displays the inquiry response data received from each Trading Role is up to each implementation. TRANSACTION STATUS INQUIRY TRANSPORT SESSION For a Transaction Status Inquiry on an ongoing transaction, the Consumer shall establish with a Trading Role, a different transport session from the ongoing transaction. For a Transaction Status Inquiry on a past transaction, how the IOTP module on the software at the Trading Role is started upon the receipt of Inquiry Request message is defined in each Mapping to Transport supplement for IOTP. TRANSACTION STATUS INQUIRY ERROR HANDLING Errors in a Transaction Status Inquiry can be categorised into one the following three cases: o Business errors (see section 4.2) in the original (inquired) messages o Technical errors (see section 4.1) - both IOTP and payment scheme specific ones - in the original IOTP (inquired) messages o Technical errors in the message containing the Inquiry Request Block itself The following outlines what the software should do in each case David Burdett et al. [Page 255] Internet Draft IOTP/1.0 28 Feb 1999 BUSINESS ERRORS IN THE ORIGINAL MESSAGES Return an Inquiry Response Block containing the Status Component which was last sent to the Consumer. TECHNICAL ERRORS IN THE ORIGINAL MESSAGES Return an Inquiry Response Block containing a Status Component. The Status Component should contain a ProcessState attribute set to ProcessError. In this case send back an Error Block indicating where the error was found in the original message. TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK Return an Error message. That is, send back an Error Block containing the Error Code (see section 6.19.2) which describes the nature of the error in the Inquiry Request message. David Burdett et al. [Page 256] Internet Draft IOTP/1.0 28 Feb 1999 INQUIRY TRANSACTION MESSAGES The following Figure outlines the Baseline IOTP Transaction Status Inquiry processes on both Consumer and Service Provider sides. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* CONSUMER IOTP MESSAGE TRADING ROLE 1. The Consumer decides to inquire (Merchant, on an IOTP transaction by, for Payment Handler, example, clicking the inquiry button Delivery Handler of the IOTP Aware Application. This or Financial will then generate an Inquiry Institution) Request Block and send it to the appropriate Trading Role. | v IotpMsg: Trans Ref 2. The Trading Role checks the Block; Inquiry ----------> transaction status of the transaction Request Block Inquiry that is being inquired upon by using Request the Transaction Id Component of the Transaction Reference Block. He then generates the appropriate Inquiry Response Block based on the status of the transaction and sends the message back to the Consumer | v 3. The IOTP Aware IotpMsg: Trans Ref Application displays the <---------------- Block; Inquiry status information to the Inquiry Response Response Block end user | v STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 34 Baseline Transaction Status Inquiry The remainder of this sub-section on the Baseline Transaction Status Inquiry IOTP Transaction defines the contents of each Trading Block. David Burdett et al. [Page 257] Internet Draft IOTP/1.0 28 Feb 1999 TRANSACTION REFERENCE BLOCK The Consumer must use the same Transaction Id Component (see section 3.3.1) as in the inquired transaction. The OtpTransId attribute in this component serves as the key in querying the transaction logs maintained at the Trading Role's site. The value of the ID attribute of the Message Id Component should be different from those of the inquired transaction (see section 3.4.1). INQUIRY REQUEST BLOCK The Inquiry Request Block (see section 7.12) contains the following components: o one Inquiry Type Component (see section 6.16). This identifies whether the inquiry is on an offer, payment, or delivery. o zero or one Payment Scheme Component (see section 6.9). This is for encapsulating payment scheme specific inquiry messages for inquiries on payment. INQUIRY RESPONSE BLOCK The Inquiry Response Block (see section 7.13) contains the following components: o one Status Component (see section 6.14). This component hold the status information on the inquired transaction, o zero or one Payment Scheme Components. These contain for encapsulated payment scheme specific inquiry messages for inquiries on payment. 8.2.2 Baseline Ping IOTP Transaction The purpose of the Baseline IOTP Ping Transaction is to enable IOTP aware application software to determine if the IOTP aware application at another Trading Role is operating and verifying whether or not signatures can be handled. The Trading Blocks used by the Baseline Ping IOTP Transaction are: o a Ping Request Block (see section 7.14) o a Ping Response Block (see section 7.15), and David Burdett et al. [Page 258] Internet Draft IOTP/1.0 28 Feb 1999 o a Signature Block (see section 7.16). PING MESSAGES The following figure outlines the message flows in the Baseline IOTP Ping Transaction. *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* IOTP TRADING ROLE IOTP MESSAGE IOTP TRADING ROLE 1. The IOTP Aware Application in an IOTP Trading Role decides to check whether the counterparty IOTP application is up and running. It generates a Ping Block and optional Signature Block and sends them to the other IOTP Trading Role. | v IotpMsg: Trans Ref --------> 2. The IOTP Trading Role which receives Block; Ping Ping the Ping Request generates a Ping Request Block Request Response and sends it back to the sender of the original Ping Request. | v 3. The original sender of the IotpMsg: Trans Ref Ping Request checks the returned <------------ Block; Ping Ping Response and takes Ping Response Response Block appropriate action, if necessary | v STOP *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 35 Baseline Ping Messages The verification that signatures can be handled is indicated by the sender of the Ping Request Block including: o Organisation Components that identify itself and the intended recipient of the Ping Request Block, and o a Signature Block that signs data in the Ping Request. In this way the receiver of the Ping Request: David Burdett et al. [Page 259] Internet Draft IOTP/1.0 28 Feb 1999 o knows who is sending the Ping Request and can therefore verify the Signature on the Request, and o knows who to generate a signature for on the Ping Response. Note that a Ping Request: o does not affect any on-going transaction o does NOT start an IOTP aware application, unlike other IOTP transaction messages such as TPO or Transaction Status Inquiry. All IOTP aware applications must return a Ping Response message to the sender of a Ping Request message when it is received. A Baseline IOTP Ping request can also contain an optional Signature Block. IOTP aware applications can, for example, use the Signature Block to check the recipient of a Ping Request can successfully process and check signatures it has received. For each Baseline Ping IOTP Transaction, each IOTP role shall establish a different transport session from other IOTP transactions. Any IOTP Trading Role can send a Ping request to any other IOTP Trading Role at any time it wants. A Ping message has its own OtpTransId, which is different from other IOTP transactions. The remainder of this sub-section on the Baseline Ping IOTP Transaction defines the contents of each Trading Block. TRANSACTION REFERENCE BLOCK The OtpTransId of a Ping transaction should be different from any other IOTP transaction. PING REQUEST BLOCK If the Ping Transaction is anonymous then no Organisation Components are included in the Ping Request Block (see section 7.7). If the Ping Transaction is not anonymous then the Ping Request Block contains Organisation Components for: o the sender of the Ping Request Block, and o the verifier of the Signature Component David Burdett et al. [Page 260] Internet Draft IOTP/1.0 28 Feb 1999 If Organisation Components are present, then it indicates that the sender of the Ping Request message has generated a Signature Block. The signature block must be verified by the Trading Role that receives the Ping Request Block. SIGNATURE BLOCK (PING REQUEST) The Ping Request Signature Block (see section 7.16) contains the following components: o one Signature Component (see section 6.17) o one or more Certificate Components, if required. PING RESPONSE BLOCK The Ping Response Block (see section 7.15) contains the following component: o the Organisation Component of the sender of the Ping Response message If the Ping Transaction is not anonymous then the Ping Response additionally contains: o copies of the Organisation Components contained in the Ping Request Block. SIGNATURE BLOCK (PING RESPONSE) The Ping Response Signature Block (see section 7.16) contains the following components: o one Signature Component (see section 6.17) o one or more Certificate Components, if required. David Burdett et al. [Page 261] Internet Draft IOTP/1.0 28 Feb 1999 9. Retrieving Logos This section describes how to retrieve logos for display by IOTP aware software using the Logo Net Locations attribute contained in the Brand Element (see section 6.6.1) and the Organisation Component (see section 6.5). The full address of a logo is defined as follows: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".GIF" Where: o Logo_net_location is obtained from the LogoNetLocn attribute in the Brand Element (see section 6.6.1) or the Organisation Component. Note that: - the content of this attribute is dependent on the Transport Mechanism (such as HTTP) that is used. See the Transport Mechanism supplement, - implementers should check that if the rightmost character of Logo Net Location is set to right-slash "/" then another, right slash should not be included when generating the Logo Address, o Logo_size identifies the size of the logo, o Logo_color_depth identifies the colour depth of the logo o "GIF" indicates that the logos are in GIF format Logo_size and Logo_color_depth are specified by the implementer of the IOTP software that is retrieving the logo depending on the size and colour that they want to use. 9.1 Logo Size There are five standard sizes for logos. The sizes in pixels and the corresponding values for Logo Size are given in the table below. Size in Logo Size Pixels Value David Burdett et al. [Page 262] Internet Draft IOTP/1.0 28 Feb 1999 32 x 32 or exsmall 32 x 20 53 x 33 small 103 x 65 medium 180 x 114 large 263 x 166 exlarge 9.2 Logo Color Depth There are three standard colour depths. The colour depth (including bits per pixel) and the corresponding value for Logo_Color_Depth are given in the table below. Color Depth Logo Color (bits per pixel) Depth Value 4 (16 colors) 4 8 (256 colors) nothing 24 (16 million colors) 24 Note that if Logo Color Depth is omitted then a logo with the default colour depth of 256 colours will be retrieved. 9.3 Logo Net Location Examples If Logo Net Location was set to "ftp://logos.xzpay.com", then: o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 colour logo o "ftp://logos.xzpay.com/small4.gif" would retrieve a small size 16 colour logo David Burdett et al. [Page 263] Internet Draft IOTP/1.0 28 Feb 1999 [Note] Organisations which make logos available for use with IOTP should always make available "small" and "medium" size logos and use the GIF format. [Note End] David Burdett et al. [Page 264] Internet Draft IOTP/1.0 28 Feb 1999 10. Brand List Examples This example contains three examples of the XML for a Brand List Component. It covers: o a simple credit card based example o a credit card based brand list including promotional credit card brands, and o a complex electronic cash based brand list Note that: o brand lists can be as complex or as simple as required o all example techniques described in this appendix can be included in one brand list. 10.1 Simple Credit Card Based Example This is a simple example involving: o only major credit card payment brands o a single price in a single currency o a single payment handler, and o a single payment protocol David Burdett et al. [Page 265] Internet Draft IOTP/1.0 28 Feb 1999 10.2 Credit Card Brand List Including Promotional Brands An example of a Credit Card based Brand List follows. It includes: o two ordinary card association brands and two promotional credit card brands. The promotional brands consist of one loyalty based (British Airways MasterCard) which offers additional David Burdett et al. [Page 266] Internet Draft IOTP/1.0 28 Feb 1999 loyalty points and one store based (Walmart) which offers a discount on purchases over a certain amount o two payment protocols: - SET (Secure Electronic Transactions) see [SET], and - SCCD (Secure Channel Credit Debit) see [SCCD]. David Burdett et al. [Page 267] Internet Draft IOTP/1.0 28 Feb 1999 238djqw1298erh18dhoire 238djqw1298erh18dhoire David Burdett et al. [Page 268] Internet Draft IOTP/1.0 28 Feb 1999 8ueu26e482hd82he82 82hd82he8226e48ueu 10.3 Brand Selection Example In order to pay by 'British Airways' MasterCard using the example above using SET and therefore getting double air miles, the Brand Selection would be: 10.4 Complex Electronic Cash Based Brand List The following is an fairly complex example which includes: o payments using either Mondex, GeldKarte, CyberCash or DigiCash o in currencies including US dollars, British Pounds, Italian Lira, German Marks and Canadian Dollars David Burdett et al. [Page 269] Internet Draft IOTP/1.0 28 Feb 1999 o a discount on the price if the payment is made in Mondex using British pounds or US dollars, and o more than one payment handler is used for payments involving Mondex or CyberCash o support for more than one version of a CyberCash CyberCoin payment protocol. David Burdett et al. [Page 270] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 271] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 272] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 273] Internet Draft IOTP/1.0 28 Feb 1999 11. Open Trading Protocol Data Type Definition This section contains the XML DTD for the Internet Open Trading Protocols. David Burdett et al. [Page 274] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 276] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 277] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 279] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 280] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 284] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 285] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 286] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 287] Internet Draft IOTP/1.0 28 Feb 1999 David Burdett et al. [Page 288] Internet Draft IOTP/1.0 28 Feb 1999 12. Glossary This section contains a glossary of some of the terms used within this specification in alphabetical order. NAME DESCRIPTION Authenticator The Organisation which is requesting the authentication of another Organisation, and Authenticatee The Organisation being authenticated by an Authenticator Business Error See Status Component. Brand A Brand is the mark which identifies a particular type of Payment Instrument. A list of Brands are the payment options which are presented by the Merchant to the Consumer and from which the Consumer makes a selection. Each Brand may have a different Payment Handler. Examples of Brands include: o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, etc. o Promotional Brands (see below). These include: o store Brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK) o coBrands, for example American Advantage Visa, where an a company uses their own Brand in conjunction with, typically, a payment association Brand. Consumer The Organisation which is to receive the benefit of and typically pay for the goods or services. Customer Care An Organisation that is providing customer care Provider typically on behalf of a Merchant. Examples of customer care include, responding to problems raised by a Consumer arising from an IOTP Transaction that the Consumer took part in. David Burdett et al. [Page 289] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Delivery Handler The Organisation that physically delivers the goods or services to the Consumer on behalf of the Merchant. Dual Brand A Dual Brand means that a single Payment Instrument may be used as if it were two separate Brands. For example there could be a single Japanese "UC" MasterCard which can be used as either a UC card or a regular MasterCard. The UC card Brand and the MasterCard Brand could each have their own separate Payment Handlers. This means that: o the Merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer, o the Consumer chooses a Brand, for example either "UC" or "MasterCard, o the Consumer IOTP aware application determines which Payment Instrument(s) match the chosen Brand, and selects, perhaps with user assistance, the correct Payment Instrument to use. Exchange Block An Exchange Block is sent between the two Trading Roles involved in a Trading Exchange. It contains one or more Trading Components. Exchange Blocks are always sent after a Request Block and before a Response Block in a Trading Exchange. The content of an Exchange Block is dependent on the type of Trading Exchange being carried out. Error Block An Error Block reports that a Technical Error was found in an IOTP Message that was previously received. Typically Technical Errors are caused by errors in the XML which has been received or some technical failure of the processing of the IOTP Message. Frequently the generation or receipt of an Error Block will result in failure of the IOTP Transaction. They are distinct from Business Errors, reported in a Status Component, which can also cause failure of an IOTP Transaction. David Burdett et al. [Page 290] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION IOTP Message An IOTP Message is the outermost wrapper for the document(s) which are sent between Trading Roles that are taking part in a trade. It is a well formed XML document. The documents it contains consist of: o a Transaction Reference Block to uniquely identify the IOTP Transaction of which the IOTP Message is part, o an optional Signature Block to digitally sign the Trading Blocks or Trading Components associated with the IOTP Transaction o an optional Error Block to report on technical errors contained in a previously received IOTP Message, and o a collection of IOTP Trading Blocks which carries the data required to carry out an IOTP Transaction. IOTP Transaction An instance of an Internet Open Trading Protocol Transaction consists of a set of IOTP Messages transferred between Trading Roles. The rules for what may be contained in the IOTP Messages is defined by the Transaction Type of IOTP Transaction. Document Exchange A Document Exchange consists of a set of IOTP Messages exchanged between two parties that implement part or all of two Trading Exchanges simultaneously in order to minimise the number of actual OTP Messages which must be sent over the Internet. Document Exchanges are combined together in sequence to implement a particular IOTP Transaction. Merchant The Organisation from whom the service or goods are being obtained, who is legally responsible for providing the goods or services and receives the benefit of any payment made Merchant Customer The Organisation that is involved with customer Care Provider dispute negotiation and resolution on behalf of the Merchant David Burdett et al. [Page 291] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Organisation A company or individual that takes part in a Trade as a Trading Role. The organisations may take one or more of the roles involved in the Trade Payment Handler The Organisation that physically receives the payment from the Consumer on behalf of the Merchant Payment Instrument A Payment Instrument is the means by which Consumer pays for goods or services offered by a Merchant. It can be, for example: o a credit card such as MasterCard or Visa; o a debit card such as MasterCard's Maestro; o a smart card based electronic cash Payment Instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card o a software based electronic payment account such as a CyberCash or DigiCash account. All Payment Instruments have a number, typically an account number, by which the Payment Instrument can be identified. David Burdett et al. [Page 292] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Promotional Brand A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit which can be received in two ways: o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the Consumer actually pays less, o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued. Each Promotional Brand should be identified as a separate Brand in the list of Brands offered by the Merchant. For example: "Walmart", "Sears", "Marks and Spencer" and "American Advantage Visa", would each be a separate Brand. Receipt Component A Receipt Component is a record of the successful completion of a Trading Exchange. Examples of Receipt Components include: Payment Receipts, and Delivery Notes. It's content may dependent on the technology used to perform the Trading Exchange. For example a Secure Electronic Transaction (SET) payment receipt consists of SET payment messages which record the result of the payment. David Burdett et al. [Page 293] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Request Block A Request Block is Trading Block that contains a request for a Trading Exchange to start. The Trading Components in a Request Block may be signed by a Signature Block so that their authenticity may be checked and to determine that the Trading Exchange being requested is authorised. Authorisation for a Trading Exchange to start can be provided by the signatures contained on Receipt Components contained in Response Blocks resulting from previously completed Trading Exchanges. Examples of Request Blocks are Payment Request and Delivery Request Response Block A Response Block is a Trading Block that indicates that a Trading Exchange is complete. It is sent by the Trading Role that received a Request Block to the Trading Role that sent the Request Block. The Response Block contains a Status Component that contains information about the completion of the Trading Exchange, for example it indicates whether or not the Trading Exchange completed successfully. For some Trading Exchanges the Response Block contains a Receipt Component that forms a record of the Trading Exchange. Receipt Components may be digitally signed using a Signature Block to make completion non-refutable. Examples of Response Blocks include Offer Response, Payment Response and Delivery Response. Signature Block A Signature Block is a Trading Block that contains one or more digital signatures in the form of Signature Components. A Signature Component may digitally sign any Block or Component in any IOTP Message in the same IOTP Transaction. David Burdett et al. [Page 294] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Status Component A Status Component contains information that describes the state of a Trading Exchange. Before the Trading Exchange is complete the Status Component can indicate information about how the Trading Exchange is progressing. Once a Trading Exchange is complete the Status Component can only indicate the success of the Trading Exchange or that a Business Error has occurred. A Business Error indicates that continuation with the Trading Exchange was not possible because of some business rule or logic, for example, "insufficient funds available", rather than any Technical Error associated with the content or format of the IOTP Messages in the IOTP Transaction. Technical Error See Error Block. Trading Block A Trading Block consists of one or more Trading Components. One or more Trading Blocks may be contained within the IOTP Messages which are physically sent in the form of [XML] documents between the different Trading Roles that are taking part in a trade. Trading Blocks are of three main types: o a Request Block, o an Exchange Block, or a o a Response Block Trading Component A Trading Component is a collection of XML elements and attributes. Trading Components are the child elements of the Trading Blocks. Examples of Trading Components are: Offer, Brand List, Payment Receipt, Delivery [information], Payment Amount [information] David Burdett et al. [Page 295] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Trading Exchange A Trading Exchange consists of the exchange, between two Trading Roles, of a sequence of documents. The documents may be in the form of Trading Blocks or they may be transferred by some other means, for example through entering data into a web page. Each Trading Exchange consists of three main parts: o the sending of a Request Block by one Trading Role (the initiator) to another Trading Role (the recipient), o the optional exchange of one or more Exchange Blocks between the recipient and the initiator, until eventually, o the Trading Role that received the Request Block sends a Response Block to the initiator. A Trading Exchange is designed to implement a useful service of some kind. Examples of Trading Exchanges/services are: o Offer, which results in a Consumer receiving an offer from a Merchant to carry out a business transaction of some kind, o Payment, where a Consumer makes a payment to a Payment Handler, o Delivery, where a Consumer requests, and optionally obtains, delivery of goods or services from a Delivery Handler, and o Authentication, where any Trading Role may request and receive information about another Trading Role. Transaction A Transaction Reference Block identifies an IOTP Reference Block Transaction. It contains data that identifies: o the Transaction Type, o the IOTP Transaction uniquely, through a globally unique transaction identifier o the IOTP Message uniquely within the IOTP Transaction, through a message identifier The Transaction Reference Block may also contain references to other transactions which may or may not be IOTP Transactions David Burdett et al. [Page 296] Internet Draft IOTP/1.0 28 Feb 1999 NAME DESCRIPTION Trading Role A Trading Role identifies the different ways in which organisations can participate in a trade. There are five Trading Roles: Consumer, Merchant, Payment Handler, Delivery Handler, and Merchant Customer Care Provider. Transaction Type A Transaction Type identifies the type an of IOTP Transaction. Examples of Transaction Type include: Purchase, Refund, Authentication, Withdrawal, Deposit (of electronic cash). The Transaction Type specifies for an IOTP Transaction: o the Trading Exchanges which may be included in the transaction, o how those Trading Exchanges may be combined to meet the business needs of the transaction o which Trading Blocks may be included in the IOTP Messages that make up the transaction o Consult this specification for the rules that apply for each Transaction Type. David Burdett et al. [Page 297] Internet Draft IOTP/1.0 28 Feb 1999 13. Copyrights Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. David Burdett et al. [Page 298] Internet Draft IOTP/1.0 28 Feb 1999 14. References This section contains references to related documents identified in this specification. [Base64] Base64 Content-Transfer-Encoding. A method of transporting binary data defined by MIME. See: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N. Borenstein. November 1996. [DOM-HASH] A method for generating hashes of all or part of an XML tree based on the DOM of that tree. See . [DNS] The Internet Domain Name System which allocates Internet names to organisations for example "OTP.org", the Domain Name for IOTP. See RFC 1034: Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. [DSA] The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project. [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986. [HMAC] See Message Authentication Using hash Functions: the HMAC Construction. RSA Cryptobytes, Volume 2, Number 1, Spring 1996 David Burdett et al. [Page 299] Internet Draft IOTP/1.0 28 Feb 1999 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See RFC 1866 and the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/ [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee. January 1997. [IANA] The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/. [ISO4217] ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO. [MD5] R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. [MIME] Multipurpose Internet Mail Extensions. See RFC822, RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. [OPS] Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others. [RFC822] IETF (Internet Engineering Task Force). RFC 822: The Standard for the Format of ARPA Internet Messages . 13 August 1982, David H Crocker. 13 August 1982. [RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994. [RFC2434] IETF (Internet Engineering Task Force). RFC 2434. Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten and H. Alvestrand David Burdett et al. [Page 300] Internet Draft IOTP/1.0 28 Feb 1999 [RSA] RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120- 126, February 1978. [SCCD] Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL. An IOTP supplement describing how SCCD works is under development. Author. Jonathan Sowler JCP, [SET] Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: . [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). [UTC] Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601. [UTF16] The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate) [XML Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- xml-names" [XML] Extensible Mark Up Language. See http://www.w3.org/TR/PR-xml-971208 for the 8 December 1997 version. David Burdett et al. [Page 301] Internet Draft IOTP/1.0 28 Feb 1999 [XMLDSIG] A proposal developed by Richard Brown, GlobeSet describing an approach to signing XML documents such as IOTP Messages. See http://www.ietf.org/internet- drafts/draft-brown-xml-dsig-00.txt and discussion on IETF Trade WG David Burdett et al. [Page 302] Internet Draft IOTP/1.0 28 Feb 1999 15. Author's Address The author of this document is: David Burdett Development Director Mondex International Ltd Advanced Technology Division 111 Pine St San Francisco, 94111 California USA Tel: +1 (415) 645 6973 Email: david.burdett@mondex.com The author of this document appreciates the following contributors to this protocol (in alphabetic order of company) without which it could not have been developed. o Phillip Mullarkey, British Telecom plc o Andrew Marchewka, Canadian Imperial Bank of Commerce o Brian Boesch, CyberCash Inc. o Donald Eastlake 3rd, CyberCash Inc. o Mark Linehan, International Business Machines o Richard Brown, GlobeSet Inc. o Peter Chang, Hewlett Packard o Masaaki Hiroya, Hitachi Ltd o Yoshiaki Kawatsura, Hitachi Ltd o Jonathan Sowler, JCP Computer Services Ltd o John Wankmueller, MasterCard International o Steve Fabes, Mondex International Ltd David Burdett et al. [Page 303] Internet Draft IOTP/1.0 28 Feb 1999 o Surendra Reddy, Oracle Corporation o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) o Chris Smith, Royal Bank of Canada o Hans Bernhard-Beykirch, SIZ (IT Development and Coordination Centre of the German Savings Banks Organisation) o W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, formally AT&T Universal Card Services) o Efrem Lipkin, Sun Microsystems o Terry Allen, Commerce One (formally Veo Systems) The author would also like to thank the following organisations for their support: o Amino Communications o DigiCash o Fujitsu o General Information Systems o Globe Id Software o Hyperion o InterTrader o Nobil I T Corp o Mercantec o Netscape o Nippon Telegraph and Telephone Corporation o Oracle Corporation o Smart Card Integrations Ltd. o Spyrus David Burdett et al. [Page 304] Internet Draft IOTP/1.0 28 Feb 1999 o Verifone o Unisource nv o Wells Fargo Bank File name: draft-ietf-trade-iotp-v1.0-protocol-03.txt Expires: 28 August 1999 David Burdett et al. [Page 305]