TRADE Working Group                                    David Burdett
  Internet Draft                                  Mondex International
  draft-ietf-trade-iotp-v1.0-protocol-02.txt           23 October 1998
  draft-ietf-trade-iotp-v1.0-protocol-03.txt
  Expires:  23 March 1998  28 August 1999

                 Internet Open Trading Protocol - IOTP
                              Version 1.0
  Status of this Memo

  This document is an Internet draft. Internet drafts Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

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

  Internet Drafts Internet-Drafts.

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

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

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

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

  Abstract

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

  Table of Contents

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

  Abstract...........................................................1 Memo..................................................2

  Abstract.............................................................3

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

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

  3. Protocol Structure.............................................28 Structure...............................................38
     3.1 Overview...................................................29 Overview.....................................................40
       3.1.1 IOTP Message Structure ................................29 ..................................40
       3.1.2 IOTP Transactions .....................................30 .......................................42
     3.2 IOTP Message...............................................31 Message.................................................43
       3.2.1 XML Document Prolog ...................................33 .....................................45
     3.3 Transaction Reference Block................................33 Block..................................45
       3.3.1 Transaction Id Component ..............................34 ................................46
       3.3.2 Message Id Component ..................................35 ....................................48
       3.3.3 Related To Component ..................................36 ....................................49
     3.4 ID Attributes..............................................37 Attributes................................................51
       3.4.1 IOTP Message ID Attribute Definition ..................38 ....................52
       3.4.2 Block and Component ID Attribute Definitions ..........39 ............53
       3.4.3 Example of use of ID Attributes .......................40 .........................54
     3.5 Element References.........................................40 References...........................................55
     3.6 Brands and Brand Selection.................................42 Selection...................................56
       3.6.1 Definition of Payment Instrument ......................42 ........................57
       3.6.2 Definition of Brand ...................................42 .....................................58
       3.6.3 Definition of Dual Brand ..............................43 ................................58
       3.6.4 Definition of Promotional Brand .......................43 .........................59
       3.6.5 Identifying Promotional Brands ........................44 ..........................59
     3.7 Extending IOTP.............................................46 IOTP...............................................62
       3.7.1 Extra XML Elements ....................................46 ......................................62
       3.7.2 Opaque Embedded Data ..................................47 ....................................63
       3.7.3 User Defined Values for IOTP Codes ....................................47 ...................................63
     3.8 Packaged Content Element...................................48 Element.....................................66
       3.8.1 Packaging HTML ..........................................68
     3.9 Identifying Languages......................................49 Languages........................................69
     3.10 Secure and Insecure Net Locations.........................50 Locations...........................70
     3.11 Cancelled Transactions......................................70
       3.11.1 Cancelling Transactions ................................70
       3.11.2 Handling Cancelled Transactions ........................71

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

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

  6. Trading Components.............................................75 Components..............................................106
     6.1 Protocol Options Component.................................76 Component..................................108
     6.2 Authentication Data Component..............................77 Component...............................110
     6.3 Authentication Response Component..........................79 Component...........................112
     6.4 Order Component............................................80 Component.............................................113
       6.4.1 Order Description Content .............................81 ..............................115
       6.4.2 OkFrom and OkTo Timestamps ............................82 .............................115
     6.5 Organisation Component.....................................82 Component......................................116
       6.5.2 Trading Role Element ..................................85 ...................................119
       6.5.3 Contact Information Element ...........................87 ............................122
       6.5.4 Person Name Element ...................................87 ....................................123
       6.5.5 Postal Address Element ................................88 .................................124
     6.6 Brand List Component.......................................89 Component........................................125
       6.6.1 Brand Element .........................................91 ..........................................127
       6.6.2 Protocol Amount Element ...............................94 ................................130
       6.6.3 Currency Amount Element ...............................95 ................................132
       6.6.4 Pay Protocol Element ..................................96 ...................................133
     6.7 Brand Selection Component..................................98 Component...................................135
       6.7.1 Brand Selection Brand Info Element ....................99 .....................137
       6.7.2 Brand Selection Protocol Amount Info Element .........100 ...........138
       6.7.3 Brand Selection Currency Amount Info Element .........100 ...........138
     6.8 Payment Component.........................................101 Component...........................................139
     6.9 Payment Scheme Component..................................102 Component....................................141
     6.10 Payment Receipt Component................................104 Component..................................142
     6.11 Payment Note Component...................................105 Component.....................................144
     6.12 Delivery Component.......................................106 Component.........................................145
       6.12.1 Delivery Data Element ...............................108 .................................147
     6.13 Delivery Note Component..................................110 Component....................................149
     6.14 Status Component...........................................151
       6.14.1 Offer Completion Codes ................................154
       6.14.2 Payment Method Information Component.....................111 Completion Codes ..............................154
       6.14.3 Delivery Completion Codes .............................155
       6.14.4 Authentication Completion Codes .......................157
     6.15 Status Component.........................................112
     6.16 Trading Role Data Component..............................117
       6.16.1 Component................................158
       6.15.1 Who Receives a Trading Role Data Component ..........118
     6.17 ............159
     6.16 Inquiry Type Component...................................118
     6.18 Component.....................................159
     6.17 Signature Component......................................119
       6.18.1 Component........................................160
       6.17.1 IOTP usage of signature elements and attributes .......164
       6.17.2 Offer Response Signature Component ..................119
       6.18.2 ....................166
       6.17.3 Payment Receipt Signature Component .................120
       6.18.3 ...................167
       6.17.4 Delivery Response Signature Component .................168
       6.17.5 Authentication Request Signature Component ............168
       6.17.6 Authentication Response Signature Component ...........168
       6.17.7 Ping Request Signature Components ...........................120 Component ......................169
       6.17.8 Ping Response Signature Component .....................169
     6.18 Certificate Component......................................169
       6.18.1 IOTP usage of signature elements and attributes .......170
     6.19 Error Component..........................................121 Component............................................170
       6.19.1 Error Processing Guidelines .........................123 ...........................173
       6.19.2 Error Codes .........................................124 ...........................................174
       6.19.3 Error Location Element ..............................127 ................................178

  7. Trading Blocks................................................128 Blocks..................................................180
     7.1 Trading Protocol Options Block............................130 Block..............................183
     7.2 TPO Selection Block.......................................131 Block.........................................184
     7.3 Offer Response Block......................................132 Block........................................185
     7.4 Authentication Request Block..............................133 Block................................186
     7.5 Authentication Response Block.............................134 Block...............................187
     7.6 Authentication Status Block.................................187
     7.7 Payment Request Block.....................................134
     7.7 Block.......................................188
     7.8 Payment Exchange Block....................................136
     7.8 Block......................................190
     7.9 Payment Response Block....................................136
     7.9 Block......................................190
     7.10 Delivery Request Block....................................137
     7.10 Block.....................................191
     7.11 Delivery Response Block..................................138
     7.11 Payment Instrument Customer Care Request Block...........139 Block....................................193
     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 Block..............................194
     7.13 Inquiry Response Trading Block...........................141
     7.16 Block.............................194
     7.14 Ping Request Block.......................................142
     7.17 Block.........................................195
     7.15 Ping Response Block......................................143
     7.18 Block........................................196
     7.16 Signature Block..........................................144
       7.18.1 Block............................................198
       7.16.1 Offer Response ......................................145
       7.18.2 ........................................199
       7.16.2 Payment Request .....................................145
       7.18.3 .......................................199
       7.16.3 Payment Response ....................................145
       7.18.4 ......................................199
       7.16.4 Delivery Request ....................................145
     7.19 ......................................199
     7.17 Error Block..............................................146 Block................................................199
     7.18 Cancel Block...............................................201

  8. Internet Open Trading Protocol Transactions............................147 Transactions.....................202
     8.1 Baseline Authentication and Payment Related IOTP Transaction..................147 Transactions........202
       8.1.1 Trading Protocol Options Block .......................150
       8.1.2 Authentication Request Block .........................150 Document Exchange .......................205
       8.1.2 Offer Document Exchange ................................212
       8.1.3 Signature Block (Authentication Request) .............150 Payment Document Exchange ..............................222
       8.1.4 Authentication Response Block ........................150 Delivery Document Exchange .............................228
       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 Payment and Delivery Document Exchange .................231
       8.1.6 Baseline Deposit Authentication ......................152
       8.2.3 IOTP Transaction ...............234
       8.1.7 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 Transaction ......................236
       8.1.8 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 Transaction .....................238
       8.1.9 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 Transaction .......................240
       8.1.10 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 Transaction ..................242
       8.1.11 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 Transaction ..............244
       8.1.12 Valid Combinations of Document Exchanges ..............248
       8.1.13 Combining Authentication Transactions with other
       Transactions .................................................252
     8.2 Infrastructure Transactions.................................253
       8.2.1 Baseline Transaction Status Inquiry IOTP Transaction......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 ...254
       8.2.2 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 .........................258

  9. Retrieving Logos..............................................206 Logos................................................262
     9.1 Logo Size.................................................207 Size...................................................262
     9.2 Logo Color Depth..........................................207 Depth............................................263
     9.3 Logo Net Location Examples................................208 Examples..................................263
  10. Brand List Examples..........................................208 Examples............................................265
     10.1 Simple Credit Card Based Example.........................208 Example...........................265
     10.2 Credit Card Brand List Including Promotional Brands......209 Brands........266
     10.3 Brand Selection Example..................................211 Example....................................269
     10.4 Complex Electronic Cash Based Brand List.................211 List...................269

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

  12. Glossary.......................................................289

  13. Glossary.....................................................229 Copyrights.....................................................298

  14. Copyrights...................................................232 References.....................................................299

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

  16. Author's Address.............................................235 Address...............................................303
  Table of Figures

  Figure 1 IOTP Trading Roles ......................................17 ........................................20
  Figure 2 Offer Exchange ..........................................19 ............................................23
  Figure 3 Payment Exchange ........................................21 ..........................................26
  Figure 4 Delivery Exchange .......................................24 .........................................30
  Figure 5 Authentication Exchange .................................25 ...................................33
  Figure 6 IOTP Message Structure ..................................29 ....................................41
  Figure 7 An IOTP Transaction .....................................30 .......................................42
  Figure 8 Example use of ID attributes ............................40 ..............................54
  Figure 9 Element References ......................................41 ........................................56
  Figure 10 Server Role Processing Sequence ........................56 ..........................80
  Figure 11 Client Role Processing Sequence ........................61 ..........................86
  Figure 12 Signature Hashing ......................................65 Digests ........................................91
  Figure 13 Example use of Signatures for Baseline Purchase ........66 ..........93
  Figure 14 Checking a Payment Handler can carry out a Payment .....70 ......100
  Figure 15 Checking a Delivery Handler can carry out a Delivery ...72 ....102
  Figure 16 Trading Components .....................................75 ......................................107
  Figure 17 Brand List Element Relationships .......................91 ........................127
  Figure 18 Trading Blocks ........................................129 ..........................................181
  Figure 19 Baseline Payment and Authentication ...............................149 Message Flow Combinations ....204
  Figure 20 Baseline Deposit with Authentication ..................153 Document Exchange ........................208
  Figure 21 Baseline Deposit without Authentication ...............154 Brand Dependent Offer Document Exchange .................214
  Figure 22 Baseline Deposit Payment Messages .....................155 Brand Independent Offer Exchange ........................217
  Figure 23 Brand Dependent Baseline Purchase .....................161 Payment Document Exchange ...............................224
  Figure 24 Brand Independent Baseline Purchase ...................162 Delivery Document Exchange ..............................229
  Figure 25 Baseline Purchase, Delivery Response Block and Payment
     Response Blocks Not Combined .................................163 and Delivery Document Exchange ..................232
  Figure 26 Baseline Purchase, Delivery Response Block and Payment
     Response Block Combined ......................................164 Authentication IOTP Transaction ................235
  Figure 27 Baseline Purchase, Purchase without Delivery Exchange .166 Deposit IOTP Transaction .......................237
  Figure 28 Baseline Purchase Variations ..........................167 IOTP Transaction ......................239
  Figure 29 Baseline Refund with Authentication ...................173 IOTP Transaction ........................241
  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 IOTP Transaction ....................243
  Figure 37 31 Baseline Value Exchange Payment Messages ..............191 IOTP Transaction ................246
  Figure 38 32 Baseline Value Exchange Signatures ....................198 ......................247
  Figure 39 IOTP Payment Instrument Customer Care Transaction Message
     Flows ........................................................200 33 Valid Combinations of Document Exchanges ................250
  Figure 40 34 Baseline Transaction Status Inquiry ...................203 .....................257
  Figure 41 35 Baseline Ping Messages ................................204 ..................................259
  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

  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

  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

  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 market-
    place with new products and services, using the new trading
    opportunities which IOTP presents

     Banks and Financial Institutions
  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

  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 1997  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
                                   the OTP consortium

  Version 0.9    12 January 1998   Revisions following limited public
                                   review _ draft for public comment
                                   only.

  Version 0.9.1  20 May 1998       Revisions following public review
                                   - internal IOTP Consortium review.

  Version 0.9.9  17 August 1998    Draft published for submission to
                                   IETF for information.

  Version 1.0    23 October 1998   Draft published incorporating
                                   comments received on version
                                   0.9.9.

  Version 1.0    28 February 1998  Revised draft published incorporating
                                   comments received on version 1.0
  2. Introduction

  The Internet Open Trading Protocols (IOTP) define a number of
  different types of IOTP Transactions:

  o Purchase. This supports a purchase involving an offer, a
    payment and optionally a delivery

  o Refund. This supports the refund of a payment as a result of,
    typically, an earlier purchase

  o Value Exchange. This involves two payments which result in the
    exchange of value from one combination of currency and payment
    method to another

  o Authentication. This supports 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 one organisation or individual to
    check that another Trading Role for use in,
     for example the creation of an offer organisation or individual are who they
    appear to be.

  o Withdrawal. This supports the withdrawal of electronic cash
    from a financial institution

  o Deposit. This supports the deposit of electronic cash at a
    financial institution

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

           Merchant Customer Care Provider resolves   ----------
      ---------------------------------------------->| Merchant |
     |          Consumer disputes and problems       |Cust.Care.|
     |                                               | Provider |
     |                                                ----------
     |
     |
                Payment Handler accepts or makes     ----------
     |    ------------------------------------------>| Payment  |
     |   |             Payment for Merchant          | Handler  |
     |   |                                            ----------
     v   v
 ----------    Consumer makes purchases or obtains    ----------
| Consumer |<--------------------------------------->| Merchant |
 ----------             refund from Merchant          ----------
     ^   ^
     |
     |         Delivery Handler supplies goods or     ----------
     |    ------------------------------------------>|Deliverer |
     |---------------------------------------------->|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               IOTP MESSAGE             MERCHANT
1. Consumer decides to   ---------------------->  2. Merchant checks
pay (request an offer)
    trade and sends      Information on what is     the information
 and sends
 information about the   being purchased (Offer     provided by the
on what to purchase to
 transaction (requests   Request) (outside scope Consumer, creates an
   an offer) to the Merchant using e.g.             of OTP)          and IOTP)          Offer and sends
         HTML it
  Merchant, e.g using                              to the Consumer.
                                                           | Consumer|
         HTML
                                                           v
                                        Components: Organisation(s)
3. Consumer checks the                (Consumer, DeliverTo, Merchant,                  Components: Organisation(s)
 information from the                 (Consumer, DeliverTo, Merchant,
 Merchant and decides    <----------     Payment Handler, Delivery
 Merchant and decides
  whether to continue       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 is provided using
  a variety of methods, for example, it could be provided:

  o using [HTML] pages as part of the "shopping experience" of the
    consumer.

  o  using Using the Open Profiling Standard [OPS] which has recently been
    proposed,

  o in the form of Organisation and Components associated with an
    authentication of a Consumer by a Merchant

  o as Order Components in a later version of IOTP.

  2.2.2 Payment Exchange

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

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

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

        CONSUMER                OTP               IOTP MESSAGE             MERCHANT
 1. Consumer decides to                           2. Merchant decides
    trade and sends       Information on what is     which payment brand
 information on what to about the        being paid for        and         brand, payment
transaction (requests an  ---------------------->    protocols to
    purchase and
offer) to the       ---------------------->  offer, places then Merchant, e.g. using   (outside scope of OTP) IOTP)  currencies/amounts
     e.g using HTML                                 to offer, places
                                                    them in a Brand
                                                   List
          HTML Component and
                                                   sends them to the
                                                       Consumer.
                                                        Consumer
                                                              |
                                                              v
  3. Consumer selects the payment   <-----------------   Brand List
brand and
brand, protocol and currency/amount     Brand List        Component
 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,
                                     information, optionally signs it
                                    to authorise payment and send sends it
                                             to the consumer 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
  8. Consumer checks Pay              Components: Pay Receipt; Pay
  8 Consumer checks Pay                scheme; Signature (Offer);
      Receipt is OK      <-------      scheme; Signature (Offer);
                          Payment  Signature (Pay Receipt)
                            Payment (signs Pay
                         Response    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 GeldKarte), payment
    protocols (for example SET Version 1.0, Secure Channel Credit
    Debit (SCCD - the name used for a credit or debit card payment
    where unauthorised access to account information is prevented
    through use of secure channel transport mechanisms such as
     SSL). SSL)
    as well as currencies/amounts that apply. The Merchant sends
    the Brand List to the Consumer. The consumer compares the
    payment brands and brands, protocols and currencies/amounts on offer with
    those that the Consumer supports and makes a selection.

  o The Brand Selection Component contains the Consumer's
    selection. Payment brand, protocol protocol, currency/amount and
    possibly protocol-
     specific protocol-specific information is sent back to the
    Merchant. This information may be used to change information in
    the Offer Exchange. For example, a merchant could choose to
    offer a discount to encourage the use of a store card.

  o The Organisation Components are generated by the Merchant. They
    contain details of the Merchant and Payment Handler Roles:
    - the Merchant role is required so that the Payment Handler can
      identify which Merchant initiated the payment. Typically, the
      result of the Payment Handler accepting (or making) a payment on
      behalf of the Merchant will be a credit or debit transaction to
      the Merchant's account held by the Payment Handler. These
      transactions are outside the scope of this version of IOTP
    - the Payment Handler role is required so that the Payment Handler
      can check that it is the correct Payment Handler to be used for
      the payment

  o The optional Authentication Data Payment Component contains challenge
     data which is used by the payment protocol details of how much to authenticate the
     consumer. Authentication may not always occur
  o  The Payment Component contains details of how much to pay, pay, the
    currency and the payment direction, and identifies the
     Authentication Data Component to use. direction

  o The "Offer Response" Signature Component, if present, digitally
    signs all of the above components to ensure their integrity.
    Note that the Brand List and Brand Selection Components are not
    signed until the payment information is created (step 3 4 in the
    diagram)

  o The Payment Scheme Component contains messages from the payment
    protocol used in the Trade. For example they could be SET
    messages, Mondex messages, GeldKarte Messages or one of the
    other payment methods supported by IOTP. The content of the
    Payment Scheme Component is defined in the supplements that
    describe how IOTP works with various payment protocols.

  o The Payment Receipt Component contains a record of the payment.
    The content depends upon the payment protocol used.

  o The "Payment Receipt" Signature Component provides proof of
    payment by digitally signing both the Payment Receipt Component
    and the Offer Response Signature. The signature on the offer
    digitally signs the Order, Organisation and Delivery Components
    contained in the Offer. This signature effectively binds the
    payment to the offer.

  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). Baseline Purchase IOTP Transaction).

  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 The
  result of the delivery may also be signed so that it can be used for
  customer care in the case of problems with physical delivery. This The
  message flow is illustrated in the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER              OTP             IOTP MESSAGE              MERCHANT
1. Consumer decides to   ------------>      2. Merchant checks the
    trade and sends       Information    information provided by the
information about what    on what is      Consumer, adds information
 to deliver and who is       being       about how the delivery will
 to take delivery, to      delivered     occur, information about the
the Merchant, using for    (outside     organisations involved in the
     example, HTML         scope of OTP)     delivery and optionally signs
                             IOTP)                    it
                                                        |
                                                        v
   3. Consumer checks the                             Components:
delivery information is OK,                            Delivery;
 obtains authorisation for    <-----------------    Organisation(s)
the delivery, for example by       Delivery        Delivery Handler,
making a payment, and sends       Information      Deliver To; Order;
the delivery information to                        Signature (Offer)
   the Delivery Handler.
             |
             v
   Components: Delivery;                  4. Delivery Handler checks
Organisation(s), Merchant,                     information and
Delivery Handler, DelivTo;   -------->     authorisation. Starts or
 Order; Signature (Offer);   Delivery       schedules delivery and
  Signature (Pay Receipt)     Request      creates and then sends a
  (from Payment Exchange)               delivery note to the Consumer
                                        which can optionally be signed
                                                      |
                                                      v
  5. Consumer checks delivery    <---------  Component: Delivery
note is OK and accepts or waits   Delivery           Note      Note; Signature
 for delivery as described in     Response    (Delivery 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 "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. list

  o The "Delivery Response" Signature Component, if present,
    provides proof of the results of the Delivery by digitally
    signing the Delivery Note and any Offer Response or Payment
    Response signatures that the Delivery Handler received.

  2.2.4 Authentication Exchange

  The goal of the Authentication Exchange is to allow one organisation,
  for example a financial institution, to be able to check that another
  organisation, for example a consumer, is who they appear to be. It
  uses a "challenge-response" mechanism.

  An Authentication Exchange involves:

  o an Authenticator - the organisation which is requesting the
    authentication, and

  o an Authenticatee - the organisation being authenticated.

  This is illustrated in the diagram below.

+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

    ORGANISATION 1             OTP            IOTP MESSAGE           ORGANISATION 2
    (AUTHENTICATEE)                                 (AUTHENTICATOR)
 1. First organisation,                            2. The second
e.g a consumer, takes an                      organisation generates
 action (for example by   ---------------->     Authentication Data
pressing a button on an       Need for         containing challenge data
    HTML page) which       Authentication        and       data, the method of
   requires that the      (outside scope of  authentication to be used
    organisation is             OTP)             IOTP)        and optionally a request
     authenticated                               for Organisation
                                             information then sends it
                                             to the
     authenticated first organisation
                                                         |
                                                         v
   3. The first organisation uses                          Component:
optionally checks any signature  <------------    Authentication Data
      associated with the        Authentication
  Authentication request then       Request
 uses 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 together with
 details of any  Organisation
     information requested
       |
       v
  Component:
Authentication   ------------->                       4. The Authentication Response is
   Response
Authentication   ------------->  checked against the challenge data to
   Response      Authentication  check that the first organisation is
                    Response     who they appear to be and the result
                                 recorded in a Status Component which
                                    is then sent back to the first
                                             organisation
                                                         |
                                                         v
5. The first organisation then                     Component: Status
 optionally checks the results   <------------
     of the Status and any       Authentication
associated signature and takes       Status
   the appropriate action or
            stops.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
                     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 mechanism,
    indicates the authentication method to be used. used and optionally
    request Organisation data about the first organisation, for
    example a ship to or billing address. It is sent by one
    organisation to the other.

  o  the 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. verification together with Organisation
    Components requested

  o the Status Component which contains the results of the second
    party's verification of the Authentication Response.

  2.3 Scope of Baseline IOTP

  This specification describes the IOTP Transactions which make up
  Baseline IOTP. As described in the preface, IOTP will evolve over
  time. This section defines the initial conformance criteria for
  implementations that claim to _support IOTP._

  The main determinant on the scope of an IOTP implementation is the
  roles which the solution is designed to support. The roles within IOTP
  are described in more detail in section 2.1 Trading Roles. To
  summarise the roles are: Merchant, Consumer, Payment Handler, Delivery
  Handler and Customer Care Provider.

  Payment Handlers who can be of three types:

  o those who accept a payment as part of a purchase or make a
    payment as part of a refund,

  o those who accept value as part of a deposit transaction, or

  o those that issue value a withdrawal transaction
  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-

Authentication   May    Must      May       b)
ication
                                          Depends

Value Exchange   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
                       Merchants

                        ECash    ECash
                Store   Value    Value   Consumer   Payment   Delivery
                       Issuer  Acquirer             Handler   Handler

TRADING BLOCKS

TPO             Must    Must     Must      Must

TPO Selection   Must    Must     Must      Must
Selection

Auth-Requesta)

Auth-Request     a)               a)        a)
               Depends          Depends   Depends

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

Offer Response  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
                       Merchants

                        ECash    ECash
                Store   Value    Value   Consumer   Payment   Delivery
                       Issuer  Acquirer             Handler   Handler

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

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

     -

   a) if Baseline Authentication IOTP Transaction is supported;

     -
   b) if required by a Payment Method as defined in its IOTP
      Supplement document.

  o "Limited" means the Trading Block must be understood and its
    content manipulated but not in every respect. Specifically, on
    the Signature Block, Consumers do not have to be able to
    validate digital signatures.

  An IOTP solution must support all the IOTP Transactions and Trading
  Blocks required by at least one role (column) as described in the
  above table for that solution to be described as "supporting IOTP".

  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 an overview of IOTP Messages Brands and
     provide the trust relationships required Brand Selection which describes how a
    Consumer can select a Brand from a list provided by IOTP the
    Merchant

  o how extra XML Elements and new user defined values for existing
    IOTP codes can be used when Extending IOTP,

  o how IOTP uses the Packaged Content Element to embed data such
    as payment protocol messages or detailed order definitions
    within an IOTP Message

  o how IOTP Identifies Languages so that different languages can
    be used within IOTP Messages
  o how IOTP handles both Secure and
     finally Insecure Net Locations when
    sending messages

  o how an IOTP Transaction can be cancelled.

  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

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

IOTP MESSAGE  <----------- OTP  <---------- IOTP Message - an XML Document which is
 |                        transported between the Trading Roles
 |-Trans Ref Block <----- Trans Ref Block - contains information which
 |  |                     describes the OTP IOTP Transaction and the OTP IOTP
 |  |                     Message.
 |  |-Trans Id Comp. <--- Transaction Id Component - uniquely
 |  |                     identifies the OTP IOTP Transaction. The Trans Id
 |  |                     Components are the same across all OTP IOTP
 |  |                     messages that comprise a single OTP IOTP
 |  |                     transaction.
 |  |-Msg Id Comp. <----- Message Id Component - identifies and
 |                        describes an OTP IOTP Message within an OTP IOTP
 |                        Transaction
 |-Signature Block <----- Signature Block (optional) - contains one or
 |  |                     more Signature Components and their
 |  |                     associated Certificates
 |  |-Signature Comp. <-- Signature Component - contains digital
 |  |                     signatures. Signatures may sign hashes digests of the
 |  |                     the Trans Ref Block and any Trading Component in
 |  |                     in any OTP IOTP Message in the same OTP Transaction. IOTP
 |  |                     transaction.
 |  |-Certificate Comp. < Certificate Component. Used to check the
 |                        signature.
 |-Trading Block <------- Trading Block - an XML Element within an OTP IOTP
 |  |-Component           Message that contains a predefined set of
 |  |-Component           Trading Components
 |  |-Component
 |  |-Component <-------- Trading Components - XML Elements within a
 |                        Trading Block that contain a predefined set
 |-Trading Block          of XML elements and attributes containing
 |  |-Component           information required to support a Trading
 |  |-Component           Exchange
 |  |-Component
 |  |-Component
 |  |-Component
 |
 |

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

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 7 An IOTP Transaction

  In the above diagram the Internet is shown as the transport mechanism.
  This is not necessarily the case. IOTP Messages can be transported
  using a variety of transport mechanisms.

  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 Trading Roles that are taking
  part in a trade.

  The XML definition of an IOTP Message is as follows.

<!ELEMENT OtpMessage (TransRefBlk,
   ( TransRefBlk,
     SigBlk?,
     ErrorBlk?,
     ( AuthReqBlk |
       AuthRespBlk |
       AuthStatusBlk |
       CancelBlk |
       DeliveryReqBlk |
       DeliveryRespBlk |
       InquiryReqBlk |
       InquiryRespBlk |
       OfferRespBlk |
       PayExchBlk |
       PayReqBlk |
       PayInstCCExchBlk |
       PayInstCCReqBlk |
       PayInstCCRespBlk
       PayRespBlk |
       PingReqBlk |
       PingRespBlk |
       TpoBlk |
       TpoSelectionBlk |
     )*
   ) >
<!ATTLIST OtpMessage
  xmlns:iotp     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-03' >

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

TpoBlk,
TpoSelectionBlk

  Attributes

xmlns:iotp         The [XML Namespace] definition for IOTP
                   messages.

  3.2.1 XML Document Prolog

  The IOTP Message is the root element of the XML document. It therefore
  needs to be preceded by an appropriate XML Document Prolog. For
  example:

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

                    Values of x-ddd:nnn indicates a
                   user defined transaction type. See OtpTransType are managed under the
                    procedure described in section 3.7.3
                   User Defined Codes. Values for
                    IOTP Codes which also allows user defined values
                    of OtpTransType to be defined.

                    In later versions of IOTP, this list will be
                    extended to support different types of standard
                    IOTP Transaction based on market demand. It is
                    also likely to support the type Dynamic which
                    indicates that the sequence of steps within the
                    transaction are non-standard.

TransTimeStamp      Where the system initiating the IOTP Transaction
                    has an internal clock, it is set to the time at
                    which the IOTP Transaction started in [UTC]
                    format.

                    The main purpose of this attribute is to provide
                    an alternative way of identifying a transaction
                    by specifying the time at which it started.

                    Some systems, for example, hand held devices may
                    not be able to generate a  time stamp. In this
                    case this attribute should contain the value
                    "NA" for Not Available.

  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
 SenderTradingRoleRef NMTOKEN #IMPLIED
 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.

SenderTradingRoleR  The Element Reference (see section 3.5) of the
ef                  Trading Role which has generated the IOTP
                    message. It is used to identify the Net
                    Locations (see section 3.10) of the Trading Role
                    to which problems Technical Errors (see section
                    4.1) with any of Trading Blocks should be
                    reported.

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

SoftwareId          This contains information which identifies the
                    software which generated the IOTP Message. Its
                    purpose is to help resolve interoperability
                    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

                    Values of RelationshipType are controlled under
                    the procedures defined code (see in section
                      3.7.3) 3.7.3 Values
                    for IOTP Codes which also allows user defined
                    values to be defined.

Relation            The Relation attribute contains a phrase in the
                    language defined by xml:lang which describes the
                    nature of the relationship between the IOTP
                    transaction that contains this component and
                    another IOTP Transaction or other event. The
                    exact words to be used are left to the implementer
                    implementers of the IOTP software.

                    The purpose of the attribute is to provide the
                    Trading Roles involved in an IOTP Transaction
                    with an explanation of the nature of the
                    relationship between the transactions.

                    Care should be taken that the words used to in
                    the Relation attribute indicate the "direction"
                    of the relationship correctly. For example: one
                    transaction might be a refund for another
                    earlier transaction. In this case the
                    transaction which is a refund should contain in
                    the Relation attribute words such as "refund
                    for" rather than "refund to" or just "refund".

RelnKeyWords        This attribute contains keywords which could be
                    used to help identify similar relationships, for
                    example all refunds. It is anticipated that
                    recommended keywords will be developed through
                    examination of actual usage. In this version of
                    the specification there are no specific
                    recommendations and the keywords used are at the
                    discretion of the implementer. implementers.

  Content:

PackagedContent     The Packaged Content (see section 3.8) contains
                    data which identifies the related transaction.
                    Its format varies depending on the value of the
                    RelationshipType.

  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 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), 7.12), the
                    same prefix is used for all messages sent by the
                    Merchant or Consumer role as follows:
                    o "M" - Merchant
                    o "C" - Consumer

                    For messages which contain an Inquiry Request
                    Trading Block, the prefix is set to "I" for
                    Inquiry.

                    The prefix for the other roles in a trade is
                    contained within the Organisation Component for
                    the role and are typically set by the Merchant.
                    The following is recommended as a guideline and
                    must not be relied upon:
                    o "P" - First (only) Payment Handler
                    o "R" - Second Payment Handler
                    o "D" - Delivery Handler

                    As a guideline, prefixes should be limited to
                    one character.

                    NameChar has the same definition as the [XML]
                    definition of NameChar.

OtpMsgIdSuffix      The suffix consists of one or more digits. The
                    suffix must be unique within a Trading Role
                    within an IOTP Transaction. The following is
                    recommended as a guideline and must not be
                    relied upon:
                    o the first IOTP Message sent by a trading role
                      is given the suffix "1"
                    o the second and subsequent IOTP Messages sent
                      by the same trading role are incremented by
                      one for each message
                    o no leading zeroes are included in the suffix
                    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 OtpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*

OtpMsgId

OtpMsgId_value      The ID attribute of the Message ID Component of
                    the IOTP Message where the Block or Component is
                    first used.

                    In IOTP, Trading Components and Trading Blocks
                    are copied from one IOTP Message to another. The
                    ID attribute does not change when an existing
                    Trading Block or Component is copied to another
                    IOTP Message.

