September  TRADE Working Group                                    David Burdett

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

                 Internet Open Trading Protocol (IOTP) - IOTP
                              Version 1.0
           -------- ---- ------- -------- ------ ------- ---

                         Donald E. Eastlake 3rd

  Status of This Document

   A later version of this draft, file name draft-ietf-trade-iotp-v1.0-
   protocol-01.txt, is intended to become an Informational RFC.
   Distribution of this document is unlimited.  Comments should be sent
   to the TRADE WG mailing list <ietf-trade@eListX.com>. Memo

  This document is an Internet-Draft.  Internet-Drafts Internet draft. Internet drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas, areas and
  its working groups. Note that other groups may also distribute working documents
  information as Internet-Drafts.

   Internet-Drafts Internet drafts.

  Internet Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may months
  and can be updated, replaced, replaced or obsoleted by other documents at any
  time. It is not appropriate inappropriate to use Internet-
   Drafts Internet drafts as reference material
  or to cite them as other than as a
   ``working draft'' or ``work "work in progress.'' progress".

  To view learn the entire list of current Internet-Drafts, status of any Internet draft please check the
   "1id-abstracts.txt"
  "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories Internet drafts shadow
  directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), coast) or
  ftp.isi.edu (US West Coast).

   Technical control over coast). Further information about the Internet Open Trading Protocol IETF can be
  found at URL: http://www.ietf.org/

  Distribution of this document is being
   transfered unlimited. Please send comments to
  the IETF TRADE  working group from the OTP Consortium.
   In some cases, the most current version of techncial documents is an
   OTP Consortium version that has not yet been republished as an RFC
   and is available from <http://www.otp.org> web site (which has not
   yet been fully updates to indicate the technical switch to the IETF).

   In this case, see
   <http://www.otp.org/otp/Home.nsf/f86055a20977be50862564b3004d010a/
   42b496239c5956aa8625655a007b1835/$FILE/OTP_Spec_v_0-9-9_ltr.pdf>.  It
   is intended that that document at <ietf-trade@lists.elistx.com >, which may
  be published as an later verson joined by sending a message with subject "subscribe" to <ietf-
  trade-request@lists.elistx.com>.

  Discussions of
   this internet-draft and then as an Informational RFC. 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 can
  encapsulates a variety of payment systems. 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 Delivery Handler of
  goods or services, and the provider of customer care support are performed
  by different parties or by one party.

   [This draft is a place holder for an internet-draft version of the
   v1.0 starting point for the trade working group.]

  Table of Contents

  Status of This Document....................................1

      Abstract...................................................2
      Table of Contents..........................................2

      1. Place Holder............................................3
      2. Security Considerations.................................3

      References.................................................4
      Author's Address...........................................4
      Expiration and File Name...................................4 this Memo................................................1

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

  1. Place Holder

   Technical control over Background......................................................9
     1.1 Commerce on the Internet Open _ 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
     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 being
   transfered Correctly Calculated...............68
     5.3 Checking a Payment or Delivery can occur...................69
       5.3.1 Check the Action Request was sent to the IETF TRADE working group from Correct
       Organisation ................................................69
       5.3.2 Check the OTP Consortium.
   In some cases, Correct Components are present in the most current version of technical documents is Request
       Block .......................................................73
       5.3.3 Check an
   OTP Consortium version 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
     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
       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
       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
  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
  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

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.

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

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

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.

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

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.

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

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

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

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

     - 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

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

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

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.

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

  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]

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:

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

  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]

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.

  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.

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

  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.

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, the user might want to put more funds into the
  instrument/account and try again.

4.3 Error Depth

  The three levels at which IOTP errors can occur are the transport
  level, the message level, and the block level. Each is described
  below.

4.3.1 Transport Level

  This level of error indicates a fundamental problem in the transport
  mechanism over which the IOTP communication is taking place.

  All transport level errors are technical errors and are indicated by
  either an explicit transport level error indication, such as a "No
  route to destination" error from TCP/IP, or by a time out where no
  response has been received to a request.

  The only reasonable automatic action when faced with transport level
  errors is to retry and, after some number of automatic retries, to
  inform the user.

  The explicit error indications that can be received are transport
  dependent and the documentation for appropriate IOTP Transport
  supplement should be consulted for errors and appropriate actions.

  Appropriate time outs to use are a function of both the transport
  being used and of the payment system if the request encapsulates
  payment information. The transport and payment system specific
  documentation should be consulted for time out and automatic retry
  parameters. Frequently there is no way to directly inform the other
  party of transport level errors but they should generally be logged
  and if automatic recovery is unsuccessful and there is a human user,
  the user should be informed.

4.3.2 Message Level

  This level of error indicates a fundamental technical problem with an
  entire IOTP message. For example, the XML is not Well formed, or the
  message is too large for the receiver to handle or there are errors in
  the Transaction Reference Block (see section 3.3) so it is not
  possible to figure out what transaction the message relates to.

  All message level errors are technical errors and are indicated by an
  Error Component (see section 6.19) sent to the other party. The Error
  Component  includes a Severity attribute which indicates whether the
  error is a Warning and may be ignored, a TransientError which
  indicates that a retry may resolve the problem or a HardError in which
  case the transaction must fail.

  The Technical Errors (see section 6.19.2 Error Codes) that are Message
  Level errors are:

  o  XML not well formed. The document is not well formed XML (see
     [XML])
  o  XML not valid. The document is not valid XML (see [XML])
  o  block level technical errors (see section 4.3.3) on the
     Transaction Reference Block (see section 3.3) and the
     Signature Block only. This should only be carried out if the
     XML is valid

  Note that checks on the Signature Block includes checking, where
  possible, that each Signature Component is correctly calculated. If
  the Digital Signature Element is incorrectly calculated then the data
  that should have been covered by the signature can not be trusted and
  must be treated as erroneous. A description of how to check a
  signature is correctly calculate is contained in section 5.2 Checking
  a Signature is Correctly Calculated.

4.3.3 4Block Level

  A Block level error indicates a problem with a block or one of its
  components in an IOTP message (apart from Transaction Reference or
  Signature Blocks). The message has been transported properly, the
  overall message structure and the block/component(s) including the
  Transaction Reference and Signature Blocks are meaningful but there is
  some error related to one of the other blocks.

  Block level errors can be either:
  o  technical errors, or
  o  business errors

  Technical Errors are further divided into:
  o  Block Level Attribute and Element Checks, and
  o  Block and Component Consistency Checks

  If a technical error occurs related to a block or component, then an
  Error Component is returned and, unless it is merely a warning, the
  usual response block is suppressed.

4.3.3.1 Block Level Attribute and Element Checks

  Block Level Attribute and Element Checks occur only within the same
  block. Checks which involve cross-checking against other blocks are
  covered by Block and Component Consistency Checks.

  The Block Level Attribute & Element checks are:
  o  checking that each attribute value within each element in a
     block conforms to any rules contained within this IOTP
     specification
  o  checking that the content of each element conforms to any
     rules contained within this IOTP specification
  o  if the previous checks are OK, then cross-checking attribute
     values and element content against other attribute values or
     element content within any other components in the same block.

4.3.3.2 Block and Component Consistency Checks

  Block and Component Consistency Checks consist of:
  o  checking that the combination of blocks and/or components
     present in the IOTP Message are consistent with the rules
     contained within this IOTP specification
  o  checking for consistency between attributes and element
     content within the blocks within the same IOTP message.
  o  checking for consistency between attributes and elements in
     blocks in this IOTP message and blocks received in earlier
     IOTP messages for the same IOTP transaction

4.3.3.3 Block Business Errors

  If a business error occurs in a process such as a Payment or a
  Delivery, then the usual type of response block is returned. The
  Status Component (see section 6.15) within that response block
  indicates the error and its severity. No Error Component or Error
  Block is generated for business errors.

4.4 Idempotency, Processing Sequence, and Message Flow

  IOTP messages are actually a combination of blocks and components as
  described in 3.1.1 IOTP Message Structure. Especially in future
  extensions of IOTP, a rich variety of combinations of such blocks and
  components can occur. It is important that the multiple
  transmission/receipt of the "same" request for state changing action
  not result in that action occurring more than once. This is called
  idempotency. For example, a customer paying for an order would want to
  pay the full amount only once. Most network transport mechanisms have
  some probability of delivering a message more than once or not at all,
  perhaps requiring retransmission. On the other hand, a request for
  status can reasonably be repeated and should be processed fresh each
  time it is received.

  Correct implementation of IOTP can be modelled by a particular
  processing order as detailed below. Any other method that is
  indistinguishable in the messages sent between the parties is equally
  acceptable.

4.4.1 Server Role Processing Sequence

  "Server roles" are any Trading Role which is not the Consumer role.
  They are "Server roles" since they typically receive a request which
  they must service and then produce a response.

  The model processing sequence for a Server role is indicated in the
  diagram below.

                            -------------
                           |    Input    |
                           | OTP Message |
                            -------------
                                  |
                                  v
                           1. Check for transport -------------->
                           or message level errors   Errors       |
                                      |OK                         |
                                      v                           |
   11. Generate output <-------2. More Blocks <------------------ +-
         message               No    to process?                  | |
            |                        |Yes                         | |
            v                         v                           | |
      -------------           3. Check Block OK --------------->  | |
     |    Output   |                 |               Errors       | |
     | OTP Message |                 |Checks OK                   | |
      -------------                  v                            | |
                    ----- ---4. Type of  Block ? -------          | |
                   |           |           |            |         | |
      ----- ---Status       Action   Encapsulating     Error      | |
     |         Request      Request      Block         Block      | |
     |                         |           |             |        | |
     |                         v           v             v        | |
     |                 6a. Action     7. Process     8.Error      | |
     |                  Request -    encapsulated     Block ?     | |
     |                  received      message and       |         | |
     |                   before?--     generate --      v         | |
     |                   |        |     response   |   STOP   ----  |
     |                   |Yes     |No        OK|   |         |      |
     |                   v        v            |   |Errors   v      |
     |       6b. Processing 6e. Process Action |   ------> 9. Gen   |
     |          of Block    Request & generate-+--------->Error     |
     |        Complete ?-     response block-  | Errors   Block &   |
     |           |       |       ^           | |           store    |
     |           |       |       |           | |            |       |
     |           |Yes    |No     |     Ok or | |            |       |
     |           |        ---    |   Warning |  --------    |       |
     v           v           v   |           v          |   |       |
5. Generate  6c. Retrieve  6d. Wait for   6f. Store     |   |       |
   Status     and resend     process      request &     |   |       |
  Response     previous     completion    response      |   |       |
   Block        Block                       block       |   |       |
     |            |                           |         v   v       |
      ---------------------------------------------- 10. Add block--
                                                     to output
                                                     message

  Figure 10 Server Role Processing Sequence

  Each of the processes in the sequence is described in more detail
  below.

4.4.1.1 Check for Transport or Message Level Error

  On receipt of an IOTP request message (step 1), first check for
  transport or message level errors (see sections 4.3.1 and 4.3.2).
  These are errors which indicate that the entire message is corrupt and
  can not reliably be associated with any particular transaction or, if
  it can be associated with a transaction, the interior information in
  the message can not be reliably accessed.

  If the OtpTransId attribute in the Transaction Id Component (see
  section 3.3.1) can be determined, set up a response message with an
  appropriate Error Component. Perform local actions such as making log
  entries.

  If the value of the OtpTransId attribute is not recognised as
  belonging to an IOTP transaction when other Blocks in the IOTP Message
  indicate that it should be recognised, then report the error using an
  Error Component with a Severity of HardError, an ErrorCode set to
  AttValNotRecog (attribute value not recognised), and an Error Location
  element (see section 6.19.3) that points to the OtpTransId attribute.

  No idempotency related actions are necessary.

4.4.1.2 Process all the blocks

  If there are no message level errors, process each of the blocks
  within the message which has not been processed (step 2).

  Once all the blocks have been processed, generate a response message
  (step 11) and send it to the requester unless there are fatal
  transport level problems. As recommended for the particular transport
  used, a limited number of automatic response retransmission attempts
  may be appropriate.

  It may be desirable to log the complete response message at the
  server. Failure of the requester to receive a response may lead to a
  time-out and a retransmission of the request. Following the procedures
  above, a duplicate request message should produce a duplicate of the
  previous response except for changes in status and transient error
  conditions that have changed.

4.4.1.3 Check the Block is OK

  Check the block is OK (see section 4.3.3). For each block level error
  found, an appropriate Error Component should be created to be included
  in the IOTP Message sent back to the Consumer. Note that some checking
  of the Transaction Reference Block and the Signature Block has
  occurred as part of Message Level error checking.

  If one or more of the Error Components contain a Severity attribute
  with a value of TransientError or HardError, then no response block
  need be generated and no further processing of the block, including
  idempotency related actions are necessary.

4.4.1.4 Determine the Type of the Block

  Trading Blocks that survive the above steps and thus have no errors,
  or at worst have added a warning error component to the response, can
  receive further processing. The nature of the processing depends (step
  4) on whether the block is a Status Request, Action Request, an Error
  Block or contains an Encapsulated Message.

4.4.1.5 Status Request Blocks

  Status Request Blocks (step 5) are either:
  o  Inquiry Request Trading Block (see section 7.14), or
  o  Ping Request Block (see section 7.16).

  These status requests do not change state and are processed fresh to
  get the current status. The appropriate response block should be added
  to the IOTP message being composed.

  No idempotency actions are required.

4.4.1.6 Action Request Blocks

  Blocks which request an action and change state need to be subject to
  idempotency duplicate filtering by checking to see if the same block
  for the same transaction has been previously stored (step 6a) at the
  server as described later.

  If the Block has been received previously then:

  o  if processing of the previously stored block is complete (step
     6b) then the same IOTP Block as previously produced must be
     included for resending to the Consumer (step 6c).
  o  if processing is not complete, wait until the processing is
     complete (step 6d) before sending the response.

  If the block has not been received before, the action request is
  processed normally (step 6e) producing a response block that is added
  to the response message. This might or might not indicate a business
  error.

  If there is a transient error indicated by an Error Component that
  contains a Severity attribute set to TransientError, then apart from
  sending the Error Block, no further actions should be taken so the
  action can be retried.

  If there is no Transient Error, then the transaction id, the request
  block, and the response block must be stored (step 6f) so they can be
  found as described above (step 6a) should a duplicate IOTP action
  request block be received for this transaction in the future.

  [Note]   Most business errors should be labelled as a TransientError
           as there is usually some possibility they will be corrected
           over time or some user action exists that can fix them.
           Requesters are expected to understand business errors and
           the appropriate time scale for user actions for retrying.
  [Note End]

4.4.1.7 Encapsulating Blocks

  Blocks which encapsulate a payment protocol (step 7) pass along the
  enclosed information to the payment system involved.

  IOTP does not know the meaning of the enclosed information. It is thus
  up to the payment system involved to handle error detection and
  idempotency. Payment systems adapted for the Internet include
  idempotency handling because duplicates are always possible. Should a
  payment system have no idempotency handling, a layer between IOTP and
  the payment system must be added to take care of this.

  No IOTP level idempotency actions are required for encapsulating
  blocks. The payment system must return material to be encapsulated in
  the IOTP response message along with indications as to whether the
  exchange will continue or this is the final response and an indication
  whether an error occurred. If a payment protocol error has occurred,
  an Error Component is added to the response block.

4.4.1.8 Error Block Received

  An error block (step 8) should not occur in a request and should be
  treated as an unexpected element with a Severity of HardError. No
  response to the block should be made in order to avoid the risk of
  loops.

  [Note]   Consumers should send Error Blocks to a server specified in
           the ErrorNetLocn attribute of the appropriate Trading Role
           element as a response to the detection of an error in an
           IOTP Message that has been received (see section 4.4.1.9
           Generate Error Block). This may be the same server as is
           used to accept IOTP Messages which contain no error. In this
           case, the error block must not considered as a fatal error.
  [Note End]

4.4.1.9 Generate Error Block

  If any of the previous steps resulted in an error being detected and
  an Error Component being created then generate an Error Block (step 9)
  containing the Error Components that describe the error(s).

  Unless the error is a "Transient Error", the Error Component(s) and
  the request block which caused the Error Components to be generated
  should be stored so that it can be reused if the action request is
  received again (step 6a).

  "Transient Errors" are not stored so that if the original Response
  Block is received again, then it can be processed as if it had never
  been received before.

4.4.1.10 Add Block to Output Message

  Any Blocks which have been created as a result of processing the block
  received are added to the output message.

4.4.2 Client Role Processing Sequence

  The "Client role" in IOTP is the Consumer Trading Role.

  [Note]   A company or organisation that is a Merchant, for example,
           may take on the Trading Role of a Consumer when making a
           purchase or downloading or withdrawing electronic cash.
  [Note End]

  The model processing sequence for a Client role is indicted in the
  diagram below.

                            -------------
                           |    Input    |
                           | OTP Message |
                            -------------
                                  |
                                  v
                           1. Check for transport -->
                           or message level errors   |Errors
                                      |OK            |
                                      v              |
11.Blocks to be sent?<---------2. More Blocks <-- --------------------
             |    |No       No    to process?        |               ^
          Yes|    v                   |Yes           |               |
             v   STOP                 v              |               |
      12. Generate            3. Check Block OK - -->|               |
     output message                  |               |Errors         |
          |                          |Checks OK      |               |
          v                          v               |               |
    -------------   ------  4. Type of  Block ? -----|               |
   |    Output   | |        |    |           |       |               |
   | OTP Message | |    ----     |           |       |               |
    -------------  |   |         |           |       |               |
       ------------    |         |           |       |               |
      |              --          |           |       |               |
      v             v            v           v       |               |
    Status       Action    Encapsulating  Error      |               |
   Request      Response       Block      Block      |               |
     |             |             |          |        |               |
     |             v             v          v        |               |
     |       6a. Action   7. Process 8a.Error Block---- > Transient  |
     |        Response  encapsulated     severity ?  |      Error    |
     |        received     message      |Hard Error  |     (retry)   |
     |        before ?          |  |    |            |        |      |
     |       Yes|   |No       Ok|  |         v       |      WAIT     |
     |      (Ig-|   |           |  |       STOP      |        |      |
     |      nore|)  v           |  |                 v        v      |
     |          | 6b. Process  |   ----- -> 9. Generate      8b.     |
     |          |    Action    |  Errors    Error Block    Retrieve  |
     |          |   Response---+-------- --> & store      and resend |
     |          |     Block    |  Errors          |        previous  |
     |          |       |Ok    |                  |        Block(s)  |
     |          |       v      v                  |          |       |
     |          |         6c. New                 |          |       |
     |          |         request                 |          |       |
     |          |       required ?                |          |       |
     |          |     No|    |Yes  6d. Generate   |          |       |
     |          |       |    ---- > Request       |          |       |
     |          |       |          Block & Store  v          v       |
     v          |       |              |           10. Add Block to  |
      ----------+-------+------------------------->  output message  |
                v       v                                            |
                  -------------------------------------------------->
  Figure 11 Client Role Processing Sequence

  Each of the processes in the sequence is described in more detail
  below.

4.4.2.1 Check for Transport or Message Level Error

  On receipt of an IOTP response message (step 1), first check for
  transport or message level errors (see sections 4.3.1 and 4.3.2).
  These are errors which indicate that the entire message is corrupt and
  can not reliably be associated with any particular transaction or, if
  it can be associated with a transaction, the interior information in
  the message can not be reliably accessed. Set up an error indication
  message with an Error Component indicating the error.

  If the value of the OtpTransId attribute is not recognised as
  belonging to an IOTP transaction when other Blocks in the IOTP Message
  indicate that it should be recognised, then report the error using an
  Error Component with a Severity of HardError, an ErrorCode set to
  AttValNotRecog (attribute value not recognised), and an Error Location
  element (see section 6.19.3) that points to the OtpTransId attribute.

  On failure to receive an expected response message, the time out
  strategy indicated in the documentation for the transport method being
  used should be followed. This may include some number of automatic
  retransmissions of the request. If a user is present, they may be
  offered options of continuing to retransmit the request or of
  cancelling the transaction.

4.4.2.2 Process all the blocks

  If there are no message level errors, process each of the blocks
  within the message which has not been processed (step 2).

  Once all the blocks have been processed, check to see if there are any
  blocks to be sent (step 11). There may be no blocks to send if the
  last response message received was the last message of the
  transaction.

  If blocks are to be sent then generate a request message (step 12) and
  send it to the server. It may be desirable to log the complete request
  message at the client. Failure of the server to receive a response may
  lead to a time-out and a retransmission of the request.

4.4.2.3 Check the Block is OK

  If there are no message level errors process each of the blocks within
  the message (step 2).

  Check the block is OK (see section 4.3.3). For each block level error
  found, an appropriate Error Component should be created to be included
  in an Error Component sent back to the Server.

  If one or more of the Error Components contain a Severity attribute
  with a value of TransientError or HardError, no further processing of
  the block should occur and it is likely that this will result in
  termination of the transaction.

4.4.2.4 Determine the Type of the Block

  Trading Blocks that survive the above steps and thus have no errors,
  or at worst have added a warning error component to the error
  indication message, can receive further processing. The nature of the
  processing depends (step 4) on whether the block is a Status Response,
  Action Response, an Error Block or contains an Encapsulated Message.

4.4.2.5 Status Response Blocks

  Status Response Blocks (step 4) are either:
  o  Inquiry Response Trading Blocks (see section 7.15), or
  o  Ping Response Blocks (see section 7.17)

  In general, such blocks should be considered a status update. The best
  action to take at the requester may depend on whether this is in
  response to a user originated or automatic status request, whether a
  status display that could be updated is being presented to the user,
  and whether the status response block shows a change in status from a
  previous response block for the same type of status. Thus client
  detection of duplication in successive status response blocks may be
  useful.

4.4.2.6 Action Response Blocks

  Check to determine if the Block has been received previously (step
  6a). If it has then it should be ignored.

  These indicate an action taken at the server in response to an action
  request block or a business error. If the response indicates success
  the block should be processed (step 6b) and, if required by the
  transaction (step 6c) , another Action Request Block generated and
  stored (step 6d).

  The Response Block should always be stored with the transaction id and
  until the transaction is terminated. If the Response Block indicates a
  transient business error, appropriate manually chosen or automatic
  steps to fix the problem or cancel the transaction should be provided.

4.4.2.7 Encapsulating Blocks

  Blocks which encapsulate a payment protocol (step 7) pass along the
  enclosed information to the payment system involved.

  IOTP does not know the meaning of the enclosed information. It is up
  to the payment system involved to handle error detection and
  idempotency. Payment systems adapted for the Internet include
  idempotency handling because duplicates are always possible. Should a
  payment system have no idempotency handling, a layer between IOTP and
  the payment system must be added to take care of this.

  No IOTP level idempotency actions are required for encapsulating
  blocks. The payment system must return an indication of whether an
  error occurred. In addition, for a continuing exchange, it must return
  material to be encapsulated in the next IOTP request/exchange (step
  6d). If the response was a final response for that payment exchange
  and there was an error, the payment system may optionally return
  material to be encapsulated in the error indication.

4.4.2.8 Error Block

  An error block in a response (step 8a) indicates some problem was
  detected by the server. If all of the error components are warnings,
  they may be optionally logged and/or presented to the user.

  Transient errors may be used to provide a manual or automatic
  resending (step 8b) of a block previously stored or alternatively may
  result in transaction cancellation. Hard errors will always terminate
  the transaction, unless they are in optional blocks, with appropriate
  indication to he user.

4.4.2.9 Generate Error Block

  If an error indication message was created above, try to send it to
  the server unless all of the error components are of the warning
  severity in which case attempted transmission to the server is
  optional.

  [Note]   To avoid error message loops, such an error indication from
           a requester must be sent to the Error Net Location specified
           in the Trading Role Element (see section 6.5.2) for the
           Organisation that is the server. Any errors encountered in
           sending such an error indication should be, at most, logged
           and must not result in any further attempts to transmit any
           error indication.
  [Note End]

4.4.2.10 Add Block to Output Message

  Any Blocks which have been created as a result of processing the block
  received are added to the output message.

5. Security Considerations

  This section considers the security associated with IOTP. It covers:
  o  an overview of how IOTP uses digital signatures
  o  how to check a signature is correctly calculated
  o  how Payment Handlers and Delivery Handlers check they can
     carry out payments or deliveries on behalf of a Merchant.
  o  how IOTP handles data integrity and privacy

5.1 Digital Signatures and IOTP

  In general, signatures when used with IOTP:
  o  are always treated as a IOTP Components (see section 6)
  o  hash one or more IOTP Components or Trading Blocks, possibly
     including other Signature Components, in any IOTP message
     within the same IOTP Transaction
  o  identify:
     - which Organisation signed (generated) the signature, and
     - which Organisation(s) should verify the signature in order to
       check that the Action the Organisation should take can occur.

  The way in which Signatures Components hash one or more elements is
  illustrated in the figure below.

        OTP MESSAGE                             SIGNATURE COMPONENT

OTP MESSAGE                                    OtpSignature Id = P1.3
 |-Trans Ref Block           hash TransRefBlk   |-SignedData
 |  |      ID=P1.1-------- ---------------------|->|-Hash of P1.1---
 |  |-Trans Id Comp          hash TransIdComp   |  |                |
 |  |     ID = M1.2------- ---------------------|->|-Hash of M1.2---|
 |  |-Msg Id Comp.              hash element    |  |                |
 |  |      ID = P1           -------------------|->|-Hash of M1.5---|
 |                          |     hash element  |  |                |
 |-Signature Block          |  -----------------|->|-Hash of M1.7---|
 |  |       ID=P1.2         | |    hash element |  |                |
 |  |-Sig Comp. ID=P1.3     | |  ---------------|->|-Hash of C1.4---|
 |  |-Sig Comp. ID=M1.5--- -  | |               |                   |
 |  |-Cert Comp. ID=P1.4      | | CertRef Iden-  -DigSig            |
 |  |-Cert Comp. ID=M1.6<- ---|-|---------------------CertRef=M1.6  |
 |  |                         | | tifies Certs    Content:          |
 |-Trading Block. ID=P1.5     | |    to use         JtvwpMdmSfMbhK<-
 |  |-Comp. ID=M1.7------- ---  |                   r1Ln3vovbMQttbBI
 |  |                           |                   J8pxLjoSRfe1o6k
 |  |-Comp. ID=P1.6             |                   OGG7nTFzTi+/0<--
 |  |                           |                                   |
 |  |-Comp. ID=C1.4------- -----               Digital signature of-
 |  |-Comp. ID=C1.5                            SignedData element
                                               using certificate
                                               identified by CertRef
   Elements signed can be in any OTP Message
        within the same OTP Transaction

  Figure 12 Signature Hashing

  [Note]   The classic example of one signature signing another in
           IOTP, is when an Offer is first signed by a Merchant
           creating an "Offer Response" signature, which is then later
           signed by a Payment Handler together with a record of the
           payment creating a "Payment Receipt" signature. In this way,
           the payment in an IOTP Transaction is bound to the
           Merchant's offer.
  [Note End]

  The detailed definitions of how signatures are created is contained in
  the paper "Digital Signature for XML - Proposal", see [XMLSIG]. That
  document should be read in conjunction with this section.

  The remainder of this section contains:
  o  an example of how IOTP uses signatures
  o  how the SignerOrgRef and VerifierOrgRef attributes within a
     Signature Component are used to identify the organisations
     associated with the signature
  o  how signatures may use either Symmetric or Asymmetric
     Cryptography
  o  Mandatory and Optional use of Signatures by IOTP, and
  o  how IOTP uses signatures to prove actions complete
     successfully

5.1.1 IOTP Signature Example

  An example of how signatures are used is illustrated in the figure
  below which shows how the various components and elements in a
  Baseline Purchase relate to one another. Refer to this example in the
  later description of how signatures are used to check a payment or
  delivery can occur (see section 5.3).

  [Note]   A Baseline Purchase transaction has been used for
           illustration purposes. The usage of the elements and
           attributes is the same for all types of IOTP Transactions.
  [Note End]

    TPO SELECTION BLOCK          TPO BLOCK         SIGNATURE BLOCK
                                                   (Offer Response)
 Brand Selection             Organisation<---  Signer   Signature
   Component                 Component       | OrgRef   Component
      |                       |               ----------(Offer
      |BrandList               -Trading Role            Response)
      |  Ref                     Element                  |
      v                       (Merchant)                  |
    Brand List                                            |
  >Component                                              |
 | |-Protocol       ------>  Organisation<--------------  |-Dig Sig
 | | Amount Elem   |         Component         Verifier | | Element
 | |   |           |          |                OrgRef    -|-(Payment
 | | Pa|Protocol   |Action     -Trading Role              |  Handler)
 | |   | Ref       |OrgRef       Element                  |
 | |   v           |          (Payment Handler)           |
 |  -PayProtocol--                                        |
 |    Elem                  ->Organisation<-------------  |-Dig Sig
 |                         |  Component        Verifier | | Element
 |                         |  |                OrgRef    -|-(Delivery
 |                         |   -Trading Role              |  Handler)
 |                         |     Element                  |
 |                         | (Delivery Handler)            -SignedData
 |                         |                                Element ^
 |           OFFER RESPONSE BLOCK                                   |
 |                         |                Contains hashes of:-----
 |BrandListRef             |ActionOrgRef    -Trans Ref Block (not
 |                         |                 shown)
  --Payment                 ---Delivery     -Transaction Id Component
   Component                  Component      (not shown)
                                            -Org Components (Merchant,
                                             Payment Handler,
                                             Delivery Handler
                                            -Brand List Component
                                            -Order Component
                                            -Payment Component
                                            -Delivery Component
                                            -Brand Selection Component
                                             (if Brand Dependent)

  Figure 13 Example use of Signatures for Baseline Purchase

5.1.2 SignerOrgRef and VerifierOrgRef Attributes

  The SignerOrgRef attribute on the Signature Component contains an
  Element Reference (see section 3.5) that points to the Organisation
  Component of the Organisation which generated the Signature. In this
  example its the Merchant.

  Note that the type of the Signature Component must match the Trading
  Role of the Organisation which signed it. If it does not, then it is
  an error. Valid combinations are given in the table below.

           Signature           Valid
           Component          Trading
              Type             Role

        OfferResponse    Merchant

        PaymentResponse  PaymentHandler

  The VerifierOrgRef attribute on the DigSig elements, contains Element
  References to the Organisation Components of the Organisations that
  should use the signature to verify that:
  o  they have a pre-existing relationship with the Organisation
     that generated the signature,
  o  the data which is secured by the signature has not been
     changed,
  o  the data has been signed correctly, and
  o  the action they are required to undertake on behalf of the
     Merchant is therefore authorised.

5.1.3 Symmetric and Asymmetric Cryptography

  The Signer of an Action and a Verifier of an Action may have agreed to
  use cryptography which is understood only by the two organisations
  involved. This requires that a separate Digital Signature Element for
  use by the verifier is contained within the Signature Component. This
  approach is more likely if symmetric cryptography is being used
  between the Trading Roles.

  Equally the same cryptography may be understood by several or all of
  the Trading Roles. In this case one Digital Signature Element may
  refer to multiple Verifiers of an Action. This is more likely if
  public key/asymmetric cryptography is being used.

  Note that one transaction may involve use of both symmetric and
  asymmetric cryptography.

5.1.4 Mandatory and Optional Signatures

  IOTP does not mandate the use of signatures. For example, if a micro
  payment is being made for 0.1 cents, then the cost of the cryptography
  required to generate the signature may be greater than the income
  generated from the payment. Therefore it is up to the Merchant to
  decide whether IOTP Messages will include signatures, and for the
  Consumer to decide whether carrying out a transaction without
  signatures is an acceptable risk. If Merchants discover that
  transactions without signatures are not being accepted, then they will
  start using signatures or accept a lower volume and value of business.

  Additional optional signatures, over and above the ones required by
  the Trading Roles may be included, for example, to identify a Customer
  Care Provider or so that a Merchant can sign an Offer using a
  certificate issued by a Certificate Authority which offers Merchant
  "Credentials" or some other warranty on the goods or services being
  offered.

5.1.5 Using signatures to Prove Actions Complete Successfully

  Proving an action completed successfully, is achieved by signing data
  on Response messages. Specifically:
  o  on the Offer Response, when a Merchant is making an Offer to
     the Consumer which can then be sent to either:
     - a Payment Handler to prove that payment is authorised, or
     - a Delivery Handler to prove that Delivery is authorised
  o  on the Payment Response, when a Payment Handler is generating
     a Payment Receipt which can be sent to either:
     - a Delivery Handler, in a Delivery Request Block to prove that
       delivery is authorised, or
     - another Payment Handler, in a second Payment Request, to prove
       that the second payment in a Value Exchange IOTP Transaction is
       authorised.

  This proof of an action may, in future versions of IOTP, also be used
  to prove after the event that the IOTP transaction occurred. For
  example to a Customer Care Provider.

5.2 Checking a Signature is Correctly Calculated

  Checking a signature is correctly calculated is part of checking for
  Message Level Errors (see section 4.3.2). It is included here so that
  all signature and security related considerations are kept together.

  Before a Trading Role can check a signature it must identify which of
  the potentially multiple digital signature elements should be checked.
  The steps involved are as follows:
  o  check that a Signature Block is present and it contains one or
     more Signature Components
  o  identify the Organisation Component which contains an OrgId
     attribute for the Organisation which is carrying out the
     signature check. If no or more than one Organisation Component
     is found then it is an error
  o  use the ID attribute of the Organisation Component to identify
     the Digital Signatures Elements which the Trading Role should
     verify. Note there may be no signatures for a Trading Role to
     verify.

  o  verify the Signature Components that contain the Digital
     Signature Elements as follows:
     - check that the Digital Signature Element correctly signs the
       Signed Data Element
     - check that the Hash Elements in the Signed Data Element are
       correctly calculated where Components or Blocks that are hashed
       have been received by the organisation checking the signature

5.3 Checking a Payment or Delivery can occur

  This section describes the processes required for a Payment Handler or
  Delivery Handler to check that a payment or delivery can occur. This
  may include checking signatures if this is specified by the Merchant.

  In outline the steps are:
  o  check that the Payment Request or Delivery Request has been
     sent to the correct organisation
  o  check that correct IOTP components are present in the request,
     and
  o  check that the payment or delivery is authorised

  For clarity and brevity the following terms or phrases are used in
  this section:
  o  a "Request Block" is used to refer to either a Payment Request
     Block (see section 7.6) or a Delivery Request Block (see
     section 7.9) unless specified to the contrary
  o  a "Response Block" is used to refer to either a Payment
     Response Block (see section 7.8) or a Delivery Response Block
     (see section 7.10)
  o  an "Action" is used to refer to an action which occurs on
     receipt of a Request Block. Actions can be either a Payment or
     a Delivery
  o  an "Action Organisation", is used to refer to the Payment
     Handler or Delivery Handler that carries out an Action
  o  a "Signer of an Action", is used to refer to the Organisations
     that sign data about an Action to authorise the Action, either
     in whole or in part
  o  a "Verifier of an Action", is used to refer to the
     Organisations that verify data to determine if they are
     authorised to carry out the Action
  o  an ActionOrgRef attribute contains Element References which
     can be used to identify the "Action Organisation" that should
     carry out an Action

5.3.1 Check the Action Request was sent to the Correct Organisation

  Checking the Action Request was sent to the correct Organisation
  varies depending on whether the Action is a Payment or a Delivery.

5.3.1.1 Payment

  In outline a Payment Handler checks if it can accept or make a payment
  by identifying the Payment Component in the Payment Request Block it
  has received, then using the ID of the Payment Component to track
  through the Brand List and Brand Selection Components to identify the
  Organisation selected by the Consumer and then checking that this
  organisation is itself.

  The way data is accessed to do this is illustrated in the figure
  below.

                                                  Start
                                                   |
                                                   v
Brand List<--------------------------+-----------Payment
Component         BrandListRef       |          Component
 |                                   |
 |-Brand<--------------------------  |
 | Element        BrandRef         | |
 |  |                          Brand Selection
 |  |Protocol                     Component
 |  | AmountRefs                   | |
 |  v                  Protocol    | |
 |-Protocol Amount<----------------  |
 | Element----------  AmountRef      |
 |  |               |                |
 |  |Currency       |Pay             |
 |  | AmountRefs    |Protocol        |
 |  v               |Ref             |
 |-Currency Amount  |                |
 | Element<---------|----------------
 |                  |
  -PayProtocol<-----
   Element---------------------->Organisation
                  Action         Component
                  OrgRef          |
                                   -Trading Role
                                     Element
                                  (Payment Handler)

  Figure 14 Checking a Payment Handler can carry out a Payment

  The following describes the steps involved and the checks which need
  to be made:
  1)
     Identify the Payment Component (see section 6.8) in the
     Payment Request Block that was received.
  2)
     Identify the Brand List and Brand Selection Components for the
     Payment Component. This involves:
     a)
       identifying the Brand List Component (see section 6.6)
       where the value of its ID attribute matches the
       BrandListRef attribute of the Payment Component. If no or
       more than one Brand List Component is found there is an
       error.
     b)
       identifying the Brand Selection Component (see section 6.7)
       where the value of its BrandListRef attribute matches the
       BrandListRef of the Payment Component. If no or more than
       one matching Brand Selection Component is found there is an
       error.
  3)
     Identify the Brand, Protocol Amount, Pay Protocol and Currency
     Amount elements within the Brand List that have been selected
     by the Consumer as follows:
     a)
       the Brand Element (see section 6.6.1) selected is the
       element where the value of its Id attribute matches the
       value of the BrandRef attribute in the Brand Selection. If
       no or more than one matching Brand Element is found then
       there is an error.
     b)
       the Protocol Amount Element (see section 6.6.2) selected is
       the element where the value of its Id attribute matches the
       value of the ProtocolAmountRef attribute in the Brand
       Selection Component. If no or more than one matching
       Protocol Amount Element is found there is an error
     c)
       the Pay Protocol Element (see section 6.6.4) selected is
       the element where the value of its Id attribute matches the
       value of the PayProtocolRef attribute in the identified
       Protocol Amount Element. If no or more than one matching
       Pay Protocol Element is found there is an error
     d)
       the Currency Amount Element (see section 6.6.3) selected is
       the element where the value of its Id attribute matches the
       value of the CurrencyAmountRef attribute in the Brand
       Selection Component. If no or more than one matching
       Currency Amount element is found there is an error
  4)
     Check the consistency of the references in the Brand List and
     Brand Selection Components:
     a)
       check that an Element Reference exists in the
       ProtocolAmountRefs attribute of the identified Brand
       Element that matches the Id attribute of the identified
       Protocol Amount Element. If no or more than one matching
       Element Reference can be found there is an error
     b)
       check that the CurrencyAmountRefs attribute of the
       identified Protocol Amount element contains an element
       reference that matches the Id attribute of the identified
       Currency Amount element. If no or more than one matching
       Element Reference is found there is an error.
     c)
       check the consistency of the elements in the Brand List.
       Specifically, the selected Brand, Protocol Amount, Pay
       Protocol and Currency Amount Elements are all child
       elements of the identified Brand List Component. If they
       are not there is an error.
  5)
     Check that the Payment Handler that received the Payment
     Request Block is the Payment Handler selected by the Consumer.
     This involves:
     a)
       identifying the Organisation Component for the Payment
       Handler. This is the Organisation Component where its ID
       attribute matches the ActionOrgRef attribute in the
       identified Pay Protocol Element. If no or more than one
       matching Organisation Component is found there is an error
     b)
       checking the Organisation Component has a Trading Role
       Element with a Role attribute of PaymentHandler. If not
       there is an error
     c)
       finally, if the identified Organisation Component is not
       the same as the organisation that received the Payment
       Request Block, then there is an error.

