Internet Open Trading Protocol - IOTP Version 1.0
From:  http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-02.txt
Date:  1999-01-18
See also:  http://www.oasis-open.org/cover/otp.html - Open Trading Protocol (OTP)
----------------------------------------------------------------------------


  TRADE Working Group                                    David Burdett

  Internet Draft                                  Mondex International
  draft-ietf-trade-iotp-v1.0-protocol-02.txt           23 October 1998
  Expires:  23 March 1998




                 Internet Open Trading Protocol - IOTP
                              Version 1.0





  Status of this Memo

  This document is an Internet draft. 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
  information as Internet drafts.

  Internet Drafts are draft documents valid for a maximum of six months
  and can 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 as other than as "work in progress".

  To learn the current status of any Internet draft please check the
  "lid-abstracts.txt" listing contained in the Internet drafts shadow
  directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ftp.ietf.org (US East coast) or
  ftp.isi.edu (US West coast). Further information about the IETF can be
  found at URL: http://www.ietf.org/

  Distribution of this document is unlimited. Please send comments to
  the TRADE  working group at <ietf-trade@lists.elistx.com >, which may
  be joined by sending a message with subject "subscribe" to <ietf-
  trade-request@lists.elistx.com>.

  Discussions of the TRADE working group are archived at
  http://www.elistx.com/archives/ietf-trade.


  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 1]

  Internet Draft                IOTP/1.0               23 October 1998


  Table of Contents


  Status of this Memo................................................1

  Abstract...........................................................1

  1. Background......................................................9
     1.1 Commerce on the Internet _ a Different Model................9
     1.2 Benefits of IOTP...........................................10
     1.3 Baseline IOTP..............................................12
     1.4 Objectives of Document.....................................12
     1.5 Purpose....................................................12
     1.6 Scope of Document..........................................13
     1.7 Document Structure.........................................13
     1.8 Intended Readership........................................14
       1.8.1 Reading Guidelines ....................................14
     1.9 History....................................................15

  2. Introduction...................................................16
     2.1 Trading Roles..............................................16
     2.2 Trading Exchanges..........................................18
       2.2.1 Offer Exchange ........................................19
       2.2.2 Payment Exchange ......................................20
       2.2.3 Delivery Exchange .....................................23
       2.2.4 Authentication Exchange ...............................24
     2.3 Scope of Baseline IOTP.....................................25

  3. Protocol Structure.............................................28
     3.1 Overview...................................................29
       3.1.1 IOTP Message Structure ................................29
       3.1.2 IOTP Transactions .....................................30
     3.2 IOTP Message...............................................31
       3.2.1 XML Document Prolog ...................................33
     3.3 Transaction Reference Block................................33
       3.3.1 Transaction Id Component ..............................34
       3.3.2 Message Id Component ..................................35
       3.3.3 Related To Component ..................................36
     3.4 ID Attributes..............................................37
       3.4.1 IOTP Message ID Attribute Definition ..................38
       3.4.2 Block and Component ID Attribute Definitions ..........39
       3.4.3 Example of use of ID Attributes .......................40
     3.5 Element References.........................................40
     3.6 Brands and Brand Selection.................................42
       3.6.1 Definition of Payment Instrument ......................42
       3.6.2 Definition of Brand ...................................42
       3.6.3 Definition of Dual Brand ..............................43
       3.6.4 Definition of Promotional Brand .......................43
       3.6.5 Identifying Promotional Brands ........................44
     3.7 Extending IOTP.............................................46
       3.7.1 Extra XML Elements ....................................46
       3.7.2 Opaque Embedded Data ..................................47
       3.7.3 User Defined Codes ....................................47

  David Burdett et al.                                        [Page 2]

  Internet Draft                IOTP/1.0               23 October 1998


     3.8 Packaged Content Element...................................48
     3.9 Identifying Languages......................................49
     3.10 Secure and Insecure Net Locations.........................50

  4. IOTP Error Handling............................................50
     4.1 Technical Errors...........................................51
     4.2 Business Errors............................................51
     4.3 Error Depth................................................52
       4.3.1 Transport Level .......................................52
       4.3.2 Message Level .........................................52
       4.3.3 4Block Level ..........................................53
     4.4 Idempotency, Processing Sequence, and Message Flow.........54
       4.4.1 Server Role Processing Sequence .......................55
       4.4.2 Client Role Processing Sequence .......................59

  5. Security Considerations........................................64
     5.1 Digital Signatures and IOTP................................64
       5.1.1 IOTP Signature Example ................................65
       5.1.2 SignerOrgRef and VerifierOrgRef Attributes ............66
       5.1.3 Symmetric and Asymmetric Cryptography .................67
       5.1.4 Mandatory and Optional Signatures .....................67
       5.1.5 Using signatures to Prove Actions Complete Successfully68
     5.2 Checking a Signature is Correctly Calculated...............68
     5.3 Checking a Payment or Delivery can occur...................69
       5.3.1 Check the Action Request was sent to the Correct
       Organisation ................................................69
       5.3.2 Check the Correct Components are present in the Request
       Block .......................................................73
       5.3.3 Check an Action is Authorised .........................73
     5.4 Data Integrity and Privacy.................................74

  6. Trading Components.............................................75
     6.1 Protocol Options Component.................................76
     6.2 Authentication Data Component..............................77
     6.3 Authentication Response Component..........................79
     6.4 Order Component............................................80
       6.4.1 Order Description Content .............................81
       6.4.2 OkFrom and OkTo Timestamps ............................82
     6.5 Organisation Component.....................................82
       6.5.2 Trading Role Element ..................................85
       6.5.3 Contact Information Element ...........................87
       6.5.4 Person Name Element ...................................87
       6.5.5 Postal Address Element ................................88
     6.6 Brand List Component.......................................89
       6.6.1 Brand Element .........................................91
       6.6.2 Protocol Amount Element ...............................94
       6.6.3 Currency Amount Element ...............................95
       6.6.4 Pay Protocol Element ..................................96
     6.7 Brand Selection Component..................................98
       6.7.1 Brand Selection Brand Info Element ....................99
       6.7.2 Brand Selection Protocol Amount Info Element .........100
       6.7.3 Brand Selection Currency Amount Info Element .........100
     6.8 Payment Component.........................................101

  David Burdett et al.                                        [Page 3]

  Internet Draft                IOTP/1.0               23 October 1998


     6.9 Payment Scheme Component..................................102
     6.10 Payment Receipt Component................................104
     6.11 Payment Note Component...................................105
     6.12 Delivery Component.......................................106
       6.12.1 Delivery Data Element ...............................108
     6.13 Delivery Note Component..................................110
     6.14 Payment Method Information Component.....................111
     6.15 Status Component.........................................112
     6.16 Trading Role Data Component..............................117
       6.16.1 Who Receives a Trading Role Data Component ..........118
     6.17 Inquiry Type Component...................................118
     6.18 Signature Component......................................119
       6.18.1 Offer Response Signature Component ..................119
       6.18.2 Payment Receipt Signature Component .................120
       6.18.3 Ping Signature Components ...........................120
     6.19 Error Component..........................................121
       6.19.1 Error Processing Guidelines .........................123
       6.19.2 Error Codes .........................................124
       6.19.3 Error Location Element ..............................127

  7. Trading Blocks................................................128
     7.1 Trading Protocol Options Block............................130
     7.2 TPO Selection Block.......................................131
     7.3 Offer Response Block......................................132
     7.4 Authentication Request Block..............................133
     7.5 Authentication Response Block.............................134
     7.6 Payment Request Block.....................................134
     7.7 Payment Exchange Block....................................136
     7.8 Payment Response Block....................................136
     7.9 Delivery Request Block....................................137
     7.10 Delivery Response Block..................................138
     7.11 Payment Instrument Customer Care Request Block...........139
     7.12 Payment Instrument Customer Care Exchange Block..........140
     7.13 Payment Instrument Customer Care Response Block..........140
     7.14 Inquiry Request Trading Block............................141
     7.15 Inquiry Response Trading Block...........................141
     7.16 Ping Request Block.......................................142
     7.17 Ping Response Block......................................143
     7.18 Signature Block..........................................144
       7.18.1 Offer Response ......................................145
       7.18.2 Payment Request .....................................145
       7.18.3 Payment Response ....................................145
       7.18.4 Delivery Request ....................................145
     7.19 Error Block..............................................146

  8. Open Trading Protocol Transactions............................147
     8.1 Baseline Authentication IOTP Transaction..................147
       8.1.1 Trading Protocol Options Block .......................150
       8.1.2 Authentication Request Block .........................150
       8.1.3 Signature Block (Authentication Request) .............150
       8.1.4 Authentication Response Block ........................150
       8.1.5 Signature Block (Authentication Response) ............150
     8.2 Baseline Deposit IOTP Transaction.........................151

  David Burdett et al.                                        [Page 4]

  Internet Draft                IOTP/1.0               23 October 1998


       8.2.1 Baseline Deposit Variations ..........................152
       8.2.2 Baseline Deposit Authentication ......................152
       8.2.3 Baseline Deposit Payment Messages ....................154
       8.2.4 TPO (Trading Protocol Options) Block .................155
       8.2.5 TPO Selection Block ..................................156
       8.2.6 Authentication Request Block .........................156
       8.2.7 Authentication Response Block ........................156
       8.2.8 Offer Response Block .................................156
       8.2.9 Signature Block (Offer Response) .....................157
       8.2.10 Payment Request Block ...............................157
       8.2.11 Signature Block (Payment Request) ...................158
       8.2.12 Payment Exchange Block ..............................158
       8.2.13 Payment Response Block ..............................158
       8.2.14 Signature Block (Payment Response) ..................158
     8.3 Baseline Purchase IOTP Transaction........................159
       8.3.1 Baseline Purchase Variations .........................159
       8.3.2 TPO (Trading Protocol Options) Block .................167
       8.3.3 TPO Selection Block ..................................167
       8.3.4 Offer Response Block .................................167
       8.3.5 Signature Block (Offer Response) .....................168
       8.3.6 Payment Request Block ................................169
       8.3.7 Signature Block (Payment Request) ....................169
       8.3.8 Payment Exchange Block ...............................169
       8.3.9 Payment Response Block ...............................169
       8.3.10 Signature Block (Payment Response) ..................170
       8.3.11 Delivery Request Block ..............................170
       8.3.12 Signature Block (Delivery Request) ..................171
       8.3.13 Delivery Response Block .............................171
     8.4 Baseline Refund IOTP Transaction..........................171
       8.4.1 Baseline Refund Variations ...........................172
       8.4.2 Baseline Refund Authentication .......................172
       8.4.3 Baseline Refund Payment Messages .....................174
       8.4.4 TPO (Trading Protocol Options) Block .................175
       8.4.5 TPO Selection Block ..................................175
       8.4.6 Authentication Request Block .........................176
       8.4.7 Authentication Response Block ........................176
       8.4.8 Offer Response Block .................................176
       8.4.9 Signature Block (Offer Response) .....................176
       8.4.10 Payment Request Block ...............................177
       8.4.11 Signature Block (Payment Request) ...................177
       8.4.12 Payment Exchange Block ..............................177
       8.4.13 Payment Response Block ..............................178
       8.4.14 Signature Block (Payment Response) ..................178
     8.5 Baseline Withdrawal IOTP Transaction......................178
       8.5.1 Baseline Withdrawal Variations .......................179
       8.5.2 Baseline Withdrawal Authentication ...................179
       8.5.3 Baseline Withdrawal Payment Messages .................182
       8.5.4 TPO (Trading Protocol Options) Block .................183
       8.5.5 TPO Selection Block ..................................183
       8.5.6 Authentication Request Block .........................183
       8.5.7 Authentication Response Block ........................184
       8.5.8 Offer Response Block .................................184
       8.5.9 Signature Block (Offer Response) .....................184

  David Burdett et al.                                        [Page 5]

  Internet Draft                IOTP/1.0               23 October 1998


       8.5.10 Payment Request Block ...............................185
       8.5.11 Signature Block (Payment Request) ...................185
       8.5.12 Payment Exchange Block ..............................185
       8.5.13 Payment Response Block ..............................186
       8.5.14 Signature Block (Payment Response) ..................186
     8.6 Baseline Value Exchange IOTP Transaction..................186
       8.6.1 Baseline Value Exchange Variations ...................187
       8.6.2 PO (Trading Protocol Options) Block ..................191
       8.6.3 TPO Selection Block ..................................192
       8.6.4 Offer Response Block .................................192
       8.6.5 Signature Block (Offer Response) .....................192
       8.6.6 Payment Request Block (first payment) ................193
       8.6.7 Signature Block (Payment Request - first payment) ....194
       8.6.8 Payment Exchange Block (first payment) ...............194
       8.6.9 Payment Response Block (first payment) ...............194
       8.6.10 Signature Block (Payment Response - first payment) ..195
       8.6.11 Payment Request Block (second payment) ..............195
       8.6.12 Signature Block (Payment Request - second payment) ..196
       8.6.13 Payment Exchange Block (second payment) .............196
       8.6.14 Payment Response Block (second payment) .............196
       8.6.15 Signature Block (Payment Response - second payment) .197
       8.6.16 Baseline Value Exchange Signatures ..................197
     8.7 Payment Instrument Customer Care IOTP Transaction.........198
       8.7.1 Payment Instrument Customer Care Request Block .......200
       8.7.2 Payment Instrument Customer Care Exchange Block ......200
       8.7.3 Payment Instrument Customer Care Response Block ......200
       8.7.4 Signature Block ......................................200
     8.8 Baseline Transaction Status Inquiry IOTP Transaction......201
       8.8.1 Which Trading Roles can receive Inquiry Requests .....201
       8.8.2 Transaction Status Inquiry Transport Session .........201
       8.8.3 Transaction Status Inquiry Error Handling ............202
       8.8.4 Inquiry Transaction Messages .........................202
       8.8.5 Transaction Reference Block ..........................203
       8.8.6 Inquiry Request Block ................................203
       8.8.7 Inquiry Response Block ...............................203
     8.9 Baseline Ping IOTP Transaction............................204
       8.9.1 Ping Messages ........................................204
       8.9.2 Transaction Reference Block ..........................205
       8.9.3 Ping Request Block ...................................205
       8.9.4 Signature Block (Ping Request) .......................206
       8.9.5 Ping Response Block ..................................206
       8.9.6 Signature Block (Ping Response) ......................206

  9. Retrieving Logos..............................................206
     9.1 Logo Size.................................................207
     9.2 Logo Color Depth..........................................207
     9.3 Logo Net Location Examples................................208

  10. Brand List Examples..........................................208
     10.1 Simple Credit Card Based Example.........................208
     10.2 Credit Card Brand List Including Promotional Brands......209
     10.3 Brand Selection Example..................................211
     10.4 Complex Electronic Cash Based Brand List.................211

  David Burdett et al.                                        [Page 6]

  Internet Draft                IOTP/1.0               23 October 1998


  11. XML Overview.................................................213
     11.1 Document Definition......................................214
     11.2 Element Declaration......................................214
       11.2.1 Example 1 ...........................................215
       11.2.2 Example 2 ...........................................215
       11.2.3 Example 3 ...........................................215
       11.2.4 Data Types used in element declarations .............216
     11.3 Attribute declarations...................................216
       11.3.1 Declared value ......................................216
       11.3.2 Default value .......................................217

  12. Open Trading Protocol Data Type Definition...................218

  13. Glossary.....................................................229

  14. Copyrights...................................................232

  15. References...................................................233

  16. Author's Address.............................................235


































  David Burdett et al.                                        [Page 7]

  Internet Draft                IOTP/1.0               23 October 1998


  Table of Figures

  Figure 1 IOTP Trading Roles ......................................17
  Figure 2 Offer Exchange ..........................................19
  Figure 3 Payment Exchange ........................................21
  Figure 4 Delivery Exchange .......................................24
  Figure 5 Authentication Exchange .................................25
  Figure 6 IOTP Message Structure ..................................29
  Figure 7 An IOTP Transaction .....................................30
  Figure 8 Example use of ID attributes ............................40
  Figure 9 Element References ......................................41
  Figure 10 Server Role Processing Sequence ........................56
  Figure 11 Client Role Processing Sequence ........................61
  Figure 12 Signature Hashing ......................................65
  Figure 13 Example use of Signatures for Baseline Purchase ........66
  Figure 14 Checking a Payment Handler can carry out a Payment .....70
  Figure 15 Checking a Delivery Handler can carry out a Delivery ...72
  Figure 16 Trading Components .....................................75
  Figure 17 Brand List Element Relationships .......................91
  Figure 18 Trading Blocks ........................................129
  Figure 19 Baseline Authentication ...............................149
  Figure 20 Baseline Deposit with Authentication ..................153
  Figure 21 Baseline Deposit without Authentication ...............154
  Figure 22 Baseline Deposit Payment Messages .....................155
  Figure 23 Brand Dependent Baseline Purchase .....................161
  Figure 24 Brand Independent Baseline Purchase ...................162
  Figure 25 Baseline Purchase, Delivery Response Block and Payment
     Response Blocks Not Combined .................................163
  Figure 26 Baseline Purchase, Delivery Response Block and Payment
     Response Block Combined ......................................164
  Figure 27 Baseline Purchase, Purchase without Delivery Exchange .166
  Figure 28 Baseline Purchase Variations ..........................167
  Figure 29 Baseline Refund with Authentication ...................173
  Figure 30 Baseline Refund without Authentication ................174
  Figure 31 Baseline Refund Payment Messages ......................175
  Figure 32 Baseline Withdrawal with Authentication ...............180
  Figure 33 Baseline Withdrawal without Authentication ............181
  Figure 34 Baseline Withdrawal Payment Messages ..................183
  Figure 35 Brand Dependent Value Exchange ........................189
  Figure 36 Brand Independent Value Exchange ......................189
  Figure 37 Baseline Value Exchange Payment Messages ..............191
  Figure 38 Baseline Value Exchange Signatures ....................198
  Figure 39 IOTP Payment Instrument Customer Care Transaction Message
     Flows ........................................................200
  Figure 40 Baseline Transaction Status Inquiry ...................203
  Figure 41 Baseline Ping Messages ................................204








  David Burdett et al.                                        [Page 8]

  Internet Draft                IOTP/1.0               23 October 1998