IdSuffix            The suffix consists of one or more digits. The
                    suffix must be unique within the ID attribute of
                    the Message ID Component used to generate the ID
                    attribute. The following is recommended as a
                    guideline and must not be relied upon:
                    o the first Block or Component sent by a trading
                      role is given the suffix "1"
                    o the ID attributes of the second and subsequent
                      Blocks or Components are incremented by one
                      for each new Block or Component added to an
                      IOTP Message
                    o no leading zeroes are included in the suffix

                    Put more simply, the first new Block or
                    Component added to the second IOTP Message sent,
                    for example, by a consumer would have a an ID
                    attribute of "C2.1", the second "C2.2", the
                    third "C2.3" etc.

                    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  IOTP MESSAGE                          2nd OTP IOTP MESSAGE
    (e.g. from Merchant to                    (e.g. from Consumer to
           Consumer                              Payment Handler)

OTP

IOTP MESSAGE                                OTP                               IOTP MESSAGE *
 |-Trans Ref Block. ID=M1.1                 |-Trans Ref Block.ID=C1.1*
 |  |-Trans Id Comp. ID = M1. ------------->|  |-Trans Id Comp.
 |  |                         Copy Element  |  |  ID=M1.2
 |  |-Msg Id Comp. ID = M1                  |  |-Msg Id Comp. ID=C1 *
 |                                          |
 |-Signature Block. ID=M1.8                 |-Signature Block.ID=C1.5*
 |  |-Sig Comp. ID=M1.15 ---- ------------->|  |-Comp. ID=M1.15
 |                            Copy Element  |
 |-Trading Block. ID=M1.3                   |-Trading Block. ID=C1.2 *
 |  |-Comp. ID=M1.4 --------- ---------------->|-Comp. ID=M1.4
 |  |                         Copy Element     |
 |  |-Comp. ID=M1.5 --------- ---------------->|-Comp. ID=M1.5
 |  |                         Copy Element     |
 |  |-Comp. ID=M1.6                            |-Comp. ID=C1.3 *
 |  |-Comp. ID=M1.7                            |-Comp. ID=C1.4 *
 |
 |-Trading Block. ID=M1.3
    |-Comp. ID=M1.4                             * = new elements
    |-Comp. ID=M1.5
    |-Comp. ID=M1.6
    |-Comp. ID=M1.7

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                  Figure 8 Example use of ID attributes
  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 Digest is included in a
    Signature Component,

  o referring to the Payment Handler Organisation Component which
    is used when making a Payment

  An Element Reference always contains the value of an ID attribute of a
  Block or Component.

  Identifying the IOTP Message, Trading Block or Trading Component which
  is referred to by an Element Reference, involves finding the XML
  element which:

  o belongs to the same IOTP Transaction (i.e. the Transaction Id
    Components of the IOTP Messages match), and

  o where the value of the ID attribute of the element matches the
    value of the Element Reference.

  [Note]   The term "match" in this specification has the same
           definition as the [XML] definition of match.
  [Note End]

  An example of "matching" an Element Reference is illustrated in the
  example below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

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

OTP

IOTP MESSAGE                                OTP                               IOTP MESSAGE
 |-Trans Ref Block. ID=M1.1     Trans ID    |-Trans Ref Block. ID=C1.1
 |  |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id Comp.ID=M1.2
 |  |                            must be    |  |
 |  |-Msg Id Comp. ID = M1      Identical   |  |-Msg Id Comp. ID=C1
 |                                  ^       |
 |-Signature Block. ID=M1.8         |       |-Signature Block. ID=C1.5
 |  |-Sig Comp. ID=M1.15            |       |  |-Comp. ID=M1.15
 |                                 AND      |
 |-Trading Block. ID=M1.3           |       |-Trading Block. ID=C1.2
 |  |-Comp. ID=M1.4                 |          |-Comp. ID=M1.4
 |  |                               v          |
 |  |-Comp. ID=M1.5 <-------- -ID Attribute    |-Comp. ID=M1.5
 |  |                          and El Ref      |
 |  |-Comp. ID=M1.6            values must     |-Comp. ID=C1.3
 |  |                             match--------|--> El Ref=M1.6
 |  |-Comp. ID=M1.7                            |-Comp. ID=C1.4
 |
 |-Trading Block. ID=M1.3
    |-Comp. ID=M1.4
    |-Comp. ID=M1.5
    |-Comp. ID=M1.6
    |-Comp. ID=M1.7

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 9 Element References

  [Note]   Element Reference attributes are defined as "NMTOKEN" rather
           than "IDREF" (see [XML]). This is because an IDREF requires
           that the XML element referred to is in the same XML
           Document. With IOTP this is not necessarily the case.
  [Note End]

  3.6 Brands and Brand Selection

  One of the key features of IOTP is the ability for a merchant to offer
  a list of Brands from which a consumer may make a selection. This
  section provides an overview of what is involved and provides guidance
  on how selection of a brand and associated payment instrument can be
  carried out by a Consumer. It covers:

  o definitions of Payment Instruments and Brands - what are
    Payment Instruments and Brands in an IOTP context. Further
    categorises Brands as optionally a "Dual Brand" or a
    "Promotional Brand",

  o identification and selection of Promotional Brands -
    Promotional Brands offer a Consumer some additional benefit,
    for example loyalty points or a discount. This means that both
    Consumers and Merchant must be able to correctly identify that
    a valid Promotional Brand is being used.

  Also see the following sections:

  o Brand List Component (section 6.6) which contains definitions
    of the XML elements which contain the list of Brands offered by
    a Merchant to a Consumer, and

  o Brand Selection Component (section 6.7) for details of how a
    Consumer records the Brand that was selected.

  3.6.1 Definition of Payment Instrument

  A Payment Instrument is the means by which a Consumer pays for goods
  or services offered by a Merchant. It can be, for example:

  o a credit card such as MasterCard or Visa;

  o a debit card such as MasterCard's Maestro;

  o a smart card based electronic cash payment instrument such as a
    Mondex Card, a GeldKarte card or a Visa Cash card

  o a software based electronic payment account such as a CyberCash
    or DigiCash account.

  All Payment Instruments have a number, typically an account number, by
  which the Payment Instrument can be identified.

  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]. Namespace] as identified by the xmlns attribute on the OtpMessage
  element. This allows IOTP to support the inclusion of additional XML
  elements within IOTP messages through the use of [XML Namespaces].

  [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

  Using 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 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 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 has a Technical Error (see section 4.1) and 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 used in the creation of a digest as
      part of the generation of a signature

  o if an extra XML element has no "IOTP:Critical" attribute then
    it must be treated as if it had an "IOTP:Critical" attribute
    with a value of "True"

  o if an XML element contains an "IOTP:Critical" attribute, then
    the value of that attribute is assumed to apply to all the
    child elements within that element

  In order to ensure that documents containing "IOTP:Critical" are
  valid, it is declared as part of the DTD for the extra element as:

IOTP:Critical      (True | False ) #TRUE

  3.7.2 Opaque Embedded Data

  If IOTP is to be extended using Opaque Embedded Data then a Packaged
  Content Element (see section 3.8) should be used to encapsulate the
  data.

  3.7.3 User Defined Values for IOTP Codes

  User defined codes provide a simple way to identify additional

  Codes used by IOTP are registered by [IANA] so that new values
  for the codes contained within this specification.

  The definition of a user defined code is can be
  co-ordinated based on an IETF consensus 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]). in RFC 2434.

  The
               purpose of element types, attributes names to which this field procedure applies is to reduce the probability of
               two organisations creating the same user-defined name

name           A name specified by
  shown in the organisation which owns table below together with the
               domain_name original values for
  attributes which identifies the user defined code
               within the domain_name.

  User defined codes are identified in this specification as "x-
  ddd:nnn". The apply. For more up-to-date information on valid
  values of User Defined Codes must conform and how these relate to the rules
  for the specific code (see explanations versions of the individual codes).

3.8 Packaged Content IOTP specification
  contact IANA.

 Element Type     Attribute               Attribute Values
                     Name

AuthData         AuthMethod    sha1

                               signature

                               pay:ppp where ppp may be set to any
                               valid value for iotpbrand (see below)

Brand            BrandId       SET:setbrand where setbrand is a brand
                               which is accepted by the [SET] payment
                               protocol

                               IOTP:iotpbrand where iotpbrand may be:
                               o GeldKarte
                               o Mondex

CurrencyAmount   CurrCode      TBD. Codes which apply when the
                               CurrCodeType  attribute is set to IOTP
                               are to be defined

CurrencyAmount   CurrCodeType  ISO4217

                               IOTP

DeliveryData     DelivMethod   Post

                               Web

                               Email

PackagedContent  Content       PCDATA

                               MIME

                               MIME:mimetype (where mimetype must be
                               the same as content-type as defined by
                               [MIME] )

                               XML

PayProtocol      ProtocolId    The values of ProtocolId are to be
                               defined by the payment scheme/method
                               owners.

RelatedTo        Relationship  OtpTransaction
                 Type
                               Reference

Status           StatusType    Offer

                               Payment

                               Delivery

                               Authentication

TradingRole      TradingRole   Consumer

                               Merchant

                               PaymentHandler

                               DeliveryHandler

                               DelivTo

                               CustCare

TransId          OtpTransType  BaselineAuthentication

                               BaselineDeposit

                               BaselinePurchase

                               BaselineRefund

                               BaselineWithdrawal

                               BaselineValueExchange

                               BaselineInquiry

                               BaselinePing

Attibute         Content       OfferResponse
(within
Signature                      PaymentResponse
Component)
                               DeliveryResponse
                               AuthenticationRequest

                               AuthenticationResponse

                               PingRequest

                               PingResponse

  However there is still a need for developers to experiment using new
  IOTP codes. For this reason, "user defined codes" may be used to
  identify additional values for the codes contained within this
  specification with the need for them to be registered with IANA.

  The definition of a user defined code is as follows:

user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*

  NameChar            NameChar has the same definition as the [XML]
                      definition of NameChar

  Use of domain names (see [DNS]) to make user defined codes unique is
  recommended although this method cannot be relied upon.

  3.8 Packaged Content Element

  The Packaged Content element supports the concept of an embedded data
  stream, transformed to both protect it against misinterpretation by
  transporting systems and to ensure XML compatibility. Examples of its
  use in IOTP include:

  o to encapsulate payment scheme messages, such as SET messages,

  o to encapsulate a description of an order. order, a payment note, or a
    delivery note.

  In general it is used to encapsulate any one or more data stream. streams.

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

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

  Attributes:

Name                Optional. Distinguishes between multiple
                    occurrences of Packaged Content Elements at the
                    same point in IOTP. For example:
                    <ABCD>
                      <PackagedContent Name='FirstMsg'>
                        snroasdfnas934k
                      </PackagedContent>
                      <PackagedContent Name='SecondMsg'>
                        dvdsjnl5poidsdsflkjnw45
                      </PackagedContent>
                    </ABCD>

                    The name attribute may be omitted, for example
                    if there is only one Packaged Content element.

Content             This identifies what type of data is contained
                    within the Content of the Packaged Content
                    Element. The valid values for the Content
                    attribute are as follows:
                    o  PCDATA.The 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

                    Values of x-www.ffgghh.com, x-ffgghh.comand and
                      x-ffgghh the Content attribute are legitimate examples. However, only
                      one should be controlled
                    under the correct format, as procedures defined by
                      FFGGHH Inc. in section 3.7.3
                    Values for IOTP Codes which also allows user
                    defined values to be defined.

Transform           This identifies the transformation that has been
                    done to the data before it was placed in the
                    content. Valid values are:
                    o NONE. The PCDATA content of the Packaged
                      Content Element is the correct representation
                      of the data. Note that entity expansion must
                      occur first (i.e. replacement of &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

  3.8.1 Packaging HTML

  The packaged content may contain HTML. In this case the following
  conventions are followed:

  o references to specify any documents, images or other things, such as
    sounds or web pages, which languages are
  used within can affect the content and attributes recipient's
    understanding of IOTP Messages.

  The following principles have been used in order to determine the data which
  XML elements contain is being packaged must refer to
    other Packaged Elements contained within the same parent
    element, e.g. an xml:lang Attributes: Order Description
  o if more than one Packaged Content element is included within a mandatory xml:lang
    parent element in order to meet the previous requirement, then
    the Name attribute is contained on every Trading
     Component which contains attributes or content of the top level Packaged Content from which may need
    references to all other Packaged Elements can be displayed or printed in determined,
    should have 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 Main. This means that the value for "Main"
    Packaged Content element must not be referred to from the Trading
     Component.

  xml:lang attributes which HTML
    in any other Packaged Content

  o relative references to other documents, images, etc. from one
    Packaged Content element to another are realised by setting the
    value of the relative reference to the Name attribute of
    another Packaged Content element at the same level and within
    the same parent element

  o no external references that require the reference to be
    resolved immediately should be used. As this could make the
    HTML difficult or impossible to display completely

  o [MIME] is used to encapsulate the data inside each Packaged
    Element. This means that the information in the MIME header
    used to identify the type of data which has been encapsulated
    and therefore how it should be displayed.

  If the above conventions are not followed by, for example, including
  external references which must be resolved, then the recipient of the
  HTML should be informed.

  [Note]   As an implementation guideline the values of the Name
           Attributes allocated to Packaged Content elements should
           make it possible to extract each Packaged Content into a
           directory and then display the HTML directly
  [Note End]

  3.9 Identifying Languages

  IOTP uses [XML] Language Identification to specify which languages are
  used within the content and attributes of IOTP Messages.

  The following principles have been used in order to determine which
  XML elements contain an xml:lang Attributes:

  o a mandatory xml:lang attribute is contained on every Trading
    Component which contains attributes or content which may need
    to be displayed or printed in a particular language
  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.

  3.11 Cancelled Transactions

  Any Trading Role involved in an IOTP Error Handling transaction may cancel that
  transaction at any time.

  3.11.1 Cancelling Transactions

  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 Transactions are a several interrelated considerations in
  handling errors, re-transmissions, duplicates, and the like. These
  factors mean cancelled by sending an IOTP aware applications must manage message flows more
  complex than the simple request/response model. Also containing
  just a wide variety of
  errors can occur in messages as well as at Cancel Block with an appropriate Status Component to the transport level or in other
  Trading Blocks or Components.

  This section describes at a high level how IOTP handles errors,
  retries and idempotency. It covers:
  o Role involved in the different types of errors which Trading Exchange.

  [Note]   The Cancel Block can occur. This is divided
     into:
     - "technical errors" which are independent of the meaning be sent asynchronously of any other
           IOTP Message. Specifically it can be sent either before
           sending or after receiving an IOTP Message from the other
           Trading Role
  [Note End]

  If an IOTP Message,
     - "business errors" which indicate that there Transaction is cancelled during a problem
       specific to Trading Exchange (i.e.
  the process (payment or delivery) which is being
       carried out, interval between sending a _request_ block and
  o  the depth of receiving the error which indicates whether
  matching _response_ block) then the error Cancel Block is at sent to the transport, message or block/component level
  o  how same
  location as the different trading roles should handle next IOTP Message in the different
     types of messages which Trading Exchange would have
  been sent.

  If a Consumer cancels a transaction after a Trading Exchange has
  completed (i.e. the "response" block for the Trading Exchange has been
  received), but before the IOTP Transaction has finished then the
  Consumer sends a Cancel Block with an appropriate Status Component to
  the net location identified by the SenderNetLocn or
  SecureSenderNetLocn contained in the Protocol Options Component
  contained in the TPO Block for the transaction. This is normally the
  Merchant Trading Role.

  A Consumer should not send a Cancel Block after the IOTP Transaction.
  Cancelling a complete should be treated as a technical error.

  After cancelling the IOTP Transaction, the Consumer should go to the
  net location specified by the CancelNetLocn attribute contained in the
  Trading Role Element for the organisation that was sent the Cancel
  Block.

  A non-Consumer Trading Role should only cancel a transaction:

  o after a request block has been received and

  o before the response block has been sent

  If a non-Consumer Trading Role cancels a transaction at any other time
  it should be treated by the recipient is an error.

  3.11.2 Handling Cancelled Transactions

  If a Cancel Block is received by a Consumer at a point in the IOTP
  Transaction when cancellation is allowed, then the Consumer should
  stop the transaction.

  If a Cancel Block is received by a non-Consumer role, then the Trading
  Role should anticipate that the Consumer may go to the location
  specified by the CancelNetLocn attribute contained in the Trading Role
  Element for the Trading Role.

  4. IOTP Error Handling

  IOTP is designed as a request/response protocol where each message is
  composed of a number of Trading Blocks which contain a number of
  Trading Components. There are a several interrelated considerations in
  handling errors, re-transmissions, duplicates, and the like. These
  factors mean IOTP aware applications must manage message flows more
  complex than the simple request/response model. Also a wide variety of
  errors can occur in messages as well as at the transport level or in
  Trading Blocks or Components.

  This section describes at a high level how IOTP handles errors,
  retries and idempotency. It covers:

  o the different types of errors which can occur. This is divided
    into:
    - "technical errors" which are independent of the meaning of the
      IOTP Message,
    - "business errors" which indicate that there is a problem specific
      to the process (e.g. payment or delivery) which is being carried
      out, and

  o the depth of the error which indicates whether the error is at
    the transport, message or block/component level

  o how the different trading roles should handle the different
    types of messages which they may receive.

  4.1 Technical Errors

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

  If communications are too poor, a message which was sent may not reach
  its destination. In this case a time-out might occur.

  The Error codes 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 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 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) 6.14) of a "response
  block" of the normal appropriate type, for example a Payment Response Block
  or a Delivery Response Block. This allows whatever additional response
  related information is needed to accompany the error indication.

  Business errors must usually be presented to the user so that they can
  decide what to do next. For example, if the error is insufficient
  funds in a Brand Independent Purchase Offer (see section 8.3.1), 8.1.2.2), the user
  might wish to choose a different payment instrument/account of the
  same brand or a different brand or payment system. Alternatively, if
  the IOTP based implementation allows it and it makes sense for that
  instrument, the user might want to put more funds into the
  instrument/account and try again.

  4.3 Error Depth

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

  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, _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 Components (see section 6.19) sent to the other party. The Error
  Component  includes a Severity attribute which indicates whether the
  error is a Warning and may be ignored, a TransientError which
  indicates that a retry may resolve the problem or a HardError in which
  case the transaction must fail.

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

  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 Checks on these blocks should only be carried out
    if the XML is valid

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

  4.3.3 4Block Block Level

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

  Block level errors can be either:

  o technical errors, or

  o business errors

  Technical Errors are further divided into:

  o Block Level Attribute and Element Checks, and

  o Block and Component Consistency Checks

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

  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 checking the consistency of
    attribute values and element content against other attribute
    values or element content within any other components in the
    same block.

  4.3.3.2 Block and Component Consistency Checks

  Block and Component Consistency Checks consist of:

  o checking that the combination of blocks and/or components
    present in the IOTP Message are consistent with the rules
    contained within this IOTP specification

  o checking for consistency between attributes and element content
    within the blocks within the same IOTP message.

  o checking for consistency between attributes and elements in
    blocks in this IOTP message and blocks received in earlier IOTP
    messages for the same IOTP transaction

  4.3.3.3 Block Business Errors

  If a business error occurs in a process such as a Payment or a
  Delivery, then the usual appropriate type of response block is returned. The
  Status Component (see section 6.15) 6.14) 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 | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -------------->
                           or message level errors   Errors      |
                                      |OK                        |
                                      v                          |
   11. Generate output <-------2. More Blocks <------------------ +- <----------------- + -
         message               No    to process?                 |  |
            |                        |Yes                        |  |
            v                         v                          |  |
      -------------           3. Check Block OK ---------------> |  |
     |    Output   |                 |               Errors      |  |
     | OTP Message | IOTP Message|                 |Checks OK                  |  |
      -------------                  v                           |  |
                    ----- ---4.
                    ---------4. Type of  Block ? -------         |  |
                   |           |           |            |        |  |
      ----- ---Status
      ---------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
  technical error found, an appropriate Error Component should be
  created to be included in the IOTP Message sent back to the Consumer.
  Note that some checking of the Transaction Reference Block and the
  Signature Block has occurred as part of Message Level error checking.

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

  4.4.1.4 Determine the Type of the Block

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

  4.4.1.5 Status Request Blocks

  Status Request Blocks (step 5) are either:

  o Inquiry Request Trading Block (see section 7.14), 7.12), or

  o Ping Request Block (see section 7.16). 7.14).

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

  No idempotency actions are required.

  4.4.1.6 Action Request Blocks

  Blocks which request an action and change state need to be subject to
  idempotency duplicate filtering by checking to see if the same block
  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 block 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 are sent by Consumers to a server specified in
           the ErrorNetLocn attribute of potentially two locations:

  o the appropriate Trading Role
           element as a response to _request_ location, i.e. the location from which they
    received the detection of an error in an IOTP Message message that has been received (see section 4.4.1.9
           Generate Error Block). This contained the error, and

  o optionally, the ErrorLogNetLocn which may be a separate
    location maintained for the purpose of logging errors

  The ErrorLogNetLocn block may be the same server location as is
           used to accept IOTP Messages which contain no error. the _request_
  location. In this case, the error block must not considered as a fatal
  error.
  [Note End]

  In order to avoid loops, no Error Block should be sent to the Consumer
  in response to an IOTP Message received from a Consumer where the IOTP
  message contains an Error Block with a severity of HardError.

  4.4.1.9 Generate Error Block

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

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

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

  4.4.1.10 Add Block to Output Message

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

  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 | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -->
                           or message level errors   |Errors
                                      |OK            |
                                      v              |
11.Blocks to be sent?<---------2. More Blocks <-- -------------------- ------------------
             |    |No       No    to process?        |               ^
          Yes|    v                   |Yes           |               |
             v   STOP                 v              |               |
      12. Generate            3. Check Block OK - -->|               |
     output message                  |               |Errors         |
          |                          |Checks OK      |               |
          v                          v               |               |
    -------------   ------  4. Type of  Block ? -----|               |
   |    Output   | |        |    |           |       |               |
   | OTP Message | IOTP Message| |    ----     |           |       |               |
    -------------  |   |         |           |       |               |
       ------------    |         |           |       |               |
      |              --          |           |       |               |
      v             v            v           v       |               |
    Status       Action    Encapsulating  Error      |               |
   Request      Response       Block      Block      |               |
     |             |             |          |         |              |
     |             v             v          v         |              |
     |       6a. Action   7. Process 8a.Error Block---- > Transient  |
     |        Response  encapsulated     severity ? |       Error    |
     |        received     message      |Hard Error |      (retry)   |
     |        before ?          |  |    |           |         |      |
     |       Yes|   |No       Ok|  |         v      |       WAIT     |
     |      (Ig-|   |           |  |       STOP     |         |      |
     |      nore|)  v           |  |                v         v      |
     |          | 6b. Process  |   ----- ->   -------> 9. Generate      8b.     |
     |          |    Action    |  Errors    Error Block    Retrieve  |
     |          |   Response---+-------- -->   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 re-
  transmissions of the request. If a user is present, they may be
  offered options of continuing to retransmit the request or of
  cancelling the transaction.

  4.4.2.2 Process all the blocks

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

  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), 7.13), or

  o Ping Response Blocks (see section 7.17) 7.15)

  In general, such blocks should be considered a status update. The best
  action to take at the requester may depend on whether this is in
  response to a user originated or automatic status request, whether a
  status display that could be updated is being presented to the user,
  and whether the status response block shows a change in status from a
  previous response block for the same type of status. Thus client
  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) , 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

  The net locations consumers send Error Blocks to are:

  o the Error Net Location net location which sent them the IOTP Message which was in
    error, this is either:
    - the location specified by the SenderNetLocn or SecureSenderNetLocn
      attribute of the Protocol Options Component if the problem was
      contained in the Trading Role Element (see section 6.5.2) for TPO Block or the
           Organisation that Offer Response Block
    - the location to which the Payment Request Block was sent if the
      problem is in either a Payment Exchange or a Payment Response
      Block, or
    - the server. Any errors encountered location to which the Delivery request Block if the problems
      in
           sending such an error indication should be, at most, logged a Delivery Response Block, and must not result in any further attempts to transmit any
           error indication.
  [Note End]

  o if present, the server identified by the ErrorLogNetLocn
    attribute of the Trading Role element identified by the
    SenderTradingRoleRef the Message Id Component.

  4.4.2.10 Add Block to Output Message

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

  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 contain digests of one or more IOTP Components or Trading
    Blocks, possibly including other Signature Components, in any
    IOTP message within the same IOTP Transaction

  o identify:
    - which Organisation signed (generated) (originated) the signature, and
    - which Organisation(s) should verify be the receive the signature in order
      to check that the Action the Organisation should take can occur.

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

        OTP

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

IOTP MESSAGE                                  SIGNATURE COMPONENT

OTP

IOTP MESSAGE                                    OtpSignature                                   Signature Id = P1.3
 |-Trans Ref Block           hash        digest TransRefBlk   |-SignedData   |-Manifest
 |  |      ID=P1.1-------- ---------------------|->|-Hash      ID=P1.1-----------------------------|->|-Digest of P1.1--- P1.1--
 |  |-Trans Id Comp          hash       digest TransIdComp   |  |                 |
 |  |     ID = M1.2------- ---------------------|->|-Hash M1.2----------------------------|->|-Digest of M1.2---| M1.2--|
 |  |-Msg Id Comp.              hash element           digest Signature  |  |                 |
 |  |      ID = P1           -------------------|->|-Hash          -------------------|->|-Digest of M1.5---| M1.5--|
 |                         |     hash   digest element  |  |                 |
 |-Signature
 |-IOTPSignatures Block    |  -----------------|->|-Hash  -----------------|->|-Digest of M1.7---| M1.7--|
 |  |       ID=P1.2        | |    hash  digest element |  |                 |
 |  |-Sig Comp.  |-Signature ID=P1.3    | |  ---------------|->|-Hash  ---------------|->|-Digest of C1.4---| C1.4--|
 |  |-Sig Comp. ID=M1.5--- -  |-Signature ID=M1.5----  | |               |                    |
 |  |-Cert Comp.  |-Signature ID=P1.4      | | CertRef Iden-  -DigSig Points to     |-RecipientInfo*     |
 |  |-Cert Comp. ID=M1.6<- ---|-|---------------------CertRef=M1.6  |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6     |
 |  |                        | | tifies Certs    Content: to use  |   SignatureValueRef|
 |  |                        | |               |  Points|to Value El|
 |  |                        | |               |        v           |
 |-Trading Block. ID=P1.5    | |    to use         JtvwpMdmSfMbhK<-                -Value* ID=P1.4:    |
 |  |-Comp. ID=M1.7------- --- ID=M1.7----------  |                   r1Ln3vovbMQttbBI                   JtvwpMdmSfMbhK<--|
 |  |                          |                   J8pxLjoSRfe1o6k                   r1Ln3vovbMQttbBI |
 |  |-Comp. ID=P1.6            |                   OGG7nTFzTi+/0<--                     J8pxLjoSRfe1o6k|
 |  |                          |                     OGG7nTFzTi+/0<-
 |  |-Comp. ID=C1.4------------
 |  |-Comp. ID=C1.4------- ----- ID=C1.5                         Digital signature of-
 |  |-Comp. ID=C1.5
                                            SignedData element
                                            using certificate
                                            identified by CertRef

  Elements signed that are digested can be in any OTP IOTP Message
       within the same OTP IOTP Transaction
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 12 Signature Hashing Digests

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

  [Note End]

  Note that one Manifest may be associated with multiple signature
  "Value" elements where each Value element contains a digital signature
  over the same manifest, perhaps using the same (or different)
  signature algorithm but using a different certificate

  This may be used to allow each potential recipient of a signature to
  use different certificates. Specifically it will allow the Merchant to
  agreed different shared secrets with their Payment Handler and
  Delivery Handler.

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

  The remainder of this section contains:

  o an example of how IOTP uses signatures

  o how the SignerOrgRef OriginatorInfo and VerifierOrgRef attributes RecipientInfo elements within a
    Signature Component are used to identify the organisations
    associated with the signature

  o how signatures may use either Symmetric or Asymmetric
    Cryptography

  o Mandatory and Optional use of Signatures by IOTP, and

  o how IOTP uses signatures to prove actions complete successfully

  5.1.1 IOTP Signature Example

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

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

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

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     | Originator |-Originator
      v                       (Merchant)                  |      ------------|--Info
    Brand List                                    Ref     |
  >Component                                              |
 | |-Protocol       ------>  Organisation<--------------  |-Dig Sig  Organisation     Recipient   |-Recipient
 | | Amount Elem   |         Component         Verifier <------------------|--Info
 | | Element
 |   |           |          |                 Refs      |                OrgRef    -|-(Payment
 | | Pa|Protocol   |Action     -Trading Role              |  Handler)
 | |   | Ref       |OrgRef       Element                  |
 | |   v           |          (Payment Handler)           |
 |  -PayProtocol--                                        |
 |    Elem                  ->Organisation<-------------  |-Dig Sig                  ->Organisation    Recipient   |-Recipient
 |                         |  Component        Verifier <-----------------|--Info
 |                         | Element
 |  |                 Refs      |                OrgRef    -|-(Delivery
 |                         |   -Trading Role              |  Handler)
 |                         |     Element                  |
 |                         | (Delivery Handler)            -SignedData            -Manifest
 |                         |                                Element                                      ^
 |           OFFER RESPONSE BLOCK                                 |
 |                         |                Contains hashes of:----- digests of:--
 |BrandListRef             |ActionOrgRef    -Trans Ref Block (not
 |                         |                 shown)
  --Payment                 ---Delivery     -Transaction Id Component
   Component                  Component      (not shown)
                                            -Org Components (Merchant,
                                             Payment Handler,
                                             Delivery Handler
                                            -Brand List Component
                                            -Order Component
                                            -Payment Component
                                            -Delivery Component
                                            -Brand Selection Component
                                             (if Brand Dependent)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

        Figure 13 Example use of Signatures for Baseline Purchase
  5.1.2 SignerOrgRef OriginatorInfo and VerifierOrgRef Attributes RecipientInfo Elements

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

  Note that the type value of the Signature Component content of the Attribute element with a
  type attribute set to IOTPSignatureType must match the Trading Role of
  the Organisation which signed it. If it does not, then it is an error.
  Valid combinations are given in the table below.

         IOTP Signature Type        Valid
           Component Trading
              Type Role

        OfferResponse           Merchant

        PaymentResponse         PaymentHandler

        DeliveryResponse        DeliveryHandler

        AuthenticationRequest   any role

        AuthenticationResponse  any role

        PingRequest             any role

        PingResponse            any role

  The VerifierOrgRef RecipientRef attribute on of the DigSig elements, RecipientInfo element in the
  Signature Component contains Element References to the Organisation
  Components of the Organisations that should use the signature to
  verify that:

  o they have a pre-existing relationship with the Organisation
    that generated the signature,

  o the data which is secured by the signature has not been
    changed,

  o the data has been signed correctly, and

  o the action they are required to undertake on behalf of the
    Merchant is therefore authorised.

  5.1.3 Symmetric and Asymmetric Cryptography

  The Signer of an Action Originator and a Verifier Recipient of an Action a signature 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 RecipientInfo and Value
  elements are contained within the Signature Component. This approach
  is more likely if symmetric cryptography is being used between the
  Trading Roles.

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

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

  5.1.4 Mandatory and Optional Signatures

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

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

  5.1.5 Using signatures to Prove Actions Complete Successfully

  Proving an action completed successfully, is achieved by signing data
  on Response messages. Specifically:

  o on the Offer Response, when a Merchant is making an Offer to
    the Consumer which can then be sent to either:

    - a Payment Handler to prove that payment is authorised, the Merchant authorises Payment,
      or
    - a Delivery Handler to prove that Delivery is authorised Merchant authorises Delivery,
      provided other necessary authorisations are complete (see below)

  o on the Payment Response, when a Payment Handler is generating a
    Payment Receipt which can be sent to either:
    - a Delivery Handler, in a Delivery Request Block to prove that
       delivery is authorised, authorise
      Delivery together with the Offer Response signature, or
    - another Payment Handler, in a second Payment Request, to prove
       that authorise
      the second payment in a Value Exchange IOTP Transaction is
       authorised. Transaction.

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

  5.2 Checking a Signature is Correctly Calculated

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

  Before a Trading Role can check a signature it must identify which of
  the potentially multiple digital signature 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 find the Trading Role should
     verify.
    RecipientInfo element that contains a RecipientRefs attribute
    that refers to that Organisation Component. Note there may be
    no signatures for a Trading Role to
     verify.

  o verify

  o check the Signature Components Component that contain contains the Digital
     Signature Elements identified
    RecipientInfo element as follows as follows:
    - check use the SignatureValueRef, the SignatureAlgoritmRef and the
      SignatureCertRef attributes to identify: respectively, the Value
      element that contains the signature to be checked, the Algorithm
      element that describes the signature algorithm to be used to
      verify the Digital Signature and the Certificate to be used by the
      signature algorithm, then
    - check that the Value Element correctly signs the
       Signed Data Manifest Element
    - check that the Hash Digest Elements in the Signed Data Manifest Element are
      correctly calculated where Components or Blocks that are hashed referenced by the
      Digest have been received by the organisation checking the
      signature

  5.3 Checking a Payment or Delivery can occur

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

  In outline the steps are:

  o check that the Payment Request or Delivery Request has been
    sent to the correct organisation

  o check that correct IOTP components are present in the request,
    and

  o check that the payment or delivery is authorised

  For clarity and brevity the following terms or phrases are used in
  this section:

  o a "Request Block" is used to refer to either a Payment Request
    Block (see section 7.6) 7.7) or a Delivery Request Block (see
    section 7.9) 7.10) unless specified to the contrary

  o a "Response Block" is used to refer to either a Payment
    Response Block (see section 7.8) 7.9) or a Delivery Response Block
    (see section 7.10) 7.11)

  o an "Action" is used to refer to an action which occurs on
    receipt of a Request Block. Actions can be either a Payment or
    a Delivery

  o an "Action Organisation", is used to refer to the Payment
    Handler or Delivery Handler that carries out an Action

  o a "Signer of an Action", is used to refer to the Organisations
    that sign data about an Action to authorise the Action, either
    in whole or in part
  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

       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.

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.

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.

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.

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) 7.7) or in the Delivery Request Block (see section
  7.9).
  7.10).

  If components are missing, there is an error.

  5.3.3 Check an Action is Authorised

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

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

  The steps involved are as follows:
  1.

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.

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.

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
      that contain references to the Action
       Organisation's Organisation Component. (see
      5.3.1). Depending on the IOTP Transaction being carried out
      (see section 8) either one or two signatures may be
      identified

   b) checking that the Signature Components are correct. This
      involves checking that Digest elements exist within the
      Manifest Element that refer to the necessary Trading
      Components
       have been hashed (see section 5.3.3.1).

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

  5.3.3.1 Check the Signatures Sign Correct Data Digests are correct

  All Signature Components contained within IOTP Messages must always
  hash: include
  Digest elements that refer to:

  o the Transaction Id Component (see section 3.3.1) of the IOTP
    message that contains the Signature Component. This binds the
    globally unique OtpTransId to other components which make up
    the IOTP Transaction

  o the Transaction Reference Block (see section 3.3) of the first
    IOTP Message that contained the signature. This binds the
    OtpTransId with information about the IOTP Message contained
    inside the Message Id Component (see section 3.3.2).

  Checking

  Check that each signature signs the correct data, involves checking Signature Component contains Digest elements that hashes of the necessary components are present in the SignedData
  element of
  refer to the Signature Component. correct data required.

  The hashes Digest elements that need to be present depend on the Trading Role
  of the Organisation which generated (signed) the signature:

  o if the signer of the signature is a Merchant then:
    - hashes Digest elements 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 Digest
    elements must be present for:
    - the Signature Component signed by the Merchant, and optionally
    - one or more Signature Components signed by the previous Payment
      Handler(s) identified by in the appropriate ActionSignerRefs
       attribute. Transaction.

  5.4 Data Integrity and Privacy

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

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

  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

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

          IOTP MESSAGE  <-----------  OTP IOTP Message - an XML Document
           |                         which is transported between the
           |                         Trading Roles
           |-Trans Ref Block <-----  Trans Ref Block - contains
           |  |                      information which describes the
           |  |                      OTP                      IOTP Transaction and the OTP IOTP
                                     Message.
 --------> |  |-Trans Id Comp. <---  Transaction Id Component -