5.3.1.2 Delivery

  The way data is accessed by a Delivery Handler in order to check that
  it may carry out a delivery is illustrated in the figure below.

                         Start
                           |
                           v
                        Delivery
                        Component
                           |
                           |ActionOrgRef
                           |
                           v
                        Organisation
                        Component
                        |
                         -Trading Role
                           Element
                        (Delivery Handler)

  Figure 15 Checking a Delivery Handler can carry out a Delivery

  The steps involved are as follows:
  1.
    Identify the Delivery Component in the Delivery Request Block.
    If there is no or more than one matching Delivery Component
    there is an error
  2.
    Use the ActionOrgRef attribute of the Delivery Component to
    identify the Organisation Component of the Delivery Handler.
    If there is no or more than one matching Organisation
    Component there is an error
  3.
    If the Organisation Component for the Delivery Handler does
    not have a Trading Role Element with a Role attribute of
    DeliveryHandler there is an error
  4.
    Finally, if the organisation that received the Delivery
    Request Block does not identify the Organisation Component for
    the Delivery Handler as itself, then there is an error.

5.3.2 Check the Correct Components are present in the Request Block

  Check that the correct components are present in the Payment Request
  Block (see section 7.6) or in the Delivery Request Block (see section
  7.9).

  If components are missing, there is an error.

5.3.3 Check an Action is Authorised

  The previous steps identified the Action Organisation and that all the
  necessary components are present. This step checks that the Action
  Organisation is authorised to carry out the Action.

  In outline the Action Organisation identifies the Merchant, checks
  that it has a pre-existing agreement which allows it carry out the
  Action and that any constraints implied by that agreement are being
  followed, then, if signatures are required, it checks that they sign
  the correct data.

  The steps involved are as follows:
  1.
    Identify the Merchant. This is the Organisation Component with
    a Trading Role Element which has a Role attribute with a value
    of Merchant. If no or more than one Trading Role Element is
    found, there is an error
  2.
    Check the Action Organisation's agreements with the Merchant
    allows the Action to be carried out. To do this the Action
    Organisation must check that:
    a) the Merchant is known and a pre-existing agreement exists
       for the Action Organisation to be their agent for the
       payment or delivery
    b) they are allowed to take part in the type of IOTP
       transaction that is occurring. For example a Payment
       Handler may have agreed to accept payments as part of a
       Baseline Purchase, but not make payments as part of a
       Baseline Refund
    c) any constraints in their agreement with the Merchant are
       being followed, for example, whether or not an Offer
       Response signature is required
   3.
     Check the signatures are correct. If signatures are required
     then they need to be checked. This involves:
    a) Identifying the correct signatures to check. This involves
       the Action Organisation identifying the Signature
       Components where the VerifierOrgRef attribute of the
       Digital Signature element points to the Action
       Organisation's Organisation Component. Depending on the
       IOTP Transaction being carried out (see section 8) either
       one or two signatures may be identified
    b) checking that the Signature Components are correct. This
       involves checking that the necessary Trading Components
       have been hashed (see section 5.3.3.1).

  [Note]   Validation that the signature is correct and that the Hash
           elements within the signature are correctly calculated is
           described in section 4 IOTP Error Handling. This is because
           errors in the signature or calculation of hashes is
           considered a Message Level Error and is carried out before
           the Request Block is processed.
  [Note End]

5.3.3.1 Check the Signatures Sign Correct Data

  All Signature Components contained within IOTP Messages must always
  hash:
  o  the Transaction Id Component (see section 3.3.1) of the IOTP
     message that contains the Signature Component. This binds the
     globally unique OtpTransId to other components which make up
     the IOTP Transaction
  o  the Transaction Reference Block (see section 3.3) of the first
     IOTP Message that contained the signature. This binds the
     OtpTransId with information about the IOTP Message contained
     inside the Message Id Component (see section 3.3.2).

  Checking that each signature signs the correct data, involves checking
  that hashes of the necessary components are present in the SignedData
  element of the Signature Component.

  The hashes that need to be present depend on the Trading Role of the
  Organisation which generated (signed) the signature:
  o  if the signer of the signature is a Merchant then:
     - hashes must be present for all the components in the Request
       Block apart from the Brand Selection Component which is optional
  o  if the signer of the signature is a Payment Handler then
     hashes should be present for:
     - the Signature Component signed by the Merchant, and optionally
     - one or more Signature Components signed by the Payment
       Handler(s) identified by the appropriate ActionSignerRefs
       attribute.

5.4 Data Integrity and Privacy

  The overall integrity of data in IOTP Messages is ensured by the
  signing of hashes of Components and Trading Blocks contained in a
  Signature Component (see section 6.18) in a Signature Block (see
  section 7.18).

  Privacy of information is provided by sending IOTP Messages between
  the various Trading Roles using a secure channel such as [SSL]. Use of
  a secure channel within IOTP is optional.

6. Trading Components

  This section describes the Trading Components used within IOTP.
  Trading Components are the child XML elements which occur immediately
  below a Trading Block as illustrated in the diagram below.

          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  |-Trading Block <-------- Trading Block - an XML Element
Components |  |-Component            within an OTP Message that
|    |     |  |-Component            contains a predefined set of
|     ---> |  |-Component            Trading Components
|          |  |-Component
|          |  |-Component <--------- Trading Components - XML
|          |                         Elements within a Trading Block
|          |-Trading Block           that contain a predefined set of
 --------> |  |-Component            XML elements and attributes
           |  |-Component            containing information required
           |  |-Component            to support a Trading Exchange
           |  |-Component
           |  |-Component
           |
           |

  Figure 16 Trading Components
  The Trading Components described in this section are listed below in
  approximately the sequence they are likely to be used:
  o  Protocol Options Component
  o  Authentication Data Component
  o  Authentication Response Component
  o  Order Component
  o  Organisation Component
  o  Brand List Component
  o  Brand Selection Component
  o  Payment Component
  o  Payment Scheme Component
  o  Payment Receipt Component
  o  Delivery Component
  o  Delivery Note Component
  o  Signature Component
  o  Certificate Component
  o  Error Component

  Note that the following components are listed in other sections of
  this specification:
  o  Transaction Id Component (see section 3.3.1)
  o  Message Id Component (see section 3.3.2)

6.1 Protocol Options Component

  Protocol options are options which apply to the IOTP Transaction as a
  whole. Essentially it provides a short description of the entire
  transaction and the net location which the Consumer role should branch
  to if the IOTP Transaction is successful.

  The definition of a Protocol Options Component is as follows.

<!ELEMENT ProtocolOptions EMPTY>
<!ATTLIST ProtocolOptions
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  ShortDesc      CDATA   #REQUIRED
  SenderNetLocn  CDATA   #REQUIRED
  SecureSenderNetLocn CDATA   #REQUIRED
  SuccessNetLocn CDATA   #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Protocol Options Component within the IOTP
                   Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

ShortDesc          This contains a short description of the IOTP
                   Transaction in the language defined by xml:lang.
                   Its purpose is to provide an explanation of what
                   type of IOTP Transaction is being conducted by the
                   parties involved.

                   It is used to facilitate selecting an individual
                   transaction from a list of similar transactions ,
                   for example from a database of IOTP transactions
                   which has been stored by a Consumer, Merchant,
                   etc.

SenderNetLocn      This contains the non secured net location of the
                   sender of the TPO Block in which the Protocol
                   Options Component is contained.

                   It is the net location to which the  recipient of
                   the TPO block should send a TPO Selection Block if
                   required.

                   The content of this attribute is dependent on the
                   Transport Mechanism see the Transport Mechanism
                   Supplement.

SecureSenderNetLo  This contains the secured net location of the
cn                 sender of the TPO Block in which the Protocol
                   Options Component is contained.

                   The content of this attribute is dependent on the
                   Transport Mechanism see the Transport Mechanism
                   Supplement.

SuccessNetLocn     This contains the net location that the should be
                   displayed after the IOTP Transaction has
                   successfully completed.

                   The content of this attribute is dependent on the
                   Transport Mechanism see the Transport Mechanism
                   Supplement.

6.2 Authentication Data Component

  This Trading Component contains data about how an Authentication
  within the IOTP Transaction will occur. Its definition is as follows.

<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
  ID ID          #REQUIRED
  AuthenticationId       CDATA   #REQUIRED
  AuthMethod     NMTOKEN #REQUIRED
  TradingRoleListNMTOKENS #IMPLIED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Authentication Data Component within the IOTP
                   Transaction.

AuthenticationId   An identifier specified by the Authenticator
                   which, if returned by the Organisation that
                   receives the Authentication Request, will enable
                   the Authenticator to identify which Authentication
                   is being referred to.

AuthMethod         This identifies the content of the Authentication
                   Data Component. Valid values are:
                   o  sha1 This indicates that the recipient of the
                      Authentication Data Component should generate a
                      hash. See 6.3 Authentication Response Component.
                   o  signature This indicates the recipient of the
                      Authentication Data Component should generate a
                      digital signature to include in the
                      Authentication Response
                   o  pay:ppp A payment protocol specific
                      authentication method. The "ppp" identifies a
                      payment protocol associated with a payment
                      exchange which is part of the IOTP Transaction.
                      In this case the content and format of the
                      AuthData element is defined in the appropriate
                      Payment Scheme supplement. For example if a
                      payment method "xzpay" provided an
                      authentication method, then this attribute would
                      have the value "pay:xzpay"
                   o  x-ddd:nnn a user defined authentication scheme
                      type see section (3.7.3 User Defined Codes).

TradingRoleList    If present, contains a list of the Trading Roles
                   (see the TradingRole attribute of the Trading Role
                   Element - section 6.5.2) for which the
                   Authenticator is requesting the Authenticatee
                   provides Organisation Components in the
                   Authentication Response.

                   For example a Merchant could request that a
                   Consumer provides Organisation Components for the
                   Consumer and DelivTo Trading Roles.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    This contains the challenge data as Packaged
                   Content (see section 3.8) that is to be responded
                   to using the method indicated by AuthMethod.

6.3 Authentication Response Component

  This Authentication Response Component contains the results of an
  authentication. Its definition is as follows.

<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
  ID ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                  An identifier which uniquely identifies the
                    Authentication Response Component within the IOTP
                    Transaction.

ContentSoftwareId   This contains information which identifies the
                    software which generated the content of the
                    element. Its purpose is to help resolve
                    interoperability problems that might occur as a
                    result of incompatibilities between messages
                    produced by different software. It is a single
                    text string in the language defined by xml:lang.
                    It must contain, as a minimum:
                    o the name of the software manufacturer
                    o the name of the software
                    o the version of the software, and
                    o the build of the software

                    It is recommended that this attribute is included
                    if the software which generated the content cannot
                    be identified from the SoftwareId attribute on the
                    Message Id Component (see section 3.3.2)

  Content:

PackagedContent     This contains the response to the content of the
                    Authentication Data Component see section 6.2 as
                    Packaged Content (see section 3.8).

                    For a payment specific scheme, it may contain
                    scheme-specific data. Refer to the scheme-specific
                    supplemental documentation.

6.4 Order Component

  An Order Component contains information about an order. Its definition
  is as follows.

<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  OrderIdentifierCDATA   #REQUIRED
  ShortDesc      CDATA   #REQUIRED
  OkFrom         CDATA   #REQUIRED
  OkTo           CDATA   #REQUIRED
  ApplicableLaw  CDATA   #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the Order
                   Component within the IOTP Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

OrderIdentifier    This is a code, reference number or other
                   identifier which the creator of the Order may use
                   to identify the order. It must be unique within an
                   IOTP Transaction. If it is used in this way, then
                   it may remove the need to specify any content for
                   the Order element as the reference can be used to
                   look up the necessary information in a database.

ShortDesc          A short description of the order in the language
                   defined by xml:lang. It is used to facilitate
                   selecting an individual order from a list of
                   orders, for example from a database of orders
                   which has been stored by a Consumer, Merchant,
                   etc.

OkFrom             The date and time in [UTC] format after which the
                   offer made by the Merchant lapses.

OkTo               The date and time in [UTC] format before which a
                   Value Acquirer may accept the offer made by the
                   Merchant is not valid.

ApplicableLaw      A phrase in the language defined by xml:lang which
                   describes the state or country of jurisdiction
                   which will apply in resolving problems or
                   disputes.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    An optional description of the order information
                   as Packaged Content (see section 3.8).

6.4.1 Order Description Content

  The Packaged Content element will normally be required, however it may
  be omitted where sufficient information about the purchase can be
  provided in the ShortDesc attribute

  Although the amount and currency are likely to appear in the Packaged
  Content of the Order Description it is the amount and currency
  contained in the payment related trading components (Brand List, Brand
  Selection and Payment) that is authoritative. This means it is
  important that the amount actually being paid (as contained in the
  payment related trading components) is prominently displayed to the
  Consumer.

  For interoperability, implementations must support Plain Text as a
  minimum so that it can be easily displayed.

6.4.2 OkFrom and OkTo Timestamps

  Note that:
  o  the OkFrom date may be later than the OkFrom date on the
     Payment Component (see section 6.8) associated with this
     order, and
  o  similarly, the OkTo date may be earlier that the OkTo date on
     the Payment Component (see section 6.8).

  [Note]   Disclaimer. The following information provided in this note
           does not represent formal advice of the Open Trading
           Protocol Consortium, any of its members or the authors of
           this specification. Readers of this specification must form
           their own views and seek their own legal counsel on the
           usefulness and applicability of this information.

           The merchant in the context of Internet commerce with
           anonymous consumers initially frames the terms of the offer
           on the web page, and in order to obtain the good or service,
           the consumer must accept them.

           If there is to be a time-limited offer, it recommended that
           merchants communicate this to the consumer and state in the
           order description in a manner which is clear to the consumer
           that:

           -   the offer is time limited

           -   the OkFrom and OkTo timestamps specify the validity of
           the offer

           -   the clock, e.g. the merchant's clock, that will be used
           to determine the validity of the offer
  [Note End]

6.5 Organisation Component

  The Organisation Component provides information about an individual or
  an organisation. This can be used for a variety of purposes. For
  example:
  o  to describe the merchant who is selling the goods,
  o  to identify who made a purchase,
  o  to identify who will take delivery of goods,
  o  to provide a customer care contact,
  o  to describe who will be the Payment Handler.

  Note that the Organisation Components which must be present in an OTP
  Message are dependent on the particular transaction being carried out.
  Refer to section 8. Open Trading Protocol Transactions, for more
  details.

  Its definition is as follows.

<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?,
     PostalAddress?)>
<!ATTLIST Org
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  OrgId          CDATA   #REQUIRED
  OtpMsgIdPrefix NMTOKEN #REQUIRED
  LegalName      CDATA   #IMPLIED
  ShortDesc      CDATA   #IMPLIED
  LogoNetLocn    CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Organisation Component within the IOTP
                   Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

OrgId              A code which identifies the organisation described
                   by the Organisation Component. See 6.5.1.1
                   Organisation IDs, below.

OtpMsgIdPrefix     Contains the prefix which must be used for all
                   IOTP Messages sent by the Organisation in this
                   IOTP Transaction. The values to be used are
                   defined in 3.4.1 IOTP Message ID Attribute
                   Definition.

LegalName          For organisations which are companies this is
                   their legal name in the language defined by
                   xml:lang. It is required for Organisations who
                   have a Trading Role other than Consumer or
                   DeliverTo.

ShortDesc          A short description of the organisation in the
                   language defined by xml:lang. It is typically the
                   name by which the organisation is commonly known.
                   For example, if the legal name was "Blue Meadows
                   Financial Services Inc.". Then its short name
                   would likely be "Blue Meadows".

                   It is used to facilitate selecting an individual
                   organisation from a list of organisations, for
                   example from a database of organisations involved
                   in IOTP Transactions which has been stored by a
                   consumer.

LogoNetLocn        The net location which can be used to download the
                   logo for the organisation.

                   See section 9 Retrieving Logos.

                   The content of this attribute must conform to
                   [RFC1738].

  Content:

TradingRole        See 6.5.2 Trading Role Element below.

ContactInfo        See 6.5.3 Contact Information Element below.

PersonName         See 6.5.4 Person Name below.

PostalAddress      See 6.5.5 Postal Address below.

6.5.1.1 Organisation IDs

  Organisation IDs are used by one IOTP Trading Role to identify
  another. In order to avoid confusion, this means that these IDs must
  be globally unique.

  In principle this is achieved in the following way:
  o  the Organisation Id for all trading roles, apart from the
     Consumer Trading Role, uses a domain name as their globally
     unique identifier,
  o  the Organisation Id for a Consumer Trading Role is allocated
     by one of the other Trading Roles in an IOTP Transaction and
     is made unique by concatenating it with that other roles'
     Organisation Id,
  o  once a Consumer is allocated an Organisation Id within an IOTP
     Transaction the same Organisation Id is used by all the other
     trading roles in that IOTP transaction to identify that
     Consumer.

  Specifically, the content of the Organisation ID is defined as
  follows:

OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName

ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/"
                                    NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"

ConsumerOrgId      If the Organisation ID  for a Consumer consists
                   of:
                   o  a standard prefix is to identify that the
                      Organisation Id is for a consumer, followed by
                   o  one or more characters which conform to the
                      definition of an XML "namechar". See [XML]
                      specifications, followed by
                   o  the NonConsumerOrgId for the Organisation which
                      allocated the ConsumerOrgId. It is normally the
                      Merchant role.

                   Use of upper and lower case is significant.

NonConsumerOrgId   If the Role is not Consumer then this contains the
                   Canonical Name for the non-consumer organisation
                   being described by the Organisation Component. See
                   [DNS].

                   Note that a NonConsumerOrgId may not start with
                   the ConsumerOrgIdPrefix.

                   Use of upper and lower case is not significant.

  Examples of Organisation Ids follow:
  o  newjerseybooks.com - a merchant organisation id
  o  westernbank.co.uk - a payment handler organisation id
  o  consumer:1000247ABH/newjerseybooks.com - a consumer
     organisation id allocated by a merchant

6.5.2 Trading Role Element

  This identifies the Trading Role of an individual or organisation in
  the IOTP Transaction. Note, an organisation may have more than one
  Trading Role and several roles may be present in one organisation
  element. Its definition is as follows:

<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
  TradingRole    NMTOKEN #REQUIRED
  ErrorNetLocn   CDATA   #IMPLIED >

  Attributes:

TradingRole        The trading role of the organisation. Valid values
                   are:
                   o  Consumer. The person or organisation that is
                      acting in the role of a consumer in the IOTP
                      Transaction.
                   o  Merchant. The person or organisation that is
                      acting in the role of merchant in the IOTP
                      Transaction.
                   o  PaymentHandler. The financial institution or
                      other organisation which is a Payment Handler
                      for the IOTP Transaction
                   o  DeliveryHandler. The person or organisation
                      that is the delivering the goods or services for
                      the IOTP Transaction
                   o  DelivTo. The person or organisation that is
                      receiving the delivery of goods or services in
                      the IOTP Transaction
                   o  CustCare. The organisation and/or individual
                      who will provide customer care for an IOTP
                      Transaction.
                   o  x-ddd:nnn a user defined role (see section
                      3.7.3 User Defined Codes).

ErrorNetLocn       The net location to which IOTP messages containing
                   Error Components with a Severity of either
                   HardError or TransientError are sent. See section
                   6.19.1 Error Processing Guidelines for more
                   details.

                   This attribute must be set when TradingRole is set
                   to Merchant, PaymentHandler or DeliveryHandler.

                   The content of this attribute is dependent on the
                   Transport Mechanism see the Transport Mechanism
                   Supplement.

CancelNetLocn      This contains the net location that should be
                   displayed by the Consumer after the Consumer has
                   received an Error Block containing an Error
                   Component with the Severity attribute set to
                   either:
                   o  HardError,
                   o  Warning but the Consumer decides to not
                      continue with the transaction
                   o  TransientError and the transaction has
                      subsequently timed out.

                   See section 6.19.1 Error Processing Guidelines for
                   more details.

                   This attribute must be set when TradingRole is set
                   to Merchant, PaymentHandler or DeliveryHandler.

                   The content of this attribute is dependent on the
                   Transport Mechanism see the Transport Mechanism
                   Supplement.

6.5.3 Contact Information Element

  This contains information which can be used to contact an organisation
  or an individual. All attributes are optional however at least one
  item of contact information should be present. Its definition is as
  follows.

<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
  xml:lang       NMTOKEN #IMPLIED
  Tel                    CDATA   #IMPLIED
  Fax            CDATA   #IMPLIED
  Email          CDATA   #IMPLIED
  NetLocn        CDATA   #IMPLIED >

  Attributes:

xml:lang           Defines the language used by attributes within
                   this element. See section 3.9 Identifying
                   Languages.

Tel                A telephone number by which the organisation may
                   be contacted. Note that this is a text field and
                   no validation is carried out on it.

Fax                A fax number by which the organisation may be
                   contacted. Note that this is a text field and no
                   validation is carried out on it.

Email              An email address by which the organisation may be
                   contacted. Note that this field should conform to
                   the conventions for address specifications
                   contained in [RFC822].

NetLocn            A location on the Internet by which information
                   about the organisation may be obtained that can be
                   displayed using a web browser.

                   The content of this attribute must conform to
                   [RFC1738].

6.5.4 Person Name Element

  This contains the name of an individual person. All fields are
  optional however as a minimum either the GivenName or the FamilyName
  should be present. Its definition is as follows.

<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
  xml:lang       NMTOKEN #IMPLIED
  Title          CDATA   #IMPLIED
  GivenName      CDATA   #IMPLIED
  Initials       CDATA   #IMPLIED
  FamilyName     CDATA   #IMPLIED >

  Attributes:

xml:lang           Defines the language used by attributes within
                   this element. See section 3.9 Identifying
                   Languages.

Title              A distinctive name; personal appellation,
                   hereditary or not, denoting or implying office
                   (e.g. judge, mayor) or nobility (e.g. duke,
                   duchess, earl), or used in addressing or referring
                   to a person (e.g. Mr, Mrs, Miss)

GivenName          The primary or main name by which a person is
                   known amongst and identified by their family,
                   friends and acquaintances. Otherwise known as
                   first name or Christian Name.

Initials           The first letter of the secondary names (other
                   than the Given Name) by which a person is known
                   amongst or identified by their family, friends and
                   acquaintances.

FamilyName         The name by which family of related individuals
                   are known. It is typically the part of an
                   individual's name which is passed on by parents to
                   their children.

6.5.5 Postal Address Element

  This contains an address which can be used, for example, for the
  physical delivery of goods, services or letters. Its definition is as
  follows.

<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
  xml:lang       NMTOKEN #IMPLIED
  AddressLine1   CDATA   #IMPLIED
  AddressLine2   CDATA   #IMPLIED
  CityOrTown     CDATA   #IMPLIED
  StateOrRegion  CDATA   #IMPLIED
  PostalCode     CDATA   #IMPLIED
  Country        CDATA   #IMPLIED
  LegalLocation  (True|False) 'False' >

  Attributes:

xml:lang           Defines the language used by attributes within
                   this element. See section 3.9 Identifying
                   Languages.

AddressLine1       The first line of a postal address. e.g. "The
                   Meadows"

AddressLine2       The second line of a postal address. e.g. "Sandy
                   Lane"

CityOrTown         The city of town of the address. e.g. "Carpham"

StateOrRegion      The state or region within a country where the
                   city or town is placed. e.g. "Surrey"

Country            The country for the address. e.g. "UK"

LegalLocation      This identifies whether the address is the
                   Registered Address for the Organisation. At least
                   one address for the Organisation must have a value
                   set to True unless the Trading Role is either
                   Consumer or DeliverTo.

6.6 Brand List Component

  Brand List Components are contained within the Trading Protocol
  Options Block (see section 7.1) of the IOTP Transaction. They contains
  lists of:
  o  payment Brands (see also section 3.6 Brands and Brand
     Selection),
  o  amounts to be paid in the currencies that are accepted or
     offered by the Merchant,
  o  the payment protocols which can be used to make payments with
     a Brand,  and
  o  the net locations of the Payment Handlers which accept payment
     for a payment protocol

  The definition of a Brand List Component is as follows.