1. Background


  The Internet Open Trading Protocol (IOTP) provides an interoperable
  framework for Internet commerce. It is payment system independent and
  encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash,
  GeldKarte, etc. IOTP is able to handle cases where such merchant roles
  as the shopping site, the payment handler, the Delivery Handler of
  goods or services, and the provider of customer support are performed
  by different parties or by one party.

  The developers of IOTP seek to provide a virtual capability that
  safely replicates the real world, the paper based, traditional,
  understood, accepted methods of trading, buying, selling, value
  exchanging that has existed for many hundreds of years.  The
  negotiation of who will be the parties to the trade, how it will be
  conducted, the presentment of an offer, the method of payment, the
  provision of a payment receipt, the delivery of goods and the receipt
  of goods. These are events that are taken for granted in the course of
  real world trade. IOTP has been produced to provide the same for the
  virtual world, and to prepare and provide for the introduction of new
  models of trading made possible by the expanding presence of the
  virtual world.

  The other fundamental ideal of the IOTP effort is to produce a
  definition of these trading events in such a way that no matter where
  produced, two unfamiliar parties using electronic commerce
  capabilities to buy and sell that conform to the IOTP specifications
  will be able to complete the business safely and successfully.

  In summary, IOTP supports:
  o  Familiar trading models
  o  New trading models
  o  Global interoperability

  The remainder of this section provides background to why IOTP was
  developed. The specification itself starts in the next chapter.