|          |  |                      uniquely identifies the OTP IOTP
|          |  |                      Transaction. The Trans Id
|          |  |                      Components are the same across
|          |  |                      all OTP IOTP messages that comprise a
|          |  |                      a single OTP IOTP transaction.
|          |  |-Msg Id Comp. <-----  Message Id Component -
|          |                         identifies and describes an OTP IOTP
|          |                         Message within an OTP IOTP
|          |                         Transaction
|          |-Signature Block <-----  Signature Block (optional) -
|          |  |                      contains one or more Signature
|          |  |                      Components and their associated
|          |  |                      Certificates
|     ---> |  |-Signature Comp. <--  Signature Component - contains
|    |     |  |                      digital signatures. Signatures
|    |     |  |                      may sign hashes digests of the Trans Ref
|    |     |  |                      Block and any Trading Component
|    |     |  |                      in any OTP IOTP Message in the same
|    |     |  |                      OTP                      IOTP Transaction.
|    |     |  |-Certificate Comp. <- Certificate Component. Used to
|    |     |                         check the signature.
  Trading  |-Trading Block <-------- Trading Block - an XML Element
Components |  |-Component            within an OTP IOTP Message that
|    |     |  |-Component            contains a predefined set of
|     ---> |  |-Component            Trading Components
|          |  |-Component
|          |  |-Component <--------- Trading Components - XML
|          |                         Elements within a Trading Block
|          |-Trading Block           that contain a predefined set of
 --------> |  |-Component            XML elements and attributes
           |  |-Component            containing information required
           |  |-Component            to support a Trading Exchange
           |  |-Component
           |  |-Component
           |
           |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 16 Trading Components
  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> EMPTY >
<!ATTLIST ProtocolOptions
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 ShortDesc          CDATA   #REQUIRED
 SenderNetLocn      CDATA   #REQUIRED   #IMPLIED
 SecureSenderNetLocn CDATA   #REQUIRED  #IMPLIED
 SuccessNetLocn     CDATA   #REQUIRED >

  Attributes:

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

xml:lang

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

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

  Either SenderNetLocn, SecureSenderNetLocn or both must be present.

  6.2 Authentication Data Component

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

<!ELEMENT AuthData (PackagedContent)> (PackagedContent+, Algorithm+)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
  AuthMethod
 TradingRoleList    NMTOKEN #REQUIRED
  TradingRoleListNMTOKENS #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 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

AlgorithmRefs       This identifies the content contains a list of the Authentication
                   Data Component. Valid values are:
                   o  sha1 This indicates that the recipient of Algorithm Elements
                    contained within the
                      Authentication Auth Data Component should generate a
                      hash. See 6.3 Authentication Response Component.
                   o  signature This indicates from
                    which the recipient of the
                      Authentication Data AuthData Component should generate a
                      digital signature
                    must choose one to include in use to generate 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 (see section (3.7.3 User Defined Codes). 6.3). Note
                    there only one Algorithm may be present.

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

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

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

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

  Content:

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

Algorithm           This contains information which describes an
                    Algorithm (see 6.17 Signature Components) that
                    may be used to generate the Authentication
                    Response.

  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  It uses one of the Algorithms selected contained in
  the AuthData Component (see section 6.2). Depending on the Algorithm
  selected, the results of the applying the algorithm will either be
  contained in a Signature Component that signs the Authentication
  Response and other data, or in the Packaged Content element within the
  Authentication Response Component. Its definition is as follows.

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

  Attributes:

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

SelectedAlgorithmRef  An Element Reference that identifies the
                      Algorithm used in generating the
                      Authentication Response. It must be one of the
                      Element References contained within the
                      AlgorithmRefs attribute of the Authentication
                      Data Component (see section 6.2)

ContentSoftwareId     This contains information which identifies the
                      software which generated the content of the
                      element. Its purpose is to help resolve
                      interoperability problems that might occur as
                      a result of incompatibilities between messages
                      produced by different software. It is a single
                      text string in the language defined by
                      xml:lang. It must contain, as a minimum:
                      o the name of the software manufacturer
                      o the name of the software
                      o the version of the software, and
                      o the build of the software
                      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 may contain the response to the content generated as a
                    result of applying the Algorithm selected from
                    the Authentication Data Component see section 6.2 as
                    Packaged Content (see section 3.8).
                    6.2.

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

  6.4 Order Component

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

<!ELEMENT Order (PackagedContent?) (PackagedContent*) >
<!ATTLIST Order
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
  OrderIdentifierCDATA
 OrderIdentifier    CDATA   #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 one or more Packaged Content Contents (see section
                    3.8).

  6.4.1 Order Description Content

  The Packaged Content element will normally be required, however it may
  be omitted where sufficient information about the purchase can be
  provided in the ShortDesc attribute attribute. If the full Order Description
  requires it several Packaged Content elements may be used.

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

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

  6.4.2 OkFrom and OkTo Timestamps

  Note that:

  o the OkFrom date may be later than the OkFrom date on the
    Payment Component (see section 6.8) associated with this order,
    and

  o similarly, the OkTo date may be earlier that the OkTo date on
    the Payment Component (see section 6.8).

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

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

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

           -

           o the offer is time limited

           -

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

           -

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

  6.5 Organisation Component

  The Organisation Component provides information about an individual or
  an organisation. This can be used for a variety of purposes. For
  example:

  o to describe the merchant who is selling the goods,

  o to identify who made a purchase,

  o to identify who will take delivery of goods,

  o to provide a customer care contact,

  o to describe who will be the Payment Handler.

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

  Its definition is as follows.

<!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
 ID              ID      #REQUIRED
 TradingRole        NMTOKEN #REQUIRED
 CancelNetLocn      CDATA   #REQUIRED
 ErrorNetLocn       CDATA   #REQUIRED
 ErrorLogNetLocn CDATA   #IMPLIED >

  Attributes:

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

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

                    Values of TradingRole are controlled under the
                    procedures defined role (see in section 3.7.3 User Defined Codes).

ErrorNetLocn       The Values for
                    IOTP Codes which also allows user defined values
                    to be defined.

CancelNetLocn       This contains 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 where the
                    Consumer should go to if the Consumer cancels
                    the transaction for some reason. It can be used
                    by the Trading Role to provide a response which
                    is more
                   details. tailored to the circumstances of a
                    particular transaction.

                    This attribute attribute:
                    o must not be present when TradingRole is set to
                      Consumer role,
                    o must be present when TradingRole is set to
                      Merchant, PaymentHandler or DeliveryHandler.

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

CancelNetLocn

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

                    See section 6.19.1 Error Processing Guidelines
                    for more details.

                    This attribute:
                    o must not be present when TradingRole is set to
                      Consumer role,
                    o must be present when TradingRole is set to
                      Merchant, PaymentHandler or DeliveryHandler.

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

ErrorLogNetLocn     Optional. This contains the net location that
                    Consumers should send IOTP Messages that contain
                    Error Blocks with an Error Component with the
                    Severity attribute set to either:
                    o HardError,
                    o Warning but the Consumer decides to not
                      continue with the transaction
                    o TransientError and the transaction has
                      subsequently timed out.

                    This attribute:
                    o must not be present when TradingRole is set to
                      Consumer role,
                    o must be present when TradingRole is set to
                      Merchant, PaymentHandler or DeliveryHandler.

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

                    The ErrorLogNetLocn can be used to send error
                    messages to the software company or some other
                    organisation responsible for fixing problems in
                    the software which sent the incoming message.
                    See section 6.19.1 Error Processing Guidelines
                    for more details.

  6.5.3 Contact Information Element

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

<!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) (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 ) 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?) (PackagedContent*) >
<!ATTLIST Brand
  Id
 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 two valid value values for the
                    BrandIdDomain is have been defined:
                    o IOTP which indicates that the
                    BrandValue is registered with IOTP.

                    The valid values for of BrandValue for brands defined
                    within the IOTP Brand domain
                      are obtainable from managed under the procedure described in
                      section 3.7.3 Values for IOTP web site http:www.IOTP.org.

                    A user defined code follows Codes, and
                    o SET which indicates that the BrandValue
                      conforms to [SET] conventions
                    defined in section 3.7.3. Uniqueness

                    Examples of a user
                    defined BrandIds are: IOTP:Mondex,
                    SET:MasterCard::, and
                    SET:Visa:Gold:AmericanAirlines.  The first
                    BrandId is not guaranteed.

BrandName           This contains the name an example of an IOTP BrandId, and
                    the following two are SET BrandIds.

                    As values of BrandId are controlled under the
                    procedures defined in section 3.7.3 Values for
                    IOTP Codes user defined values may be defined.

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

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

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

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

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

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

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

  Content:

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

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

  6.6.2 Protocol Amount Element

  The Protocol Amount element links a Brand to:

  o the currencies and amounts in Currency Amount Elements (see
    section 6.6.3) that can be used with the Brand, and

  o the Payment Protocols and Payment Handlers defined in a Pay
    Protocol Element (see section 6.6.4), which can be used with
    those currencies and amounts.

  Its definition is as follows:

<!ELEMENT ProtocolAmount (PackagedContent?) (PackagedContent*) >
<!ATTLIST ProtocolAmount
  Id
 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

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

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

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

  Content:

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

  Examples of Protocol Amount Elements are contained in10 Brand List
  Examples.

  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                 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
                    . IOTP indicates that values of CurrCode are
                      managed under the procedure described in
                      section 3.7.3 User Defined Codes). Values for IOTP Codes

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

  Note that Amount, CurrCodeType and CurrCode have identical meanings to
  the attributes
                    As values of CurrCodeType are managed under the same name on the Payment Component (see
                    procedure described in section
  6.8). 3.7.3 Values for
                    IOTP Codes user defined values of CurrCodeType
                    may be defined.

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

  6.6.4 Pay Protocol Element

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

<!ELEMENT PayProtocol (PackagedContent?) (PackagedContent*) >
<!ATTLIST PayProtocol
  Id
 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

                    Values of ProtocolId is defined in are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes.

                    Each payment supplement for defines the value to be
                    used with that payment method.

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

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

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

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

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

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

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

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

                    It is recommended that this attribute is
                    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 elements (see section
                    3.8) containing information about the protocol
                    which is used by the payment protocol. The
                    content of this information is defined in the
                    supplement for a payment protocol which
                    describes how the payment protocol works with
                    IOTP. An example of its use could be to include
                    a payment protocol message.

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

  6.7 Brand Selection Component

  A Brand Selection Component identifies the choice of payment brand,
  payment protocol and the Payment Handler.  This element is used:

  o in Payment Request messages within Baseline Purchase and
    Baseline Value IOTP Transactions to identify the brand,
    protocol and payment handler for a payment, or

  o to, optionally, inform a merchant in a purchase of the payment
    brand being used so that the offer and order details can be
    amended accordingly.

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

  The definition of a Brand Selection Component is as follows.

<!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
BrandSelProtocolAm  required by a particular payment
BrandSelCurrencyAmountInfo brand or
ountInfo,           protocol. See sections 6.7.1, 6.7.2, and 6.7.3.
BrandSelCurrencyAm
ountInfo

  The following rules apply:

  o the BrandListRef must contain the ID of a Brand List Component
    in the same IOTP Transaction
  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) (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
  Id
 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 elements (see section 3.8) that contains
                    contain additional data that may be required by
                    a particular payment brand. See the payment
                    method supplement for IOTP for rules on how this
                    is used.

  6.7.2 Brand Selection Protocol Amount Info Element

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

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

  Attributes:

ContentSoftwareId   See section 6.7.1 Brand Selection Brand Info
                    Element.

  Content:

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

  6.7.3 Brand Selection Currency Amount Info Element

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

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

  Attributes:

ContentSoftwareId   See section 6.7.1 Brand Selection Brand Info
                    Element.

  Content:

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

  6.8 Payment Component

  A Payment Component contains information used to control how a payment
  is carried out. Its provides information on:

  o the times within which a Payment with a Payment Handler may be
    started

  o a reference to the Brand List (see section 6.6) which
    identifies the Brands, protocols, currencies and amounts which
    can be used to make a payment

  o whether or not 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?) EMPTY >
<!ATTLIST Payment
 ID                 ID      #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 BrandListRef       NMTOKEN #REQUIRED
 SignedPayReceipt       ('True'|'False') (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) 7.7)
                    containing the Payment Component.

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

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

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) (7.9) generated by the payment handler for
                    the payment must be digitally signed.

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

  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) (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 elements (see section 3.8). See
                    the payment scheme supplement for the definition
                    of its content.

  6.10 Payment Receipt Component

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

  Typically the content of a Payment Receipt Component will contain data
  which describes:

  o the amount paid and its currency

  o the date and time of the payment

  o internal reference numbers which identify the payment to the
    payment system

  o potentially digital signatures generated by the payment method
    which can be used to prove after the event that the payment
    occurred.

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

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

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

  [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?) (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 referenced by
                      Digests in the Payment Response signature
                      component, if one is being used.

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

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

                    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     Contains payment scheme specific record of the
                    payment which can be used for receipt purposes
                    as Packaged Content elements (see section 3.8).
                    Each payment scheme defines in its supplement
                    the structure of the content.

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

  6.11 Payment Note Component

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

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

<!ELEMENT PaymentNote (PackagedContent) (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 one or more Packaged
                    Content elements (see section 3.8).

  6.12 Delivery Component

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

<!ELEMENT Delivery (DeliveryData?, PackagedContent?) PackagedContent*) >
<!ATTLIST Delivery
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 DelivExch (True|False)          (True | False) #REQUIRED
 DelivAndPayResp (True|False)    (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) 7.11) and the Payment Response Block
                    (see section 7.8 7.9 ) are combined into one IOTP
                    Message. Valid values are:
                    o True indicates both blocks will be in the same
                      IOTP Message, and
                    o False indicates each block will be in a
                      different IOTP Message

                    DelivAndPayResp should not be true if DelivExch
                    is False.

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

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

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     Contains "user" data defined for the Merchant
                    which is required by the Delivery
                   Handler. See section 3.8 Handler as one
                    or more Packaged Content Element. Elements see section
                    3.8.

  6.12.1 Delivery Data Element

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

<!ELEMENT DeliveryData (PackagedContent?) (PackagedContent*) >
<!ATTLIST DeliveryData
 xml:lang           NMTOKEN #IMPLIED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 DelivMethod        NMTOKEN #REQUIRED
 DelivToRef         NMTOKEN #REQUIRED
  DelivReqNetLocnCDATA
 DelivReqNetLocn    CDATA   #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). 7.10).

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

                    Values of DelivMethod are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes which allows user defined delivery method see
                       3.7.3 User Defined Codes. codes to be
                    defined.

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

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

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

SecDelivReqNetLocn  This contains the Net Location to which a
                    secured Delivery Request Block (see section 7.9)
                    7.10) 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     Additional information about the delivery as one
                    or more Packaged Content elements (see section 3.8).
                    3.8) provided to the Delivery Handler by the
                    merchant.

  6.13 Delivery Note Component

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

  For interoperability, the Delivery Note Component Packaged Content
  should support both Plain Text and HTML.

<!ELEMENT DeliveryNote (PackagedContent) (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

DelivHandlerDelivId   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 one
                    or more Packaged Content elements (see section
                    3.8).

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

  6.14 Payment Method Information Status Component

  A Payment Method Information Status Component contains data which describes
  the Payment Method which initiated the Payment Instrument Customer
  Care Transaction and the software which generated status information about the message. business
  success or failure (see section 4.2) of a process.

  Its definition is as follows.

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

  Attributes:

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

BrandId            The Brand Identifier attribute copied from the
                   BrandId attribute of

xml:lang            Defines the Brand Element (see language used by attributes within
                    this component. See section 6.6.1)of the Payment Instrument which
                   needs customer care.

PayProtocolId      The ProtocolId attribute copied from 3.9 Identifying
                    Languages.

StatusType          Indicates the Pay
                   Protocol Element (see section 6.6.4) type 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 process which the Status
                    is reporting on. It may be set to either Offer,
                    Payment, Delivery or Authentication Authentication.

                    Values of StatusType are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes which also allows user defined values
                    of StatusType to be defined.

ElRef               Contains an Element Reference (see section 3.5)
                    to the Component for which the Status is being
                    described. It must refer to either:
                    o a Trading Protocol Options Block (see section
                      7.1), if the StatusType is Offer,
                    o a Payment Component (see section 6.8), if the
                      StatusType is Payment, or
                    o a Delivery Component (see section 6.12), if
                      the StatusType is Delivery
                    o an Authentication Data Component (see section
                      6.2) if the statusType 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). 7.12). It indicates there was a
                      Technical Error (see section 4.1) in the
                      Request Block which is being processed or some
                      internal processing error.

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

CompletionCode      Indicates how the process completed. Valid
                    values for the CompletionCode are given below
                    together with the conditions when it must be
                    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) 7.13) to give the
                    reference number for a transaction which has
                    previously been unavailable.

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

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

6.15.1.1

  6.14.1 Offer Completion Codes

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

       Value                           Description

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

OfferDecl

ConsCancelled       Consumer Cancelled. The Consumer decides to
                    cancel the transaction for some reason. This
                    code is only valid in a Status Component
                    contained in a Cancel Block.

MerchCancelled      Offer Declined. Cancelled. The Merchant declines to
                    generate an offer for some reason. reason and cancels
                    the transaction. This code is only valid in a
                    Status Component contained in a Cancel Block.

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

6.15.1.2

  6.14.2 Payment Completion Codes

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

       Value                           Description

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

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

ConsCancelled       Consumer Cancelled. The Consumer decides to
                    cancel the payment for some reason. This code is
                    only valid in a Status Component contained in a
                    Cancel Block.

PaymtCancelled      Payment Cancelled. The Payment Handler declines
                    to complete the payment for some reason and
                    cancels the transaction. This code is only valid
                    in a Status Component contained in a Cancel
                    Block.

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

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

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

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

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

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

6.15.1.3

  6.14.3 Delivery Completion Codes

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

       Value                           Description

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

                    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. re-
                    ordered. This is only valid if ProcessState is
                    Failed.

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

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

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

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

ConsCancelled       Consumer Cancelled. The Consumer decides to
                    cancel the delivery for some reason. This code
                    is only valid in a Status Component contained in
                    a Cancel Block.

DelivCancelled      Delivery Cancelled. The Delivery Handler
                    declines to complete the Delivery for some
                    reason and cancels the transaction. This code is
                    only valid in a Status Component contained in a
                    Cancel Block.

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

6.15.1.4

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

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

AutEeCancel         Authenticatee Cancel. The organisation being
                    authenticated declines to be authenticated. authenticated for
                    some reason. This could be, for example because
                    the signature on an Authentication Request was
                    invalid or the Authenticator was not known or
                    acceptable to the Authenticatee.

AutOrCancel         Authenticator Cancel. The organisation
                    requesting authentication declines to validate
                    the Authentication Response received for some
                    reason and cancels the transaction.

NoAuthData          Authentication Data Not Available. The
                    Authenticatee does not have the data that must
                    be provided so that they may be successfully
                    authenticated. For example a password may have
                    been forgotten, the Authenticatee has not yet
                    become a member, or a smart card token is not
                    present.

AuthFailed          Authentication Failed. The Authenticator checked
                    the Authentication Response but the
                    authentication failed for some reason. For
                    example a password may have been incorrect.

TradRolesIncon      Trading Roles Inconsistent. The Trading Roles
                    contained within the TradingRoleList attribute
                    of the Authentication Data Component are
                    inconsistent with the Trading Role which the
                    Authenticatee is taking in the OTP transaction IOTP Transaction
                    or is able to take. Examples of inconsistencies
                    include:
                    o asking a PaymentHandler for DeliveryHandler
                      information
                    o asking a Consumer for Merchant information

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

6.16

  6.15 Trading Role Data Component

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

  Trading Role Components identify:

  o the organisation that generated the component, and

  o the organisation that is to receive it.

  They are first generated and included in a "Response" Block, and then
  copied to the appropriate "Request" Block. For example a Payment
  Handler might need to inform a Delivery Handler that a credit card
  payment had been authorised but not captured. There may also be other
  information that the Payment Handler has generated who where the format is
  privately agreed with the Delivery Handler which needs to be
  communicated. In another example a Merchant might need to provide a
  Payment Handler with some specific information about a Consumer so
  that consumer can acquire double loyalty points with the payment.

  Its definition is as follows.

<!ELEMENT TradingRoleData (PackagedContent) (PackagedContent+) >
<!ATTLIST TradingRoleData
  ID                ID      #REQUIRED
  OriginatorElRefNMTOKEN
  OriginatorElRef   NMTOKEN #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 Roles as one or more
                    PackagedContent elements see section 3.8.

6.16.1

  6.15.1 Who Receives a Trading Role Data Component

  The rules for deciding what to do with Trading Role Data Components
  are described below.

  o whenever a Trading Role Data Component is received in a
    "Response" block identify the Organisation Components of the
    Organisations that are to receive it as identified by the
    DestinationElRefs attribute.

  o whenever a "Request" Block is being sent, check to see if it is
    being sent to one of the Organisations identified by the
     DestinationElRef
    DestinationElRefs attribute. If it is then include in the
    "Request" block:
    - the Trading Role Data Component as well as,
    - the Organisation Component of the Organisation identified by the
       OrignatorElRef
      OriginatorElRef attribute (if not already present)

6.17

  6.16 Inquiry Type Component

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

<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
 ID                 ID      #REQUIRED
 Type (Offer|Payment|Delivery)               NMTOKEN #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 6.14).

  6.17 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

  [Note]   Definitions of the XML structures for signatures is and
           certificates are described in the paper "Digital Signature Signatures
           for XML - Proposal", see [XMLSIG]. [XMLDSIG]. As this is an Internet
           Draft, it will be subject to revision.

           However there is an immediate need for a more stable version
           to be used with pilots of IOTP that are currently planned.
           Therefore, this section contains a definition of a Signature
           Component that closely follows the definitions contained in
           XMLDSIG, but has been modified to meet some specific IOTP
           requirements.

           In the future it is anticipated that future versions of IOTP
           will adopt a stable version of the XMLDSIG once it becomes
           available.
  [Note End]

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

  The Signature Component:

  o  hashes contains digests of one or more Blocks or Components in one or
    more IOTP Messages within the same IOTP Transaction and places
    the result in a Digest Element

  o concatenates these hashes into Digest elements with other information on
    the type of signature, the originator and potential recipients
    of the signature and details of the signature algorithms being
    used and places them in a Signed Data Manifest element, and

  o signs the SignedData Manifest element using the optional certificate
    identified in the CertRef attribute of Certificate element within the Digital Signature
     element.
    Block placing the result in a Value element within a Signature
    Component

  Note that a Signed Data Element there may be signed by more than one Digital
  Signature element. multiple Value elements that contain signatures
  of a Manifest Element.

  A Signature Component can be one of two four 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 Signature,

  o a Delivery Response Signature Component Signature, or

  o an Authentication Response Signature.

  For a general explanation of signatures see section 5 Security
  Considerations.

  The Signed Data Element definition of the Offer Response a Signature Component
  should contain hashes is as follows:

<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
  ID                ID      #IMPLIED >

<!ELEMENT Manifest
  (Algorithm+,
   Digest+,
   Attributes?,
   OriginatorInfo,
   RecipientInfo+,
  )
<!ATTLIST Manifest
  LocatorHRefBase   CDATA   #IMPLIED >

<!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm
 ID                 ID      #REQUIRED
 type  (digest|signature|keyagreement) #IMPLIED
 name               NMTOKEN #REQUIRED >

<!ELEMENT Digest (Value) >
<!ATTLIST Digest
 LocatorHREF        NMTOKEN #REQUIRED
 DigestAlgorithmRef IDREF   #REQUIRED >

<!ELEMENT Attributes (Attribute+) >

<!ELEMENT Attribute ( #PCDATA ) >
<!ATTLIST Attribute
 type               NMTOKEN #REQUIRED
 critical  ( true | false ) #REQUIRED >

<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
 OriginatorRef      NMTOKEN #IMPLIED >

<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
 SignatureAlgorithmRef IDREF #REQUIRED
 SignatureValueRef  IDREF    #REQUIRED
 SignatureCertRef   IDREF    #IMPLIED
 RecipientRefs      NMTOKENS #IMPLIED >

<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
 type               PCDATA  #REQUIRED >
  6.17.1 IOTP usage of the following Components:
  o  the Transaction Id Component (see section 3.3.1) signature elements and attributes

  Detailed definitions of the IOTP
     message above elements and attributes are
  contained in [XMLDSIG]. The following contains additional information
  that describes how these elements and attributes are used by IOTP.

  SIGNATURE ELEMENT

  The ID attribute is mandatory.

  MANIFEST ELEMENT

  The optional LocatorHrefBase attribute contains text which should be
  concatenated before the Offer Response Signature
  o text contained in the Transaction Reference Block (see section 3.3) LocatorHREF attribute of
  all Digest elements within the IOTP
     Message that contains the Offer Response Signature
  o  from the TPO Block:
     - Manifest.

  Its purpose is to reduce the Protocol Options Component
     - each size of LocatorHREF attribute values
  since the Organisation Components
     - each first part of the Brand List Components
  o  optionally, all LocatorHREF attributes in the Brand Selection Components if they were
     sent same
  signature are likely to be the Merchant same.

  Typically, within IOTP, it will contain all the characters in a TPO Selection Block
  o  from
  LocatorHref attribute up to the Offer Response Block:
     - sharp ("#") character (see immediately
  below).

  ALGORITHM AND PARAMETER ELEMENTS

  The algorithm element identifies the Order Component
     - each algorithms used in generating the
  signature. The type of the Payment Components
     - algorithm is defined by the Delivery Component
     - each value of the Authentication Data Components
     - any Trading Role Data Components

  The Offer Response Signature Component should also contain Digital
  Type attribute which indicates if it is the algorithm is to be used as
  a Digest algorithm, a Signature Elements for each algorithm or a Key Agreement
  algorithm.

  The following Digest algorithms must be implemented:

  o a [DOM-HASH] algorithm. This is identified by setting the Name
    attribute of the organisations that may or will need Algorithm element to verify the signature. This involves: "urn:ibm:dom-hash"

  o  if the Merchant has received a TPO Selection Block containing
     Brand Selection Components, then generate [SHA1] algorithm. This is identified by setting the Name
    attribute of the Algorithm element to "urn:fips:sha1", and

  o a Digital Signature
     Element for [MD5] algorithm. This is identified by setting the Payment Handler Name
    attribute of the Algorithm element to "urn:rsa:md5"

  The following Signature algorithms must be implemented:

  o a [DSA] algorithm. This is identified by setting the Brand
     Selection Component and Name
    attribute of the Delivery Handler Algorithm element to "urn:us.gov:dsa"
  o a [HMAC] algorithm. This is identified by setting the
     Delivery Component. See section 5.3.1 Check Name
    attribute of the Action Request
     was sent Algorithm element to "urn:ibm:hmac"

  It is recommended that the Correct Organisation for following Signature algorithm is also
  implemented:

  o a description [RSA] algorithm. This is identified by setting the Name
    attribute of how
     this can the Algorithm element to "urn:rsa:rsa"

  In addition other payment scheme specific algorithms may be done.
  o  if used. In
  this case the Merchant value of the name attribute to use is not expecting specified in the
  payment scheme supplement for that algorithm.

  One algorithm may make use of other algorithms by use of the Parameter
  element, for example:

<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
  <Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
    <Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>

  DIGEST ELEMENT

  The LocatorHREF attribute identifies the IOTP element which is being
  digitally signed. Specifically it consists of:

  o the value of the OtpTransId attribute of the Transaction ID
    Component, followed by:

  o a sharp character, i.e. "#", followed by

  o an Element Reference (see section 3.5) to receive the element within
    the IOTP Transaction which is the subject of the digest.

  Before analysing the structure of the LocatorHREF attribute, it must
  be concatenated with the value of the LocatorHrefBase attribute of the
  Manifest element (see immediately above).

  ATTRIBUTE ELEMENT

  There must be one and only one Attribute Element that contains a TPO Selection
     Block then generate Type
  attribute with a Digital Signature Element value of IOTPSignatureType and with content set to
  either: OfferResponse, PaymentResponse, DeliveryResponse,
  AuthenticationRequest, AuthenticationResponse, PingRequest or
  PingResponse; depending on the type of the signature.

  Values of the content of the Attribute element are controlled under
  the procedures defined in section 3.7.3 Values for IOTP Codes which
  also allows user defined values to be defined.

  The Critical attribute must be set to true.

  ORIGINATORINFO ELEMENT

  The OriginatorRef attribute of the
     Delivery Handler OriginatorInfo element must always
  be present and all contain an Element Reference (see section 3.5) to the Payment Handlers
  Organisation Component of the Organisation that are
     involved.

6.18.2 Payment Receipt generated the
  Signature Component Component.

  RECIPIENTINFO ELEMENT

  The Signed Data Element RecipientRefs attribute contains a list of Element References (see
  section 3.5), that point to the Payment Receipt Organisations that might need to
  validate the signature. For details see below.

  6.17.2 Offer Response Signature Component

  The Manifest Element of a signature which has a type of OfferResponse
  should contain hashes of Digest elements for the following Components:

  o the Transaction Id Component (see section 3.3.1) of the IOTP
    message that contains the Payment Receipt Offer Response 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 from the Payment Receipt Component
  o TPO Block:
    - the Status Protocol Options 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
    - each of the Ping Response or Ping
  Request Signature Organisation Components should contain hashes
    - each of the following
  Components: Brand List Components

  o optionally, 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 Brand Selection Components if they were
    sent to the
  Trading Roles involved Merchant in a TPO Selection Block
  o from the trade.

  For clarity two phrases are defined which are used in Offer Response Block:
    - the description
  of an Error Component:
  o  message in error. An IOTP message which contains or causes an
     error Order Component
    - each of some kind
  o  message reporting the error. An IOTP message that contains an
     Error Payment Components
    - the Delivery Component that describes
    - each of the error found in a message in
     error. Authentication Data Components
    - any Trading Role Data Components

  The definition Offer Response Signature should also contain Digest elements for
  the components that describe each 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 organisations that may or
  will need to verify the Error
                   Component within signature. This involves:

  o if the IOTP Transaction.

xml:lang           Defines Merchant has received a TPO Selection Block containing
    Brand Selection Components, then generate a Digest element for
    the language used Payment Handler identified by attributes or child
                   elements within this component, unless overridden the Brand Selection Component
    and the Delivery Handler identified by an xml:lang attribute on a child element. the Delivery Component.
    See section 3.9 Identifying Languages.

ErrorCode          Contains an error code which indicates the nature
                   of 5.3.1 Check the error in Action Request was sent to the message in error. Valid values
    Correct Organisation for the ErrorCode are given in section 6.19.2
                   Error Codes.

ErrorDesc          Contains a narrative description of how this can be done.

  o if the error in Merchant is not expecting to receive a TPO Selection
    Block then generate a Digest element for the language defined by xml:lang. Delivery Handler
    and all the Payment Handlers that are involved.

  6.17.3 Payment Receipt Signature Component

  The content Manifest Element of
                   this attribute is defined by the vendor/developer
                   of Payment Receipt Signature Component should
  contain Digest Elements for the software which generated following Components:

  o the Error Transaction Id Component

Severity           Indicates the severity (see section 3.3.1) of the error.  Valid values
                   are:
                   o  Warning. This indicates that although there is
                      a IOTP
    message in error that contains the IOTP Transaction can
                      still continue. Payment Receipt Signature

  o  TransientError. This indicates the Transaction Reference Block (see section 3.3) of the IOTP
    Message that contains the error
                      in Payment Receipt Signature

  o the message in error may be recovered if Offer Response Signature Component

  o the
                      message in error  that is referred to by Payment Receipt Component

  o the
                      ErrorLocation element is resent Status Component

  o  HardError. This indicates that there is an
                      unrecoverable error in the message in error and Brand Selection Component.

  o any Trading Role Data Components
  6.17.4 Delivery Response Signature Component

  The Manifest Element of the IOTP Transaction must stop.

MinRetrySecs       This attribute Delivery Response Signature Component
  should be present if Severity is
                   set to TransientError. It is contain Digest Elements for the minimum number following Components:

  o the Transaction Id Component (see section 3.3.1) 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 that contains the ErrorLocation element.

                   If Severity is not set to TransientError then Delivery  Response Signature

  o the
                   value Transaction Reference Block (see section 3.3) of this attribute is ignored.

SwVendorErrorRef   This attribute is a reference whose value is set
                   by the vendor/developer of IOTP
    Message that contains the software which
                   generated Delivery  Response Signature

  o the Error Component. It should contain
                   data which enables Signature Components contained in the vendor to identify preceding Delivery
    Request (if any)

  o the
                   precise location in their software and Status Component

  o the set Delivery Note Component

  6.17.5 Authentication Request Signature Component

  The Manifest Element of
                   circumstances which caused the software to
                   generate a message reporting Authentication Request Signature Component
  should contain Digest Elements for the error. See also following Components:

  o the SoftwareId attribute of Transaction Reference Block (see section 3.3) for the IOTP
    Message Id element
                   in that contains information that describes the IOTP
    Message and IOTP Transaction

  o the Transaction Reference Block (section 3.3).

  Content:

ErrorLocation      This Id Component (see section 3.3.1) which globally
    uniquely identifies the IOTP Transaction Id of

  o the
                   message in error  and, where possible, following components of the element
                   and attribute in TPO Block :
    - the message in error that caused Protocol Options Component
    - the Error Organisation Component to be generated.

                   If

  o the Severity following components of the error is not
                   TransientError, more than one ErrorLocation may be
                   specified as appropriate depending on Authentication Request Block:
    - the nature Authentication Data Component

  6.17.6 Authentication Response Signature Component

  The Manifest Element of the error (see section 6.19.2 Error Codes) and
                   at Authentication Response Signature
  Component should contain Digest Elements for the discretion of following Components:

  o the vendor/developer of Transaction Reference Block (see section 3.3) for the IOTP Aware Application.

PackagedContent    This
    Message that contains additional data which can be used to
                   understand the error. Its content may vary as
                   appropriate depending on information that describes the nature of IOTP
    Message and IOTP Transaction

  o the error Transaction Id Component (see section 6.19.2 Error Codes) and at 3.3.1) which globally
    uniquely identifies the
                   discretion of IOTP Transaction

  o the vendor/developer following components 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 Authentication Request Block:
    - the
  error, carry out Authentication Data Component

  o the actions appropriate for Organisation Components contained in the Error Authentication
    Response Block

  6.17.7 Ping Request Signature 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 the Ping Request is generating a message reporting being singed (see section 8.2.2), the
  error with an Error Manifest
  Element of the Ping Request Signature Component where should contain Digest
  elements for all the Severity attribute Organisation Components.

  6.17.8 Ping Response Signature Component

  If the Ping Response is set to
  Warning, then if being singed (see section 8.2.2), the message reporting Manifest
  Element of the error does not contain
  another Error Ping Response Signature Component with a severity higher than Warning, should contain Digest
  elements fir all the IOTP
  Message must also include Organisation Components.

  6.18 Certificate Component

  [Note]   Definitions of the Trading Blocks XML structures for signatures and Trading Components
  that would have been included if no error was being reported.

  If a message reporting
           certificates are described in the error is received with an Error Component
  where Severity paper "Digital Signatures
           for XML - Proposal", see [XMLDSIG]. As this is set to Warning, then:
  o an Internet
           Draft, it is recommended that information about the error is either
     logged, or otherwise reported will be subject to the user,
  o  the implementer of the IOTP aware application must either, revision.

           See note at
     their or the user's discretion:
     - continue the IOTP transaction start of section 6.17 Signature Component
           for more details.
  [Note End]

  A Certificate Component contains a Digital Certificate. Its structure
  is as normal, or
     - fail the follows:

<!ELEMENT Certificate (
  IssuerAndSerialNumber
  ( Value | Locator ) )>
<!ATTLIST Certificate
 ID                 ID      #IMPLIED
 type               NMTOKEN #REQUIRED >

<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
 issuer             CDATA   #REQUIRED
 number             CDATA   #REQUIRED >

<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
 id                 ID      #IMPLIED
 encoding ( base64 | none ) #REQUIRED >

<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
 href               CDATA   #REQUIRED >

  6.18.1 IOTP transaction by generating a message reporting usage of signature elements and attributes

  Detailed definitions of the
       error with an above elements and attributes are
  contained in [XMLDSIG]. The following contains additional information
  that describes how these elements and attributes are used by IOTP.

  CERTIFICATE COMPONENT

  The ID attribute is mandatory.

  VALUE ELEMENT

  The ID attribute is mandatory.

  6.19 Error Component with Severity set to HardError

  The Error Component contains information about Technical Errors (see
  section 6.19.1.3).

  If the intention is to continue the 4.1) in an IOTP transaction then, if there
  are no other Error Components with a higher severity, check that Message which has been received by one of the
  necessary
  Trading Blocks and Trading Components for normal processing
  of Roles involved in the transaction to continue trade.

  For clarity two phrases are present. If they defined which are not then
  generate a message reporting used in the error with description
  of an Error Component with
  Severity set to HardError.

6.19.1.2 Severity - Transient Error

  If an Component:

  o message in error. An IOTP Aware Application is generating a message which contains or causes an
    error of some kind

  o message reporting the
  error with error. An IOTP message that contains an
    Error Component where that describes the Severity attribute is set to
  TransientError, then there should be only one Error Component error found in the
  message reporting the error. In addition, the MinRetrySecs attribute
  should be present.

  If a message reporting in
    error.

  The definition of 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 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 is missing or is invalid, then:
     - generate a message reporting       CDATA   #IMPLIED
 SwVendorErrorRef   CDATA   #IMPLIED >

  Attributes:

ID                  An identifier which uniquely identifies the error containing an
                    Error Component with a Severity of Warning and send it on within the next IOTP message (if any) to be sent to Transaction.

xml:lang            Defines the Trading Role 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 sent indicates the message reporting
                    nature of the error with in the invalid MinRetrySecs,
       and
     - use a value message in error.
                    Valid values for MinRetrySecs which is set by the
       vendor/developer ErrorCode are given in
                    section 6.19.2 Error Codes.

ErrorDesc           Contains a narrative description of the IOTP Aware Application.
  o  check that only one ErrorLocation element is contained within error in
                    the Error Component and that it refers to an IOTP Message
     which was sent language defined by xml:lang. The content of
                    this attribute is defined by the recipient
                    vendor/developer of the software which generated
                    the Error Component with a

Severity            Indicates the severity of TransientError. If more than one ErrorLocation the error.  Valid
                    values are:
                    o Warning. This indicates that although there is
     present then generate
                      a message reporting the in error with a
     Severity of HardError.

6.19.1.3 Severity - Hard Error

  If an the IOTP Aware Application is generating a message reporting Transaction can
                      still continue.
                    o TransientError. This indicates that 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 in error may be recovered if
                      the error.

  If a message reporting the in error  that is referred to by
                      the ErrorLocation element is resent
                    o HardError. This indicates that there is received with an Error Component
  where
                      unrecoverable error in the message in error
                      and the IOTP Transaction must stop.

MinRetrySecs        This attribute should be present if Severity is
                    set to HardError then terminate the IOTP
  Transaction.

6.19.2 Error Codes

  The following table contains the valid values for TransientError. It is the ErrorCode
  attribute minimum number
                    of whole seconds which the Error Component. The first sentence of IOTP aware
                    application which received the
  description contains message reporting
                    the text that error should be used to describe wait before re-sending the
                    message in error when displayed or otherwise reported. Individual implementations
  may translate this into alternative languages at their discretion.

  An Error Code must identified by the ErrorLocation
                    element.

                    If Severity is not be more that 14 characters long.

       Value                           Description

Reserved           Reserved. set to TransientError then
                    the value of this attribute is ignored.

SwVendorErrorRef    This error attribute is reserved a reference whose value is set
                    by the vendor/developer of the software. Contact software which
                    generated the
                   vendor/developer 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 for more
                   information to
                    generate a message reporting the error. See also
                    the SoftwareId attribute of the Message Id
                    element in the Transaction Reference
                   Block(section Block
                    (section 3.3).

XmlNotWellFrmd     XML not well formed. The XML document is not well
                   formed. See [XML] for

  Content:

ErrorLocation       This identifies the meaning IOTP Transaction Id of "well
                   formed". Even if the XML is not well formed, it
                   should still be scanned to find
                    message in error  and, where possible, the Transaction
                   Reference Block so
                    element and attribute in the message in error
                    that a properly formed caused the Error
                   Response may Component to be generated.

       Value                           Description

XmlNotValid        XML not valid. The XML document is well formed but
                   the document is not valid. See [XML] for

                    If the
                   meaning Severity of "valid". Specifically:
                   o the XML document does error is not comply with
                    TransientError, more than one ErrorLocation may
                    be specified as appropriate depending on the
                      constraints defined in
                    nature of the IOTP document type
                      declaration error (see section 12 Open Trading
                      Protocol Data Type Definition), 6.19.2 Error
                    Codes) and
                   o  the XML document does not comply with at the
                      constraints defined in discretion of  the document type
                      declaration
                    vendor/developer of any the IOTP Aware Application.

PackagedContent     This contains additional [XML Namespace]
                      that are declared.

                   As for XML not well formed, attempts should still data which can be made used
                    to extract understand the Transaction Reference Block
                   so that a properly formed Error Response error. Its content may be
                   generated.

ElUnexpected       Unexpected element. Although vary as
                    appropriate depending on the XML document is
                   well formed nature of the error
                    (see section 6.19.2 Error Codes) and valid, an element is present that 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 not expected more than one Error Component in a message reporting the particular context
                   according to
  error, carry out the rules and constraints contained
                   in this specification.

ElNotSupp          Element not supported. Although actions appropriate for the document is
                   well formed and valid, an element is present that:
                   o  is consistent Error Component with
  the rules and constraints
                      contained in highest severity. In this specification, but
                   o 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 not supported by generating a message reporting the IOTP Aware Application
                      which
  error with an Error Component where the Severity attribute is processing 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.

ElMissing          Element missing. Although
  Message must also include the document is well
                   formed Trading Blocks and valid, an element is missing Trading Components
  that
                   should would have been present included if no error was being reported.

  If a message reporting the rules and
                   constraints contained in this specification are
                   followed.

                   In this case set the PackagedContent of the error is received with an Error Component
  where Severity is set to the type of the missing element.

ElContIllegal      Element content illegal. Although the document Warning, then:

  o it is
                   well formed and valid, recommended that information about the element PackagedContent
                   contains values which do not conform error is either
    logged, or otherwise reported to the rules
                   and constraints contained in this specification.

EncapProtErr       Encapsulated protocol error. Although the document
                   is well formed and valid, user,

  o the PackagedContent implementer 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, IOTP aware application must either, at
    their or the presence of user's discretion:
    - continue the
                   attribute is not expected in IOTP transaction as normal, or
    - fail the particular
                   context according to IOTP transaction by generating a message reporting the rules and constraints
                   contained in this specification.

AttNotSupp         Attribute not supported. Although
      error with an Error Component with Severity set to HardError (see
      section 6.19.1.3).

  If the XML document intention is well formed and valid, and the presence of to continue the
                   attribute in an element is consistent IOTP transaction then, if there
  are no other Error Components with a higher severity, check that the
                   rules
  necessary Trading Blocks and constraints contained in this
                   specification, it is Trading Components for normal processing
  of the transaction to continue are present. If they are not supported by 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 which is processing the IOTP
                   Message.

AttMissing         Attribute missing. Although generating a message reporting the document is well
                   formed and valid,
  error with an Error Component where the Severity attribute is missing that set to
  TransientError, then there should have been present if the rules and
                   constraints contained be only one Error Component in this specification are
                   followed. the
  message reporting the error. In this case set addition, the PackagedContent of 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 type of the missing attribute.

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

AttValNotRecog     Attribute Value Not Recognised. The attribute
                   contains a value which the IOTP Aware Application
                   generating valid number,
    then use the MinRetrySecs value given. Otherwise if
    MinRetrySecs is missing or is invalid, then:
    - generate a message reporting the error could
                   not recognise even though containing an Error
      Component with a Severity of Warning and send it should have been able
                   to since on the information had been provided in an
                   earlier next IOTP message.

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

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

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

ValueTooLarge      Value too large or in
      message reporting the future. The error with the invalid MinRetrySecs, and
    - use a value of all
                   or part of for MinRetrySecs which is set by the  PackagedContent vendor/developer
      of an the IOTP Aware Application.

  o check that only one ErrorLocation element or
                   an attribute, although valid, is too large.

ElInconsistent     Element Inconsistent. Although contained within
    the document is
                   well formed Error Component and valid, according that it refers to the rules and
                   constraints contained in this specification:
                   o  the content of an element is inconsistent with
       Value                           Description IOTP Message which
    was sent by the content recipient of other elements or their
                      attributes, or
                   o the value of an attribute is inconsistent Error Component with
                      the value a
    Severity of one or TransientError. If more other attributes.

                   In this case create than one 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
    present then generate a problem with the
                   Transport Mechanism which is preventing the message from being received. It is typically
                   associated reporting the error with a Transient Error. Explanation
    Severity of
                   the Transport HardError.

  6.19.1.3 Severity - Hard Error

  If an IOTP Aware Application is contained within the
                   ErrorDesc attribute. The values which can be used
                   inside ErrorDesc with generating a TransportError is
                   specified in the IOTP supplement for message reporting the Transport
                   mechanism.

6.19.3 Error Location Element

  An Error Location Element identifies an element and optionally
  error with an Error Component where the Severity attribute set to
  HardError, then there should be only one Error Component in the
  message in error which is associated with reporting the error.
  It contains

  If a reference message reporting the error is received with an Error Component
  where Severity is set to HardError then terminate 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
  Transaction.

  6.19.2 Error Codes

  The following table contains the "type" (see [XML]) valid values for the ErrorCode
  attribute of the Element in Error Component. The first sentence of the message in error where
  description contains the text that should be used to describe the
  error is located.

OtpMsgRef 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 value
                    vendor/developer of the ID attribute software. Contact the
       Value                           Description
                    vendor/developer of the software for more
                    information See the SoftwareId attribute of the
                    Message Id Component (see section 3.3.2) 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 message in error XML is not well formed, it
                    should still be scanned to which this find the Transaction
                    Reference Block so that a properly formed Error Component
                   applies.

BlkRef             If
                    Response may be generated.

XmlNotValid         XML not valid. The XML document is well formed
                    but the error document is associated not valid. See [XML] for the
                    meaning of "valid". Specifically:
                    o the XML document does not comply with a specific the
                      constraints defined in the IOTP document type
                      declaration (see section 11 Open Trading
                   Block, then this is
                      Protocol Data Type Definition), and
                    o the value of XML document does not comply with the ID attribute
                      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 Trading Transaction
                    Reference Block where so that a properly formed Error
                    Response may be generated.

ElUnexpected        Unexpected element. Although the error XML document is located.

CompRef            If the error
                    well formed and valid, an element is associated with a specific Trading
                   Component, then this present
                    that is not expected in the value of the ID
                   attribute of particular context
                    according to the Trading Component where rules and constraints contained
                    in this specification.

ElNotSupp           Element not supported. Although the error document is located.

ElementRef         If the error
                    well formed and valid, an element is associated present
                    that:
                    o is consistent with a specific element
                   within a Trading Component then, if the element
                   has an attribute with an "attribute type" (see
                   [XML]) of "ID", then rules and constraints
                      contained in this specification, but
                    o is not supported by the value of that
                   attribute.

AttName            If the error IOTP Aware Application
                      which is associated with processing the value of IOTP Message.

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

                    In this case set the PackagedContent of the
                    Error Component should contain to the value type of the
                   attribute.

  Note that as many as missing
                    element.

ElContIllegal       Element content illegal. Although the document
                    is well formed and valid, the attributes as possible should be included.
  For example if an attribute in a child element of a Trading Component
                    PackagedContent contains an incorrect value, then all values which do not
                    conform to the attributes of ErrorLocation
  should be present.

7. Trading Blocks

  Trading Blocks consist of one or more Trading Components rules and
  optionally one or more Signature Components. One or more Trading
  Blocks may be constraints contained within
                    in this specification.

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

AttUnexpected       Unexpected attribute. Although the form XML document
                    is well formed and valid, the presence of [XML] documents between the different
  organisations that are taking part in a trade.

  This
                    attribute is illustrated not expected in the diagram below.

          OTP MESSAGE  <-----------  OTP Message - an particular
                    context according to the rules and constraints
                    contained in this specification.

AttNotSupp          Attribute not supported. Although the XML Document
           |                         which
                    document is transported between well formed and valid, and the
           |                         Trading Roles
           |-Trans Ref Block <-----  Trans Ref Block - contains
           |  |                      information which describes
                    presence of the
           |  |                      OTP Transaction attribute in an element is
                    consistent with the rules and constraints
                    contained in this specification, it is not
                    supported by the OTP
           |  |                      Message.
           |  |-Trans Id Comp. <---  Transaction Id Component -
           |  |                      uniquely identifies IOTP Aware Application which is
                    processing the OTP
           |  |                      Transaction. The Trans Id
           |  |                      Components are IOTP Message.

AttMissing          Attribute missing. Although the same across
           |  |                      all OTP messages that comprise a
           |  |                      single OTP transaction.
           |  |-Msg Id Comp. <-----  Message Id Component - identifies
           | document is well
                    formed and describes an OTP Message
           |                         within valid, 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 attribute is missing that
                    should have been present if the Trans Ref
           |  |                      Block rules and any Trading Component
           |  |                      in any OTP Message
                    constraints contained in this specification are
                    followed.

                    In this case set the same
           |  |                      OTP Transaction.
           |  |-Certificate Comp. <- Certificate Component. Used PackagedContent of the
                    Error Component to
           |                         check the signature.
   ------> |-Trading Block <-------- Trading Block - an XML Element
  |        |  |-Component            within an OTP Message that
Trading    |  |-Component            contains a predefined set type of
Blocks     |  |-Component            Trading Components
  |        |  |-Component
  |        |  |-Component <--------- Trading Components - XML Elements
  |        |                         within a Trading Block that
   ------> |-Trading Block           contain the missing
                    attribute.

AttValIllegal       Attribute value illegal. The attribute contains
                    a predefined set of XML
           |  |-Component            elements and attributes
           |  |-Component            containing information required
           |  |-Component value which does not conform 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). rules and
       Value                           Description
                    constraints contained in this specification.

AttValNotRecog      Attribute Value Not Recognised. The definition of an attribute
                    contains a value which the 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 Aware
                    Application generating 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 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
  Transaction. message.

MsgTooLarge         Message too large. The definition of a TPO Trading Block message 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 too large to
                    be processed by the IOTP
                   Transaction (see section 3.4 ID Attributes).

  Content:

ProtocolOptions Aware Application.

ElTooLarge          Element too large. The Protocol Options Component (see section
                   6.1)defines the options which apply element is too large to
                    be processed by the whole IOTP Transaction (see section 8).

BrandList          This Brand List Component contains one Aware Application

ValueTooSmall       Value too small or more
                   payment brands and protocols which may be selected
                   (see section 6.6).

Org early. The Organisation Components (see section 6.5)
                   identify value of all or
                    part of the organisations and their roles  PackagedContent of an element or an
                    attribute, although valid, is too small.

ValueTooLarge       Value too large or in the
                   IOTP Transaction. future. The roles and organisations
                   which must be present will depend on the
                   particular type value of
                    all or part of IOTP Transaction. See the
                   definition  PackagedContent of each transaction in section 8. Open
                   Trading Protocol Transactions.

  The TPO Block should contain:
  o an
                    element or an attribute, although valid, is too
                    large.

ElInconsistent      Element Inconsistent. Although the Protocol Options Component document is
                    well formed and valid, according to the rules
                    and constraints contained in this specification:
                    o the Organisation Component content of an element is inconsistent with
                      the Trading Role content of Merchant other elements or their
                      attributes, or
                    o the Organisation Component value of an attribute is inconsistent with
                      the Trading Role value of Consumer
  o  optionally, one or more other attributes.

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

TransportError      Transport Error. This error code is used to
                    indicate that there is a problem with the Trading Role
                    Transport Mechanism which is preventing the
                    message from being received. It is typically
                    associated with a Transient Error. Explanation
                    of DeliverTo, if there the Transport Error is contained within the
                    ErrorDesc attribute. The values which can be
                    used inside ErrorDesc with a Delivery included TransportError is
       Value                           Description
                    specified in the IOTP
     Transaction
  o  Brand List Components supplement for each payment in the IOTP Transaction
  o  Organisation Components for all
                    Transport mechanism.

UnknownError        Unknown Error. Indicates that the Payment Handlers involved
  o  optionally, Organisation Components transaction
                    cannot complete for some reason that is not
                    covered explicitly by any of the Delivery Handler
     (if any) for other errors.
                    The ErrorDesc attribute should be used to
                    indicate the transaction
  o  additional Organisation Components that nature of the Merchant may want problem.

                    This could be used to include. For example
     - a Customer Care Provider
     - indicate, for example, an Certificate Authority that offers Merchant "Credentials" or
       some other warranty on the goods
                    internal error in a backend server or services being offered.

7.2 TPO Selection Block

  The TPO Selection Block contains the results client
                    process of selections made from some kind.

  6.19.3 Error Location Element

  An Error Location Element identifies an element and optionally an
  attribute in the options contained message in error which is associated with the Trading Protocol Options Block (see
  section 7.1).The definition of error.
  It contains a TPO Selection Block reference to the IOTP Message, Trading Block, Trading
  Component, element and attribute, which is as follows. in error.

<!ELEMENT TpoSelectionBlk (BrandSelection+) ErrorLocation EMPTY >
<!ATTLIST TpoSelectionBlk
  ID ID ErrorLocation
 ElementType        NMTOKEN #REQUIRED
 OtpMsgRef          NMTOKEN #REQUIRED
 BlkRef             NMTOKEN #IMPLIED
 CompRef            NMTOKEN #IMPLIED
 ElementRef         NMTOKEN #IMPLIED
 AttName            NMTOKEN #IMPLIED >

  Attributes:

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

  Content:

BrandSelection

ElementType         This identifies is the choice "type" (see [XML]) 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 Element in
                    the IOTP Transaction.

  The TPO Selection Block should contain one Brand Selection Component
  for each Brand List message in error where 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 error is to
  take place. Its definition located.

OtpMsgRef           This 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 value of the IOTP Transaction.

  Content:

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

AuthData           The Authentication Data error to which this Error
                    Component contains
                   information about how Authentication applies.

BlkRef              If the error is associated with the Offer will occur. See section 6.2.

Order              The Order Component contains details about the
                   goods, services or financial transaction which a specific
                    Trading Block, then this is
                   taking place see section 6.4.

                   The Order Component must be present unless the
                   ProcessState value of the ID
                    attribute of the Status Component Trading Block where the error
                    is
                   set to Failed.

Payment            The Payment Components contain information about located.

CompRef             If the payments which are to be made see section 6.8.

Delivery           The Delivery Component contains details error is associated with a specific
                    Trading Component, then this is the value of the
                    ID attribute of the
                   delivery to be made (see section 6.12).

TradingRoleData    The Trading Role Data Component contains opaque
                   data which where the
                    error is needs to be communicated between located.

ElementRef          If 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 error is
  used to obtain information about and optionally authenticate associated with a specific
                    element within 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 Component then, if the
                   Authentication Request Block within
                    element has an attribute with an "attribute
                    type" (see [XML]) of "ID", then this is the IOTP
                   Transaction.

  Content

AuthData
                    value of that attribute.

AttName             If the Authentication Data Component error is not
                   present it means that associated with the Authentication Request
                   Block value of an
                    attribute, then this is just requesting the return name of
                   Organisation Components which describe that
                    attribute. In this case the
                   Consumer.

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

7.5 Authentication Response Block

  The Authentication Response Block contains value of
                    the response which results
  from processing attribute.

  Note that as many as the Authentication Request Block. Its definition is attributes as
  follows.

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

  Attributes:

ID                 An identifier which uniquely identifies possible should be included.
  For example if an attribute in a child element of a Trading Component
  contains an incorrect value, then all the
                   Authentication Response Block 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
                   Transaction.

  Content:

AuthResp           The Authentication Response Component Messages which
                   contains are physically
  sent in the results form of processing [XML] documents between the challenge
                   data different
  organisations that are taking part in a trade.

  This is illustrated in the Authentication Data Component diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

          IOTP MESSAGE  <----------- IOTP Message - see
                   section 6.3.

Org                Organisation Components an XML Document
           |                         which contain information
                   corresponding to is transported between the Consumer and DelivTo
           |                         Trading
                   Roles.

7.6 Payment Request Roles
           |-Trans Ref Block

  The Payment Request <-----  Trans Ref 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 describes the
           |  |                      IOTP Transaction and the IOTP
           |  |                      Message.
           |  |-Trans Id Comp. <---  Transaction Id Component -
           |  |                      uniquely identifies the
                   Payment Request Block within the IOTP
           |  |                      Transaction.

  Content:

Status             Contains the Status The Trans Id
           |  |                      Components (see section 6.12)
                   of the responses of are the steps (e.g. an Offer
                   Response and/or same across
           |  |                      all IOTP messages that comprise 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
           |  |                      single IOTP transaction.
           |  |-Msg Id Comp. <-----  Message Id Component - identifies
           |                         and describes an IOTP Message
           |                         within an IOTP Transaction
           |-Signature Block <-----  Signature Block (optional) -
           |  |                      contains a list of one or more payment brands Signature
           |  |                      Components and protocols which their associated
           |  |                      Certificates
           |  |-Signature Comp. <--  Signature Component - contains
           |  |                      digital signatures. Signatures
           |  |                      may be
                   selected (see section 6.6).

BrandSelection     This identifies the choice sign digests of payment brand, the
                   payment protocol Trans Ref
           |  |                      Block and the payment handler to be
                   used any Trading Component
           |  |                      in any IOTP Message in a payment within the same
           |  |                      IOTP Transaction.
                   There is one Brand Selection Component (see
                   section 6.7) for each payment
           |  |-Certificate Comp. <- Certificate Component. Used to be made in
           |                         check the signature.
   ------> |-Trading Block <-------- Trading Block - an XML Element
  |        |  |-Component            within an IOTP Transaction.

Payment            The Payment 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 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 required
           |  |-Component            to support a Trading Exchange
           |  |-Component
           |  |-Component
           |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                         Figure 18 Trading Blocks
  Trading Blocks are defined as part of
                   organisations involved in the payment definition of an IOTP
  Message (see section
                   6.5). 3.1.1). The Organisations present are dependent on
                   the definition of an IOTP Transaction and the data which Message element
  is to be
                   signed. See section 5 Security Considerations for
                   more details.

TradingRoleData repeated here:

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

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

  The Payment this
  version of IOTP. They are:

  o Authentication Request Block should contain:

  o  the Organisation Component with a Trading Role of Merchant Authentication Response Block

  o  the Organisation Component with the Trading Role of Consumer Authentication Status Block

  o  the Payment Component for the Payment Cancel Block

  o  the Brand List Component for the Payment Delivery Request Block

  o  the Brand Selection Component for the Brand List Delivery Response Block

  o Error Block

  o Inquiry Request Block

  o Inquiry Response Block
  o Offer Response Block

  o  the Organisation Component for the Payment Handler of the Exchange Block

  o Payment Request Block

  o  the Organisation Component (if any) for the Organisation which
     carried out the previous step, for example another Payment
     Handler Response Block

  o  the Organisation Component for the organisation which Signature Block

  o Trading Protocol Options Block

  o TPO Selection Block

  The Transaction Reference Block is to
     carry out described in section 3.3.

  7.1 Trading Protocol Options Block

  The TPO Trading Block contains options which apply to the next step, if any. This may be, for example,
     either a Delivery Handler or IOTP
  Transaction. The definition of a Payment Handler.
  o 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 for any additional Organisations
     that (see section 6.5)
                    identify the Merchant has included organisations and their roles in
                    the Offer Response IOTP Transaction. The roles and
                    organisations which must be present will depend
                    on the particular type of IOTP Transaction. See
                    the definition of each transaction in section 8.
                    Internet Open Trading Protocol Transactions.

  The TPO Block should contain:

  o  an Optional Payment Scheme Data Component, 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 required by there is a Delivery included in the
     Payment Method as defined IOTP
    Transaction

  o Brand List Components for each payment in the IOTP supplement Transaction

  o Organisation Components for all the
     payment method Payment Handlers involved

  o  any Trading Role Data optionally, Organisation Components for the Delivery Handler
    (if any) for the transaction

  o additional Organisation Components that the Merchant may be required (see
     section 6.16.1).

7.7 Payment Exchange 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 Payment Exchange TPO Selection Block contains payment scheme specific data which
  is exchanged between two the results of selections made from
  the roles options contained in a trade. Its the Trading Protocol Options Block (see
  section 7.1).The definition of a TPO Selection Block is as follows.

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

  Attributes:

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

  Content:

PaySchemeData

BrandSelection      This Trading Component contains identifies the choice of payment scheme
                   specific data see brand and
                    payment protocol to be used in a payment within
                    the IOTP Transaction. There is one Brand
                    Selection Component (see section 6.9 Payment Scheme
                   Component.

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

  This Payment

  The Offer Response Block contains a information about details of the Payment
  Status, a Payment Receipt, and an optional payment protocol message. goods, services,
  amount, delivery instructions or financial transaction which is to
  take place. Its definition is as follows.

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

  Attributes:

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

  Content:

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

PayReceipt         Contains payment scheme specific data which can be
                   used to verify

Order               The Order Component contains details about 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
                    goods, services or financial transaction which
                    is taking place see section 6.4.

                    The Order Component must be present unless the Payment Handler wants to
                   provide to
                    ProcessState attribute of the Consumer. For example, if a
                   withdrawal or deposit were being made then it
                   could Status Component
                    is set to Failed.

Payment             The Payment Components contain information on the remaining balance
                   on about
                    the account after payments which are to be made see section
                    6.8.

Delivery            The Delivery Component contains details of the transfer was complete.
                   See
                    delivery to be made (see section 6.11 Payment Note Component. 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).

7.9 6.15).

  The Offer Response Block should contain:

  o the Order Component for the IOTP Transaction

  o Payment Components for each Payment in the IOTP Transaction

  o the Delivery Component the IOTP Transaction requires (if any).

  7.4 Authentication Request Block

  The Delivery

  This Authentication Request Block contains details of the goods or services challenge data which are is
  used to be delivered together with obtain information about and optionally authenticate a signature
  Consumer by another Trading Role. Its definition is as follows.

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

  Attributes

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

  Content

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

                    If the optional Authentication Data Component
                    (see section 6.2) is present it contains data
                    which describes the different types of
                    Authentication the consumer should provide.

  7.5 Authentication Response Block

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

<!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 check the Trading Roles
                    as requested by the TradingRoleList attribute of
                    the AuthData component.

  7.6 Authentication Status Block

  The Authentication Status Block indicates the success or failure of
  the validation of an Authentication Response Block by an
  Authenticator. Its definition is as follows.

<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
 ID                 ID      #REQUIRED >

  Attributes:

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

  Content:

Status              Contains status information about the business
                    success (see section 4.2) or failure of the
                    authentication

  7.7 Payment Request Block

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

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

  Attributes:

ID                  An identifier which uniquely identifies the
                   Delivery
                    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 is dependent. depends. It is used to indicate
                    the success or failure of those steps. Delivery Payment
                    should only occur of the previous steps were
                    successful.

Order

BrandList           The Order Brand List Component contains details about the
                   goods, services a list of one
                    or financial transaction more payment brands and protocols which is
                   taking place see section 6.4.

Org                The Organisation Components may
                    be selected (see section 6.5)
                   identify 6.6).

BrandSelection      This identifies the organisations choice of payment brand, the
                    payment protocol and their roles the payment handler to be
                    used in a payment within the IOTP Transaction. The roles and organisations
                   which must
                    There is one Brand Selection Component (see
                    section 6.7) for each payment to be present will depend on made in the
                   particular type of
                    IOTP Transaction. See

Payment             The Payment Components contain information about
                    the
                   definition of each transaction in payment which is being made see section 8. Open
                   Trading Protocol Transactions.

Delivery 6.8.

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

Org                 The Organisation Component contains details of
                    organisations involved in the
                   delivery payment (see
                    section 6.5). The Organisations present are
                    dependent on the IOTP Transaction and the data
                    which is to be made (see signed. See section 6.12). 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). 6.15).

  The Delivery Payment Request Block contains: should contain:

  o the Organisation Component with a Trading Role of Merchant

  o the Organisation Component for with the Consumer and DeliverTo Trading Roles Role of Consumer

  o the Delivery Payment Component for the Delivery Payment

  o the Organisation Brand List Component for the Delivery Handler.
     Specifically Payment

  o the Organisation Brand Selection Component identified by for the
     ActionOrgRef attribute on Brand List

  o the Delivery 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 a 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.10 Delivery Response 6.15.1).

  7.8 Payment Exchange Block

  The Delivery Response Payment Exchange Block contains a Delivery Note containing
  details on how payment scheme specific data which
  is exchanged between two of the goods will be delivered. roles in a trade. 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) PayExchBlk (PaySchemeData) >
<!ATTLIST DeliveryRespBlk PayExchBlk
 ID                 ID      #REQUIRED >

  Attributes:

ID                  An identifier which uniquely identifies the
                   Delivery Response
                    Payment Exchange 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

PaySchemeData       This Trading Component contains details about
                   how the goods or services will be delivered (see payment scheme
                    specific data see section 6.13).

7.11 6.9 Payment Instrument Customer Care Request Scheme
                    Component.

  7.9 Payment Response Block

  The

  This Payment Instrument Customer Care Request Response Block contains a information which requests that an IOTP Payment Instrument Customer
  Care Transaction is started in order to provide Customer Care for about the
  Consumer's Payment Instrument.
  Status, a Payment Receipt, and an optional payment protocol message.
  Its definition is as follows.

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

  Attributes:

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

  Content:

PayMethodInfo      The Payment Method Information Component

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

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

PaySchemeData      Optional Payment Scheme Components (see section
                   6.9) that contain       Contains payment scheme specific data.
                   The sequence of the data see
                    section, for example a payment protocol message.
                    See 6.9 Payment Scheme Components in
                   the Block is the sequence in which they should be
                   processed by Component.

PaymentNote         Contains additional, non payment related,
                    information which the Payment Scheme software which
                   receives this message.

7.12 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 Instrument Customer Care Exchange Block Note
                    Component.

TradingRoleData     The Payment Instrument Customer Care Exchange Block Trading Role Data Component contains payment
  scheme specific opaque
                    data which is exchanged needs to be communicated between
                    the Payment Instrument
  User and Trading Roles involved in an OTP Transaction
                    (see section 6.15).

  7.10 Delivery Request Block

  The Delivery Request Block contains details of the Payment Scheme Customer Care Provider. 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 PayInstCCExchBlk (PaySchemeData) DeliveryReqBlk (Status+, Order, Org*, Delivery,
     TradingRoleData*) >
<!ATTLIST PayInstCCExchBlk DeliveryReqBlk
 ID                 ID      #REQUIRED >

  Attributes:

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

  Content:

PaySchemeData      Optional Payment Scheme

Status              Contains the Status Components (see section
                   6.9) that contain payment scheme specific data.
                   The sequence
                    6.12) of the responses of the steps (e.g. a
                    Payment Scheme 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 Block is IOTP Transaction. The roles and
                    organisations which must be present will depend
                    on the sequence particular type of IOTP Transaction. See
                    the definition of each transaction in section 8.
                    Internet Open Trading Protocol Transactions.

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

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

  The Delivery Request Block contains:

  o the Organisation Component with a Trading Role of Merchant

  o the Organisation Component for the Consumer and DeliverTo
    Trading Roles

  o the Delivery Component for the Delivery

  o the Organisation Component for the Delivery Handler.
    Specifically the Organisation Component identified by the Payment Scheme software
    ActionOrgRef attribute on the Delivery Component
  o the Organisation Component (if any) for the Organisation which
                   receives this message.

7.13
    carried out the previous step, for example a Payment Instrument Customer Care Handler

  o the Organisation Components for any additional Organisations
    that the Merchant has included in the Offer Response Block

  o any Trading Role Data Components that may be required (see
    section 6.15.1).

  7.11 Delivery Response Block

  The Payment Instrument Customer Care Delivery Response Block contains a Delivery Note containing
  details on how the final
  Payment Scheme Component of the IOTP Payment Instrument Customer Care
  Transaction. 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 PayInstCCRespBlk (PaySchemeData) DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST PayInstCCRespBlk DeliveryRespBlk
 ID                 ID      #REQUIRED >

  Attributes:

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

  Content:

PaySchemeData      Optional Payment Scheme Components

Status              Contains status information about the business
                    success (see section
                   6.9) that contain payment scheme specific data.
                   The sequence 4.2) or failure of the Payment Scheme Components
                    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 Block is the sequence in which they should goods or services will be
                   processed by the Payment Scheme software which
                   receives this message.