<!ELEMENT BrandList (Brand+, ProtocolAmount+,
        CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
  ID             ID      #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  ShortDesc      CDATA   #REQUIRED
  PayDirection (Debit | Credit ) #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the Brand
                   List Component within the IOTP Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

ShortDesc          A text description in the language defined by
                   xml:Lang giving details of the purpose of the
                   Brand List.  This information must be displayed to
                   the receiver of the Brand List in order to assist
                   with making the selection. It is of particular
                   benefit in allowing a Consumer to distinguish the
                   purpose of a Brand List when an IOTP Transaction
                   involves more than one payment.

PayDirection       Indicates the direction in which the payment for
                   which a Brand is being selected is to be made. Its
                   values may be:
                   o  Debit The sender of the Payment Request Block
                      (e.g. the Consumer) to which this Brand List
                      relates will make the payment to the Payment
                      Handler, or
                   o  Credit The sender of the Payment Request Block
                      to which this Brand List relates will receive a
                      payment from the Payment Handler.

  Content:

Brand              This describes a Brand. The sequence of the Brand
                   elements (see section 6.6.1) within the Brand List
                   does not indicate any preference. It is
                   recommended that software which processes this
                   Brand List presents Brands in a sequence which the
                   receiver of the Brand List prefers.

ProtocolAmount     This links a particular Brand to:
                   o  the currencies and amounts in CurrencyAmount
                      elements that can be used with the Brand, and
                   o  the Payment Protocols and Payment Handlers,
                      which can be used with those currencies and
                      amounts, and a particular Brand

CurrencyAmount     This contains a currency code and an amount.

PayProtocol        This contains information about a Payment Protocol
                   and the Payment Handler which may be used with a
                   particular Brand.

  The relationships between the elements which make up the content of
  the Brand List is illustrated in the diagram below.

                  Brand List
                  Component
                   |
                   |-Brand
                   | Element
                   |  |
                   |  |Protocol
                   |  | AmountRefs
                   |  v
                   |-Protocol Amount
                   | Element----------
                   |  |               |
                   |  |Currency       |Pay
                   |  | AmountRefs    |Protocol
                   |  v               |Ref
                   |-Currency Amount  |
                   | Element          |
                   |                  |
                    -PayProtocol<-----
                     Element

  Figure 17 Brand List Element Relationships

  Examples of complete Brand Lists are contained in section 10 Brand
  List Examples.

6.6.1 Brand Element

  A Brand Element describes a brand that can be used for making a
  payment. One or more of these elements is carried in each Brand List
  Component that has the PayDirection attribute set to Debit.  Exactly
  one Brand Element may be carried in a Brand List Component that has
  the PayDirection attribute set to Credit.

<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
  Id ID          #REQUIRED
  xml:lang       NMTOKEN #IMPLIED
  BrandId        NMTOKEN #REQUIRED
  BrandName      CDATA   #REQUIRED
  BrandLogoNetLocn       CDATA   #REQUIRED
  BrandNarrative CDATA   #IMPLIED
  ProtocolAmountRefs     IDREFS  #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

Id                  Element identifier, potentially referenced in a
                    Brand Selection Component contained in a later
                    Payment Request message and uniquely identifies
                    the Brand element within the IOTP Transaction.

xml:lang            Defines the language used by attributes and
                    content of this element. See section 3.9
                    Identifying Languages.

BrandId             This contains a unique identifier for the brand or
                    promotional brand. It is used to match against a
                    list of Payment Instruments which the Consumer
                    holds to determine whether or not the Consumer can
                    pay with the Brand.

                    The syntax for a BrandId is as follows:

                    BrandId ::= UserDefinedCode |
                                   BrandIdDomain ":" BrandValue

                    Currently the only valid value for the
                    BrandIdDomain is IOTP which indicates that the
                    BrandValue is registered with IOTP.

                    The valid values for BrandValue for brands defined
                    within the IOTP Brand domain are obtainable from
                    the IOTP web site http:www.IOTP.org.

                    A user defined code follows the conventions
                    defined in section 3.7.3. Uniqueness of a user
                    defined BrandId is not guaranteed.

BrandName           This contains the name of the brand, for example
                    MasterCard Credit. This is the description of the
                    Brand which is displayed to the consumer in the
                    Consumers language defined by xml:lang. For
                    example it might be "American Airlines Advantage
                    Visa". Note that this attribute is not used for
                    matching against the payment instruments held by
                    the Consumer.

BrandLogoNetLocn    The net location which can be used to download the
                    logo for the organisation. See section Retrieving
                    Logos (see section 9).

                    The content of this attribute must conform to
                    [RFC1738].

BrandNarrative      This optional attribute is designed to be used by
                    the Merchant to indicate some special conditions
                    or benefit which would apply if the Consumer
                    selected that brand. For example "5% discount",
                    "free shipping and handling", "free breakage
                    insurance for 1 year", "double air miles apply",
                    etc.

ProtocolAmountRefs  Identifies the protocols and related currencies
                    and amounts which can be used with this Brand.
                    Specified as a list of ID's of Protocol Amount
                    Elements (see section 6.6.2) contained within the
                    Brand List.

ContentSoftwareId   This optional attribute contains information which
                    identifies the software which generated the
                    content of the element. Its purpose is to help
                    resolve interoperability problems that might occur
                    as a result of incompatibilities between messages
                    produced by different software. It is a single
                    text string in the language defined by xml:lang.
                    It must contain, as a minimum:
                    o  the name of the software manufacturer
                    o  the name of the software
                    o  the version of the software, and
                    o  the build of the software

                    It is recommended that this attribute is included
                    if the software which generated the content cannot
                    be identified from the SoftwareId attribute on the
                    Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Optional Packaged Content (see section 3.8)
                   containing information about the brand which may
                   be used by the payment protocol. The content of
                   this information is defined in the supplement for
                   a payment protocol which describes how the payment
                   protocol works with IOTP.

  Examples Brand Elements are contained in section  10 Brand List
  Examples.

6.6.2 Protocol Amount Element

  The Protocol Amount element links a Brand to:
  o  the currencies and amounts in Currency Amount Elements (see
     section 6.6.3) that can be used with the Brand, and
  o  the Payment Protocols and Payment Handlers defined in a Pay
     Protocol Element (see section 6.6.4), which can be used with
     those currencies and amounts.

  Its definition is as follows:

<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
  Id ID          #REQUIRED
  PayProtocolRef IDREF   #REQUIRED
  CurrencyAmountRefs     IDREFS  #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

Id                  Element identifier, potentially referenced in a
                    Brand element; or in a Brand Selection Component
                    contained in a later Payment Request message which
                    uniquely identifies the Protocol Amount element
                    within the IOTP Transaction.

PayProtocolRef      Contains an Element Reference (see section 3.5)
                    that refers to the Pay Protocol Element (see
                    section 6.6.4) that contains the Payment Protocol
                    and Payment Handlers that can be used with the
                    Brand.

CurrencyamountRefs  Contains a list of  Element References (see
                    section 3.5) that refer to the Currency Amount
                    Element (see section 6.6.3) that describes the
                    currencies and amounts that can be used with the
                    Brand.

ContentSoftwareId   This contains information which identifies the
                    software which generated the content of the
                    element. Its purpose is to help resolve
                    interoperability problems that might occur as a
                    result of incompatibilities between messages
                    produced by different software. It is a single
                    text string in the language defined by xml:lang.
                    It must contain, as a minimum:
                    o  the name of the software manufacturer
                    o  the name of the software
                    o  the version of the software, and
                    o  the build of the software

                    It is recommended that this attribute is included
                    if the software which generated the content cannot
                    be identified from the SoftwareId attribute on the
                    Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Optional Packaged Content (see section 3.8)
                   containing information about the protocol amount
                   which may be used by the payment protocol. The
                   content of this information is defined in the
                   supplement for a payment protocol which describes
                   how the payment protocol works with IOTP.

  Examples Protocol Amount Elements are contained in10 Brand List
  Examples.

6.6.3 Currency Amount Element

  A Currency Amount element contains:
  o  a currency code (and its type), and
  o  an amount.

  One or more of these elements is carried in each Brand List Component.
  Its definition is as follows:

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
  Id ID          #REQUIRED
  Amount         CDATA   #REQUIRED
  CurrCodeType   NMTOKEN 'ISO4217'
  CurrCode       CDATA   #REQUIRED >

  Attributes:

Id                 Element identifier, potentially referenced in a
                   Brand element; or in a Brand Selection Component
                   contained in a later Payment Request message which
                   uniquely identifies the Currency Amount Element
                   within the IOTP Transaction.

Amount             Indicates the amount to be paid in whole and
                   fractional units of the currency. For example
                   $245.35 would be expressed "245.35". Note that
                   values smaller than the smallest denomination are
                   allowed. For example one tenth of a cent would be
                   "0.001".

CurrCodeType       Indicates the domain of the CurrCode. This
                   attribute is included so that the currency code
                   may support non-standard "currencies" such as
                   frequent flyer points, trading stamps, etc. Its
                   values may be:

                   o  ISO4217 indicates the currency code conforms to
                      [ISO 4217]
                   o  x-ddd:nnn a user defined currency code type
                      (see section 3.7.3 User Defined Codes).

CurrCode           A code which identifies the currency to be used in
                   the payment. The domain of valid currency codes is
                   defined by CurrCodeType

  Note that Amount, CurrCodeType and CurrCode have identical meanings to
  the attributes of the same name on the Payment Component (see section
  6.8).

  Examples Currency Amount Elements are contained in 10 Brand List
  Examples.

6.6.4 Pay Protocol Element

  A Pay Protocol element specifies details of a Payment Protocol and the
  Payment Handler that can be used with a Brand. One or more of these
  elements is carried in each Brand List.

<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
  Id ID          #REQUIRED
  xml:lang       NMTOKEN #IMPLIED
  ProtocolId     NMTOKEN #REQUIRED
  ProtocolName   CDATA   #REQUIRED
  ActionOrgRef   NMTOKEN #REQUIRED
  PayReqNetLocn  CDATA   #IMPLIED
  SecPayReqNetLocn       CDATA   #IMPLIED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

Id                 Element identifier, potentially referenced in a
                   Brand element; or in a Brand Selection Component
                   contained in a later Payment Request message which
                   uniquely identifies the Pay Protocol element
                   within the IOTP Transaction.

xml:lang           Defines the language used by attributes and
                   content of this element. See section 3.9
                   Identifying Languages.

ProtocolId         Consists of a protocol name and version. For
                   example "SETv1.0".

                   The value used for the ProtocolId is defined in
                   the payment supplement for the payment method.

ProtocolName       A narrative description of the payment protocol
                   and its version in the language identified by
                   xml:lang. For example "Secure Electronic
                   Transaction Version 1.0". Its purpose is to help
                   provide information on the payment protocol being
                   used if problems arise.

ActionOrgRef       An Element Reference (see section 3.5) to the
                   Organisation Component for the Payment Handler for
                   the Payment Protocol.

PayReqNetLocn      The Net Location indicating where an unsecured
                   Payment Request message should be sent if this
                   protocol choice is used.

                   The content of this attribute is dependent on the
                   Transport Mechanism (such must conform to
                   [RFC1738].

SecPayReqNetLocn   The Net Location indicating where a secured
                   Payment Request message should be sent if this
                   protocol choice is used.

                   A secured payment involves the use of a secure
                   channel such as [SSL] in order to communicate with
                   the Payment Handler.

                   The content of this attribute must conform to
                   [RFC1738]. See also See section 3.10 Secure and
                   Insecure Net Locations.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Optional Packaged Content information (see section
                   3.8) about the protocol which is used by the
                   payment protocol. The content of this information
                   is defined in the supplement for a payment
                   protocol which describes how the payment protocol
                   works with IOTP. An example of its use could be to
                   include a payment protocol message.

  Examples Pay Protocol Elements are contained in section 6.6 Brand List
  Component.

6.7 Brand Selection Component

  A Brand Selection Component identifies the choice of payment brand,
  payment protocol and the Payment Handler.  This element is used:
  o  in Payment Request messages within Baseline Purchase and
     Baseline Value IOTP Transactions to identify the brand,
     protocol and payment handler for a payment, or
  o  to, optionally, inform a merchant in a purchase of the payment
     brand being used so that the offer and order details can be
     amended accordingly.

  In Baseline IOTP, the integrity of Brand Selection Components is not
  guaranteed.  However, modification of Brand Selection Components can
  only cause denial of service if the payment protocol itself is secure
  against message modification, duplication, and swapping attacks.

  The definition of a Brand Selection Component is as follows.

<!ELEMENT BrandSelection (BrandSelBrandInfo?,
        BrandSelProtocolAmountInfo?,
     BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
  ID             ID      #REQUIRED
  BrandListRef   NMTOKEN #REQUIRED
  BrandRef       NMTOKEN #REQUIRED
  ProtocolAmountRef      NMTOKEN #REQUIRED
  CurrencyAmountRef      NMTOKEN #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the Brand
                   Selection Component within the IOTP Transaction.

BrandListRef       The Element Reference (see section 3.5) of the
                   Brand List Component from which a Brand is being
                   selected

BrandRef           The Element Reference of a Brand element within
                   the Brand List Component that is being selected
                   that is to be used in the payment.

ProtocolAmountRef  The Element Reference of a Protocol Amount element
                   within the Brand List Component which is to be
                   used when making the payment.

CurrencyAmountRef  The Element Reference of a Currency Amount element
                   within the Brand List Component which is to be
                   used when making the payment.

  Content:

BrandSelBrandInfo,           This contains any additional data that
BrandSelProtocolAmountInfo,  may be required by a particular payment
BrandSelCurrencyAmountInfo   brand or protocol. See sections 6.7.1,
                             6.7.2, and 6.7.3.

  The following rules apply:
  o  the BrandListRef must contain the ID of a Brand List Component
     in the same IOTP Transaction
  o  every Brand List Component in the Trading Protocol Options
     Block must be referenced by one and only one Brand Selection
     Component
  o  the BrandRef must refer to the ID of a Brand contained within
     the Brand List Component referred to by BrandListRef
  o  the ProtocolAmountRef must refer to one of the Element IDs
     listed  in the ProtocolAmountRefs attribute of the Brand
     element identified by BrandRef
  o  the CurrencyAmountRef must refer to one of the Element IDs
     listed in the CurrencyAmountRefs attribute of the Protocol
     Amount Element identified by ProtocolAmountRef.

  An example of a Brand Selection Component is included in 10 Brand List
  Examples.

6.7.1 Brand Selection Brand Info Element

  The Brand Selection Brand Info Element contains any additional data
  that may be required by a particular payment brand. See the IOTP
  payment method supplement for a description of how and when it used.

<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
  Id ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:

                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Packaged Content information (see section 3.8)
                   that contains additional data that may be required
                   by a particular payment brand. See the payment
                   method supplement for IOTP for rules on how this
                   is used.

6.7.2 Brand Selection Protocol Amount Info Element

  The Brand Selection Protocol Amount Info Element contains any
  additional data that is payment protocol specific that may be required
  by a particular payment brand or payment protocol. See the IOTP
  payment method supplement for a description of how and when it used.

<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
  Id ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ContentSoftwareId  See section 6.7.1 Brand Selection Brand Info
                   Element.

  Content:

PackagedContent    Packaged Content information (see section 3.8)
                   that contains any additional data that may be
                   required by a particular payment brand. See the
                   payment method supplement for IOTP for rules on
                   how this is used.

6.7.3 Brand Selection Currency Amount Info Element

  The Brand Selection Currency Amount Info Element contains any
  additional data that is payment brand and currency specific that may
  be required by a particular payment brand. See the IOTP payment method
  supplement for a description of how and when it used.

<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
  Id ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ContentSoftwareId  See section 6.7.1 Brand Selection Brand Info
                   Element.

  Content:

PackagedContent    Packaged Content information (see section 3.8)
                   that contains any additional data relating to the
                   payment brand and currency. See the payment method
                   supplement for IOTP for rules on how this is used.

6.8 Payment Component

  A Payment Component contains information used to control how a payment
  is carried out. Its provides information on:
  o  the times within which a Payment with a Payment Handler may be
     started
  o  a reference to the Brand List (see section 6.6) which
     identifies the Brands, protocols, currencies and amounts which
     can be used to make a payment
  o  whether or not an authentication of the consumer is required
     as part of the payment
  o  whether or not a payment receipt will be provided
  o  whether another payment precedes this payment.

  Its definition is as follows.

<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
  ID ID          #REQUIRED
  OkFrom         CDATA   #REQUIRED
  OkTo           CDATA   #REQUIRED
  BrandListRef   NMTOKEN #REQUIRED
  SignedPayReceipt       ('True'|'False') #REQUIRED
  AuthDataRef    NMTOKEN #IMPLIED
  StartAfter     NMTOKENS  #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Component within the IOTP Transaction.

OkFrom             The date and time in [UTC] format after which a
                   Payment Handler may accept for processing a
                   Payment Request Block (see section 7.6) containing
                   the Payment Component.

OkTo               The date and time in [UTC] format before which a
                   Payment Handler may for processing accept a
                   Payment Request Block containing the Payment
                   Component.

BrandListRef       An Element Reference (see section 3.5) of a Brand
                   List Component (see section 6.6) within the TPO
                   Trading Block for the IOTP Transaction. The Brand
                   List identifies the alternative ways in which the
                   payment can be made.

AuthDataRef        An element reference (see section 3.4) of an
                   Authentication Data Component (see section 6.2)
                   which is to be used for authentication of the
                   Trading Role which sends the Payment Request Block
                   containing the Payment Component to the Payment
                   Handler. If not present, then no authentication is
                   to take place.

SignedPayReceipt   Indicates whether or not the Payment Response
                   Block (7.8) generated by the payment handler for
                   the payment must be digitally signed.

StartAfter         Contains Element References (see section 3.5) of
                   other Payment Components which describe payments
                   which must be complete before this payment can
                   start. If no StartAfter attribute is present then
                   there are no dependencies and the payment can
                   start immediately

  Contents

PackagedContent    This optional element contains "user" data defined
                   by the Merchant which is required by the Payment
                   Handler. See section 3.8 Packaged Content Element.

6.9 Payment Scheme Component

  A Payment Scheme Component contains payment protocol information for a
  specific payment scheme which is transferred between the parties
  involved in a payment for example a [SET] message. Its definition is
  as follows.

<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
  ID ID          #REQUIRED
  ConsumerPaymentId      CDATA   #IMPLIED
  PaymentHandlerPayId CDATA   #IMPLIED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                   An identifier which uniquely identifies the
                     Payment Scheme Component within the IOTP
                     Transaction.

ConsumerPaymentId    An identifier specified by the Consumer which,
                     if returned by the Payment Handler in another
                     Payment Scheme Component or by other means, will
                     enable the Consumer to identify which payment is
                     being referred to.

PaymentHandlerPayId  An identifier specified by the Payment Handler
                     which, if returned by the Consumer in another
                     Payment Scheme Component, or by other means,
                     will enable the Payment Handler to identify
                     which payment is being referred to. It is
                     required on every Payment Scheme Component apart
                     from the one contained in a Payment Request
                     Block.

ContentSoftwareId    This contains information which identifies the
                     software which generated the content of the
                     element. Its purpose is to help resolve
                     interoperability problems that might occur as a
                     result of incompatibilities between messages
                     produced by different software. It is a single
                     text string in the language defined by xml:lang.
                     It must contain, as a minimum:
                     o  the name of the software manufacturer
                     o  the name of the software
                     o  the version of the software, and
                     o  the build of the software

                     It is recommended that this attribute is
                     included if the software which generated the
                     content cannot be identified from the SoftwareId
                     attribute on the Message Id Component (see
                     section 3.3.2)

  Content:

PackagedContent      Contains the payment scheme protocol information
                     as Packaged Content (see section 3.8). See the
                     payment scheme supplement for the definition of
                     its content.

6.10 Payment Receipt Component

  A Payment Receipt is a record of a payment which demonstrates how much
  money has been paid or received. It is distinct from a purchase
  receipt in that it contains no record of what was being purchased.

  Typically the content of a Payment Receipt Component will contain data
  which describes:
  o  the amount paid and its currency
  o  the date and time of the payment
  o  internal reference numbers which identify the payment to the
     payment system
  o  potentially digital signatures generated by the payment method
     which can be used to prove after the event that the payment
     occurred.

  If the Payment Method being used provides the facility then the
  Payment Receipt Component should contain payment protocol messages, or
  references to messages, which prove the payment occurred.

  The precise definition of the content is Payment Method dependent.
  Refer to the supplement for the payment method being used to determine
  the rules that apply.

  Information contained in the Payment Receipt Component should be
  displayed or otherwise made available to the Consumer.

  [Note]   If the Payment Receipt Component contains Payment Protocol
           Messages, then the Messages will need to be processed by
           Payment Method software to convert it into a format which
           can be understood by the Consumer
  [Note End]

  The definition of a Payment Receipt Component is as follows.

<!ELEMENT PayReceipt (PackagedContent?) >
<!ATTLIST PayReceipt
  ID ID          #REQUIRED
  PaymentRef     NMTOKEN #REQUIRED
  PayReceiptRefs NMTOKENS  #IMPLIED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Receipt Component within the IOTP
                   Transaction.

PaymentRef         Contains an Element Reference (see section 3.5) to
                   the Payment Component (see section 6.8) to which
                   this payment receipt applies

PayReceiptRefs     Optionally contains Element References to other
                   Components (potentially including Pay Scheme
                   Components) which together make up the receipt.
                   Note that:
                   o  each payment scheme defines in its supplement
                      the elements which must be referenced.
                   o  each of the components referenced must be
                      hashed and signed in the Payment Response
                      signature component, if one is being used.

                   The client software should save all the components
                   referenced so that the payment receipt can be
                   reconstructed when required.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Optionally contains the payment scheme specific
                   record of the payment which can be used for
                   receipt purposes as Packaged Content (see section
                   3.8). Each payment scheme defines in its
                   supplement the structure of the content.

  Note that either the PayReceiptRefs attribute, the PackagedContent
  element, or both must be present.

6.11 Payment Note Component

  The Payment Note Component contains additional, non payment related,
  information which the Payment Handler wants to provide to the
  Consumer. For example, if a withdrawal or deposit were being made then
  it could contain information on the remaining balance on the account
  after the transfer was complete. The information should duplicate
  information contained within the Payment Receipt Component.

  Information contained in the Payment Note Component should be
  displayed or otherwise made available to the Consumer. For
  interoperability, the Payment Note Component should support, as a
  minimum, a content type of "Plain/Text". Its definition is as follows.

<!ELEMENT PaymentNote (PackagedContent) >
<!ATTLIST PaymentNote
  ID ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Receipt Component within the IOTP
                   Transaction.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Contains additional, non payment related,
                   information which the Payment Handler wants to
                   provide to the Consumer as Packaged Content (see
                   section 3.8).

6.12 Delivery Component

  The Delivery Element contains information required to deliver goods or
  services. Its definition is as follows.

<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
<!ATTLIST Delivery
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  DelivExch (True|False) #REQUIRED
  DelivAndPayResp (True|False) #REQUIRED
  ActionOrgRef   NMTOKEN #IMPLIED
  ConsumerDeliveryId     CDATA   #IMPLIED >

  Attributes:

ID                   An identifier which uniquely identifies the
                     Delivery Component within the IOTP Transaction.

xml:lang             Defines the language used by attributes or child
                     elements within this component, unless
                     overridden by an xml:lang attribute on a child
                     element. See section 3.9 Identifying Languages.

DelivExch            Indicates if this IOTP Transaction includes the
                     messages associated with a Delivery Exchange.
                     Valid values are:
                     o  True indicates it does include a Delivery
                       Exchange
                     o  False indicates it does not include a Delivery
                       Exchange

                     If set to true then a DeliveryData element must
                     be present. If set to false it may be absent.

DelivAndPayResp      Indicates if the Delivery Response Block (see
                     section 7.10) and the Payment Response Block
                     (see section 7.8 ) are combined into one IOTP
                     Message. Valid values are:
                     o  True indicates both blocks will be in the same
                       IOTP Message, and
                     o  False indicates each block will be in a
                       different IOTP Message

                     DelivAndPayResp should not be true if DelivExch
                     is False.

                     In practice combining the Delivery Response
                     Block and Payment Response Block is only likely
                     to be  practical if the Merchant, the Payment
                     Handler and the Delivery Handler are the same
                     organisation since:
                     o  the Payment Handler must have access to Order
                       Component information so that they know what
                       to deliver, and
                     o  the Payment Handler must be able to carry out
                       the delivery

ActionOrgRef         An Element Reference to the Organisation
                     Component of the Delivery Handler for this
                     delivery.

ConsumerDeliveryId   An identifier specified by the Consumer which,
                     if returned by the Delivery Handler in another
                     Delivery Component, or by other means, will
                     enable the Consumer to identify which Delivery
                     is being referred to.

  Content:

DeliveryData       Contains details about how the delivery will be
                   carried out. See 6.12.1 Delivery Data Element
                   below.

PackagedContent    This optional element contains "user" data defined
                   for the Merchant which is required by the Delivery
                   Handler. See section 3.8 Packaged Content Element.

6.12.1 Delivery Data Element

  The DeliveryData element contains information about where and how
  goods are to be delivered. Its definition is as follows.

<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
  xml:lang       NMTOKEN #IMPLIED
  OkFrom         CDATA   #REQUIRED
  OkTo           CDATA   #REQUIRED
  DelivMethod    NMTOKEN #REQUIRED
  DelivToRef     NMTOKEN #REQUIRED
  DelivReqNetLocnCDATA   #REQUIRED
  SecDelivReqNetLocn     CDATA   #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

xml:lang            Defines the language used by attributes within
                    this component. See section 3.9 Identifying
                    Languages.

OkFrom              The date and time in [UTC] format after which the
                    Delivery Handler may accept for processing a
                    Delivery Request Block (see section 7.9).

OkTo                The date and time in [UTC] format before which the
                    Delivery Handler may accept for processing a
                    Delivery Request Block.

DelivMethod         Indicates the method by which goods or services
                    may be delivered. Valid values are:
                    o  Post the goods will be delivered by post or
                       courier
                    o  Web the goods will be delivered electronically
                       in the Delivery Note Component
                    o  Email the goods will be delivered
                       electronically by e-mail
                    o  x-ddd:nnn a user defined delivery method see
                       3.7.3 User Defined Codes.

DelivToRef          The Element Reference (see section 3.4) of an
                    Organisation Component within the IOTP Transaction
                    which has a role of DelivTo. The information in
                    this block is used to determine where delivery is
                    to be made. It must be compatible with
                    DelivMethod. Specifically if the DelivMethod is:
                    o  Post, then the there must be a Postal Address
                       Element containing sufficient information for a
                       postal delivery,
                    o  Web, then there are no specific requirements.
                       The information will be sent in a web page back
                       to the Consumer
                    o  Email, then there must be Contact Information
                       Element with a valid e-mail address

DelivReqNetLocn     This contains the Net Location to which an
                    unsecured Delivery Request Block (see section 7.9)
                    which contains the Delivery Component should be
                    sent.

                    The content of this attribute is dependent on the
                    Transport Mechanism must conform to [RFC1738].

SecDelivReqNetLocn  This contains the Net Location to which a secured
                    Delivery Request Block (see section 7.9) which
                    contains the Delivery Component should be sent.

                    A secured delivery request involves the use of a
                    secure channel such as [SSL] in order to
                    communicate with the Payment Handler.

                    The content of this attribute is dependent on the
                    Transport Mechanism must conform to [RFC1738].

                    See also Section 3.10 Secure and Insecure Net
                    Locations.

ContentSoftwareId   This contains information which identifies the
                    software which generated the content of the
                    element. Its purpose is to help resolve
                    interoperability problems that might occur as a
                    result of incompatibilities between messages
                    produced by different software. It is a single
                    text string in the language defined by xml:lang.
                    It must contain, as a minimum:
                    o  the name of the software manufacturer
                    o  the name of the software
                    o  the version of the software, and
                    o  the build of the software

                    It is recommended that this attribute is included
                    if the software which generated the content cannot
                    be identified from the SoftwareId attribute on the
                    Message Id Component (see section 3.3.2)

  Content:

PackagedContent    Optional additional information about the delivery
                   as Packaged Content (see section 3.8). provided to
                   the Delivery Handler by the merchant.

6.13 Delivery Note Component

  A Delivery Note contains delivery instructions about the delivery of
  goods or services or potentially the actual Delivery Information
  itself. It is information which the person or organisation receiving
  the Delivery Note can use when delivery occurs.

<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  DelivHandlerDelivId    CDATA   #IMPLIED
  ContentSoftwareId      CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Delivery Note Component within the IOTP
                   Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

DelivHandlerDeliv  An optional identifier specified by the Delivery
Id                 Handler which, if returned by the Consumer in
                   another Delivery Component, or by other means,
                   will enable the Delivery Handler to identify which
                   Delivery is being referred to. It is required on
                   every Delivery Component apart from the one
                   contained in a Delivery Request Block.

                   An example use of this attribute is to contain a
                   delivery tracking number.

ContentSoftwareId  This contains information which identifies the
                   software which generated the content of the
                   element. Its purpose is to help resolve
                   interoperability problems that might occur as a
                   result of incompatibilities between messages
                   produced by different software. It is a single
                   text string in the language defined by xml:lang.
                   It must contain, as a minimum:
                   o  the name of the software manufacturer
                   o  the name of the software
                   o  the version of the software, and
                   o  the build of the software

                   It is recommended that this attribute is included
                   if the software which generated the content cannot
                   be identified from the SoftwareId attribute on the
                   Message Id Component (see section 3.3.2)

  Content:

DeliveryNote       Contains the actual delivery note information as
                   Packaged Content (see section 3.8).

  [Note]   If the content of the Delivery Message is a Mime message
           then the Delivery Note may trigger an application which
           causes the actual delivery to occur.
  [Note End]

6.14 Payment Method Information Component

  A Payment Method Information Component contains data which describes
  the Payment Method which initiated the Payment Instrument Customer
  Care Transaction and the software which generated the message. Its
  definition is as follows.

<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
  ID ID          #REQUIRED
  BrandId        NMTOKEN #REQUIRED
  PayProtocolId  NMTOKEN #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Method Information Component within the
                   IOTP Transaction.

BrandId            The Brand Identifier attribute copied from the
                   BrandId attribute of the Brand Element (see
                   section 6.6.1)of the Payment Instrument which
                   needs customer care.

PayProtocolId      The ProtocolId attribute copied from the Pay
                   Protocol Element (see section 6.6.4) of the Brand
                   being used. This may not be required for all types
                   of Payment Instrument. See the IOTP Supplement for
                   the Payment Method to determine if this is to be
                   used.

6.15 Status Component

  A Status Component contains status information about the business
  success or failure (see section 4.2) of a process.

  Its definition is as follows.

<!ELEMENT Status EMPTY >
<!ATTLIST Status
  ID ID          #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  StatusType (Offer|Payment|Delivery|Authentication) #REQUIRED
  ElRef          NMTOKEN #REQUIRED
  ProcessState (NotYetStarted|InProgress|
     CompletedOk|Failed|ProcessError) #REQUIRED
  CompletionCode NMTOKEN #IMPLIED
  ProcessReference       CDATA   #IMPLIED
  StatusDesc     CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the Status
                   Component within the IOTP Transaction.

xml:lang           Defines the language used by attributes within
                   this component. See section 3.9 Identifying
                   Languages.

StatusType         Indicates the type of process which the Status is
                   reporting on. It may be set to either Offer,
                   Payment, Delivery or Authentication

ElRef              Contains an Element Reference (see section 3.5) to
                   the Component for which the Status is being
                   described. It must refer to either:
                   o  a Trading Protocol Options Block (see section
                      7.1), if the StatusType is Offer,
                   o  a Payment Component (see section 6.8), if the
                      StatusType is Payment, or
                   o  a Delivery Component (see section 6.12), if the
                      StatusType is Delivery
                   o  an Authentication Data Component (see section
                      6.2) if the statusType is Authentication.

ProcessState       Contains a State Code which indicates the current
                   state of the process being carried out. Valid
                   values for ProcessState are:
                   o  NotYetStarted. A Request Block has been
                      received but the process has not yet started
                   o  InProgress. Processing of the Request Block has
                      started but it is not yet complete
                   o  CompletedOk. The processing of the Request
                      Block has completed successfully without any
                      errors
                   o  Failed. The processing of the Request Block has
                      failed because of a business error (see section
                      4.2)
                   o  ProcessError. This value is only used when the
                      Status Component is being used in connection
                      with an Inquiry Request Trading Block (see
                      section 7.14). It indicates there was a
                      Technical Error (see section 4.1) in the Request
                      Block which is being processed or some internal
                      processing error.

                   Note that this code reports on the processing of a
                   Request Block. Further, asynchronous processing
                   may occur after the Response Block associated with
                   the Process has been sent.

CompletionCode     Indicates how the process completed. Valid values
                   for the CompletionCode are given below together
                   with the conditions when it must be present.

                   A CompletionCode is a maximum of 14 characters
                   long.

ProcessReference   This optional attribute holds a reference for the
                   process whose status is being reported. It may
                   hold the following values:
                   o  when StatusType is set to Offer, it should
                      contain the OrderIdentifier from the Order
                      Component
                   o  when StatusType is set to Payment, it should
                      contain the PaymentHandlerPayId from the Payment
                      Scheme Data Component
                   o  when StatusType is set to Delivery, it should
                      contain the DelivHandlerDelivId from the
                      Delivery Note Component
                   o  when StatusType is set to Authentication, it
                      should contain the AuthenticationId from the
                      Authentication Data Component

                   This attribute should be absent in the Inquiry
                   Request message when the Consumer has not been
                   given such a reference number by the IOTP Service
                   Provider.

                   This attribute can be used in an Inquiry Response
                   Block (see section 7.15) to give the reference
                   number for a transaction which has previously been
                   unavailable.

                   For example, the package tracking number might not
                   be assigned at the time a delivery response was
                   received. However, if the Consumer issues a
                   Baseline Transaction Status Inquiry later, the
                   Delivery Handler can put the package tracking
                   number into this attribute in the Inquiry Response
                   message and send it back to the Consumer.

StatusDesc         An optional textual description of the current
                   status of the process in the language identified
                   by xml:lang.

6.15.1.1 Offer Completion Codes

  The Completion Code is only required if the ProcessState attribute is
  set to Failed. The following table contains the valid values for the
  CompletionCode that may be used. It is recommended that the StatusDesc
  attribute is used to provide further explanation where appropriate.

       Value                           Description

AuthError          Authentication Error. The check of the
                   Authentication Response which was carried out has
                   failed.

OfferDecl          Offer Declined. The Merchant declines to generate
                   an offer for some reason.

Unspecified        Unspecified error. There is some unknown problem
                   or error which does not fall into one of the other
                   CompletionCodes.

6.15.1.2 Payment Completion Codes

  The CompletionCode is only required if the ProcessState attribute is
  set to Failed. The following table contains the valid values for the
  CompletionCode that may be used. It is recommended that the StatusDesc
  attribute is used by individual payment schemes to provide further
  explanation where appropriate.

       Value                           Description

BrandNotSupp       Brand not supported. The payment brand is not
                   supported by the Payment Handler.

CurrNotSupp        Currency not supported. The currency in which the
                   payment is to be made is not supported by either
                   the Payment Instrument or the Payment Handler.

AuthError          Authentication Error. The Payment Scheme specific
                   authentication check which was carried out has
                   failed.

InsuffFunds        Insufficient funds. There are insufficient funds
                   available for the payment to be made.

InstBrandInvalid   Payment Instrument not valid for Brand. A Payment
                   Instrument is being used which does not correspond
                   with the Brand selected. For example a Visa credit
                   card is being used when MasterCard was selected as
                   the Brand.

PaymntDecl         Payment declined. The Payment Handler declines to
                   accept the payment for some reason.

InstNotValid       Payment instrument not valid for trade. The
                   Payment Instrument cannot be used for the proposed
                   type of trade, for some reason.

BadInstrumenat     Bad instrument. There is a problem with the
                   Payment Instrument being used which means that it
                   is unable to be used for the payment.

Unspecified        Unspecified error. There is some unknown problem
                   or error which does not fall into one of the other
                   CompletionCodes. The StatusDesc attribute should
                   provide the explanation of the cause.

6.15.1.3 Delivery Completion Codes

  The following table contains the valid values for the CompletionCode
  attribute for a Delivery. It is recommended that the StatusDesc
  attribute is used to provide further explanation where appropriate.

       Value                           Description

BackOrdered        Back Ordered. The goods to be delivered are on
                   order but they have not yet been received.

                   Shipping will be arranged when they are received.
                   This is only valid if ProcessState is CompletedOk.

PermNotAvail       Permanently Not Available. The goods are
                   permanently unavailable and cannot be re-ordered.
                   This is only valid if ProcessState is Failed.

TempNotAvail       Temporarily Not Available. The goods are
                   temporarily unavailable and may become available
                   if they can be ordered. This is only valid if
                   ProcessState is CompletedOk.

ShipPending        Shipping Pending. The goods are available and are
                   scheduled for shipping but they have not yet been
                   shipped. This is only valid if ProcessState is
                   CompletedOk.

Shipped            Goods Shipped. The goods have been shipped.
                   Confirmation of delivery is awaited. This is only
                   valid if ProcessState is CompletedOk.

ShippedNoConf      Shipped - No Delivery Confirmation. The goods have
                   been shipped but it is not possible to confirm
                   delivery of the goods. This is only valid if
                   ProcessState is CompletedOk.

Confirmed          Confirmed. All goods have been delivered and
                   confirmation of their delivery has been received.
                   This is only valid if ProcessState is CompletedOk.

6.15.1.4 Authentication Completion Codes

  The Completion Code is only required if the ProcessState attribute is
  set to Failed. The following table contains the valid values for the
  CompletionCode that may be used. It is recommended that the StatusDesc
  attribute is used to provide further explanation where appropriate.

       Value                           Description

AuthDecl           Authentication Declined. The Authenticatee
                   declines to be authenticated. This could be, for
                   example because the signature on an Authentication
                   Request was invalid or the Authenticator was not
                   known or acceptable to the Authenticatee.

TradRolesIncon     Trading Roles Inconsistent. The Trading Roles
                   contained within the TradingRoleList attribute of
                   the Authentication Data Component are inconsistent
                   with the Trading Role which the Authenticatee is
                   taking in the OTP transaction or is able to take.
                   Examples of inconsistencies include:

                   o  asking a PaymentHandler for DeliveryHandler
                      information
                   o  asking a Consumer for Merchant information

Unspecified        Unspecified error. There is some unknown problem
                   or error which does not fall into one of the other
                   CompletionCodes.

6.16 Trading Role Data Component

  The Trading Role Data Component contains opaque data which is needs to
  be communicated between the Trading Roles involved in an OTP
  Transaction.

  Trading Role Components identify:
  o  the organisation that generated the component, and
  o  the organisation that is to receive it.

  They are first generated and included in a "Response" Block, and then
  copied to the appropriate "Request" Block. For example a Payment
  Handler might need to inform a Delivery Handler that a credit card
  payment had been authorised but not captured. There may also be other
  information that the Payment Handler has generated who format is
  privately agreed with the Delivery Handler which needs to be
  communicated.

  Its definition is as follows.

<!ELEMENT TradingRoleData (PackagedContent) >
<!ATTLIST TradingRoleData
  ID ID          #REQUIRED
  OriginatorElRefNMTOKEN #REQUIRED
  DestinationElRefs      NMTOKENS   #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Trading Role Data Component within the IOTP
                   Transaction.

OrginatorElRef     Contains an element reference to the Organisation
                   Component of the Organisation that created the
                   Trading Role Data Component and included it in a
                   "Response" Block (e.g. an Offer Response or a
                   Payment Response Block).

DestinationElRefs  Contains element references to the Organisation
                   Components of the Organisations that are to
                   receive the Trading Role Data Component in a
                   "Request" Block (e.g. either a Payment Request or
                   a Delivery Request Block).

  Content:

PackagedContent    This contains the data which is to be sent between
                   the various Trading Roles. For a definition of
                   PackagedContent see section 3.8.

6.16.1 Who Receives a Trading Role Data Component

  The rules for deciding what to do with Trading Role Data Components
  are described below.
  o  whenever a Trading Role Data Component is received in a
     "Response" block identify the Organisation Components of the
     Organisations that are to receive it as identified by the
     DestinationElRefs attribute.
  o  whenever a "Request" Block is being sent, check to see if it
     is being sent to one of the Organisations identified by the
     DestinationElRef attribute. If it is then include in the
     "Request" block:
     - the Trading Role Data Component as well as,
     - the Organisation Component of the Organisation identified by the
       OrignatorElRef attribute (if not already present)

6.17 Inquiry Type Component

  The Inquiry Component contains the information which indicates what
  type of process is being inquired upon. Its definition is as follows.

<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
  ID ID          #REQUIRED
  Type (Offer|Payment|Delivery) #REQUIRED
  ElRef          NMTOKEN #IMPLIED
  ProcessReference       CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Inquiry Type Component within the IOTP
                   Transaction.

Type               Contains the type of inquiry. Valid values for
                   Type are:
                   o  Offer. The inquiry is about the status of an
                      offer and is addressed to the Merchant.
                   o  Payment. The inquiry is about the status of a
                      payment and is addressed to the Payment Handler.
                   o  Delivery. The inquiry is about the status of a
                      delivery and addressed to the Delivery Handler.

ElRef              Contains an Element Reference (see section 3.5) to
                   the component to which this Inquiry Type Component
                   applies. That is,
                   o  TPO Block when Type is Offer
                   o  Payment Component when Type is Payment
                   o  Delivery Component when Type is Delivery

ProcessReference   Optionally contains a reference to the process
                   being inquired upon. It should be set if the
                   information is available. For the definition of
                   the values it may contain, see the
                   ProcessReference attribute of the Status Component
                   (see section 6.15).

6.18 Signature Component

  Each Signature Component digitally signs one or more Blocks or
  Components including other Signature Components.

  For a general explanation of signatures see section 5 Security
  Considerations. Detailed definitions of the XML structures for
  signatures is described in the paper "Digital Signature for XML -
  Proposal", see [XMLSIG].

  The Signature Component:
  o  hashes one or more Blocks or Components in one or more IOTP
     Messages within the same IOTP Transaction
  o  concatenates these hashes into a Signed Data element, and
  o  signs the SignedData element using the optional certificate
     identified in the CertRef attribute of the Digital Signature
     element.

  Note that a Signed Data Element may be signed by more than one Digital
  Signature element.

  A Signature Component can be one of two types either:
  o  an Offer Response Signature, or
  o  a Payment Response Signature

  How these signatures are constructed is described below

6.18.1 Offer Response Signature Component

  The Signed Data Element of the Offer Response Signature Component
  should contain hashes of the following Components:
  o  the Transaction Id Component (see section 3.3.1) of the IOTP
     message that contains the Offer Response Signature
  o  the Transaction Reference Block (see section 3.3) of the IOTP
     Message that contains the Offer Response Signature
  o  from the TPO Block:
     - the Protocol Options Component
     - each of the Organisation Components
     - each of the Brand List Components
  o  optionally, all the Brand Selection Components if they were
     sent to the Merchant in a TPO Selection Block
  o  from the Offer Response Block:
     - the Order Component
     - each of the Payment Components
     - the Delivery Component
     - each of the Authentication Data Components
     - any Trading Role Data Components

  The Offer Response Signature Component should also contain Digital
  Signature Elements for each of the organisations that may or will need
  to verify the signature. This involves:
  o  if the Merchant has received a TPO Selection Block containing
     Brand Selection Components, then generate a Digital Signature
     Element for the Payment Handler identified by the Brand
     Selection Component and the Delivery Handler identified by the
     Delivery Component. See section 5.3.1 Check the Action Request
     was sent to the Correct Organisation for a description of how
     this can be done.
  o  if the Merchant is not expecting to receive a TPO Selection
     Block then generate a Digital Signature Element for the
     Delivery Handler and all the Payment Handlers that are
     involved.

6.18.2 Payment Receipt Signature Component

  The Signed Data Element of the Payment Receipt Signature Component
  should contain hashes of the following Components:
  o  the Transaction Id Component (see section 3.3.1) of the IOTP
     message that contains the Payment Receipt Signature
  o  the Transaction Reference Block (see section 3.3) of the IOTP
     Message that contains the Payment Receipt Signature
  o  the Offer Response Signature Component
  o  the Payment Receipt Component
  o  the Status Component
  o  the Brand Selection Component.
  o  any Trading Role Data Components

6.18.3 Ping Signature Components

  If the Ping Response Transaction is generating a signature (see
  section 8.9), the Signed Data Element of the Ping Response or Ping
  Request Signature Components should contain hashes of the following
  Components:
  o  all the Organisation Components.

6.19 Error Component

  The Error Component contains information about Technical Errors (see
  section 4.1) in an IOTP Message which has been received by one of the
  Trading Roles involved in the trade.

  For clarity two phrases are defined which are used in the description
  of an Error Component:
  o  message in error. An IOTP message which contains or causes an
     error of some kind
  o  message reporting the error. An IOTP message that contains an
     Error Component that describes the error found in a message in
     error.

  The definition of the Error Component is as follows.

<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
  ID NMTOKEN     #REQUIRED
  xml:lang       NMTOKEN #REQUIRED
  ErrorCode      NMTOKEN #REQUIRED
  ErrorDesc      CDATA   #REQUIRED
  Severity (Warning|TransientError|HardError)   #REQUIRED
  MinRetrySecs   CDATA   #IMPLIED
  SwVendorErrorRef       CDATA   #IMPLIED >

  Attributes:

ID                 An identifier which uniquely identifies the Error
                   Component within the IOTP Transaction.

xml:lang           Defines the language used by attributes or child
                   elements within this component, unless overridden
                   by an xml:lang attribute on a child element. See
                   section 3.9 Identifying Languages.

ErrorCode          Contains an error code which indicates the nature
                   of the error in the message in error. Valid values
                   for the ErrorCode are given in section 6.19.2
                   Error Codes.

ErrorDesc          Contains a narrative description of the error in
                   the language defined by xml:lang. The content of
                   this attribute is defined by the vendor/developer
                   of the software which generated the Error
                   Component

Severity           Indicates the severity of the error.  Valid values
                   are:
                   o  Warning. This indicates that although there is
                      a message in error the IOTP Transaction can
                      still continue.
                   o  TransientError. This indicates that the error
                      in the message in error may be recovered if the
                      message in error  that is referred to by the
                      ErrorLocation element is resent
                   o  HardError. This indicates that there is an
                      unrecoverable error in the message in error and
                      the IOTP Transaction must stop.

MinRetrySecs       This attribute should be present if Severity is
                   set to TransientError. It is the minimum number of
                   whole seconds which the IOTP aware application
                   which received the message reporting the error
                   should wait before re-sending the message in error
                   identified by the ErrorLocation element.

                   If Severity is not set to TransientError then the
                   value of this attribute is ignored.

SwVendorErrorRef   This attribute is a reference whose value is set
                   by the vendor/developer of the software which
                   generated the Error Component. It should contain
                   data which enables the vendor to identify the
                   precise location in their software and the set of
                   circumstances which caused the software to
                   generate a message reporting the error. See also
                   the SoftwareId attribute of the Message Id element
                   in the Transaction Reference Block (section 3.3).

  Content:

ErrorLocation      This identifies the IOTP Transaction Id of the
                   message in error  and, where possible, the element
                   and attribute in the message in error that caused
                   the Error Component to be generated.

                   If the Severity of the error is not
                   TransientError, more than one ErrorLocation may be
                   specified as appropriate depending on the nature
                   of the error (see section 6.19.2 Error Codes) and
                   at the discretion of  the vendor/developer of the
                   IOTP Aware Application.

PackagedContent    This contains additional data which can be used to
                   understand the error. Its content may vary as
                   appropriate depending on the nature of the error
                   (see section 6.19.2 Error Codes) and at the
                   discretion of the vendor/developer of the IOTP
                   Aware Application. For a definition of
                   PackagedContent see section 3.8.

6.19.1 Error Processing Guidelines

  If there is more than one Error Component in a message reporting the
  error, carry out the actions appropriate for the Error Component with
  the highest severity. In this context, HardError has a higher severity
  than TransientError, which has a higher severity than Warning.

6.19.1.1 Severity - Warning

  If an IOTP aware application is generating a message reporting the
  error with an Error Component where the Severity attribute is set to
  Warning, then if the message reporting the error does not contain
  another Error Component with a severity higher than Warning, the IOTP
  Message must also include the Trading Blocks and Trading Components
  that would have been included if no error was being reported.

  If a message reporting the error is received with an Error Component
  where Severity is set to Warning, then:
  o  it is recommended that information about the error is either
     logged, or otherwise reported to the user,
  o  the implementer of the IOTP aware application must either, at
     their or the user's discretion:
     - continue the IOTP transaction as normal, or
     - fail the IOTP transaction by generating a message reporting the
       error with an Error Component with Severity set to HardError
       (see section 6.19.1.3).

  If the intention is to continue the IOTP transaction then, if there
  are no other Error Components with a higher severity, check that the
  necessary Trading Blocks and Trading Components for normal processing
  of the transaction to continue are present. If they are not then
  generate a message reporting the error with an Error Component with
  Severity set to HardError.

6.19.1.2 Severity - Transient Error

  If an IOTP Aware Application is generating a message reporting the
  error with an Error Component where the Severity attribute is set to
  TransientError, then there should be only one Error Component in the
  message reporting the error. In addition, the MinRetrySecs attribute
  should be present.

  If a message reporting the error is received with an Error Component
  where Severity is set to TransientError then:
  o  if the MinRetrySecs attribute is present and a valid number,
     then use the MinRetrySecs value given. Otherwise if
     MinRetrySecs is missing or is invalid, then:
     - generate a message reporting the error containing an Error
       Component with a Severity of Warning and send it on the next
       IOTP message (if any) to be sent to the Trading Role which sent
       the message reporting the error with the invalid MinRetrySecs,
       and
     - use a value for MinRetrySecs which is set by the
       vendor/developer of the IOTP Aware Application.
  o  check that only one ErrorLocation element is contained within
     the Error Component and that it refers to an IOTP Message
     which was sent by the recipient of the Error Component with a
     Severity of TransientError. If more than one ErrorLocation is
     present then generate a message reporting the error with a
     Severity of HardError.

6.19.1.3 Severity - Hard Error

  If an IOTP Aware Application is generating a message reporting the
  error with an Error Component where the Severity attribute set to
  HardError, then there should be only one Error Component in the
  message reporting the error.

  If a message reporting the error is received with an Error Component
  where Severity is set to HardError then terminate the IOTP
  Transaction.

6.19.2 Error Codes

  The following table contains the valid values for the ErrorCode
  attribute of the Error Component. The first sentence of the
  description contains the text that should be used to describe the
  error when displayed or otherwise reported. Individual implementations
  may translate this into alternative languages at their discretion.

  An Error Code must not be more that 14 characters long.

       Value                           Description

Reserved           Reserved. This error is reserved by the
                   vendor/developer of the software. Contact the
                   vendor/developer of the software for more
                   information See the SoftwareId attribute of the
                   Message Id element in the Transaction Reference
                   Block(section 3.3).

XmlNotWellFrmd     XML not well formed. The XML document is not well
                   formed. See [XML] for the meaning of "well
                   formed". Even if the XML is not well formed, it
                   should still be scanned to find the Transaction
                   Reference Block so that a properly formed Error
                   Response may be generated.

       Value                           Description

XmlNotValid        XML not valid. The XML document is well formed but
                   the document is not valid. See [XML] for the
                   meaning of "valid". Specifically:
                   o  the XML document does not comply with the
                      constraints defined in the IOTP document type
                      declaration (see section 12 Open Trading
                      Protocol Data Type Definition), and
                   o  the XML document does not comply with the
                      constraints defined in the document type
                      declaration of any additional [XML Namespace]
                      that are declared.

                   As for XML not well formed, attempts should still
                   be made to extract the Transaction Reference Block
                   so that a properly formed Error Response may be
                   generated.

ElUnexpected       Unexpected element. Although the XML document is
                   well formed and valid, an element is present that
                   is not expected in the particular context
                   according to the rules and constraints contained
                   in this specification.

ElNotSupp          Element not supported. Although the document is
                   well formed and valid, an element is present that:
                   o  is consistent with the rules and constraints
                      contained in this specification, but
                   o  is not supported by the IOTP Aware Application
                      which is processing the IOTP Message.

ElMissing          Element missing. Although the document is well
                   formed and valid, an element is missing that
                   should have been present if the rules and
                   constraints contained in this specification are
                   followed.

                   In this case set the PackagedContent of the Error
                   Component to the type of the missing element.

ElContIllegal      Element content illegal. Although the document is
                   well formed and valid, the element PackagedContent
                   contains values which do not conform to the rules
                   and constraints contained in this specification.

EncapProtErr       Encapsulated protocol error. Although the document
                   is well formed and valid, the PackagedContent of
                   an element contains data from an encapsulated
                   protocol which contains errors.

AttUnexpected      Unexpected attribute. Although the XML document is
       Value                           Description
                   well formed and valid, the presence of the
                   attribute is not expected in the particular
                   context according to the rules and constraints
                   contained in this specification.

AttNotSupp         Attribute not supported. Although the XML document
                   is well formed and valid, and the presence of the
                   attribute in an element is consistent with the
                   rules and constraints contained in this
                   specification, it is not supported by the IOTP
                   Aware Application which is processing the IOTP
                   Message.

AttMissing         Attribute missing. Although the document is well
                   formed and valid, an attribute is missing that
                   should have been present if the rules and
                   constraints contained in this specification are
                   followed.

                   In this case set the PackagedContent of the Error
                   Component to the type of the missing attribute.

AttValIllegal      Attribute value illegal. The attribute contains a
                   value which does not conform to the rules and
                   constraints contained in this specification.

AttValNotRecog     Attribute Value Not Recognised. The attribute
                   contains a value which the IOTP Aware Application
                   generating the message reporting the error could
                   not recognise even though it should have been able
                   to since the information had been provided in an
                   earlier IOTP message.

MsgTooLarge        Message too large. The message is too large to be
                   processed by the IOTP Aware Application.

ElTooLarge         Element too large. The element is too large to be
                   processed by the IOTP Aware Application

ValueTooSmall      Value too small or early. The value of all or part
                   of the  PackagedContent of an element or an
                   attribute, although valid, is too small.

ValueTooLarge      Value too large or in the future. The value of all
                   or part of the  PackagedContent of an element or
                   an attribute, although valid, is too large.

ElInconsistent     Element Inconsistent. Although the document is
                   well formed and valid, according to the rules and
                   constraints contained in this specification:
                   o  the content of an element is inconsistent with
       Value                           Description
                      the content of other elements or their
                      attributes, or
                   o  the value of an attribute is inconsistent with
                      the value of one or more other attributes.

                   In this case create ErrorLocation elements which
                   identify all the attributes or elements which are
                   inconsistent.

TransportError     Transport Error. This error code is used to
                   indicate that there is a problem with the
                   Transport Mechanism which is preventing the
                   message from being received. It is typically
                   associated with a Transient Error. Explanation of
                   the Transport Error is contained within the
                   ErrorDesc attribute. The values which can be used
                   inside ErrorDesc with a TransportError is
                   specified in the IOTP supplement for the Transport
                   mechanism.

6.19.3 Error Location Element

  An Error Location Element identifies an element and optionally an
  attribute in the message in error which is associated with the error.
  It contains a reference to the IOTP Message, Trading Block, Trading
  Component, element and attribute, which is in error.

<!ELEMENT ErrorLocation EMPTY>
<!ATTLIST ErrorLocation
  ElementType    NMTOKEN #REQUIRED
  OtpMsgRef      NMTOKEN #REQUIRED
  BlkRef         NMTOKEN #IMPLIED
  CompRef        NMTOKEN #IMPLIED
  ElementRef     NMTOKEN #IMPLIED
  AttName        NMTOKEN #IMPLIED >

  Attributes:

ElementType        This is the "type" (see [XML]) of the Element in
                   the message in error where the error is located.

OtpMsgRef          This is the value of the ID attribute of the of
                   the Message Id Component (see section 3.3.2) of
                   the message in error to which this Error Component
                   applies.

BlkRef             If the error is associated with a specific Trading
                   Block, then this is the value of the ID attribute
                   of the Trading Block where the error is located.

CompRef            If the error is associated with a specific Trading
                   Component, then this is the value of the ID
                   attribute of the Trading Component where the error
                   is located.

ElementRef         If the error is associated with a specific element
                   within a Trading Component then, if the element
                   has an attribute with an "attribute type" (see
                   [XML]) of "ID", then this is the value of that
                   attribute.

AttName            If the error is associated with the value of an
                   attribute, then this is the name of that
                   attribute. In this case the PackagedContent of the
                   Error Component should contain the value of the
                   attribute.

  Note that as many as the attributes as possible should be included.
  For example if an attribute in a child element of a Trading Component
  contains an incorrect value, then all the attributes of ErrorLocation
  should be present.

7. Trading Blocks

  Trading Blocks consist of one or more Trading Components and
  optionally one or more Signature Components. One or more Trading
  Blocks may be contained within the IOTP Messages which are physically
  sent in the form of [XML] documents between the different
  organisations that are taking part in a trade.

  This is illustrated in the diagram below.

          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
  |        |  |-Component            within an OTP Message that
Trading    |  |-Component            contains a predefined set of
Blocks     |  |-Component            Trading Components
  |        |  |-Component
  |        |  |-Component <--------- Trading Components - XML Elements
  |        |                         within a Trading Block that
   ------> |-Trading Block           contain a predefined set of XML
           |  |-Component            elements and attributes
           |  |-Component            containing information required
           |  |-Component            to support a Trading Exchange
           |  |-Component
           |  |-Component
           |
           |

  Figure 18 Trading Blocks

  Trading Blocks are defined as part of the definition of an IOTP
  Message (see section 3.1.1). The definition of an IOTP Message element
  is repeated here:

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

  The remainder of this section defines the Trading Blocks in this
  version of IOTP. They are:
  o  Authentication Request Block
  o  Authentication Response Block
  o  Delivery Request Block
  o  Delivery Response Block
  o  Error Block
  o  Inquiry Request Block
  o  Inquiry Response Block
  o  Offer Response Block
  o  Payment Exchange Block
  o  Payment Request Block
  o  Payment Response Block
  o  Payment Instrument Customer Care Exchange Block
  o  Payment Instrument Customer Care Request Block
  o  Payment Instrument Customer Care Response Block
  o  Signature Block
  o  Trading Protocol Options Block
  o  TPO Selection Block

  The Transaction Reference Block is described in section 3.3.

7.1 Trading Protocol Options Block

  The TPO Trading Block contains options which apply to the IOTP
  Transaction. The definition of a TPO Trading Block is as follows.

<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Trading Protocol Options Block within the IOTP
                   Transaction (see section 3.4 ID Attributes).

  Content:

ProtocolOptions    The Protocol Options Component (see section
                   6.1)defines the options which apply to the whole
                   IOTP Transaction (see section 8).

BrandList          This Brand List Component contains one or more
                   payment brands and protocols which may be selected
                   (see section 6.6).

Org                The Organisation Components (see section 6.5)
                   identify the organisations and their roles in the
                   IOTP Transaction. The roles and organisations
                   which must be present will depend on the
                   particular type of IOTP Transaction. See the
                   definition of each transaction in section 8. Open
                   Trading Protocol Transactions.

  The TPO Block should contain:
  o  the Protocol Options Component
  o  the Organisation Component with the Trading Role of Merchant
  o  the Organisation Component with the Trading Role of Consumer
  o  optionally, the Organisation Component with the Trading Role
     of DeliverTo, if there is a Delivery included in the IOTP
     Transaction
  o  Brand List Components for each payment in the IOTP Transaction
  o  Organisation Components for all the Payment Handlers involved
  o  optionally, Organisation Components for the Delivery Handler
     (if any) for the transaction
  o  additional Organisation Components that the Merchant may want
     to include. For example
     - a Customer Care Provider
     - an Certificate Authority that offers Merchant "Credentials" or
       some other warranty on the goods or services being offered.

7.2 TPO Selection Block

  The TPO Selection Block contains the results of selections made from
  the options contained in the Trading Protocol Options Block (see
  section 7.1).The definition of a TPO Selection Block is as follows.

<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the TPO
                   Selection Block within the IOTP Transaction.

  Content:

BrandSelection     This identifies the choice of payment brand and
                   payment protocol to be used in a payment within
                   the IOTP Transaction. There is one Brand Selection
                   Component (see section 6.7) for each payment to be
                   made in the IOTP Transaction.

  The TPO Selection Block should contain one Brand Selection Component
  for each Brand List in the TPO Block.

7.3 Offer Response Block

  The Offer Response Block contains details of the goods, services,
  amount, delivery instructions or financial transaction which is to
  take place. Its definition is as follows.

<!ELEMENT OfferRespBlk (Status, AuthData*, Order?, Payment*,
     Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the Offer
                   Response Block within the IOTP Transaction.

  Content:

Status             Contains status information about the business
                   success (see section 4.2) or failure of the
                   generation of the Offer. Note that in an Offer
                   Response Block, a ProcessState of NotYetStarted or
                   InProgress are illegal values.

AuthData           The Authentication Data Component contains
                   information about how Authentication associated
                   with the Offer will occur. See section 6.2.

Order              The Order Component contains details about the
                   goods, services or financial transaction which is
                   taking place see section 6.4.

                   The Order Component must be present unless the
                   ProcessState attribute of the Status Component is
                   set to Failed.

Payment            The Payment Components contain information about
                   the payments which are to be made see section 6.8.

Delivery           The Delivery Component contains details of the
                   delivery to be made (see section 6.12).

TradingRoleData    The Trading Role Data Component contains opaque
                   data which is needs to be communicated between the
                   Trading Roles involved in an OTP Transaction (see
                   section 6.16).

  The Offer Response Block should contain:
  o  the Order Component for the IOTP Transaction
  o  Payment Components for each Payment in the IOTP Transaction
  o  the Delivery Component for IOTP Transaction requires (if any)
  o  the Authentication Data Component (if required) for each
     Payment

7.4 Authentication Request Block

  This Authentication Request Block contains the challenge data which is
  used to obtain information about and optionally authenticate a
  Consumer by another Trading Role. Its definition is as follows.

<!ELEMENT AuthReqBlk (AuthData?) >
<!ATTLIST AuthReqBlk
  ID ID          #REQUIRED >

  Attributes

ID                 An identifier which uniquely identifies the
                   Authentication Request Block within the IOTP
                   Transaction.

  Content

AuthData           If the Authentication Data Component is not
                   present it means that the Authentication Request
                   Block is just requesting the return of
                   Organisation Components which describe the
                   Consumer.

                   If the optional Authentication Data Component (see
                   section 6.2) is present it contains data which
                   describes what additional Authentication the
                   consumer must provide.

7.5 Authentication Response Block

  The Authentication Response Block contains the response which results
  from processing the Authentication Request Block. Its definition is as
  follows.

<!ELEMENT AuthRespBlk (AuthResp, Org+) >
<!ATTLIST AuthRespBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Authentication Response Block within the IOTP
                   Transaction.

  Content:

AuthResp           The Authentication Response Component which
                   contains the results of processing the challenge
                   data in the Authentication Data Component - see
                   section 6.3.

Org                Organisation Components which contain information
                   corresponding to the Consumer and DelivTo Trading
                   Roles.

7.6 Payment Request Block

  The Payment Request Block contains information which requests that a
  payment is started. Its definition is as follows.

<!ELEMENT PayReqBlk (Status+, AuthData?, BrandList,
     BrandSelection, Payment, PaySchemeData?, Org*,
     TradingRoleData*) >
<!ATTLIST PayReqBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Request Block within the IOTP Transaction.

  Content:

Status             Contains the Status Components (see section 6.12)
                   of the responses of the steps (e.g. an Offer
                   Response and/or a Payment Response) on which this
                   step depends. It is used to indicate the success
                   or failure of those steps. Payment should only
                   occur of the previous steps were successful.

AuthData           The optional Authentication Data Component
                   contains data about how Authentication associated
                   with the payment, if any, will occur. See section
                   6.2.

BrandList          The Brand List Component contains a list of one or
                   more payment brands and protocols which may be
                   selected (see section 6.6).

BrandSelection     This identifies the choice of payment brand, the
                   payment protocol and the payment handler to be
                   used in a payment within the IOTP Transaction.
                   There is one Brand Selection Component (see
                   section 6.7) for each payment to be made in the
                   IOTP Transaction.

Payment            The Payment Components contain information about
                   the payment which is being made see section 6.8.

PaySchemeData      The Payment Scheme Component contains payment
                   scheme specific data see section 6.9.

Org                The Organisation Component contains details of
                   organisations involved in the payment (see section
                   6.5). The Organisations present are dependent on
                   the IOTP Transaction and the data which is to be
                   signed. See section 5 Security Considerations for
                   more details.

TradingRoleData    The Trading Role Data Component contains opaque
                   data which is needs to be communicated between the
                   Trading Roles involved in an OTP Transaction (see
                   section 6.16).

  The Payment Request Block should contain:
  o  the Organisation Component with a Trading Role of Merchant
  o  the Organisation Component with the Trading Role of Consumer
  o  the Payment Component for the Payment
  o  the Brand List Component for the Payment
  o  the Brand Selection Component for the Brand List
  o  the Organisation Component for the Payment Handler of the
     Payment
  o  the Organisation Component (if any) for the Organisation which
     carried out the previous step, for example another Payment
     Handler
  o  the Organisation Component for the organisation which is to
     carry out the next step, if any. This may be, for example,
     either a Delivery Handler or a Payment Handler.
  o  the Organisation Components for any additional Organisations
     that the Merchant has included in the Offer Response Block
  o  an Optional Payment Scheme Data Component, if required by the
     Payment Method as defined in the IOTP supplement for the
     payment method
  o  any Trading Role Data Components that may be required (see
     section 6.16.1).

7.7 Payment Exchange Block

  The Payment Exchange Block contains payment scheme specific data which
  is exchanged between two of the roles in a trade. Its definition is as
  follows.

<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Exchange Block within the IOTP
                   Transaction.

  Content:

PaySchemeData      This Trading Component contains payment scheme
                   specific data see section 6.9 Payment Scheme
                   Component.

7.8 Payment Response Block

  This Payment Response Block contains a information about the Payment
  Status, a Payment Receipt, and an optional payment protocol message.
  Its definition is as follows.

<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Response Block within the IOTP
                   Transaction.

  Content:

Status             Contains status information about the business
                   success (see section 4.2) or failure of the
                   payment. Note that in a Pay Response Block, a
                   ProcessState of NotYetStarted or InProgress are
                   illegal values.

PayReceipt         Contains payment scheme specific data which can be
                   used to verify the payment occurred. See section
                   6.10 Payment Receipt Component.

PaySchemeData      Contains payment scheme specific data see section,
                   for example a payment protocol message. See 6.9
                   Payment Scheme Component.

PaymentNote        Contains additional, non payment related,
                   information which the Payment Handler wants to
                   provide to the Consumer. For example, if a
                   withdrawal or deposit were being made then it
                   could contain information on the remaining balance
                   on the account after the transfer was complete.
                   See section 6.11 Payment Note Component.

TradingRoleData    The Trading Role Data Component contains opaque
                   data which is needs to be communicated between the
                   Trading Roles involved in an OTP Transaction (see
                   section 6.16).

7.9 Delivery Request Block

  The Delivery Request Block contains details of the goods or services
  which are to be delivered together with a signature which can be used
  to check that delivery is authorised. Its definition is as follows.

<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
     TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Delivery Request Block within the IOTP
                   Transaction.

  Content:

Status             Contains the Status Components (see section 6.12)
                   of the responses of the steps (e.g. a Payment
                   Response) on which this step is dependent. It is
                   used to indicate the success or failure of those
                   steps. Delivery should only occur of the previous
                   steps were successful.

Order              The Order Component contains details about the
                   goods, services or financial transaction which is
                   taking place see section 6.4.

Org                The Organisation Components (see section 6.5)
                   identify the organisations and their roles in the
                   IOTP Transaction. The roles and organisations
                   which must be present will depend on the
                   particular type of IOTP Transaction. See the
                   definition of each transaction in section 8. Open
                   Trading Protocol Transactions.

Delivery           The Delivery Component contains details of the
                   delivery to be made (see section 6.12).

TradingRoleData    The Trading Role Data Component contains opaque
                   data which is needs to be communicated between the
                   Trading Roles involved in an OTP Transaction (see
                   section 6.16).

  The Delivery Request Block contains:
  o  the Organisation Component with a Trading Role of Merchant
  o  the Organisation Component for the Consumer and DeliverTo
     Trading Roles
  o  the Delivery Component for the Delivery
  o  the Organisation Component for the Delivery Handler.
     Specifically the Organisation Component identified by the
     ActionOrgRef attribute on the Delivery Component
  o  the Organisation Component (if any) for the Organisation which
     carried out the previous step, for example a Payment Handler
  o  the Organisation Components for any additional Organisations
     that the Merchant has included in the Offer Response Block
  o  any Trading Role Data Components that may be required (see
     section 6.16.1).

7.10 Delivery Response Block

  The Delivery Response Block contains a Delivery Note containing
  details on how the goods will be delivered. Its definition is as
  follows. Note that in a Delivery Response Block a Delivery Status
  Element with a DeliveryStatusCode of NotYetStarted or InProgress is
  invalid.

<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Delivery Response Block within the IOTP
                   Transaction.

  Content:

Status             Contains status information about the business
                   success (see section 4.2) or failure of the
                   delivery.  Note that in a Delivery Response Block,
                   a ProcessState of NotYetStarted or InProgress are
                   illegal values.

DeliveryNote       The Delivery Note Component contains details about
                   how the goods or services will be delivered (see
                   section 6.13).

7.11 Payment Instrument Customer Care Request Block

  The Payment Instrument Customer Care Request Block contains
  information which requests that an IOTP Payment Instrument Customer
  Care Transaction is started in order to provide Customer Care for the
  Consumer's Payment Instrument. Its definition is as follows.

<!ELEMENT PayInstCCReqBlk (PaymethodInfo, PaySchemeData*) >
<!ATTLIST PayInstCCReqBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Instrument Customer Care Request Block
                   within the IOTP Transaction.

  Content:

PayMethodInfo      The Payment Method Information Component (see
                   section 6.14) contains data which describes the
                   Payment Method which initiated the Payment
                   Instrument Customer Care Transaction

PaySchemeData      Optional Payment Scheme Components (see section
                   6.9) that contain payment scheme specific data.
                   The sequence of the Payment Scheme Components in
                   the Block is the sequence in which they should be
                   processed by the Payment Scheme software which
                   receives this message.

7.12 Payment Instrument Customer Care Exchange Block

  The Payment Instrument Customer Care Exchange Block contains payment
  scheme specific data which is exchanged between the Payment Instrument
  User and the Payment Scheme Customer Care Provider. Its definition is
  as follows.

<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Instrument Customer Care Exchange Block
                   within the IOTP Transaction.

  Content:

PaySchemeData      Optional Payment Scheme Components (see section
                   6.9) that contain payment scheme specific data.
                   The sequence of the Payment Scheme Components in
                   the Block is the sequence in which they should be
                   processed by the Payment Scheme software which
                   receives this message.

7.13 Payment Instrument Customer Care Response Block

  The Payment Instrument Customer Care Response Block contains the final
  Payment Scheme Component of the IOTP Payment Instrument Customer Care
  Transaction. Its definition is as follows.

<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Payment Instrument Customer Care Response Block
                   within the IOTP Transaction.

  Content:

PaySchemeData      Optional Payment Scheme Components (see section
                   6.9) that contain payment scheme specific data.
                   The sequence of the Payment Scheme Components in
                   the Block is the sequence in which they should be
                   processed by the Payment Scheme software which
                   receives this message.

7.14 Inquiry Request Trading Block

  The Inquiry Request Trading Block contains an Inquiry Type Component
  and an optional Payment Scheme Component to contain payment scheme
  specific inquiry messages.

<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Inquiry Request Trading Block within the IOTP
                   Transaction.

  Content:

InquiryType        Inquiry Type Component (see section 6.17) that
                   contains the type of inquiry.

PaySchemeData      Payment Scheme Component (see section 6.9) that
                   contains payment scheme specific inquiry messages
                   for inquiries on payments. This is present when
                   the Type attribute of Inquiry Type Component is
                   Payment.

7.15 Inquiry Response Trading Block

  The Inquiry Response Trading Block contains a Status Component and an
  optional Payment Scheme Component to contain payment scheme specific
  inquiry messages. Its purpose is to enquire on the current status of
  an IOTP transaction at a server.

<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
  ID ID          #REQUIRED
  LastReceivedOtpMsgRef NMTOKEN  #IMPLIED
  LastSentOtpMsgRef      NMTOKEN #IMPLIED >

  Attributes:

ID                     An identifier which uniquely identifies the
                       Inquiry Response Trading Block within the IOTP
                       Transaction.

LastReceivedOtpMsgRef  Contains an Element Reference (see section
                       3.5) to the Message Id Component (see section
                       3.3.2) of the last message this server has
                       received from the Consumer. If there is no
                       previously received message from the Consumer
                       in the pertinent transaction, this attribute
                       should be contain the value Null. This
                       attribute exists for debugging purposes.

LastSentOtpMsgRef      Contains an Element Reference (see section
                       3.5) to the Message Id Component (see section
                       3.3.2) of the last message this server has
                       sent to the Consumer. If there is no
                       previously sent message to the Consumer in the
                       pertinent transaction, this attribute should
                       contain the value Null. This attribute exists
                       for debugging purposes.

  Content:

Status             Contains status information about the business
                   success (see section 4.2) or failure of a certain
                   trading exchange (i.e., Offer, Payment, or
                   Delivery).

PaySchemeData      Payment Scheme Component (see section 6.9) that
                   contains payment scheme specific inquiry messages
                   for inquiries on payments. This is present when
                   the Type attribute of StatusType attribute of the
                   Status Component is set to Payment.

7.16 Ping Request Block

  The Ping Request Block is used to determine if a Server is operating
  and whether or not cryptography is compatible.

  The definition of a Ping Request Block is as follows.

<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
  ID ID          #REQUIRED>

  Attributes:

ID                 An identifier which uniquely identifies the Ping
                   Request Trading Block within the IOTP Transaction.

  Content:

Org                Optional Organisation Components (see section
                   6.5).

                   If no Organisation Component is present then the
                   Ping Request is anonymous and simply determines if
                   the server is operating.

                   However if Organisation Components are present,
                   then it indicates that the sender of the Ping
                   Request wants to verify that digital signatures
                   can be handled.

                   In this case the sender includes:
                   o  an Organisation Component that identifies
                      itself specifying the Trading Role(s) it is
                      taking in IOTP transactions (Merchant, Payment
                      Handler, etc)
                   o  an Organisation Component that identifies the
                      intended recipient of the message.

                   These are then used to generate a signature over
                   the Ping Response Block.

7.17 Ping Response Block

  The Ping Response Trading Block provides the result of a Ping Request.

  It contains an Organisation Component that identifies the sender of
  the Ping Response.

  If the Ping Request to which this block is a response contained
  Organisation Components, then it also contains those Organisation
  Components.

<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
  ID ID          #REQUIRED
  PingStatusCode (Ok|Busy|Down) #REQUIRED
  SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
  xml:lang       NMTOKEN #IMPLIED
  PingStatusDesc CDATA   #IMPLIED>

  Attributes:

ID                   An identifier which uniquely identifies the Ping
                     Request Trading Block within the IOTP
                     Transaction.

PingStatusCode       Contains a code which shows the status of the
                     sender software which processes IOTP messages.
                     Valid values are:
                     o  Ok. Everything with the service is working
                       normally, including the signature
                       verification.
                     o  Busy. Things are working normally but there
                       may be some delays.
                     o  Down. The server is not functioning fully but
                       can still provide a Ping response.

SigVerifyStatusCode  Contains a code which shows the status of
                     signature verification. This is present only
                     when the message containing the Ping Request
                     Block also contains a Signature Block. Valid
                     values are:
                     o  Ok. The signature has successfully been
                       verified and proved compatible.
                     o  NotSupported The receiver of this Ping Request
                       Block does not support validation of
                       signatures.
                     o  Fail. Signature verification failed.

Xml:lang             Defines the language used in PingStatusDesc.
                     This is present when PingStatusDesc is present.

PingStatusDesc       Contains a short description of the status of
                     the server which sends this Ping Response Block.
                     Servers, if their designers want, can use this
                     attribute to send more refined status
                     information than PingStatusCode which can be
                     used for debugging purposes, for example.

  Content:

Org                These are Organisation Components (see section
                   6.5).

                   The Organisation Components of the sender of the
                   Ping Response is always included in addition to
                   the Organisation Components sent in the Ping
                   Request.

  [Note]   Ping Status Code values do not include a value such as Fail,
           since, when the software receiving the Ping Request message
           is not working at all, no Ping Response message will be sent
           back.
  [Note End]

7.18 Signature Block

  The Signature Block contains one or more Signature Components and
  associated Certificates which sign data associated with the IOTP
  Transaction. For a general discussion and introduction to how IOTP
  uses signatures, see section 5 Security Considerations. The definition
  of the Signature Component and certificates is contained in the paper
  "Digital Signature for XML - Proposal", see [XMLSIG].

  The definition of a Signature Block is as follows:

<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
  ID ID          #REQUIRED >

  Attributes:

ID                 An identifier which uniquely identifies the
                   Signature Block within the IOTP Transaction.

  Content:

OtpSig             Contains a Digital Signature. See the paper
                   "Digital Signature for XML - Proposal" [XMLSIG],
                   for its definition

OtpCert            Contains a Digital Certificate. See the paper
                   "Digital Signature for XML - Proposal" [XMLSIG],
                   for its definition

  The contents of a Signature Block depends on the Trading Block that is
  contained in the same IOTP Message as the Signature Block.

7.18.1 Offer Response

  A Signature Block which is in the same message as an Offer Response
  Block contains just an Offer Response Signature Component (see section
  6.18.1).

7.18.2 Payment Request

  A Signature Block which is in the same message as a Payment Request
  Block contains:
  o  an Offer Response Signature Component (see section 6.18.1),
     and
  o  if the Payment is dependent on an earlier step (as indicated
     by the StartAfter attribute on the Payment Component), then
     the Payment Receipt Signature Component (see section 6.18.2)
     generated by the previous step

7.18.3 Payment Response

  A Signature Block which is in the same message as a Payment Response
  Block contains just a Payment Receipt Signature Component (see section
  6.18.2) generated by the step.

7.18.4 Delivery Request

  A Signature Block which is in the same message as a Delivery Request
  Block contains:

  o  an Offer Response Signature Component (see section 6.18.1),
     and
  o  the Payment Receipt Signature Component (see section 6.18.2)
     generated by the previous step.

7.19 Error Block

  The Error Trading Block contains one or more Error Components (see
  section 6.19) which contain information about Technical Errors (see
  section 4.1) in an IOTP Message which has been received by one of the
  Trading Roles involved in the trade.

  For clarity two phrases are defined which are used in the description
  of an Error Trading Block:
  o  message in error. An IOTP message which contains or causes an
     error of some kind
  o  message reporting the error. An IOTP message that contains an
     Error Trading Block that describes the error found in a
     message in error.

  An Error Trading Block may be contained in any message reporting the
  error. The action which then follows depends on the severity of the
  error. See the definition of an Error Component, for an explanation of
  the different types of severity and the actions which can then occur.

  [Note]   Although, an Error Trading Block can report multiple
           different errors using multiple Error Components, there is
           no obligation on a developer of an IOTP Aware Application to
           do so.
  [Note End]

  The structure of an Error Trading Block is as follows.

<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
  ID ID          #REQUIRED >

  Attributes:

ID             An identifier which uniquely identifies the Error
               Trading Block within the IOTP Transaction.

  Content:

ErrorComp       An Error Component (see section 6.19) that
                contains information about an individual
                Technical Error.

PaySchemeData   An optional Payment Scheme Component (see section
                6.9) which contains a Payment Scheme Message. See
                the appropriate payment scheme supplement to
                determine whether or not this component needs to
                be present and for the definition of what it must
                contain.

8. Open Trading Protocol Transactions

  The Baseline Open Trading Protocol supports the following types of
  Baseline IOTP Transactions:
  o  Authentication
  o  Deposit
  o  Purchase
  o  Refund
  o  Withdrawal
  o  Baseline Value Exchange
  o  Payment Instrument Customer Care
  o  Transaction Status Inquiry, and
  o  Ping

  Each of these transactions are described in more detail in the
  following sections providing descriptions of:
  o  the Trading Blocks in each IOTP Transaction
  o  the Trading Components in each Trading Block, and
  o  how the Trading Components are signed

  [Note]   There are many similarities between the transactions within
           IOTP. This is because there is a lot of reuse of the Trading
           Blocks between the different transactions.

           This means that there should be significant opportunity for
           software re-use. For example, from an IOTP perspective, the
           Deposit, Refund and Withdrawal transactions are essentially
           the same, although the processing which will occur,
           especially at the server end, will differ.
  [Note End]

8.1 Baseline Authentication IOTP Transaction

  In a Baseline Authentication IOTP Transaction:
  o  the Authenticator is the organisation which is requesting the
     authentication, and
  o  the Authenticatee is the organisation being authenticated.

  A Baseline Authentication IOTP Transaction may occur at any time
  between any of the Trading Roles involved in OTP Transactions. This
  means it could occur:
  o  before another IOTP Transaction
  o  at the same time as another IOTP Transaction
  o  independently of any other IOTP Transaction.

  The authentication consists of:
  o  an Authentication Request being sent by the Authenticator to
     the Authenticatee, and
  o  an Authentication Response being sent in return by the
     Authenticatee to the Authenticator which is then checked.

  A Baseline Authentication IOTP Transaction also:
  o  provides an Authenticatee with an Organisation Component which
     describes the Authenticator, and
  o  optionally provides the Authenticator with Organisation
     Components which describe the Authenticatee

  The Authentication Request may also be digitally signed which allows
  the Authenticatee to verify the credentials of the organisation which
  requesting the authentication.

  An Authenticatee may decline to be authenticated by sending setting
  the CompletionCode of the Status Component in the Authentication
  Response Block to Declined.

  Example uses of the Baseline Authentication IOTP Transaction include:
  o  when the Baseline Authentication IOTP Transaction takes place
     as an early part of a session where strong continuity exists.
     For example, a Financial Institution could:
     - set up a secure channel (e.g. using SSL) with a customer
     - authenticate the customer using the Baseline Authentication IOTP
       Transaction, and then
     - provide the customer with access to account information and
       other services with the confidence that they are communicating
       with a bona fide customer.
  o  as a means of providing a Merchant role with Organisation
     Components that contain information about Consumer and DelivTo
     Trading Roles
  o  so that a Consumer may authenticate a Payment Handler before
     starting a payment.

  The Baseline Authentication IOTP Transaction consists of just the
  Authentication Trading Exchange (see section 2.2.4).

  The Trading Blocks used by the Baseline Authentication IOTP
  Transaction are:
  o  Trading Protocol Options Block
  o  Signature Block
  o  Authentication Request Block, and
  o  Authentication Response Block

  There are no variations of the Baseline Authentication IOTP
  Transaction.

  The IOTP Messages used in a Baseline Authentication are illustrated in
  the diagram below.

    ORGANISATION 1            OTP MESSAGE           ORGANISATION 2

1. First organisation                               2. The second
takes an action (for                           organisation generates
example by pressing a  --------------------->    an  Authentication
  button on an HTML     Authentication Need         Request Block
page) which requires   (outside scope of OTP)   containing challenge
that the organisation                          data and the method of
  is authenticated                              authentication to be
                                                used then sends it to
                                               the first organisation
                                                          |
                                                          v
  3. OTP aware application                              OTPMsg:Trans
started. If a Signature Block  <--------------------     Ref Block;
    is present the first               TPO &              Signature
organisation may use this to       Authentication        Block; TPO
check the credentials of the          Request           Block; Auth.
second organisation. If it is                          Response Block;
  OK the first organisation
 uses the challenge data and
  the authentication method
      specified in the
Authentication Request Block
to generate an Authentication
Response Block which is sent
      back to the first
  organisation. Optionally
  keeps information on OTP
   Transaction for record
 keeping purposes and stops
       |
       v
 OTPMsg: Trans                             4. The second organisation
  Ref Block;     ---------------------->   checks the Authentication
   Signature     Authentication Response      Response against the
  Block; Auth                                challenge data in the
Response Block                            Authentication Request Block
       |                                    to check that the first
       v                                    organisation is who they
     STOP                                   appear to be, and stops.
                                                       |
                                                       v
                                                      STOP

  Figure 19 Baseline Authentication

  The remainder of this sub-section on the Baseline Authentication IOTP
  Transaction defines the contents of each Trading Block.

8.1.1 Trading Protocol Options Block

  The TPO (Trading Protocol Options) Block (see section 7.1) must
  contain the following Trading Component:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.

8.1.2 Authentication Request Block

  The Authentication Request Block (see section 7.4) must contain the
  following Trading Component:
  o  one Authentication Data Component (see section 6.2)
  o  one Organisation Component (see section 6.5) which describes
     the Authenticator

8.1.3 Signature Block (Authentication Request)

  If the Authentication Request is being digitally signed then a
  Signature Block must be included in the same IOTP message that
  contains an Authentication Request Block. The Signature Component
  contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Authentication
     Request Block within the IOTP Transaction. It contains
     information that identifies the IOTP Message and IOTP
     Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the TPO Block :
     - the Protocol Options Component
  o  the following components of the Authentication Request Block:
     - the Authentication Data Component

8.1.4 Authentication Response Block

  The Authentication Response Block (see section 7.5) must contain the
  following Trading Component:
  o  one Authentication Response Component (see section 6.3)
  o  one Organisation Component for every Trading Role identified
     in the TradingRoleList attribute of the Authentication Data
     Component contained in the Authentication Request Block.

8.1.5 Signature Block (Authentication Response)

  If the AuthMethod attribute of the Authentication Data Component
  contained in the Authentication Request Block indicates that the
  Authentication Response should consist of a digital signature then a
  Signature Block must be included in the same IOTP message that
  contains an Authentication Response Block. The Signature Component
  contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Authentication
     Request Block within the IOTP Transaction. It contains
     information that identifies the IOTP Message and IOTP
     Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Authentication Request Block:
     - the Authentication Data Component
  o  the Organisation Components contained in the Authentication
     Response Block

  [Note]   It should not be assumed that all trading roles can support
           the signing of data. Particularly it should not be assumed
           that Consumers support the signing of data.
  [Note End]

8.2 Baseline Deposit IOTP Transaction

  The Baseline Deposit IOTP Transaction supports the deposit of
  electronic cash with a Financial Institution.

  [Note]   The Financial Institution has, in IOTP terminology, a role
           of merchant in that a service (i.e. a deposit of electronic
           cash) is being offered in return for a fee, for example bank
           charges of some kind. The term "Financial Institution" is
           used in the diagrams and in the text for clarity.
  [Note End]

  The Baseline Deposit IOTP Transaction consists of the following
  Trading Exchanges:
  o   an optional Authentication Exchange (see section 2.2.4),
  o  an Offer Exchange (see section 2.2.1), and
  o  a Payment Exchange (see section 2.2.2).

  These Trading Exchanges are implemented by a set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each IOTP Message contains Trading Blocks (see
  section 7) which contain the Trading Components (see section 6) which
  are required by the Trading Exchanges.

  The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Authentication Request Block
  o  Authentication Response Block
  o  Offer Response Block
  o  Payment Request Block
  o  Payment Exchange Block
  o  Payment Response Block
  o  Signature Block

8.2.1 Baseline Deposit Variations

  The Baseline Deposit IOTP Transaction occurs in two basic forms:
  o  Baseline Deposit with Authentication. Where the Consumer
     making the deposit is authenticated before the deposit is
     made, and
  o  Baseline Deposit without Authentication. Where the Consumer is
     not authenticated before the deposit is made.

  In both these forms it is assumed that the Payment Brand being used is
  determined before the Baseline Deposit transaction starts. This means
  that Brand Selection is limited to Payment Protocol selection only.

8.2.2 Baseline Deposit Authentication

  In Baseline Deposit with Authentication an Authentication Exchange
  occurs before the Offer Exchange containing the details of the deposit
  is provided by the Financial Institution.

  In Baseline Deposit without Authentication, there is no Authentication
  Exchange and the Financial Institution provides details about the
  deposit immediately at the start of the IOTP Transaction.

  These two alternatives are illustrated in the two diagrams below. The
  first diagram illustrates the case when an Authentication Exchange is
  included.

       CONSUMER               OTP MESSAGE       FINANCIAL INSTITUTION
1. Consumer decides                              2. The Financial
     to deposit                                Institution sets the
electronic cash and   --------------------  payment brand and decides
 sends information             >            which protocols to offer,
 about how much to    Deposit Information          generates an
 deposit, the brand    (outside scope of      Authentication Request
 to be used, etc to           OTP)          Block containing challenge
   the Financial                              data and the method of
 Institution, e.g.                           authentication and sends
     using HTML                                  to the Consumer
                                                                |
                                                                v
3. OTP aware application started.                         OTPMsg:Tran
The consumer selects the payment  <---------------------      s Ref
    protocol to use, records               TPO &           Block; TPO
 selection in a Brand Selection   Authentication Request     Block;
     Component, generates an                              Auth.Respon
Authentication Response Component                           se Block
 and sends back to the Financial
          Institution.

       |
       v
 OTPMsg: Trans                           4. The Financial Institution
Ref Block; Auth  -------------------->    checks the Authentication
Response Block;    TPO Selection  &     Response against the challenge
 TPO Selection      Authentication        data in the Authentication
                       Response            Request Block, uses the
                                         information to identify the
                                         consumer, generates an Offer
                                          Response Block containing
                                        information about the deposit,
                                         and optional Signature Block
                                          and sends to the Consumer
                                                               |
                                                               v
  5. Consumer checks Offer is OK,                        OTPMsg: Trans
  combines components from the TPO                        Ref Block;
 Block, the TPO Selection Block and  <----------------     Signature
the Offer Response Block to create a   Offer Response    Block; Offer
 Pay Request Block and sends to the                     Response Block
 Payment Handler with the Signature
          Block if present
                |                  Note that the Financial Institution
                v                  has, in OTP terminology, a role of
            CONTINUED                          "Merchant".

  Figure 20 Baseline Deposit with Authentication

  Note that the above diagram:
  o  describes the general case where a Merchant can accept a
     deposit in several different types of electronic cash. In
     practice usually only one form of electronic cash may be
     accepted. However, there may be several different protocols
     which may be used for the same "brand" of electronic cash.
  o  the financial institution may use the results of the
     authentication to identify not only the consumer but also the
     account to which the payment is to be deposited. If no single
     account can be identified, then it must be obtained by other
     means. For example:
     - the consumer could specify the account number in the initial
       dialogue (see step 1), or
     - the consumer could have been identified earlier, for example
       using a Baseline Authentication IOTP Transaction, and an account
       selected from a list provided by the Financial Institution.

  The second diagram illustrates the case when an Authentication
  Exchange is not included.

      CONSUMER            OTP MESSAGE         FINANCIAL INSTITUTION
 1. Consumer decides                         2. Financial Institution
to deposit electronic                       sets the payment brand and
   cash and sends     ------------------>   decides which protocols to

information about how Deposit Information   offer, generates an Offer
much to deposit, the   (outside scope of    Response Block containing
brand to use, etc to          OTP)            information about the
    the Financial                              deposit, an optional
  Institution, e.g.                         Signature Block and sends
     using HTML                                  to the Consumer
                                                               |
                                                               v
   3. OTP aware application started.                     OTPMsg:Trans
Consumer selects the payment protocol to  <------------   Ref Block;
   use, records selection in a Brand          TPO &        Signature
  Selection Component, checks Offer is        Offer       Block; TPO
    OK, combines the Brand Selection        Response     Block; Offer
Component with information from the TPO                    Response
Block and Offer Response Block to create                     Block
a Pay Request Block and sends it to the
 Payment Handler together with optional
            Signature Block
             |
             v                Note that the Financial Institution has,
         CONTINUED           in OTP terminology, a role of "Merchant".

  Figure 21 Baseline Deposit without Authentication

  The Baseline Deposit without authentication might be used:
  o  if a previous IOTP transaction, for example a Baseline
     Withdrawal or a Baseline Authentication, authenticated the
     consumer, and a secure channel has been maintained, therefore
     the authenticity of the consumer is known
  o  if authentication is achieved as part of a proprietary payment
     protocol and is therefore included in the Payment Exchange
  o  if authentication of the consumer has been achieved by some
     other means outside of the scope of IOTP, for example, by
     using a pass phrase.

  IOTP aware applications supporting the Consumer Trading Role must
  check for the existence of an Authentication Request Block in the
  first IOTP Message to determine whether the Baseline Deposit includes
  an Authentication Exchange or not.

8.2.3 Baseline Deposit Payment Messages

  Once the Offer Response Trading Block has been received, the sequence
  of IOTP Messages illustrated in Figure 22 occurs. These are the same
  whether or not an Authentication of the Consumer has occurred. Note
  that these continue where the previous diagrams (Figure 20 and Figure
  21) finish.

        CONSUMER              OTP MESSAGE          PAYMENT HANDLER
   3/5. Consumer generates Pay
  Request Block encapsulating a
   payment protocol message if
  required and sends to Payment
 Handler with the Signature Block
            if present
                |
                v
 OtpMsg: Trans                6. Payment Handler processes Pay Request
  Ref Block;     ---------->    Block, checks optional signature and
   Signature       Payment       starts exchanging payment protocol
  Block; Pay       Request    messages, encapsulated in a Pay Exchange
 Request Block                        Block, with the Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref    <-----------------> Ref Block; Pay
Exchange Blocks with   Block; Pay    Payment Exchange   Exchange Block
  Payment Handler    Exchange Block
                                                            |
                                                            v
                               8. Eventually payment protocol messages
                                finish so Payment Handler creates Pay
                               Receipt Component inside a Pay Response
                                   Block, and an optional Signature
                                Component inside the Signature Block,
                                     sends to Consumer and stops
                                                        |
                                                        v
  9. Consumer checks Pay                     OtpMsg: Trans Ref Block;
Response is OK. Optionally  <-------------     Signature Block; Pay
 keeps information on OTP      Payment            Response Block
  Transaction for record       Response                 |
keeping purposes and stops                              v
            |                                          STOP
            v
           STOP

  Figure 22 Baseline Deposit Payment Messages

  The remainder of this sub-section on the Baseline Deposit IOTP
  Transaction defines the contents of each Trading Block. For most
  Trading Blocks, the content does not alter with the variations
  described above. Where differences apply, these are stated.

8.2.4 TPO (Trading Protocol Options) Block

  The TPO (Trading Protocol Options) Block (see section 8.3.2) must
  contain the following Trading Components:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.

  o  one Brand List Component (see section 6.6) which contains the
     payment brand and protocols which may be selected for use in
     the Payment Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - the Merchant who is accepting the deposit
     - the Consumer who is making the deposit
     - the PaymentHandlers for the payment

8.2.5 TPO Selection Block

  The TPO Selection Block (see section 7.2) is only used by Baseline
  Deposit with Authentication. It contains:
  o  one Brand Selection Component (see section 6.7) for use in the
     Payment Exchange. It contains the results of the consumer
     selecting a Payment Brand and Payment Protocol from the list
     provided in the Brand List Component.

8.2.6 Authentication Request Block

  The Authentication Request Block (see section 7.4) must contain the
  following Trading Component:
  o  one Authentication Data Component (see section 6.2)

8.2.7 Authentication Response Block

  The Authentication Response Block (see section 7.5) must contain the
  following Trading Component:
  o  one Authentication Response Component (see section 6.3).

8.2.8 Offer Response Block

  The Offer Response Block (see section 7.3) must contain the following
  components:
  o  zero or one Authentication Data Component (see section 6.2) An
     Authentication Data Component is required for each Payment
     Exchange, where its Payment Component contains an AuthDataRef
     attribute
  o  one Order Component (see section 6.4) which contains details
     about the deposit, for example the amount of value being
     deposited and any fees which might apply
  o  one Payment Component (see section 6.8) which contains
     information about the payment which is to be made
  o  one Delivery Component (see section 6.12) with the DelivExch
     attribute set to False

  The Offer Response Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  [Note]   A role of Merchant is used in the above description since a
           service (i.e. a deposit of electronic cash) is being offered
           in return for a fee, for example bank charges of some kind.
           The term "Financial Institution" is used in the diagrams and
           in the text for clarity.
  [Note End]

8.2.9 Signature Block (Offer Response)

  If the Baseline Deposit Offer Response is being digitally signed then
  a Signature Block must be included in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18).
  The Signature Component contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message and IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the Payment Component
     - all the Organisation Components present, and
     - the Delivery Component
     - any Trading Role Data Components
  o  the following components of the TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Deposit is a Baseline Deposit with Authentication then
  the Signature Component additionally contains a hash of the following:
  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.2.10 Payment Request Block

  The Payment Request Block (see section 7.6) contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component if present
     - the Payment Component
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler
  o  the  following component from the TPO Block:
     - the Brand List Component
  o  one Brand Selection Component either:
     - copied from the Offer Response Block if the deposit is a
       Baseline Deposit with Authentication, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the deposit is a Baseline Deposit
       without Authentication
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Payment Handlers should check that they are authorised to carry out
  the Payment (see section 5 Security Considerations).

8.2.11 Signature Block (Payment Request)

  If the Baseline Deposit Offer Response Block was signed then the IOTP
  Message that contains the Payment Request Block must also contain a
  Signature Block with a copy of the "Offer Response" Signature
  Component.

8.2.12 Payment Exchange Block

  The Payment Exchange Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain.

8.2.13 Payment Response Block

  The Payment Response Block (see section 7.8) contains:
  o  one Payment Receipt Component(see section 6.10) which contains
     scheme specific data which can be used to verify the payment
     occurred
  o  one Payment Scheme Component (see section 6.9) if required
     which contains payment method specific data. See the Payment
     Method supplement for the payment method being used to
     determine what this should contain
  o  the "Offer Response" Signature Component (see section 6.18)
     from the Payment Request Block if present.

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.2.14 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component of the Offer
  Response Block being set to True, then the IOTP Message that contains
  the Payment Response Block must also contain a Signature Block with a
  "Payment Receipt" Signature Component which contains hashes of the
  following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block,
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block,
  o  any Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from the Payment
     Request Block if present.

8.3 Baseline Purchase IOTP Transaction

  The Baseline Purchase IOTP Transaction supports the purchase of goods
  or services using any payment method. It consists of the following
  Trading Exchanges:
  o  an Offer Exchange (see section 2.2.1),
  o  a Payment Exchange (see section 2.2.2), and
  o  an optional Delivery Exchange (see section 2.2.3)

  These Trading Exchanges are implemented by a set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each IOTP Message contains Trading Blocks (see
  section 7) which contain the Trading Components (see section 6) which
  are required by the Trading Exchanges.

  The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Offer Response Block
  o  Payment Request Block
  o  Payment Exchange Block
  o  Payment Response Block
  o  Delivery Request Block
  o  Delivery Response Block
  o  Signature Block

8.3.1 Baseline Purchase Variations

  The Baseline Purchase IOTP Transaction occurs in two basic forms:
  o  Brand Dependent Purchase. Where the content of the offer, e.g.
     the order details, amount, delivery details, etc., are
     dependent on the payment brand and protocol selected by the
     consumer, and
  o  Brand Independent Purchase. Where the content of the offer is
     not dependent on the payment brand and protocol selected.

  Further variation is supported in that:
  o  the Delivery Exchange is optional, and
  o  the Delivery Response Block may be sent to the consumer
     either:
     - at the same time as the Payment Response Block, or
     - after the Payment Response Block as the result of the Consumer
       sending the Delivery Handler a Delivery Request Block.

8.3.1.1 Brand Dependent Purchases

  In a Brand Dependent Purchase the TPO Block and the Offer Response
  Block are sent separately by the Merchant to the Consumer, i.e.:
  o  the Brand List Component is sent to the Consumer in a TPO
     Block,
  o  the Consumer selects a Payment Brand, Payment Protocol and
     optionally a Currency and amount from the Brand List Component
  o  the Consumer sends the selected brand, protocol and
     currency/amount back to the Merchant in a TPO Selection Block,
     and
  o  the Merchant uses the information received to define the
     content of and then send the Offer Response Block to the
     Consumer.

  In a Brand Independent Purchase the TPO Block and the Offer Response
  Block are sent together by the Merchant to the Consumer in the same
  IOTP Message at the start of the IOTP Transaction.

  These two alternatives are illustrated in the two diagrams below. The
  first diagram illustrates a Brand Dependent Purchase.

       CONSUMER                OTP MESSAGE              MERCHANT
1. Consumer decides                          2. Merchant decides which
 to trade and sends                              payment brand and
 information about    --------------------> protocols to offer, places
what to purchase to   Purchase Information     them in a Brand List
 the Merchant, e.g.     (outside scope of    Component in a TPO Block,
     using HTML               OTP)             and sends to Consumer
                                                                |
                                                                v
3. OTP aware application started. Consumer                   OTPMsg:
   selects the payment brand and payment    <-----------    Trans Ref
  protocol to use, records selection in a        TPO       Block; TPO
 Brand Selection Component, and sends back                    Block
                to Merchant
      |
      v
 OTPMsg:Trans                     4. Merchant uses payment brand and
Ref Block; TPO  ------------>    protocol selected and information on
  Selection     TPO Selection    what is being purchased to create an
    Block                      Offer Response Block containing details
                                   about goods ordered, price, etc.
                                   optionally signs it and sends to
                                               Consumer
                                                              |
                                                              v
  5. Consumer checks Offer is OK,                       OTPMsg:Trans
 combines components from the TPO    <---------------    Ref Block;
Block, the TPO Selection Block and    Offer Response      Signature
the Offer Response Block to create                      Block; Offer
a Pay Request Block and sends it to                    Response Block
 the Payment Handler together with
  the Signature Block if present
                 |
                 v
             CONTINUED

  Figure 23 Brand Dependent Baseline Purchase

  The second diagram illustrates the Brand Independent Purchase.

       CONSUMER                OTP MESSAGE              MERCHANT
  1. Consumer                             2. Merchant decides which
  decides to                            payment brand and protocols to
trade and sends  -------------------->  offer, places them in a Brand
  information    Purchase Information   List Component in a TPO Block,
 about what to     (outside scope of      creates an Offer Response
purchase to the          OTP)           Block containing details about
Merchant, e.g.                            goods ordered, price, etc,
  using HTML                            optionally signs it and sends
                                                 to Consumer
                                                           |
                                                           v
    3. OTP aware application                       OTPMsg: Trans Ref
 started. Consumer selects the    <-------------    Block; Signature
   payment brand and payment          TPO &        Block; TPO Block;
    protocol to use, records      Offer Response  Offer Response Block
 selection in a Brand Selection
 Component, checks Offer is OK,
  combines the Brand Selection
Component with information from
the TPO Block and Offer Response
 Block to create a Pay Request
   Block and sends it to the
 Payment Handler together with
 the Signature Block if present
               |
               v
           CONTINUED
  Figure 24 Brand Independent Baseline Purchase

  A Brand Independent Purchase always occurs when only one payment brand
  and protocol is being offered to the Consumer by the Merchant. It is
  also likely to, but will not necessarily, occur when multiple brands
  are being offered, the Payment Handler is the same, and all brands use
  the same set of protocols.

  Note that the TPO Block and the Offer Response Block may be sent in
  separate IOTP messages even if the Offer Response Block does not
  change. However this increases the number of messages in the
  transaction and is therefore likely to increase transaction response
  times.

  IOTP aware applications supporting the Consumer Trading Role must
  check for the existence of an Offer Response Block in the first IOTP
  Message to determine whether the Baseline Purchase is brand dependent
  or not.

8.3.1.2 Combining Delivery Response Block and Payment Response Block

  The Delivery Response Block and the Payment Response Block may be
  sent:
  o  separately by the Payment Handler to the Consumer, i.e.:
     - the Payment Response Block containing a Payment Receipt and
       optional signature for the payment is sent by the Payment
       Handler to the Consumer,
     - the Consumer combines these components from the Payment Response
       Block with components from the Offer Response Block, to create a
       Delivery Request Block
     - the Consumer sends the Delivery Request Block to the Delivery
       Handler
     - the Delivery Handler processes the Delivery Request Block and
       sends a Delivery Response Block back to the Consumer, or
  o  together, from the Payment Handler to the Consumer, when the
     Payment Exchange is complete.

  These two alternatives are illustrated in the two diagrams below.

  The first diagram illustrates when the Delivery Response Block and the
  Payment Response Block are sent to the Consumer in separate IOTP
  Messages. Note, these diagrams continue where the previous diagrams
  (Figure 23 and Figure 24) finish.

       CONSUMER               OTP MESSAGE          PAYMENT HANDLER
3/5. Consumer generates Pay Request
   Block encapsulating a payment
 protocol message if required and
     sends to Payment Handler
                 |
                 v
tpMsg: Trans Ref                   6. Payment Handler checks optional
Block; Signature  ------------->    signature, processes Pay Request
   Block; Pay         Payment     Block, and starts exchanging payment
 Request Block        Request     protocol messages, encapsulated in a
                                      Pay Exchange Block, with the
                                                Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref   <----------------->  Ref Block; Pay
xchange Blocks with   Block; Pay     Payment Exchange   Exchange Block
  Payment Handler   Exchange Block
                                                             |
                                                             v
                                     8. Eventually payment protocol
                                   messages finish so Payment Handler
                                    creates Pay Receipt Component and
                                   inside a Pay Response Block, and an
                                   optional Signature Component in the
                                   Signature Block, sends to Consumer
                                                and stops
                                                       |
                                                       v
9. Consumer checks Pay Response is                     OtpMsg: Trans
 OK, and creates Delivery Request   <---------------     Ref Block;
  from Pay Response Block, Offer    Payment Response  Signature Block
Response Block and Signature Block                      Pay Response
and sends to the Delivery Handler                          Block
       |          ====================================================
       v                            DELIVERY HANDLER
tpMsg: Trans Ref                    10. Delivery Handler checks Pay
Block; Signature  ------------->  Receipt, Order in Offer Response and
 Block Delivery      Delivery      the optional Signatures, creates a
 Request Block       Request       Delivery Response Block, sends to
                                           Consumer and stops
                                                          |
                                                          v
 10. Consumer checks Delivery                     OtpMsg: Trans Ref
    Response Block is OK,       <-------------     Block; Delivery
ptionally keeps information on     Delivery         Response Block
  OTP Transaction for record       Response               |
  keeping purposes and stops                              v
                                                         STOP
              |
              v
             STOP

  Figure 25 Baseline Purchase, Delivery Response Block and Payment
  Response Blocks Not Combined
  The second diagram illustrates the case when the Delivery Response
  Block and the Payment Response Block are combined into one IOTP
  Message.

        CONSUMER              OTP MESSAGE              MERCHANT
   3/5. Consumer generates Pay
  Request Block encapsulating a
   payment protocol message if
  required and sends to Payment
 Handler together with Signature
        Block if present
                |
                v
 OtpMsg: Trans                      6. Payment Handler processes Pay
   Ref Block;     ------------->     Request, and starts exchanging
Signature Block;     Payment           payment protocol messages,
  Pay Request        Request         encapsulated in a Pay Exchange
     Block                              Block, with the Consumer
                                                   |
                                                   v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref   <----------------->  Ref Block; Pay
xchange Blocks with   Block; Pay     Payment Exchange   Exchange Block
  Payment Handler   Exchange Block
                                                          |
                                                          v
                                      8. Eventually payment protocol
                                        messages finish so Payment
                                        Handler creates Pay Receipt
                                      Component inside a Pay Response
                                      Block and an optional Signature
                                     Component, then uses information
                                     from the Offer Response Block to
                                     create a Delivery Response Block,
                                     sends both to Consumer and stops
                                                     |
                                                     v
  9. Consumer checks Pay                      OtpMsg: Trans Ref Block;
  Response and Delivery     <---------------    Signature Block; Pay
 Response Blocks are OK,    Payment Response  Response Block; Delivery
     optionally keeps          & Delivery          Response Block
    information on OTP          Response                  |
  Transaction for record                                  v
keeping purposes and stops                              STOP
            |
            v
           STOP

  Figure 26 Baseline Purchase, Delivery Response Block and Payment
  Response Block Combined
  The Delivery Response Block and the Payment Response Block may be
  combined into the same IOTP Message only if the Payment Handler has
  the information available so that she can send the Delivery Response
  Block. This is likely to, but will not necessarily, occur when the
  Merchant, the Payment Handler and the Delivery Handler Roles are
  combined.

  The DelivAndPayResp attribute of the Delivery Component (see section
  6.12) contained within the Offer Response Block (see section 7.3) is
  set to True if the Delivery Response Block and the Payment Response
  Block are combined into the same IOTP Message and is set to False if
  the Delivery Response Block and the Payment Response Block are sent in
  separate IOTP Messages.

8.3.1.3 Optional Delivery Exchange

  The final variation of the Baseline Purchase IOTP Transactions is a
  purchase without a delivery step. This is illustrated in the following
  diagram which continues where the earlier diagrams (Figure 23and
  Figure 24) finish.

        CONSUMER              OTP MESSAGE              MERCHANT
  3/5. Consumer generates Pay
 Request Block encapsulating a
  payment protocol message if
 required and sends to Payment
Handler together with Signature
        Block if present
               |
               v
OtpMsg: Trans Ref                        6. Payment Handler checks
 Block; Signature  --------------->  signature, processes Pay Request
Block; Pay Request  Payment Request    Block, and starts exchanging
      Block                             payment protocol messages,
                                      encapsulated in a Pay Exchange
                                         Block, with the Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref    <-----------------> Ref Block; Pay
Exchange Blocks with   Block; Pay    Payment Exchange   Exchange Block
  Payment Handler    Exchange Block                        |
                                                          |
                                                          v
                                        8. Eventually payment protocol
                                          messages finish so Payment
                                         Handler creates Pay Receipt
                                            Component inside a Pay
                                         Response Block and optional
                                        Signature Component, sends to
                                              Consumer and stops
                                                       |
                                                       v
 9. Consumer checks Pay                     OtpMsg: Trans Ref Block;
     Response is OK,       <------------      Signature Block; Pay
    optionally keeps          Payment            Response Block
   information on OTP        Response                  |
 Transaction for record                                v
  keeping purposes and                                STOP
          stops
            |
            v
          STOP

  Figure 27 Baseline Purchase, Purchase without Delivery Exchange

  The DelivExch attribute of the Delivery Component (see section 6.12)
  contained in the Offer Response Block (see section 7.3) is set to
  False if the Delivery Exchange is omitted and is set to True if the
  Delivery Exchange is included.

8.3.1.4 Combining Variations

  The diagram below shows how the different variations in the Baseline
  Purchase Transaction may be combined.

                                  START
                                    |
                                    v
               Offer Response Block in first OTP Message?
                    |=True                        |=False
                    v                             v
                   Brand                        Brand
                Independent                   Dependent
                 Purchase                      Purchase
                    |    =True           =False   |
                     ------------      -----------
                                 |    |
                                 v    v
                               DelivExch ?
                        =True    |    |   =False
                      -----------      ------------
                     |                             |
                     v                             v
               DelivAndPayResp ?           Purchase without
                 |         |              Delivery Exchange
           =False|         |=True                  |
         --------           --------               v
        |                           |            STOP
        v                           v
Delivery Response               Delivery
  Block and Pay              Response Block
 Response Blocks            and Pay Response
   Not Combined              Blocks Combined
        |                           |
        v                           v
       STOP                       STOP

  Figure 28 Baseline Purchase Variations

  The remainder of this sub-section on the Baseline Purchase IOTP
  Transaction defines the contents of each Trading Block. For most
  Trading Blocks, the content does not alter with the variations
  described above. Where differences apply, these are stated.

8.3.2 TPO (Trading Protocol Options) Block

  The TPO (Trading Protocol Options) Block (see section 8.3.2) must
  contain the following Trading Components:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.
  o  one Brand List Component (see section 6.6) which contains one
     or more payment brands and protocols which may be selected for
     use in the Payment Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - Merchant who is providing the goods or services
     - Consumer who is making the purchase
     - PaymentHandlers for the payment.

8.3.3 TPO Selection Block

  The TPO Selection Block (see section 7.2) is only used by Brand
  Dependent Purchase. It contains:
  o  one Brand Selection Component (see section 6.7) for use in the
     Payment Exchange. It contains the results of the consumer
     selecting a Payment Brand and Payment Protocol from the list
     provided in the Brand List Component.

8.3.4 Offer Response Block

  The Offer Response Block (see section 7.3) contains the following
  components:
  o  zero or one Authentication Data Component (see section 6.2) An
     Authentication Data Component is required for each Payment
     Exchange, where its Payment Component (see section 6.8)
     contains an AuthDataRef attribute.
  o  one Order Component (see section 6.4) which contains details
     about the goods, services which are being purchased
  o  one Payment Component (see section 6.8) which contains
     information about the payment which is to be made
  o  Organisation Components (see section 6.5) with the following
     roles:
     - Merchant who is providing the goods or services
     - Consumer who is making the purchase
     - PaymentHandler for the payment. The "ID" of the Payment Handler
       Organisation Component is contained within the VaOrgRef
       attribute of the Payment Component
  o  one Delivery Component (see section 6.12) which contains
     details of the delivery to be made.

  If the Baseline Purchase includes a Delivery Exchange then the Offer
  Response Block must also contain:
  o  Organisation Components with the following roles:
     - DeliveryHandler who will be delivering the goods or services
     - DelivTo i.e. the person or organisation which is to take
       delivery

  The Offer Response Block may also contain one or more Trading Role
  Data Components (see section 6.16).

8.3.5 Signature Block (Offer Response)

  If the Baseline Purchase Offer Response is being digitally signed then
  a Signature Block must be included in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18).
  The Signature Component contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message and IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the Payment Component
     - all the Organisation Components present, and
     - the Delivery Component,
     - any Trading Role Data Components
  o  the following components of the TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Purchase is a Brand Dependent Purchase then the
  Signature Component additionally contains a hash of the following:
  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.3.6 Payment Request Block

  The Payment Request Block (see section 7.6) contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component if present
     - the Payment Component
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler
  o  the  following component from the TPO Block:
     - the Brand List Component
  o  one Brand Selection Component either:
     - copied from the Offer Response Block if the purchase is a Brand
       Dependent Purchase, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the purchase is a Brand
       Independent Purchase
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Payment Handlers should check that they are authorised to carry out
  the Payment (see section 5 Security Considerations).

8.3.7 Signature Block (Payment Request)

  If the Baseline Purchase Offer Response Block was signed then the IOTP
  Message that contains the Payment Request Block must also contain a
  Signature Block with a copy of the "Offer Response" Signature
  Component.

8.3.8 Payment Exchange Block

  The Payment Exchange Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain.

8.3.9 Payment Response Block

  The Payment Response Block (see section 7.8) contains:
  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify the
     payment occurred
  o  one Payment Scheme Component (see section 6.9) if required
     which contains payment method specific data. See the Payment
     Method supplement for the payment method being used to
     determine what this should contain
  o  the "Offer Response" Signature Component (see section 6.18)
     from the Payment Request Block if present

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.3.10 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component of the Offer
  Response Block being set to True, then the IOTP Message that contains
  the Payment Response Block must also contain a Signature Block with a
  "Payment Receipt" Signature Component which contains hashes of the
  following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block
  o  any Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from the Payment
     Request Block if present.

8.3.11 Delivery Request Block

  The Delivery Request Block (see section 7.9) contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component (see section 6.15)
     - the Order Component (see section 6.4)
     - the Organisation Component (see section 6.5) with the roles of:
       Merchant, DeliveryHandler and DeliverTo
     - the Delivery Component (see section 6.12)
  o  the following Component from the Payment Response Block:
     - the Status Component (see section 6.15).

  The Delivery Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Payment Handlers should check that they are authorised to carry out
  the Payment (see section 5 Security Considerations).

8.3.12 Signature Block (Delivery Request)

  If the Baseline Purchase Offer Response or Payment Response Blocks
  were signed then the IOTP Message that contains the Delivery Request
  Block must also contain a Signature Block with a copy of:
  o  the "Offer Response" Signature Component if present, and/or
  o  the "Payment Receipt" Signature Component, if present

8.3.13 Delivery Response Block

  The Delivery Response Block contains:
  o  one Delivery Note Component (see section 6.13) which contains
     delivery instructions about the delivery of goods or services

8.4 Baseline Refund IOTP Transaction

  In business terms the refund process typically consists of:
  o  a request for a refund being made by the Consumer to the
     Merchant, typically supported by evidence to demonstrate:
     - the original trade took place, for example by providing a
       receipt for the original transaction
     - using some type of authentication, that the consumer requesting
       the refund is the consumer, or a representative of the consumer,
       who carried out the original trade
     - the reason why the merchant should make the refund
  o  the merchant agreeing (or not) to the refund. This may involve
     some negotiation between the Consumer and the Merchant, and,
     if the merchant agrees,
  o  a refund payment by the Merchant to the Consumer.

  The Baseline Refund IOTP Transaction supports a subset of the above,
  specifically it supports:
  o  the optional authentication of the Consumer using an
     Authentication Exchange (see section 2.2.4), and
  o  the refund payment by the Merchant to the Consumer using the
     following two Trading Exchanges:
     - an Offer Exchange (see section 2.2.1), and
     - a Payment Exchange (see section 2.2.2).

  These Trading Exchanges are implemented by a set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each IOTP Message contains Trading Blocks (see
  section 7) which contain the Trading Components (see section 6) which
  are required by the Trading Exchanges.

  The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Authentication Request Block
  o  Authentication Response Block
  o  Offer Response Block
  o  Payment Request Block
  o  Payment Exchange Block
  o  Payment Response Block
  o  Signature Block

8.4.1 Baseline Refund Variations

  The Baseline Refund IOTP Transaction occurs in two basic forms:
  o  Baseline Refund with Authentication. Where the Consumer
     requesting the refund is authenticated before the refund is
     made, and
  o  Baseline Refund without Authentication. Where the Consumer is
     not authenticated before the refund is made.

8.4.2 Baseline Refund Authentication

  In Baseline Refund with Authentication an Authentication Exchange
  occurs before the Offer Exchange containing the details of the refund
  is provided by the Merchant.

  In Baseline Refund without Authentication, there is no Authentication
  Exchange and the Merchant provides details about the refund
  immediately at the start of the IOTP Transaction.

  These two alternatives are illustrated in the two diagrams below. The
  first diagram illustrates the case when an Authentication Exchange is
  included.

       CONSUMER                OTP MESSAGE             MERCHANT
1. Consumer requests                        2. The Merchant sets the
     payment of                             payment brand and decides
 previously agreed    ------------------>   which protocols to offer,
   refund, sends      Refund Information          generates an
 information about     (outside scope of     Authentication Request
 refund, such as a           OTP)          Block containing challenge
reference number to                          data and the method of
 the Merchant, e.g.                         authentication and sends
     using HTML                                  to the Consumer
                                                          |
                                                          v
   3. OTP aware application                        OTPMsg:Trans Ref
started. The consumer selects   <--------------   Block; TPO Block;
   payment protocol to use,          TPO &       Auth.Response Block
 records selection in a Brand   Authentication
Selection Component, generates      Request
  an Authentication Response
Component and sends both back
       to the Merchant.
      |
      v

OTPMsg: Trans                         4. The Merchant checks the
 Ref Block;   --------------->   Authentication Response against the
Auth Response TPO Selection  &   challenge data in the Authentication
 Block; TPO    Authentication    Request Block, uses the information
  Selection       Response       to identify the consumer and refund,
    Block                         generates an Offer Response Block
                                   containing information about the
                                 refund, an optional Signature Block
                                      and sends to the Consumer
                                                              |
                                                              v
  5. Consumer checks Offer is OK,                       OTPMsg: Trans
 combines components from the TPO    <---------------    Ref Block;
Block, the TPO Selection Block and    Offer Response      Signature
the Offer Response Block to create                      Block; Offer
 a Pay Request Block and sends to                      Response Block
 the Payment Handler together with
        optional Signature
                 |
                 v
             CONTINUED

  Figure 29 Baseline Refund with Authentication

  The second diagram illustrates the case when an Authentication
  Exchange is not included.

       CONSUMER               OTP MESSAGE              MERCHANT
 1. Consumer requests                    2. Merchant sets the payment
 payment of previously                      brand and decides which
 agreed refund, sends   -------------->       protocols to offer,
   information about         Refund       generates an Offer Response
refund to the Merchant,   Information    Block containing information
  such as a reference    (outside scope      about the refund, an
  number, using, for        of OTP)      optional Signature Block and
     example, HTML                           sends to the Consumer
                                                               |
                                                               v
   3. OTP aware application started.                     OTPMsg:Trans
 Consumer selects the payment protocol  <--------------   Ref Block;
 to use, records selection in a Brand        TPO &         Signature
 Selection Component, checks Offer is    Offer Response   Block; TPO
   OK, combines the Brand Selection                      Block; Offer
Component with information from the TPO                    Response
   Block and Offer Response Block to                         Block
create a Pay Request Block and sends it
 to the Payment Handler together with
       optional Signature Block
                   |
                   v
               CONTINUED
  Figure 30 Baseline Refund without Authentication

  The Baseline Refund without authentication might be used:
  o  when authentication of the consumer has been achieved by some
     other means, for example, the consumer has entered some
     previously supplied code in order to identify herself and the
     refund to which the code applies. The code could be supplied,
     for example on a web page or by e-mail.
  o  when a previous IOTP transaction, for example a Baseline
     Authentication, authenticated the consumer, and a secure
     channel has been maintained, therefore the authenticity of the
     consumer is known and therefore the previously agreed refund
     can be identified.
  o  when the authentication of the consumer is carried out by the
     Payment Handler using a payment scheme authentication method.

  IOTP aware applications supporting the Consumer Trading Role must
  check for the existence of an Authentication Request Block in the
  first IOTP Message to determine whether the Baseline Refund includes
  an Authentication Exchange or not.

8.4.3 Baseline Refund Payment Messages

  Once the Offer Response Trading Block has been received, the sequence
  of IOTP Messages illustrated in Figure 31 occurs. These are the same
  whether or not an Authentication of the Consumer has occurred. Note
  that these continue where the previous diagrams (Figure 29 and Figure
  30) finish.

        CONSUMER              OTP MESSAGE          PAYMENT HANDLER
  3/5. Consumer generates Pay
 Request Block encapsulating a
  payment protocol message if
 required and sends to Payment
 Handler together with optional
        Signature Block
               |
               v
tpMsg: Trans Ref                 6. Payment Handler checks signature,
Block; Signature  ------------>    processes Pay Request Block, and
   Block; Pay        Payment      starts exchanging payment protocol
 Request Block       Request        messages, encapsulated in a Pay
                                   Exchange Block, with the Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref   <-----------------> Ref Block; Pay
xchange Blocks with   Block; Pay     Payment Exchange  Exchange Block
  Payment Handler   Exchange Block
                                                         |
                                                         v
                                     8. Eventually payment protocol
                                   messages finish so Payment Handler
                                      creates Pay Receipt Component
                                   inside a Pay Response Block, sends
                                      to Consumer with and optional
                                      Signature Component and stops
                                                      |
                                                      v
 9. Consumer checks Pay                      OtpMsg: Trans Ref Block;
esponse is OK. Optionally  <---------------    Signature Block; Pay
keeps information on OTP   Payment Response       Response Block
 Transaction for record                                 |
eeping purposes and stops                               v
            |                                          STOP
            v
          STOP

  Figure 31 Baseline Refund Payment Messages

  The remainder of this sub-section on the Baseline Refund IOTP
  Transaction defines the contents of each Trading Block. For most
  Trading Blocks, the content does not alter with the variations
  described above. Where differences apply, these are stated.

8.4.4 TPO (Trading Protocol Options) Block

  The TPO (Trading Protocol Options) Block (see section 8.3.2) must
  contain the following Trading Components:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.
  o  one Brand List Component (see section 6.6) which contains the
     payment brand and protocols which may be selected for use in
     the Payment Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - the Merchant who is making the refund
     - the Consumer who is requesting the refund
     - the PaymentHandlers for the payment.

8.4.5 TPO Selection Block

  The TPO Selection Block (see section 7.2) is only used by Baseline
  Refund with Authentication. It contains:
  o  one Brand Selection Component (see section 6.7) for use in the
     Payment Exchange. It contains the results of the consumer
     selecting a Payment Brand and Payment Protocol from the list
     provided in the Brand List Component.

8.4.6 Authentication Request Block

  The Authentication Request Block (see section 7.4) must contain the
  following Trading Component:
  o  one Authentication Data Component (see section 6.2)

8.4.7 Authentication Response Block

  The Authentication Response Block (see section 7.5) must contain the
  following Trading Component:
  o  one Authentication Response Component (see section 6.3).

8.4.8 Offer Response Block

  The Offer Response Block (see section 7.3) must contain the following
  components:
  o  zero or one Authentication Data Component (see section 6.2) An
     Authentication Data Component is required for each Payment
     Exchange, where its Payment Component  contains an AuthDataRef
     attribute
  o  one Order Component (see section 6.4) which contains details
     about the refund, for example the amount being refunded and
     any conditions which might apply
  o  one Payment Component  (see section 7.2) which contains
     information about the payment which is to be made
  o  one Delivery Component (see section 6.12) with the DelivExch
     attribute set to False.

  The Offer Response Block may also contain one or more Trading Role
  Data Components (see section 6.16).

8.4.9 Signature Block (Offer Response)

  If the Baseline Refund Offer Response is being digitally signed then a
  Signature Block must be included in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18).
  The Signature Component contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message and IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the Payment Component
     - all the Organisation Components present, and
     - the Delivery Component,
     - any Trading Role Data Components
  o  the following components of the TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Refund is a Baseline Refund with Authentication then
  the Signature Component additionally contains a hash of the following:
  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.4.10 Payment Request Block

  The Payment Request Block (see section 7.6) contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component if present
     - the Payment Component
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler
  o  the  following component from the TPO Block:
     - the Brand List Component
  o  one Brand Selection Component either:
     - copied from the Offer Response Block if the refund is a Baseline
       Refund with Authentication, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the refund is a Baseline Refund
       with Authentication
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Payment Handlers should check that they are authorised to carry out
  the Payment (see section 5 Security Considerations).

8.4.11 Signature Block (Payment Request)

  If the Baseline Refund Offer Response Block was signed then the IOTP
  Message that contains the Payment Request Block must also contain a
  Signature Block with a copy of the "Offer Response" Signature
  Component.

8.4.12 Payment Exchange Block

  The Payment Exchange Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain.

8.4.13 Payment Response Block

  The Payment Response Block (see section 7.8) contains:
  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify the
     payment occurred
  o  one Payment Scheme Component (see section 6.9) if required
     which contains payment method specific data. See the Payment
     Method supplement for the payment method being used to
     determine what this should contain
  o  the "Offer Response" Signature Component (see section 6.18)
     from the Payment Request Block if present

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.4.14 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component of the Offer
  Response Block being set to True, then the IOTP Message that contains
  the Payment Response Block must also contain a Signature Block with a
  "Payment Receipt" Signature Component which contains hashes of the
  following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block,
  o  any Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from the Payment
     Request Block if present.

8.5 Baseline Withdrawal IOTP Transaction

  The Baseline Withdrawal IOTP Transaction supports the withdrawal of
  electronic cash from a Financial Institution.

  [Note]   The Financial Institution has, in IOTP terminology, a role
           of merchant in that a service (i.e. a withdrawal of
           electronic cash) is being offered in return for a fee, for
           example bank charges of some kind. The term "Financial
           Institution" is used in the diagrams and in the text for
           clarity.
  [Note End]

  The Baseline Withdrawal IOTP Transaction consists of the following
  Trading Exchanges:
  o  an optional Authentication Exchange (see section 2.2.4),
  o  an Offer Exchange (see section 2.2.1), and
  o  a Payment Exchange (see section 2.2.2).

  These Trading Exchanges are implemented by a set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each IOTP Message contains Trading Blocks (see
  section 7) which contain the Trading Components (see section 6) which
  are required by the Trading Exchanges.

  The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Authentication Request Block
  o  Authentication Response Block
  o  Offer Response Block
  o  Payment Request Block
  o  Payment Exchange Block
  o  Payment Response Block
  o  Signature Block

8.5.1 Baseline Withdrawal Variations

  The Baseline Withdrawal IOTP Transaction occurs in two basic forms:
  o  Baseline Withdrawal with Authentication. Where the Consumer
     making the withdrawal is authenticated before the withdrawal
     is made, and
  o  Baseline Withdrawal without Authentication. Where the Consumer
     is not authenticated before the withdrawal is made.

  In both these forms it is assumed that the Payment Brand being used is
  determined before the Baseline Withdrawal transaction starts. This
  means that Brand Selection is limited to Payment Protocol selection
  only.

8.5.2 Baseline Withdrawal Authentication

  In Baseline Withdrawal with Authentication an Authentication Exchange
  occurs before the Offer Exchange containing the details of the
  withdrawal is provided by the Financial Institution.

  In Baseline Withdrawal without Authentication, there is no
  Authentication Exchange and the Financial Institution provides details
  about the withdrawal immediately at the start of the IOTP Transaction.

  These two alternatives are illustrated in the two diagrams below. The
  first diagram illustrates the case when an Authentication Exchange is
  included.

       CONSUMER                OTP MESSAGE             FINANCIAL
                                                      INSTITUTION
1. Consumer decides to                   2. The Financial Institution
  withdraw electronic                     sets the payment brand and
    cash and sends      -------------->    decides the protocols to
 information about how     Withdrawal         offer, generates an
much to withdraw to the   Information    Authentication Request Block
Financial Institution,   (outside scope    containing challenge data
    e.g. using HTML         of OTP)            and the method of
                                          authentication and sends to
                                                 the Consumer
                                                             |
                                                             v
    3. OTP aware application                         OTPMsg:Trans Ref
 started. The consumer selects    <-----------------    Block; TPO
  the payment protocol to use,          TPO &          Block; Auth.
  records selection in a Brand      Authentication    Response Block
 Selection Component, generates        Request
   an Authentication Response
Component and sends back to the
     Financial Institution.
     |
     v
  OTPMsg:                        4. The Financial Institution checks
 Trans Ref   --------------->    the Authentication Response against
Block; Auth  TPO Selection  &         the challenge data in the
  Response    Authentication   Authentication Request Block, uses the
 Block; TPO      Response       information to identify the consumer,
 Selection                        generates an Offer Response Block
                                  containing information about the
                                withdrawal, an optional signature and
                                        sends to the Consumer
                                                             |
                                                             v
5. Consumer checks Offer is OK,                        OTPMsg: Trans
 combines components from the                           Ref Block;
 TPO Block, the TPO Selection   <------------------  Signature Block;
 Block and the Offer Response      Offer Response     Offer Response
 Block to create a Pay Request                             Block
Block and sends to the Payment
Handler together with optional
        Signature Block
               |
               v                 Note that the Financial Institution
           CONTINUED              has, in OTP terminology, a role of
                                             "Merchant".

  Figure 32 Baseline Withdrawal with Authentication
  Note that the above diagram:
  o  describes the general case where a Financial Institution can
     offer withdrawal of several different types of electronic
     cash. In practice usually only one form of electronic cash may
     be offered. However, there may be several different protocols
     which may be used for the same "brand" of electronic cash
  o  the financial institution may use the results of the
     authentication to identify not only the consumer but also the
     account from which the withdrawal is to be made. If no single
     account can be identified, then it must be obtained by other
     means. For example:
     - the consumer could specify the account number in the initial
       dialogue (see step 1), or
     - the consumer could have been identified earlier, for example
       using a Baseline Authentication IOTP Transaction, and an account
       selected from a list provided by the Financial Institution.

  The second diagram illustrates the case when an Authentication
  Exchange is not included.

       CONSUMER                OTP MESSAGE             FINANCIAL
                                                      INSTITUTION
1. Consumer decides to                     2. Financial Institution
  withdraw electronic                      decides sets the payment
    cash and sends       ------------>     brand and decides which
 information about how    Withdrawal        protocols to offer for
much to withdraw, etc.    Information      withdrawal, generates an
   to the Financial        (outside          Offer Response Block
Institution, e.g. using  scope of OTP)   containing information about
         HTML                            the withdrawal, an optional
                                          signature and sends to the
                                                   Consumer
                                                        |
                                                        v
  3. OTP aware application started.                     OTPMsg: Trans
Consumer selects the payment protocol  <--------------    Ref Block;
 to use, records selection in a Brand       TPO &         Signature
 Selection Component, checks Offer is   Offer Response    Block; TPO
   OK, combines the Brand Selection                      Block; Offer
 Component with information from the                       Response
TPO Block and Offer Response Block to                       Block
 create a Pay Request Block and sends
  it to the Payment Handler together
    with optional Signature Block
                  |
                  v                        Note that the Financial
              CONTINUED                    Institution has, in OTP
                                           terminology, a role of
                                                 "Merchant".

  Figure 33 Baseline Withdrawal without Authentication
  The Baseline Withdrawal without Authentication might be used:
  o  when a previous IOTP transaction, for example a Baseline
     Deposit or a Baseline Authentication, authenticated the
     consumer, and a secure channel has been maintained, therefore
     the authenticity of the consumer is known
  o  when authentication is achieved as part of a proprietary
     payment protocol and is therefore included in the Payment
     Exchange
  o  when authentication of the consumer has been achieved by some
     other means, for example, by using a pass phrase, or a
     proprietary banking software solution.

  IOTP aware applications supporting the Consumer Trading Role must
  check for the existence of an Authentication Request Block in the
  first IOTP Message to determine whether the Baseline Withdrawal
  includes an Authentication Exchange or not.

8.5.3 Baseline Withdrawal Payment Messages

  Once the Offer Response Trading Block has been received, the sequence
  of IOTP Messages illustrated in Figure 34 occurs. These are the same
  whether or not an Authentication of the Consumer has occurred. Note
  that these continue where the previous diagrams (Figure 32 and Figure
  33) finish.

        CONSUMER              OTP MESSAGE          PAYMENT HANDLER
   3/5. Consumer generates Pay
  Request Block encapsulating a
   payment protocol message if
  required and sends to Payment
 Handler together with optional
         Signature Block
                |
                v
 OtpMsg: Trans                          6. Payment Handler checks
   Ref Block;     --------------->  optional signature, processes Pay
Signature Block;   Payment Request      Request Block, and starts
  Pay Request                          exchanging payment protocol
     Block                           messages, encapsulated in a Pay
                                    Exchange Block, with the Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref    <----------------->Ref Block; Pay
Exchange Blocks with   Block; Pay    Payment Exchange  Exchange Block
  Payment Handler    Exchange Block
                                                          |
                                                          v
                                       8. Eventually payment protocol
                                         messages finish so Payment
                                        Handler creates Pay Receipt
                                      Component inside a Pay Response
                                       Block, an optional signature,
                                        sends to Consumer and stops
                                                         |
                                                         v
   9. Consumer checks Pay                    OtpMsg: Trans Ref Block;
 Response is OK. Optionally   <------------       Signature Block
  keeps information on OTP       Payment        Pay Response Block
   Transaction for record       Response                 |
 keeping purposes and stops                              v
             |                                         STOP
             v
            STOP

  Figure 34 Baseline Withdrawal Payment Messages

  The remainder of this sub-section on the Baseline Withdrawal IOTP
  Transaction defines the contents of each Trading Block. For most
  Trading Blocks, the content does not alter with the variations
  described above. Where differences apply, these are stated.

8.5.4 TPO (Trading Protocol Options) Block

  The TPO (Trading Protocol Options) Block (see section 8.3.2) must
  contain the following Trading Components:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.
  o  one Brand List Component (see section 6.6) which contains the
     payment brand and protocols which may be selected for use in
     the Payment Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - the Merchant who is accepting the withdrawal
     - the Consumer who is making the withdrawal
     - the PaymentHandler for the payment.

8.5.5 TPO Selection Block

  The TPO Selection Block (see section 7.2) is only used by Baseline
  Withdrawal with Authentication. It contains:
  o  one Brand Selection Component (see section 6.7) for use in the
     Payment Exchange. It contains the results of the consumer
     selecting a Payment Brand and Payment Protocol from the list
     provided in the Brand List Component.

8.5.6 Authentication Request Block

  The Authentication Request Block (see section 7.4) must contain the
  following Trading Component:
  o  one Authentication Data Component (see section 6.2)

8.5.7 Authentication Response Block

  The Authentication Response Block (see section 7.5) must contain the
  following Trading Component:
  o  one Authentication Response Component (see section 6.3).

8.5.8 Offer Response Block

  The Offer Response Block (see section 7.3) must contain the following
  components:
  o  zero or one Authentication Data Components (see section 6.2)
     An Authentication Data Component is required for each Payment
     Exchange, where its Payment Component contains an AuthDataRef
     attribute
  o  one Order Component (see section 6.4) which contains details
     about the withdrawal, for example the amount being withdrawn
     and any fees which might apply
  o  one Payment Component  (see section 7.2) which contains
     information about the payment which is to be made
  o  one Delivery Component (see section 6.12) with the DelivExch
     attribute set to False.

  The Offer Response Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  [Note]   In the above an Organisation with a role of Merchant is used
           in that a service (i.e. a withdrawal of electronic cash) is
           being offered in return for a fee, for example bank charges
           of some kind. The term "Financial Institution" is used in
           the diagrams and in the text for clarity.
  [Note End]

8.5.9 Signature Block (Offer Response)

  If the Baseline Withdrawal Offer Response is being digitally signed
  then a Signature Block must be included in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18).
  The Signature Component contains hashes of the following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message and IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the Payment Component
     - all the Organisation Components present
     - the Delivery Component,
     - any Trading Role Data Components
  o  the following components of the TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Withdrawal is a Baseline Withdrawal with
  Authentication then the Signature Component additionally contains a
  hash of the following:
  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.5.10 Payment Request Block

  The Payment Request Block (see section 7.6) contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component if present
     - the Payment Component
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler
  o  the  following component from the TPO Block:
     - the Brand List Component
  o  one Brand Selection Component either:
     - copied from the Offer Response Block if the withdrawal is a
       Baseline Withdrawal with Authentication, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the withdrawal is a Baseline
       Withdrawal without Authentication
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Payment Handlers should check that they are authorised to carry out
  the Payment (see section 5 Security Considerations).