1.1 Commerce on the Internet _ a Different Model

  The growth of the Internet and the advent of electronic commerce are
  bringing about enormous changes around the world in society, politics
  and government, and in business. The ways in which trading partners
  communicate, conduct commerce, are governed have been enriched and
  changed forever.




  David Burdett et al.                                        [Page 9]

  Internet Draft                IOTP/1.0               23 October 1998


  One of the very fundamental changes about which IOTP is concerned is
  taking place in the way consumers and merchants trade. Characteristics
  of trading that have changed markedly include:
  o  Presence: Face-to-face transactions become the exception, not
     the rule. Already with the rise of mail order and telephone
     order placement this change has been felt in western commerce.
     Electronic commerce over the Internet will further expand the
     scope and volume of transactions conducted without ever seeing
     the people who are a part of the enterprise with whom one does
     business.
  o  Authentication: An important part of personal presence is the
     ability of the parties to use familiar objects and dialogue to
     confirm they are who they claim to be. The seller displays one
     or several well known financial logos that declaim his ability
     to accept widely used credit and debit instruments in the
     payment part of a purchase. The buyer brings government or
     financial institution identification that assures the seller
     she will be paid. People use intangibles such as personal
     appearance and conduct, location of the store, apparent
     quality and familiarity with brands of merchandise, and a good
     clear look in the eye to reinforce formal means of
     authentication.
  o  Payment Instruments: Despite the enormous size of bank card
     financial payments associations and their members, most of the
     world's trade still takes place using the coin of the realm or
     barter. The present infrastructure of the payments business
     cannot economically support low value transactions and could
     not survive under the consequent volumes of transactions if it
     did accept low value transactions.
  o  Transaction Values: New meaning for low value transactions
     arises in the Internet where sellers may wish to offer for
     example, pages of information for fractions of currency that
     do not exist in the real world.
  o  Delivery: New modes of delivery must be accommodated such as
     direct electronic delivery. The means by which receipt is
     confirmed and the execution of payment change dramatically
     where the goods or services have extremely low delivery cost
     but may in fact have very high value. Or, maybe the value is
     not high, but once delivery occurs the value is irretrievably
     delivered so payment must be final and non-refundable but
     delivery nonetheless must still be confirmed before payment.
     Incremental delivery such as listening or viewing time or
     playing time are other models that operate somewhat
     differently in the virtual world.



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

  David Burdett et al.                                       [Page 10]

  Internet Draft                IOTP/1.0               23 October 1998


  with any other vendors' software. However since IOTP focuses on how
  these solutions communicate, there is still plenty of opportunity for
  product differentiation.

     Payment Brands

  IOTP provides a standard framework for encapsulating payment
  protocols. This means that it is easier for payment products to be
  incorporated into IOTP solutions. As a result the payment brands will
  be more widely distributed and available on a wider variety of
  platforms.

     Merchants

  There are several benefits for Merchants:
  o  they will be able to offer a wider variety of payment brands,
  o  they can be more certain that the customer will have the
     software needed to complete the purchase
  o  through receiving payment and delivery receipts from their
     customers, they will be able to provide customer care knowing
     that they are dealing with the individual or organisation with
     which they originally traded
  o  new merchants will be able to enter this new (Internet)
     market-place with new products and services, using the new
     trading opportunities which IOTP presents

     Banks and Financial Institutions

  There are also several benefits for Banks and Financial Institutions:
  o  they will be able to provide IOTP support for merchants
  o  they will find new opportunities for IOTP related services:
     - providing customer care for merchants
     - fees from processing new payments and deposits
  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







  David Burdett et al.                                       [Page 11]

  Internet Draft                IOTP/1.0               23 October 1998


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
  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





  David Burdett et al.                                       [Page 12]

  Internet Draft                IOTP/1.0               23 October 1998


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.

  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 a generic overview of the exception handling. This
     section should be read carefully.


  David Burdett et al.                                       [Page 13]

  Internet Draft                IOTP/1.0               23 October 1998


  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.


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

  David Burdett et al.                                       [Page 14]

  Internet Draft                IOTP/1.0               23 October 1998


  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      Initial draft for comment
                  1997

  Version 0.2     14 April 1997    Revised draft including changes
                                   arising from comments

  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
                                   IOTP dev

  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.















  David Burdett et al.                                       [Page 15]

  Internet Draft                IOTP/1.0               23 October 1998