7.14
                    delivered (see section 6.13).

  7.12 Inquiry Request Trading Block

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

<!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) 6.16) that
                    contains the type of inquiry.

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

7.15

  7.13 Inquiry Response Trading Block

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

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

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

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

  Content:

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

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

7.16

  7.14 Ping Request Block

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

  The definition of a Ping Request Block is as follows.

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

  7.15 Ping Response Block

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

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

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

<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
 ID                 ID      #REQUIRED
 PingStatusCode (Ok|Busy|Down) (Ok | Busy | Down) #REQUIRED
 SigVerifyStatusCode (Ok|NotSupported|Fail) (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

  7.16 Signature Block

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

  The definition of a Signature Block is as follows:

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

  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           A Signature for XML - Proposal" [XMLSIG],
                   for its definition Component. See section 6.17.

Certificate         A Certificate Component. See section 6.18.

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

7.18.1

  7.16.1 Offer Response

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

7.18.2
  6.17.2).

  7.16.2 Payment Request

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

  o an Offer Response Signature Component (see section 6.18.1), 6.17.2), and

  o if the Payment is dependent on an earlier step (as indicated by
    the StartAfter attribute on the Payment Component), then the
    Payment Receipt Signature Component (see section 6.18.2) 6.17.3)
    generated by the previous step

7.18.3

  7.16.3 Payment Response

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

7.18.4

  7.16.4 Delivery Request

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

  o an Offer Response Signature Component (see section 6.18.1), 6.17.2), and

  o the Payment Receipt Signature Component (see section 6.18.2) 6.17.3)
    generated by the previous step.

7.19

  7.17 Error Block

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

  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 Components (see section 6.19) that
                    contains information about an individual
                    Technical Error.

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

  7.18 Cancel Block

  The Cancel Block is used to inform a non-Consumer role such as a
  Merchant, Payment Handler or Delivery Handler that a transaction has
  been cancelled by the Consumer. It's main purpose is to allow the
  server to close down the transaction without a waiting for a time-out
  to occur. Its definition is as follows.

<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
 ID                 ID      #REQUIRED >

  Attributes:

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

  Content:

Status              Contains status information indicating that the
                    IOTP transaction has been cancelled.

  8. Internet Open Trading Protocol Transactions

  The Baseline Open Trading Protocol supports the following four types of
  Baseline IOTP Transactions: transactions
  for different purposes. These are

  o an Authentication IOTP transaction which supports
    authentication of one party in a trade by another

  o IOTP Transactions that involve one or more payments.
    Specifically:
    - Deposit
  o
    - Purchase
  o
    - Refund
  o  Withdrawal
  o  Baseline
    - Withdrawal, and
    - Value Exchange

  o  Payment Instrument Customer Care
  o IOTP Transactions designed to check the correct function of the
    IOTP infrastructure. Specifically:
    - Transaction Status Inquiry, and
  o
    - Ping

  Each of these transactions are described in more detail in the
  following sections providing descriptions of:
  o

  Although the Trading Blocks in each Authentication 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 can operate on its own,
  authentication can optionally precede any of the Trading
           Blocks between the different _payment_
  transactions.

           This means that there should be significant opportunity for
           software re-use. For example, from an IOTP perspective, Therefore, the
           Deposit, Refund rest of this section is divided into two
  parts covering:

  o Authentication and Withdrawal Payment transactions (Authentication,
    Deposit, Purchase, Refund, Withdrawal and Value Exchange)

  o Infrastructure Transactions (Transaction Status Inquiry and
    Ping) that are essentially
           the same, although the processing which will occur,
           especially at the server end, will differ.
  [Note End] designed to support inquiries on whether or not
    a transaction has succeeded or a Trading Role's servers are
    operating correctly, and

  8.1 Baseline Authentication and Payment Related IOTP Transaction

  In a Baseline Transactions

  The Authentication and Payment related IOTP Transaction:
  o  the Authenticator is the organisation Transactions consist of
  six Document Exchanges which are then combined in sequence to
  implement a specific transaction.

  Generally, there is requesting the
     authentication, a close, but not exact, correspondence between a
  Document Exchange and
  o  the Authenticatee a Trading Exchange. The main difference is the organisation being authenticated.

  A Baseline Authentication IOTP Transaction may occur at any time
  between any that
  some Document Exchanges implement part or all of the two Trading Roles involved Exchanges
  simultaneously in order to minimise the number of actual OTP Transactions. This
  means it could occur: Messages
  which must be sent over the Internet.

  The six Document Exchanges are:

  o  before another Authentication. This is a direct implementation of the
    Authentication Trading Exchange

  o Brand Dependent Offer. This is the Offer Trading Exchange
    combined with the Brand Selection part of the Payment Trading
    Exchange. Its purpose is to provide the Merchant with
    information on the Brand selected so that the content of the
    Offer Response may be adapted accordingly

  o Brand Independent Offer. This is also an Offer Trading
    Exchange. However, in this instance, the content of the Offer
    Response does depend on the Brand selected.

  o Payment. This is a direct implementation of the Payment part of
    a Payment Trading Exchange

  o Delivery. This is a direct implementation of the Delivery
    Exchange

  o Delivery with Payment. This is an implementation of combined
    Payment and Delivery Trading Exchanges

  These Document Exchanges are combined together in different sequences
  to implement each IOTP Transaction Transaction. The way in which they may be
  combined is illustrated by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

  START -----------------------------------------------------
   |                                                         v
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |    |
                    |                     |              |    |
                    |      -------------- | -------------     |
                    v      v              v      v            |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                     |    |                   |   |           |
                     |     ---------------    |   |           |
                     |                    |   |   |           |
                     |     -------------- | --    |           |
                     v    v               v       v           |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                       |                      |               |
           -----------------------------      |               |
           v                v           |     |               |
      ----------        ---------       |     |               |
     | DELIVERY |      | PAYMENT |      |     |               |
     |          |      | {second)|      |     |               |
      ----------        ---------       |     |               |
           |                |           |     |               v
            ----------------------------------------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

      Figure 19 Payment and Authentication Message Flow Combinations

  The combinations of Document Exchanges that are valid depend on the
  particular IOTP transaction.

  The remainder of this sub-section describes:

  o  at each Document Exchange in more detail including descriptions of
    the same time as another content of each Trading Block in the Document Exchanges,
    and
  o descriptions of how each IOTP Transaction
  o  independently uses the Document
    Exchange to effect the desired result.

  [Note]   The descriptions of the Document Exchanges which follow
           describe the ways in which various Business Errors (see
           section 4.2) are handled. No reference is made however to
           the handling of Technical Errors (see section 4.1) in any other IOTP Transaction. of
           the messages since these are handled the same way
           irrespective of the context in which the message is being
           sent. See section 4 for more details.
  [Note End]

  8.1.1 Authentication Document Exchange

  The Authentication Document Exchange is a direct implementation of the
  Authentication Trading Exchange (see section 2.2.4). It involves:

  o an Authenticator - the organisation which is requesting the
    authentication, and

  o an Authenticatee - the organisation being authenticated.

  The authentication consists of:

  o an Authentication Request being sent by the Authenticator to
    the Authenticatee, and

  o an Authentication Response being sent in return by the
    Authenticatee to the Authenticator which is then checked.

  A Baseline checked, and

  o an Authentication IOTP Transaction Status being sent by the Authenticator to the
    Authenticatee to provide an indication of the success or
    failure of the authentication.

  An Authentication Document Exchange also:

  o provides an Authenticatee with an Organisation Component which
    describes the Authenticator, and

  o optionally provides the Authenticator with Organisation
    Components which describe the Authenticatee Authenticatee.

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

  The IOTP Messages 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 involved are illustrated in by the diagram
  below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

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

                                                        |
                                                        v
                                                      STOP

  Figure 19 Baseline Authentication
  5. The remainder of this sub-section on first organisation                            IotpMsg: Trans
  checks the Baseline Authentication IOTP
  Transaction defines the contents of each Trading Block.

8.1.1 Trading Protocol Options Block

  The TPO (Trading Protocol Options)    <--------------------     Ref Block;
 Status Block (see section 7.1) must
  contain the following Trading Component:
  o  one Protocol Options Component which defines the options which
     apply to and optionally   Authentication Status  Signature Block;
keeps information on the whole IOTP Transaction. See Section 6.1.

8.1.2 Authentication Request                           Auth Response
   Transaction for record                                   Block

  The
 keeping purposes and stops.                                  |
              v                                               v
            STOP                                            STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                Figure 20 Authentication Document Exchange

  8.1.1.1 Message Processing Guidelines

  On receiving a TPO & Authentication Request Block IOTP Message (see section 7.4) must contain the
  following Trading Component: below),
  an Authenticatee may either:

  o  one generate and send an Authentication Data Component (see section 6.2)
  o  one Organisation Component (see section 6.5) which describes Response IOTP Message back
    to the Authenticator

8.1.3 Signature Block (Authentication Request)

  If Authenticator, or

  o indicate failure to comply with the Authentication Request is being digitally signed then by
    sending a
  Signature Cancel Block must be included in back to the same IOTP message that
  contains an Authentication Request Block. The Signature Authenticator containing a
    Status Component
  contains hashes with a StatusType of Authentication a
    ProcessState of Failed and the following XML elements:
  o  the Transaction Reference Block CompletionCode (see section 3.3) for the
    6.14.4) set to either: AutEeCancel, NoAuthData, TradRolesIncon
    or Unspecified.

  On receiving an Authentication Response IOTP Message which contains the first usage of the (see below), an
  Authenticator should send in return, an Authentication
     Request Block within the Status IOTP Transaction. It contains
     information that identifies
  Message (see below) containing a Status Block with a Status Component
  where the StatusType is set to Authentication, and:

  o the ProcessState attribute of the Status Component is set to
    CompletedOk which indicates a successful completion, or

  o the ProcessState attribute is set to Failed and the
    CompletionCode attribute is set to either: AutOrCancel,
    AuthFailed or Unspecified which indicates a failed
    authentication,

  On receiving an Authentication Status IOTP Message (see below), the
  Authenticatee should check the Status Component in the Status Block.
  If this indicates:

  o a successful authentication, then the Authenticatee should
    either:
    - continue with the next step in the IOTP Transaction of which the
      Authentication Document Exchange is part (if any), or
    - indicate a failure to continue with the rest of the IOTP
      Transaction, by sending back to the Authenticator a Cancel block
      containing a Status Component with a StatusType of Authentication,
      a ProcessState of Failed and the CompletionCode (see section
      6.14.4) set to AutEeCancel.

  o a failed authentication, then the failure should be reported to
    the Authenticatee and any further processing stopped.

  If the Authenticator receives an IOTP Message containing a Cancel
  block, then the Authenticatee is likely to go to the CancelNetLocn
  specified on the Trading Role Element in the Organisation Component
  for the Authenticator contained in the Authentication Request Block.

  8.1.1.2 TPO & Authentication Request IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of:

  o a Trading Protocol Options Block (see section 7.1)

  o an Authentication Request Block (see section 7.4), and

  o an optional Signature Block (see section 7.16).

  Each of these are described below.

  TRADING PROTOCOL OPTIONS BLOCK

  The Trading Protocol Options Block (see section 7.1) must contain the
  following Trading Components:

  o one Protocol Options Component (see Section 6.1) which defines
    the options which apply to the whole Authentication Document
    Exchange.

  o one Organisation Component (see section 6.5) which describes
    the Authenticator. The Trading Role on the Organisation
    Component should indicate the role which the Authenticator is
    taking in the Trade, for example a Merchant or a Consumer.

  AUTHENTICATION REQUEST BLOCK

  The Authentication Request Block (see section 7.4) must contain the
  following Trading Components:

  o one Authentication Data Component (see section 6.2), and

  SIGNATURE BLOCK (AUTHENTICATION REQUEST)

  If the Authentication Request is being digitally signed then a
  Signature Block must be included. It contains Digests of the following
  XML elements:

  o the Transaction Reference Block (see section 3.3) for the IOTP
    Message that contains information that describes the IOTP
    Message and IOTP Transaction

  o the Transaction Id Component (see section 3.3.1) which globally
    uniquely identifies the IOTP Transaction

  o the following components of the TPO Block :
    - the Protocol Options Component
    - the Organisation Component

  o the following components of the Authentication Request Block:
    - the Authentication Data Component

8.1.4

  8.1.1.3 Authentication Response IOTP Message

  Apart from a Transaction Reference Block

  The (see section 3.3), this
  message consists of:

  o an Authentication Response Block (see section 7.5) 7.5), and

  o an optional Signature Block (see section 7.16).

  Each of these are described below.

  AUTHENTICATION RESPONSE BLOCK

  The Authentication Response Block must contain the following Trading
  Component:

  o one Authentication Response Component (see section 6.3)
  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)

  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 Digest Elements for 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 that contains information that identifies describes the IOTP
    Message and IOTP Transaction

  o the Transaction Id Component (see section 3.3.1) which globally
    uniquely identifies the IOTP Transaction

  o the following components of the Authentication Request Block:
    - the Authentication Data Component

  o the Organisation Components contained in the Authentication
    Response Block

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

8.2 Baseline Deposit

  8.1.1.4 Authentication Status IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of:

  o an Authentication Status Block (see section 7.5), and

  o an optional Signature Block (see section 7.16).

  Each of these are described below.

  AUTHENTICATION STATUS BLOCK

  The Baseline Deposit IOTP Transaction supports Authentication Status Block (see section 7.6) must contain the deposit of
  electronic cash
  following Trading Components:

  o one Status Component (see section 6.14) with a Financial Institution.

  [Note]   The Financial Institution has, in IOTP terminology, ProcessState
    attribute set to CompletedOk.

  SIGNATURE BLOCK (AUTHENTICATION STATUS)

  If the Authentication Status Block is being digitally signed then a role
           of merchant in
  Signature Block must be included that contains a service (i.e. a deposit of electronic
           cash) is being offered in return Signature Component
  with Digest elements for a fee, the following XML elements:

  o the Transaction Reference Block (see section 3.3) for example bank
           charges of some kind. The term "Financial Institution" is
           used in the diagrams IOTP
    Message that contains information that describes the IOTP
    Message and in IOTP Transaction

  o the Transaction Id Component (see section 3.3.1) which globally
    uniquely identifies the text for clarity.
  [Note End]

  The Baseline Deposit IOTP Transaction consists of

  o the following
  Trading Exchanges:
  o   an optional components of the Authentication Exchange Status Block:
    - the Status Component (see section 2.2.4),
  o 6.14).

  [Note]   If the Authentication Document Exchange is followed by an
           Offer Document Exchange (see section 2.2.1), 8.1.2) then the
           Authentication Status Block and the Signature Block
           (Authentication Status) may be combined with either:

           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 TPO 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 8.1.2.3), or

           o a TPO Selection Block
  o  Authentication Request Block
  o  Authentication Response Block
  o and Offer Response Block
  o  Payment Request Block
  o  Payment IOTP Message (see section
             8.1.2.6)
  [Note End]

  8.1.2 Offer Document Exchange Block
  o  Payment Response Block
  o  Signature Block

8.2.1 Baseline Deposit Variations

  The Baseline Deposit IOTP Transaction Offer Document Exchange occurs in two basic forms:

  o  Baseline Deposit with Authentication. Brand Dependent Offer Exchange. Where the Consumer
     making content of the deposit is authenticated before offer,
    e.g. the deposit is
     made, order details, amount, delivery details, etc., are
    dependent on the payment brand and protocol selected by the
    consumer, and

  o  Baseline Deposit without Authentication. Brand Independent Offer Exchange. Where the Consumer content of the
    offer is not authenticated before dependent on the deposit is made.

  In both payment brand and protocol
    selected.

  Each of 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 types of Offer Document Exchange may be preceded by an
  Authentication Document Exchange
  occurs before the (see section 8.1.1).

  8.1.2.1 Brand Dependent Offer Document Exchange

  In a Brand Dependent Offer Document Exchange containing the details of TPO Block and the deposit
  is provided
  Offer Response Block are sent separately by the Financial Institution.

  In Baseline Deposit without Authentication, there Merchant to the
  Consumer, i.e.:

  o the Brand List Component is no Authentication
  Exchange 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 Financial Institution provides details about Brand List Component

  o the
  deposit immediately at Consumer sends the start of selected brand, protocol and
    currency/amount back to the IOTP Transaction.

  These two alternatives are illustrated Merchant in a TPO Selection Block,
    and

  o the two diagrams below. The
  first diagram illustrates Merchant uses the case when an Authentication Exchange information received to define the
    content of and then send the Offer Response Block to the
    Consumer.

  This is
  included. illustrated by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER               OTP              IOTP MESSAGE       FINANCIAL INSTITUTION              MERCHANT
1. Consumer decides                         2. The Financial Merchant decides which
 to deposit                                Institution sets the
electronic cash trade and   -------------------- sends                         payment brand and decides
 sends information             >            which protocols to offer,
 about how much to    Deposit ,
  information that    ------------------->    curencies and amounts
enables the Merchant   Offer Information          generates     apply, places them in a
 to create an
 deposit, the brand offer    (outside scope of      Authentication Request
 to be used, etc    Brand List Component in a
  to           OTP)          Block containing challenge
   the Financial                              data and the method of
 Institution, e.g.                           authentication Merchant,           IOTP)           TPO Block, and sends to
  e.g. using HTML                                  to the                                    Consumer
                                                               |
                                                               v
    3. OTP IOTP aware application                            IotpMsg:Trans
  started.                         OTPMsg:Tran
The consumer Consumer selects the payment  <---------------------      s   <-------------------  Ref Block; TPO
 payment brand, payment protocol           TPO               Block
   and currency/amount 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. Merchant
       |
       v
 OTPMsg:
IotpMsg: Trans                            4. The Financial Institution Merchant uses selected
Ref Block; Auth  -------------------->    checks the Authentication
Response Block; TPO   -------------------->      payment brand, payment
Selection  &     Response against the challenge Block      TPO Selection      Authentication        data in the Authentication
                       Response            Request Block, uses      protocol, currency/amount and
                                           the offer information to identify the
                                         consumer, generates
                                        create an Offer Response Block
                                         containing
                                        information details about the deposit,
                                         and optional Signature Block
                                          IOTP Transaction including
                                         price, etc. optionally signs
                                           it and sends to the Consumer
                                                               |
                                                               v
  5. Consumer checks Offer is OK,                        OTPMsg:                       IotpMsg: 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 next IOTP Message for the                        Response Block
 Payment Handler
 Transaction and sends it  together
with the Signature Block if present
                |                  Note that
    to the Financial Institution required Trading Role
                |
                v                  has, in OTP terminology, a role of
            CONTINUED                          "Merchant".

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

            Figure 20 Baseline Deposit with Authentication

  Note that 21 Brand Dependent Offer Document Exchange
  Note, a Consumer identifies a Brand Dependent Offer Document Exchange,
  by the above diagram: absence of an Offer Response Block in the first IOTP Message.

  MESSAGE PROCESSING GUIDELINES

  On receiving a TPO IOTP Message (see below), the Consumer may either:

  o  describes generate and send a TPO Selection IOTP Message back to the general case where
    Merchant, or

  o indicate failure to continue with the IOTP Transaction by
    sending a Cancel Block back to the Merchant can accept containing a
     deposit in several different types Status
    Component with a StatusType of electronic cash. In
     practice usually only one form Offer, a ProcessState of electronic cash may be
     accepted. However, there may be several different protocols
     which Failed
    and the CompletionCode (see section 6.14.4) set to either:
    ConsCancelled or Unspecified.

  On receiving a TPO Selection IOTP Message (see below) the Merchant may be used for
  either:

  o generate and send an Offer Response IOTP Message back to the same "brand" of electronic cash.
    Consumer, or

  o indicate failure to continue with the financial institution may use IOTP Transaction by
    sending a Cancel Block back to the results Consumer containing a Status
    Component with a StatusType of Offer, a ProcessState of Failed
    and the
     authentication CompletionCode (see section 6.14.4) set to identify not only either:
    MerchCancelled or Unspecified.

  On receiving an Offer Response IOTP Message (see below) the consumer but also Consumer
  may either:

  o generate and send the
     account next IOTP Message in the IOTP transaction
    and send it to which the payment required Trading Role. This is dependent on
    the IOTP Transaction, or

  o indicate failure to be deposited. If no single
     account can be identified, then it must be obtained by other
     means. For example:
     - continue with the consumer could specify IOTP Transaction by
    sending a Cancel Block back to the account number in Consumer containing a Status
    Component with a StatusType of Offer, a ProcessState of Failed
    and the initial
       dialogue CompletionCode (see step 1), section 6.14.4) set to either:
    ConsCancelled or
     - Unspecified.

  If the consumer could have been identified earlier, Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer is likely to go to the CancelNetLocn specified on
  the Trading Role Element in the Organisation Component for example
       using the
  Merchant.

  If the Consumer receives an IOTP Message containing a Baseline Authentication Cancel block,
  then the information contained in the IOTP Transaction, and an account
       selected from Message should be reported
  to the Consumer but no further action taken.

  8.1.2.2 Brand Independent Offer Document Exchange

  In a list provided Brand Independent Offer Document Exchange the TPO Block and the
  Offer Response Block are sent together by the Financial Institution.

  The second diagram illustrates Merchant to the case when
  Consumer, i.e. there is one IOTP Message that contains both a TPO
  Block, and an Authentication
  Exchange Offer Response Block.

  The message flow is not included. illustrated by the diagram below:

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER            OTP               IOTP MESSAGE         FINANCIAL INSTITUTION              MERCHANT
  1. Consumer decides                             2. Financial Institution Merchant decides which
  decides to deposit electronic                       sets the                              payment brand and
   cash brand, protocols ,
trade and sends     ------------------>   decides which protocols to  -------------------->  currencies and amounts apply,
  information about how Deposit Information   offer, generates an      Offer
much to deposit, the Information     places them in a Brand List
 that enables      (outside scope of      Component in a TPO Block,
the Merchant to          IOTP)            creates an Offer Response
create an offer                         Block containing
brand to use, etc to          OTP)            information details about
    to the                              the Financial                              deposit, an optional
  Institution, IOTP Transaction including
Merchant, e.g.                         Signature Block and sends                           price, etc, optionally signs
  using HTML                               it and sends to the Consumer
                                                           |
                                                           v
   3. OTP IOTP aware application                       IotpMsg: Trans Ref
 started.                     OTPMsg:Trans Consumer selects the    <-------------    Block; Signature
   payment brand and payment          TPO &        Block; TPO Block;
    protocol to  <------------   Ref Block; use, records      Offer Response  Offer Response Block
 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 the next IOTP
Message for the Transaction and
   sends it to the
 Payment Handler together with optional the
 Signature Block if present to
   the required Trading Role
               |
               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 22 Brand Independent Offer Exchange

  Note that a Baseline Authentication, authenticated the
     consumer, Brand Independent Offer Document Exchange always occurs
  when only one payment brand, protocol and a secure channel has been maintained, therefore currency/amount is being
  offered to the authenticity of Consumer by the consumer Merchant. It is known
  o  if authentication also likely to, but
  will not necessarily, occur when multiple brands are being offered,
  the Payment Handler is achieved as part the same, and all brands use the same set of a proprietary payment
     protocol
  protocols.

  Note that the TPO Block and is therefore included in the Payment Exchange
  o Offer Response Block can be sent in
  separate IOTP messages (see Brand Dependent Offer Document Exchange)
  even if authentication of the consumer has been achieved by some
     other means outside of Offer Response Block does not change. However this
  increases the scope number of IOTP, for example, by
     using a pass phrase. 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 Authentication Request Offer Response Block in the first IOTP
  Message to determine whether the Baseline Deposit includes
  an Authentication Offer Document Exchange or is brand
  dependent or not.

8.2.3 Baseline Deposit Payment Messages

  Once the

  MESSAGE PROCESSING GUIDELINES

  On receiving a TPO and 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 Message (see below), the
  Consumer has occurred. Note
  that these continue where may either:

  o generate and send the previous diagrams (Figure 20 next IOTP Message in the IOTP transaction
    and Figure
  21) finish.

        CONSUMER              OTP MESSAGE          PAYMENT HANDLER
   3/5. Consumer generates Pay
  Request Block encapsulating a
   payment protocol message if send it to the required and sends Trading Role. This is dependent on
    the IOTP Transaction, or

  o indicate failure to Payment
 Handler continue 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 IOTP Transaction by
    sending a Pay Exchange
 Request Cancel Block                        Block, with back to 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 Merchant containing a Status
    Component inside with a Pay Response
                                   Block, StatusType of Offer, a ProcessState of Failed
    and an optional Signature
                                Component inside the Signature Block,
                                     sends CompletionCode (see section 6.14.1) set to either:
    ConsCancelled or Unspecified.

  If the Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer 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 likely to go to the Baseline Deposit IOTP
  Transaction defines CancelNetLocn specified on
  the contents of each Trading Block. For most
  Trading Blocks, Role Element in the content does not alter with Organisation Component for the variations
  described above. Where differences apply, these are stated.

8.2.4
  Merchant.

  8.1.2.3 TPO (Trading Protocol Options) Block IOTP Message

  The TPO (Trading IOTP Message is only used with a Brand Dependent Offer
  Document Exchange. Apart from a Transaction Reference Block (see
  section 3.3), this message consists of just a Trading Protocol Options) Options
  Block (see section 8.3.2) 7.1) which is described below.

  TPO (TRADING PROTOCOL OPTIONS) BLOCK

  The Trading Protocol Options Block must contain the following Trading
  Components:

  o one Protocol Options Component which defines the options which
    apply to the whole IOTP Transaction. See Section 6.1.

  o one Brand List Component (see section 6.6) which contains for each Payment in
    the IOTP Transaction that contain one or more payment brand brands
    and protocols which may be selected for use in
     the Payment Exchange each payment
  o Organisation Components (see section 6.5) with the following
    roles:
    - the Merchant who is accepting making the deposit offer
    - the Consumer who is making carrying out the deposit transaction
    - the PaymentHandlers PaymentHandler(s) for the payment

8.2.5 TPO Selection Block payment. 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 "ID" of the Payment Exchange. It contains
      Handler Organisation Component is contained within the results PhOrgRef
      attribute of the consumer
     selecting a Payment Brand and Payment Protocol from Component

  If the list
     provided in IOTP Transaction includes a Delivery then the Brand List Component.

8.2.6 Authentication Request Block

  The Authentication Request TPO Block (see section 7.4) must contain the
  following Trading Component:
  also contain:

  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 Organisation Components with the following Trading Component:
  o  one Authentication Response Component (see section 6.3).

8.2.8 Offer Response roles:
    - DeliveryHandler who will be delivering the goods or services
    - DelivTo i.e. the person or organisation which is to take delivery

  AUTHENTICATION STATUS AND SIGNATURE BLOCKS

  If the Offer Document Exchange was preceded by an Authentication
  Document Exchange, then the TPO IOTP Message may also contain:

  o an Authentication Status Block (see section 7.6), and

  o an optional Signature Block (Authentication Status) Signature
    Block

  See section 8.1.1.4 Authentication Status IOTP Message for more
  details.

  8.1.2.4 TPO Selection IOTP Message

  The TPO Selection IOTP Message is only used with a Brand Dependent
  Offer Document Exchange. Apart from a Transaction Reference Block (see
  section 3.3), this message consists of just a TPO Selection Block (see
  section 7.1) which is described below.

  TPO SELECTION BLOCK

  The TPO Selection Block (see section 7.2) contains:

  o one Brand Selection Component (see section 6.7) for use in a
    later Payment Exchange. It contains the results of the consumer
    selecting a Payment Brand, Payment Protocol and currency/amount
    from the list provided in the Brand List Component.

  8.1.2.5 Offer Response IOTP Message

  The Offer Response IOTP Message is only used with a Brand Dependent
  Offer Document Exchange. Apart from a Transaction Reference Block (see
  section 3.3), this message consists of:

  o an Offer Response Block (see section 7.1) and

  o an optional Signature Block (see section 7.16).

  OFFER RESPONSE BLOCK

  The Offer Response Block (see section 7.3) must contain contains the following
  components:

  o  zero or one Authentication Data Status Component (see section 6.2) An
     Authentication Data Component is required for each Payment
     Exchange, where its Payment Component contains an AuthDataRef 6.14) which indicates the
    status of the Offer Response. The ProcessState attribute should
    be set to CompletedOk

  o one Order Component (see section 6.4) which contains details
    about the deposit, for example the amount of value being
     deposited goods and any fees services which might apply are being purchased or the
    financial transaction which is taking place

  o one or more Payment Component Component(s) (see section 6.8) which contains
     information about the for each
    payment which is to be made

  o zero or one Delivery Component Components (see section 6.12) with containing
    details of the DelivExch
     attribute set delivery to False

  The Offer Response Block may also contain one be made if the IOTP Transaction
    includes a delivery

  o zero or more Trading Role Data Components (see section 6.16).

  [Note]   A role of Merchant is used in 6.15) if
    required by the above description since a
           service (i.e. a deposit of electronic cash) Merchant.

  SIGNATURE BLOCK (OFFER RESPONSE)

  If the Authentication Status Block is being offered
           in return for digitally signed then 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) must be included that contains a Signature Component
  (see section 6.17) with Digest Elements for the following XML
  elements:

  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" a Signature Component (see section 6.18).
  The Signature Component contains hashes of
  6.17) with Digest Elements for 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 that contains information that identifies describes the IOTP
    Message and IOTP Transaction
  o the Transaction Id Component (see section 3.3.1) which globally
    uniquely identifies the IOTP Transaction

  o the following components of the Offer Response Block: TPO Block :
    - the Authentication Data Component if present Protocol Options Component, and
    - the Order Brand List Component
    - all the Payment Organisation Components present

  o the following components of the Offer Response Block:
    - the Order Component
    - all the Organisation Payment Components present, and present
    - the Delivery Component if present
    - any Trading Role Data Components
  o  the following components of the present

  8.1.2.6 TPO Block :
     - the Protocol Options Component, and
     - the Brand List Component

  If the Baseline Deposit Offer Response IOTP Message

  The TPO and Offer Response IOTP Message is a Baseline Deposit only used 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
  Independent Offer Document Exchange. Apart from a Transaction
  Reference Block

  The Payment Request (see section 3.3), this message consists of:

  o a Trading Protocol Options Block (see section 7.6) contains: 7.1)

  o  the following components copied from the an Offer Response Block:
     - the Status Component
     - the Authentication Data Component if present
     - the Payment Component
     - the Organisation Components with the roles of: Merchant Block (see section 7.1) and
       PaymentHandler

  o an optional Signature Block (see section 7.16).

  TPO (TRADING PROTOCOL OPTIONS) BLOCK

  This is the  following component from same as the Trading Protocol Options Block described in
  TPO Block:
     - IOTP Message (see section 8.1.2.3).

  OFFER RESPONSE BLOCK

  This the Brand List Component
  o  one Brand Selection Component either:
     - copied from same as 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 in the deposit is a Baseline Deposit
       without Authentication
  o  one Payment Scheme Component Offer Response IOTP
  Message (see section 6.9) if required by 8.1.2.5).

  AUTHENTICATION STATUS

  If the payment method used (see Offer Document Exchange was preceded by an Authentication
  Document Exchange, then the Payment Method supplement to
     determine if this is needed).

  The Payment Request Block TPO and Offer Response IOTP Message may
  also contain one or more Trading Role
  Data Components an Authentication Status Block (see section 6.16).

  Payment Handlers should check that they are authorised to carry out 7.6).

  SIGNATURE BLOCK

  This is the same as the Payment (see section 5 Security Considerations).

8.2.11 Signature Block (Payment Request)

  If in the Baseline Deposit Offer Response Block was signed then the IOTP
  Message that contains (see section 8.1.2.5) with the Payment Request addition that:

  o if the Offer Document Exchange is Brand Dependent then the
    Signature Component in the Signature Block must also contain additionally
    contains a Digest Element for the Brand Selection Component
    contained in the TPO Selection Block

  o if the Offer Document Exchange was preceded by an
    Authentication Document Exchange then the Signature Component
    in the Signature Block with additionally contains a copy of Digest Element
    for the "Offer Response" Signature
  Component.

8.2.12 Authentication Status Block.

  8.1.3 Payment Document Exchange Block

  The Payment Document Exchange Block (see section 7.7) contains:
  o  one is a direct implementation of the last
  part of a Payment Scheme Component Trading Exchange (see section 6.9) which contains
     payment method specific data. See 2.2.2) after the Payment Method
     supplement for Brand
  has been selected by the payment method being used to determine what
     this should contain.

8.2.13 Payment Response Block

  The Consumer. A Payment Response Block (see section 7.8) contains: Exchange consists of:

  o  one the Consumer requesting that a payment starts by generating
    Payment Receipt Component(see section 6.10) which contains
     scheme specific data which can be used Request IOTP Message using information from previous
    IOTP Messages in the Transaction and then sending it to verify the payment
     occurred
    Payment Handler

  o  one the Payment Scheme Component (see section 6.9) if required
     which contains payment method specific data. See Handler and the Consumer then swapping Payment
     Method supplement for
    Exchange IOTP Messages encapsulating payment protocol messages
    until the payment method being used to
     determine what this should contain is complete, and finally

  o the "Offer Response" Signature Component (see section 6.18)
     from the Payment Request Block if present.

  The Handler sending a Payment Response IOTP Message to
    the Consumer containing a receipt for the payment.

  The IOTP Messages which are involved are illustrated by the diagram
  below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER               IOTP MESSAGE         PAYMENT HANDLER
 1. Consumer generates Pay Request
   Block may also contain:
  o encapsulating a payment
 protocol message if required and
 sends to Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components (see section 6.16).

8.2.14 Handler with the
    Signature Block (Payment Response)

  If a signed if present
                 |
                 v
 IotpMsg: Trans                     2. Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Handler processes Pay
   Ref Block;     ------------->     Request Block, checks optional
Signature Block;      Payment Component of the Offer
  Response        signature and starts exchanging
ay Request Block being set to True, then the IOTP Message that contains      Request          payment protocol messages,
                                     encapsulated in a Pay Exchange
                                        Block, with the Consumer
                                                          |
                                                          v
  Consumer keeps <- ----->IotpMsg:                      IotpMsg: Trans
 on exchanging Pay     Trans Ref   <----------------->  Ref Block; Pay
xchange Blocks with   Block; Pay     Payment Response Exchange   Exchange Block must also contain a Signature
  Payment Handler   Exchange Block with
                                                             |
                                                             v
                                     4. Eventually payment protocol
                                   messages finish so Payment Handler
                                  creates Pay Receipt Component inside
                                      a
  "Payment Receipt" Pay Response Block, and an
                                   optional Signature Component which contains hashes of the
  following:
  o inside
                                      the Signature Block, sends to
                                           Consumer and stops
                                                       |
                                                       v