8.5.11 Signature Block (Payment Request)

  If the Baseline Withdrawal Offer Response Block was signed then the
  IOTP Message that contains the Payment Request Block must also contain
  a Signature Block with a copy of the "Offer Response" Signature
  Component.

8.5.12 Payment Exchange Block

  The Payment Exchange Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain.

8.5.13 Payment Response Block

  The Payment Response Block (see section 7.8) contains:
  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify the
     payment occurred
  o  one Payment Scheme Component (see section 6.9) if required
     which contains payment method specific data. See the Payment
     Method supplement for the payment method being used to
     determine what this should contain
  o  the "Offer Response" Signature Component (see section 6.18)
     from the Payment Request Block if present

  The Offer Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.5.14 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component of the Offer
  Response Block being set to True, then the IOTP Message that contains
  the Payment Response Block must also contain a Signature Block with a
  "Payment Receipt" Signature Component which contains hashes of the
  following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block,
  o  any Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from the Payment
     Request Block if present.

8.6 Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange Transaction uses Payment Exchanges (see
  section 2.2.2) to support the exchange of value in one currency
  obtained using one payment method with value in the same or another
  currency using the same or another payment method. Examples of its use
  include:
  o  electronic cash advance on a credit card. For example the
     first payment could be a dollar SET Payment Exchange on a
     credit card with the second Payment Exchange being a download
     of DigiCash e-cash in dollars.
  o  foreign exchange using the same payment method. For example
     the payment could be an upload of Mondex value in French
     Francs and the second a download of Mondex value in British
     Pounds
  o  foreign exchange using different payment methods. For example
     the first payment could be a SET payment in Euros followed a
     download of GeldKarte in Deutchmarks.

  The Baseline Value Exchange uses three Trading Exchanges:
  o  an Offer Exchange (see section 2.2.1) which provides details
     of what values and currencies will be exchanged, and
  o  two Payment Exchanges (see section 2.2.2) which carry out the
     two payments involved

  These Trading Exchanges are implemented by a set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each IOTP Message contains Trading Blocks (see
  section 7) which contain the Trading Components (see section 6) which
  are required by the Trading Exchanges.

  The Trading Blocks used by the Baseline Value Exchange IOTP
  Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Offer Response Block
  o  Payment Request Block
  o  Payment Exchange Block
  o  Payment Response Block
  o  Signature Block