2. Introduction


  The 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 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  Payment Instrument Customer Care. This supports the provision
     of Payment Brand or Payment Method specific customer care of a
     Payment Instrument
  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.

  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 five Trading Roles used within IOTP are
  illustrated in the diagram below.

  David Burdett et al.                                       [Page 16]

  Internet Draft                IOTP/1.0               23 October 1998



           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          ----------
     |
     |                                                ----------
     |   Payment Instrument Customer Care Provider   | Payment  |
      ---------------------------------------------->|Instrument|
         resolves problems with Payment Instruments  |Cust.Care.|
                                                     | Provider |
                                                      ----------

  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
  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
  o  Payment Instrument Customer Care Provider. The entity that
     resolves problems with a particular Payment Instrument

  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,

  David Burdett et al.                                       [Page 17]

  Internet Draft                IOTP/1.0               23 October 1998


     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
  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.


  David Burdett et al.                                       [Page 18]

  Internet Draft                IOTP/1.0               23 October 1998


  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.


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                OTP MESSAGE             MERCHANT
1. Consumer decides to   ---------------------->  2. Merchant checks
pay (request an offer)   Information on what is     the information
 and sends information   being purchased (Offer     provided by the
on what to purchase to   Request) (outside scope   Consumer, creates
the Merchant using e.g.          of OTP)          and Offer and sends
         HTML                                     it to the Consumer.
                                                           |
                                                           v
                                        Components: Organisation(s)