5. Consumer checks Pay Response is                     IotpMsg: Trans
OK. Optionally keeps information on  <---------------     Ref Block;
OTP Transaction Reference Block (see section 3.3) for record keeping  Payment Response  Signature Block
   purposes and either stops or                         Pay Response
creates the next IOTP Message which contains the first usage of the Payment Response
     Block,
  o for                          Block
   the Transaction Id Component (see section 3.3.1) within and sends it
together with the
     Transaction Reference Signature Block that globally uniquely identifies
if present to the required Trading
               Role

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
                   Figure 23 Payment Document Exchange

  8.1.3.1 Message Processing Guidelines

  On receiving a Payment Request IOTP Transaction,
  o Message, the Payment Receipt Component from Handler
  should check that they are authorised to carry out the Payment Response Block, (see
  section 5 Security Considerations). They may then either:

  o generate and send a Payment Exchange IOTP Message back to the other Components referenced by
    Consumer, if more payment protocol messages need to be
    exchanged, or

  o generate and send a Payment Response IOTP Message if the PayReceiptRefs
     attribute (if present)
    exchange of payment protocol messages is complete, or

  o indicate failure to continue with the Payment Receipt Component,
  o by sending a
    Cancel Block back to the Consumer containing a Status Component from
    with a StatusType of Payment, a ProcessState of Failed and the
    CompletionCode (see section 6.14.4) set to either:
    BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError,
    InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument or
    Unspecified.

  On receiving a Payment Response Block, Exchange IOTP Message, the Consumer may either:

  o  any Trading Role Data Components in generate and send a Payment Exchange Message back to the
    Payment Response
     Block, and Handler or

  o  the "Offer Response" Signature Component from indicate failure to continue with the Payment
     Request by sending a
    Cancel Block if present.

8.3 Baseline Purchase IOTP Transaction

  The Baseline Purchase IOTP Transaction supports back to the purchase Payment Handler containing a Status
    Component with a StatusType of goods
  or services using any payment method. It consists Payment, a ProcessState of
    Failed and the following
  Trading Exchanges:
  o  an Offer Exchange (see section 2.2.1),
  o  a Payment Exchange CompletionCode (see section 2.2.2), and
  o  an optional Delivery Exchange (see section 2.2.3)

  These Trading Exchanges are implemented by a 6.14.2) set of predefined IOTP
  Messages (see section o) which are exchanged between the Trading Roles
  (see section 2.1). Each to
    either: ConsCancelled or Unspecified.

  On receiving a Payment Exchange 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 Message, the Baseline Purchase IOTP Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Offer Response Block
  o Payment Request Block Handler may
  either:

  o generate and send a 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 Message back to the
    Consumer, if more payment brand and protocol selected by the
     consumer, and messages need to be
    exchanged, or

  o  Brand Independent Purchase. Where generate and send a Payment Response IOTP Message if the content
    exchange of the offer is
     not dependent on the payment brand and protocol selected.

  Further variation is supported in that:
  o  the Delivery Exchange messages is optional, and complete, or

  o  the Delivery Response Block may be sent indicate failure to the consumer
     either:
     - at the same time as the Payment Response Block, or
     - after continue with the Payment Response by sending a
    Cancel Block as the result of back to the Consumer
       sending the Delivery Handler containing a Delivery Request Block.

8.3.1.1 Brand Dependent Purchases

  In Status Component
    with a Brand Dependent Purchase the TPO Block StatusType of Payment, a ProcessState of Failed and the Offer Response
  Block are sent separately by the Merchant
    CompletionCode (see section 6.14.2) set to either:
    PaymtCancelled or Unspecified.

  On receiving a Payment Response IOTP Message, the Consumer, i.e.: Consumer may either:

  o generate and send the Brand List Component is sent to the Consumer next IOTP Message in a TPO
     Block,
  o the Consumer selects a Payment Brand, Payment Protocol and
     optionally a Currency IOTP transaction
    and amount from send it to the Brand List Component required Trading Role. This is dependent on
    the IOTP Transaction,

  o stop, since the Consumer sends IOTP Transaction has ended, or

  o indicate failure to continue with the selected brand, protocol and
     currency/amount IOTP Transaction by
    sending a Cancel Block back to the Merchant in containing a TPO Selection Block,
     and
  o  the Merchant uses the information received to define the
     content Status
    Component with a StatusType of Payment, a ProcessState of
    Failed and then send the Offer Response Block CompletionCode (see section 6.14.1) set to
    either: ConsCancelled or Unspecified.

  If the
     Consumer.

  In Consumer receives an IOTP Message containing a Brand Independent Purchase the TPO Block and Cancel block,
  then the Offer Response
  Block are sent together by information contained in the Merchant IOTP Message should be reported
  to the Consumer in but no further action taken.

  If the same Payment Handler receives an IOTP Message at containing a Cancel
  block, then the start of Consumer is likely to go to the IOTP Transaction.

  These two alternatives are illustrated CancelNetLocn
  specified on the Trading Role Element in the two diagrams below. The
  first diagram illustrates Organisation Component
  for the Payment Handler from which any further action may take place.

  If the Merchant receives an IOTP Message containing a Brand Dependent Purchase.

       CONSUMER                OTP MESSAGE              MERCHANT
1. Cancel block,
  then the Consumer decides                          2. Merchant decides which
 to trade and sends should have completed the payment brand and
 information about    --------------------> protocols to offer, places
what but not continuing
  with the transaction for some reason. In this case the Consumer is
  likely to purchase go to   Purchase Information     them the CancelNetLocn specified on the Trading Role
  Element in a Brand List the Merchant, e.g.     (outside scope of Organisation Component in a TPO Block,
     using HTML               OTP)             and sends to Consumer
                                                                |
                                                                v
3. OTP aware application started. Consumer                   OTPMsg:
   selects for the payment brand and payment    <-----------    Trans Ref
  protocol to use, records selection in Merchant from which any
  further action may take place.

  8.1.3.2 Payment Request IOTP Message

  Apart from a        TPO       Block; TPO
 Brand Selection Component, and sends back Transaction Reference Block
                to Merchant
      |
      v
 OTPMsg:Trans                     4. Merchant uses payment brand and
Ref Block; TPO  ------------>    protocol selected (see section 3.3), this
  message consists of:

  o a Payment Request Block, and information on
  Selection     TPO Selection    what is being purchased to create

  o an optional Signature Block                      Offer Response

  PAYMENT REQUEST BLOCK

  The Payment Request 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 (see section 7.7) contains:

  o the following components copied from the TPO    <---------------    Ref Block;
Block, the TPO Selection Block and    Offer Response      Signature
the Offer Response Block to create                      Block;
    from the preceding Offer
a Pay Request Block and sends it to                    Response Block Document Exchange:
    - the Status Component
    - the Payment Handler together with Component for the Signature Block if present
                 |
                 v
             CONTINUED

  Figure 23 Brand Dependent Baseline Purchase

  The second diagram illustrates payment which is being carried out
    - the Brand Independent Purchase.

       CONSUMER                OTP MESSAGE              MERCHANT
  1. Consumer                             2. Organisation Components with the roles of Merchant decides which
  decides to                            payment brand and protocols to
trade and sends  -------------------->  offer, places them in a for the
      PaymentHandler that is being sent the Payment Request Block

  o the  following component from the TPO Block:
    - the Brand
  information    Purchase Information List Component in a TPO Block,
 about what to     (outside scope of      creates an Offer Response
purchase to for 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 payment, i.e. the    <-------------    Block; Signature
   payment brand and payment          TPO &        Block; TPO Block;
    protocol Brand List
      referred to use, records      Offer Response  Offer Response Block
 selection in a by the BrandListRef attribute on the Payment Component

  o one Brand Selection
 Component, checks Offer is OK,
  combines Component for the Brand List, i.e. the
    Brand Selection Component with information where BrandListRef attribute points
    to the Brand List. This component can be either:
    - copied from the TPO Selection Block and Offer Response
 Block to create if the payment was preceded by
      a Pay Request
   Block and sends it to Brand Dependent Offer Document Exchange (see section 8.1.2.1),
      or
    - created by the
 Payment Handler together with Consumer, containing 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 brand, payment
      protocol is being offered to and currency/amount selected from the Consumer by the Merchant. It is
  also likely to, but will not necessarily, occur when multiple brands
  are being offered, Brand List, if the
      payment was preceded by a Brand Independent Offer Document
      Exchange (see section 8.1.2.2)

  o an optional Payment Handler is the same, and all brands use
  the same set of protocols.

  Note that Scheme Component (see section 6.9) if
    required by the TPO Block and payment method used (see the Offer Response Block may be sent in
  separate IOTP messages even Payment Method
    supplement to determine 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 needed).

  o zero or more Trading Role must
  check for the existence of Data Components (see section 6.15).

  Note that:

  o if there is more than one Payment Components in an Offer
    Response Block in the first IOTP
  Message to determine whether Block, then the Baseline Purchase second payment is brand dependent
  or not.

8.3.1.2 Combining Delivery Response Block and Payment Response Block

  The Delivery the one within the
    Offer Response Block and that contains a StartAfter attribute (see
    section 6.8) that identifies the Payment Response Block may be
  sent: Component for the
    first payment

  o  separately by the Payment Handler to include is identified by the Consumer, i.e.:
     - the Payment Response Block containing a Payment Receipt and
       optional signature Brand
    Selection Component (see section 6.7) for the payment is payment. Also see
    section 5.3.1 Check the Action Request was sent by to the Correct
    Organisation for an explanation on how Payment
       Handler Handlers are
    identified

  o the Brand List Component to include is the Consumer,
     - one identified by
    the Consumer combines these components from BrandListRef attribute of the Payment Response
       Block with components Component for the
    identified payment
  o the Brand Selection Component to include from the Offer
    Response Block, to create a
       Delivery Request Block
     - is the Consumer sends one that contains an BrandListRef
    attribute (see section 3.5) which identifies the Delivery Request Block to Brand List
    Component for the Delivery
       Handler
     - second payment.

  SIGNATURE BLOCK (PAYMENT REQUEST)

  If the Delivery Handler processes either the Delivery Request Block and
       sends a Delivery preceding Offer Document Exchange included an Offer
  Response Block back to the Consumer, Signature (see section 8.1.2.5 Offer Response IOTP Message),
  or
  o  together, from the Payment Handler to the Consumer, when the a preceding Payment Exchange is complete.

  These two alternatives are illustrated in the two diagrams below.

  The first diagram illustrates when the Delivery included a Payment Response Block and the Signature
  (see section 8.1.3.4 Payment Response Block are sent IOTP Message) then they should
  both be copied to the Consumer Signature Block 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 IOTP
  Message.

  8.1.3.3 Payment     Block, and starts exchanging payment
 Request Exchange IOTP Message

  Apart from a Transaction Reference Block        Request     protocol messages, encapsulated in (see section 3.3), this
  message consists of just 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 Block.

  PAYMENT EXCHANGE BLOCK

  The Payment Handler Exchange Block
                                                             |
                                                             v
                                     8. Eventually payment protocol
                                   messages finish so (see section 7.8) contains:

  o one Payment Handler
                                    creates Pay Receipt Scheme Component and
                                   inside (see section 6.9) which contains
    payment method specific data. See the Payment Method supplement
    for the payment method being used to determine what this should
    contain.

  8.1.3.4 Payment Response IOTP Message

  Apart from a Pay Transaction Reference Block (see section 3.3), this
  message consists of:

  o a Payment Response Block, and

  o an optional Signature Block

  PAYMENT RESPONSE BLOCK

  The Payment Response Block (see section 7.9) contains:

  o one Payment Receipt Component in (see section 6.10) which contains
    scheme specific data which can be used to verify the
                                   Signature Block, sends 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 Consumer
                                                and stops
                                                       |
                                                       v
9. Consumer checks Pay Response
    determine what this should contain

  o an optional Payment Note Component (see section 6.11)

  o zero or more Trading Role Data Components (see section 6.15).

  SIGNATURE BLOCK (PAYMENT RESPONSE)

  If a signed Payment Receipt is                     OtpMsg: Trans
 OK, and creates Delivery Request   <---------------     Ref Block; being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component being set to True,
  then the Signature Block should contain a Signature Component which
  contains Digest Elements for the following:

  o the Transaction Reference Block (see section 3.3) for the IOTP
    Message which contains the first usage of the Payment Response
    Block,

  o the Transaction Id Component (see section 3.3.1) within the
    Transaction Reference Block that globally uniquely identifies
    the IOTP Transaction,

  o the Payment Receipt Component from Pay the Payment Response Block, Offer

  o the other Components referenced by the PayReceiptRefs attribute
    (if present) of the Payment Receipt Component,

  o the Status Component from the Payment Response  Signature Block Block,

  o any Trading Role Data Components in the Payment Response Block Block,
    and

  o all the Signature Components contained in the Payment Request
    Block                      Pay Response if present.

  8.1.4 Delivery Document Exchange

  The Delivery Document Exchange is a direct implementation of a
  Delivery Trading Exchange (see section 2.2.3). It consists of:

  o the Consumer requesting a Delivery by generating Delivery
    Request IOTP Message using information from previous IOTP
    Messages in the Transaction and sends then sending it to the Delivery
    Handler                          Block
       |          ====================================================
       v
  o the Delivery Handler sending a Delivery Response IOTP Message
    to the Consumer containing details about the Handler's response
    to the request together with an optional signature.

  The message flow is illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER              IOTP MESSAGE          DELIVERY HANDLER
tpMsg: Trans Ref                    10.
1. Consumer generates                            2. Delivery Handler
  Delivery Request                              checks Pay
Block; Signature  ------------->  Receipt, Order in Offer Response the Status and
Block and sends it to  --------------------->  Order Components in the
the Delivery Handler      Delivery Request      Delivery Request and
 with the Signature                                 the optional
  Block if present                              Signatures, creates a
 Request Block       Request
                                                  Delivery Response
                                                   Block, sends to
                                                 Consumer and stops
                                                          |
                                                          v
 10.
 3. Consumer checks Delivery                     OtpMsg: Trans Ref                            IotpMsg:Trans
    Response Block is OK,       <-------------      <--------------------     Ref Block; Delivery
ptionally
optionally keeps information on     Delivery Response Block
  OTP        Delivery
   on IOTP Transaction for record                             Response               | Block
 record keeping purposes and
            stops                              v
                                                         STOP
              |
              v
             STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                   Figure 25 Baseline Purchase, 24 Delivery Response Block and Payment
  Response Blocks Not Combined
  The second diagram illustrates Document Exchange

  8.1.4.1 Message Processing Guidelines

  On receiving a Delivery Request IOTP Message, the case when Delivery Handler
  should check that they are authorised to carry out the Delivery Response
  Block (see
  section 5 Security Considerations). They may then either:

  o generate and the Payment send a Delivery 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 Message to Payment
 Handler together the
    Consumer, or

  o indicate failure to continue 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 the Delivery by sending a Pay Exchange
    Cancel Block                              Block, with back to 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 containing a Status Component inside
    with a Pay Response
                                      Block StatusType of Delivery, a ProcessState of Failed and an optional Signature
                                     Component, then uses information
                                     from the Offer Response Block
    CompletionCode (see section 6.14.4) set to
                                     create either:
    DelivCanceled, or Unspecified.

  On receiving a Delivery Response Block,
                                     sends both to IOTP Message, the Consumer and stops
                                                     |
                                                     v
  9. should
  just stop since the IOTP Transaction is complete.

  If the Consumer checks Pay                      OtpMsg: Trans Ref Block;
  Response and Delivery     <---------------    Signature Block; Pay
 Response Blocks are OK,    Payment Response  Response Block; receives an IOTP Message containing a Cancel block,
  then the information contained in the IOTP Message should be reported
  to the Consumer but no further action taken.

  8.1.4.2 Delivery
     optionally keeps          & Request IOTP Message

  The Delivery          Response Block
    information on OTP          Response                  |
  Transaction for record                                  v
keeping purposes and stops                              STOP
            |
            v
           STOP

  Figure 26 Baseline Purchase, Request IOTP Message consists of:

  o a Delivery Response Block Request Block, and Payment
  Response

  o an optional Signature Block Combined

  DELIVERY REQUEST BLOCK

  The Delivery Response Request Block and (see section 7.10) contains:

  o the Payment Response Block may be
  combined into following components copied from the same IOTP Message only if Offer Response Block:
    - the Payment Handler has Status Component (see section 6.14)
    - the information available so that she can send Order Component (see section 6.4)
    - the Delivery Response
  Block. This is likely to, but will not necessarily, occur when Organisation Component (see section 6.5) with the roles of:
      Merchant, the Payment Handler DeliveryHandler and the Delivery Handler Roles are
  combined.

  The DelivAndPayResp attribute of DeliverTo
    - the Delivery Component (see section 6.12) contained within

  o the Offer following Component from the Payment Response Block Block:
    - the Status Component (see section 7.3) is
  set to True if 6.14).

  o zero or more Trading Role Data Components (see section 6.15).

  SIGNATURE BLOCK (DELIVERY REQUEST)

  If the Delivery preceding Offer Document Exchange included an Offer Response Block and
  Signature or the Payment Document Exchange included a Payment Response
  Block are combined into
  Signature, then they should both be copied to the same Signature Block.

  8.1.4.3 Delivery Response IOTP Message and is set to False if
  the

  The Delivery Response IOTP Message contains a Delivery Response Block
  and the Payment an options Signature Block.

  DELIVERY RESPONSE BLOCK

  The Delivery Response Block are sent in
  separate IOTP Messages.

8.3.1.3 Optional contains:

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

  SIGNATURE BLOCK (DELIVERY RESPONSE)

  The final variation Signature Block should contain one Signature Component that
  contains Digest elements that refer to

  o the Transaction Id Component (see section 3.3.1) of the Baseline Purchase IOTP Transactions is a
  purchase without
    message that contains the Delivery  Response Signature

  o the Transaction Reference Block (see section 3.3) of the IOTP
    Message that contains the Delivery  Response Signature

  o the Signature Components contained in the Delivery Request (if
    any)

  o the Status Component

  o the Delivery Note Component

  8.1.5 Payment and Delivery Document Exchange

  The Payment and Delivery Document Exchange is a delivery step. This combination of the
  last part of the Payment Trading Exchange (see section 2.2.2) and a
  Delivery Trading Exchange (see section 2.2.3). It consists of:

  o the Consumer requesting that a payment starts by generating
    Payment Request IOTP Message using information from previous
    IOTP Messages in the Transaction and then sending it to the
    Payment Handler

  o the Payment Handler and the Consumer then swapping Payment
    Exchange IOTP Messages encapsulating payment protocol messages
    until the payment is illustrated complete, and finally

  o the Payment Handler sending to the Consumer in one IOTP
    Message:
    - a Payment Response Block containing a receipt for the following
  diagram payment, and
    - a Delivery Response Block containing details of the goods or
      services to be delivered

  The IOTP Messages which continues where are involved are illustrated by the earlier diagrams (Figure 23and
  Figure 24) finish. diagram
  below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

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

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

             Figure 27 Baseline Purchase, Purchase without 25 Payment and Delivery Document Exchange
  The DelivExch 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 in within the Offer Response Block (see section 7.3) is
  set to
  False True if the Delivery Exchange is omitted Response Block and the Payment Response
  Block are combined into the same IOTP Message and is set to True False 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 the Payment 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 are sent in
  separate IOTP
  Transaction defines the contents of each Trading Block. For most
  Trading Blocks, Messages.

  8.1.5.1 Message Processing Guidelines

  On receiving a Payment Request IOTP Message or a Payment Exchange IOTP
  Message, the content does not alter with Payment Handler should carry out 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 same actions as for
     use in the
  a Payment Document Exchange
  o  Organisation Components (see section 6.5) with the following
     roles:
     - Merchant who is providing 8.1.3.1).

  On receiving a Payment Exchange IOTP Message, the goods or services
     - Consumer who is making should also
  carry out the purchase
     - PaymentHandlers same actions as 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 a Payment Document Exchange (see
  section 6.7) for use in the
     Payment Exchange. It contains the results of the consumer
     selecting 8.1.3.1).

  On receiving a Payment Brand and Payment Protocol from the list
     provided in the Brand List Component.

8.3.4 Offer Response Block

  The Offer and Delivery Response Block (see section 7.3) contains IOTP Message
  then the following
  components:
  o  zero or one Authentication Data Component (see section 6.2) An
     Authentication Data Component IOTP Transaction is required for each Payment
     Exchange, where its Payment Component (see section 6.8)
     contains complete and should take no further
  action.

  If the Consumer receives an AuthDataRef attribute.
  o  one Order Component (see section 6.4) which contains details
     about IOTP Message containing a Cancel block,
  then the goods, services which are being purchased
  o  one Payment Component (see section 6.8) which contains information about contained in the payment which is to IOTP Message should be made
  o  Organisation Components (see section 6.5) with reported
  to the following
     roles:
     - Merchant who is providing Consumer but no further action taken.

  If the Payment Handler receives an IOTP Message containing a Cancel
  block, then the goods or services
     - Consumer who is making likely to go to the purchase
     - PaymentHandler for CancelNetLocn
  specified on the payment. The "ID" of Trading Role Element in the Payment Handler Organisation Component is contained within the VaOrgRef
       attribute of
  for the Payment Component
  o  one Delivery Component (see section 6.12) Handler from which contains
     details of the delivery to be made. any further action may take place.

  If the Baseline Purchase includes Merchant receives an IOTP Message containing a Delivery Exchange Cancel block,
  then the Offer
  Response Block must also contain:
  o  Organisation Components with Consumer should have completed the following roles:
     - DeliveryHandler who will be delivering payment but not continuing
  with the goods or services
     - DelivTo i.e. transaction for some reason. In this case the person or organisation which Consumer is
  likely to take
       delivery

  The Offer Response Block may also contain one or more go to the CancelNetLocn specified on the Trading Role
  Data Components (see section 6.16).

8.3.5 Signature Block (Offer Response)

  If
  Element in the Baseline Purchase Offer Response Organisation Component for the Merchant from which any
  further action may take place.

  8.1.5.2 Payment Request IOTP Message

  The content of this message is being digitally signed then
  a Signature Block must be included in the same as for a Payment Request IOTP message that
  contains an "Offer Response" Signature Component
  Message in a Payment Document Exchange (see section 6.18). 8.1.3.2)

  8.1.5.3 Payment Exchange IOTP Message

  The Signature Component contains hashes content of this message is the following XML elements:
  o  the Transaction Reference Block (see section 3.3) same as for the IOTP
     Message which contains the first usage of the Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the a Payment Exchange IOTP
  Message and IOTP Transaction
  o  the Transaction Id Component in a Payment Document Exchange (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 8.1.3.3).

  8.1.5.4 Payment Component
     - all the Organisation Components present, Response 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 Response IOTP Message

  The content of the following: this message consists of:

  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.3.6 Payment Request Block

  The a Payment Request Response Block,

  o an optional Signature Block (see section 7.6) contains: (Payment Response), and

  o  the following components copied from the Offer a Delivery Response Block:
     - the Status Component
     - Block.

  PAYMENT RESPONSE BLOCK

  The content of this block is the Authentication Data Component if present
     - same as 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 in
  the purchase is Payment Response IOTP Message associated with a Brand
       Independent Purchase
  o  one Payment Scheme Component Document
  Exchange (see section 6.9) if required by
     the payment method used (see the Payment Method supplement to
     determine if 8.1.3.4).

  SIGNATURE BLOCK (PAYMENT RESPONSE)

  The content of this block 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 same as the Signature Block (Payment Request)

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

8.3.8 Payment Exchange Block

  The
  Payment Document Exchange Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See 8.1.3.4).

  DELIVERY RESPONSE BLOCK

  The content of this block is the Payment Method
     supplement for same as the payment method being used to determine what
     this should contain.

8.3.9 Payment Delivery Response Block

  The Payment
  in the Delivery Response Block IOTP Message associated with a Delivery
  Document Exchange (see section 7.8) contains: 8.1.4.3).

  8.1.6 Baseline Authentication IOTP Transaction

  A Baseline Authentication IOTP Transaction may occur at any time
  between any of the Trading Roles involved in OTP Transactions. This
  means it could occur:

  o  one Payment Receipt Component (see section 6.10) which
     contains scheme specific data which can be used to verify before another IOTP Transaction
  o at the
     payment occurred same time as another IOTP Transaction

  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 independently of any other IOTP Transaction.

  The Payment Response Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o  one or more Trading Role Data Components Baseline Authentication IOTP Transaction consists of just an
  Authentication Document Exchange (see section 6.16).

8.3.10 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated 8.1.1) as illustrated by
  the
  SignedPayReceipt attribute of the Payment Component diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -------------------------------------------------------
                                                             v
                                                    ----------------
                                                   | AUTHENTICATION |
                                                    ----------------
                                                              |
                                                              |
                                                              |
                                                              |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                                                              |
                                                              |
                                                              |
                                                              |
                                                              |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                                                              |
                                                              |
                                                              |
      ----------        ---------                             |
     | DELIVERY |      | PAYMENT |                            |
     |          |      | {second)|                            |
      ----------        ---------                             |
                                                              v
                                                            STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

            Figure 26 Baseline Authentication IOTP Transaction

  Example uses of the Offer
  Response Block being set to True, then the Baseline Authentication IOTP Message that contains Transaction include:

  o when the Payment Response Block must also contain Baseline Authentication IOTP Transaction takes place
    as an early part of a Signature Block session where strong continuity exists.
    For example, a Financial Institution could:
    - set up a secure channel (e.g. using SSL) with a
  "Payment Receipt" Signature Component which contains hashes of the
  following:
  o customer
    - authenticate the Transaction Reference Block (see section 3.3) for customer using the Baseline Authentication IOTP
     Message which contains
      Transaction, and then
    - provide the first usage of customer with access to account information and other
      services with the Payment Response
     Block, confidence that they are communicating with a
      bona fide customer.

  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block as a means of providing a Merchant role with Organisation
    Components that globally uniquely identifies
     the IOTP Transaction, contain information about Consumer and DelivTo
    Trading Roles

  o  the Payment Receipt Component from the so that a Consumer may authenticate a Payment Response Block
  o  the other Components referenced by Handler before
    starting a payment.

  8.1.7 Baseline Deposit IOTP Transaction

  The Baseline Deposit IOTP Transaction supports the PayReceiptRefs
     attribute (if present) deposit of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block
  o  any Trading Role Data Components
  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 Payment Response
     Block, diagrams and
  o  the "Offer Response" Signature Component from in the Payment
     Request Block if present.

8.3.11 Delivery Request Block text for clarity.
  [Note End]

  The Delivery Request Block (see section 7.9) contains:
  o Baseline Deposit IOTP Transaction consists of the following components copied from the Offer Response Block:
     - the Status Component
  Document Exchanges:

  o an optional Authentication Document Exchange (see section 6.15)
     - the Order Component
    8.1.1)

  o an Offer Document Exchange (see section 6.4)
     - the Organisation Component (see section 6.5) with the roles of:
       Merchant, DeliveryHandler 8.1.2), and DeliverTo
     - the Delivery Component (see section 6.12)

  o  the following Component from the a Payment Response Block:
     - the Status Component Document Exchange (see section 6.15). 8.1.3).

  The Delivery Request Block way in which these Document Exchanges 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 be combined together is
  illustrated by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -----------------------------------------------------
   |                                                       v
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |
                    |                     |              |
                    |      -------------- | -------------
                    v      v              v      v
               -------------------     -----------------
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |
              |       OFFER       |   |      OFFER      |
               -------------------     -----------------
                     |                        |
                     |                        |
                     |                        |
                     |     -------------------
                     v    v
                   ---------           --------------
                  | PAYMENT |         | PAYMENT WITH |
                  | (first) |         |   DELIVERY   |
                   ---------           --------------
                       |
                        ----------------
                                        |
      ----------        ---------       |
     | DELIVERY |      | PAYMENT |      |
     |          |      | {second)|      |
      ----------        ---------       |
                                        |
                                         -----------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

               Figure 27 Baseline Purchase Offer Response or Payment Response Blocks
  were signed then the Deposit 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 Transaction

  See section 6.13) 8.1.12 _Valid Combinations of Document Exchanges_ to
  determine which contains
     delivery instructions about the delivery combination of goods or services

8.4 Baseline Refund document exchanges apply to a
  particular instance of an IOTP Transaction

  In business terms the refund process typically consists of:

  Note that:

  o a request for Merchant (Financial Institution) may be able to accept a refund being made by
    deposit in several different types of electronic cash although,
    since the Consumer to role that is depositing the
     Merchant, typically supported by evidence electronic cash
    usually knows what type of cash they want to demonstrate:
     - the original trade took place, for example by providing a
       receipt deposit, it is
    usually constrained in practice to only one type. However,
    there may be several different protocols which may be used for
    the original transaction
     - using some type same "brand" of authentication, that electronic cash. In this case a Brand
    Dependent Offer may be appropriate to negotiate the consumer requesting protocol to
    be used.

  o the refund is Merchant (Financial Institution) may use the consumer, or a representative results of the consumer,
       who carried out
    authentication to identify not only the original trade
     - consumer but also the reason why
    account to which the merchant should make payment is to be deposited. If no single
    account can be identified, then it must be obtained by other
    means. For example:
    - the refund
  o consumer could specify the merchant agreeing (or not) account number prior to the refund. This may involve
     some negotiation between
      Baseline Deposit IOTP Transaction starting, or
    - the Consumer consumer could have been identified earlier, for example using
      a Baseline Authentication IOTP Transaction, and the Merchant, and,
     if the merchant agrees,
  o an account
      selected from a refund payment list provided by the Merchant to the Consumer. Financial Institution.

  o The Baseline Refund Deposit IOTP Transaction supports a subset of the above,
  specifically it supports:
  o  the optional authentication of the Consumer using without an Authentication
    Document Exchange (see section 2.2.4), might be used:
    - if a previous IOTP transaction, for example a Baseline Withdrawal
      or a Baseline Authentication, authenticated the consumer, and
  o a
      secure channel has been maintained, therefore the refund authenticity of
      the consumer is known
    - if authentication is achieved as part of a proprietary payment
      protocol and is therefore included in the Payment Document
      Exchange
    - if authentication of the consumer has been achieved by some other
      means outside of the Merchant to scope of IOTP, for example, by using a pass
      phrase, or a proprietary banking software solution.

  8.1.8 Baseline Purchase IOTP Transaction

  The Baseline Purchase IOTP Transaction supports the Consumer purchase of goods
  or services using any payment method. It consists of the following two Trading
  Document Exchanges:
     -

  o an optional Authentication Document Exchange (see section
    8.1.1)

  o an Offer Document Exchange (see section 2.2.1), and 8.1.2)

  o either:
    - a Payment Document Exchange (see section 2.2.2).

  These Trading Exchanges are implemented 8.1.3) followed 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 Delivery Document Exchange (see section 7) which contain the Trading Components 8.1.4)
  o a Payment Document Exchange only, or

  o a combined Payment and Delivery Document Exchange (see section 6)
    8.1.5).

  The ways in which these Document Exchanges are required by the Trading Exchanges.

  The Trading Blocks used combined is illustrated
  by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -----------------------------------------------------
   |                                                       v
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |    |
                    |                     |              |    |
                    |      -------------- | -------------     |
                    v      v              v      v            |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                     |    |                   |   |           |
                     |     ---------------    |   |           |
                     |                    |   |   |           |
                     |     -------------- | --    |           |
                     v    v               v       v           |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                       |                      |               |
           -----------------------------      |               |
           v                            |     |               |
      ----------        ---------       |     |               |
     | DELIVERY |      | PAYMENT |      |     |               |
     |          |      | {second)|      |     |               |
      ----------        ---------       |     |               |
           |                            |     |               v
            ----------------------------------------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

               Figure 28 Baseline Purchase IOTP Transaction 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
  See section 8.1.12 Valid Combinations of Document Exchanges to
  determine which combination of document exchanges apply to a
  particular instance of an IOTP Transaction

  8.1.9 Baseline Refund IOTP Transaction occurs in two basic forms:

  In business terms the refund process typically consists of:

  o  Baseline Refund with Authentication. Where 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 authenticated before the refund is
     made, and
  o  Baseline Refund without Authentication. Where consumer, or a representative of the Consumer is
     not authenticated before consumer,
      who carried out the refund is made.

8.4.2 Baseline Refund Authentication

  In Baseline Refund with Authentication an Authentication Exchange
  occurs before original trade
    - the Offer Exchange containing reason why the details of merchant should make the refund
  is provided by

  o the Merchant.

  In Baseline Refund without Authentication, there is no Authentication
  Exchange and the Merchant provides details about merchant agreeing (or not) to the refund
  immediately at refund. This may involve
    some negotiation between the start of Consumer and the IOTP Transaction.

  These two alternatives are illustrated in Merchant, and, if
    the two diagrams below. The
  first diagram illustrates merchant agrees,

  o a refund payment by 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 the Consumer.

  The Baseline Refund Information          generates an
 information about     (outside scope of     Authentication Request
 refund, such as IOTP Transaction supports a           OTP)          Block containing challenge
reference number to                          data and the method subset of the Merchant, e.g. above,
  specifically it supports:

  o stand alone authentication and sends
     using HTML                                  to of 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 using a Brand   Authentication
Selection Component, generates      Request
  an separate
    Baseline Authentication Response
Component and sends both back
       to IOTP Transaction (see section 8.1.6)

  o a refund payment by 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 Consumer using the
                                 refund,
    following two Trading Exchanges:
    - an optional Signature Block
                                      and sends to the Consumer
                                                              |
                                                              v
  5. Consumer checks Authentication Document Exchange (see section 8.1.1)
    - an Offer is OK,                       OTPMsg: Trans
 combines components from the TPO    <---------------    Ref Block;