8.6.1 Baseline Value Exchange Variations

  The Baseline Value Exchange IOTP Transaction occurs in two basic
  forms:
  o  Brand Dependent Value Exchange. Where the content of the
     offer, for example the rate at which one form of value is
     exchanged for another, is dependent on the payment brands and
     protocols selected by the consumer, and
  o  Brand Independent Value Exchange. Where the content of the
     offer is not dependent on the payment brands and protocols
     selected.

  In Brand Dependent Value Exchange the TPO Block and the Offer Response
  Block are sent separately by the Merchant to the Consumer, i.e.:
  o  the Brand List Components for the two payments are sent to the
     Consumer in a TPO Block,
  o  the Consumer selects a Payment Brand and Payment Protocol from
     the Brand List Component for each of the payments in the Value
     Exchange
  o  the Consumer sends the selected brands and protocols back to
     the Merchant in a TPO Selection Block, and
  o  the Merchant Uses the information received to define the
     content of the Offer Response Block and then sends it to the
     Consumer.

  [Note]   In the above the role is a Merchant even though the
           organisation carrying out the Value Exchange may be a Bank
           or some other Financial Institution. This is because the
           Bank is acting as a merchant in that they are making an
           offer which the Consumer can either accept or decline.
  [Note End]

  In Brand Independent Value Exchange the TPO Block and the Offer
  Response Block are sent together by the Merchant to the Consumer in
  the same IOTP Message at the start of the IOTP Transaction.

  These two alternatives are illustrated in the two diagrams below. The
  first diagram illustrates a Brand Dependent Value Exchange.

       CONSUMER                OTP MESSAGE             MERCHANT
 1. Consumer decides to                    2. Merchant decides which