3. Consumer checks the                (Consumer, DeliverTo, Merchant,
 information from the    <----------     Payment Handler, Delivery
 Merchant and decides       Offer     Handler, Cust Care); Order; Pay
  whether to continue     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
     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

  David Burdett et al.                                       [Page 19]

  Internet Draft                IOTP/1.0               23 October 1998


     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 could be 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 and Order Components in a later
     version of IOTP.


2.2.2 Payment Exchange

  The goal of the Payment Exchange is for a payment to be made from the
  Consumer to a Payment Handler or vice versa using a payment brand and
  payment protocol selected by the Consumer. A secondary goal is to
  optionally provide the Consumer with a digitally signed Payment
  Receipt which can be used to link the payment to the reason for the
  payment as described in the Offer Exchange.

  Payment Exchanges can work in a variety of ways. The most general case
  where the trade is dependent on the payment brand and protocol used is
  illustrated in the diagram below. Simpler payment exchanges are
  possible.

        CONSUMER                OTP MESSAGE             MERCHANT
 1. Consumer decides to                           2. Merchant decides
    trade and sends       Information on what is  which payment brand
 information on what to       being paid for        and protocols to
    purchase to the       ---------------------->  offer, places then
  Merchant, e.g. using    (outside scope of OTP)    in a Brand List
          HTML                                    Component and sends
                                                      them to the
                                                       Consumer.

  David Burdett et al.                                       [Page 20]

  Internet Draft                IOTP/1.0               23 October 1998


                                                              |
                                                              v
  3. Consumer selects the payment   <-----------------   Brand List