Block, the TPO Selection Block Document Exchange (see section 8.1.2), 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 Document Exchange (see section 8.1.3).

  The ways in which these Document Exchanges are combined is illustrated
  by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -----------------------------------------------------
   |                                                       v
             CONTINUED
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |
                    |                     |              |
                    |      -------------- | -------------
                    v      v              v      v
               -------------------     -----------------
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |
              |       OFFER       |   |      OFFER      |
               -------------------     -----------------
                     |                        |
                     |                        |
                     |                        |
                     |     -------------------
                     v    v
                   ---------           --------------
                  | PAYMENT |         | PAYMENT WITH |
                  | (first) |         |   DELIVERY   |
                   ---------           --------------
                       |
                        ----------------
                                        |
      ----------        ---------       |
     | DELIVERY |      | PAYMENT |      |
     |          |      | {second)|      |
      ----------        ---------       |
                                        |
                                         -----------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                Figure 29 Baseline Refund with Authentication

  The second diagram illustrates the case when IOTP Transaction

  A Baseline Refund IOTP Transaction without an Authentication Document
  Exchange is not included.

       CONSUMER               OTP MESSAGE              MERCHANT
 1. Consumer requests                    2. Merchant sets the payment
 payment might be used:

  o when authentication of the consumer has been achieved by some
    other means, for example, the consumer has entered some
    previously                      brand and decides which
 agreed refund, sends   -------------->       protocols supplied code in order to offer,
   information about         Refund       generates an Offer Response identify herself and the
    refund to which 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, 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.

  8.1.10 Baseline Withdrawal IOTP aware applications supporting the Consumer Trading Role must
  check for Transaction

  The Baseline Withdrawal IOTP Transaction supports the existence withdrawal of an Authentication Request Block
  electronic cash from a Financial Institution.

  [Note]   The Financial Institution has, 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 terminology, a role
           of IOTP Messages illustrated merchant 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 service (i.e. a withdrawal of
           electronic cash) is being offered in return for a Pay
                                   Exchange Block, with fee, for
           example bank charges of some kind. The term "Financial
           Institution" is used in 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 diagrams 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 in the text for record                                 |
eeping purposes and stops                               v
            |                                          STOP
            v
          STOP

  Figure 31 Baseline Refund Payment Messages
           clarity.
  [Note End]

  The remainder of this sub-section on the Baseline Refund Withdrawal IOTP Transaction defines the contents consists 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:
  Document Exchanges:

  o  one Protocol Options Component which defines the options which
     apply to the whole IOTP Transaction. See Section 6.1. an optional Authentication Document Exchange (see section
    8.1.1)

  o  one Brand List Component an Offer Document Exchange (see section 6.6) which contains the
     payment brand 8.1.2), and protocols which may be selected for use in
     the

  o a Payment Document 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 8.1.3).

  The TPO Selection Block (see section 7.2) way in which these Document Exchanges may be combined together is only used
  illustrated by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -----------------------------------------------------
   |                                                       v
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |
                    |                     |              |
                    |      -------------- | -------------
                    v      v              v      v
               -------------------     -----------------
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |
              |       OFFER       |   |      OFFER      |
               -------------------     -----------------
                     |                        |
                     |                        |
                     |                        |
                     |     -------------------
                     v    v
                   ---------           --------------
                  | PAYMENT |         | PAYMENT WITH |
                  | (first) |         |   DELIVERY   |
                   ---------           --------------
                       |
                        ----------------
                                        |
      ----------        ---------       |
     | DELIVERY |      | PAYMENT |      |
     |          |      | {second)|      |
      ----------        ---------       |
                                        |
                                         -----------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

              Figure 30 Baseline
  Refund with Authentication. It contains: Withdrawal IOTP Transaction

  Note that:

  o a Merchant (Financial Institution) may be able to offer
    withdrawal of several different types of electronic cash. In
    practice usually only one Brand Selection Component (see section 6.7) form of electronic cash may be
    offered. However, there may be several different protocols
    which may be used for use in the
     Payment Exchange. It contains same "brand" of electronic cash
  o the Merchant (Financial Institution) may use the results of the
    authentication to identify not only the consumer
     selecting a Payment Brand and Payment Protocol from but also the list
     provided in
    account from which the Brand List Component.

8.4.6 Authentication Request Block

  The Authentication Request Block (see section 7.4) withdrawal is to be made. If no single
    account can be identified, then it must contain be obtained by other
    means. For example:
    - 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 consumer could specify 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 account number prior to the following
  components:
  o  zero
      Baseline Withdrawal IOTP Transaction starting, or one Authentication Data Component (see section 6.2) An
     Authentication Data Component is required
    - the consumer could have been identified earlier, for each Payment
     Exchange, where its Payment Component  contains example using
      a Baseline Authentication IOTP Transaction, and an AuthDataRef
     attribute
  o  one Order Component (see section 6.4) which contains details
     about account
      selected from a list provided by the refund, Financial Institution.

  o a Baseline Withdrawal without an authentication might be used:
    - if a previous IOTP transaction, for example a Baseline Deposit or
      a Baseline Authentication, authenticated the amount being refunded consumer, and
     any conditions which might apply
  o  one Payment Component  (see section 7.2) which contains
     information about a
      secure channel has been maintained, therefore the authenticity of
      the consumer is known
    - if authentication is achieved as part of a proprietary payment which
      protocol and is to be made
  o  one Delivery Component (see section 6.12) with therefore included in 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 Payment Document
      Exchange
    - if authentication of the Baseline Refund Offer Response is being digitally signed then consumer has been achieved by some other
      means, for example, by using a
  Signature Block must be included pass phrase, or a proprietary
      banking software solution.

  8.1.11 Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange Transaction uses Payment Document
  Exchanges to support the exchange of value in one currency obtained
  using one payment method with value in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18).
  The Signature Component contains hashes 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 following XML elements: first
    payment could be a _dollar SET Payment_ using a credit card
    with the second payment being a download of Visa Cash e-cash in
    dollars.

  o foreign exchange using the Transaction Reference Block (see section 3.3) for same payment method. For example the IOTP
     Message which contains
    payment could be an upload of Mondex value in British Pounds
    and the second a download of Mondex value in Euros

  o foreign exchange using different payment methods. For example
    the first usage payment could be a SET payment in Canadian Dollars
    followed a download of GeldKarte in Deutchmarks.

  The Baseline Value Exchange uses the following Document Exchanges:

  o an optional Authentication Document Exchange (see section
    8.1.1)

  o an Offer Response
     Block within the IOTP Transaction. It contains information
     that identifies the IOTP Message Document Exchange (see section 8.1.2), which provides
    details of what values and currencies will be exchanged, and IOTP Transaction

  o  the Transaction Id Component two Payment Document Exchanges (see section 3.3.1) 8.1.3) which
     globally uniquely identifies carry
    out the two payments involved.

  The way in which these Document Exchanges may be combined together is
  illustrated by the diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START -----------------------------------------------------
   |                                                         v
   |                                                ----------------
   |                                               | AUTHENTICATION |
   |                                                ----------------
    --------------------------------------               |
                    |                     |              |
                    |      -------------- | -------------
                    v      v              v      v
               -------------------     -----------------
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |
              |       OFFER       |   |      OFFER      |
               -------------------     -----------------
                     |                        |
                     |                        |
                     |                        |
                     |     -------------------
                     v    v
                   ---------           --------------
                  | PAYMENT |         | PAYMENT WITH |
                  | (first) |         |   DELIVERY   |
                   ---------           --------------
                       |
                        ----
                            v
      ----------        ---------
     | DELIVERY |      | PAYMENT |
     |          |      | {second)|
      ----------        ---------
                            |
                             -----------------------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

            Figure 31 Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange IOTP Transaction occurs in two basic
  forms:

  o Brand Dependent Value Exchange. Where the following components content of the Offer Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - offer,
    for example the Payment Component
     - all rate at which one form of value is exchanged
    for another, is dependent on the Organisation Components present, payment brands and
     - protocols
    selected by the Delivery Component,
     - any Trading Role Data Components consumer, and
  o Brand Independent Value Exchange. Where the following components content of the TPO Block :
     -
    offer is not dependent on the Protocol Options Component, payment brands and
     - protocols
    selected.

  [Note]   In the Brand List Component

  If above the Baseline Refund role is a Baseline Refund with Authentication then Merchant even though the Signature Component additionally contains a hash of
           organisation carrying out the following:
  o Value Exchange may be a Bank
           or some other Financial Institution. This is because the Brand Selection Component contained
           Bank is acting as a merchant in the TPO Selection
     Block.

8.4.10 Payment Request Block that they are making an
           offer which the Consumer can either accept or decline.
  [Note End]

  The Payment Request TPO Block (see section 7.6) contains:
  o  the following components copied from the and Offer Response Block:
     - the Status Component
     - Block may only be combined into the Authentication Data Component
  same IOTP Message 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 content of the Offer Response Block if the refund is does not
  change as a Baseline
       Refund with Authentication, or
     - created by the Consumer, containing result of selecting the payment brand brands 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
  protocols to be used (see in the Payment Method supplement to
     determine if this is needed). Value Exchange.

  BASELINE VALUE EXCHANGE SIGNATURES

  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 use of signatures to carry out
  the Payment (see section 5 Security Considerations).

8.4.11 Signature Block (Payment Request)

  If ensure the integrity of a Baseline Refund Offer Response Block was signed then the IOTP
  Message that contains Value
  Exchange is illustrated by the Payment Request Block must also contain a diagram below.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

Signature generated                  IotpMsg (TPO)
by Merchant ensures                  - Trans Ref Block with a copy
integrity of the "Offer Response" Offer -------->  -  - Signature
  Component.

8.4.12 Payment Exchange Block

  The Payment Exchange
                                 |   - TPO Block (see section 7.7) contains:
  o  one Payment Scheme Component (see section 6.9) which contains
     payment method specific data. See              MERCHANT
                                 |   - Offer Response Block
                                 |
Signature generated by           |
the Payment Method
     supplement for Handler of           |   IotpMsg (Pay Resp 1)
the first payment method being used to determine what
     this should contain.

8.4.13 Payment Response Block

  The Payment Response binds          |   - Trans Ref Block (see section 7.8) contains:
  o  one Payment         PAYMENT
Pay 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 first ----->  -> - Signature Block -----   HANDLER
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 Offer                 - Pay 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 1 |    1
                                                            |
Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated generated by the
  SignedPayReceipt attribute of                                      |
the Payment Component Handler of           IotpMsg (Pay Resp 2)       |  PAYMENT
the Offer
  Response second payment binds           - Trans Ref Block being set to True, then        |  HANDLER
the IOTP Message that contains second payment to 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 <------     2
first payment and therefore        - Pay Response Block (see section 3.3) for 2
to the IOTP
     Message which contains the first usage Offer

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

              Figure 32 Baseline Value Exchange Signatures
  8.1.12 Valid Combinations of Document Exchanges

  The following diagram illustrates the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within the
     Transaction Reference Block that globally uniquely identifies data conditions in the various
  IOTP Transaction,
  o  the Payment Receipt Component from the Payment Response Block
  o  the other Components referenced messages which can be used by the PayReceiptRefs
     attribute (if present) of the Payment Receipt Component,
  o  the Status Component from the Payment Response Block,
  o  any a Consumer Trading Role Data Components in the Payment Response
     Block, and
  o  the "Offer Response" Signature Component from to
  determine whether the Payment combination of Document Exchanges are valid.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

START
  |
  v
Auth Request Block if present.

8.5 Baseline Withdrawal in  =TRUE
 first IOTP Transaction

  The Baseline Withdrawal Message ? ---------------------------------------
   | = FALSE                                                 |
   v                                                         v
Offer Response Block in                             ----------------
  first IOTP Transaction supports the withdrawal of
  electronic cash from a Financial Institution.

  [Note]   The Financial Institution has, Message ?                             | AUTHENTICATION |
   |=TRUE         |=FALSE                           ----------------
   |              |                                        |
   |              |                                        v
   |                ----------------------       TPO & Offer Response
    -------------                         |    Blocks in last IOTP terminology, a role Msg
                 |                        |     |=TRUE        |=FALSE
                 |                        |     |             v
                 |          ------------- | ----       TPO Block only i
                 |         |              |           last IOTP Message
                 |         |              |          of merchant in that a service (i.e. a withdrawal Authentication
                 |         |              |          |=TRUE   |=FALSE
                 v         v              v          v        |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                       |                   |                  |
                       v                   v                  |
                    Offer Response Block contains             |
                          Delivery Component ?                |
                         |=FALSE        |=TRUE                |
                      ---               v                     |
                     |        Value of
           electronic cash) is being offered in return for a fee, for
           example bank charges DelivAndPayResp        |
                     |    attribute of some kind. The term "Financial
           Institution" is used in the diagrams Delivery Component ?   |
                     |    |=FALSE         |=TRUE              |
                     |    |               |                   |
                     v    v               v                   |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                       |                      |               |
                       v                      |               |
         Offer and Response Block contains                    |
               Delivery Component ?                           |
               |=TRUE           |=FALSE                       |
               |                v                             |
               |         Two Payment Components               |
               |      present in the text for
           clarity.
  [Note End]

  The Baseline Withdrawal Offer Response Block?        |
               |           |=TRUE             |=FALSE         |
               v           v                  |               |
      ----------        ---------             |               |
     | DELIVERY |      | PAYMENT |            |               |
     |          |      | {second)|            |               |
      ----------        ---------             |               |
           |                |                 |               v
            ----------------------------------------------> STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

            Figure 33 Valid Combinations of Document Exchanges

1) If first IOTP Transaction consists Message of the following
  Trading Exchanges:
  o an optional IOTP Transaction contains an
   Authentication Exchange (see section 2.2.4),
  o Request then:

   a) IOTP Transaction includes an Offer Authentication Document Exchange
      (see section 2.2.1), 8.1.1). (Note 1)

   b) If the last IOTP Message of the Authentication Document
      Exchange includes a TPO Block and
  o an Offer Response Block
      then:

      i) IOTP Transaction includes a Payment Brand Independent Offer
         Document Exchange (see section 2.2.2).

  These Trading Exchanges are implemented by a set of predefined 8.1.2.2). (Note 2)

   c) Otherwise, if the last IOTP
  Messages (see section o) which are exchanged between Message of the Trading Roles Authentication
      Exchange includes a TPO Block but NO Offer Response Block,
      then:

      i) IOTP Transaction includes a Brand Dependent Offer Document
         Exchange (see section 2.1). Each 8.1.2.1). (Note 2)

   d) Otherwise (Authentication Status IOTP Message contains Trading Blocks (see
  section 7) which contain of 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
      Authentication Document Exchange contains neither a TPO Selection Block
  o
      but nor an Offer Response Block)

      i) IOTP Transaction consists of just an Authentication
         Document Exchange. (Note 3)

2) Otherwise (no Authentication Request Block
  o in first IOTP Message):

   a) IOTP Transaction does not include an Authentication Document
      Exchange (Note 2)

   b) If first IOTP Message contains an Offer Response Block, then:

      i) the IOTP Transaction contains a Brand Independent Offer
         Document Exchange (Note 2)

   c) Otherwise (no Offer Response Block
  o in first IOTP Message):

      i) the IOTP Transaction includes a Brand Dependent Offer
         Document Exchange (Note 2)

3) If an Offer Response Block
  o  Payment Request exists in any IOTP message then:

   a) If the Offer Response Block
  o contains a Delivery Component
      then:

      i) If the DelivAndPayResp attribute of the Delivery Component
         is set to True, then:

         .  the IOTP Transaction consists of a Payment And Delivery
            Document Exchange Block
  o (see section 8.1.5) (Note 4)

      ii) otherwise (the DelivAndPayResp attribute of the Delivery
         Component is set to False)

         .  the IOTP Transaction consists of a Payment Document
            Exchange (see section 8.1.3) followed by a Delivery
            Document Exchange (see section 8.1.4) (Note 4)

   b) otherwise (the Offer Response Block
  o  Signature does not contain a
      Delivery Component)

      i) if the Offer Response Block

8.5.1 Baseline Withdrawal Variations

  The Baseline Withdrawal contains just one Payment
         Component, then:

         .  the IOTP Transaction occurs in contains just one Payment Document
            Exchange (Note 5)

      ii) if the Offer Response Block contains two basic forms:
  o  Baseline Withdrawal with Authentication. Where Payment
         Components, then:

         .  the Consumer
     making IOTP Transaction contains two Payment Document
            Exchanges. The StartAfter attribute of the withdrawal Payment
            Components is authenticated before used to indicate which payment occurs
            first (Note 6)
      iii) if the withdrawal Offer Response Block contains no or more than two
         Payment Components, then there is made, and
  o  Baseline Withdrawal without Authentication. Where the Consumer an error

4) Otherwise (no Offer Response Block) there is not authenticated before an error.

  The following table indicates the withdrawal is made.

  In both these forms it is assumed that types of IOTP Transactions which can
  validly have the conditions indicated above.

Ref                     IOTP Transaction Validity

 1. Any Payment Brand being used is
  determined before the Baseline Withdrawal transaction starts. This
  means that Brand Selection is limited to and Authentication IOTP Transaction

 2. Any Payment Protocol selection
  only.

8.5.2 and Authentication IOTP Transaction except Baseline Withdrawal
    Authentication

  In

 3. Either Baseline Authentication, or a Baseline Purchase, Refund,
    Deposit, Withdrawal or Value Exchange with a failed
    Authentication

 4. Baseline Purchase only

 5. Baseline Purchase, Refund, Deposit or Withdrawal

 6. Baseline Value Exchange only

  8.1.13 Combining Authentication Transactions with other Transactions

  In the previous sections an Authentication Document Exchange
  occurs before the is shown
  preceding an Offer Document Exchange containing the details as part of a single IOTP
  Transaction with the
  withdrawal is provided by the Financial Institution.

  In Baseline Withdrawal without Authentication, there same OTP Transaction Id.

  It is no also possible to run a separate Authentication Exchange and the Financial Institution provides details
  about the withdrawal immediately Transaction at the start of the
  any point, even in parallel with another 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. Typically
  this will be used:

  o by a Consumer decides to                   2. The Financial Institution
  withdraw electronic                     sets the payment brand and
    cash and sends      -------------->    decides authenticate a Payment Handler or a Delivery
    Handler, or

  o by a Payment Handler or Delivery Handler to authenticate a
    Consumer.

  In outline the protocols basic process consists of:

  o the Trading Role that decides it wants to
 information about how     Withdrawal         offer, generates carry out an
much to withdraw to the   Information    Authentication Request Block
Financial Institution,   (outside scope    containing challenge data
    e.g. using HTML
    authentication of OTP)            and another role suspends the method of
                                          authentication and sends current IOTP
    transaction being carried out
  o a stand-alone Authentication transaction is then carried out.
    This may, at implementer's option, be linked 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 original
    IOTP Transaction using a Brand      Authentication    Response Block
 Selection Component, generates        Request
   an Authentication Response Related To Component and sends back to (see section
    3.3.3) in the
     Financial Institution.
     |
     v
  OTPMsg:                        4. The Financial Institution checks
 Trans Ref   ---------------> Transaction Reference Block.

  o if the Authentication Response against
Block; Auth  TPO Selection  & transaction is successful, then the challenge data in
    original IOTP Transaction is restarted

  o if the
  Response    Authentication Authentication Request Block, uses fails then the
 Block; TPO      Response       information to identify original IOTP Transaction
    is cancelled.

  For example, a Consumer could:

  o authenticate the consumer,
 Selection                        generates Payment Handler for a Payment between
    receiving 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 a Merchant and before sending
    the Offer Response      Offer Response     Offer Response
 Block to create a Pay Payment Request                             Block
Block and sends to that Payment Handler

  o authenticate a Delivery Handler for a Delivery between
    receiving the Payment Response from a Payment Handler together with optional
        Signature Block
               |
               v                 Note that and
    before sending the Financial Institution
           CONTINUED              has, in OTP terminology, Delivery Request

  A Payment Handler could authenticate a role of
                                             "Merchant".

  Figure 32 Baseline Withdrawal with Authentication
  Note that Consumer after receiving the above diagram:
  o  describes
  Payment Request and before sending the general case where next Payment related message.

  A Delivery Handler could authenticate 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 Consumer after receiving the same "brand" of electronic cash
  o
  Delivery Request and before sending the financial institution Delivery Response.

  [Note]   Some Payment Methods may use the results of the carry out an authentication to identify not only the consumer but also within
           the
     account from which Payment Exchange. In this case the withdrawal is information required
           to be made. If no single
     account can be identified, then it must be obtained by other
     means. For example:
     - the consumer could specify carry out the account number authentication will be included in the initial
       dialogue (see step 1), or
     - the consumer could have been identified earlier, for example
       using a Baseline Authentication Payment
           Scheme Components.

           In this instance IOTP Transaction, and aware application will not be aware
           that an account
       selected from a list provided by authentication has occurred since the Financial Institution.

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

       CONSUMER                OTP MESSAGE             FINANCIAL
                                                      INSTITUTION
1. Consumer decides Payment Scheme
           Components that contain authentication data will be
           indistinguishable from other Payment Scheme Components.
  [Note End]

  8.2 Infrastructure Transactions

  Infrastructure Transactions are designed to                     2. Financial Institution
  withdraw electronic                      decides sets the payment
    cash and sends       ------------>     brand and decides support inquiries on
  whether or not a transaction has succeeded or a Trading Role's servers
  are operating correctly. There are two types of transaction:

  o a Transaction Status Inquiry Transaction which provides
    information about how    Withdrawal        protocols to offer for
much to withdraw, etc.    Information      withdrawal, generates an
   to on the Financial        (outside          Offer Response Block
Institution, e.g. using  scope status of OTP)   containing information about
         HTML                            the withdrawal, an optional
                                          signature existing or complete IOTP
    transaction, and sends

  o Ping Transaction that enables one IOTP aware application to
    determine if the
                                                   Consumer
                                                        |
                                                        v
  3. OTP IOTP 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 at another Trading Role
    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 operating 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 verify whether or not signatures can be
    handled.

  Each of
                                                 "Merchant".

  Figure 33 these is described below

  8.2.1 Baseline Withdrawal without Authentication Transaction Status Inquiry IOTP Transaction

  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 Transaction Status Inquiry provides information on
  the authenticity status of an existing or complete IOTP transaction.

  The Trading Blocks used by the consumer is known Baseline Transaction Status Inquiry
  Transaction are:

  o  when authentication is achieved an Inquiry Request Trading Block (see section 7.12), and

  o an Inquiry Response Trading Block (see section 7.13).

  [Note]   Note that:

           o Consumer Inquiries on Authentication transaction are not
             supported.

           o Authentication of Consumers as part of a proprietary
     payment protocol and an inquiry is therefore included not
             supported in the Payment
     Exchange
  o  when authentication Baseline version of the consumer has been achieved by some
     other means, for example, by using a pass phrase, or IOTP.
  [Note End]

  WHICH TRADING ROLES CAN RECEIVE INQUIRY REQUESTS

  The Consumer can send a
     proprietary banking software solution.

  IOTP aware applications supporting Transaction Status Inquiry Block to the Consumer
  appropriate Trading Role must
  check for after the existence of an Authentication Request Block in following events have occurred:

  o to the
  first IOTP Message Merchant, after sending TPO Selection Block,

  o 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, Handler, after sending Payment Request Block,

  o to the sequence
  of Delivery Handler, after sending Delivery Request Block.

  [Note]   IOTP Messages illustrated in Figure 34 occurs. These are the same
  whether or does not an Authentication of support sending Inquiry Requests to the
           Consumer has occurred. Note
  that these continue where since the previous diagrams (Figure 32 consumer may not be on-line to receive
           and Figure
  33) finish.

        CONSUMER              OTP MESSAGE          PAYMENT HANDLER
   3/5. process them.

  [Note End]

  If the Consumer generates Pay is inquiring on transaction that is not yet complete,
  it should send the Inquiry 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 Trading Role to which
  it sent the last IOTP message. If the Consumer and stops
                                                         |
                                                         v
   9. Consumer checks Pay                    OtpMsg: Trans Ref Block;
 Response is OK. Optionally   <------------       Signature Block
  keeps information inquiring on OTP       Payment        Pay Response a
  transaction which is complete, there are two alternatives in deciding
  the Trading Roles that the Inquiry Request 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 should be sent to:

  o the Baseline Withdrawal Consumer IOTP
  Transaction defines software can ask the contents end user to determine
    the type of each inquiry they want to make, or

  o the Consumer IOTP software can send the inquiry request message
    to all the Trading Block. Roles that were involved in the IOTP
    transaction.

  For most the second case above, how the Consumer IOTP Aware Application
  displays the inquiry response data received from each Trading Blocks, Role is
  up to each implementation.

  TRANSACTION STATUS INQUIRY TRANSPORT SESSION

  For a Transaction Status Inquiry on an ongoing transaction, the content does not alter
  Consumer shall establish with a Trading Role, a different transport
  session from 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 ongoing transaction. For a Transaction Status Inquiry
  on a past transaction, how the IOTP module on the software at the following
  Trading Components:
  o  one Protocol Options Component which defines Role is started upon the options which
     apply receipt of Inquiry Request message is
  defined in each Mapping to Transport supplement for IOTP.

  TRANSACTION STATUS INQUIRY ERROR HANDLING

  Errors in a Transaction Status Inquiry can be categorised into one the whole IOTP Transaction. See Section 6.1.
  following three cases:

  o  one Brand List Component Business errors (see section 6.6) which contains the
     payment brand and protocols which may be selected for use 4.2) in the Payment Exchange original (inquired)
    messages

  o  Organisation Components Technical errors (see section 6.5) with the following
     roles: 4.1) - the Merchant who is accepting the withdrawal both IOTP and payment
    scheme specific ones - in the Consumer who is making the withdrawal
     - original IOTP (inquired) messages

  o Technical errors in the PaymentHandler for message containing the payment.

8.5.5 TPO Selection Inquiry Request
    Block itself

  The TPO Selection following outlines what the software should do in each case
  BUSINESS ERRORS IN THE ORIGINAL MESSAGES

  Return an Inquiry Response Block (see section 7.2) is only used by Baseline
  Withdrawal with Authentication. It contains:
  o  one Brand Selection containing the Status Component (see section 6.7) for use 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
     Payment Exchange. It contains original message.

  TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK

  Return an Error message. That is, send back an Error Block containing
  the results Error Code (see section 6.19.2) which describes the nature of the consumer
     selecting a Payment Brand
  error in the Inquiry Request message.

  INQUIRY TRANSACTION MESSAGES

  The following Figure outlines the Baseline IOTP Transaction Status
  Inquiry processes on both Consumer and Service Provider sides.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

         CONSUMER              IOTP MESSAGE         TRADING ROLE
 1. The Consumer decides to inquire                     (Merchant,
   on an IOTP transaction by, for                    Payment Protocol from Handler,
example, clicking the list
     provided in inquiry button                 Delivery Handler
of the Brand List Component.

8.5.6 Authentication IOTP Aware Application. This                    or Financial
   will then generate an Inquiry                       Institution)
  Request Block and send it to the
     appropriate Trading Role.
        |
        v
IotpMsg: Trans Ref                  2. The Authentication Trading Role checks the
  Block; Inquiry   ---------->  transaction status of the transaction
  Request Block (see section 7.4) must contain      Inquiry     that is being inquired upon by using
                     Request     the
  following Trading Component:
  o  one Authentication Data Transaction Id Component (see section 6.2)

8.5.7 Authentication 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 Authentication IOTP Aware                           IotpMsg: Trans Ref
 Application displays the    <----------------     Block; Inquiry
 status information to the   Inquiry Response      Response Block
         end user
             |
             v
           STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

              Figure 34 Baseline Transaction Status Inquiry

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

  TRANSACTION REFERENCE BLOCK

  The Consumer must use the same Transaction Id Component (see section 7.5) must contain
  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
  following Trading Component:
  o  one Authentication Response 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 6.3).

8.5.8 Offer Response Block 3.4.1).

  INQUIRY REQUEST BLOCK

  The Offer Response Inquiry Request Block (see section 7.3) must contain 7.12) contains the following
  components:

  o  zero or one Authentication Data Components Inquiry Type Component (see section 6.2)
     An Authentication Data Component 6.16). This identifies
    whether the inquiry is required for each Payment
     Exchange, where its Payment Component contains on an AuthDataRef
     attribute offer, payment, or delivery.

  o zero or one Order Payment Scheme Component (see section 6.4) which contains details
     about the withdrawal, 6.9). This is
    for example encapsulating payment scheme specific inquiry messages for
    inquiries on payment.

  INQUIRY RESPONSE BLOCK

  The Inquiry Response Block (see section 7.13) contains the amount being withdrawn
     and any fees which might apply following
  components:

  o one Payment Status Component (see section 7.2) which contains 6.14). This component hold
    the status information about on the payment which is to be made inquired transaction,

  o zero or one Delivery Component (see section 6.12) with Payment Scheme Components. These contain for
    encapsulated payment scheme specific inquiry messages for
    inquiries on payment.

  8.2.2 Baseline Ping IOTP Transaction

  The purpose of the DelivExch
     attribute set Baseline IOTP Ping Transaction is to False.

  The Offer Response Block may also contain one or more enable IOTP
  aware application software to determine if the IOTP aware application
  at another 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. operating and verifying whether or not
  signatures can be handled.

  The term "Financial Institution" is Trading Blocks used in
           the diagrams and in the text for clarity.
  [Note End]

8.5.9 Signature Block (Offer Response)

  If by the Baseline Withdrawal Offer Ping IOTP Transaction are:

  o a Ping Request Block (see section 7.14)

  o a Ping Response is being digitally signed
  then Block (see section 7.15), and
  o a Signature Block must be included in the same IOTP message that
  contains an "Offer Response" Signature Component (see section 6.18). 7.16).

  PING MESSAGES

  The Signature Component contains hashes of the following XML elements:
  o figure outlines the Transaction Reference Block (see section 3.3) for message flows in the Baseline IOTP
     Message which contains the first usage of the Offer Response
     Block within
  Ping Transaction.

*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

     IOTP TRADING ROLE         IOTP MESSAGE       IOTP TRADING ROLE
1. The IOTP Aware Application in an
IOTP Trading Role decides to  check
   whether the counterparty IOTP Transaction.
 application is up and running. It contains information
     that identifies
generates a Ping Block and optional
 Signature Block and sends them to
    the other IOTP Message and Trading Role.
                 |
                 v
IotpMsg: Trans Ref -------->  2. The IOTP Transaction
  o  the Transaction Id Component (see section 3.3.1) Trading Role which
     globally uniquely identifies the IOTP Transaction
  o  the following components of receives
   Block; Ping        Ping       the Offer Ping Request generates a Ping
  Request Block     Request      Response Block:
     - the Authentication Data Component if present
     - the Order Component
     - the Payment Component
     - all the Organisation Components present
     - and sends it back to the Delivery Component,
     - any Trading Role Data Components
  o
                                sender of the following components original Ping Request.
                                                       |
                                                       v
  3. The original sender of the TPO Block :
     -                    IotpMsg: Trans Ref
Ping Request checks the Protocol Options Component, returned   <------------      Block; Ping
     Ping Response and
     - the Brand List Component

  If the takes       Ping Response     Response Block
appropriate action, if necessary
                |
                v
              STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                     Figure 35 Baseline Withdrawal Ping Messages

  The verification that signatures can be handled is a Baseline Withdrawal with
  Authentication then indicated by the Signature Component additionally contains a
  hash
  sender of the following:
  o  the Brand Selection Component contained in the TPO Selection
     Block.

8.5.10 Payment Request Block

  The Payment Ping Request Block (see section 7.6) contains: including:

  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 that identify itself and the roles of: Merchant intended
    recipient of the Ping Request Block, and
       PaymentHandler

  o a Signature Block that signs data in the  following component from Ping Request.

  In this way the TPO Block:
     - receiver of the Brand List Component Ping Request:

  o  one Brand Selection Component either:
     - copied from the Offer Response Block if the withdrawal knows who is a
       Baseline Withdrawal with Authentication, or
     - created by the Consumer, containing sending the payment brand Ping Request and
       payment protocol selected, if can therefore verify
    the withdrawal is a Baseline
       Withdrawal without Authentication
  o  one Payment Scheme Component (see section 6.9) if required by Signature on the payment method used (see Request, and

  o knows who to generate a signature for on the Payment Method supplement 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
     determine if this is needed).

  The Payment the
  sender of a Ping Request Block may message when it is received.

  A Baseline IOTP Ping request can also contain one or more 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
  Data Components (see section 6.16).

  Payment Handlers can send a Ping request to any other IOTP
  Trading Role at any time it wants. A Ping message has its own
  OtpTransId, which is different from other IOTP transactions.

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

  TRANSACTION REFERENCE BLOCK

  The OtpTransId of a Ping transaction should check that they be different from any
  other IOTP transaction.

  PING REQUEST BLOCK

  If the Ping Transaction is anonymous then no Organisation Components
  are authorised to carry out included in the Payment Ping Request Block (see section 5 Security Considerations).

8.5.11 Signature Block (Payment Request) 7.7).

  If the Baseline Withdrawal Offer Response Block was signed Ping Transaction is not anonymous then the
  IOTP Message that Ping Request Block
  contains Organisation Components for:

  o the Payment sender of the Ping Request Block must also contain
  a Block, and

  o the verifier of the Signature Block with a copy Component
  If Organisation Components are present, then it indicates that the
  sender of the "Offer Response" Ping Request message has generated a Signature
  Component.

8.5.12 Payment Exchange Block Block.
  The Payment Exchange signature block must be verified by the Trading Role that receives
  the Ping Request Block.

  SIGNATURE BLOCK (PING REQUEST)

  The Ping Request Signature Block (see section 7.7) contains: 7.16) contains the
  following components:

  o one Payment Scheme Signature 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 6.17)

  o one or more Certificate Components, if required.

  PING RESPONSE BLOCK

  The Payment Ping Response Block (see section 7.8) contains:
  o  one Payment Receipt Component (see section 6.10) which 7.15) contains scheme specific data which can be used to verify the
     payment occurred following
  component:

  o  one Payment Scheme the Organisation Component (see section 6.9) if required
     which contains payment method specific data. See of the Payment
     Method supplement for sender of the payment method being used to
     determine what this should contain Ping Response
    message

  If the Ping Transaction is not anonymous then the Ping Response
  additionally contains:

  o copies of the "Offer Response" Signature Component (see section 6.18)
     from Organisation Components contained in the Payment Ping
    Request Block if present Block.

  SIGNATURE BLOCK (PING RESPONSE)

  The Offer Ping Response Signature Block may also contain:
  o  a Payment Note Component (see section 6.11)
  o 7.16) contains the
  following components:

  o one Signature Component (see section 6.17)

  o one or more Trading Role Data Components (see Certificate Components, if required.

  9. Retrieving Logos

  This section 6.16).