conduct a Value Exchange -------------->  payment brand and protocols
 and sends information    Value Exchange   to offer for each payment,
 about the exchange to     Information     places them in Brand List
the Merchant, e.g. using  (outside scope   Components in a TPO Block,
          HTML               of OTP)         and sends to Consumer
                                                       |
                                                       v
3. OTP aware application started.                      OTPMsg: Trans
Consumer selects the payment brand  <---------------   Ref Block; TPO
 and payment protocol to use for           TPO             Block
 each payment, records selections
in two Brand Selection Components,
    and sends back to Merchant
      |
      v
 OTPMsg:Trans                    4. Merchant uses payment brands and
Ref Block; TPO                  protocols selected to create an Offer
  Selection     ------------->    Response Block containing details
    Block        TPO Selection      about the Value Exchange, e.g.
                                 exchange rates, commission, etc. and
                                   sends to Consumer together with
                                          optional signature
                                                             |
                                                             v
 5. Consumer checks Offer is OK,                        OTPMsg:Trans
combines components from the TPO   <----------------     Ref Block;
 Block, the TPO Selection Block      Offer Response      Signature
 and the Offer Response Block to                        Block; Offer
 create a Pay Request Block for                        Response Block
the first payment and sends it to
 Payment Handler 1 together with
     the optional signature
                |
                v
            CONTINUED

  Figure 35 Brand Dependent Value Exchange

  The second diagram illustrates the a Brand Independent Value Exchange.

       CONSUMER                OTP MESSAGE             MERCHANT
   1. Consumer                    2. Merchant decides which payment
   decides to                   brand and protocols to offer for each
 conduct a Value   ----------->   payment, places them in Brand List
  Exchange and        Value     Components in a TPO Block, creates an