brand and protocol to use, creates a    Brand List        Component
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 send 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
 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
            v                         Components: Pay Receipt; Pay
  8 Consumer checks Pay                scheme; Signature (Offer);
      Receipt is OK        <-------      Signature (Pay Receipt)
                            Payment     (signs Pay Receipt and
                           Response   Signature (Offer) components)

  Figure 3 Payment Exchange



  David Burdett et al.                                       [Page 21]

  Internet Draft                IOTP/1.0               23 October 1998


  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) and 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). The Merchant sends the Brand List to the Consumer. The
     consumer compares the payment brands and protocols 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 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 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 optional Authentication Data Component contains challenge
     data which is used by the payment protocol to authenticate the
     consumer. Authentication may not always occur
  o  The Payment Component contains details of how much to pay, the
     currency and the payment direction, and identifies the
     Authentication Data Component to use.
  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 3 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 Signature. The signature on the offer
     digitally signs the Order, Organisation and Delivery


  David Burdett et al.                                       [Page 22]

  Internet Draft                IOTP/1.0               23 October 1998


     Components contained in the Offer. This signature effectively
     binds the payment to the offer.

  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 8.3).


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. A future
  goal is to have a signed delivery that can be used for customer care
  in the case of problems with physical delivery. This is illustrated in
  the diagram below.

       CONSUMER              OTP 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 OTP)  delivery and optionally signs
                                                      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
                                                      |
                                                      v
  5. Consumer checks delivery    <---------  Component: Delivery
note is OK and accepts or waits   Delivery           Note
 for delivery as described in     Response

  David Burdett et al.                                       [Page 23]

  Internet Draft                IOTP/1.0               23 October 1998


       the Delivery Note

  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.


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. This is illustrated in the
  diagram below.

    ORGANISATION 1             OTP MESSAGE           ORGANISATION 2
 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 data
    HTML page) which       Authentication        and the method of
   requires that the      (outside scope of  authentication to be used
    organisation is             OTP)           then sends it to the
     authenticated                              first organisation

  David Burdett et al.                                       [Page 24]

  Internet Draft                IOTP/1.0               23 October 1998


                                                         |
                                                         v
3. The first organisation uses                        Component:
  the challenge data with the    <------------    Authentication Data
specified authentication method  Authentication
 to generate an Authentication      Request
Response which is sent back to
    the second organisation
       |
       v
  Component:
Authentication   ------------->    4. The Authentication Response is
   Response      Authentication  checked against the challenge data to
                    Response     check that the first organisation is
                                         who they appear to be

  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 and
     indicates the authentication method to be used. 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.



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

  The following table defines, for each role, the IOTP Transactions and
  Trading Blocks which must be supported for that role.

  David Burdett et al.                                       [Page 25]

  Internet Draft                IOTP/1.0               23 October 1998



                    Merchants

                     ECash   ECash
              Store  Value   Value   Consumer Payment Delivery   Pay
                     Issuer Acquirer          Handler Handler   Inst.
                                                                 Cuts
                                                                 Care

TRANSACTIONS

Purchase    Must                     Must

Refund      Must                     b)
                                     Depends

Authent-    May      Must   May      b)
ication                              Depends

Value       May                      Must
Exchange

Withdrawal           Must            b)
                                     Depends

Deposit                     Must     b)
                                     Depends

Inquiry     Must     Must   Must     Must     Must    Must     Must

Ping        Must     Must   Must     Must     Must    Must     Must

Pay Inst.                            b)                        Must
Cust. Care                           Depends

  TRADING
   BLOCKS

TPO         Must     Must   Must     Must

TPO         Must     Must   Must     Must
Selection

Auth-Requesta)              a)       a)
            Depends         Depends  Depends

Auth-Reply  a)              a)       a)
            Depends         Depends  Depends

Offer       Must     Must   Must     Must
Response

Payment                              Must     Must

  David Burdett et al.                                       [Page 26]

  Internet Draft                IOTP/1.0               23 October 1998



                    Merchants

                     ECash   ECash
              Store  Value   Value   Consumer Payment Delivery   Pay
                     Issuer Acquirer          Handler Handler   Inst.
                                                                 Cuts
                                                                 Care
Request

Payment                              Must     Must
Exchange

Payment                              Must     Must
Response

Delivery                             Must             Must
Request

Delivery                             Must             Must
Response

Pay Inst.                            b)                        Must
Cust Care                            Depends
Req.

Pay Inst.                            b)                        Must
Cust Care                            Depends
Resp

Inquiry     Must     Must   Must     Must     Must    Must     Must
Request

Inquiry     Must     Must   Must     Must     Must    Must     Must
Response

Ping RequestMust     Must   Must     Must     Must    Must     Must

Ping        Must     Must   Must     Must     Must    Must     Must
Response

Signature   Must     Must   Must     Limited  Must    Must     b)
                                                               Depends

Error       Must     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:

  David Burdett et al.                                       [Page 27]

  Internet Draft                IOTP/1.0               23 October 1998


     - if Baseline Authentication IOTP Transaction is
       supported;

     - 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".



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 Merchant and Payment Instrument
     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 such as
  o  IOTP Signature Components which use digital signature
     techniques to preserve the integrity of IOTP Messages and
     provide the trust relationships required by IOTP
  o  how extra XML Elements and new user defined values for
     existing IOTP codes can be used when Extending IOTP, and
     finally






  David Burdett et al.                                       [Page 28]

  Internet Draft                IOTP/1.0               23 October 1998


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.