8.5.14 Signature Block (Payment Response)

  If a signed Payment Receipt is being provided, indicated describes how to retrieve logos for display by IOTP aware
  software using the
  SignedPayReceipt Logo Net Locations attribute of the Payment Component of the Offer
  Response Block being set to True, then contained in the IOTP Message that contains Brand
  Element (see section 6.6.1) and the Payment Response Block must also contain a Signature Block with a
  "Payment Receipt" Signature Organisation Component which contains hashes (see
  section 6.5).

  The full address of the
  following: 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 Transaction Reference Block LogoNetLocn attribute in
    the Brand Element (see section 3.3) for 6.6.1) or the IOTP
     Message which contains Organisation
    Component. Note that:
    - the first usage content of this attribute is dependent on the Payment Response
     Block,
  o  the Transaction Id Component (see section 3.3.1) within Transport
      Mechanism (such as  HTTP) that is used. See the
     Transaction Reference Block Transport
      Mechanism supplement,
    - implementers should check that globally uniquely 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 IOTP Transaction, size of the logo,

  o Logo_color_depth identifies the Payment Receipt Component from colour depth of the Payment Response Block logo

  o "GIF" indicates that the other Components referenced logos are in GIF format

  Logo_size and Logo_color_depth are specified by the PayReceiptRefs
     attribute (if present) implementer of the Payment Receipt Component,
  o
  IOTP software that is retrieving the Status Component from logo depending on the Payment Response Block,
  o  any Trading Role Data Components size and
  colour that they want to use.

  9.1 Logo Size

  There are five standard sizes for logos. The sizes in the Payment Response
     Block, pixels and
  o the "Offer Response" Signature Component from
  corresponding values for Logo Size are given in the Payment
     Request Block if present.

8.6 Baseline table below.

          Size in     Logo Size
          Pixels        Value Exchange IOTP Transaction
       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 Baseline Value Exchange Transaction uses Payment Exchanges (see
  section 2.2.2) to support colour depth (including
  bits per pixel) and the exchange of value in one currency
  obtained using one payment method with corresponding value for Logo_Color_Depth are
  given 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 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
     credit card logo with the second Payment Exchange being a download default
  colour depth of DigiCash e-cash in dollars.
  o  foreign exchange using the same payment method. For example
     the payment could 256 colours will be an upload of Mondex value in French
     Francs and the second a download of Mondex value in British
     Pounds retrieved.

  9.3 Logo Net Location Examples

  If Logo Net Location was set to "ftp://logos.xzpay.com", then:

  o  foreign exchange using different payment methods. For example
     the first payment could be a SET payment in Euros followed "ftp://logos.xzpay.com/medium.gif" would retrieve a
     download of GeldKarte in Deutchmarks.

  The Baseline Value Exchange uses three Trading Exchanges: medium size
    256 colour logo

  o  an Offer Exchange (see section 2.2.1) "ftp://logos.xzpay.com/small4.gif" would retrieve a small size
    16 colour logo
  [Note]   Organisations which provides details
     of what values make logos available for use with IOTP
           should always make available "small" and currencies will be exchanged, "medium" size logos
           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 use the Trading Roles
  (see section 2.1). Each IOTP Message GIF format.
  [Note End]
  10. Brand List Examples

  This example 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 three examples of the Baseline Value Exchange IOTP
  Transaction are:
  o  Trading Protocol Options Block
  o  TPO Selection Block
  o  Offer Response Block XML for a Brand List
  Component. It covers:

  o  Payment Request Block a simple credit card based example

  o  Payment Exchange Block a credit card based brand list including promotional credit
    card brands, and

  o  Payment Response Block a complex electronic cash based brand list

  Note that:

  o  Signature Block

8.6.1 Baseline Value Exchange Variations

  The Baseline Value Exchange IOTP Transaction occurs in two basic
  forms: brand lists can be as complex or as simple as required

  o  Brand Dependent Value Exchange. Where the content of the
     offer, for all example the rate at which techniques described in this appendix can be
    included in one form of value is
     exchanged for another, brand list.

  10.1 Simple Credit Card Based Example

  This is dependent on the payment brands and
     protocols selected by the consumer, and a simple example involving:

  o  Brand Independent Value Exchange. Where the content of the
     offer is not dependent on the only major credit card 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 a single price in a TPO Block, single currency

  o  the Consumer selects a Payment Brand single payment handler, and Payment Protocol from
     the

  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 Component for each Including Promotional Brands

  An example of the payments in the Value
     Exchange a Credit Card based Brand List follows. It includes:

  o  the Consumer sends the selected two ordinary card association 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+ ) > two promotional credit
    card brands. The "*" indicates zero or more, and the "+" indicates promotional brands consist of one or more.

  If A occurred zero times loyalty
    based (British Airways MasterCard) which offers additional
    loyalty points 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 store based (Walmart) 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 offers 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
    discount on purchases over a letter certain amount

  o two payment protocols:
    - SET (Secure Electronic Transactions) see [SET], 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.
    - SCCD (Secure Channel Credit Debit) see [SCCD].

<BrandList ID='M1.2'
  XML:Lang='us-en'
  ShortDesc='Purchase ladies coat'
  PayDirection='Debit' >
  <Brand ID                 Identifier. This value of this attribute is unique
                   for each element.

IDREF              This value of this attribute matches the value of
                   some ='M1.3'
    BrandId='MC'
    BrandName='MasterCard'
    BrandLogoNetLocn='ftp:otplogos.mastercard.com'
    ProtocolAmountRefs='M1.7 M1.8'>
  </Brand>
  <Brand 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 ='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 this default value is not
                   specified, 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 application gives example
  above using SET and therefore getting double air miles, the pre-
                   determined attribute value.

'value' 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 'value specified following 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 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 value for ATT1 must be present as it discount on the price if the payment is "#REQUIRED" made in Mondex using
    British pounds or US dollars, and it must be either "A"

  o more than one payment handler is used for payments involving
    Mondex or "B" CyberCash

  o support for the XML document to be valid. For
  example:

<X Att1='B'> DataX </X>

12. 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. Open Trading Protocol Data Type Definition

  This section contains a copy of the XML DTD for the Internet 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).
  Protocols.

<!--
******************************************************
*                                                    *
* OPEN TRADING PROTOCOL DTD VERSION 1.0 1.0.1            *
*                                                    *
* Changes from version 0.9.9 1.0                           *
* - corrects typos in OTP Message and Added xmlns namespace attribute to OtpMessage    *
*      Payment Method Information component   element                                          *
* - adds "place holder" definitions of OtpSig and Added SenderTradingRoleRef to MsgId Component    *
*      OtpCert Components - Added Name attribute to PackagedContent element  *
* - adds Status Component Changed usage of PackagedContent in following    *
*   elements to the Delivery Request support multiple PackagedContent     *
*      block   occurences: AuthData, AuthResp, Order, Brand,    *
*   ProtocolAmount, PayProtocol, BrandSelBrandInfo,  *
*   BrandSelProtocolAmountInfo,                      *
*   BrandSelCurrencyAmountInfo, PaySchemeData,       *
*   PayReceipt, PaymentNote, Delivery, DeliveryData, *
*   DeliveryNote and TradingRoleData.                *
* - moves Changed the Status Component REQUIRED to IMPLIED on the start of the*           *      content
*   SenderNetLocn and SecureSenderNetLoc attributes  *
*   of the Offer Response Block to make it* ProtocolOptions component                 *
* - Changed TradingRole element by: adding Id        *      consistent with other Response
*   attribute, changing CancelNetLocn and Request ErrorLocn  *
*      blocks   attributes to Required from Implied, adding      *
*    - adds the Status Component to the Payment   ErrorLogNetLocn attribute                        *
*      Request Block - Removed PackagedContent from Payment Component   *
* - adds Removed the PayReceiptRefs AuthDataRef attribute to from the       *
*   Payment Receipt Component                                *
* - changes the Type Changed PayReceiptRefs attribute of the Content Attribute of Payment  *
*      the PackagedContent element   Receipt component to CDATA Implied from Required       *
*      NMTOKEN - Changed the permitted values of StatusType       *
*    - adds   attribute in the Trading Role Data Status Component and Type       *
*    - adds   attribute in the Trading Role Data Inquiry Type Component to the be    *
*   NMTOKEN to allow extra Status types to be defined*
* - Removed AuthData Component from the Offer Response, Payment Request, Payment        *
*   Response and Delivery Request Blocks Block                                   *
* - adds Payment Note Removed Org Component from the AuthReq Block     *
* - adds the Payment Note Removed Status Component to from the AuthResp Block *
*      response block - Added an AuthStatusBlk Block                     *
* - adds an Org Component to the Authentication Removed AuthData component from PayReqBlk        *
*      Request - Added a CancelBlk Block                          *
* - adds an Org Component and a Added Status Component  *
* to the Authentication Request Payment Instrument *
*   Customer Care Response Block                     *
* - adds a TradingRoleList and AuthenticationId A number of layout changes to improve appearance *
*      attributes - Removed references to the Authentication Data payment instrument customer*
*   care. Specifically: removed PayInstCCExchBlk,    *

*      Component   PayInstCCReqBlk, PayInstCCRespBlk, and           *
*   PayMethodInfo and reference to these             *
* - adds Authentication as a valid value of the Removed OtpSig and OtpCert components and        *
*      StatusType attribute of the Status Component   replaced with Signatures and Certificate         *
*   components based on DSIG proposal                *
* - removes ErrorNetLocn Added Algorithm Element to AuthData Block        *
* - Removed AuthMethod and CancelNetLocn attri- added AlgorithmRefs       *
*      butes from the Protocol Options Component   attribute to AuthData Block                      *
* - adds the CancelNetLocn Added SelectedAlgorithmRef attribute to the          *
*      Trading Role element   AuthResp Block                                   *
*                                                    *
* Copyright Open Trading Protocol Consortium ,1998 Internet Engineering Task Force 1998,99  *
* (note copyright will be assigned to IETF/ISOC)                                                    *
******************************************************

******************************************************
* OTP MESSAGE DEFINITION                             *
******************************************************
 -->

<!ELEMENT OtpMessage (TransRefBlk,
   ( TransRefBlk,
     SigBlk?,
     ErrorBlk?,
     ( AuthReqBlk |
       AuthRespBlk |
       AuthStatusBlk |
       CancelBlk |
       DeliveryReqBlk |
       DeliveryRespBlk |
       InquiryReqBlk |
       InquiryRespBlk |
       OfferRespBlk |
       PayExchBlk |
       PayReqBlk |
       PayInstCCExchBlk |
       PayInstCCReqBlk |
       PayInstCCRespBlk |
       PayRespBlk |
       PingReqBlk |
       PingRespBlk |
       TpoBlk |
       TpoSelectionBlk
     )*
   ) >
<!ATTLIST OtpMessage
  xmlns:iotp     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-03' >

<!--
******************************************************
* 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
 SenderTradingRoleRef NMTOKEN #IMPLIED
 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
 Name             NMTOKEN   #IMPLIED
 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   #IMPLIED
 SecureSenderNetLocn CDATA  #REQUIRED  #IMPLIED
 SuccessNetLocn     CDATA   #REQUIRED >

<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthData (PackagedContent)> (PackagedContent+, Algorithm+)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AuthMethod         NMTOKEN
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent) (PackagedContent*) >
<!ATTLIST AuthResp
 ID                 ID      #REQUIRED
 SelectedAlgorithmRef NMTOKEN #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent?) (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
 ID              ID      #REQUIRED
 TradingRole        NMTOKEN #REQUIRED
 CancelNetLocn      CDATA   #REQUIRED
 ErrorNetLocn       CDATA   #IMPLIED
 CancelNetLocn   #REQUIRED
 ErrorLogNetLocn 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) (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) (Debit | Credit) #REQUIRED >

<!ELEMENT Brand (PackagedContent?) (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?) (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?) (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) (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
 ID                 ID      #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

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

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

<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment (PackagedContent?) EMPTY >
<!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) (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 ConsumerPaymentId  CDATA   #IMPLIED
 PaymentHandlerPayId CDATA  #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent) (PackagedContent+) >
<!ATTLIST PayReceipt
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED
 PayReceiptRefs     NMTOKENS #REQUIRED #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent) (PackagedContent+) >
<!ATTLIST PaymentNote
  ID                ID      #REQUIRED
  ContentSoftwareId CDATA   #IMPLIED >

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

<!ELEMENT DeliveryData (PackagedContent?) (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) (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)         NMTOKEN #REQUIRED
 ElRef              NMTOKEN #REQUIRED
 ProcessState (NotYetStarted|InProgress|
     CompletedOk|Failed|ProcessError) (NotYetStarted | InProgress |
     CompletedOk | Failed | ProcessError) #REQUIRED
 CompletionCode     NMTOKEN #IMPLIED
 ProcessReference   CDATA   #IMPLIED
 StatusDesc         CDATA   #IMPLIED >

<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent) (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)               NMTOKEN #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) (AuthData?) >
<!ATTLIST AuthReqBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp, Org+, Status) Org*) >
<!ATTLIST AuthRespBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
 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 INQUIRY REQUEST BLOCK -->

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

<!-- PAYMENT INSTRUMENT CUSTOMER CARE EXCHANGE INQUIRY RESPONSE BLOCK -->
<!ELEMENT PayInstCCExchBlk (PaySchemeData) InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST PayInstCCExchBlk InquiryRespBlk
 ID                 ID      #REQUIRED
 LastReceivedOtpMsgRef NMTOKEN #IMPLIED
 LastSentOtpMsgRef  NMTOKEN #IMPLIED >

<!-- PAYMENT INSTRUMENT CUSTOMER CARE PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
 ID                 ID      #REQUIRED>

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

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

<!-- INQUIRY REQUEST CANCEL BLOCK -->
<!ELEMENT InquiryReqBlk CancelBlk (Status) >
<!ATTLIST CancelBlk
 ID                 ID      #REQUIRED >

<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION                   *
******************************************************
 -->

<!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures
  ID                ID      #IMPLIED >

<!--
******************************************************
* IOTP SIGNAUTRE COMPPONENT DEFINITION               *
******************************************************
 -->

<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
  ID                ID      #IMPLIED >

<!ELEMENT Manifest
  (Algorithm+,
   Digest+,
   Attributes?,
   OriginatorInfo,
   RecipientInfo+,
  )
<!ATTLIST Manifest
  LocatorHRefBase   CDATA   #IMPLIED >

<!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm
 ID                 ID      #REQUIRED
 type  (digest|signature|keyagreement) #IMPLIED
 name               NMTOKEN #REQUIRED >

<!ELEMENT Digest (Value) >
<!ATTLIST Digest
 LocatorHREF        NMTOKEN #REQUIRED
 DigestAlgorithmRef IDREF   #REQUIRED >

<!ELEMENT Attributes (Attribute+) >

<!ELEMENT Attribute ( #PCDATA ) >
<!ATTLIST Attribute
 type               NMTOKEN #REQUIRED
 critical  ( InquiryType, PaySchemeData? true | false ) #REQUIRED >

<!ELEMENT OriginatorInfo ANY >
<!ATTLIST InquiryReqBlk
 ID                 ID      #REQUIRED OriginatorInfo
 OriginatorRef      NMTOKEN #IMPLIED >

<!-- INQUIRY RESPONSE BLOCK -->

<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) RecipientInfo ANY >
<!ATTLIST InquiryRespBlk
 ID                 ID RecipientInfo
 SignatureAlgorithmRef IDREF #REQUIRED
 LastReceivedOtpMsgRef NMTOKEN
 SignatureValueRef  IDREF    #REQUIRED
 SignatureCertRef   IDREF    #IMPLIED
 LastSentOtpMsgRef  NMTOKEN
 RecipientRefs      NMTOKENS #IMPLIED >

<!-- PING REQUEST BLOCK -->

<!ELEMENT PingReqBlk (Org*)> Parameter ANY >
<!ATTLIST PingReqBlk
 ID                 ID      #REQUIRED> Parameter
 type               PCDATA  #REQUIRED >

<!-- PING RESPONSE BLOCK
******************************************************
* IOTP CERTIFICATE COMPPONENT DEFINITION             *
******************************************************
 -->
<!ELEMENT PingRespBlk (Org+)> Certificate (
  IssuerAndSerialNumber
  ( Value | Locator ) )>
<!ATTLIST PingRespBlk Certificate
 ID                 ID      #REQUIRED
 PingStatusCode (Ok|Busy|Down) #REQUIRED
 SigVerifyStatusCode (Ok|NotSupported|Fail)      #IMPLIED
 xml:lang
 type               NMTOKEN #IMPLIED
 PingStatusDesc     CDATA   #IMPLIED>

<!-- SIGNATURE BLOCK --> #REQUIRED >

<!ELEMENT SigBlk (OtpSig+, OtpCert*) IssuerAndSerialNumber EMPTY >
<!ATTLIST SigBlk
 ID                 ID IssuerAndSerialNumber
 issuer             CDATA   #REQUIRED
 number             CDATA   #REQUIRED >

<!-- ERROR BLOCK -->

<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) Value ( #PCDATA ) >
<!ATTLIST ErrorBlk
 ID Value
 id                 ID      #IMPLIED
 encoding ( base64 | none ) #REQUIRED >

<!-- placeholders for content models to come from XMLSIG -->
<!ELEMENT OtpSig (#PCDATA)>

<!ELEMENT OtpCert (#PCDATA)>

13. Locator EMPTY>
<!ATTLIST Locator
 href               CDATA   #REQUIRED >
  12. Glossary

  This section contains a glossary of some of the terms used within this
  specification in alphabetical order.

        NAME                           DESCRIPTION

Authenticator       The organisation Organisation which is requesting the
                    authentication of another organisation, Organisation, and

Authenticatee       The organisation Organisation being authenticated by
                   authenticated by an
                    Authenticator

Business Error      See Status Component.

Brand               A Brand is the mark which identifies a
                    particular type of Payment Instrument. A list of
                    Brands are the payment options which are
                    presented by the
  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 a company uses their own Brand in
                      conjunction with, typically, a payment
                      association Brand.

Consumer            The person or organisation Organisation which is to receive the benefit
                    of and typically pay for the goods or services services.

Customer Care       An Organisation that is providing customer care
Provider            typically on behalf of a Merchant. Examples of
                    customer care include, responding to problems
                    raised by a Consumer arising from an IOTP
                    Transaction that the Consumer took part in.

        NAME                           DESCRIPTION

Delivery Handler    The entity Organisation 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

Exchange Block      An IOTP Message Exchange Block is sent between the two
                    Trading Roles involved in a collection of IOTP Trading Exchange. It
                    contains one or more Trading Components.
                    Exchange Blocks are always sent after a Request
                    Block and before a Response Block in a Trading
                    Exchange. The content of an Exchange Block is
                    dependent on the type of Trading Exchange being
                    carried out.

Error Block         An Error Block reports that a Technical Error
                    was found in an IOTP Message that was previously
                    received. Typically Technical Errors are caused
                    by errors in the XML which carries has been received or
                    some technical failure of the data required to carry
                   out processing of the
                    IOTP Message. Frequently the generation or
                    receipt of an Error Block will result in failure
                    of the IOTP Transaction. They are distinct from
                    Business Errors, reported in a well formed
                   XML document Status Component,
                    which can also cause failure of an IOTP
                    Transaction.

        NAME                           DESCRIPTION

IOTP Message        An IOTP Message is the outermost wrapper for the
                    document(s) which are sent between the Trading Roles
                    that
  NAME             DESCRIPTION are taking part in a trade. It is a well
                    formed XML document. The documents it contains
                    consist of:
                    o a Transaction Reference Block to uniquely
                      identify the IOTP Transaction of which the
                      IOTP Message is part,
                    o an optional Signature Block to digitally sign
                      the Trading Blocks or Trading Components
                      associated with the IOTP Transaction
                    o an optional Error Block to report on technical
                      errors contained in a previously received IOTP
                      Message, and
                    o a collection of IOTP Trading Blocks which
                      carries the data required to carry out an IOTP
                      Transaction.

IOTP Transaction    An instance of an Internet Open Trading Protocol
                    Transaction consists of a set of IOTP Messages
                    transferred between Trading Roles. The rules for
                    what may be contained in the IOTP Messages is
                    defined by the Transaction      described as Type of IOTP
                    Transaction.

Document Exchange   A Document Exchange consists of a predefined set of IOTP IOTP
                    Messages exchanged between two parties that
                    implement part or all of two Trading Exchanges
                    simultaneously in order to minimise the number
                    of actual OTP Messages
                   transferred between which must be sent over
                    the Trading Roles. Internet.

                    Document Exchanges are combined together in
                    sequence to implement a particular IOTP
                    Transaction.

Merchant            The person or organisation Organisation from whom the purchase
                   is service or goods
                    are being made and obtained, who is legally responsible
                    for providing the goods or services and receives
                    the benefit of the any payment made

Merchant Customer   The entity Organisation that is involved with customer dispute
  Customer
Care Provider       dispute negotiation and resolution on behalf of
                    the
  Provider Merchant
        NAME                           DESCRIPTION

Organisation        A company or individual that takes part in a
                    Trade as a Trading Role. The organisations may
                    take one or more of the roles involved in the
                    Trade

Payment Handler     The entity Organisation that physically receives the
                    payment
  Handler from the Consumer on behalf of the
                    Merchant

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

        NAME                           DESCRIPTION

Promotional Brand   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. Merchant. For example: "Walmart", "Sears",
                    "Marks and Spencer" and "American Advantage
                    Visa", would each be a separate Brand.

Receipt Component   A Receipt Component is a record of the
                    successful completion of a Trading Exchange.
                    Examples of Receipt Components include: Payment
                    Receipts, and Delivery Notes. It's content may
                    dependent on the technology used to perform the
                    Trading Exchange. For example a Secure
                    Electronic Transaction (SET) payment receipt
                    consists of SET payment messages which record
                    the result of the payment.

        NAME                           DESCRIPTION

Request Block       A Request Block is Trading Block that contains a
                    request for a Trading Exchange to start. The
                    Trading Components in a Request Block may be
                    signed by a Signature Block so that their
                    authenticity may be checked and to determine
                    that the Trading Exchange being requested is
                    authorised. Authorisation for a Trading Exchange
                    to start can be provided by the signatures
                    contained on Receipt Components contained in
                    Response Blocks resulting from previously
                    completed Trading Exchanges.  Examples of
                    Request Blocks are Payment Request and Delivery
                    Request

Response Block      A Response Block is a Trading Block that
                    indicates that a Trading Exchange is complete.
                    It is sent by the Trading Role that received a
                    Request Block to the Trading Role that sent the
                    Request Block. The Response Block contains a
                    Status Component that contains information about
                    the completion of the Trading Exchange, for
                    example it indicates whether or not the Trading
                    Exchange completed successfully. For some
                    Trading Exchanges the Response Block contains a
                    Receipt Component that forms a record of the
                    Trading Exchange. Receipt Components may be
                    digitally signed using a Signature Block to make
                    completion non-refutable. Examples of Response
                    Blocks include Offer Response, Payment Response
                    and Delivery Response.

Signature Block     A Signature Block is a Trading Block that
                    contains one or more digital signatures in the
                    form of Signature Components. A Signature
                    Component may digitally sign any Block or
                    Component in any IOTP Message in the same IOTP
                    Transaction.

        NAME                           DESCRIPTION

Status Component    A Status Component contains information that
                    describes the state of a Trading Exchange.

                    Before the Trading Exchange is complete the
                    Status Component can indicate information about
                    how the Trading Exchange is progressing.

                    Once a Trading Exchange is complete the Status
                    Component can only indicate the success of the
                    Trading Exchange or that a Business Error has
                    occurred.

                    A Business Error indicates that continuation
                    with the Trading Exchange was not possible
                    because of some business rule or logic, for
                    example, "insufficient funds available", rather
                    than any Technical Error associated with the
                    content or format of the IOTP Messages in the
                    IOTP Transaction.

Technical Error     See Error Block.

Trading Block       A Trading Block consists of one or more Trading
                    Components. One or more Trading Blocks may be
                    contained within the IOTP Messages which are
                    physically sent in the form of [XML] documents
                    between the different organisations Trading Roles that are
                    taking part in a trade. Trading Blocks are of
                    three main types:
                    o a Request Block,
                    o an Exchange Block, or a
                    o a Response Block

Trading Component   A Trading Component is collections a collection of XML
  Component
                    elements and attributes. Trading Components are
                    the child elements of the Trading Blocks.
                    Examples of Trading Components are: Offer, Brand
                    List, Payment Receipt, Delivery [information],
                    Payment Amount [information]
        NAME                           DESCRIPTION

Trading Exchange    A Trading Exchange consists of the exchange,
                    between two Trading Roles, of a sequence of
                    documents. The documents may be in the form of
                    Trading Blocks or they may be transferred by
                    some other means, for example through entering
                    data into a web page. Each Trading Exchange
                    consists of three main parts:
                    o the sending of a Request Block by one Trading
                      Role (the initiator) to another Trading Role
                      (the recipient),
                    o the optional exchange of one or more Exchange
                      Blocks between the recipient and the
                      initiator, until eventually,
                    o the Trading Role that received the Request
                      Block sends a Response Block to the initiator.

                    A Trading Exchange is designed to implement a
                    useful service of some kind. Examples of Trading
                    Exchanges/services are:
                    o Offer, which results in a Consumer receiving
                      an offer from a Merchant to carry out a
                      business transaction of some kind,
                    o Payment, where a Consumer makes a payment to a
                      Payment Handler,
                    o Delivery, where a Consumer requests, and
                      optionally obtains, delivery of goods or
                      services from a Delivery Handler, and
                    o Authentication, where any Trading Role may
                      request and receive information about another
                      Trading Role.

Transaction         A Transaction Reference Block identifies an IOTP
Reference Block     Transaction. It contains data that identifies:
                    o the Transaction Type,
                    o the IOTP Transaction uniquely, through a
                      globally unique transaction identifier
                    o the IOTP Message uniquely within the IOTP
                      Transaction, through a message identifier

                    The Transaction Reference Block may also contain
                    references to other transactions which may or
                    may not be IOTP Transactions
        NAME                           DESCRIPTION

Trading Role        A Trading Role identifies the different ways in
                    which organisations can participate in a trade.
                    There are five Trading Roles: Consumer,
                    Merchant, Payment Handler, Delivery Handler, Merchant
                   Customer Care Provider and Payment Instrument
                    Merchant Customer Care Provider.

14.

Transaction Type    A Transaction Type identifies the type an of
                    IOTP Transaction. Examples of Transaction Type
                    include: Purchase, Refund, Authentication,
                    Withdrawal, Deposit (of electronic cash). The
                    Transaction Type specifies for an IOTP
                    Transaction:
                    o the Trading Exchanges which may be included in
                      the transaction,
                    o how those Trading Exchanges may be combined to
                      meet the business needs of the transaction
                    o which Trading Blocks may be included in the
                      IOTP Messages that make up the transaction
                    o Consult this specification for the rules that
                      apply for each Transaction Type.

  13. Copyrights

  Copyright (C) The Internet Society (1998). All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published and
  distributed, in whole or in part, without restriction of any kind,
  provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organisations, except as needed for the purpose of developing
  Internet standards in which case the procedures for copyrights defined
  in the Internet Standards process must be followed, or as required to
  translate it into languages other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
  FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
  NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
  OR FITNESS FOR A PARTICULAR PURPOSE.

15.

  14. References

  This section contains references to related documents identified in
  this specification.

[Base64]    Base64 Content-Transfer-Encoding. A method of
            transporting binary data defined by MIME. See: RFC 2045:
            Multipurpose Internet Mail Extensions (MIME) Part One:
            Format of Internet Message Bodies. N. Freed & N.
            Borenstein. November 1996.

[DOM-HASH]  A method for generating hashes of all or part of an XML
            tree based on the DOM of that tree. See
            <ftp://ftp.pothole.com/pub/dee3/drarft-hiroshi-com-hash-
            00.txt>.

[DNS]       The Internet Domain Name System which allocates Internet
            names to organisations for example "IOTP.org", "OTP.org", the Domain
            Name for IOTP. See RFC 1034: Domain names - concepts and
            facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035:
            Domain names - implementation and specification. P.V.
            Mockapetris. Nov-01-1987.

[DSA]       The Digital Signature Algorithm (DSA) published by the
            National Institute of Standards and Technology (NIST) in
            the Digital Signature Standard (DSS), which is a part of
            the US government's Capstone project.

[ECCDSA]    Elliptic Curve Cryptosystems Digital Signature Algorithm
            (ECCDSA). Elliptic curve cryptosystems are analogs analogues of
            public-key cryptosystems such as RSA in which modular
            multiplication is replaced by the elliptic curve
            addition operation. See: V. S. Miller. Use of elliptic
            curves in cryptography. In Advances in Cryptology -
            Crypto '85, pages 417-426, Springer-Verlag, 1986.

[HMAC]      See Message Authentication Using hash Functions: the
            HMAC Construction. RSA Cryptobytes, Volume 2, Number 1,
            Spring 1996

[HTML]      Hyper Text Mark Up Language. The Hypertext Mark-up
            Language (HTML) is a simple mark-up language used to
            create hypertext documents that are platform
            independent. See RFC 1866 and the World Wide Web (W3C)
            consortium web site at: http://www.w3.org/MarkUp/

[HTTP]      Hyper Text Transfer Protocol versions 1.0 and 1.1. See
            RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T.
            Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC
            2068: Hypertext Transfer Protocol -- HTTP/1.1. R.
            Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
            Lee. January 1997.

[IANA]      The Internet Assigned Numbers Authority. The
            organisation responsible for co-ordinating the names and
            numbers associated with the Internet. See
            http://www.iana.org/.

[ISO4217]   ISO 4217: Codes for the Representation of Currencies.
            Available from ANSI or ISO.

[MD5]       R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm.

[MIME]      Multipurpose Internet Mail Extensions. See RFC822,
            RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049.

[OPS]       Open Profiling Standard. A proposed standard which
            provides a framework with built-in privacy safeguards
            for the trusted exchange of profile information between
            individuals and web sites.  Being developed by Netscape
            and Microsoft amongst others.

[RFC822]    IETF (Internet Engineering Task Force). RFC 822: The
            Standard for the Format of ARPA Internet Messages

            . 13 August 1982, David H Crocker. 13 August 1982.

[RFC1738]   IETF (Internet Engineering Task Force). RFC 1738:
            Uniform Resource Locators (URL), ed. T. Berners-Lee, L.
            Masinter, M. McCahill. 1994.

[RFC2434]   IETF (Internet Engineering Task Force). RFC 2434.
            Guidelines for Writing an IANA Considerations Section in
            RFCs. T. Narten and H. Alvestrand

[RSA]       RSA is a public-key cryptosystem for both encryption and
            authentication supported by RSA Data Security Inc. See:
            R. L. Rivest, A. Shamir, and L.M. Adleman. A method for
            obtaining digital signatures and public-key
            cryptosystems. Communications of the ACM, 21(2): 120-126, 120-
            126, February 1978.

[SCCD]      Secure Channel Credit Debit. A method of conducting a
            credit or debit card payment where unauthorised access
            to account information is prevented through use of
            secure channel transport mechanisms such as SSL. An IOTP
            supplement describing how SCCD works is under
            development. Author. Jonathan Sowler JCP,

[SET]       Secure Electronic Transaction Specification, Version
            1.0, May 31, 1997. Supports credit and debit card
            payments using certificates at the Consumer and Merchant
            to help ensure authenticity.
            Download from:
            <http://www.mastercard.com/set/specs.html>.

[SHA1]      [FIPS-180-1]"Secure Hash Standard", National Institute
            of Standards and Technology, US Department Of Commerce,
            April 1995. Also known as: 59 Fed Reg. 35317 (1994).

[UTC]       Universal Time Co-ordinated. A method of defining time
            absolutely relative to Greenwich Mean Time (GMT).
            Typically of the form:  "CCYY-MM-DDTHH:MM:SS.sssZ+n"
            where the "+n" defines the number of hours from GMT. See
            ISO DIS8601.

[UTF16]     The Unicode Standard, Version 2.0.  The Unicode
            Consortium, Reading, Massachusetts. See ISO/IEC 10646 1
            Proposed Draft Amendment 1

[X.509]     ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995,
            Including Draft Amendment 1: Certificate Extensions
            (Version 3 Certificate)

[XML        See Design decisions reached at the XML Working Group
Namespace]  meeting        Recommendation for Namespaces in Montreal, Canada, August 22, 1987 XML, World Wide Web
Namespace]  Consortium, 14 January 1999, "http://www.w3.org/TR/REC-
            xml-names"

[XML]       Extensible Mark Up Language. See http://www.w3.org/TR/PR-
            xml-971208
            http://www.w3.org/TR/PR-xml-971208 for the 8 December
            1997 version.

[XMLSIG]

[XMLDSIG]   A proposal developed by the IOTP consortium Richard Brown, GlobeSet
            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)

16. See http://www.ietf.org/internet-
            drafts/draft-brown-xml-dsig-00.txt and discussion on
            IETF Trade WG
  15. Author's Address

  The author of this document is:

  David Burdett
  Development Director
  Mondex International Ltd
  Advanced Technology Division
  111 Pine St, Suite 600 St
  San Francisco, 94111
  California
  USA

  Tel: +1 (415) 645 6973

  Email: david.burdett@mondex.com

  The author of this document appreciates the following contributors to
  this protocol (in alphabetic order of company) without which it could
  not have been developed.

  o Phillip Mullarkey, British Telecom plc

  o Andrew Marchewka, Canadian Imperial Bank of Commerce

  o Brian Boesch, CyberCash Inc.

  o Donald Eastlake 3rd, CyberCash Inc.

  o Mark Linehan, International Business Machines

  o Richard Brown, GlobeSet Inc.

  o Peter Chang, Hewlett Packard

  o Masaaki Hiroya, Hitachi Ltd

  o Yoshiaki Kawatsura, Hitachi Ltd

  o Jonathan Sowler, JCP Computer Services Ltd

  o John Wankmueller, MasterCard International

  o Steve Fabes, Mondex International Ltd
  o Surendra Reddy, Oracle Corporation

  o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)

  o Chris Smith, Royal Bank of Canada

  o Hans Bernhard-Beykirch, SIZ (IT Development and Coordination
    Centre of the German Savings Banks Organisation)

  o W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services,
    formally AT&T Universal Card Services)

  o Efrem Lipkin, Sun Microsystems

  o Terry Allen, Commerce One (formally Veo Systems Systems)

  The author would also like to thank the following organisations for
  their support:

  o Amino Communications

  o DigiCash

  o Fujitsu

  o General Information Systems

  o Globe Id Software

  o Hyperion

  o InterTrader

  o Nobil I T Corp

  o Mercantec

  o Netscape

  o Nippon Telegraph and Telephone Corporation

  o Oracle Corporation

  o Smart Card Integrations Ltd.

  o Spyrus
  o Verifone

  o Unisource nv

  o Wells Fargo Bank

Note: This is file draft-ietf-trade-iotp-v1.0-protocol-02.txt

  File name: draft-ietf-trade-iotp-v1.0-protocol-03.txt
  Expires: 23 May  28 August 1999