sends information    Exchange      Offer Response Block containing
    about the      Information    details about the Value Exchange,
 exchange to the     (outside   e.g. exchange rates, commission, etc.
 Merchant, e.g.      scope of    and sends to Consumer together with
   using HTML          OTP)            optional Signature Block
                                                             |
                                                             v
   3. OTP aware application started.                     OTPMsg:Trans
 Consumer selects the payment brand and   <-------------  Ref Block;
    payment protocol to use for each          TPO &        Signature
payment, records selections in two Brand  Offer Response  Block; TPO
 Selection Components, checks Offer is                   Block; Offer
    OK, combines the Brand Selection                       Response
  Component for the first payment with                       Block
information from the TPO Block and Offer
 Response Block to create a Pay Request
Block for the first payment and sends it
 to Payment Handler 1 with the optional
            Signature Block
                   |
                   v
               CONTINUED

  Figure 36 Brand Independent Value Exchange

  The TPO Block and Offer Response Block may only be combined into the
  same IOTP Message if the content of the Offer Response Block does not
  change as a result of selecting the payment brands and payment
  protocols to be used in the Value Exchange.

  Note that the TPO Block and the Offer Response Block may be sent in
  separate IOTP messages even if the Offer Response Block does not
  change. However this increases the number of messages in the
  transaction and is therefore likely to increase transaction response
  times.

  IOTP aware applications supporting the Consumer Trading Role must
  check for the existence of an Offer Response Block in the first IOTP
  Message to determine whether the Baseline Value Exchange is brand
  dependent.

  Whether or not the Value Exchange is brand dependent, the exchange of
  Trading Blocks between the Consumer and the Payment Handlers are the
  same. This is illustrated in the diagram below. Note that this diagram
  continues where the previous diagrams (Figure 35 and Figure 36)
  finish.

        CONSUMER              OTP MESSAGE         PAYMENT HANDLER 1
  3/5. Consumer generates Pay
 Request Block encapsulating a
  payment protocol message if
 required and sends to Payment
    Handler 1 with optional
        Signature Block
               |
               v
 OtpMsg: Trans                  6. Payment Handler 1 processes checks
  Ref Block;     ----------->   signature, Pay Request Block for the
   Signature       Payment      first payment, and starts exchanging
  Block; Pay      Request 1          payment protocol messages ,
Request Block 1                 encapsulated in a Pay Exchange Block,
                                          with the Consumer
                                                          |
                                                          v
7. Consumer keeps<- ----->OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref    <----------------->Ref Block; Pay
Exchange Blocks with   Block; Pay   Payment Exchange 1 Exchange Block
 Payment Handler 1   Exchange Block
                                                           |
                                                           v
                                      8. Eventually payment protocol
                                        messages finish so Payment
                                       Handler 1 creates Pay Receipt
                                     Component and optional Signature
                                      Component inside a Pay Response
                                      Block for first payment, sends
                                         to Consumer with optional
                                         Signature Block and stops
                                                            |
                                                            v
   9. Consumer checks Pay                           OtpMsg: Trans Ref
Response for first payment is  <-----------------   Block; Signature
 OK, and creates Pay Request   Payment Response 1      Block; Pay
  for second payment using                          Response Block 1
  Offer Response Block and                                  |
optionally the signatures and                               v
 sends to Payment Handler 2                               STOP
       |         ====================================================
       v                           PAYMENT HANDLER 2
 OtpMsg: Trans               10. Payment Handler 2 checks signature,
   Ref Block;    ------->  processes Pay Request Block for the second
Signature Block   Payment    payment, and starts exchanging payment
  Pay Request     Request   protocol messages , encapsulated in a Pay
   Block (2)         2          Exchange Block, with the Consumer
                                                          |
                                                          v
11. Consumer keeps<------>OtpMsg:                       OtpMsg: Trans
 on exchanging Pay     Trans Ref    <----------------->Ref Block; Pay
Exchange Blocks with   Block; Pay   Payment Exchange 2 Exchange Block
 Payment Handler 2   Exchange Block                      |
|
                                      12. Eventually payment protocol
                                         messages finish so Payment
                                       Handler 2 creates Pay Receipt
                                         Component and inside a Pay
                                         Response Block for second
                                      payment, sends to Consumer with
                                        optional signature and stops
                                                          |
                                                          v
 13. Consumer checks Payment                      OtpMsg: Trans Ref
  Response Block for second     <------------- Block; Signature Block
  payment is OK, optionally        Payment      Pay Response Block 2
   keeps information on OTP       Response 2              |
Transaction for record keeping                            v
      purposes and stops                                STOP
              |
              v
             STOP

  Figure 37 Baseline Value Exchange Payment Messages

  The remainder of this sub-section on the Baseline Value Exchange IOTP
  Transaction defines the contents of each Trading Block. The content
  does not alter with the variations described above.

8.6.2 PO (Trading Protocol Options) Block

  The TPO (Trading Protocol Options) Block (see section 8.3.2) must
  contain the following Trading Components:
  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1.
  o  two Brand List Components (see section 6.6) one for each
     Payment Exchange where each Brand List Component contains one
     or more payment brands and protocols which may be selected for
     use in the Payment Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - Merchant who is providing the goods or services
     - Consumer who is making the purchase
     - the PaymentHandlers for the payments.

8.6.3 TPO Selection Block

  The TPO Selection Block (see section 7.2) is only used by Brand
  Dependent Value Exchange. It contains:
  o  two Brand Selection Components (see section 6.7). One for each
     of the Payment Exchanges. Each Brand Selection Component
     contains the results of the consumer selecting a Payment Brand
     and Payment Protocol from the list provided in the Brand List
     Component.

8.6.4 Offer Response Block

  The Offer Response Block (see section 7.3) contains the following
  components:
  o  zero, one or two Authentication Data Component (see section
     6.2). An Authentication Data Component is required for each
     Payment Exchange, where its Payment Component contains an
     AuthDataRef attribute.
  o  one Order Component (see section 6.4) which contains details
     about the Value Exchange, for example, exchange rates,
     commission, etc.
  o  two Payment Components (see section 6.8) which contain
     information about each of the two payments which are to be
     made

  The Offer Response Block may also contain one or more Trading Role
  Data Components (see section 6.16).

8.6.5 Signature Block (Offer Response)

  If the Baseline Value Exchange Offer Response is being digitally
  signed then a Signature Block must be included in the same IOTP
  message that contains an "Offer Response" Signature Component (see
  section 6.18). The Signature Component contains hashes of the
  following XML elements:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message and IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) which
     globally uniquely identifies the IOTP Transaction
  o  the following components of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the two Payment Components
     - all the Organisation Components present, and
     - any Trading Role Data Components
  o  the following components of the TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Value Exchange is a Brand Dependent Value Exchange
  then the Signature Component additionally contains a hash of the
  following:
  o  the two Brand Selection Components contained in the TPO
     Selection Block.

8.6.6 Payment Request Block (first payment)

  The Payment Request Block (see section 7.6) for the first payment
  contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component for the first payment if
       required
     - the Payment Component  for the first payment
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler for the first payment
  o  the following component copied from the TPO Block:
     - the Brand List Component for the first payment
  o  one Brand Selection Component for the first payment which is
     either:
     - copied from the Offer Response Block if the purchase is a Brand
       Dependent Value Exchange, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the purchase is a Brand
       Independent Value Exchange
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Note that:
  o  the Payment Component  for the first payment is the one within
     the Offer Response Block that contains no StartAfter attribute
     (see section 6.8)
  o  the Authentication Data Component to include is identified by
     the AuthDataRef attribute of the Payment Component for the
     first payment. If no AuthDataRef attribute is present then no
     Authentication Data Component is required
  o  the Payment Handler to include is identified by the Brand
     Selection Component (see section 6.7) for the first payment.
     Also see section 5.3.1 Check the Action Request was sent to
     the Correct Organisation for an explanation on how Payment
     Handlers are identified
  o  the Brand List Component to include is the one identified by
     the BrandListRef attribute of the Payment Component for the
     first payment
  o  the Brand Selection Component to include from the Offer
     Response Block is the one that contains an Element Reference
     (see section 3.5) which identifies the Brand List Component
     for the first payment

8.6.7 Signature Block (Payment Request - first payment)

  If the Baseline Value Exchange Offer Response Block was signed then
  the IOTP Message that contains the Payment Request Block for the first
  payment must also contain a Signature Block with a copy of the "Offer
  Response" Signature Component.

8.6.8 Payment Exchange Block (first payment)

  The Payment Exchange Block (see section 7.7) for the first payment
  contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data for the payment method being used
     by the first payment. See the Payment Method supplement for
     the payment method being used to determine what this should
     contain.

8.6.9 Payment Response Block (first payment)

  The Payment Response Block for the first payment (see section 7.8)
  contains:
  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify the
     first payment occurred
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used by the first payment which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain
  o  the Signature Component (see section 6.18) from the Payment
     Request Block for the first payment if present.

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.6.10 Signature Block (Payment Response - first payment)

  If a signed Payment Receipt is being provided for the first payment,
  indicated by the SignedPayReceipt attribute of the Payment Component
  for the first payment in the Offer Response Block being set to True,
  then the IOTP Message that contains the Payment Response Block for the
  first payment must also contain a Signature Block with a "Payment
  Receipt" Signature Component which contains hashes of the following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block for the first payment,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
     for the first payment
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component for
     the first payment,
  o  the Status Component from the Payment Response Block for the
     first payment,
  o  any Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from the Payment
     Request Block for the first payment, if present.

8.6.11 Payment Request Block (second payment)

  The Payment Request Block (see section 7.6) for the second payment
  contains:
  o  the following components copied from the Offer Response Block:
     - the Status Component
     - the Authentication Data Component for the second payment if
       required
     - the Payment Component  for the second payment
     - the Organisation Components with the roles of: Merchant and
       PaymentHandler for the second payment
  o  the following component copied from the TPO Block:
     - the Brand List Component for the second payment
  o  one Brand Selection Component for the second payment which is
     either:
     - copied from the Offer Response Block if the purchase is a Brand
       Dependent Value Exchange, or
     - created by the Consumer, containing the payment brand and
       payment protocol selected, if the purchase is a Brand
       Independent Value Exchange
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if this is needed)
  o  the following components copied from the Payment Response
     Block for the first payment:
     - the Status Component
  The Payment Request Block may also contain one or more Trading Role
  Data Components (see section 6.16).

  Note that:
  o  the Payment Component  for the second payment is the one
     within the Offer Response Block that contains a StartAfter
     attribute (see section 6.8) that identifies the Payment
     Component for the first payment
  o  the Authentication Data Component to include is identified by
     the AuthDataRef attribute of the Payment Component  for the
     second payment. If no AuthDataRef attribute is present then no
     Authentication Data Component is required
  o  the Payment Handler to include is identified by the Brand
     Selection Component (see section 6.7) for the second payment.
     Also see section 5.3.1 Check the Action Request was sent to
     the Correct Organisation for an explanation on how Payment
     Handlers are identified
  o  the Brand List Component to include is the one identified by
     the BrandListRef attribute of the Payment Component  for the
     second payment
  o  the Brand Selection Component to include from the Offer
     Response Block is the one that contains an Element Reference
     (see section 3.5) which identifies the Brand List Component
     for the second payment

8.6.12 Signature Block (Payment Request - second payment)

  If the Baseline Value Exchange Offer Response Block or the Payment
  Response Block for the first payment was signed then the IOTP Message
  that contains the Payment Request Block for the second payment must
  also contain a Signature Block with a copy of:
  o  the "Offer Response" Signature Component, if present, and/or
  o  the "Payment Receipt" Signature Component copied from the
     Payment Response Block for the first payment, if present.

8.6.13 Payment Exchange Block (second payment)

  The Payment Exchange Block (see section 7.7) for the second payment
  contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data for the payment method being used
     by the second payment. See the Payment Method supplement for
     the payment method being used to determine what this should
     contain.

8.6.14 Payment Response Block (second payment)

  The Payment Response Block for the second payment (see section 7.8)
  contains:

  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify the
     second payment occurred
  o  one Payment Scheme Component (see section 6.9) if required by
     the payment method used by the second payment which contains
     payment method specific data. See the Payment Method
     supplement for the payment method being used to determine what
     this should contain
  o  all the Signature Components (see section 6.18) from the
     Payment Request Block for the second payment if present

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.6.15 Signature Block (Payment Response - second payment)

  If a signed Payment Receipt is being provided for the second payment,
  indicated by the SignedPayReceipt attribute of the Payment Component
  for the second payment in the Offer Response Block being set to True,
  then the IOTP Message that contains the Payment Response Block for the
  second payment must also contain a Signature Block with a "Payment
  Receipt" Signature Component which contains hashes of the following:
  o  the Transaction Reference Block (see section 3.3) for the IOTP
     Message which contains the first usage of the Payment Response
     Block for the second payment,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies
     the IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
     for the second payment
  o  the Status Component from the Payment Response Block for the
     second payment, and
  o  the other Components referenced by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component for
     the second payment,
  o  any Trading Role Data Components in the Payment Response Block
  o  the "Offer Response" Signature Component from the Payment
     Request Block for the second payment, if present, and
  o  the "Payment Receipt" Signature Component from the Payment
     Request Block for the first payment, if present.

8.6.16 Baseline Value Exchange Signatures

  The use of signatures to ensure the integrity of a Baseline Value
  Exchange is illustrated by the diagram below.

Signature generated                  OtpMsg (TPO)
by Merchant ensures                  - Trans Ref Block
integrity of the Offer -------->  -  - Signature Block
                                 |   - TPO Block              MERCHANT
                                 |   - Offer Response Block
                                 |
Signature generated by           |
the Payment Handler of           |   OtpMsg (Pay Resp 1)
the first payment binds          |   - Trans Ref Block         PAYMENT
Pay Receipt for the first ----->  -> - Signature Block -----   HANDLER
payment to the Offer                 - Pay Response Block 1 |    1
                                                            |
Signature generated by                                      |
the Payment Handler of           OtpMsg (Pay Resp 2)        |  PAYMENT
the second payment binds           - Trans Ref Block        |  HANDLER
the second payment to the ----->   - Signature Block <------     2
first payment and therefore        - Pay Response Block 2
to the Offer

  Figure 38 Baseline Value Exchange Signatures

  If signatures are used then the Payment Handlers should check that all
  Signature Components they receive are valid (see section 5 Security
  Considerations).

8.7 Payment Instrument Customer Care IOTP Transaction

  An IOTP  Payment Instrument Customer Care Transaction is used to
  provide Payment Brand or Payment Method specific customer care. It
  allows Consumer Payment Brand software to exchange information with a
  Payment Instrument Customer Care Provider.

  The circumstances under which this transaction is used, if any, is
  defined in the IOTP Supplement for the Payment Brand.

  Note that the IOTP Payment Instrument Customer Care Transaction:
  o  is initiated by the Consumer Payment Brand software which must
     identify the need for the transaction to occur. Note that in
     other IOTP Transactions, the transaction is initiated by the
     Merchant
  o  has no TPO Block, as it is initiated by the Consumer
  o  relies on the Consumer Payment Brand software to identify the
     net location of the Payment Instrument Customer Care Provider
     to which the first message in the transaction must be sent
  o  ends when the Payment Scheme Customer Care Service determines
     that the exchange of messages with the Consumer is to stop.

  Note that a Payment Instrument Customer Care Transaction can be
  initiated at any time by a Consumer including in the middle of another
  IOTP Transaction. In this case, the transaction shall establish a
  different transport session from the ongoing transaction. See the
  Mapping to Transport for the Transport Mechanism being used.

  The transaction consists of three types of IOTP messages as
  illustrated in the figure below.

        CONSUMER              OTP MESSAGE         PAYMENT INSTRUMENT
  (PAYMENT INSTRUMENT                               CUSTOMER CARE
         USER)                                         PROVIDER

1. Consumer Payment Instrument Software
  identifies need to contact Payment
Instrument Customer Care Provider then
 generates data to place in a Payment
Instrument Customer Care Request Block
  and the net location it needs to be
  sent to. OTP aware application uses
data to generate the Payment Instrument
Customer Care Request Block then sends
   it to the Customer Care Provider.
                   |
                   v
OtpMsg: Trans Ref                     2. Payment Instrument Customer
 Block; Signature  -------------->   Care Provider processes Payment
Block (Optional);      Payment      Instrument  Customer Care Request
Payment Instrument    Instrument       Block, and starts exchanging
Cust Care Request     Cust. Care     Payment Instrument Customer Care
      Block            Request          Exchange Blocks, with the
                                                Consumer.
                                                          |
                                                          v
3. Consumer keeps on OtpMsg: Trans                      OtpMsg: Trans
 exchanging Payment    Ref Block;   <----------------->  Ref Block;
Instrument Customer Signature Block Payment Instrument Signature Block
Care Exchange Blocks   (optional)   Cust. Care Exchange  (optional)
    with Payment        Payment                            Payment
Instrument Customer    Instrument                        Instrument
   Care Provider       Cust. Care                        Cust. Care
                     Exchange Block                    Exchange Block
                                                           |
                                                           v
                                    4. Eventually Payment Instrument
                                     Customer Care Provider software
                                      identifies Payment Instrument
                                    Customer Care Exchanges finished
                                    so generates a Payment Instrument
                                      Customer Care Response Block,
                                      sends it to the Consumer and
                                                 stops.
                                                     |
                                                     v
 5. Consumer checks Pay                          OtpMsg: Trans Ref
Instrument Response is OK,  <----------------  Block; Signature Block
    optionally keeps            Payment             (Optional);
   information on OTP          Instrument        Payment Instrument
 Transaction for record        Cust. Care       Cust. Care Response

keeping purposes and stops      Response               Block
           |                                             |
           v                                             v
         STOP                                          STOP

  Figure 39 IOTP Payment Instrument Customer Care Transaction Message
  Flows

  The remainder of this sub-section on the Payment Instrument Customer
  Care Transaction defines the contents of each Trading Block.

8.7.1 Payment Instrument Customer Care Request Block

  The Payment Instrument Customer Care Request Block contains:
  o  a Payment Method Information Component (see section 6.14)
     which describes the Payment Method for which Customer Care is
     requested, and
  o  zero or more optional Payment Scheme Components (see section
     6.9) which contain optional Payment scheme data

8.7.2 Payment Instrument Customer Care Exchange Block

  The Payment Instrument Customer Care Exchange Block contains:
  o  a Payment Method Information Component (see section 6.14)
     which describes the Payment Method for which Customer Care is
     being provided, and
  o  zero or more optional Payment Scheme Components (see section
     6.9) which contain optional Payment scheme data

8.7.3 Payment Instrument Customer Care Response Block

  The Payment Instrument Customer Care Response Block contains:
  o  a Payment Method Information Component (see section 6.14)
     which describes the Payment Method for which Customer Care is
     complete, and
  o  zero or more optional Payment Scheme Component (see section
     6.9) which contains optional Payment scheme data

8.7.4 Signature Block

  Any of the IOTP Messages which contain Payment Instrument Customer
  care blocks may also include a Signature Block (see section 7.18)
  containing a Signature Component (see section 6.18). How these are
  used and what it signs is dependent on the Payment Brand and Payment
  method being used. See the IOTP Payment Supplement for the payment
  method.

8.8 Baseline Transaction Status Inquiry IOTP Transaction

  The Baseline IOTP Transaction Status Inquiry provides a Consumer with
  information on the status of an existing or complete IOTP transaction.

  The Trading Blocks used by the Baseline Transaction Status Inquiry
  Transaction are:
  o  an Inquiry Request Trading Block (see section 7.14), and
  o  an Inquiry Response Trading Block (see section 7.15).

  [Note]   Note that:

       . Consumer Inquiries on Authentication transaction are not
         supported.

       . Authentication of Consumers as part of an inquiry is not
         supported in the Baseline version of IOTP.
  [Note End]

8.8.1 Which Trading Roles can receive Inquiry Requests

  The Consumer can send a Transaction Status Inquiry Block to the
  appropriate Trading Role after the following events have occurred:
  o  to the Merchant, after sending TPO Selection Block,
  o  to the Payment Handler, after sending Payment Request Block,
  o  to the Delivery Handler, after sending Delivery Request Block.

  [Note]   IOTP does not support sending Inquiry Requests to the
           Consumer since the consumer may not be on-line to receive
           and process them.
  [Note End]

  If the Consumer is inquiring on transaction that is not yet complete,
  it should send the Inquiry Request Block to the Trading Role to which
  it sent the last IOTP message. If the Consumer is inquiring on a
  transaction which is complete, there are two alternatives in deciding
  the Trading Roles that the Inquiry Request Block should be sent to:
  o  the Consumer IOTP software can ask the end user to determine
     the type of inquiry they want to make, or
  o  the Consumer IOTP software can send the inquiry request
     message to all the Trading Roles that were involved in the
     IOTP transaction.

  For the second case above, how the Consumer IOTP Aware Application
  displays the inquiry response data received from each Trading Role is
  up to each implementation.

8.8.2 Transaction Status Inquiry Transport Session

  For a Transaction Status Inquiry on an ongoing transaction, the
  Consumer shall establish with a Trading Role, a different transport
  session from the ongoing transaction. For a Transaction Status Inquiry
  on a past transaction, how the IOTP module on the software at the
  Trading Role is started upon the receipt of Inquiry Request message is
  defined in each Mapping to Transport supplement for IOTP.

8.8.3 Transaction Status Inquiry Error Handling

  Errors in a Transaction Status Inquiry can be categorised into one the
  following three cases:
  o  Business errors (see section 4.2) in the original (inquired)
     messages
  o  Technical errors (see section 4.1) - both IOTP and payment
     scheme specific ones - in the original IOTP (inquired)
     messages
  o  Technical errors in the message containing the Inquiry Request
     Block itself

  The following outlines what the software should do in each case

     Business errors in the original messages

  Return an Inquiry Response Block containing the Status Component which
  was last sent to the Consumer.

     Technical errors in the original messages

  Return an Inquiry Response Block containing a Status Component. The
  Status Component should contain a ProcessState attribute set to
  ProcessError. In this case send back an Error Block indicating where
  the error was found in the original message.

     Technical errors in the Inquiry Request Block

  Return an Error message. That is, send back an Error Block containing
  the Error Code (see section 6.19.2) which describes the nature of the
  error in the Inquiry Request message.

8.8.4 Inquiry Transaction Messages

  The following Figure outlines the Baseline IOTP Transaction Status
  Inquiry processes on both Consumer and Service Provider sides.

         CONSUMER               OTP MESSAGE         TRADING ROLE
 1. The Consumer decides to inquire                     (Merchant,
   on an OTP transaction by, for                     Payment Handler,
example, cliking the inquiry button                  Delivery Handler
 of the OTP Aware Application. This                    or Financial
   will then generate an Inquiry                       Institution)
  Request Block and send it to the
     appropriate Trading Role.
        |
        v
 OtpMs: Trans Ref                   2. The Trading Role checks the
  Block; Inquiry   ---------->  transaction status of the transaction
  Request Block      Inquiry     that is being inquired upon by using
                     Request     the Transaction Id Component of the
                                 Transaction Reference Block. He then
                                  generates the appropriate Inquiry
                                Response Block based on the status of
                                the transaction and sends the message
                                         back to the Consumer
                                                          |
                                                          v
     3. The OTP Aware                             OtpMsg: Trans Ref
 Application displays the    <----------------     Block; Inquiry
 status information to the   Inquiry Response      Response Block
         end user
             |
             v
           STOP

  Figure 40 Baseline Transaction Status Inquiry

  The remainder of this sub-section on the Baseline Transaction Status
  Inquiry IOTP Transaction defines the contents of each Trading Block.

8.8.5 Transaction Reference Block

  The Consumer must use the same Transaction Id Component (see section
  3.3.1) as in the inquired transaction. The OtpTransId attribute in
  this component serves as the key in querying the transaction logs
  maintained at the Trading Role's site. The value of the ID attribute
  of the Message Id Component should be different from those of the
  inquired transaction (see section 3.4.1).

8.8.6 Inquiry Request Block

  The Inquiry Request Block (see section 7.14) contains the following
  components:
  o  one Inquiry Type Component (see section 6.17). This identifies
     whether the inquiry is on an offer, payment, or delivery.
  o  zero or one Payment Scheme Component (see section 6.9). This
     is for encapsulating payment scheme specific inquiry messages
     for inquiries on payment.

8.8.7 Inquiry Response Block

  The Inquiry Response Block (see section 7.15) contains the following
  components:

  o  one Status Component (see section 6.15). This component hold
     the status information on the inquired transaction,
  o  zero or one Payment Scheme Components. These contain for
     encapsulated payment scheme specific inquiry messages for
     inquiries on payment.

8.9 Baseline Ping IOTP Transaction

  The purpose of the Baseline IOTP Ping Transaction is to enable IOTP
  aware application software to determine if the IOTP aware application
  at another Trading Role is operating and verifying whether or not
  signatures can be handled.

  The Trading Blocks used by the Baseline Ping IOTP Transaction are:
  o  a Ping Request Block (see section 7.16)
  o  a Ping Response Block (see section 7.17), and
  o  a Signature Block (see section 7.18).

8.9.1 Ping Messages

  The following figure outlines the message flows in the Baseline IOTP
  Ping Transaction.

     OTP TRADING ROLE           OTP MESSAGE       OTP TRADING ROLE
 1. The OTP Aware Application in an
 OTP Trading Role decides to  check
    whether the counterparty OTP
 application is up and running. It
generates a Ping Block and optional
 Signature Block and sends them to
    the other OTP Trading Role.
                 |
                 v
 OtpMs: Trans Ref  -------->   2. The OTP Trading Role which receives
   Block; Ping        Ping       the Ping Request generates a Ping
  Request Block     Request      Response and sends it back to the
                                sender of the original Ping Request.
                                                       |
                                                       v
  3. The original sender of the                    OtpMsg: Trans Ref
Ping Request checks the returned   <------------      Block; Ping
     Ping Response and takes       Ping Response     Response Block
appropriate action, if necessary
                |
                v
              STOP

  Figure 41 Baseline Ping Messages
  The verification that signatures can be handled is indicated by the
  sender of the Ping Request Block including:
  o  Organisation Components that identify itself and the intended
     recipient of the Ping Request Block, and
  o  a Signature Block that signs data in the Ping Request.

  In this way the receiver of the Ping Request:
  o  knows who is sending the Ping Request and can therefore verify
     the Signature on the Request, and
  o  knows who to generate a signature for on the Ping Response.

  Note that a Ping Request:
  o  does not affect any on-going transaction
  o  does NOT start an IOTP aware application, unlike other IOTP
     transaction messages such as TPO or Transaction Status
     Inquiry.

  All IOTP aware applications must return a Ping Response message to the
  sender of a Ping Request message when it is received.

  A Baseline IOTP Ping request can also contain an optional Signature
  Block. IOTP aware applications can, for example, use the Signature
  Block to check the recipient of a Ping Request can successfully
  process and check signatures it has received.

  For each Baseline Ping IOTP Transaction, each IOTP role shall
  establish a different transport session from other IOTP transactions.

  Any IOTP Trading Role can send a Ping request to any other IOTP
  Trading Role at any time it wants. A Ping message has its own
  OtpTransID, which is different from other IOTP transactions.

  The remainder of this sub-section on the Baseline Ping IOTP
  Transaction defines the contents of each Trading Block.

8.9.2 Transaction Reference Block

  The OtpTransId of a Ping transaction should be different from any
  other IOTP transaction.

8.9.3 Ping Request Block

  If the Ping Transaction is anonymous then no Organisation Components
  are included in the Ping Request Block (see section 7.6).

  If the Ping Transaction is not anonymous then the Ping Request Block
  contains Organisation Components for:
  o  the sender of the Ping Request Block, and
  o  the verifier of the Signature Component
  If Organisation Components are present, then it indicates that the
  sender of the Ping Request message has generated a Signature Block.
  The signature block must be verified by the Trading Role that receives
  the Ping Request Block.

8.9.4 Signature Block (Ping Request)

  The Ping Request Signature Block (see section 7.18) contains the
  following components:
  o  one Signature Component (see section 6.18)
  o  one or more Certificate Components, if required.

8.9.5 Ping Response Block

  The Ping Response Block (see section 7.17) contains the following
  component:
  o  the Organisation Component of the sender of the Ping Response
     message

  If the Ping Transaction is not anonymous then the Ping Response
  additionally contains:
  o  copies of the Organisation Components contained in the Ping
     Request Block.

8.9.6 Signature Block (Ping Response)

  The Ping Response Signature Block (see section 7.18) contains the
  following components:
  o  one Signature Component (see section 6.18)
  o  one or more Certificate Components, if required.

9. Retrieving Logos

  This section describes how to retrieve logos for display by IOTP aware
  software using the Logo Net Locations attribute contained in the Brand
  Element (see section 6.6.1) and the Organisation Component (see
  section 6.5).

  The full address of a logo is defined as follows:
Logo_address ::= Logo_net_location "/" Logo_size
                                    Logo_color_depth ".GIF"

  Where:
  o  Logo_net_location is obtained from the LogoNetLocn attribute
     in the Brand Element (see section 6.6.1) or the Organisation
     Component. Note that:

     - the content of this attribute is dependent on the Transport
       Mechanism (such as  HTTP) that is used. See the Transport
       Mechanism supplement,
     - implementers should check that if the rightmost character of
       Logo Net Location is set to right-slash "/" then another, right
       slash should not be included when generating the Logo Address,
  o  Logo_size identifies the size of the logo,
  o  Logo_color_depth identifies the colour depth of the logo
  o  "GIF" indicates that the logos are in GIF format

  Logo_size and Logo_color_depth are specified by the implementer of the
  IOTP software that is retrieving the logo depending on the size and
  colour that they want to use.

9.1 Logo Size

  There are five standard sizes for logos. The sizes in pixels and the
  corresponding values for Logo Size are given in the table below.

          Size in     Logo Size
          Pixels        Value

       32 x 32 or   exsmall
       32 x 20

       53 x 33      small

       103 x 65     medium

       180 x 114    large

       263 x 166    exlarge

9.2 Logo Color Depth

  There are three standard colour depths. The colour depth (including
  bits per pixel) and the corresponding value for Logo_Color_Depth are
  given in the table below.

               Color Depth          Logo Color
            (bits per pixel)        Depth Value

        4 (16 colors)            4

        8 (256 colors)           nothing

        24 (16 million colors)   24
  Note that if Logo Color Depth is omitted then a logo with the default
  colour depth of 256 colours will be retrieved.

9.3 Logo Net Location Examples

  If Logo Net Location was set to "ftp://logos.xzpay.com", then:
  o  "ftp://logos.xzpay.com/medium.gif" would retrieve a medium
     size 256 colour logo
  o  "ftp://logos.xzpay.com/small4.gif" would retrieve a small size
     16 colour logo

  [Note]   Organisations which make logos available for use with IOTP
           should always make available "small" and "medium" size logos
           and use the GIF format.
  [Note End]

10. Brand List Examples

  This example contains three examples of the XML for a Brand List
  Component. It covers:
  o  a simple credit card based example
  o  a credit card based brand list including promotional credit
     card brands, and
  o  a complex electronic cash based brand list

  Note that:
  o  brand lists can be as complex or as simple as required
  o  all example techniques described in this appendix can be
     included in one brand list.

10.1 Simple Credit Card Based Example

  This is a simple example involving:
  o  only major credit card payment brands
  o  a single price in a single currency
  o  a single payment handler, and
  o  a single payment protocol

<BrandList ID='M1.2'
  XML:Lang='us-en'
  ShortDesc='Purchase book including s&h'
  PayDirection='Debit' >
  <Brand ID ='M1.30'
    BrandId='MC'
    BrandName='MasterCard'
    BrandLogoNetLocn='ftp:otplogos.mastercard.com'
    ProtocolAmountRefs='M1.33'>
  </Brand>
  <Brand ID ='M.31'
    BrandId='Visa'
    BrandName='Visa'
    BrandLogoNetLocn='ftp:otplogos.visa.com'
    ProtocolAmountRefs='M1.33'>
  </Brand>
  <Brand ID ='M1.32'
    BrandId='Amex'
    BrandName='American Express'
    BrandLogoNetLocn='ftp:otplogos.amex.com'
    ProtocolAmountRefs ='M1.33' >
  </Brand >
  <ProtocolAmount ID ='M1.33'
    PayProtocolRef='M1.35'
    CurrencyAmountRefs='M1.34'>
  </ProtocolAmount>
  <CurrencyAmount ID ='M1.34'
    Amount='10.95'
    CurrCode='USD'/>
  <PayProtocol ID ='M1.35'
    ProtocolId='SCCD1.0'
    ProtocolName='Secure Channel Credit/Debit'
    PayReqNetLocn='http://www.merchant.com/etill/sccd1' >
  </PayProtocol>
</BrandList>

10.2 Credit Card Brand List Including Promotional Brands

  An example of a Credit Card based Brand List follows. It includes:
  o  two ordinary card association brands and two promotional
     credit card brands. The promotional brands consist of one
     loyalty based (British Airways MasterCard) which offers
     additional loyalty points and one store based (Walmart) which
     offers a discount on purchases over a certain amount
  o  two payment protocols:
     - SET (Secure Electronic Transactions) see [SET], and
     - SCCD (Secure Channel Credit Debit) see [SCCD].