OTP MESSAGE  <----------- OTP Message - an XML Document which is
 |                        transported between the Trading Roles
 |-Trans Ref Block <----- Trans Ref Block - contains information which
 |  |                     describes the OTP Transaction and the OTP
 |  |                     Message.
 |  |-Trans Id Comp. <--- Transaction Id Component - uniquely
 |  |                     identifies the OTP Transaction. The Trans Id
 |  |                     Components are the same across all OTP
 |  |                     messages that comprise a single OTP
 |  |                     transaction.
 |  |-Msg Id Comp. <----- Message Id Component - identifies and
 |                        describes an OTP Message within an OTP
 |                        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 hashes of the
 |  |                     Trans Ref Block and any Trading Component in
 |  |                     any OTP Message in the same OTP Transaction.
 |  |-Certificate Comp. < Certificate Component. Used to check the
 |                        signature.
 |-Trading Block <------- Trading Block - an XML Element within an OTP
 |  |-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
 |
 |

  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

  David Burdett et al.                                       [Page 29]

  Internet Draft                IOTP/1.0               23 October 1998


  globally unique identifier in the Transaction Reference Block is
  sufficient to uniquely identify any Trading Block or Trading
  Component.


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
                                                         OTP Message
                                   ---                        |
                                  |   |                       v
 Process incoming                 | I |                 -------------
  OTP Message &    <------------- |   | -------------- | OTP Message |
generate next OTP                 |   |                 -------------
     Message                      | N |
        |                         |   |
        v                         |   |
  -------------                   | T |                Process incoming
 | OTP Message |   -------------- |   | ------------->  OTP Message &
  -------------                   |   |               generate next OTP
                                  | E |                    Message
                                  |   |                       |
                                  |   |                       v
 Process incoming                 | R |                 -------------
   OTP Message     <------------- |   | -------------- | OTP Message |
generate last OTP                 |   |                 -------------
  Message & stop                  | N |
        |                         |   |
        v                         |   |
  -------------                   | E |                  Process last
 | OTP Message |   -------------- |   | ------------->   incoming OTP
  -------------                   |   |                 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.

  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


  David Burdett et al.                                       [Page 30]

  Internet Draft                IOTP/1.0               23 October 1998


  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  Payment Instrument Customer Care. This supports the provision
     of Payment Brand or Payment Method specific customer care of a
     Payment Instrument
  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 organisations that are taking
  part in a trade.

  The XML definition of an IOTP Message is as follows.






















  David Burdett et al.                                       [Page 31]

  Internet Draft                IOTP/1.0               23 October 1998



<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
     ( AuthReqBlk |
       AuthRespBlk |
       DeliveryReqBlk |
       DeliveryRespBlk |
       InquiryReqBlk |
       InquiryRespBlk |
       OfferRespBlk |
       PayExchBlk |
       PayReqBlk |
       PayInstCCExchBlk |
       PayInstCCReqBlk |
       PayInstCCRespBlk
       PayRespBlk |
       PingReqBlk |
       PingRespBlk |
       TpoBlk |
       TpoSelectionBlk |
       )*
     ) >

  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 Open
OfferRespBlk,      Trading Protocol Transactions.
PayExchBlk,
PayReqBlk,         Full definitions of each Trading Block are
PayInstCCExchBlk,  described in section 7.
PayInstCCReqBlk,
PayInstCCRespBlk
PayRespBlk,
PingReqBlk,
PingRespBlk,
SigBlk,
TpoBlk,
TpoSelectionBlk







  David Burdett et al.                                       [Page 32]

  Internet Draft                IOTP/1.0               23 October 1998


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:

<?XML Version='1.0'?>
<!DOCTYPE OtpMessage >
<OtpMessage>
  ...
</OtpMessage>



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:

<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
  ID ID          #REQUIRED >

  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.




  David Burdett et al.                                       [Page 33]

  Internet Draft                IOTP/1.0               23 October 1998


3.3.1 Transaction Id Component

  This contains information which globally uniquely identifies the IOTP
  Transaction. Its definition is as follows:

<!ELEMENT TransId EMPTY>
<!ATTLIST TransId
  ID ID          #REQUIRED
  Version        NMTOKEN #FIXED '1.0'
  OtpTransId     NMTOKEN #REQUIRED
  OtpTransType   CDATA   #REQUIRED >
  TransTimeStamp CDATA   #REQUIRED >

  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
                   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
                   o  BaselinePayInstrumentCustomerCare
                   o  x-ddd:nnn

                   A value for OtpTransType of x-ddd:nnn indicates a
                   user defined transaction type. See section 3.7.3
                   User Defined Codes.

                   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

  David Burdett et al.                                       [Page 34]

  Internet Draft                IOTP/1.0               23 October 1998


                   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.


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.

<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
  ID ID          #REQUIRED
  RespOtpMsg     NMTOKEN #IMPLIED
  xml:lang       NMTOKEN #REQUIRED
  SoftwareId     CDATA   #REQUIRED
  TimeStamp      CDATA   #IMPLIED >

  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.

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

  David Burdett et al.                                       [Page 35]

  Internet Draft                IOTP/1.0               23 October 1998


                   software which generated the IOTP Message. 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

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.

<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  RelationshipType       NMTOKEN #REQUIRED
  Relation       CDATA   #REQUIRED
  RelnKeyWords   NMTOKENS  #IMPLIED >

  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,
                      non-IOTP document.
                   o  x-ddd:nnn a user defined code (see section
                      3.7.3)

Relation           The Relation attribute contains a phrase in the

  David Burdett et al.                                       [Page 36]

  Internet Draft                IOTP/1.0               23 October 1998


                   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 implementer 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 the implementer.

  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.



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

  David Burdett et al.                                       [Page 37]

  Internet Draft                IOTP/1.0               23 October 1998


  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.


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.14), 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

  David Burdett et al.                                       [Page 38]

  Internet Draft                IOTP/1.0               23 October 1998


                    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

                  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 "." IdSuffix
IdSuffix ::= Digit (Digit)*

OtpMsgId           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.

                   Digit has the same definition as the [XML]

  David Burdett et al.                                       [Page 39]

  Internet Draft                IOTP/1.0               23 October 1998


                   definition of Digit.


3.4.3 Example of use of ID Attributes

  The diagram below illustrates how ID attribute values are used.

       1st  OTP MESSAGE                           2nd OTP MESSAGE
    (e.g. from Merchant to                    (e.g. from Consumer to
           Consumer                              Payment Handler)

OTP MESSAGE                                OTP 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




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 hash value 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.

  David Burdett et al.                                       [Page 40]

  Internet Draft                IOTP/1.0               23 October 1998


  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.

       1st  OTP MESSAGE                           2nd OTP MESSAGE
    (e.g. from Merchant to                    (e.g. from Consumer to
           Consumer                              Payment Handler)

OTP MESSAGE                                OTP 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] 
            



  David Burdett et al.                                       [Page 41]

  Internet Draft                IOTP/1.0               23 October 1998


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
  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 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.


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, American
     Express, Mondex, GeldKarte, CyberCash, etc.
  o  promotional brands (see below). These include:



  David Burdett et al.                                       [Page 42]

  Internet Draft                IOTP/1.0               23 October 1998


     - 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] 
            


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


  David Burdett et al.                                       [Page 43]

  Internet Draft                IOTP/1.0               23 October 1998


     - 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

  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.


  David Burdett et al.                                       [Page 44]

  Internet Draft                IOTP/1.0               23 October 1998


  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.



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 45]

  Internet Draft                IOTP/1.0               23 October 1998


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 user-defined values for existing IOTP codes.


3.7.1 Extra XML Elements

  The XML element and attribute names used within IOTP constitute an
  [XML Namespace]. This allows IOTP to support the inclusion of
  additional XML elements within IOTP messages through the use of [XML
  Namespaces].

  [Note]   In drafts of the [XML] specification, the concept of
           "Namespaces" have been discussed. However they are not
           present in the XML documentation submitted for approval (see
           XML draft dated 8 December 1997) although it appears as if
           they may be included in version 1.1 of XML. It is considered
           by the authors of this document that IOTP would be an ideal
           example of a Namespace so that other XML elements with
           potentially the same name can be included unambiguously in
           XML documents which conform to this specification. If
           Namespaces, or an equivalent, is not developed for XML as a
           whole then IOTP is likely to propose its own equivalent. The
           Views of other organisations on this topic are sought.
  [Note End] 
            

  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]. This means that:
     - the namespace must be declared to the XML parser
     - each element must have a start and end tags which conform 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.


  David Burdett et al.                                       [Page 46]

  Internet Draft                IOTP/1.0               23 October 1998


  The purpose of this attribute is to allow an IOTP aware application to
  determine if the IOTP transaction can safely continue. Specifically:
  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 must fail. See section 6.19 Error Component.
  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 hashed 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 User Defined Codes

  User defined codes provide a simple way to identify additional values
  for the codes contained within this specification.

  The definition of a user defined code is as follows:

user_defined_code ::= ( "x-" | "X-" ) domain_name ":" name

domain_name    A name which identifies the organisation which is
               creating the user defined code (see [DNS]). The
               purpose of this field is to reduce the probability of
               two organisations creating the same user-defined name

name           A name specified by the organisation which owns the
               domain_name which identifies the user defined code
               within the domain_name.

  David Burdett et al.                                       [Page 47]

  Internet Draft                IOTP/1.0               23 October 1998


  User defined codes are identified in this specification as "x-
  ddd:nnn". The values of User Defined Codes must conform to the rules
  for the specific code (see explanations of the individual codes).



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.

  In general it is used to encapsulate any data stream.

  This data stream has two standardised attributes that allow for
  decoding and interpretation of the contents. Its definition is as
  follows.

<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent
  Content        CDATA   "PCDATA"
  Transform (NONE|BASE64)  "NONE" >

  Attributes:

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
                      Element can be treated as an XML document.
                      Entities and CDATA sections, or Transform set to

  David Burdett et al.                                       [Page 48]

  Internet Draft                IOTP/1.0               23 October 1998


                      BASE64, must be used to ensure that the Packaged
                      Content Element contents are legitimate PCDATA.
                   o  x-ddd:usercode. The content is private, where
                      ddd represents a domain name of a user, and
                      usercode represents a particular content format
                      defined by that user. The guidelines around a x-
                      ddd are very loose. Given company FFGGHH Inc.,
                      all of x-www.ffgghh.com, x-ffgghh.comand and
                      x-ffgghh are legitimate examples. However, only
                      one should be the correct format, as defined by
                      FFGGHH Inc.

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 &amp; and &#9;)
                      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.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
  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.

  David Burdett et al.                                       [Page 49]

  Internet Draft                IOTP/1.0               23 October 1998


  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
     preference the preference of the sender of the message.





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 (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.


  David Burdett et al.                                       [Page 50]

  Internet Draft                IOTP/1.0               23 October 1998


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 6.19) in an Error
  Block (see section 7.19) sent by the party which detected the error in
  an IOTP message to the party which sent the erroneous message.

  If communications 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 (see section 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.15) of a "response
  block" of the normal 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 Purchase (see section 8.3.1), 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, t