<BrandList ID='M1.2'
  XML:Lang='us-en'
  ShortDesc='Purchase ladies coat'
  PayDirection='Debit' >
  <Brand ID ='M1.3'
    BrandId='MC'
    BrandName='MasterCard'
    BrandLogoNetLocn='ftp:otplogos.mastercard.com'
    ProtocolAmountRefs='M1.7 M1.8'>
  </Brand>
  <Brand ID ='M1.4'
    BrandId='Visa'
    BrandName='Visa'
    BrandLogoNetLocn='ftp:otplogos.visa.com'
    ProtocolAmountRefs='M1.7 M1.8'>
  </Brand>
  <Brand ID ='M1.5'
    BrandId='MC/BritishAirways'
    BrandName='British Airways MasterCard'
    BrandLogoNetLocn='ftp:otplogos.britishairways.co.uk'
    BrandNarrative='Double air miles with British Airways
                                    MasterCard'
    ProtocolAmountRefs ='M1.7 M1.8' >
  </Brand >
  <Brand ID ='M1.6'
    BrandId='Walmart'
    BrandName='Walmart Store Card'
    BrandLogoNetLocn='ftp:otplogos.walmart.com'
    BrandNarrative='5% off with your Walmart Card
                   on purchases over $150'
    ProtocolAmountRefs='M1.7'>
  </Brand>
  <ProtocolAmount ID ='M1.7'
    PayProtocolRef='M1.10'
    CurrencyAmountRefs='M1.9' >
    <PackagedContent Transform="BASE64">
       238djqw1298erh18dhoire
    <PackagedContent>
  </ProtocolAmount>
  <ProtocolAmount ID ='M1.8'
    PayProtocolRef='M1.11'
    CurrencyAmountRefs='M1.9' >
    <PackagedContent Transform="BASE64">
       238djqw1298erh18dhoire
    <PackagedContent Transform="BASE64">
  </ProtocolAmount>
  <CurrencyAmount ID ='M1.9'
    Amount='157.53'
    CurrCode='USD'/>
  <PayProtocol ID ='M1.10'
    ProtocolId='SET1.0'
    ProtocolName='Secure Electronic Transaction Version 1.0'
    PayReqNetLocn='http://www.merchant.com/etill/set1' >
    <PackagedContent Transform="BASE64">
      8ueu26e482hd82he82
    <PackagedContent Transform="BASE64">
  </PayProtocol>
  <PayProtocol ID ='M1.11'
    ProtocolId='SCCD1.0'
    ProtocolName='Secure Channel Credit/Debit'
    PayReqNetLocn='http://www.merchant.com/etill/sccd1' >
    <PackagedContent Transform="BASE64">
       82hd82he8226e48ueu
    <PackagedContent Transform="BASE64">
  </PayProtocol>
 </BrandList>

10.3 Brand Selection Example

  In order to pay by 'British Airways' MasterCard using the example
  above using SET and therefore getting double air miles, the Brand
  Selection would be:

<BrandSelection ID='C1.2'
  BrandListRef='M1.3'
  BrandRef='M1.5'
  ProtocolAmountRef='M1.7'
  CurrencyAmountRef='M1.9' >
</BrandSelection>

10.4 Complex Electronic Cash Based Brand List

  The following is an fairly complex example which includes:
  o  payments using either Mondex, GeldKarte, CyberCash or DigiCash
  o  in currencies including US dollars, British Pounds, Italian
     Lira, German Marks and Canadian Dollars
  o  a discount on the price if the payment is made in Mondex using
     British pounds or US dollars, and
  o  more than one payment handler is used for payments involving
     Mondex or CyberCash
  o  support for more than one version of a CyberCash CyberCoin
     payment protocol.

<BrandList ID='M1.2'
  XML:Lang='us-en'
  ShortDesc='Company report on XYZ Co'
  PayDirection='Debit' >
  <Brand ID ='M1.13'
    BrandId='MX'
    BrandName='Mondex Electronic Cash'
    BrandLogoNetLocn='ftp:otplogos.mondex.com'
    ProtocolAmountRefs='M1.17 M1.18'>
  </Brand>
  <Brand ID ='M1.14'
    BrandId='GK'
    BrandName='GeldKarte Electronic Cash'
    BrandLogoNetLocn='ftp:otplogos.geldkarte.co.de'
    ProtocolAmountRefs='M1.19'>
  </Brand>
  <Brand ID ='M1.15'
    BrandId='CCash'
    BrandName='CyberCoin Eletronic Cash'
    BrandLogoNetLocn='ftp:otplogos.cybercash.com'
    ProtocolAmountRefs ='M1.20' >
  </Brand >
  <Brand ID ='M1.16'
    BrandId='DigiCash'
    BrandName='DigiCash Electronic Cash'
    BrandLogoNetLocn='ftp:otplogos.digicash.com'
    BrandNarrative='5% off with your Walmart Card
                   on purchases over $150'
    ProtocolAmountRefs='M1.22'>
  </Brand>
  <ProtocolAmount ID ='M1.17'
    PayProtocolRef='M1.31'
    CurrencyAmountRefs='M1.25 M1.29'>
  </ProtocolAmount>
  <ProtocolAmount ID ='M1.18'
    PayProtocolRef='M1.32'
    CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
  </ProtocolAmount>
  <ProtocolAmount ID ='M1.19'
    PayProtocolRef='M1.35'
    CurrencyAmountRefs='M1.28'>
  </ProtocolAmount>
  <ProtocolAmount ID ='M1.20'
    PayProtocolRef='M1.34 M1.33'
    CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
  </ProtocolAmount>
  <ProtocolAmount ID ='M1.21'
    PayProtocolRef='M1.36'
    CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
  </ProtocolAmount>
  <CurrencyAmount ID ='M1.23'
    Amount='20.00'
    CurrCode='USD'/>
  <CurrencyAmount ID ='M1.24'
    Amount='12.00'
    CurrCode='GBP'/>
  <CurrencyAmount ID ='M1.25'
    Amount='19.50'
    CurrCode='USD'/>
  <CurrencyAmount ID ='M1.26'
    Amount='11.75'
    CurrCode='GBP'/>
  <CurrencyAmount ID ='M1.27'
    Amount='36.00'
    CurrCode='DEM'/>
  <CurrencyAmount ID ='M1.28'
    Amount='100.00'
    CurrCode='FFR'/>
  <CurrencyAmount ID ='M1.29'
    Amount='22.00'
    CurrCode='CAD'/>
  <CurrencyAmount ID ='M1.30'
    Amount='15000'
    CurrCode='ITL'/>
  <PayProtocol ID ='M1.31'
    ProtocolId='MXv1.0'
    ProtocolName='Mondex IOTP Protocol Version 1.0'
    PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
  </PayProtocol>
  <PayProtocol ID ='M1.32'
    ProtocolId='MXv1.0'
    ProtocolName='Mondex IOTP Protocol Version 1.0'
    PayReqNetLocn='http://www.mxbankuk.com/vserver' >
  </PayProtocol>
  <PayProtocol ID ='M1.33'
    ProtocolId='Ccashv1.0'
    ProtocolName='CyberCash Version 1.0'
    PayReqNetLocn='http://www.ccash.com/ccoin' >
  </PayProtocol>
  <PayProtocol ID ='M1.34'
    ProtocolId='CCashv2.0'
    ProtocolName='CyberCash Version 2.0'
    PayReqNetLocn='http://www.ccash.com/ccoin' >
  </PayProtocol>
  <PayProtocol ID ='M1.35'
    ProtocolId='GKv1.0'
    ProtocolName='GeldKarte Version 1.0'
    PayReqNetLocn='http://www.merchant.com/pgway' >
  </PayProtocol>
  <PayProtocol ID ='M1.36'
    ProtocolId='DCashv1.0'
    ProtocolName='DigiCash Protocol Version 1.0'
    PayReqNetLocn='http://www.merchant.com/digicash' >
  </PayProtocol>
  </BrandList>

11. XML Overview

  This section contains an overview of [XML]. Its purpose is to provide
  sufficient explanation so that the XML examples in this document may
  be understood. This description is not complete. For more detail and
  the full specification see the reference contained in the Preface to
  this document.

  XML is based on SGML has the goal of enabling "generic SGML to be
  served, received, and processed on the Web in the way that is now
  possible with HTML. XML has been designed for ease of implementation
  and for interoperability with both SGML and HTML."

  XML is designed as a universal, open data format for the Internet and
  allows the structure of data in messages to be clearly and
  unambiguously defined.

  In the following examples, underlined words are to be replaced by
  proper names; for example, document name could be OtpMessage,
  EDIMessage, and so on.

  The structure of data in XML is defined using a number of key
  components. These are:
  o  document definitions
  o  element declarations and
  o  attribute declarations.

  These are described below.

11.1 Document Definition

  A document definition has the following form:

<!DOCTYPE DocumentName [DocumentStructureDefinition] >

DocumentName       For IOTP this is always OtpMessage.

DocumentStructure  This contains the declarations of elements,
Definition         attributes and entities.

  For example:

<!DOCTYPE X [
  <!ELEMENT Y (Y1, Y2) >
  <!ATTLIST Y ('a' | 'b' | 'c') 'a' >
  <!ELEMENT Z (Z1 | Z2) >
  <!ATTLIST Z CDATA #REQUIRED>
]>

11.2 Element Declaration

  An element declaration has the following form:

<!ELEMENT ElementName (ElementContents)>

ElementContent     This defines the relationships among the elements,
                   the order of occurrences of the elements, and
                   their number of occurrences.

11.2.1 Example 1

  An element X consists of elements A, B, and C in that order. This
  would be declared as follows:

<!ELEMENT X (A, B, C) >

  If the elements A, B, and C can appear in any order, "&" is used in
  place of ",".

  As XML this would be expressed as follows:

<X>
  <A> DataA </A>
  <B> DataB </B>
  <C> DataC </C>
</X>

  In this example
  o  "<X>" is a start tag and "</x>" is an end tag
  o  "DataA", "DataB", and "DataC" is the content of the element
     and can consist of other elements, or character data or may
     even be empty.

11.2.2 Example 2

  An element X consists of one of the elements A, B, or C. This would be
  declared as follows:

<!ELEMENT X ( A | B | C ) >

  If element A is selected then this would be expressed as:

<X>
  <A> DataA </A>
</X>

11.2.3 Example 3

  An element X consists of element A occurring zero or more times and
  element B occurring one or more times in that order. This would be
  declared as follows:

<!ELEMENT X ( A*, B+ ) >

  The "*" indicates zero or more, and the "+" indicates one or more.

  If A occurred zero times and b occurred twice then this would be
  expressed as:

<X>
  <B> DataB </B>
  <B> DataB </B>
</X>

11.2.4 Data Types used in element declarations

  The previous examples described how one element can be defined as
  having "children" elements. In element declarations XML also supports
  data types. The data types used in this IOTP specification are shown
  below.

    Data Types                         Descriptions

#PCDATA            The element content contains data which the XML
                   parser can search to look for tags or entity
                   declarations.

ANY                The element content can contain any element
                   defined in any order.

EMPTY              The element content contains no data.

11.3 Attribute declarations

  Attribute declarations describe information about an element. More
  than one attribute can be defined for one element. Attributes are
  contained within the start tag of an element. They are defined as
  follows:

<!ATTLIST ElementName AttributeName1 DeclaredValue1
                                    DefaultValue1
           AttributeName2 DeclaredValue2 DefaultValue2
                   ...
           AttributeNameN DeclaredValueN DefaultValueN >

11.3.1 Declared value

  When the permissible values of an attribute are known, those values
  are declared as a list in the declared value.

  When the list of permissible values are not pre-defined, data types
  are specified instead. The data types which can be used for attribute
  declarations are listed below. Only the ones used in this IOTP
  specification are shown.

  Attribute Types                      Descriptions

CDATA              Character data. Characters other than attribute
                   value delimiters such as (_ ') can be used.
                   Characters of zero length are allowed.

NMTOKEN            An attribute which conforms with the rules for an
                   XML name. In outline it must start with a letter
                   and be followed by any combination of letters,
                   digits, or a few special characters. No spaces are
                   allowed

NMTOKENS           One or more NMTOKEN separated by spaces.

ID                 Identifier. This value of this attribute is unique
                   for each element.

IDREF              This value of this attribute matches the value of
                   some ID attribute of an element in the same XML
                   document. It is used to point to that element.

IDREFS             One or more IDREFs separated by spaces.

11.3.2 Default value

  Default values indicate whether or not the attribute must be present
  in an element.

  For default values, the following default keywords as well as some
  concrete values can be specified. Only the default keywords used in
  this IOTP specification are shown.

      Values                           Descriptions

#REQUIRED          CANNOT abbreviate. Some value must be specified
                   for this attribute.

#IMPLIED           When an attribute with this default value is not
                   specified, the application gives the pre-
                   determined attribute value.

'value'            The 'value specified is the default. Other values
                   may be used.

#FIXED 'value'     The value must and can only be the value specified

Example

  An example of an attribute declaration follows:

<!ATTLIST X
  Att1 ( A, B ) #REQUIRED >
  In this example a value for ATT1 must be present as it is "#REQUIRED"
  and it must be either "A" or "B" for the XML document to be valid. For
  example:

<X Att1='B'> DataX </X>

12. Open Trading Protocol Data Type Definition

  This section contains a copy of the XML DTD for the Open Trading
  Protocols for information purposes.

  The master copy of the DTD for IOTP, which should be relied upon is
  available for download from the IOTP web site (http://www.IOTP.org).

<!--
******************************************************
*                                                    *
* OPEN TRADING PROTOCOL DTD VERSION 1.0              *
*                                                    *
* Changes from version 0.9.9                          *
*    - corrects typos in OTP Message and             *
*      Payment Method Information component          *
*    - adds "place holder" definitions of OtpSig and *
*      OtpCert Components                            *
*    - adds Status Component to the Delivery Request *
*      block                                         *
*    - moves the Status Component to the start of the*
*      content of the Offer Response Block to make it*
*      consistent with other Response and Request    *
*      blocks                                        *
*    - adds the Status Component to the Payment      *
*      Request Block                                 *
*    - adds the PayReceiptRefs attribute to the      *
*      Payment Receipt Component                     *
*    - changes the Type of the Content Attribute of  *
*      the PackagedContent element to CDATA from     *
*      NMTOKEN                                       *
*    - adds the Trading Role Data Component          *
*    - adds the Trading Role Data Component to the   *
*      Offer Response, Payment Request, Payment      *
*      Response and Delivery Request Blocks          *
*    - adds Payment Note Component                   *
*    - adds the Payment Note Component to the        *
*      response block                                *
*    - adds an Org Component to the Authentication   *
*      Request Block                                 *
*    - adds an Org Component and a Status Component  *
*      to the Authentication Request Block           *
*    - adds a TradingRoleList and AuthenticationId   *
*      attributes to the Authentication Data         *
*      Component                                     *
*    - adds Authentication as a valid value of the   *
*      StatusType attribute of the Status Component  *
*    - removes ErrorNetLocn and CancelNetLocn attri- *
*      butes from the Protocol Options Component     *
*    - adds the CancelNetLocn attribute to the       *
*      Trading Role element                          *
*                                                    *
* Copyright Open Trading Protocol Consortium ,1998   *
* (note copyright will be assigned to IETF/ISOC)     *
******************************************************

******************************************************
* OTP MESSAGE DEFINITION                             *
******************************************************
 -->

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

<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION             *
******************************************************
 -->

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

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

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

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

<!--
******************************************************
* Packaged Content Common Element                    *
******************************************************
 -->

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

<!--
******************************************************
* TRADING COMPONENTS                                 *
******************************************************
 -->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 ShortDesc          CDATA   #REQUIRED
 SenderNetLocn      CDATA   #REQUIRED
 SecureSenderNetLocn CDATA  #REQUIRED
 SuccessNetLocn     CDATA   #REQUIRED >

<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AuthMethod         NMTOKEN #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
 ID                 ID      #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 OrderIdentifier    CDATA   #REQUIRED
 ShortDesc          CDATA   #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 ApplicableLaw      CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?,
     PersonName?, PostalAddress?)>
<!ATTLIST Org
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 OrgId              CDATA   #REQUIRED
 OtpMsgIdPrefix     NMTOKEN #REQUIRED
 LegalName          CDATA   #IMPLIED
 ShortDesc          CDATA   #IMPLIED
 LogoNetLocn        CDATA   #IMPLIED >

<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
 TradingRole        NMTOKEN #REQUIRED
 ErrorNetLocn       CDATA   #IMPLIED
 CancelNetLocn      CDATA   #IMPLIED >

<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
 xml:lang           NMTOKEN #IMPLIED
 Tel                CDATA   #IMPLIED
 Fax                CDATA   #IMPLIED
 Email              CDATA   #IMPLIED
 NetLocn            CDATA   #IMPLIED >

<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
 xml:lang           NMTOKEN #IMPLIED
 Title              CDATA   #IMPLIED
 GivenName          CDATA   #IMPLIED
 Initials           CDATA   #IMPLIED
 FamilyName         CDATA   #IMPLIED >

<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
 xml:lang           NMTOKEN #IMPLIED
 AddressLine1       CDATA   #IMPLIED
 AddressLine2       CDATA   #IMPLIED
 CityOrTown         CDATA   #IMPLIED
 StateOrRegion      CDATA   #IMPLIED
 PostalCode         CDATA   #IMPLIED
 Country            CDATA   #IMPLIED
 LegalLocation (True|False) 'False' >

<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
 CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 ShortDesc          CDATA   #REQUIRED
 PayDirection (Debit|Credit) #REQUIRED >

<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #IMPLIED
 BrandId            NMTOKEN #REQUIRED
 BrandName          CDATA   #REQUIRED
 BrandLogoNetLocn   CDATA   #REQUIRED
 BrandNarrative     CDATA   #IMPLIED
 ProtocolAmountRefs IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
 ID                 ID      #REQUIRED
 PayProtocolRef     IDREF   #REQUIRED
 CurrencyAmountRefs IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
 ID                 ID      #REQUIRED
 Amount             CDATA   #REQUIRED
 CurrCodeType       NMTOKEN 'ISO4217'
 CurrCode           CDATA   #REQUIRED >

<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #IMPLIED
 ProtocolId         NMTOKEN #REQUIRED
 ProtocolName       CDATA   #REQUIRED
 ActionOrgRef       NMTOKEN #REQUIRED
 PayReqNetLocn      CDATA   #IMPLIED
 SecPayReqNetLocn   CDATA   #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
     BrandSelProtocolAmountInfo?,
     BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
 ID                 ID      #REQUIRED
 BrandListRef       NMTOKEN #REQUIRED
 BrandRef           NMTOKEN #REQUIRED
 ProtocolAmountRef  NMTOKEN #REQUIRED
 CurrencyAmountRef  NMTOKEN #REQUIRED >

<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
 ID                 ID      #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
 ID                 ID      #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
 ID                 ID      #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
 ID                 ID      #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 BrandListRef       NMTOKEN #REQUIRED
 SignedPayReceipt (True | False) #REQUIRED
 AuthDataRef        NMTOKEN #IMPLIED
 StartAfter         NMTOKENS #IMPLIED >

<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 ConsumerPaymentId  CDATA   #IMPLIED
 PaymentHandlerPayId CDATA  #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent) >
<!ATTLIST PayReceipt
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED
 PayReceiptRefs     NMTOKENS #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent) >
<!ATTLIST PaymentNote
  ID ID          #REQUIRED
  ContentSoftwareId      CDATA   #IMPLIED >

<!-- DELIVERY COMPONENT -->
<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
<!ATTLIST Delivery
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 DelivExch          (True|False) #REQUIRED
 DelivAndPayResp    (True|False) #REQUIRED
 ActionOrgRef       NMTOKEN #IMPLIED
 ConsumerDeliveryId CDATA   #IMPLIED >

<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
 xml:lang           NMTOKEN #IMPLIED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 DelivMethod        NMTOKEN #REQUIRED
 DelivToRef         NMTOKEN #REQUIRED
 DelivReqNetLocn    CDATA   #REQUIRED
 SecDelivReqNetLocn CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 DelivHandlerDelivId CDATA  #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT METHOD INFORMATION COMPONENT -->
<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
 ID                 ID      #REQUIRED
 BrandId            NMTOKEN #REQUIRED
 PayProtocolId      NMTOKEN #IMPLIED >

<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY >
<!ATTLIST Status
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 StatusType (Offer|Payment|Delivery|
     Authentication) #REQUIRED
 ElRef              NMTOKEN #REQUIRED
 ProcessState (NotYetStarted|InProgress|
     CompletedOk|Failed|ProcessError) #REQUIRED
 CompletionCode     NMTOKEN #IMPLIED
 ProcessReference   CDATA   #IMPLIED
 StatusDesc         CDATA   #IMPLIED >

<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent) >
<!ATTLIST TradingRoleData
  ID                ID      #REQUIRED
  OriginatorElRef   NMTOKEN #REQUIRED
  DestinationElRefs NMTOKENS #REQUIRED >

<!-- INQUIRY TYPE COMPONENT -->
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
 ID                 ID      #REQUIRED
 Type (Offer|Payment|Delivery) #REQUIRED
 ElRef              NMTOKEN #IMPLIED
 ProcessReference   CDATA   #IMPLIED >

<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
 ID                 NMTOKEN #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 ErrorCode          NMTOKEN #REQUIRED
 ErrorDesc          CDATA   #REQUIRED
 Severity (Warning|TransientError|HardError) #REQUIRED
 MinRetrySecs       CDATA   #IMPLIED
 SwVendorErrorRef   CDATA   #IMPLIED >

<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
 ElementType        NMTOKEN #REQUIRED
 OtpMsgRef          NMTOKEN #REQUIRED
 BlkRef             NMTOKEN #IMPLIED
 CompRef            NMTOKEN #IMPLIED
 ElementRef         NMTOKEN #IMPLIED
 AttName            NMTOKEN #IMPLIED >

<!--
******************************************************
* TRADING BLOCKS                                     *
******************************************************
 -->

<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
 ID                 ID      #REQUIRED >

<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
 ID                 ID      #REQUIRED >

<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, AuthData*, Order?,
     Payment*, Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthData?, Org) >
<!ATTLIST AuthReqBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp, Org+, Status) >
<!ATTLIST AuthRespBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, AuthData?, BrandList,
     BrandSelection, Payment, PaySchemeData?, Org*,
     TradingRoleData*) >
<!ATTLIST PayReqBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
 ID                 ID      #REQUIRED >

<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
     TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
 ID                 ID      #REQUIRED >

<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT INSTRUMENT CUSTOMER CARE REQUEST BLOCK -->
<!ELEMENT PayInstCCReqBlk (PayMethodInfoData, PaySchemeData*) >
<!ATTLIST PayInstCCReqBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT INSTRUMENT CUSTOMER CARE EXCHANGE BLOCK -->
<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT INSTRUMENT CUSTOMER CARE RESPONSE BLOCK -->
<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
 ID                 ID      #REQUIRED >

<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
 ID                 ID      #REQUIRED >

<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
 ID                 ID      #REQUIRED
 LastReceivedOtpMsgRef NMTOKEN #IMPLIED
 LastSentOtpMsgRef  NMTOKEN #IMPLIED >

<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
 ID                 ID      #REQUIRED>

<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
 ID                 ID      #REQUIRED
 PingStatusCode (Ok|Busy|Down) #REQUIRED
 SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
 xml:lang           NMTOKEN #IMPLIED
 PingStatusDesc     CDATA   #IMPLIED>

<!-- SIGNATURE BLOCK -->
<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
 ID                 ID      #REQUIRED >

<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
 ID                 ID      #REQUIRED >

<!-- placeholders for content models to come from XMLSIG -->
<!ELEMENT OtpSig (#PCDATA)>

<!ELEMENT OtpCert (#PCDATA)>

13. Glossary

  This section contains a glossary of some of the terms used within this
  specification in alphabetical order.

  NAME             DESCRIPTION

  Authenticator    The organisation which is requesting the
                   authentication of another organisation, and

  Authenticatee    The organisation being authenticated by
                   authenticated by an Authenticator

  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
  NAME             DESCRIPTION
                   Merchant to the Consumer and from which the
                   Consumer makes a selection. Each Brand may have a
                   different Payment Handler. Examples of Brands
                   include:
                    o payment association and proprietary
                      Brands, for example MasterCard, Visa,
                      American Express, Diners Club, American
                      Express, Mondex, GeldKarte, CyberCash,
                      etc.
                    o Promotional Brands (see below). These
                      include:
                    o store Brands, where the Payment
                      Instrument is issued to a Consumer by a
                      particular Merchant, for example Walmart,
                      Sears, or Marks and Spencer (UK)
                    o coBrands, for example American Advantage
                      Visa, where an organisation uses their
                      own Brand in conjunction with, typically,
                      a payment association Brand.

  Consumer         The person or organisation which is to receive
                   and pay for the goods or services

  Delivery         The entity that physically delivers the goods or
  Handler          services to the Consumer on behalf of the
                   Merchant.

  Dual Brand       A Dual Brand means that a single Payment
                   Instrument may be used as if it were two separate
                   Brands. For example there could be a single
                   Japanese "UC" MasterCard which can be used as
                   either a UC card or a regular MasterCard. The UC
                   card Brand and the MasterCard Brand could each
                   have their own separate Payment Handlers. This
                   means that:
                    o the Merchant treats, for example "UC" and
                      "MasterCard" as two separate Brands when
                      offering a list of Brands to the
                      Consumer,
                    o the Consumer chooses a Brand, for example
                      either "UC" or "MasterCard,
                    o the Consumer IOTP aware application
                      determines which Payment Instrument(s)
                      match the chosen Brand, and selects,
                      perhaps with user assistance, the correct
                      Payment Instrument to use.

  IOTP Message     An IOTP Message is a collection of IOTP Trading
                   Blocks which carries the data required to carry
                   out an IOTP Transaction. They are a well formed
                   XML document sent between the Trading Roles that
  NAME             DESCRIPTION
                   are taking part in a trade.

  IOTP             An Internet Open Trading Protocol Transaction is
  Transaction      described as a predefined set of IOTP Messages
                   transferred between the Trading Roles.

  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

  Merchant         The entity that has is involved with customer dispute
  Customer Care    negotiation and resolution on behalf of the
  Provider         Merchant

  Payment          The entity that physically receives the payment
  Handler          from the Consumer on behalf of the Merchant

  Payment          A Payment Instrument is the means by which
  Instrument       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.

  Payment          The entity that resolves problems with a
  Instrument       particular Payment Instrument
  Customer Care
  Provider

  Promotional      A Promotional Brand means that, if the Consumer
  Brand            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
  NAME             DESCRIPTION
                      statement. For example loyalty points in
                      a frequent flyer scheme could be awarded
                      based on the total payments made with the
                      Payment Instrument since the last
                      statement was issued.

                   Each Promotional Brand should be identified as a
                   separate Brand in the list of Brands offered by
                   the Merchant. For example: "Walmart", "Sears",
                   "Marks and Spencer" and "American Advantage
                   Visa", would each be a separate Brand.

  Trading Block    A Trading Block consists of one or more Trading
                   Components. One or more Trading Blocks may be
                   contained within the IOTP Messages which are
                   physically sent in the form of [XML] documents
                   between the different organisations that are
                   taking part in a trade.

  Trading          A Trading Component is collections of XML
  Component        elements and attributes. Trading Components are
                   the child elements of the Trading Blocks.

  Trading Role     A Trading Role identifies the different ways in
                   which organisations can participate in a trade.
                   There are five Trading Roles: Consumer, Merchant,
                   Payment Handler, Delivery Handler, Merchant
                   Customer Care Provider and Payment Instrument
                   Customer Care Provider.

14. Copyrights

  Copyright (C) The Internet Society (1998). All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published and
  distributed, in whole or in part, without restriction of any kind,
  provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not yet been republished be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organisations, except as needed for the purpose of developing
  Internet standards in which case the procedures for copyrights defined
  in the Internet Standards process must be followed, or as required to
  translate it into languages other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
  FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
  NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
  OR FITNESS FOR A PARTICULAR PURPOSE.

15. References

  This section contains references to related documents identified in
  this specification.

[Base64]    Base64 Content-Transfer-Encoding. A method of
            transporting binary data defined by MIME. See: RFC 2045:
            Multipurpose Internet Mail Extensions (MIME) Part One:
            Format of Internet Message Bodies. N. Freed & N.
            Borenstein. November 1996.

[DNS]       The Internet Domain Name System which allocates Internet
            names to organisations for example "IOTP.org", the Domain
            Name for IOTP. See RFC 1034: Domain names - concepts and
            facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035:
            Domain names - implementation and specification. P.V.
            Mockapetris. Nov-01-1987.

[DSA]       The Digital Signature Algorithm (DSA) published by the
            National Institute of Standards and Technology (NIST) in
            the Digital Signature Standard (DSS), which is available from <http://www.otp.org> web site (which has not
   yet been fully updates to indicate a part of
            the technical switch to US government's Capstone project.

[ECCDSA]    Elliptic Curve Cryptosystems Digital Signature Algorithm
            (ECCDSA). Elliptic curve cryptosystems are analogs of
            public-key cryptosystems such as RSA in which modular
            multiplication is replaced by the IETF). elliptic curve addition
            operation. See: V. S. Miller. Use of elliptic curves in
            cryptography. In this case, see
   <http://www.otp.org/otp/Home.nsf/f86055a20977be50862564b3004d010a/
   42b496239c5956aa8625655a007b1835/$FILE/OTP_Spec_v_0-9-9_ltr.pdf>.  It Advances in Cryptology - Crypto '85,
            pages 417-426, Springer-Verlag, 1986.

[HTML]      Hyper Text Mark Up Language. The Hypertext Mark-up
            Language (HTML) is intended that a simple mark-up language used to
            create hypertext documents that document be appropriately reformated / edited are platform independent.
            See RFC 1866 and published as an later verson of this internet-draft the World Wide Web (W3C) consortium web
            site at: http://www.w3.org/MarkUp/

[HTTP]      Hyper Text Transfer Protocol versions 1.0 and then as
   an Informational RFC.

2. Security Considerations

   Security 1.1. See
            RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T.

            Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC
            2068: Hypertext Transfer Protocol -- HTTP/1.1. R.
            Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
            Lee. January 1997.

[ISO4217]   ISO 4217: Codes for the Representation of Currencies.
            Available from ANSI or ISO.

[MIME]      Multipurpose Internet Mail Extensions. See RFC822,
            RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049.

[OPS]       Open Trade Protocol messages Profiling Standard. A proposed standard which
            provides a framework with built-in privacy safeguards for
            the trusted exchange of profile information between
            individuals and web sites.  Being developed by Netscape
            and Microsoft amongst others.

[RFC822]    IETF (Internet Engineering Task Force). RFC 822: The
            Standard for the Format of ARPA Internet Messages

            . 13 August 1982, David H Crocker. 13 August 1982.

[RFC1738]   IETF (Internet Engineering Task Force). RFC 1738: Uniform
            Resource Locators (URL), ed. T. Berners-Lee, L. Masinter,
            M. McCahill. 1994.

[RSA]       RSA is primarily
   dependent on a public-key cryptosystem for both encryption and
            authentication supported by RSA Data Security Inc. See:
            R. L. Rivest, A. Shamir, and L.M. Adleman. A method for
            obtaining digital signatures within IOTP as described in [v0.9.9].

   Note that and public-key
            cryptosystems. Communications of the security ACM, 21(2): 120-126,
            February 1978.

[SCCD]      Secure Channel Credit Debit. A method of conducting a
            credit or debit card payment protocols transported by where unauthorised access to
            account information is prevented through use of secure
            channel transport mechanisms such as SSL. An IOTP
            supplement describing how SCCD works is under
            development. Author. Jonathan Sowler JCP,

[SET]       Secure Electronic Transaction Specification, Version 1.0,
            May 31, 1997. Supports credit and debit card payments
            using certificates at the responsibility Consumer and Merchant to help
            ensure authenticity.
            Download from:
            <http://www.mastercard.com/set/specs.html>.

[SHA1]      [FIPS-180-1]"Secure Hash Standard", National Institute of those payment protocols.

References

   v0.9.9 - David Burdett, "Internet Open Trading Protocol,
            Standards and Technology, US Department Of Commerce,
            April 1995. Also known as: 59 Fed Reg. 35317 (1994).

[UTC]       Universal Time Co-ordinated. A method of defining time
            absolutely relative to Greenwich Mean Time (GMT).

            Typically of the form:  "CCYY-MM-DDTHH:MM:SS.sssZ+n"
            where the "+n" defines the number of hours from GMT. See
            ISO DIS8601.

[UTF16]     The Unicode Standard, Version
      0.9.9", OTP 2.0.  The Unicode
            Consortium, 17 Reading, Massachusetts. See ISO/IEC 10646 1
            Proposed Draft Amendment 1

[X.509]     ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995,
            Including Draft Amendment 1: Certificate Extensions
            (Version 3 Certificate)

[XML        See Design decisions reached at the XML Working Group
Namespace]  meeting in Montreal, Canada, August 22, 1987

[XML]       Extensible Mark Up Language. See http://www.w3.org/TR/PR-
            xml-971208 for the 8 December 1997 version.

[XMLSIG]    A proposal developed by the IOTP consortium describing an
            approach to signing XML documents such as IOTP Messages.
            It is intended that this document is submitted to W3C for
            consideration. Author. Richard Brown. GlobeSet. (Under
            preparation August 1998. 1998)

16. Author's Address

  The author of this document is:

  David Burdett
  Development Director
  Mondex International Ltd
  Advanced Technology Division
  111 Pine St, Suite 600
  San Francisco, 94111
  California
  USA

  Tel: +1 (415) 645 6973

  Email: david.burdett@mondex.com

  The author of this document appreciates the following contributors to
  this protocol (in alphabetic order of company) without which it could
  not have been developed.
  o  Phillip Mullarkey, British Telecom plc
  o  Andrew Marchewka, Canadian Imperial Bank of Commerce
  o  Brian Boesch, CyberCash Inc.
  o  Donald E. Eastlake 3rd
   IBM
   318 Acton Street 3rd, CyberCash Inc.
  o  Mark Linehan, International Business Machines
  o  Peter Chang, Hewlett Packard
  o  Masaaki Hiroya, Hitachi Ltd
  o  Yoshiaki Kawatsura, Hitachi Ltd
  o  Jonathan Sowler, JCP Computer Services Ltd
  o  John Wankmueller, MasterCard International
  o  Steve Fabes, Mondex International Ltd
  o  Surendra Reddy, Oracle Corporation
  o  Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
  o  Chris Smith, Royal Bank of Canada
  o  Hans Bernhard-Beykirch, SIZ (IT Development and Coordination
     Centre of the German Savings Banks Organisation)
  o  W. Reid Carlisle, MA 01741 USA

   Telephone:   +1 978 287 4877
                +1 914 784-7913
   FAX:         +1 978 371 7148
   email:       dee3@us.ibm.com

Expiration Spyrus (ex Citibank Universal Card Services,
     formally AT&T Universal Card Services)
  o  Efrem Lipkin, Sun Microsystems
  o  Terry Allen, Veo Systems

  The author would also like to thank the following organisations for
  their support:
  o  Amino Communications
  o  DigiCash
  o  Fujitsu
  o  General Information Systems
  o  Globe Id Software
  o  Hyperion
  o  InterTrader
  o  Nobil I T Corp
  o  Mercantec
  o  Netscape
  o  Nippon Telegraph and File Name Telephone Corporation
  o  Oracle Corporation
  o  Smart Card Integrations Ltd.
  o  Spyrus
  o  Verifone
  o  Unisource nv
  o  Wells Fargo Bank

Note: This draft expires December 1998.

   Its file name is draft-ietf-trade-iotp-v1.0-protocol-01.txt. file draft-ietf-trade-iotp-v1.0-protocol-02.txt
Expires: 23 May 1999