TRADE Working Group                                    David Burdett
  Internet Draft                                  Mondex International
  draft-ietf-trade-iotp-v1.0-protocol-03.txt
  draft-ietf-trade-iotp-v1.0-protocol-04.txt
  Expires:  28  13 February 2000                            12 August 1999

                 Internet Open Trading Protocol - IOTP
                              Version 1.0

  Status of this Memo

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

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

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

  To view the list Internet-Draft Shadow Directories, see
  http://www.ietf.org/shadow.html.

  Distribution of this document is unlimited. Please send comments to
  the TRADE  working group at <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.

  David Burdett et al.

  Abstract

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

  This document obsoletes the previous version of the IOTP specification
  (draft-ietf-trade-iotp-v1.0-protocol-03.txt.)
  Table of Contents

  Status of this Memo..................................................2

  Abstract.............................................................3 Memo..................................................1

  Abstract.............................................................2

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

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

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

  4. IOTP Error Handling..............................................73 Handling..............................................58
     4.1 Technical Errors.............................................73 Errors.............................................58
     4.2 Business Errors..............................................74 Errors..............................................59
     4.3 Error Depth..................................................74 Depth..................................................59
       4.3.1 Transport Level .........................................75 .........................................59
       4.3.2 Message Level ...........................................75 ...........................................60
       4.3.3 Block Level .............................................76 .............................................61
     4.4 Idempotency, Processing Sequence, and Message Flow...........78
       4.4.1 Flow...........63
     4.5 Server Role Processing Sequence .........................78
       4.4.2 Sequence..............................63
       4.5.1 Initiating Transactions .................................64
       4.5.2 Processing Input Messages ...............................64
       4.5.3 Cancelling a Transaction ................................70
       4.5.4 Retransmitting Messages .................................71
     4.6 Client Role Processing Sequence .........................84 Sequence..............................71
       4.6.1 Initiating Transactions .................................72
       4.6.2 Processing Input Messages ...............................72
       4.6.3 Cancelling a Transaction ................................74
       4.6.4 Retransmitting Messages .................................74

  5. Security Considerations..........................................90 Considerations..........................................75
     5.1 Determining whether to use digital signatures................75
     5.2 Symmetric and Asymmetric Cryptography........................77
     5.3 Data Privacy.................................................77
     5.4 Payment Protocol Security....................................77

  6. Digital Signatures and IOTP..................................90
       5.1.1 IOTP......................................79
     6.1 How IOTP uses Digital Signatures.............................79
       6.1.1 IOTP Signature Example ..................................92
       5.1.2 ..................................81
       6.1.2 OriginatorInfo and RecipientInfo Elements ...............94
       5.1.3 Symmetric and Asymmetric Cryptography ...................95
       5.1.4 Mandatory and Optional Signatures .......................95
       5.1.5 ...............82
       6.1.3 Using signatures to Prove Actions Complete Successfully .95
     5.2 .83
     6.2 Checking a Signature is Correctly Calculated.................96
     5.3 Calculated.................84
     6.3 Checking a Payment or Delivery can occur.....................97
       5.3.1 occur.....................85
       6.3.1 Check the Action Request Block was sent to the Correct
       Organisation ..................................................99
       5.3.2 ..................................................86
       6.3.2 Check the Correct Components are present in the Request
       Block ........................................................103
       5.3.3 .........................................................89
       6.3.3 Check an Action is Authorised ..........................103
     5.4 Data Integrity and Privacy..................................105

  6. ...........................89

  7. Trading Components..............................................106
     6.1 Components...............................................92
     7.1 Protocol Options Component..................................108
     6.2 Component...................................94
     7.2 Authentication Data Component...............................110
     6.3 Request Component.............................95
     7.3 Authentication Response Component...........................112
     6.4 Component............................96
     7.4 Trading Role Information Request Component...................97
     7.5 Order Component.............................................113
       6.4.1 Component..............................................98
       7.5.1 Order Description Content ..............................115
       6.4.2 ...............................99
       7.5.2 OkFrom and OkTo Timestamps .............................115
     6.5 ..............................99
     7.6 Organisation Component......................................116
       6.5.2 Component......................................100
       7.6.2 Trading Role Element ...................................119
       6.5.3 ...................................103
       7.6.3 Contact Information Element ............................122
       6.5.4 ............................106
       7.6.4 Person Name Element ....................................123
       6.5.5 ....................................107
       7.6.5 Postal Address Element .................................124
     6.6 .................................108
     7.7 Brand List Component........................................125
       6.6.1 Component........................................109
       7.7.1 Brand Element ..........................................111
       7.7.2 Protocol Brand Element ..........................................127
       6.6.2 .................................113
       7.7.3 Protocol Amount Element ................................130
       6.6.3 ................................114
       7.7.4 Currency Amount Element ................................132
       6.6.4 ................................115
       7.7.5 Pay Protocol Element ...................................133
     6.7 ...................................116
     7.8 Brand Selection Component...................................135
       6.7.1 Component...................................118
       7.8.1 Brand Selection Brand Info Element .....................137
       6.7.2 .....................119
       7.8.2 Brand Selection Protocol Amount Info Element ...........138
       6.7.3 ...........120
       7.8.3 Brand Selection Currency Amount Info Element ...........138
     6.8 ...........120
     7.9 Payment Component...........................................139
     6.9 Component...........................................121
     7.10 Payment Scheme Component....................................141
     6.10 Component...................................122
     7.11 Payment Receipt Component..................................142
     6.11 Component..................................123
     7.12 Payment Note Component.....................................144
     6.12 Component.....................................125
     7.13 Delivery Component.........................................145
       6.12.1 Component.........................................126
       7.13.1 Delivery Data Element .................................147
     6.13 .................................128
     7.14 Delivery Note Component....................................149
     6.14 Component....................................130
     7.15 Status Component...........................................151
       6.14.1 Component...........................................131
       7.15.1 Offer Completion Codes ................................154
       6.14.2 ................................133
       7.15.2 Payment Completion Codes ..............................154
       6.14.3 ..............................135
       7.15.3 Delivery Completion Codes .............................155
       6.14.4 .............................137
       7.15.4 Authentication Completion Codes .......................157
     6.15 .......................139
       7.15.5 Undefined Completion Codes ............................140
       7.15.6 Transaction Inquiry Completion Codes ..................141
     7.16 Trading Role Data Component................................158
       6.15.1 Component................................141
       7.16.1 Who Receives a Trading Role Data Component ............159
     6.16 ............142
     7.17 Inquiry Type Component.....................................159
     6.17 Component.....................................143
     7.18 Signature Component........................................160
       6.17.1 Component........................................143
       7.18.1 IOTP usage of signature elements and attributes .......164
       6.17.2 .......145
       7.18.2 Offer Response Signature Component ....................166
       6.17.3 ....................148
       7.18.3 Payment Receipt Signature Component ...................167
       6.17.4 ...................149
       7.18.4 Delivery Response Signature Component .................168
       6.17.5 .................149
       7.18.5 Authentication Request Signature Component ............168
       6.17.6 ............150
       7.18.6 Authentication Response Signature Component ...........168
       6.17.7 ...........150
       7.18.7 Ping Request Signature Component ......................169
       6.17.8 ......................151
       7.18.8 Ping Response Signature Component .....................169
     6.18 .....................151
     7.19 Certificate Component......................................169
       6.18.1 Component......................................151
       7.19.1 IOTP usage of signature elements and attributes .......170
     6.19 .......152
     7.20 Error Component............................................170
       6.19.1 Component............................................152
       7.20.1 Error Processing Guidelines ...........................173
       6.19.2 ...........................154
       7.20.2 Error Codes ...........................................174
       6.19.3 ...........................................156
       7.20.3 Error Location Element ................................178

  7. ................................159

  8. Trading Blocks..................................................180
     7.1 Blocks..................................................161
     8.1 Trading Protocol Options Block..............................183
     7.2 Block..............................163
     8.2 TPO Selection Block.........................................184
     7.3 Block.........................................164
     8.3 Offer Response Block........................................185
     7.4 Block........................................165
     8.4 Authentication Request Block................................186
     7.5 Block................................166
     8.5 Authentication Response Block...............................187
     7.6 Block...............................167
     8.6 Authentication Status Block.................................187
     7.7 Block.................................168
     8.7 Payment Request Block.......................................188
     7.8 Block.......................................169
     8.8 Payment Exchange Block......................................190
     7.9 Block......................................170
     8.9 Payment Response Block......................................190
     7.10 Block......................................171
     8.10 Delivery Request Block.....................................191
     7.11 Block.....................................172
     8.11 Delivery Response Block....................................193
     7.12 Block....................................173
     8.12 Inquiry Request Trading Block..............................194
     7.13 Block..............................174
     8.13 Inquiry Response Trading Block.............................194
     7.14 Block.............................175
     8.14 Ping Request Block.........................................195
     7.15 Block.........................................176
     8.15 Ping Response Block........................................196
     7.16 Block........................................177
     8.16 Signature Block............................................198
       7.16.1 Block............................................179
       8.16.1 Signature Block with Offer Response ........................................199
       7.16.2 ...................179
       8.16.2 Signature Block with Payment Request .......................................199
       7.16.3 ..................179
       8.16.3 Signature Block with Payment Response ......................................199
       7.16.4 .................180
       8.16.4 Signature Block with Delivery Request ......................................199
     7.17 .................180
       8.16.5 Signature Block with Delivery Response ................180
     8.17 Error Block................................................199
     7.18 Block................................................180
     8.18 Cancel Block...............................................201

  8. Block...............................................181

  9. Internet Open Trading Protocol Transactions.....................202
     8.1 Transactions.....................183
     9.1 Authentication and Payment Related IOTP Transactions........202
       8.1.1 Transactions........183
       9.1.1 Authentication Document Exchange .......................205
       8.1.2 .......................185
       9.1.2 Offer Document Exchange ................................212
       8.1.3 ................................191
       9.1.3 Payment Document Exchange ..............................222
       8.1.4 ..............................199
       9.1.4 Delivery Document Exchange .............................228
       8.1.5 .............................205
       9.1.5 Payment and Delivery Document Exchange .................231
       8.1.6 .................207
       9.1.6 Baseline Authentication IOTP Transaction ...............234
       8.1.7 ...............211
       9.1.7 Baseline Deposit IOTP Transaction ......................236
       8.1.8 ......................212
       9.1.8 Baseline Purchase IOTP Transaction .....................238
       8.1.9 .....................214
       9.1.9 Baseline Refund IOTP Transaction .......................240
       8.1.10 .......................215
       9.1.10 Baseline Withdrawal IOTP Transaction ..................242
       8.1.11 ..................217
       9.1.11 Baseline Value Exchange IOTP Transaction ..............244
       8.1.12 ..............219
       9.1.12 Valid Combinations of Document Exchanges ..............248
       8.1.13 ..............222
       9.1.13 Combining Authentication Transactions with other
       Transactions .................................................252
     8.2 .................................................225
     9.2 Infrastructure Transactions.................................253
       8.2.1 Transactions.................................227
       9.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...254
       8.2.2 ...227
       9.2.2 Baseline Ping IOTP Transaction .........................258

  9. .........................231

  10. Retrieving Logos................................................262
     9.1 Logos...............................................235
     10.1 Logo Size...................................................262
     9.2 Size..................................................235
     10.2 Logo Color Depth............................................263
     9.3 Depth...........................................236
     10.3 Logo Net Location Examples..................................263
  10. Examples.................................236

  11. Brands.........................................................237
     11.1 Brand Definitions and Brand Selection......................237
       11.1.1 Definition of Payment Instrument ......................237
       11.1.2 Definition of Brand ...................................238
       11.1.3 Definition of Dual Brand ..............................238
       11.1.4 Definition of Promotional Brand .......................239
       11.1.5 Identifying Promotional Brands ........................239
     11.2 Brand List Examples............................................265
     10.1 Examples........................................242
       11.2.1 Simple Credit Card Based Example...........................265
     10.2 Example ......................242
       11.2.2 Credit Card Brand List Including Promotional Brands........266
     10.3 Brands ...243
       11.2.3 Brand Selection Example....................................269
     10.4 Example ...............................246
       11.2.4 Complex Electronic Cash Based Brand List...................269

  11. List ..............246

  12. IANA Considerations............................................251
     12.1 Codes Controlled by IANA...................................251
     12.2 Codes not controlled by IANA...............................256

  13. Internet Open Trading Protocol Data Type Definition.....................274

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

  13. Copyrights.....................................................298 Definition............257

  14. References.....................................................299 Glossary.......................................................272

  15. Copyrights.....................................................282

  16. References.....................................................283

  17. Author's Address...............................................303 Address...............................................286
  Table of Figures

  Figure 1 IOTP Trading Roles ........................................20 ........................................19
  Figure 2 Offer Exchange ............................................23 ............................................22
  Figure 3 Payment Exchange ..........................................26 ..........................................25
  Figure 4 Delivery Exchange .........................................30 .........................................27
  Figure 5 Authentication Exchange ...................................33 ...................................29
  Figure 6 IOTP Message Structure ....................................41 ....................................35
  Figure 7 An IOTP Transaction .......................................42 .......................................37
  Figure 8 Example use of ID attributes ..............................54 ..............................48
  Figure 9 Element References ........................................56 ........................................50
  Figure 10 Server Role Processing Sequence ..........................80
  Figure 11 Client Role Processing Sequence ..........................86
  Figure 12 Signature Digests ........................................91 ........................................80
  Figure 13 11 Example use of Signatures for Baseline Purchase ..........93 ..........82
  Figure 14 12 Checking a Payment Handler can carry out a Payment ......100 .......87
  Figure 15 13 Checking a Delivery Handler can carry out a Delivery ....102 .....89
  Figure 16 14 Trading Components ......................................107 .......................................93
  Figure 17 15 Brand List Element Relationships ........................127 ........................111
  Figure 18 16 Trading Blocks ..........................................181 ..........................................162
  Figure 19 17 Payment and Authentication Message Flow Combinations ....204 ....185
  Figure 20 18 Authentication Document Exchange ........................208 ........................187
  Figure 21 19 Brand Dependent Offer Document Exchange .................214 .................193
  Figure 22 20 Brand Independent Offer Exchange ........................217 ........................195
  Figure 23 21 Payment Document Exchange ...............................224 ...............................200
  Figure 24 22 Delivery Document Exchange ..............................229 ..............................206
  Figure 25 23 Payment and Delivery Document Exchange ..................232 ..................209
  Figure 26 24 Baseline Authentication IOTP Transaction ................235 ................212
  Figure 27 25 Baseline Deposit IOTP Transaction .......................237 .......................213
  Figure 28 26 Baseline Purchase IOTP Transaction ......................239 ......................215
  Figure 29 27 Baseline Refund IOTP Transaction ........................241 ........................217
  Figure 30 28 Baseline Withdrawal IOTP Transaction ....................243 ....................219
  Figure 31 29 Baseline Value Exchange IOTP Transaction ................246 ................221
  Figure 32 30 Baseline Value Exchange Signatures ......................247 ......................222
  Figure 33 31 Valid Combinations of Document Exchanges ................250 ................223
  Figure 34 32 Baseline Transaction Status Inquiry .....................257 .....................230
  Figure 35 33 Baseline Ping Messages ..................................259 ..................................232
  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, 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 _ Internet, a Different Model

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

  One of the very fundamental changes about which IOTP is concerned is
  taking place in the way consumers and merchants trade. Characteristics
  of trading that have changed markedly include:

      o Presence: Face-to-face transactions become the exception,
        not the rule. Already with the rise of mail order and
        telephone order placement this change has been felt in
        western commerce. Electronic commerce over the Internet
        will further expand the scope and volume of transactions
        conducted without ever seeing the people who are a part of
        the enterprise with whom one does business.

      o Authentication: An important part of personal presence is
        the ability of the parties to use familiar objects and
        dialogue to confirm they are who they claim to be. The
        seller displays one or several well known financial logos
        that declaim his ability to accept widely used credit and
        debit instruments in the payment part of a purchase. The
        buyer brings government or financial institution
        identification that assures the seller she will be paid.
        People use intangibles such as personal appearance and
        conduct, location of the store, apparent quality and
        familiarity with brands of merchandise, and a good clear
        look in the eye to reinforce formal means of
        authentication.

      o Payment Instruments: Despite the enormous size of bank card
        financial payments associations and their members, most of
        the world's trade still takes place using the coin of the
        realm or barter. The present infrastructure of the payments
        business cannot economically support low value transactions
        and could not survive under the consequent volumes of
        transactions if it did accept low value transactions.

      o Transaction Values: New meaning for low value transactions
        arises in the Internet where sellers may wish to offer for
        example, pages of information for fractions of currency
        that do not exist in the real world.

      o Delivery: New modes of delivery must be accommodated such
        as direct electronic delivery. The means by which receipt
        is confirmed and the execution of payment change
        dramatically where the goods or services have extremely low
        delivery cost but may in fact have very high value. Or,
        maybe the value is not high, but once delivery occurs the
        value is irretrievably delivered so payment must be final
        and non-refundable but delivery nonetheless must still be
        confirmed before payment. Incremental delivery such as
        listening or viewing time or playing time are other models
        that operate somewhat differently in the virtual world.

  1.2 Benefits of IOTP

  ELECTRONIC COMMERCE SOFTWARE VENDORS

  Electronic Commerce Software Vendors will be able to develop e-
  commerce products which are more attractive as they will inter-operate
  with any other vendors' software. However since IOTP focuses on how
  these solutions communicate, there is still plenty of opportunity for
  product differentiation.

  PAYMENT BRANDS

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

  MERCHANTS

  There are several benefits for Merchants:

      o they will be able to offer a wider variety of payment
        brands,

      o they can be more certain that the customer will have the
        software needed to complete the purchase

      o through receiving payment and delivery receipts from their
        customers, they will be able to provide customer care
        knowing that they are dealing with the individual or
        organisation with which they originally traded
      o new merchants will be able to enter this new (Internet) market-
    place
        market-place with new products and services, using the new
        trading opportunities which IOTP presents

  BANKS AND FINANCIAL INSTITUTIONS

  There are also several benefits for Banks and Financial Institutions:

      o they will be able to provide IOTP support for merchants

      o they will find new opportunities for IOTP related services:
       - providing customer care for merchants
       - fees from processing new payments and deposits

      o they have an opportunity to build relationships with new
        types of merchants

  CUSTOMERS

  For Customers there are several benefits:

      o they will have a larger selection of merchants with whom
        they can trade

      o there is a more consistent interface when making the
        purchase

      o there are ways in which they can get their problems fixed
        through the merchant (rather than the bank!)

      o there is a record of their transaction which can be used,
        for example, to feed into accounting systems or,
        potentially, to present to the tax authorities

  1.3 Baseline IOTP

  This specification is Baseline IOTP. It is a Baseline in that it
  contains ways of doing trades on the Internet which are the most
  common. The team working on the IOTP see an extended versions version 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_ "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.
  specification.

  During this period it is anticipated that there will be no changes to
  the scope of this specification with the only changes made being
  limited to corrections where problems are found. Software solutions
  have been developed based on earlier versions of this specification
  (for example version 0.9 published in early 1998) 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 Internet Open Trading Protocols
  which can be used to design and implement systems which support
  electronic trading on the Internet using the Internet Open Trading
  Protocols.

  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

  1.5 Scope of Document

  The protocol describes the content, format and sequences of messages
  that pass among the participants in an electronic trade - consumers,
  merchants and banks or other financial institutions, and customer care
  providers. These are required to support the electronic commerce
  transactions outlined in the objectives above.

  The protocol is designed to be applicable to any electronic payment
  scheme since it targets the complete purchase process where the
  movement of electronic value from the payer to the payee is only one,
  but important, step of many that may be involved to complete the
  trade.

  Payment Scheme which IOTP could support include MasterCard Credit,
  Visa Credit, Mondex Cash, Visa Cash, GeldKarte, 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

  1.6 Document Structure

  The document consists of the following sections:

      o Section 1 - Background: This section gives a brief
        background on electronic commerce and the benefits IOTP
        offers.

      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 considers
        from an IETF perspective, how IOTP addresses security. It
        includes: how to determine whether to use digital
        signatures with IOTP, how IOTP address data privacy, and
        how security considerations built into payment protocols relate to IOTP
        security.

      o Section 6 - Digital Signatures and IOTP: This section
        provides an overview of how IOTP uses digital signatures for the XML
    elements exchanged between signatures;
        how to check a signature is correctly calculated and how
        the various Trading Roles. Roles that participate in trade should
        check signatures when required.

      o Section 6 7 - Trading Components: This section defines the
        XML elements required by Trading Components.

      o Section 7 8 - Trading Blocks: This section describes how
        Trading Blocks are constructed from Trading Components.

      o Section 8 9 - Internet Open Trading Protocol Transactions:
        This section describes all the IOTP Baseline transactions.
        It refers to Trading Blocks and Trading Components and
        Signatures. This section doesn't directly link error
        handling during the protocol exchanges, the reader is
        advised to understand Error Handling as defined in section
        before reading this section.

      o Section 9 10 - Retrieving Logos: This section describes how
        IOTP specific logos can be retrieved.

      o Section 10 11 - Brand List Examples: Brands: This section gives provides: an overview of
        Brand Definitions and Brand Selection which describe how a
        Consumer can select a Brand from a list provided by the
        Merchant; as well as some examples for of Brand List. Lists.

      o Section 11 12 - XML Overview: IANA Considerations: This section gives brief
    introduction to XML. describes
        how new values for codes used by IOTP are co-ordinated.

      o Section 12 13 - Internet Open Trading Protocol Data Type
        Definition: This section contains the XML Data Type
        Definitions for IOTP.

      o Section 12 14 - Glossary. This describes all the major
        terminology used by IOTP.

  1.8

      o Section 15 - Copyright information.

      o Section 16 - A list of the other documents referenced by
        the IOTP specification.

      o Section 17 - The Author's Address

  1.7 Intended Readership

  Software and hardware developers; development analysts; business and
  technical planners; industry analysts; merchants; bank and other
  payment handlers; owners, custodians, and users of payment protocols.

  1.8.1

  1.7.1 Reading Guidelines

  This IOTP specification is structured primarily in a sequence targeted
  at people who want to understand the principles of IOTP. However from
  practical implementation experience by implementers of earlier of
  versions of the protocol new readers who plan to implement IOTP may
  prefer to read the document in a different sequence as described
  below.

  Review the transport independent parts of the specification: This
  covers

      o Section 12 14 - Glossary

      o Section 1 - Background

      o Section 2 - Introduction

      o Section 3 - Protocol Structure

      o Section 4 - IOTP Error Handling

      o Section 8 5 - Security Considerations

      o Section 9 - Internet Open Trading Protocol Transactions

      o Section 10 11 - Brand List Examples Brands

      o Section 4 12 - IOTP Error Handling IANA Considerations

      o Section 9 10 - Retrieving Logos

  Review the detailed XML definitions:

      o Section 11 8 - XML Overview (if the reader does not know XML) Trading Blocks

      o Section 7 - Trading Blocks Components

      o Section 6 - Trading Components

  1.9 History

  Version 0.1    20 February 1997  Initial draft for comment

  Version 0.2    14 April 1997     Revised draft including changes
                                   arising from comments
  Version 0.2a   24 April 1997     Same as version 0-2 with
                                   typographic corrections

  Version 0.3    9 October 1997    Revised draft for comment
                                   including revised encoding
                                   approach using [XML]

  Version 0.4    31 October 1997   Published draft for limited public
                                   review by groups working within
                                   the OTP consortium

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

  Version 0.9.1  20 May 1998       Revisions following public review
                                   - internal Digital Signatures and 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 one organisation or
        individual to check that another organisation or individual
        are who they appear to be.

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

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

      o Inquiry This supports inquiries on the status of an IOTP
        transaction which is either in progress or is complete

      o Ping This supports a simple query which enables one IOTP
        aware application to determine whether another IOTP
        application running elsewhere is working or not.

  These IOTP Transactions are "Baseline" transactions since they have
  been identified as a minimum useful set of transactions. Later
  versions of IOTP may include additional types of transactions.

  Each of the IOTP Transactions above involve:

      o a number organisations playing a Trading Role, and

      o a set of Trading Exchanges. Each Trading Exchange involves
        the exchange of data, between Trading Roles, in the form of
        a set of Trading Components.

  Trading Roles, Trading Exchanges and Trading Components are described
  below.

  2.1 Trading Roles

  The Trading Roles identify the different parts which organisations can ca
  take in a trade. The six Trading Roles used within IOTP are
  illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

           Merchant Customer Care Provider resolves   ----------
      ---------------------------------------------->| Merchant |
     |          Consumer disputes and problems       |Cust.Care.|
     |                                               | Provider |
     |                                                ----------
     |
                Payment Handler accepts or makes     ----------
     |    ------------------------------------------>| Payment  |
     |   |             Payment for Merchant          | Handler  |
     |   |                                            ----------
     v   v
 ----------    Consumer makes purchases or obtains    ----------
| Consumer |<--------------------------------------->| Merchant |
 ----------             refund from Merchant          ----------
     ^
     |         Delivery Handler supplies goods or     ----------
     |---------------------------------------------->|Deliverer |
                    services for Merchant             ----------

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

                       Figure 1 IOTP Trading Roles

  The roles are:

      o Consumer. The person or organisation which is to receive
        and pay for the goods or services

      o Merchant. The person or organisation from whom the purchase
        is being made and who is legally responsible for providing
        the goods or services and receives the benefit of the
        payment made

      o Payment Handler. The entity that physically receives the
        payment from the Consumer on behalf of the Merchant

      o Delivery Handler. The entity that physically delivers the
        goods or services to the Consumer on behalf of the
        Merchant.

      o Merchant Customer Care Provider. The entity that is
        involved with customer dispute negotiation and resolution
        on behalf of the Merchant

  Roles may be carried out by the same organisation or different
  organisations. For example:

      o in the simplest case one physical organisation (e.g. a
        merchant) could handle the purchase, accept the payment,
        deliver the goods and provide merchant customer care

      o at the other extreme, a merchant could handle the purchase
        but instruct the consumer to pay a bank or financial
        institution, request that delivery be made by an overnight
        courier firm and to contact an organisation which provides
        24x7 service if problems arise.

  Note that in this specification, unless stated to the contrary, when
  the words Consumer, Merchant, Payment Handler, Delivery Handler or
  Customer Care Provider are used, they refer to the Trading Role rather rathe
  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 tak
  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 Internet Open Trading Protocols identify four Trading Exchanges
  which involve the exchange of data between the Trading Roles. The
  Trading Exchanges are:

      o Offer. The Offer Exchange results in the Merchant providing
        the Consumer with the reason why the trade is taking place.
        It is called an Offer since the Consumer must accept the
        Offer if a trade is to continue

      o Payment. The Payment Exchange results in a payment of some
        kind between the Consumer and the Payment Handler. This may
        occur in either direction
      o Delivery. The Delivery Exchange transmits either the on-line 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 include
  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               IOTP MESSAGE             MERCHANT

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to   ---------------------->  2. Merchant checks trade and sends information about the
             transaction (requests an offer) to the Merchant e.g. using
             HTML.

     C --> M Data: Information on what is     the information
 information about the being purchased (Offer
             Request) - outside scope of IOTP

 2.          Merchant checks the information provided by the
 transaction (requests   Request) (outside scope Consumer,
             creates an
   an offer) to the             of IOTP) Offer optionally signs it and sends it
  Merchant, e.g using to the Consumer|
         HTML
                                                           v
3. Consumer checks the
             Consumer.

     C <-- M OFFER RESPONSE. Components: Organisation(s)
 information from the (Consumer,
             DeliverTo, Merchant,
 Merchant and decides    <---------- Payment Handler, Delivery
  whether to continue       Offer     Handler, Cust Customer Care);
             Order; Pay
                          Response Amount; Delivery; Optional Offer Response
             Signature
                                        (Offer Response)(which that signs other components) components

 3.          Consumer checks the information from the Merchant and
             decides whether to continue.

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

                         Figure 2 Offer Exchange

  An Offer Exchange uses the following Trading Components that are
  passed between the Consumer and the Merchant:

      o the 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 is provided using usin
  a variety of methods, for example, it could be provided:

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

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

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

      o as Order Components in a later version of IOTP.

  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 cas
  where the trade is dependent on the payment brand and protocol used is i
  illustrated in the diagram below. Simpler payment exchanges are
  possible.

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

        CONSUMER               IOTP MESSAGE             MERCHANT
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer  Pay Handler
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to                           2. Merchant decides trade and sends       Information on what is     which payment information
                    about the        being paid for         brand, payment transaction (requests an  ---------------------->    protocols and offer) to the Merchant,
                    Merchant e.g. using HTML.

     C --> M        Information on what is being paid for (outside scope scop
                    of IOTP) IOTP

 2.                 Merchant decides which payment brand, payment
                    protocols and currencies/amounts
     e.g using HTML to offer, places
                                                    them
                    then in a Brand List Component and sends them to the th
                    Consumer
                                                              |
                                                              v

     C <-- M        Components: Brand List

 3.                 Consumer selects the payment   <-----------------   Brand List brand, protocol and
                    currency/amount     Brand List        Component to use, creates a Brand Selection
   Component
                    component and sends it to the Merchant
        |
        v

     C --> M        Component: Brand List Selection   ---------------->

 4.                 Merchant checks Brand
                    Brand Selection Selection, creates a Payment
                    Amount information, optionally signs it to authorise authoris
                    payment and sends it to the Consumer
                                                    |
                                                    v

     C <-- M        Component: Pay Amount; Organisation(s) (Merchant an
                    Payment Handler); Optional Offer Response Signature
                    that signs other components

 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

     C --------> P  PAYMENT HANDLER REQUEST. Components: Pay Scheme; Auth Amount;
                    Organisations (Merchant and Payment Handler);
                    Optional Offer Response Signature that signs other
                    components; Pay Scheme

 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 components for selected
 ----- components except payment brand and
                    payment
|       Pay Scheme) protocol
|        |                                              |
|        v                                              v
| Component: Pay Scheme  <------------------>

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme
|                          Payment Exchange
|                                                        |
|                                                        v
|

 7.                 Eventually payment protocol messages
 ----------- finish so
                    Payment Handler sends Pay
            | Receipt and optional
                    signature to
            | the Consumer as proof of payment
            |                                      |
            |                                      v
  8. Consumer checks Pay

     C <-------> P  PAYMENT RESPONSE. Components: Pay Receipt; Pay
      Receipt is OK      <-------      scheme; Signature (Offer); Payment  Signature (Pay Receipt) (signs Pay
                    Note; Optional Offer Response Signature; Optional
                    Payment Receipt and Signature (Offer)
                                              components) that binds the payment to
                    the Offer
 8.                 Consumer checks Payment Receipt is OK

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

                        Figure 3 Payment Exchange

  A Payment Exchange uses the following Trading Components that are
  passed between the Consumer, the Merchant and the Payment Handler:

      o The Brand List Component contains a list of payment brands
        (for example, MasterCard, Visa, Mondex, GeldKarte), payment
        protocols (for example SET Version 1.0, Secure Channel
        Credit Debit (SCCD - the name used for a credit or debit
        card payment where unauthorised access to account
        information is prevented through use of secure channel
        transport mechanisms such as SSL) SSL/TLS) as well as
        currencies/amounts that apply. The Merchant sends the Brand
        List to the Consumer. The consumer compares the payment
        brands, protocols and currencies/amounts on offer with
        those that the Consumer supports and makes a selection.

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

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

      o The Payment Component contains details of how much to pay,
        the currency and the payment direction

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

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

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

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

  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 a
  the same time as the Brand List Component generated by step 1. These
  and other variations are described in the Baseline Purchase IOTP
  Transaction (see section Baseline Purchase IOTP Transaction).

  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 providin
  details about the delivery, such as shipping tracking number. The
  result of the delivery may also be signed so that it can be used for
  customer care in the case of problems with physical delivery. The
  message flow is illustrated in the diagram below.

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

       CONSUMER             IOTP MESSAGE              MERCHANT

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer  Delivery
     |        Handler
     |  Merchant |
STEP |     |     |
 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 to take delivery,
                    to the Merchant e.g. using HTML.

     C --> M        Information on what is being delivered (outside
                    scope of IOTP)

 2.                 Merchant checks the information provided by the
                    Consumer, adds information about how the delivery
                    will
 to take delivery, to      delivered occur, information about the
the Merchant, using for    (outside organisations
                    involved in the
     example, HTML         scope of delivery and optionally signs
                             IOTP) sings it
                                                        |
                                                        v an
                    sends it to the Consumer

     C <-- M        Components: Delivery; Organisations (Delivery
                    Handler, Deliver To); Order, Optional Offer Respons
                    Signature

 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 informatio
                    to                        Signature (Offer) the Delivery Handler.
             |
             v Handler

     C --------> D  DELIVERY REQUEST. Components: Delivery; Delivery,
                    Organisations: (Merchant, Delivery Handler,
                    DelivTo); Order, Optional Offer Response Signature,
                    Optional Payment Receipt Signature (from Payment
                    Exchange)

 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 not tot the
                    Consumer which can optionally be signed
                                                      |
                                                      v signed.

     C <-------- D  DELIVERY RESPONSE. Components: Delivery Note,
                    Optional Delivery Response Signature

 5.                 Consumer checks delivery    <---------  Component: Delivery note is OK and accepts or
                    waits   Delivery      Note; Signature for delivery as described in     Response    (Delivery Response) the the Delivery Note
                    Note.

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

                        Figure 4 Delivery Exchange

  A Delivery Exchange uses the following Trading Components that are
  passed between the Consumer, the Merchant and the Delivery Handler:

      o The Organisation Component(s) contain details of the
        Deliver To, Delivery Handler and Merchant Roles:
       - the Deliver To role indicates where the goods or services are
         to be delivered to
       - the Delivery Handler role is required so that the Delivery
         Handler can check that she is the correct Delivery Handler to
         do the delivery
       - the Merchant role is required so that the Delivery Handler can
         identify which Merchant initiated the delivery

      o The Order Component, contains information about the goods
        or services to be delivered

      o The Delivery Component contains information about how
        delivery will occur, for example by post or using e-mail.

      o The "Offer Response" Signature Component, if present,
        digitally signs all of the above components to ensure their
        integrity.

      o The "Payment Receipt" Signature Component provides proof of
        payment by digitally signing the Payment Receipt Component
        and the Offer Signature. This is used by the Delivery
        Handler to check that delivery is authorised

      o The Delivery Note Component contains customer care
        information related to a physical delivery, or
        alternatively the actual "electronic goods". The Consumer's
        software does not interpret information about a physical
        delivery but should have the ability to display the
        information, both at the time of the delivery and later if
        the Consumer selects the Trade to which this delivery
        relates from a transaction list

      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

+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1            IOTP MESSAGE           ORGANISATION
 (Authenticatee)
     |   Organisation 2
    (AUTHENTICATEE)                                 (AUTHENTICATOR)
     |  (Authenticator)
STEP |     |
 1.          First organisation,                            2. The second
e.g e.g. a consumer, Consumer, takes an                      organisation generates action (for
             example by   ---------------->     Authentication Data pressing a button on an       Need for         containing challenge HTML page) which       Authentication       data, the method of
             requires that the organisation is authenticated

     1 --> 2 Need for Authentication (outside scope of  authentication to be used
    organisation is IOTP)

 2.          The second organisation generates an Authentication
             Request - including challenge data, and optionally a list of the
             algorithms that may be used for the authentication -
             and/or a request
     authenticated for the Organisation information then
             sends it to the first organisation
                                                         |
                                                         v

     1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
             Request, Trading Role Information Request

 3.          The first organisation                          Component: optionally checks any signature  <------------    Authentication Data
             associated with the Authentication
  Authentication request then Request then uses the challenge data with
 the
             specified authentication
     method algorithm to generate an
             Authentication Response which is sent back to the second
             organisation together with details of any Organisation
             information requested
       |
       v

     1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
             Response, Organisation(s)

 4.          The Authentication Response is
Authentication   -------------> checked against the
             challenge data to
   Response      Authentication check that the first organisation is
                    Response who
             they appear to be and the result recorded in a Status
             Component which is then sent back to the first
                                             organisation
                                                         |
                                                         v
             organisation.

     1 <-- 2 AUTHENTICATION STATUS. Component: Status

 5.          The first organisation then                     Component: Status optionally checks the results   <------------
     of
             indicated by 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 Request Component which contains the challenge
    data to be used in the "challenge-response" mechanism, that requests an
        Authentication and indicates the authentication method to be used algorithm
        and optionally
    request Organisation optional challenge data to be used.

      o A Trading Role Information Request Component that requests
        information about the first organisation, an Organisation, for example a ship to or
        billing address. It is sent by one
    organisation to the other.

      o The Authentication Response Component which contains the
        challenge response generated by the recipient of the
        Authentication Data Request Component. It is sent back to the first
    organisation for verification together with

      o Organisation Components requested that contain the result of the
        Trading Role Information Request

      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._ "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 IOT
  are described in more detail in section 2.1 Trading Roles. To
  summarise the roles are: Merchant, Consumer, Payment Handler, Delivery Deliver
  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
                       Issuer  Acquirer             Handler   Handler

 TRANSACTIONS

Purchase        Must                       Must

Refund          Must                        b)
                                          Depends

Authentication   May    Must      May       b)
                                          Depends

Value Exchange   May                       Must

Withdrawal              Must                b)
                                          Depends

Deposit                          Must       b)
                                          Depends

Inquiry         Must    Must     Must      Must       Must      Must

Ping            Must    Must     Must      Must       Must      Must
                       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
                       Merchants

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

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

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

Offer Response  Must    Must     Must      Must

Payment                                    Must       Must
Request

Payment                                    Must       Must
Exchange

Payment                                    Must       Must
Response

Delivery                                   Must                 Must
Request
                       Merchants

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

Delivery                                   Must                 Must
Response

Inquiry         Must    Must     Must      Must       Must      Must
Request

Inquiry         Must    Must     Must      Must       Must      Must
Response
                       Merchants

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

Ping Request    Must    Must     Must      Must       Must      Must

Ping Response   Must    Must     Must      Must       Must      Must

Signature       Must    Must     Must     Limited     Must      Must

Error           Must    Must     Must      Must       Must      Must

  In the above table:

      o _Must_ "Must" means that a Trading Role must support the
        Transaction or Trading Block.

      o _May_ "May" means that an implementation may support the
        Transaction or Trading Block at the option of the
        developer.

      o _Depends_ "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 Customer Care
        Provider, and

      o Trading Exchanges where each Trading Exchange involves the
        exchange of data, between Trading Roles, in the form of a
        set of Trading Components.

  This section describes:

      o how Trading Components are constructed into Trading Blocks
        and the IOTP Messages which are physically sent in the form
        of [XML] documents between the different Trading Roles,

      o how IOTP Messages are exchanged between Trading Roles to
        create an IOTP Transaction

      o the XML definitions of an IOTP Message including a
        Transaction Reference Block - an XML element which
        identifies an IOTP Transaction and the IOTP Message within
        it

      o the definitions of the XML ID Attributes which are used to
        identify IOTP Messages, Trading Blocks and Trading
        Components and how these are referred to using Element
        References from other XML elements

      o an overview of Brands and Brand Selection which describes how a
    Consumer can select a Brand from a list provided by the
    Merchant

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

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

      o how IOTP Identifies Languages so that different languages
        can be used within IOTP Messages

      o how IOTP handles both Secure and 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.

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

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

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

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

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

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
                       Figure 7 An IOTP Transaction

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

  The IOTP Transactions (see section 8) 9) 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
        one Trading Role by another Trading Role using a variety of
        authentication methods, algorithms, and the provision of an
        Organisation
    Component Information about a Consumer to another the Trading Role that is
        being authenticated for use in,
    for example use in, for example, the creation
        of an offer

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

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

      o Inquiry This supports inquiries on the status of an IOTP
        transaction which is either in progress or is complete

      o Ping This supports a simple query which enables one IOTP
        aware application to determine whether another IOTP
        application running elsewhere is working or not.

  3.2 IOTP Message

  As described earlier, IOTP Messages are [XML] documents which are
  physically sent between the different Trading Roles that are taking
  part in a trade.

  The XML definition of an IOTP Message is as follows.

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

  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 9
OfferRespBlk,      Internet Open Trading Protocol Transactions.
PayExchBlk,
PayReqBlk,         Full definitions of each Trading Block are
PayRespBlk,        described in section 7. 8.
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 therefor
  needs to be preceded by an appropriate XML Document Prolog. For
  example:

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

  3.3 Transaction Reference Block

  A Transaction Reference Block contains information which identifies
  the IOTP Transaction and IOTP Message. The Transaction Reference Block Bloc
  contains:

      o a Transaction Id Component which globally uniquely
        identifies the IOTP Transaction. The Transaction Id
        Components are the same across all IOTP messages that
        comprise a single IOTP transaction,

      o a Message Id Component which provides control information
        about the IOTP Message as well as uniquely identifying the
        IOTP Message within an IOTP Transaction, and

      o zero or more Related To Components which link this IOTP
        Transaction to either other IOTP Transactions or other
        events using the identifiers of those events.

  The definition of a Transaction Reference Block is as follows:

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

  Attributes:

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

  Content:

TransId             See 3.3.1 Transaction Id Component immediately
                    below.

MsgId               See 3.3.2 Message Id Component immediately
                    below.

RelatedTo           See 3.3.3 Related To Component immediately
                    below.

  3.3.1 Transaction Id Component

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

<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
 ID                 ID      #REQUIRED
 Version            NMTOKEN #FIXED '1.0'
 OtpTransId
 IotpTransId         NMTOKEN #REQUIRED
 OtpTransType
 IotpTransType       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

IotpTransId         Contains data which uniquely identifies the IOTP
                    Transaction. It must conform to the rules for
                    Message Ids in [RFC 822].

OtpTransType

IotpTransType       This is the type of IOTP Transaction being
                    carried out. For Baseline IOTP it identifies a
                    "standard" IOTP Transaction and implies the
                    sequence and content of the IOTP Messages
                    exchanged between the Trading Roles. The valid
                    values for Baseline IOTP are:
                    o BaselineAuthentication
                    o BaselineDeposit
                    o BaselinePurchase
                    o BaselineRefund
                    o BaselineWithdrawal
                    o BaselineValueExchange
                    o BaselineInquiry
                    o BaselinePing

                    Values of OtpTransType IotpTransType are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes 12 IANA
                    Considerations which also allows user defined
                    values of OtpTransType IotpTransType 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. Transaction. 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
 RespIotpMsg         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

RespIotpMsg           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

SenderTradingRoleRef  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) 3.9) 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 3.8 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 3.8 Identifying Languages.

RelationshipType    Defines the type of the relationship. Valid
                    values are:
                    o OtpTransaction. IotpTransaction. in which case the Packaged
                      Content Element contains an OtpTransId IotpTransId of
                      another IOTP Transaction
                    o Reference in which case the Packaged Content
                      Element contains the reference of some other,
                      non-IOTP document.

                    Values of RelationshipType are controlled under
                    the procedures defined in section 3.7.3 Values
                    for IOTP Codes 12 IANA
                    Considerations which also allows user defined
                    values to be defined.

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

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

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

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

  Content:

PackagedContent     The Packaged Content (see section 3.8) 3.7) 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 eac
  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 attribut
  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 th
  content of any IOTP Message, Block or Component from any other IOTP
  Message, Block or Component in the same IOTP Transaction using Element Elemen
  References (see section 3.5).

  This section defines the rules for setting the values for the ID
  attributes of IOTP Messages, Blocks and Components.

  3.4.1 IOTP Message ID Attribute Definition

  The ID attribute of the Message Id Component of an IOTP Message must
  be unique within an IOTP Transaction. It's definition is as follows:

OtpMsgId_value

IotpMsgId_value  ::= OtpMsgIdPrefix OtpMsgIdSuffix
OtpMsgIdPrefix IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix  ::= NameChar (NameChar)*
OtpMsgIdSuffix
IotpMsgIdSuffix  ::= Digit (Digit)*

OtpMsgIdPrefix

IotpMsgIdPrefix     Apart from messages which contain an Inquiry
                    Request Trading Block (see section 7.12), 8.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

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

OtpMsgId_value

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

IOTP MESSAGE                               IOTP MESSAGE *
 |-Trans Ref Block. ID=M1.1                 |-Trans Ref Block.ID=C1.1*
 |  |-Trans Id Comp. ID = M1. ------------->| M1.2 ------------>|  |-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. -------------------------->|-Comp. ID=M1.4
 |  |                         Copy Element     |
 |  |-Comp. ID=M1.5 --------- ---------------->|-Comp. -------------------------->|-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 ID=M1.9
    |-Comp. ID=M1.4 ID=M1.10                             * = new elements
    |-Comp. ID=M1.5 ID=M1.11
    |-Comp. ID=M1.6 ID=M1.12
    |-Comp. ID=M1.7 ID=M1.13

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

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

IOTP MESSAGE                               IOTP MESSAGE
 |-Trans Ref Block. ID=M1.1     Trans ID    |-Trans Ref Block. ID=C1.1
 |  |-Trans Id Comp. ID = M1. <-Components--|->|-Trans M1.2 <-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 Ref=M1.5
 |  |-Comp. ID=M1.7                            |-Comp. ID=C1.4
 |
 |-Trading Block. ID=M1.3 ID=M1.9
    |-Comp. ID=M1.4 ID=M1.10
    |-Comp. ID=M1.5 ID=M1.11
    |-Comp. ID=M1.6 ID=M1.12
    |-Comp. ID=M1.7 ID=M1.13

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

                       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 Extending IOTP is the ability for

  Baseline IOTP defines a merchant minimum protocol which systems supporting IOT
  must be able to offer
  a list accept. As new versions of Brands from which a consumer may make a selection. This
  section provides an overview IOTP are developed,
  additional types of what is involved IOTP Transactions will be defined. In addition to
  this, Baseline and provides guidance
  on how selection future versions of a brand and associated payment instrument can be
  carried out by a Consumer. It covers: IOTP will support user
  extensions to IOTP through two mechanisms:

      o definitions of Payment Instruments extra XML elements, and Brands - what are
    Payment Instruments

      o new values for existing IOTP codes.

  3.6.1 Extra XML Elements

  The XML element and Brands in an attribute names used within IOTP context. Further
    categorises Brands constitute an
  [XML Namespace] as optionally a "Dual Brand" or a
    "Promotional Brand",

  o identification and selection identified by the xmlns attribute on the
  IotpMessage element. This allows IOTP to support the inclusion of Promotional Brands -
    Promotional Brands offer a Consumer some
  additional benefit,
    for example loyalty points or XML elements within IOTP messages through the use of [XML
  Namespaces].

  Using XML Namespaces, extra XML elements may be included at any level
  within an IOTP message including:

      o new Trading Blocks

      o new Trading Components

      o new XML elements within a discount. This means that both
    Consumers and Merchant Trading Component.

  The following rules apply:

      o any new XML element must be able declared according to correctly identify that
    a valid Promotional Brand is being used.

  Also see the following sections: rules
        for [XML Namespaces]
      o Brand List Component (section 6.6) which contains definitions
    of the new XML elements which are either Trading Blocks or Trading
        Components must contain the list an ID attributes with an attribute
        name of Brands offered by
    a Merchant ID.

  In order to a Consumer, and

  o Brand Selection Component (section 6.7) for details make sure that extra XML elements can be processed
  properly, IOTP reserves the use of how a
    Consumer records special attribute, IOTP:Critical
  which takes the Brand that was selected.

  3.6.1 Definition values True or False and may appear in extra elements
  added to an IOTP message.

  The purpose of Payment Instrument

  A Payment Instrument this attribute is to allow an IOTP aware application t
  determine if the means by which a Consumer pays for goods
  or services offered by a Merchant. It IOTP transaction can be, for example: safely continue. Specifically:

      o if an extra XML element has an "IOTP:Critical" attribute
        with a credit card such as MasterCard or Visa;

  o 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 debit card such as MasterCard's Maestro; Technical Error (see
        section 4.1) and must fail.

      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 if an account number, by
  which the Payment Instrument can be identified.

  3.6.2 Definition of Brand

  A Brand is the mark which identifies extra XML element has an "IOTP:Critical" attribute
        with a particular type of Payment
  Instrument. A list value of Brands are "False" then the payment options which are
  presented by IOTP transaction may
        continue if the Merchant IOTP aware application does not know how to the Consumer and from which the Consumer
  makes a selection. Each Brand may have a different Payment Handler.
  Examples of Brands include:

  o payment association and proprietary Brands, for example
    MasterCard, Visa, American Express, Diners Club, Mondex,
    GeldKarte, CyberCash, etc.

  o promotional brands (see below). These include:
        process it. In this case:
       - store brands, where any extra XML elements contained within an XML element defined
         within the Payment Instrument IOTP namespace, must be included with that element
         whenever the IOTP XML element is issued to a Consumer
      by a particular Merchant, for example Walmart, Sears, used or Marks and
      Spencer (UK) copied by IOTP
       - 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 the content of Dual Brand

  A Dual Brand means the extra element must be ignored except that a single payment instrument may
         it must be included when it is used in the creation of a
         digest as part of the generation of a signature

      o if an extra XML element has no "IOTP:Critical" attribute
        then it were two separate Brands. For example there could be a single
  Japanese "UC" MasterCard which can must be used treated as either a UC card or if it had an "IOTP:Critical"
        attribute with a
  regular MasterCard. The UC card Brand and the MasterCard Brand could
  each have their own separate Payment Handlers. This means that: value of "True"

      o if an XML element contains an "IOTP:Critical" attribute,
        then the merchant treats, for example "UC" and "MasterCard" as two
    separate Brands when offering a list value of Brands that attribute is assumed to apply to all
        the Consumer,

  o child elements within that element

  In order to ensure that documents containing "IOTP:Critical" are
  valid, it is declared as part of the consumer chooses a Brand, DTD for example either "UC" or
    "MasterCard,

  o the consumer extra element as:

IOTP:Critical      (True | False ) #TRUE

  3.6.2 Opaque Embedded Data

  If IOTP aware application determines which Payment
    Instrument(s) match is to be extended using Opaque Embedded Data then a Packaged
  Content Element (see section 3.7) should be used to encapsulate the chosen Brand, and selects, perhaps with
    user assistance,
  data.

  3.7 Packaged Content Element

  The Packaged Content element supports the correct Payment Instrument concept of an embedded data
  stream, transformed to use.

  [Note]   Dual Brands need no special treatment both protect it against misinterpretation by the Merchant
  transporting systems and
           therefore no explicit reference is made to Dual Brands ensure XML compatibility. Examples of its
  use in
           the DTD. This is because, as far as the Merchant is
           concerned, each Brand in a Dual Brand is treated IOTP include:

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

      o to encapsulate a
           separate Brand. It is at the Consumer, that the matching description of an order, a Brand to payment note,
        or a Dual Brand Payment Instrument needs delivery note.

  In general it is used to be done.
  [Note End]
  3.6.4 Definition of Promotional Brand

  A Promotional Brand means that, if the Consumer pays with encapsulate one or more data streams.

  This data stream has three standardised attributes that Brand,
  then allow for
  identification, decoding and interpretation of the Consumer will receive some additional benefit which can be
  received in two ways:

  o contents. Its
  definition is as follows.

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

  Attributes:

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

                    The name attribute may be omitted, for example
                    if a Consumer pays with a
    "Walmart MasterCard" at a Walmart web site, then a 5% discount
    might apply, which means there is only one Packaged Content element.

Content             This identifies what type of data is contained
                    within the consumer actually pays less, Content of the Packaged Content
                    Element. The valid values for the Content
                    attribute are as follows:
                    o from their Payment Instrument (card) issuer when PCDATA. The content of the payment
    appears on their statement. For example loyalty points in a
    frequent flyer scheme could Packaged Content
                      Element can be awarded based on the total
    payments made treated as PCDATA with the Payment Instrument since the last
    statement was issued.

  Note that: no
                      further processing.
                    o the first example (obtaining the benefit at the time MIME. The content of
    purchase), requires that:
    - the Consumer Packaged Content
                      Element is informed a complete MIME item. Processing
                      should include looking for MIME headers inside
                      the Packaged Content Element.
                    o MIME:mimetype. The content of the benefits which arise if that Brand Packaged
                      Content Element is selected
    - if MIME content, with the Brand
                      following header "Content-Type: mimetype".
                      Although it is selected, the Merchant changes the relevant IOTP
      Components in the Offer Response possible to reflect have MIME:mimetype
                      with the correct amount Transform attribute set to
      be paid

  o the second (obtaining a benefit through the Payment Instrument
    issuer) does not require NONE, it
                      is far more likely to have Transform attribute
                      set to BASE64. Note that the Offer Response if Transform is changed

  o each Promotional Brand should NONE
                      is used, then the entire content must still
                      conform to PCDATA. Some characters will need
                      to be identified encoded either as a separate Brand
    in the list XML default
                      entities, or as numeric character entities.
                    o XML. The content of Brands offered by the Merchant. For example:
    "Walmart", "Sears", "Marks and Spencer" and "American Advantage
    Visa", would each Packaged Content
                      Element can 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 treated as an XML document.
                      Entities and CDATA sections, or their Payment Handler positively
    identify the promotional brand being Transform set
                      to BASE64, must be used at to ensure that the time
                      Packaged Content Element contents are
                      legitimate PCDATA.

                    Values of
    purchase

  o how does the Consumer reliably identify Content attribute are controlled
                    under the correct promotional
    brand from procedures defined in section 12 IANA
                    Considerations which also allows user defined
                    values to be defined.

Transform           This identifies the Brand List presented by transformation that has been
                    done to the Merchant data before it was placed in the
                    content. Valid values are:
                    o NONE. The following is a description PCDATA content of how this could be achieved.

  [Note]   Please note that the approach described here Packaged
                      Content Element is a model
           approach that solves the problem. Other equivalent methods
           may be used.
  [Note End]

  3.6.5.1 Merchant/Payment Handler Identification correct representation
                      of Promotional Brands

  Correct identification the data. Note that entity expansion must
                      occur first (i.e. replacement of &amp; and
                      &#9;) before the Consumer data is paying using examined. CDATA
                      sections may legitimately occur in a Promotional
  Brand Packaged
                      Content Element where the Transform attribute
                      is important since a Consumer might fraudulently claim set to have a
  Promotional Brand that offers a reduced payment amount when in reality
  they do not.

  Two approaches seem possible: NONE.
                    o use some feature BASE64. The PCDATA content of the Payment Instrument or the payment
    method to positively identify the Brand being used. For
    example, the SET certificate for Packaged
                      Content Element represents a BASE64 encoding
                      of the Brand could be used, if
    one actual content.

  Content:

PCDATA              This is available, or

  o use the Payment Instrument (card) number to look up information
    about actual data which has been embedded.
                    The format of the Payment Instrument data and rules on a Payment Instrument issuer
    database how to determine if
                    decode it are contained in the Payment Instrument is a
    promotional brand

  Note that:

  o Content and the first assumes
                    Transform attributes

  Note that SET is available.

  o the second is only possible if the Merchant, or alternatively any special details, especially custom attributes, must be
  represented at a higher level.

  3.7.1 Packaging HTML

  The packaged content may contain HTML. In this case the Payment Handler, has access following
  conventions are followed:

      o references to card issuer information.

  IOTP does not provide the Merchant with Payment Instrument information
  (e.g. a card any documents, images or account number). This is only sent other things, such
        as part of sounds or web pages, which can affect the
  encapsulated payment protocol to a Payment Handler. This means that:

  o recipient's
        understanding of the Merchant would have data which is being packaged must
        refer to assume that other Packaged Elements contained within the Payment Instrument
    selected was a valid Promotional Brand, or same
        parent element, e.g. an Order Description

      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 more than one Packaged Content element is included
        within a valid Promotional Brand
  is most likely if parent element in order to meet the Payment Handler is also previous
        requirement, then the Card Issuer.

  3.6.5.2 Consumer Selection Name attribute of Promotional Brands

  Two ways by the top level
        Packaged Content from which a Consumer references to all other
        Packaged Elements can correctly select be determined, should have a Promotional Brand
  are: value of
        Main

      o the Consumer visually matching a logo for the Promotional Brand
    which has been provided relative references to the Consumer other documents, images, etc. from
        one Packaged Content element to another are realised by
        setting 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 value of Brands offered by the
    Merchant.

  In the latter case, the code contained in the Consumer wallet must
  match exactly relative reference to the code in Name
        attribute of another Packaged Content element at the list offered by same
        level and within the Merchant otherwise same parent element

      o no match will be found. Ways in which external references that require the Consumer's IOTP Aware
  Application reference to be
        resolved immediately should be used. As this could obtain such a code include:

  o the Consumer types make the code in directly. This
        HTML difficult or impossible to display completely

      o [MIME] is error prone
    and not user friendly, also the consumer needs used to be provided
    with encapsulate the code. data inside each Packaged
        Element. This approach is not recommended,

  o using some means that the 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 MIME header
        used to identify the payment software type of data which handles has been
        encapsulated and therefore how it should be displayed.

  If the
      particular payment method, this could apply to, above conventions are not followed by, for example,
      GeldKarte, Mondex, CyberCash and DigiCash

  o the consumer making a initial "manual" link between a
    Promotional Brand in including
  external references which must be resolved, then the list recipient of Brands offered by the Merchant
    and
  HTML should be informed.

  [Note]   As an individual Payment Instrument, implementation guideline the first time values of the
    promotional brand is used. The IOTP Aware application would Name
           Attributes allocated to Packaged Content elements should
           make it possible to extract each Packaged Content into a
           directory and then "remember" the code for display the Promotional Brand HTML directly
  [Note End]

  3.7.2 Packaging XML

  Support for use in
    future purchases

  [Note]   It XML is not the intention of recommended. When XML needs to be displayed, for
  example to display the developers content of this
           specification an Order Description to develop a prescriptive list Consumer,
  then implementers should follow the latest recommendations of payment
           brands. It the
  World Wide Web Consortium.

  [Note]   At the time of writing this specification, standards are
           under development that specify XML style sheets that show
           how XML documents should be displayed. See:

           o "Extensible Stylesheet Language (XSL) Specification" at
             http://www.w3.org/TR/WD-xsl, and

           o "Associating stylesheets with XML documents" at
             http://www.w3.org/TR/xml-stylesheet.

           Once these standards become W3C "Recommendations", then it
           is anticipated that owners of brands this specification will develop
           distinctive names for Brands which should mean that name
           clashes are unlikely. be amended if
           practical.
  [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

  3.8 Identifying Languages

  IOTP Transactions will be defined. In addition uses [XML] Language Identification to
  this, Baseline specify which languages ar
  used within the content and future versions attributes of IOTP will support user
  extensions Messages.

  The following principles have been used in order to IOTP through two mechanisms:

  o extra determine which
  XML elements, and elements contain an xml:lang Attributes:

      o new values for existing IOTP codes.

  3.7.1 Extra XML Elements

  The XML element and a mandatory xml:lang attribute names used within IOTP constitute 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
  [XML Namespace] as identified by the xmlns optional xml:lang attribute is included on the OtpMessage
  element. This allows IOTP to support the inclusion of additional XML child
        elements within IOTP messages through of these Trading Components. In this case the use
        value of [XML Namespaces].

  Using XML Namespaces, extra XML elements may be included at any level
  within an IOTP message including:

  o new xml:lang, if present, overrides the value for the
        Trading Blocks

  o new Component.

  xml:lang attributes which follow these principles are included in the
  Trading Components

  o new and their child XML elements within a Trading Component.

  The following rules apply:

  o any new XML element must defined in section 7.

  3.9 Secure and Insecure Net Locations

  IOTP contains several "Net Locations" which identify places where,
  typically, IOTP Messages may be declared according to the rules for
    [XML Namespaces] sent. Net Locations come in two types

      o new XML elements "Secure" Net Locations which are net locations where
        privacy of data is secured using, for example, encryption
        methods such as [SSL/TLS], and
      o "Insecure" Net Locations where privacy of data is not
        assured.

  Note that either Trading Blocks a Secure Net Location or Trading
    Components must contain an ID attributes with an attribute name Insecure Net Location or
  both must be present.

  If only one of ID.

  In order to make sure that extra XML elements can the two Net Locations is present, then the one present
  must be processed
  properly, IOTP reserves used.

  Where both types of net location are present then either may be used
  depending on the use preference of a special attribute, IOTP:Critical,
  which takes the values True or False and may appear sender of the message.

  3.10 Cancelled Transactions

  Any Trading Role involved in extra elements
  added to an IOTP message.

  The purpose of this attribute is to allow transaction may cancel that
  transaction at any time.

  3.10.1 Cancelling Transactions

  IOTP Transactions are cancelled by sending an IOTP aware application message containing
  just a Cancel Block with an appropriate Status Component to
  determine if the other
  Trading Role involved in the Trading Exchange.

  [Note]   The Cancel Block can be sent asynchronously of any other
           IOTP transaction Message. Specifically it can safely continue. Specifically:

  o if an extra XML element has be sent either before
           sending or after receiving an "IOTP:Critical" attribute with a
    value of "True" and IOTP Message from the other
           Trading Role
  [Note End]

  If an IOTP aware application does not know how
    to process Transaction is cancelled during a Trading Exchange (i.e.
  the element interval between sending a "request" block and its child elements, receiving the
  matching "response" block) then the Cancel Block is sent to the same
  location as the next IOTP Message in the Trading Exchange would have
  been sent.

  If a Consumer cancels a transaction has after a Technical Error (see section 4.1) and must
    fail.

  o if an extra XML element Trading Exchange has an "IOTP:Critical" attribute with a
    value of "False" then
  completed (i.e. the IOTP transaction may continue if "response" block for the Trading Exchange has bee
  received), but before the IOTP aware application does not know how to process it. In this
    case:
    - any extra XML elements contained within Transaction has finished then the
  Consumer sends a Cancel Block with an XML element defined
      within appropriate Status Component to
  the net location identified by the SenderNetLocn or
  SecureSenderNetLocn contained in the Protocol Options Component (see
  section 7.1) contained in the TPO Block (see section 8.1) for the
  transaction. This is normally the Merchant Trading Role.

  A Consumer should not send a Cancel Block after the IOTP namespace, must Transaction
  has completed. Cancelling a complete transaction should be included with that element
      whenever treated as
  a technical error.

  After cancelling the IOTP XML element is used or copied Transaction, the Consumer should go to the
  net location specified by IOTP
    - the content of CancelNetLocn attribute contained in th
  Trading Role Element for the extra element must be ignored except organisation that it
      must be included when it is used in was sent the creation of Cancel
  Block.

  A non-Consumer Trading Role should only cancel a digest as
      part of the generation of transaction:

      o after a signature request block has been received and

      o if an extra XML element before the response block has no "IOTP:Critical" attribute then been sent

  If a non-Consumer Trading Role cancels a transaction at any other tim
  it must should be treated by the recipient as if it had an "IOTP:Critical" attribute
    with error.

  3.10.2 Handling Cancelled Transactions

  If a value of "True"

  o if an XML element contains an "IOTP:Critical" attribute, then
    the value of that attribute Cancel Block is assumed to apply to all received by a Consumer at a point in the
    child elements within that element

  In order to ensure that documents containing "IOTP:Critical" are
  valid, it IOTP
  Transaction when cancellation is declared as part of allowed, then the DTD for Consumer should
  stop the extra element as:

IOTP:Critical      (True | False ) #TRUE

  3.7.2 Opaque Embedded Data transaction.

  If IOTP a Cancel Block is to be extended using Opaque Embedded Data then received by a Packaged
  Content Element (see section 3.8) non-Consumer role, then the Tradin
  Role should be used anticipate that the Consumer may go to encapsulate the
  data.

  3.7.3 Values for IOTP Codes

  Codes used by IOTP are registered location
  specified by [IANA] so that new values can be
  co-ordinated based on an IETF consensus as defined in RFC 2434.

  The element types, attributes names to which this procedure applies is
  shown in the table below together with CancelNetLocn attribute contained in the original values Trading Rol
  Element for
  attributes which apply. For more up-to-date information on valid
  values and how these relate to versions of the Trading Role.

  4. IOTP Error Handling

  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 designed as a brand
                               which is accepted by the [SET] payment request/response protocol

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

CurrencyAmount   CurrCode      TBD. Codes which apply when the
                               CurrCodeType  attribute each message is set to IOTP
  composed of a number of Trading Blocks which contain a number of
  Trading Components. There are to be defined

CurrencyAmount   CurrCodeType  ISO4217 several interrelated considerations in
  handling errors, re-transmissions, duplicates, and the like. These
  factors mean IOTP

DeliveryData     DelivMethod   Post

                               Web

                               Email

PackagedContent  Content       PCDATA

                               MIME

                               MIME:mimetype (where mimetype aware applications must be manage message flows more
  complex than the same as content-type simple request/response model. Also a wide variety o
  errors can occur in messages as defined by
                               [MIME] )

                               XML

PayProtocol      ProtocolId    The values of ProtocolId are to be
                               defined by well as at 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 transport level or in
  Trading Blocks or Components.

  This section describes at a need for developers to experiment using new high level how IOTP codes. For this reason, "user defined codes" may be used to
  identify additional values for the codes contained within this
  specification with handles errors,
  retries and idempotency. It covers:

      o the need for them to be registered with IANA.

  The definition different types of a user defined code errors which can occur. This is as follows:

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

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

  Use
        divided into:
       - "technical errors" which are independent 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 purpose of its
  use in the
         IOTP include:

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

  o to encapsulate a description of an order, Message,
       - "business errors" which indicate that there is a problem
         specific to the process (e.g. payment note, or a
    delivery note.

  In general it delivery) which is used to encapsulate one or more data streams.

  This data stream has three standardised attributes that allow for
  identification, decoding
         being carried out, and interpretation of

      o the contents. Its
  definition is as follows.

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

  Attributes:

Name                Optional. Distinguishes between multiple
                    occurrences depth 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 error which indicates whether the error is contained
                    within
        at the Content of transport, message or block/component level

      o how the Packaged Content
                    Element. The valid values for different trading roles should handle the Content
                    attribute different
        types of messages which they may receive.

  4.1 Technical Errors

  Technical Errors are as follows:
                    o PCDATA. The content those which are independent of the Packaged Content
                      Element meaning of th
  message. This means, they can be treated as PCDATA affect any attempt at IOTP
  communication. Typically they are handled in a standard fashion with no
                      further processing.
                    o MIME. The content
  limited number of the Packaged Content
                      Element is a complete MIME item. Processing
                      should include looking standard options for MIME headers inside the Packaged Content Element. user. Specifically these
  are:

      o MIME:mimetype. The content of retrying the Packaged
                      Content Element is MIME content, with transmission, or

      o cancelling the
                      following header "Content-Type: mimetype".
                      Although it transaction.

  When communications are operating sufficiently well, a technical erro
  is possible to have MIME:mimetype
                      with indicated by an Error Component (see section 7.20) in an Error
  Block (see section 8.17) sent by 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 party which detected the entire content must still
                      conform to PCDATA. Some characters will need error i
  an IOTP message to be encoded either as the XML default
                      entities, or as numeric character entities.
                    o XML. party which sent the erroneous message.

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

  The content of Error Codes associated with Technical Errors are recorded in the Packaged Content
                      Element
  Error Component which lists all the different technical errors which
  can be treated as an XML document.
                      Entities and CDATA sections, or Transform set
                      to BASE64, must be used to ensure that set.

  4.2 Business Errors

  Business Errors may occur when the
                      Packaged Content Element contents IOTP messages are
                      legitimate PCDATA.

                    Values of the Content attribute "technically"
  correct. They are controlled
                    under the procedures defined in section 3.7.3
                    Values connected with a particular process, for IOTP Codes which also allows user
                    defined values to be defined.

Transform           This identifies the transformation that example, a
  offer, payment, delivery or authentication, where each process has been
                    done to the data before it was placed 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
                    content. Valid values are:
                    o NONE. The PCDATA content Status Component (see section 7.15) of a "response
  block" of the Packaged
                      Content Element appropriate type, for example a Payment Response Block
  or a Delivery Response Block. This allows whatever additional respons
  related information is needed to accompany the correct representation
                      of error indication.

  Business errors must usually be presented to the data. Note user so that entity expansion must
                      occur first (i.e. replacement of &amp; and
                      &#9;) before they ca
  decide what to do next. For example, if the data error is examined. CDATA
                      sections may legitimately occur insufficient
  funds in a Packaged
                      Content Element where Brand Independent Offer (see section 9.1.2.2), the Transform attribute
                      is set user
  might wish to NONE.
                    o BASE64. The PCDATA content choose a different payment instrument/account of the Packaged
                      Content Element represents
  same brand or a BASE64 encoding
                      of different brand or payment system. Alternatively, if
  the actual content.

  Content:

PCDATA              This is IOTP based implementation allows it and it makes sense for that
  instrument, the actual data which has been embedded.
                    The format of user might want to put more funds into the data
  instrument/account and rules on how to
                    decode it try again.

  4.3 Error Depth

  The three levels at which IOTP errors can occur are contained in the Content transport
  level, the message level, and the
                    Transform attributes

  Note that any special details, especially custom attributes, must be
  represented at a higher block level.

  3.8.1 Packaging HTML

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

  o references to any documents, images or other things, such as
    sounds or web pages, which can affect the recipient's
    understanding Each is described
  below.

  4.3.1 Transport Level

  This level of error indicates a fundamental problem in the data transport
  mechanism over which is being packaged must refer to
    other Packaged Elements contained within the same parent
    element, e.g. an Order Description
  o if more than one Packaged Content element IOTP communication is included within taking place.

  All transport level errors are technical errors and are indicated by
  either an explicit transport level error indication, such as a
    parent element in order "No
  route to meet the previous requirement, then
    the Name attribute of the top level Packaged Content destination" error from which
    references TCP/IP, or by a time out where no
  response has been received to all other Packaged Elements can be determined,
    should have a value request.

  The only reasonable automatic action when faced with transport level
  errors is to retry and, after some number of Main. This means that the "Main"
    Packaged Content element must not be referred automatic retries, to from
  inform the HTML
    in any other Packaged Content

  o relative references to other documents, images, etc. from one
    Packaged Content element to another user.

  The explicit error indications that can be received are realised by setting transport
  dependent and the
    value of documentation for the relative reference appropriate IOTP Transport
  supplement should be consulted for errors and appropriate actions.

  Appropriate time outs to the Name attribute use are a function of
    another Packaged Content element at both the same level transport
  being used and within of the same parent element

  o no external references that require payment system if the reference to be
    resolved immediately request encapsulates
  payment information. The transport and payment system specific
  documentation should be used. As this could make the
    HTML difficult or impossible to display completely

  o [MIME] consulted for time out and automatic retry
  parameters. Frequently there is used to encapsulate the data inside each Packaged
    Element. This means that the information in the MIME header
    used no way to identify directly inform the type other
  party of data which has been encapsulated
    and therefore how it transport level errors but they should generally be displayed.

  If the above conventions are not followed by, for example, including
  external references which must be resolved, then the recipient of logged
  and if automatic recovery is unsuccessful and there is a human user,
  the
  HTML user should be informed.

  [Note]   As

  4.3.2 Message Level

  This level of error indicates a fundamental technical problem with an implementation guideline
  entire IOTP message. For example, the values of XML is not "Well Formed", or th
  message is too large for the Name
           Attributes allocated receiver to Packaged Content elements should
           make handle or there are errors i
  the Transaction Reference Block (see section 3.3) so it is not
  possible to extract each Packaged Content into a
           directory and then display figure out what transaction the HTML directly
  [Note End]

  3.9 Identifying Languages

  IOTP uses [XML] Language Identification to specify which languages message relates to.

  All message level errors are
  used within the content technical errors and attributes of IOTP Messages.

  The following principles have been used in order are indicated by
  Error Components (see section 7.20) sent to determine which
  XML elements contain an xml:lang Attributes:

  o the other party. The Erro
  Component includes a mandatory xml:lang Severity attribute is contained on every Trading
    Component which contains attributes or content which indicates whether the
  error is a Warning and may need
    to be displayed or printed in ignored, 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 TransientError which follow these principles are included in
  indicates that a retry may resolve the
  Trading Components and their child XML elements defined problem or a HardError in whic
  case the transaction must fail.

  The Technical Errors (see 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 7.20.2 Error Codes) that are net locations where privacy of
    data is secured using, for example, encryption methods such as
    [SSL], and Messag
  Level errors are:

      o "Insecure" Net Locations where privacy of data XML not well formed. The document is not assured.

  Where both types of net location are present, the following rules
  apply: well formed XML
        (see [XML])

      o either a Secure Net Location or an Insecure Net Location or
    both must be present XML not valid. The document is not valid XML (see [XML])

      o if only one of block level technical errors (see section 4.3.3) on the two Net Locations is present, then
        Transaction Reference Block (see section 3.3) and the one
    present must
        Signature Block only. Checks on these blocks should only be used

  o
        carried out if both are present, then the either may be used depending XML is valid
  Note that checks on the preference of Signature Block include checking, where
  possible, that each Signature Component is correctly calculated. If
  the sender of Signature is incorrectly calculated then the message.

  3.11 Cancelled Transactions

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

  3.11.1 Cancelling Transactions

  IOTP Transactions are cancelled should hav
  been covered by sending an IOTP message containing
  just the signature can not be trusted and must be treated
  as erroneous. A description of how to check a Cancel signature is correctly
  calculated is contained in section 6.2.

  4.3.3 Block Level

  A Block level error indicates a problem with a block or one of its
  components in an appropriate Status Component to IOTP message (apart from Transaction Reference or
  Signature Blocks). The message has been transported properly, the other
  Trading Role involved in
  overall message structure and the Trading Exchange.

  [Note]   The Cancel Block can be sent asynchronously block/component(s) including the
  Transaction Reference and Signature Blocks are meaningful but there i
  some error related to one of any the other
           IOTP Message. Specifically it blocks.

  Block level errors can be sent either before
           sending either:

      o technical errors, or after receiving an IOTP Message from the other
           Trading Role
  [Note End]

      o business errors

  Technical Errors are further divided into:

      o Block Level Attribute and Element Checks, and

      o Block and Component Consistency Checks

      o Transient Technical Errors

  If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
  the interval between sending technical error occurs related to a _request_ block and receiving the
  matching _response_ block) or component, then the Cancel Block an
  Error Component is sent to the same
  location as generated for return.

  4.3.3.1 Block Level Attribute and Element Checks

  Block Level Attribute and Element Checks occur only within the next IOTP Message 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 the Trading Exchange would have
  been sent.

  If a Consumer cancels a transaction after a Trading Exchange has
  completed (i.e. the "response"
        block for the Trading Exchange has been
  received), but before the conforms to any rules contained within this IOTP Transaction has finished then
        specification

      o checking that the
  Consumer sends a Cancel Block with an appropriate Status Component content of each element conforms to any
        rules contained within this IOTP specification
      o if the net location identified by previous checks are OK, then checking the SenderNetLocn
        consistency of attribute values and element content against
        other attribute values or
  SecureSenderNetLocn contained element content within any other
        components in the Protocol Options same block.

  4.3.3.2 Block and Component
  contained in the TPO Consistency Checks

  Block for the transaction. This is normally and Component Consistency Checks consist of:

      o checking that the
  Merchant Trading Role.

  A Consumer should not send a Cancel Block after combination of blocks and/or components
        present in the IOTP Transaction.
  Cancelling a complete should be treated as a technical error.

  After cancelling Message are consistent with the rules
        contained within this IOTP Transaction, the Consumer should go to specification

      o checking for consistency between attributes and element
        content within the
  net location specified by blocks within the CancelNetLocn attribute contained same IOTP message.

      o checking for consistency between attributes and elements in the
  Trading Role Element
        blocks in this IOTP message and blocks received in earlier
        IOTP messages for the organisation that was sent same IOTP transaction

  If the Cancel
  Block.

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

  o after a request block has been received passes the "Block Level Attribute and

  o before Element Checks" an
  the response block has been sent

  If a non-Consumer Trading Role cancels a transaction at any other time "Block and Component Consistency Checks" then it should be treated by the recipient is an error.

  3.11.2 Handling Cancelled Transactions

  If a Cancel Block is received processed
  either by a Consumer at a point in the IOTP
  Transaction when cancellation is allowed, then Aware application or perhaps by some "back-end"
  system such as a payment server.

  4.3.3.3 Transient Technical Errors

  During the Consumer should
  stop processing of the transaction.

  If a Cancel Block is received some temporary failure may occur
  that can potentially be recovered by a non-Consumer role, then the Trading
  Role should anticipate other trading role re-
  transmitting, at some slightly later time, the original message that
  they sent.

  In this case the Consumer may go to other role is informed of the location
  specified Transient Error by
  sending them an Error Component (see section 7.20) with the CancelNetLocn attribute contained in Severity
  Attribute set to TransientError and the Trading Role
  Element MinRetrySecs attribute set to
  some value suitable for the Trading Role.

  4. IOTP Error Handling

  IOTP is designed as a request/response Transport Mechanism and/or payment
  protocol where each message is
  composed of a number being used (see appropriate Transport and payment protocol
  Supplements).

  Note that transient technical errors can be generated by any of the
  Trading Blocks which contain a number of
  Trading Components. There are a several interrelated considerations Roles involved 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 transaction.

  4.3.3.4 Block Level Business Errors

  If a wide variety of
  errors can occur business error occurs in messages as well a process such as at the transport level or in
  Trading Blocks a Payment or Components.

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

  o
  Delivery, then the different types appropriate type of errors which can occur. This response block is divided
    into:
    - "technical errors" which are independent of returned
  containing a Status Component (see section 7.15) with the meaning ProcessStat
  attribute set to Failed and the CompletionCode indicating the nature
  of the
      IOTP Message,
    - "business errors" which indicate problem.

  Some business errors may be "transient" in that there is a problem specific
      to the process (e.g. payment or delivery) which is being carried
      out, Consumer role may
  be able to recover and

  o complete the depth of transaction in some other way. Fo
  example if the error which indicates whether Credit Card that a consumer provided had insufficient
  funds for a purchase, then the error Consumer may recover by using a
  different credit card.

  Recovery from "transient" business errors is at
    the transport, message or block/component level

  o how dependent on the different trading roles should handle
  CompletionCode. See the different
    types definition of the Status Component for what i
  possible.

  Note that no Error Component or Error Block is generated for business
  errors.

  4.4 Idempotency, Processing Sequence, and Message Flow

  IOTP messages which they may receive.

  4.1 Technical Errors

  Technical Errors are those which are independent of the meaning actually a combination of the
  message. This means, they can affect any attempt at blocks and components as
  described in 3.1.1 IOTP
  communication. Typically they are handled Message Structure. Especially in a standard fashion with a
  limited number future
  extensions of standard options for the user. Specifically these
  are:

  o retrying the transmission, or

  o cancelling the transaction.

  When communications are operating sufficiently well, IOTP, a technical error rich variety of combinations of such blocks and
  components can occur. It is indicated by an Error Component (see section 0) in an Error Block
  (see section 7.17) sent by important that the party which detected multiple
  transmission/receipt of the error "same" request for an action that will
  change state does not result in that action occurring more than once.
  This is called idempotency. For example, a customer paying for an
  IOTP message
  order would want to pay the party which sent the erroneous message.

  If communications are too poor, full amount only once. Most network
  transport mechanisms have some probability of delivering a message which was sent may
  more than once or not reach
  its destination. In this case at all, perhaps requiring retransmission. On th
  other hand, a time-out might occur.

  The Error Codes associated with Technical Errors are recorded in Error
  Components 6.19) which lists all the different technical errors which request for status can reasonably be set.

  4.2 Business Errors

  Business Errors may occur when the repeated and shoul
  be processed fresh each time it is received.

  Correct implementation of IOTP messages are "technically"
  correct. They are connected with can be modelled by a particular process, for example, an
  offer, payment, delivery or authentication, where each process has a
  different set of possible business errors.

  For example, "Insufficient funds"
  processing order as detailed below. Any other method that is a reasonable payment error but
  makes no sense for a delivery while "Back ordered"
  indistinguishable in the messages sent between the parties is a reasonable
  delivery error but not meaningful for a payment. Business errors equally
  acceptable.

  4.5 Server Role Processing Sequence

  "Server roles" are
  indicated in any Trading Role which is not the Status Component (see section 6.14) of Consumer role.
  They are "Server roles" since they typically receive a "response
  block" of the appropriate type, for example request which
  they must service and then produce a Payment Response Block
  or response. However server roles
  can also initiate transactions. More specifically Server Roles must b
  able to:

      o Initiate a Delivery Response Block. This allows whatever additional response transaction (see section 4.5.1). These are
        divided into:
       - payment related information is needed to accompany transactions and
       - infrastructure transactions
      o Accept and process a message received from another role
        (see section 4.5.2). This includes:
       - identifying if the error indication.

  Business errors must usually be presented message belongs to a transaction that has
         been received before
       - handling duplicate messages
       - generating Transient errors if the user so servers that they can
  decide what process the
         input message are too busy to do next. For example, if handle it
       - processing the error message if it is insufficient
  funds error free, authorised and, if
         appropriate, producing a response to send back to the other
         role

      o Cancel a current transaction if requested (see section
        4.5.3)

      o Re-transmit messages if a response was expected but has not
        been received in a Brand Independent Offer reasonable time (see section 8.1.2.2), the user
  might wish to choose 4.5.4).

  4.5.1 Initiating Transactions

  Server Roles may initiate a variety of different payment instrument/account types of the
  same brand or transaction
  Specifically:

      o an Inquiry Transaction (see section 9.2.1)

      o a different brand or payment system. Alternatively, if Ping Transaction (see section 9.2.2)

      o an Authentication Transaction (see section 9.1.6)

      o a Payment Related Transaction such as:
       - a Deposit (see section 9.1.7)
       - a Purchase (see section 9.1.8)
       - a Refund (see section 9.1.9)
       - a Withdrawal (see section 9.1.10)
       - a Value Exchange (see section 9.1.11)

  4.5.2 Processing Input Messages

  Processing input messages involves the IOTP based implementation allows it and it makes sense for that
  instrument, following:

      o checking the user might want to put more funds into structure and identity of the
  instrument/account message

      o checking for and try again.

  4.3 Error Depth

  The three levels at handling duplicate messages

      o processing non-duplicate original messages which IOTP includes:
       - checking for errors, then if no errors can occur are the transport
  level, found
       - processing the message level, and the block level. to produce an output message if
         appropriate
  Each is described
  below.

  4.3.1 Transport Level

  This level of error indicates a fundamental problem these is discussed in more detail below.

  4.5.2.1 Checking Structure and Message Identity

  It is critical to check that the transport
  mechanism over which the IOTP communication message is taking place.

  All transport level errors are technical errors "well formed" XML and are indicated by
  either tha
  the transaction identifier (IotpTransId attribute on the TransId
  Component) within the IOTP message can be successfully identified
  since an explicit transport level error indication, such as a "No
  route IotpTransId will be needed to destination" error from TCP/IP, or by generate a time out where no
  response has been received to a request.

  The only reasonable automatic action when faced with transport level
  errors response.

  If the input message is to retry and, after some number not well formed then generate an Error
  Component with a Severity of automatic retries, to
  inform the user.

  The explicit error indications that can be received are transport
  dependent HardError and ErrorCode of
  XmlNotWellFrmd.

  If the documentation for appropriate IOTP Transport
  supplement should message is well formed but the IotpTransId cannot be consulted for errors and appropriate actions.

  Appropriate time outs to use are identifie
  then generate an ErrorComponent with:

      o a function Severity of both the transport
  being used HardError and an ErrorCode of AttMissing,

      o one PackagedContent containing the payment system if the request encapsulates
  payment information. The transport original Input Message,
        and payment system specific
  documentation should be consulted for time out

      o the second PackagedContent containing "IotpTransId" - the
        missing attribute.

  Insert the Error Component inside an Error Block with a new
  TransactionId component with a new IotpTransId and automatic retry
  parameters. Frequently there is no way return it to directly inform the other
  party
  sender 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 original message.

  4.5.2.2 Checking/Handling Duplicate Messages

  If the input message can be informed.

  4.3.2 Message Level

  This level of error indicates identified as potentially a fundamental technical problem with valid input
  message then check to see if an
  entire IOTP message. For example, the XML is not _Well Formed_, or the "identical" input message is too large for has been
  received before. Identical means that all blocks, components,
  elements, attribute values and element content in the receiver to handle or there input message
  are errors in the Transaction Reference Block (see section 3.3) so it is not
  possible same.

  If an identical message has been received before then check to figure out what transaction see if
  the processing of the previous message relates to.

  All has completed.

  If processing has not completed then do nothing as the processing of
  the previous message level errors are technical errors will result in a response if required.

  Otherwise, if processing has completed and are indicated by resulted in an
  Error Components (see section 6.19) output
  message then retrieve the last message that was sent to and send it
  again.

  If the other party. The Error
  Component  includes message is not a Severity attribute which indicates whether duplicate then it should be processed.

  4.5.2.3 Processing Non-Duplicate Message

  Once it's been established that the
  error message is not a Warning and may duplicate, then
  it can be ignored, a TransientError which
  indicates processed. This involves:

      o checking that a retry may resolve server is available to handle the problem or message,
        generating a HardError in which
  case the transaction must fail.

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

  o XML not well formed. The document if it is not well formed XML (see
    [XML])

      o XML not valid. The document checking the Transaction is not valid XML (see [XML]) Not Already in error or
        cancelled

      o validating the input message. This includes:
       - checking for message level errors
       - checking for block level technical errors (see section 4.3.3) on the
    Transaction Reference Block (see section 3.3) and
       - checking any encapsulated data

      o checking for errors in the Signature
    Block only. Checks on these sequence that 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
        received

      o generating error components for any errors that result

      o if no hard errors result, then processing the signature can not be trusted message and
  must be treated as erroneous. A description
        generating an output message, if required, for return to
        the sender of how the Input Message

  [Note]   This approach to check a
  signature is correctly calculated is contained handling of duplicate input messages means,
           if absolutely "identical" messages are received then
           absolutely "identical" messages are returned. This also
           applies to Inquiry and Ping transactions when in section 5.2 Checking
  a Signature is Correctly Calculated.

  4.3.3 Block Level

  A Block level error indicates a problem with reality the
           state of a block transaction or one the processing ability of its
  components in the
           servers may have changed. If up-to-date status of
           transactions or servers is required, then an IOTP message (apart from Transaction Reference or
  Signature Blocks).
           transaction with a new IotpTransId must be used.
  [Note End]

  Each of the above steps is discussed below.

  CHECKING A SERVER IS AVAILABLE

  The message has been transported properly, process that is handling the
  overall input message structure and should check that the block/component(s) including
  rest of the
  Transaction Reference and Signature Blocks are meaningful but there system is
  some not so busy that a response in a reasonable tim
  cannot be produced.

  If the server is too busy, then it should generate an Error Component
  with a transient error related and send it back to one the sender of the other blocks.

  Block level errors can Input
  Message requesting that the original message be either: resent after an
  appropriate period of time.

  [Note]   Some servers may occasionally become very busy due to
           unexpected increases in workload. This approach allows short
           peaks in workloads to be handled by delaying the input of
           messages by asking the sender of the message to resubmit
           later.
  [Note End]

  CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED

  Check that:

      o technical errors, previous messages received or

  o business errors

  Technical Errors are further divided into:

  o Block Level Attribute and Element Checks, sent did not contain or
        result in Hard Errors, and

      o Block and Component Consistency Checks

  If a technical error occurs related to a block the Transaction has not been cancelled by either the
        Consumer or component, then an
  Error Component is returned and, unless the Server Trading Role

  If it is merely a warning, has then, ignore 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 message. A transaction with hard errors or
  that has been cancelled, cannot be restarted.

  CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS

  If 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: transaction is still OK then check for message level errors.
  This involves:

      o checking that each attribute value within each element in a
    block conforms to any rules contained within this IOTP
    specification the XML is valid

      o checking that the elements, attributes and content of each element conforms the
        Transaction Reference Block are without error and conform
        to any rules
    contained within this IOTP specification

      o if the previous checks are OK, then checking the consistency of
    attribute values digital signature which involves:
       - checking that the Signature value is correctly calculated, and element content against other attribute
       - the hash 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: digests are correctly calculated where
         the source of the hash value is available.

  Checking for block level errors involves:

      o checking that within each block (apart from the combination Transaction
        Reference Block) that:
       - the attributes, elements and element contents are valid
       - the values of blocks and/or components
    present in the IOTP Message attributes, elements and element contents
         are consistent with the rules
    contained within this IOTP specification the block

      o checking for consistency between attributes and element content
    within that the combination of blocks within the same IOTP message. are valid

      o checking for consistency between attributes and that the values of the attribute, elements in and
        element contents are consistent between the blocks in this IOTP the
        input message and blocks received in earlier IOTP messages for either sent or
        received. This includes checking that the same IOTP presence of a
        block is valid for a particular transaction

  4.3.3.3 type
  If the message contains any encapsulated data, then if possible check
  the encapsulated data for errors using additional software to check
  the data where appropriate.

  4.5.2.4 Check for Errors in Block Business Sequence

  Errors

  If a business error occurs in a process such as a Payment or a
  Delivery, then the appropriate type of response block is returned. The
  Status Component (see section 6.14) within sequence that response block
  indicates blocks arrive depends on the error block. Block
  where checking for sequence is required are:

      o Error and its severity. No Cancel Blocks. If an Error Component or Error Cancel Block refers
        to an IOTP transaction that is generated not recognised then it is a
        Hard Error. Do not return an error if Error or Cancel
        Blocks have been received for business errors.

  4.4 Idempotency, Processing Sequence, and Message Flow the IOTP messages are actually a combination of blocks Transaction before
        to avoid looping.

      o Inquiry Request and components as
  described in 3.1.1 Response Blocks. If an Inquiry Request
        or an Inquiry Response Block refers to an IOTP Message Structure. Especially in future
  extensions of IOTP, a rich variety of combinations of such blocks and
  components can occur. It is important transaction
        that the multiple
  transmission/receipt of the "same" request for state changing action is not result in that action occurring more than once. This recognised then it is called
  idempotency. For example, a customer paying for Hard Error

      o Authentication Request Block. If an order would want Authentication Request
        Block refers 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 an IOTP transaction that is recognised it
        is received.

  Correct implementation of IOTP can be modelled by a particular
  processing order Hard Error

      o Authentication Response Block. Check as detailed below. Any other method follows:
       - if an Authentication Response Block does not refer to an IOTP
         transaction that is
  indistinguishable in recognised it is a Hard Error, otherwise
       - if the messages Authentication Response Block doesn't refer to an
         Authentication Request that had been previously 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 it
         is a response.

  The model processing sequence Hard Error, otherwise
       - if an Authentication Response for a Server role is indicated in the
  diagram below.

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

                            -------------
                           |    Input    |
                           | same IOTP Message|
                            -------------
                                  |
                                  v
                           1. transaction
         has been received before and the Authentication was successful
         then it is a Hard Error.

      o Authentication Status Block. Check for transport -------------->
                           or message level errors   Errors      |
                                      |OK                        |
                                      v                          |
   11. Generate output <-------2. More Blocks <----------------- + as follows:
       -
         message               No    to process?                 |  |
            |                        |Yes                        |  |
            v                         v                          |  |
      -------------           3. Check if an Authentication Status Block OK ---------------> |  |
     |    Output   |                 |               Errors      |  |
     | does not refer to an IOTP Message|                 |Checks OK                  |  |
      -------------                  v                           |  |
                    ---------4. Type of  Block ? -------         |  |
                   |           |           |            |        |  |
      ---------Status       Action   Encapsulating     Error     |  |
     |         Request      Request      Block         Block     |  |
     |                         |           |             |       |  |
     |                         v           v             v       |  |
     |                 6a. Action     7. Process     8.Error     |  |
     |                  Request
         transaction that is recognised it is a Hard Error, otherwise
       -    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     |   |       | if the Authentication Status     and resend     process      request &     |   |       |
  Response     previous     completion    response      |   |       | Block        Block                       block       |   |       |
     |            |                           |         v   v       |
      ---------------------------------------------- 10. Add block-- doesn't refer to output
                                                     message

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

                Figure 10 Server Role Processing Sequence

  Each of the processes in the sequence an
         Authentication Response that had been previously sent then it
         is described in more detail
  below.

  4.4.1.1 Check for Transport or Message Level Error

  On receipt of a Hard Error, otherwise
       - if an IOTP request message (step 1), first check Authentication Status 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 same IOTP transaction or, if has
         been received before then 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 is a response message with an
  appropriate Warning Error Component. Perform local actions such

      o TPO Selection Block (Merchant only). Check as making log
  entries.

  If the value of follows:
       - if the OtpTransId attribute is not recognised as
  belonging TPO Selection Block doesn't refer to an IOTP transaction when other Blocks in the IOTP Message
  indicate
         Transaction that it should be recognised, is recognised then report the error using an
  Error Component with it is a Severity of HardError, an ErrorCode set Hard Error,
         otherwise
       - if the TPO Selection Block refers 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 IOTP Transaction where
         a response message
  (step 11) TPO Block and send Offer Response (in one message) had previously
         been sent then it to is a Hard Error, otherwise
       - if the requester unless there are fatal
  transport level problems. As recommended TPO Selection Block does not refer to an IOTP
         Transaction where a TPO Block only (i.e. without an Offer
         Response) had previously been sent then it is a Hard Error,
         otherwise
       - if a TPO Selection Block for the particular transport
  used, same TPO Block has been
         received before then it is 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 Hard Error

      o Payment Request Block (Payment Handler only). Check as
        follows:
       - if the requester Payment Request Block refers to receive a response may lead an IOTP Transaction
         that is not recognised then its OK, otherwise
       - if the Payment Request Block refers to IOTP Transaction that
         was not for a
  time-out and Payment then it is a retransmission of the request. Following Hard Error, otherwise
       - if the procedures
  above, previous payment CompletedOk OR failed with a duplicate request message should produce non-
         recoverable Completion Code then it is a duplicate of Hard Error, otherwise
       - if the previous response except for changes payment is still in status and transient error
  conditions that have changed.

  4.4.1.3 progress then it is a Hard
         Error

      o Payment Exchange Block (Payment Handler only). Check as
        follows:
       - if the Payment Exchange Block doesn't refer to an IOTP
         Transaction that is OK

  Check the block recognised then it 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 a Hard Error,
         otherwise
       - if the Payment Exchange doesn't refer to an IOTP Message Transaction
         where a Payment Exchange had previously been sent back to the Consumer.
  Note that some checking of then it a
         Hard Error

      o Delivery Request (Delivery Handler Only). If the Transaction Reference Delivery
        Request Block and refers to an IOTP Transaction that is
        recognised by the
  Signature Block has occurred as part of Message Level error checking. Server then it is a Hard Error

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

  4.4.1.4 Determine then collect them into an
  Error Block for sending to the Type sender of the Block

  Trading Blocks Input message. Note that survive
  Error Blocks should be sent back to the above steps sender of the message and thus have no errors,
  or at worst have added a warning error component to
  the response, can
  receive further processing. The nature ErrorLogNetLocn for the Trading Role of the processing depends (step
  4) sender if one is
  specified.

  [Note]   The above checking on whether the block is a Status Request, Action Request, an Error
  Block or contains an Encapsulated Message.

  4.4.1.5 Status Request Blocks

  Status Request Blocks (step 5) are either:

  o Inquiry Request Trading Block (see section 7.12), or sequence of Authentication
           Responses and Payment Requests supports the Consumer re-
           submitting a repeat action request since the previous one
           failed, for example:

           o Ping Request Block (see section 7.14).

  These status requests do because they did not change state and are processed fresh to
  get know the current status. The appropriate correct response block should be added (e.g. a
             password) on an authentication or,

           o they were unable to pay as there were insufficient funds
             on a credit card
  [Note End]
  PROCESS THE ERROR FREE INPUT MESSAGE

  If the IOTP input 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 passes the previous checks then it can be subject to
  idempotency duplicate filtering by checking
  processed to see produce an output message if required. Note that:

      o Inquiry Requests on Ping Transactions should be ignored

      o if the same block Input message contains an Error Block with a
        Transient Error then wait for the same transaction has been previously stored (step 6a) at the
  server as described later.

  If required time then resend
        the Block has been received previously then: previous message

      o if the input message contains a Error Component with a
        HardError or a Cancel Block then stop all further
        processing of the previously stored block is complete (step
    6b) then transaction. This includes suppressing
        the same IOTP Block as previously produced must be
    included for resending sending of any messages currently being generated or
        responding to the Consumer (step 6c). any new non-duplicate messages that are
        received

      o if processing is not complete, wait until the processing is
    complete (step 6d) before sending the response.

  If of encapsulated messages (e.g. Payment Protocol
        Messages) may result in additional transient errors

      o a digital signature can only safely be generated once all
        the block has not blocks and components have been received before, the action request is
  processed normally (step 6e) producing a response block that generated and it is added
  to
        known which elements in the response message. This might or might not indicate a business
  error. message need to be signed.

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

  If there resent as required if an identical input message is received
  again. Note that output messages that contain transient errors are no Transient Error, then the transaction id, the request
  block, and the response block must be stored (step 6f)
  saved so that they can be
  found as described above (step 6a) should a duplicate IOTP action
  request block be processed afresh when the input message is
  received for this again.

  4.5.3 Cancelling a Transaction

  This process cancels a current transaction in the future.

  [Note]   Most business errors should be labelled on an IOTP server as a TransientError
           as there
  result of an external request from another system or server. The
  processing required is usually some possibility they will as follows:

      o if the IotpTransId of the transaction to be corrected
           over time cancelled not
        recognised, or some user action exists that can fix them.
           Requesters are expected complete then fail the request, otherwise

      o if the IotpTransId refers to understand business errors and Inquiry Transaction or a Ping
        Transaction then fail the appropriate time scale for user actions for retrying.
  [Note End]

  4.4.1.7 Encapsulating Blocks

  Blocks request, otherwise

      o determine which encapsulate a payment protocol (step 7) pass along the
  enclosed information Document Exchange to the payment system involved.

  IOTP does not know the meaning of the enclosed information. It is thus
  up cancel and generate a
        Cancel Block and send it to the payment system involved to handle error detection and
  idempotency. Payment systems adapted other party
  4.5.4 Retransmitting Messages

  The server should periodically check for the Internet include
  idempotency handling because duplicates are always possible. Should transactions where a
  payment system have no idempotency handling, message
  is expected in return but none has been received after a layer between IOTP and time that is
  dependent on factors such as:

      o the payment system must be added to take care of this.

  No IOTP level idempotency actions are Transport Mechanism being used;

      o the time required for encapsulating
  blocks. The payment system must return material to be process encapsulated in
  the IOTP response message along with indications as to messages (e.g.
        Payment messages) and

      o whether the
  exchange will continue or this not human input is the final response and an indication
  whether an error occurred. required.

  If a payment protocol error no message has occurred,
  an Error Component is added to been received the response block.

  4.4.1.8 Error Block Received

  An error block (step 8) should not occur in a request block and original message should be treated as an unexpected element with resent
  This should occur up to a Severity maximum number of HardError.

  Error Blocks are sent by Consumers to potentially two locations:

  o times dependent on the _request_ location, i.e.
  reliability of the location from which they Transport Mechanism being used.

  If no response is received after the IOTP message that contained the error, and

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

  The ErrorLogNetLocn block may
  Transaction should be the same location as the _request_
  location. "timed out". In this case, set the error block must not considered as a fatal
  error.

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

  4.4.1.9 Generate Error Block

  If any process stat
  of the previous steps resulted in an error being detected transaction to Failed, 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 completion code of either:

      o TimedOutRcvr if the original Response
  Block is received again, then it transaction can be processed as potentially recovered
        later, or

      o TimedOutNoRcvr 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 transaction is non-recoverable

  4.6 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
           purchases or downloading or withdrawing electronic cash.
  [Note End]
  The model processing sequence for

  More specifically the Consumer Role must be able to:

      o Initiate a Client transaction (see section 4.6.1). These are
        divided into:
       - payment related transactions and
       - infrastructure transactions

      o Accept and process a message received from another role is indicted in
        (see section 4.6.2). This includes:
       - identifying if the
  diagram below.

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

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

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

                Figure 11 Client Role Processing Sequence

Each of
       - handling duplicate messages
       - generating Transient errors if the processes in servers that process 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
         input message level errors (see sections 4.3.1 and 4.3.2).
  These are errors which indicate that too busy to handle it
       - processing the entire message is corrupt and
  can not reliably be associated with any particular transaction or, if it can be associated with is error free and, if
         appropriate, producing a transaction, response to send back to the interior information in other
         role

      o Cancel a current transaction if requested, for example by
        the message can User (see section 4.6.3)

      o Re-transmit messages if a response was expected but has not be reliably accessed. Set up
        been received in a reasonable time (see section 4.6.4).

  4.6.1 Initiating Transactions

  The Consumer Role may initiate a number of different types of
  transaction. Specifically:

      o an error indication
  message with Inquiry Transaction (see section 9.2.1)

      o a Ping Transaction (see section 9.2.2)

      o an Error Component indicating the error.

  If the value Authentication Transaction (see section 9.1.6)

  4.6.2 Processing Input Messages

  Processing of the OtpTransId attribute Input Messages for a Consumer Role is not recognised the same as
  belonging to an for a
  IOTP transaction when other Blocks Server (see section 4.5.2) except in the area of checking for
  Errors in Block Sequence (for an IOTP Message
  indicate that it should be recognised, then report Server see section 4.5.2.4).
  This is described below

  [Note]   The description of the error using processing for 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 IOTP Server
           includes consideration of automatic re-
  transmissions multi-threading of input messages
           and multi-tasking of requests. For the request. If Consumer Role -
           particularly if running on a user stand-alone system such as a PC
           - use of multi-threading is present, they may be
  offered options a decision of continuing to retransmit the request or implementer of
  cancelling the transaction.

  4.4.2.2 Process all
           the blocks

  If there are no transport or message level errors, process each consumer role IOTP solution.
  [Note End]

  4.6.2.1 Check for Errors in Block Sequence

  The handling of the following blocks within is the message which has not been processed (step 2).

  Once all same as for an IOTP Serve
  (see section 4.5.2.4) except that the Consumer Role is substituted fo
  IOTP Server Role:

      o Error and Cancel Blocks,

      o Inquiry Request and Response Blocks,
      o Authentication Request, Response and Status Blocks.

  For the other blocks have been processed, check to see if there are any
  blocks to be sent (step 11). There may be no a Consumer role might receive, the potential
  errors in the sequence that blocks to send if arrive depends on the
  last response message received was block. Block
  where checking for sequence is required are:

      o TPO Block. Check as follows:
       - if the last input message of the
  transaction.

  If blocks are to be sent also contains an Authentication Request
         block and an Offer Response Block then generate there is a request Hard Error,
         otherwise
       - if the input message (step 12) also contains an Authentication Request
         block and
  send it to the server. It may be desirable to log Authentication Status block then there is Hard Error
         otherwise,
       - if the complete request input message at also contains an Authentication Request
         block and the client. Failure of IOTP Transaction is recognised by the server to receive a response may
  lead to a time-out and Consumer
         role's system, then there is a retransmission of Hard Error, otherwise
       - if the request.

  4.4.2.3 Check input message also contains an Authentication Status
         block and the Block IOTP Transaction is OK

  If not recognised by the
         Consumer role's system then there are no is a Hard Error, otherwise
       - if input message level errors process each of the blocks within also contains an Authentication Status Block
         and the Authentication Status Block has not been sent after an
         earlier Authentication Response message (step 2).

  Check the block then there is OK (see section 4.3.3). For each block level a hard
         error
  found, an appropriate Error Component should be created to be included
  in
       - if input message also contains an Error Component sent back to Offer Response Block and the Server.

  If one or more of
         IOTP Transaction is recognised by the Error Components contain a Severity attribute
  with Consumer role's system
         then there is a value of TransientError or HardError, no further processing of Hard Error, otherwise
       - if the block should occur TPO Block occurs on its own and it is likely that this will result in
  termination of the transaction.

  4.4.2.4 Determine IOTP Transaction is
         recognised by the Type of Consumer role's system then there is a Hard
         Error

      o Offer Response Block. Check as follows:
       - if the Offer Response Block

  Trading Blocks is not part of an IOTP Transaction
         that survive is recognised by the above steps and thus have no errors,
  or at worst have added Consumer role then there is a warning error component to the error
  indication message, can receive further processing. The nature of Hard
         Error, otherwise
       - if the
  processing depends (step 4) on whether Offer Response Block does not refer to an IOTP
         transaction where a TPO Selection Block was the block last message
         sent then there is a Status Response,
  Action Response, an Hard Error Block or contains an Encapsulated Message.

  4.4.2.5 Status Response Blocks

  Status Response Blocks (step 4) are either:

  o Inquiry Response Trading Blocks (see section 7.13), or

      o Ping Response Blocks (see section 7.15)

  In general, such blocks should be considered a status update. The best
  action to take at Payment Exchange Block. Check as follows:
       - if the requester may depend on whether this is in
  response Payment Exchange Block doesn't refer to a user originated or automatic status request, whether a
  status display an IOTP
         Transaction that could be updated is being presented to recognised by the user,
  and whether Consumer role's system
         then there is a Hard Error, otherwise
       - if the status response block shows Payment Exchange doesn't refer to an IOTP Transaction
         where either a change in status from Payment Request or a
  previous response Payment Exchange 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 was
         most recently sent then there is a Hard Error

      o Payment Response Blocks Block. Check to determine as follows:
       - if the Payment Response Block has been received previously (step
  6a). If it has then it should be ignored.

  These indicate doesn't refer to an action taken at IOTP
         Transaction that is recognised by the server in response Consumer role's system
         then there is a Hard Error, otherwise
       - if the Payment Response doesn't refer to an action
  request block IOTOP Transaction
         where either a Payment Request or a business error. If the response indicates success
  the Payment Exchange block should be processed (step 6b) and, was
         most recently sent then there is a Hard Error

      o Delivery Response Block. Check as follows:
       - if required by the
  transaction (step 6c), another Action Request Block generated and
  stored (step 6d).

  The Delivery Response Block should always be stored with the transaction id
  until doesn't refer to an IOTP
         Transaction that is recognised by the transaction Consumer role's system
         then there is terminated. a Hard Error, otherwise
       - If the Delivery Response Block indicates a
  transient business error, appropriate manually chosen or automatic
  steps doesn't refer to fix the problem an IOTP Transaction
         where either a Payment Request or cancel the a Payment Exchange block was
         most recently sent then there is a Hard Error

  4.6.3 Cancelling a Transaction

  This process cancels a current transaction should be provided.

  4.4.2.7 Encapsulating Blocks

  Blocks which encapsulate on an Consumer role's
  system as a payment protocol (step 7) pass along the
  enclosed information to result of an external request from the payment user, or another
  system involved.

  IOTP does not know the meaning of or server in the enclosed information. It Consumer's role. The processing 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, same a layer between
  for an IOTP and
  the payment system must be added to take care Server (see section 4.5.3).

  4.6.4 Retransmitting Messages

  The process of this.

  No IOTP level idempotency actions are required retransmitting messages is the same as for encapsulating
  blocks. The payment system must return an indication of whether IOTP
  Server (see section 4.5.4).

  5. Security Considerations

  This section considers, from an
  error occurred. In addition, for a continuing exchange, IETF perspective how IOTP addresses
  security. The next section (see section 6. Digital Signatures and
  IOTP) describes how IOTP uses Digital Signatures when these are
  needed.

  This section covers:

      o determining whether to use digital signatures

      o data privacy, and

      o payment protocol security.

  5.1 Determining whether to use digital signatures

  The use of digital signatures within IOTP are entirely optional. IOTP
  can work successfully entirely without the use of digital signatures.

  Ultimately it must return
  material is up to be encapsulated in the next Merchant, or other trading role, to decide
  whether IOTP request/exchange (step
  6d). If Messages will include signatures, and for the response was Consumer t
  decide whether carrying out a final response for transaction without signatures is an
  acceptable risk. If Merchants discover that payment exchange transactions without
  signatures are not being accepted, then they will either:

      o start using signatures,

      o find a method of working which does not need signatures, or

      o accept a lower volume and there was an error, value of business.

  A non-exhaustive list of the payment system may optionally return
  material to reasons why digital signatures might be encapsulated in
  used follows:

      o the error indication.

  4.4.2.8 Error Block

  An error block in Merchant (or other trading role) wants to demonstrate
        that they can be trusted. If, for example, a response (step 8a) indicates some problem was
  detected by merchant
        generates an Offer Response Signature (see section 7.18.2)
        using a certificate from a trusted third party, known to
        the server. If all of Consumer, then the error components Consumer can check the signature and
        certificate and so more reasonably rely on the offer being
        from the actual organisation the Merchant claims to be. In
        this case signatures using asymmetric cryptography are warnings,
  they may be optionally logged and/or presented
        likely to the user.

  Transient errors may be used required
      o the Merchant, or other Trading Role, want to provide generate a manual or automatic
  resending (step 8b)
        record 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, transaction that is fit for a particular
        purpose. For example, with appropriate
  indication to he user.

  4.4.2.9 Generate Error Block

  If an error indication message was created above, try trust hierarchies,
        digital signatures could be checked by the Consumer to send
        determine:
       - if it to
  the unless all of the error components are would be accepted by tax authorities as a valid record
         of a transaction, or
       - if some warranty, for example from a "Better Business Bureau"
         or similar was being provided

      o the warning severity in
  which case attempted transmission Payment Handler, or Delivery Handler, needs to know
        that the server request is optional.

  The net locations consumers send Error Blocks to are:

  o the net location which sent them the IOTP Message which was unaltered and authorised. For example,
        in
    error, this is either:
    - the location specified by the SenderNetLocn or SecureSenderNetLocn
      attribute IOTP, details of how much to pay is sent to the Protocol Options Component if the problem was
      contained Consumer
        in the TPO Block or the Offer Response Block
    - the location and then forwarded to which the Payment Request Block was sent if the
      problem is
        Handler in either a Payment Exchange or a Payment Response
      Block, or
    - the location to which Request. If the Delivery request Block if is not signed,
        the problems
      in Consumer could change the amount due by, for example,
        removing a Delivery Response Block, and

  o if present, digit. If the server identified by Payment Handler has no access to
        the ErrorLogNetLocn
    attribute of original payment information in the Trading Role element identified by Offer Response,
        then, without signatures, the
    SenderTradingRoleRef Payment Handler cannot be
        sure that the Message Id Component.

  4.4.2.10 Add Block to Output Message

  Any Blocks which have data has not been created as a result of processing altered. Similarly, if the block
  received are added to
        payment information is not digitally signed, the output message.

  5. Security Considerations

  This section considers Payment
        Handler cannot be sure who is the security associated with IOTP. It covers:

  o an overview of how IOTP uses digital signatures Merchant that is
        requesting the payment

      o how a Payment Handler or Delivery Handler wants to check provide a
        non-refutable record of the completion status of a signature is correctly calculated

  o how Payment Handlers and
        or Delivery. If a Payment Response or Delivery Handlers check they Response is
        signed, then the Consumer can carry
    out payments later use the record of the
        Payment or deliveries on behalf Delivery to prove that it occurred. This could
        be used, for example, for customer care purposes.

  A non-exhaustive list of a Merchant.

  o how IOTP handles data integrity and privacy

  5.1 Digital Signatures and IOTP

  In general, the reasons why digital signatures when might not
  be used with IOTP: follows:

      o trading roles are always treated as a IOTP Components (see section 6)

  o contain digests combined therefore changes to data made
        by the consumer can be detected. One of the reasons for
        using signatures is so that one trading role can determine
        if data has been changed by the Consumer or more IOTP Components or Trading
    Blocks, possibly including some other Signature Components, in any
    IOTP message within
        party. However if the same IOTP Transaction

  o identify:
    - which Organisation signed (originated) trading roles have access to the signature, and
    - which Organisation(s) should
        necessary data, then it might be possible to compare, for
        example, the receive payment information in the signature Payment Request
        with the payment information in order the Offer Response. Access
        to check that the Action data necessary could be realised by, for example,
        the Organisation should take Merchant and Payment Handler roles being carried out by
        the same organisation on the same system, or the Merchant
        and Payment Handler roles being carried out on different
        systems but the systems can occur.

  The way communicate in which Signatures Components digest one or more elements some way. (Note
        this type of communication is
  illustrated in outside the figure below.

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

IOTP MESSAGE                                  SIGNATURE COMPONENT

IOTP MESSAGE                                   Signature Id = P1.3
 |-Trans Ref Block        digest TransRefBlk   |-Manifest
 |  |      ID=P1.1-----------------------------|->|-Digest of P1.1--
 |  |-Trans Id Comp       digest TransIdComp   |  |                 |
 |  |     ID = M1.2----------------------------|->|-Digest current scope of M1.2--|
 |  |-Msg Id Comp.           digest Signature  |  |                 |
 |  |      ID = P1          -------------------|->|-Digest
        IOTP)
      o the processing cost of M1.5--|
 |                         |   digest element  |  |                 |
 |-IOTPSignatures Block    |  -----------------|->|-Digest the cryptography is too high. For
        example, if a payment is being made of M1.7--|
 |  |       ID=P1.2        | |  digest element |  |                 |
 |  |-Signature ID=P1.3    | |  ---------------|->|-Digest only a few cents,
        the cost of carrying out all the cryptography associated
        with generating and checking digital signatures might make
        the whole transaction uneconomic. Co-locating trading
        roles, could help avoid this problem.

  5.2 Symmetric and Asymmetric Cryptography

  The advantage of C1.4--|
 |  |-Signature ID=M1.5----  | |               |                    |
 |  |-Signature ID=P1.4      | | Points to     |-RecipientInfo*     |
 |  |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6     |
 |  |                        | | Certs to use  |   SignatureValueRef|
 |  |                        | |               |  Points|to Value El|
 |  |                        | |               |        v           |
 |-Trading Block. ID=P1.5    | |                -Value* ID=P1.4:    |
 |  |-Comp. ID=M1.7----------  |                   JtvwpMdmSfMbhK<--|
 |  |                          |                   r1Ln3vovbMQttbBI |
 |  |-Comp. ID=P1.6            |                     J8pxLjoSRfe1o6k|
 |  |                          |                     OGG7nTFzTi+/0<-
 |  |-Comp. ID=C1.4------------
 |  |-Comp. ID=C1.5                         Digital signature of-
                                            SignedData element using certificate
                                            identified by CertRef

  Elements symmetric keys with IOTP is that are digested can no Public Key
  Infrastructure need be in any IOTP Message
       within set up and just the same IOTP Transaction
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 12 Signature Digests

  [Note]   The classic example Merchant, Payment Handler
  and Delivery Handler need to agree the shared secrets to use.

  However the disadvantage of one signature signing another in
           IOTP, symmetric cryptography is when an Offer that the
  Consumer cannot easily check the credentials of the Merchant, Payment
  Handler, etc. that they are dealing with. This is first signed by a Merchant
           creating an "Offer Response" signature, which likely to reduce,
  somewhat, the trust that the Consumer will have carrying out the
  transaction.

  However it should be noted that even if asymmetric cryptography is then later
           signed by a Payment Handler together
  being used, the Consumer does not NEED to be provided with a record of any digita
  certificates as the
           payment creating a "Payment Receipt" signature. In this way, integrity of the payment in an IOTP Transaction transaction is bound determined by, fo
  example, the Payment Handler checking the Offer Response Signature
  copied to the
           Merchant's offer.

  [Note End] Payment Request.

  Note that one Manifest symmetric, asymmetric or both types of cryptography may be associated with multiple signature
  "Value" elements where each Value element contains
  used in a digital signature
  over the same manifest, perhaps using single transaction.

  5.3 Data Privacy

  Privacy of information is provided by sending IOTP Messages between
  the same (or different)
  signature algorithm but various Trading Roles using a different certificate

  This may secure channel such as [SSL/TLS].
  Use of a secure channel within IOTP is optional.

  5.4 Payment Protocol Security

  IOTP is designed to be completely blind to the payment protocol being
  used to allow each potential recipient of effect a signature to
  use different certificates. Specifically payment. From the security perspective, this means
  that IOTP neither helps, nor hinders, the achievement of payment
  security.

  If it will allow is necessary to consider payment security from an IOTP
  perspective, then this should be included in the Merchant payment protocol
  supplement which describes how IOTP supports that payment protocol.

  However what IOTP is designed to
  agreed different shared secrets with their do is to use digital signatures to
  bind together the record, contained in a "response" message, of each
  trading exchange in a transaction. For example IOTP can bind together
  an Offer, a Payment Handler and
  Delivery Handler.

  The detailed definitions of a Signature component is contained Delivery.

  6. Digital Signatures and IOTP

  IOTP can work successfully without using any digital signatures
  although in
  section 6.17.

  The remainder an open networking environment it will be less secure -
  see 5. Security Considerations for a description of the factors that
  need to be considered.

  However, this section contains: describes how to use digital signatures in the
  many situations when they will be needed. Topics covered are:

      o an example overview of how IOTP uses digital signatures

      o how the OriginatorInfo and RecipientInfo elements within a
    Signature Component are used to identify the organisations
    associated with the 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.

  6.1 How IOTP uses Digital Signatures

  In general, signatures may use either Symmetric when used with IOTP:

      o are always treated as IOTP Components (see section 7)

      o contain digests of one or Asymmetric
    Cryptography more IOTP Components or Trading
        Blocks, possibly including other Signature Components, in
        any IOTP message within the same IOTP Transaction

      o Mandatory identify:
       - which Organisation signed (originated) the signature, and Optional use
       - which Organisation(s) should process the signature in order to
         check that the Action the Organisation should take can occur.

  Digital certificates may be associated with digital signatures if
  asymmetric cryptography is being used. However if symmetric
  cryptography is being used, then the digital certificate will be
  replaced by some identifier of the secret key to use.

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

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

IOTP MESSAGE                                  SIGNATURE COMPONENT

IOTP Message                                   Signature Id = P1.3
 |-Trans Ref Block        digest TransRefBlk   |-Manifest
 |  |      ID=P1.1-----------------------------|->|-Digest of P1.1--
 |  |-Trans Id Comp       digest TransIdComp   |  |                 |
 |  |     ID = M1.2----------------------------|->|-Digest of M1.2--|
 |  |-Msg Id Comp.           digest Signature  |  |                 |
 |  |      ID = P1          -------------------|->|-Digest of M1.5--|
 |                         |   digest element  |  |                 |
 |-Signatures Block        |  -----------------|->|-Digest of M1.7--|
 |  |       ID=P1.2        | |  digest element |  |                 |
 |  |-Signature ID=P1.3    | |  ---------------|->|-Digest of C1.4--|
 |  |-Signature ID=M1.5----  | |               |  |                 |
 |  |-Signature ID=P1.4      | | Points to     |   -RecipientInfo*  |
 |  |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6  |
 |  |                        | | Certs to use  |  Sig.ValueRef=P1.4 |
 |  |                        | |               |        |           |
 |  |                        | |               |        |           |
 |-Trading Block. ID=P1.5    | |               |        v           |
 |  |-Comp. ID=M1.7----------  |                -Value* ID=P1.4:    |
 |  |                          |                   JtvwpMdmSfMbhK<--
 |  |-Comp. ID=P1.6            |                   r1Ln3vovbMQttbBI
 |  |                          |                   J8pxLjoSRfe1o6k
 |  |-Comp. ID=C1.4------------                    OGG7nTFzTi+/0<-
 |  |-Comp. ID=C1.5
                            Digital signature of Manifest element
                            using certificate identified by CertRef

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

                       Figure 10 Signature Digests

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

  Note that one Manifest may be associated with multiple signature
  "Value" elements where each Value element contains a digital signatur
  over the same Manifest, perhaps using the same (or different)
  signature algorithm but using a different certificate or shared secre
  key. Specifically it will allow the Merchant to agree different share
  secrets keys with their Payment Handler and Delivery Handler.

  The detailed definitions of a Signature component are contained in
  section 7.18.

  The remainder of this section contains:

      o an example of how IOTP uses signatures

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

      o how IOTP uses signatures to prove actions complete
        successfully

  5.1.1

  6.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). 6.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<---           Signature    |------Signature
   Component                 Component       |   |      Component
      |                       |              |            |           -Manifest
      |BrandList               -Trading Role |            |
      |  Ref                     Element     | Originator |-Originator
      v                         (Merchant)    ------------|--Info
    Brand List                                    Ref     |
  >Component                                              |
 | |-Protocol       ------>  Organisation     Recipient   |-Recipient
 | | Amount Elem   |         Component <------------------|--Info
 | |   |           |          |                 Refs      |
 | | Pa|Protocol |Pay|Protocol   |Action     -Trading Role              |
 | |   | Ref       |OrgRef       Element                  |
 | |   v           |          (Payment Handler)           |
 |  -PayProtocol--                                        |
 |    Elem                  ->Organisation    Recipient   |-Recipient
 |                         |  Component <-----------------|--Info <--------------------Info
 |                         |  |                 Refs
 |                         |                         |   -Trading Role
 |                         |                         |     Element
 |                         |                         | (Delivery Handler)            -Manifest
 | Handler
 |                                      ^
 |           OFFER RESPONSE BLOCK
 |                         |                         |                Contains digests of:--
 |BrandListRef             |ActionOrgRef    -Trans Ref Block (not
 |                         |                 shown)
  --Payment                 ---Delivery     -Transaction Id
   Component                  Component

The Manifest element in the Signature Component contains digests of:
the Trans Ref Block (not shown); the Transaction ID Component (not shown)
                                            -Org
shown); Organisation Components (Merchant, Payment Handler, Delivery Handler
                                            -Brand
Handler); the Brand List Component; the Order Component, the Payment
Component
                                            -Order Component
                                            -Payment Component
                                            -Delivery the Delivery Component
                                            -Brand and the Brand Selection Component (if
a Brand Dependent) Dependent Purchase).
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

        Figure 13 11 Example use of Signatures for Baseline Purchase
  5.1.2

  6.1.2 OriginatorInfo and RecipientInfo Elements

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

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

         IOTP Signature Type        Valid Trading Role

        OfferResponse           Merchant

        PaymentResponse         PaymentHandler

        DeliveryResponse        DeliveryHandler

        AuthenticationRequest   any role

        AuthenticationResponse  any role

        PingRequest             any role

        PingResponse            any role

  The RecipientRef RecipientRefs attribute of the RecipientInfo element in the
  Signature Component contains Element References to the Organisation
  Components of the Organisations that should use the signature to
  verify that:

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

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

      o the data has been signed correctly, and

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

  5.1.3 Symmetric and Asymmetric Cryptography

  The Originator and Recipient of a signature may have agreed to use

  Note that if symmetric cryptography which is understood only by the two organisations
  involved. This requires that being used then a separate
  RecipientInfo and Value elements for each different set of shared
  secret keys are contained likely within the Signature Component. This approach
  is more likely

  Alternatively if symmetric asymmetric 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 then the
  RecpientRefs attribute of one RecipientInfo element may refer to
  multiple Organisation Components.
  This is more likely if public key/asymmetric cryptography is being
  used.

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

  5.1.4 Mandatory and Optional Signatures

  IOTP does not mandate the use of signatures. For example, Components 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 are all 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 same
  certificates.

  6.1.3 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 the Merchant authorises
         Payment, or
       - a Delivery Handler to prove that Merchant authorises Delivery,
         provided other necessary authorisations are complete (see
         below)

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

      o Delivery Response, when a Delivery Handler is generating a
        Delivery Note. This can be used to prove after the event
        what the Delivery Handler said they would do
      o Authentication Response. One method of authenticating
        another party to a trade is to send an Authentication
        Request specifying that a Digital Signature should be used
        for authentication

      o Transaction Status Inquiry. The Inquiry Response Block may
        be digitally signed to attest to the authenticity of the
        response

      o Ping. The Ping Response may be digitally signed so that
        checks can be made that the signature can be understood.

  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

  6.2 Checking a Signature is Correctly Calculated

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

  Before a Trading Role can check a signature it must identify which of
  the potentially multiple Signature elements should be checked. The
  steps involved are as follows:

      o check that a Signature Block is present and it contains one
        or more Signature Components

      o identify the Organisation Component which contains an OrgId
        attribute for the Organisation which is carrying out the
        signature check. If no or more than one Organisation
        Component is found then it is an error

      o use the ID attribute of the Organisation Component to find
        the RecipientInfo element that contains a RecipientRefs
        attribute that refers to that Organisation Component. Note
        there may be no signatures to verify

      o check the Signature Component that contains the identified
        RecipientInfo element as follows as follows:
       - use the SignatureValueRef, the SignatureAlgoritmRef SignatureValueRef and the
      SignatureCertRef SignatureAlgorithmRef
         attributes to identify: respectively, identify, respectively: the Value element that
         contains the signature to be checked, checked and the Signature
         Algorithm element that describes the signature algorithm to be
         used to verify the Signature, then
       - if the Signature and Algorithm element indicates that asymmetric
         cryptography is being used then use the SignatureCertRef to
         identify the Certificate to be used by the signature algorithm, algorithm
       - if Signature Algorithm element indicates that symmetric
         cryptography is being used then the content of the
         RecipientInfo element is used to identify the correct shared
         secret key to use
       - use the specified signature algorithm to check that the Value
         Element correctly signs the Manifest Element
       - check that the Digest Elements in the Manifest Element are
         correctly calculated where Components or Blocks referenced by
         the Digest have been received by the organisation checking the
      signature

  5.3
         signature.

  6.3 Checking a Payment or Delivery can occur

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

  In outline the steps are:

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

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

      o check that the payment or delivery is authorised

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

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

      o a "Response Block" is used to refer to either a Payment
        Response Block (see section 7.9) 8.9) or a Delivery Response
        Block (see section 7.11) 8.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

  6.3.1 Check the Action Request Block was sent to the Correct Organisation

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

  5.3.1.1

  6.3.1.1 Payment

  In outline a Payment Handler checks if it can accept or make a payment paymen
  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 12 Checking a Payment Handler can carry out a Payment

  The following describes the steps involved and the checks which need
  to be made:

1)

      o Identify the Payment Component (see section 6.8) 7.9) in the
        Payment Request Block that was received.

2)

      o Identify the Brand List and Brand Selection Components for
        the Payment Component. This involves:

   a)
       - identifying the Brand List Component (see section 6.6) 7.7) 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) 7.8)
         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)

      o 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) 7.7.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) 7.7.3) 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) 7.7.5) 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) 7.7.4) 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)

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

      o 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

  6.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 13 Checking a Delivery Handler can carry out a Delivery

  The steps involved are as follows:

1)

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

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

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

      o 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

  6.3.2 Check the Correct Components are present in the Request Block

  Check that the correct components are present in the Payment Request
  Block (see section 7.7) 8.7) or in the Delivery Request Block (see section
  7.10).
  8.10).

  If components are missing, there is an error.

  5.3.3

  6.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 will identifies the Merchant,
  checks that it has a pre-existing agreement which with the Merchant that
  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)

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

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

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

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

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

  5.3.3.1 6.3.3.1).

  6.3.3.1 Check the Signatures Digests are correct

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

      o the Transaction Id Component (see section 3.3.1) of the
        IOTP message that contains the Signature Component. This
        binds the globally unique OtpTransId IotpTransId 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 IotpTransId with information about the IOTP Message
        contained inside the Message Id Component (see section
        3.3.2).

  Check that each Signature Component contains Digest elements that
  refer to the correct data required.

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

      o if the signer of the signature is a Merchant then:
       - Digest elements must be present for all the components in the
         Request Block apart from the Brand Selection Component which
         is optional

      o if the signer of the signature is a Payment Handler then
        Digest elements must be present for:
       - the Signature Component signed by the Merchant, and optionally
       - one or more Signature Components signed by the previous
         Payment Handler(s) in the Transaction.

  5.4 Data Integrity and Privacy

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

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

  6.

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

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

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

           |  |-Component  |-Trading Comp.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                       Figure 16 14 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 Request Component

      o Authentication Response Component

      o Trading Role Information Request 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
  7.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 branc
  to if the IOTP Transaction is successful.

  The definition of a Protocol Options Component is as follows.

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

  Attributes:

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

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

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

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

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

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

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

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

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

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

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

  Either SenderNetLocn, SecureSenderNetLocn or both must be present.

  6.2

  7.2 Authentication Data Request Component

  This Trading Component contains parameter data about how that is used in an
  Authentication
  within the IOTP Transaction will occur. of one Trading Role by another. Its definition is as
  follows.

<!ELEMENT AuthData (PackagedContent+, Algorithm+)> AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthData AuthReq
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

  If required the Algorithm may use the challenge data, contained in th
  Packaged Content elements within the Authentication Request Component
  in its calculation. The format of the Packaged Contents are Algorithm
  dependent.

  Attributes:

ID                  An identifier which uniquely identifies the
                    Authentication Data Request 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.

AlgorithmRefs       This contains a list of the Algorithm Elements
                    contained within the Auth Data Component from
                    which the recipient of the AuthData Component
                    must choose one to use to generate the
                    Authentication Response (see section 6.3). Note
                    there only one Algorithm may be present.

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

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

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

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

  Content:

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

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

  6.3 Authentication Response Component

  This Authentication Response Component contains

                    The Algorithms that may be used are identified
                    by the Name attribute of the Algorithm element.
                    For valid values see section 12. IANA
                    Considerations.

  7.3 Authentication Response Component

  The Authentication Response Component contains the results of an
  authentication.
  authentication request.  It uses one of the Algorithms selected Algorithm contained in the AuthData
  Authentication Request Component (see section 6.2). 7.2) selected from the
  Authentication Request Block (see section 8.4).

  Depending on the Algorithm selected, the results of the applying the
  algorithm will either be contained in a Signature Component that signs sign
  both the Authentication Response and potentially other data, or in the th
  Packaged Content element elements within the Authentication Response
  Component. Its definition is as follows.

<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #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

AuthenticationId      The Authentication Response. It must be one of the
                      Element References contained within identifier specified by the
                      AlgorithmRefs attribute of
                      Authenticator that was included in the
                      Authentication
                      Data Component (see Request Component(see section 6.2)

ContentSoftwareId
                      7.2). This contains information which identifies the
                      software which generated the content of will enable the
                      element. Its purpose is Authenticator 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
                      identify the software
                      It is recommended Authentication that this attribute is
                      included if the software which generated the
                      content cannot be identified from being
                      referred to.

SelectedAlgorithmRef  An Element Reference that identifies the
                      SoftwareId attribute on
                      Algorithm element used to generate the Message Id
                      Component (see
                      Authentication Response.

ContentSoftwareId     See section 3.3.2) 14. Glossary.

  Content:

PackagedContent     This may contain the response generated as a
                    result of applying the Algorithm selected from
                    the Authentication Data Request Component see section
                    6.2.
                    7.2.

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

  6.4 documentation for
                    definitions of its content.

  7.4 Trading Role Information Request Component

  This Trading Component contains a list of Trading Roles (see section
  2.1) about which information is being requested. The result of a
  Trading Role Request is a set of Organisation Components (see section
  7.6) that describe each of the Trading Roles requested.

  Example usage includes:

      o a Merchant requesting that a Consumer provides Organisation
        Components for the Consumer and DelivTo Trading Roles

      o a Consumer requesting from a Merchant, information about
        the Payment Handlers and Delivery Handlers that the
        Merchant uses.

  Its definition is as follows.

<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
 ID                 ID      #REQUIRED
 TradingRoleList    NMTOKEN #REQUIRED >

  Attributes:

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

TradingRoleList     Contains a list of one or more Trading Roles
                    (see the TradingRole attribute of the Trading
                    Role Element - section 7.6.2) for which
                    information is being requested.

  7.5 Order Component

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

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

  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 3.8 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   See section 3.3.2) 14. Glossary.

  Content:

PackagedContent     An optional description of the order information
                    as one or more Packaged Contents (see section
                    3.8).

  6.4.1
                    3.7).

  7.5.1 Order Description Content

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

  Although the amount and currency are likely to appear in the Packaged
  Content of the Order Description it is the amount and currency
  contained in the payment related trading components (Brand List, Brand Bran
  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 Text, HTML
  and XML as a minimum so that it can be easily displayed.

  6.4.2

  7.5.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) 7.9) 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). 7.9).

  [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 goods or service,
           services, the consumer must accept them.

           If there is to be a time-limited offer, it is 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

           Also note that although the OkFrom and OkTo dates are likely
           to appear in the Packaged Content of the Order Description
           it is the dates contained in the Order Component that is
           authoritative. This means it is important that the OkFrom
           and OkTo dates actually being used is prominently displayed
           to the Consumer.
  [Note End]

  6.5

  7.6 Organisation Component

  The Organisation Component provides information about an individual or o
  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 IOT
  Message are dependent on the particular transaction being carried out. out
  Refer to section 8. 9. 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 3.8 Identifying Languages.

OrgId               A code which identifies the organisation
                    described by the Organisation Component. See
                    6.5.1.1
                    7.6.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 10 Retrieving Logos.

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

  Content:

TradingRole         See 6.5.2 7.6.2 Trading Role Element below.

ContactInfo         See 6.5.3 7.6.3 Contact Information Element below.

PersonName          See 6.5.4 7.6.4 Person Name below.

PostalAddress       See 6.5.5 7.6.5 Postal Address below.

  6.5.1.1

  7.6.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 Payment Handler organisation id

      o consumer:1000247ABH/newjerseybooks.com - a consumer
        organisation id allocated by a merchant

  6.5.2

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

                    Values of TradingRole are controlled under the
                    procedures defined in section 3.7.3 Values for
                    IOTP Codes 12 IANA
                    Considerations which also allows user defined
                    values to be defined.

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

CancelNetLocn       This contains the net location of where the
                    Consumer should go to if the Consumer cancels
                    the transaction for some reason. It can be used
                    by the Trading Role to provide a response which
                    is more tailored to the circumstances of a
                    particular transaction.

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

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

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

                    See section 6.19.1 7.20.1 Error Processing Guidelines
                    for more details.

                    This attribute:
                    o must not be present when TradingRole is set to
                      Consumer role, or DelivTo,
                    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 7.20.1 Error Processing Guidelines
                    for more details.

  6.5.3

  7.6.3 Contact Information Element

  This contains information which can be used to contact an organisation organisatio
  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 3.8 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

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

  7.6.5 Postal Address Element

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

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

  Attributes:

xml:lang            Defines the language used by attributes within
                    this element. See section 3.9 3.8 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"

Postal Code         The code known as, for example a post code or
                    zip code, that is typically used by Postal
                    Organisations to organise postal deliveries into
                    efficient sequences. e.g. "KT22 1AA"

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

  7.7 Brand List Component

  Brand List Components are contained within the Trading Protocol
  Options Block (see section 7.1) 8.1) of the IOTP Transaction. They contains contain
  lists of:

      o payment Brands (see also section 3.6 Brands 11.1 Brand Definitions and
        Brand Selection),

      o amounts to be paid in the currencies that are accepted or
        offered by the Merchant,

      o the payment protocols which can be used to make payments
        with a Brand,  and

      o the net locations of the Payment Handlers which accept
        payment for a payment protocol

  The definition of a Brand List Component is as follows.

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

  Attributes:

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

xml:lang            Defines the language used by attributes or child
                    elements within this component, unless
                    overridden by an xml:lang attribute on a child
                    element. See section 3.9 3.8 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) 7.7.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
                   |                   ProtocolAmountRefs
                   |-Brand Element-----------------------------
                   | Element  |                                        |
                   |  |Protocol   - Protocol Brand Element--------        |
                   |                                   |       |
                   |                         ProtocolId|       |
                   |                                   | AmountRefs       |  v
                   |-Protocol Amount Element<----------+-------
                   | Element----------  |                      |         |
                   |  |Currency  |                      |         |
                   |  |CurrencyAmountRefs    |Pay      |
                   | AmountRefs  |                      |Protocol |
                   |  v                      |Ref      |
                   |-Currency Amount Element |         |
                   | Element                 |         |
                   |
                    -PayProtocol<-----
                     Element                         |         |
                    -PayProtocolElement<------<--------

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

                Figure 17 15 Brand List Element Relationships

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

  6.6.1

  7.7.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*) (ProtocolBrand*, PackagedContent*) >
<!ATTLIST Brand
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #IMPLIED
 BrandId            NMTOKEN            CDATA   #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 3.8
                    Identifying Languages.

BrandId             This contains a unique identifier for the brand
                    or
                    (or promotional brand. 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 using the Brand.

                    The syntax for a BrandId is as follows:

                    BrandId ::= BrandIdDomain ":" BrandValue

                    Currently the two valid values for the
                    BrandIdDomain have been defined:
                    o IOTP which indicates that values

                    Values of BrandValue BrandId are managed under the
                    procedure described in section 3.7.3 Values for IOTP Codes, and
                    o SET which indicates that the BrandValue
                      conforms to [SET] conventions

                    Examples of BrandIds are: IOTP:Mondex,
                    SET:MasterCard::, and
                    SET:Visa:Gold:AmericanAirlines.  The first
                    BrandId is an example of an IOTP BrandId, and
                    the following two are SET BrandIds. 12 IANA
                    Considerations.

                    As values of BrandId are controlled under the
                    procedures defined in section 3.7.3 Values for
                    IOTP Codes 12 IANA
                    Considerations 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). 10).

                    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) 7.7.3) contained within
                    the Brand List.

ContentSoftwareId   This optional attribute contains   See section 14. Glossary.

  Content:

ProtocolBrand       Protocol Brand elements contain brand
                    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 used with a specific payment
                    protocol (see section 3.3.2)

  Content: 7.7.2)

PackagedContent     Optional Packaged Content (see section 3.8) 3.7)
                    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

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

  6.6.2

  7.7.2 Protocol Amount Brand Element

  The Protocol Amount element links a Brand to:

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

  o is specific to
  the Payment Protocols and Payment Handlers defined in use of a Pay particular Protocol Element (see section 6.6.4), which can be used with
    those currencies and amounts. a Brand. Its definition is as follows:
  follows.

<!ELEMENT ProtocolAmount ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolAmount
 ID                 ID      #REQUIRED
 PayProtocolRef     IDREF   #REQUIRED
 CurrencyAmountRefs IDREFS ProtocolBrand
 ProtocolId         CDATA   #REQUIRED
 ContentSoftwareId
 ProtocolBrandId    CDATA   #IMPLIED   #REQUIRED >

  Attributes:

Id                  Element identifier,

ProtocolId          This must match the value of a ProtocolId
                    attribute in a Pay Protocol Element (see section
                    7.7.5).

                    The values of ProtocolId should be unique within
                    a Brand Element otherwise there is an error.

ProtocolBrandId     This is the Payment Brand Id to be used with a
                    particular payment protocol. For example, SET
                    and EMV have their own well defined, yet
                    different, values for the Brand Id to be used
                    with each protocol.

                    The valid values of this attribute are defined
                    in the supplement for the payment protocol
                    identified by ProtocolId that describes how the
                    payment protocol works with IOTP.

  Content:

PackagedContent     Optional Packaged Content (see section 3.7)
                    elements containing information about the
                    protocol/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.

  7.7.3 Protocol Amount Element

  The Protocol Amount element links a Brand to:

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

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

  Its definition is as follows:

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

  Attributes:

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

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

CurrencyAmountRefs  Contains a list of  Element References (see
                    section 3.5) that refer to the Currency Amount
                    Element (see section 6.6.3) 7.7.4) 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   See section 3.3.2) 14. Glossary.

  Content:

PackagedContent     Optional Packaged Content (see section 3.8) 3.7)
                    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 in section 11.2
  Brand List Examples.

  6.6.3

  7.7.4 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. Component
  Its definition is as follows:

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
 ID                 ID      #REQUIRED
 Amount             CDATA   #REQUIRED
 CurrCodeType       NMTOKEN 'ISO4217' 'ISO4217-A'
 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:
                    . ISO4217 ISO4217-A (the default) indicates the currency
                      code is a three character alphabetic currency
                      code that conforms to [ISO 4217]
                    . IOTP indicates that values of CurrCode are
                      managed under the procedure described in
                      section 3.7.3 Values for IOTP Codes 12 IANA Considerations

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

                    As values of CurrCodeType are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes 12 IANA
                    Considerations user defined values of
                    CurrCodeType may be defined.

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

  6.6.4

  7.7.5 Pay Protocol Element

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

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

  Attributes:

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

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

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

                    Values

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

                    Each
                    payment supplement defines scheme/method owners in the value to be
                    used with document
                    that describes how to encapsulate a payment method.
                    protocol within IOTP.

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] [SSL/TLS] in order to
                    communicate with the Payment Handler.

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

ContentSoftwareId   This contains   See section 14. Glossary.

  Content:

PackagedContent     Optional Packaged Content elements (see section
                    3.7) containing information which identifies about the
                    software protocol
                    which generated is used by the payment protocol. 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 this information is a single
                    text string defined in the language defined by xml:lang.
                    It must contain, as
                    supplement for a minimum:
                    o the name of the software manufacturer
                    o payment protocol which
                    describes how the name payment protocol works with
                    IOTP. An example 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 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 its use could be to include
                    a payment protocol message.

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

  6.7 Examples.

  7.8 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 may be
BrandSelProtocolAm  required by a particular payment brand or
ountInfo,           protocol. See sections 6.7.1, 6.7.2, 7.8.1, 7.8.2, and 6.7.3. 7.8.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 (see section 8.1) 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 11.2 Brand
  List Examples.

  6.7.1

  7.8.1 Brand Selection Brand Info Element

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

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

  Attributes:

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

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

  Content:

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

  6.7.2

  7.8.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 require
  by a particular payment brand or payment protocol. See the IOTP
  payment method supplement for a description of how and when it used.

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

  Attributes:

ContentSoftwareId   See section 6.7.1 Brand Selection Brand Info
                    Element. 14. Glossary.

  Content:

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

  6.7.3

  7.8.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 metho
  supplement for a description of how and when it used.

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

  Attributes:

ContentSoftwareId   See section 6.7.1 Brand Selection Brand Info
                    Element. 14. Glossary.

  Content:

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

  6.8

  7.9 Payment Component

  A Payment Component contains information used to control how a payment paymen
  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) 7.7) which
        identifies the Brands, protocols, currencies and amounts
        which can be used to make a payment

      o whether or not a payment receipt will be provided

      o whether another payment precedes this payment.

  Its definition is as follows.

<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
 ID                 ID      #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 BrandListRef       NMTOKEN #REQUIRED
 SignedPayReceipt (True | False) #REQUIRED
 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.7) 8.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) 7.7) within
                    the TPO Trading Block for the IOTP Transaction.
                    The Brand List identifies the alternative ways
                    in which the payment can be made.

SignedPayReceipt    Indicates whether or not the Payment Response
                    Block (7.9) (8.9) generated by the payment handler 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
  6.9

  7.10 Payment Scheme Component

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

<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #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    See section 3.3.2) 14. Glossary.

  Content:

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

  6.10

                    Note that:
                    o the values of the Name attribute of each
                      packaged content element are defined by the
                      Payment Protocol Supplement
                    o the value of each Name must be unique within a
                      Payment where a Payment is defined as all
                      Payment Scheme or Payment Receipt Components
                      with the same value of the PaymentRef
                      attribute

  7.11 Payment Receipt Component

  A Payment Receipt is a record of a payment which demonstrates how much muc
  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 dat
  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 o
  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 determin
  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
 PayReceiptNameRefs 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) 7.9) to
                    which this payment receipt applies

PayReceiptRefs

PayReceiptNameRefs  Optionally contains Element References to other
                    Components (potentially including Pay Scheme
                    Components) which a list of the values of the
                    Name attributes of Packaged Content elements
                    that together make up the receipt. The Packaged
                    Content elements are contained either within:
                    o Payment Scheme Data components exchanged
                      between the Payment Handler and the Consumer
                      roles during the Payment, and/or
                    o the Payment Receipt component itself.

                    Note that:
                    o each payment scheme defines in its supplement
                      the elements which must be referenced.
                    o each Names of the components Packaged Content elements
                      that must be referenced by
                      Digests listed in the Payment Response signature
                      component, this attribute (if
                      any).
                    o if one is being used.

                    The client software should save all the
                    components a Payment Scheme Component contains
                      Packaged Content elements with a name that
                      matches a name within PaymentReceiptRefs, then
                      those Payment Scheme Components must be
                      referenced by Digests in the Payment Response
                      signature component (if such a signature is
                      being used)

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

ContentSoftwareId   This   See section 14. Glossary.

  Content:

PackagedContent     Optionally contains payment scheme payment
                    receipt 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 Packaged Content elements
                    (see section 3.7). See the software
                    o payment scheme
                    supplement for the version definition of the software, and its content.

                    Note that:
                    o the build values of the software

                    It is recommended that this Name attribute is
                    included if the software which generated the of each
                      packaged content cannot be identified from element are defined by the SoftwareId
                    attribute on
                      Payment Protocol Supplement
                    o the Message Id Component (see
                    section 3.3.2)

  Content:

PackagedContent     Contains payment scheme specific record value of the
                    payment which can each Name must be used for receipt purposes unique within a
                      Payment where a Payment is defined as Packaged Content elements (see section 3.8).
                    Each payment scheme defines in its supplement all
                      Payment Scheme or Payment Receipt Components,
                      with the structure same value of the content. PaymentRef
                      attribute

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

  6.11

  7.12 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 the
  it could contain information on the remaining balance on the account
  after the transfer was complete. The information should duplicate
  information contained within the Payment Receipt Component.

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

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

  Attributes:

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

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

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

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

  7.13 Delivery Component

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

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

  Attributes:

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

xml:lang            Defines the language used by attributes or child
                    elements within this component, unless
                    overridden by an xml:lang attribute on a child
                    element. See section 3.9 3.8 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.11) 8.11) and the Payment Response Block
                    (see section 7.9 8.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 7.13.1 Delivery Data Element
                    below.

PackagedContent     Contains "user" data defined for the Merchant
                    which is required by the Delivery Handler as one
                    or more Packaged Content Elements see section
                    3.8.

  6.12.1
                    3.7.

  7.13.1 Delivery Data Element

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

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

OkFrom              The date and time in [UTC] format after which
                    the Delivery Handler may accept for processing a
                    Delivery Request Block (see section 7.10). 8.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
                    Values of DelivMethod are managed under the
                    procedure described in section 3.7.3 Values for
                    IOTP Codes 12 IANA
                    Considerations which allows user defined codes
                    to be defined.

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

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

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

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

                    A secured delivery request involves the use of a
                    secure channel such as [SSL] [SSL/TLS] 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 3.9 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   See section 3.3.2) 14. Glossary.

  Content:

PackagedContent     Additional information about the delivery as one
                    or more Packaged Content elements (see section
                    3.8)
                    3.7) provided to the Delivery Handler by the
                    merchant.

  6.13

  7.14 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 Text, HTML and HTML. XML.

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

  Attributes:

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

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

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

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

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

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

  Content:

DeliveryNote        Contains actual delivery note     See section 14. Glossary.

  Content:

PackagedContent     Contains actual delivery note information as one
                    or more Packaged Content elements (see section
                    3.8).
                    3.7).

  [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

  7.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         NMTOKEN #REQUIRED
 ElRef              NMTOKEN #REQUIRED #IMPLIED
 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 3.8 Identifying
                    Languages.

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

                    Undefined means that the type of document
                    exchange could not be identified. This is caused
                    by an error in the initial input message of the
                    exchange.

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

ElRef               Contains               If the StatusType is not set to Undefined then
                    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 Order Component (see section
                      7.1), 7.5), if the
                      StatusType is Offer,
                    o a Payment Component (see section 6.8), 7.9), if the
                      StatusType is Payment, or
                    o a Delivery Component (see section 6.12), 7.13), if
                      the StatusType is Delivery
                    o an Authentication Data Request Component (see
                      section
                      6.2) 7.2) if the StatusType is
                      Authentication.

ProcessState        Contains a State Code which indicates the
                    current state of the process being carried out.
                    Valid values for ProcessState are:
                    o NotYetStarted. A Request Block has been
                      received but the process has not yet started
                    o InProgress. Processing of the Request Block
                      has started but it is not yet complete
                    o CompletedOk. The processing of the Request
                      Block has completed successfully without any
                      errors
                    o Failed. The processing of the Request Block
                      has failed because of a business error (see
                      section 4.2)
                    o ProcessError. This value is only used when the
                      Status Component is being used in connection
                      with an Inquiry Request Trading Block (see
                      section 7.12). 8.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.
                    present and indications on when recovery from
                    failures are possible.

                    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 Request 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 inside an
                    Inquiry Response Block (see section 7.13) 8.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.14.1

  7.15.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. used and indicates whether or not recovery
  might be possible. It is recommended that the StatusDesc attribute is
  used to provide further explanation where appropriate.

       Value                           Description

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

ConsCancelled

                    Recovery may be possible by the Consumer re-
                    submitting a new Authentication Response Block
                    with corrected information.

ConsCancelbled      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 or an Inquiry
                    Response Block.

                    No recovery possible.

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

                    No recovery possible.

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

  6.14.2

                    No recovery possible.

TimedOutRcvr        Recoverable Time Out. Messages were resent but
                    no response received. The document exchange has
                    therefore "Timed Out". This code is only valid
                    on a Transaction Inquiry.

                    Recovery is possible if the last message from
                    the other Trading Role is received again.

TimedOutNoRcvr      Non Recoverable Time Out. Messages were resent
                    but no response received. The document exchange
                    has therefore "Timed Out". This code is only
                    valid on a Transaction Inquiry.

                    No recovery possible.

  7.15.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. used and indicates where recovery may be
  possible. 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.

                    See below for recovery options.

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.

                    If the payment is Brand Independent, then the
                    Consumer may recover by selecting a different
                    currency, if available, or a different brand.
                    Note that this may involve a different 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 or an Inquiry Response Block.

                    Recovery is not possible.

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 or an Inquiry Response Block.

                    See below for recovery options.

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

                    Recovery may be possible. See the payment scheme
                    supplement to determine what is allowed.

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

                    See below for recovery options.

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.

                    See below for recovery options.

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

                    See below for recovery options.

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.

                    See below for recovery options.

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

  6.14.3 Delivery Completion Codes

  The following table contains the valid values for the CompletionCode
  attribute

                    See below 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 recovery options.

TimedOutRcvr        Recoverable Time Out. Messages were resent but they have not yet been received.

                    Shipping will be arranged when they are
                    no response received. The document exchange has
                    therefore "Timed Out". This code is only valid
                    on a Transaction Inquiry.

                    Recovery is possible if ProcessState the last message from
                    the other Trading Role is
                    CompletedOk.

PermNotAvail        Permanently Not Available. received again.

TimedOutNoRcvr      Non Recoverable Time Out. Messages were resent
                    but no response received. The goods are
                    permanently unavailable and cannot be re-
                    ordered. document exchange
                    has therefore "Timed Out". This code is only
                    valid if ProcessState is
                    Failed.

TempNotAvail        Temporarily Not Available. The goods are on a Transaction Inquiry.

                    No recovery possible.

  If the Payment is Brand Independent, then recovery may be possible
  for some values of the Completion Code, by the Consumer selecting
  either a different payment brand or a different payment instrument
  for the same brand. Note that this might involve a different Payment
  Handler. The codes to which this applies are: BrandNotSupp,
  PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid,
  BadInstrument and Unspecified.

  Recovery from Payments associated with Brand Dependent purchases is
  only possible, if the Brand Selection component sent by the Merchant
  to the Consumer does not change. In practice this means that the same
  Brand, Protocol Amount and PayProtocol elements must be used. All
  that can change is the Payment Instrument. Any other change will
  invalidate the Merchant's Offer as a changed selection will
  invalidate the Offer Response.

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

                    Recovery is not possible.

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

                    Recovery is not possible.

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.

                    Recovery is not possible.

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.

                    Recovery is not possible.

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

                    Recovery is not possible.

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.

                    Recovery is not possible.

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 or an Inquiry Response Block.

                    Recovery is not possible.

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 or an Inquiry Response Block.

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

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

  6.14.4

                    Recovery is not possible.

TimedOutRcvr        Recoverable Time Out. Messages were resent but
                    no response received. The document exchange has
                    therefore "Timed Out". This code is only valid
                    on a Transaction Inquiry.

                    Recovery is possible if the last message from
                    the other Trading Role is received again.

TimedOutNoRcvr      Non Recoverable Time Out. Messages were resent
                    but no response received. The document exchange
                    has therefore "Timed Out". This code is only
                    valid on a Transaction Inquiry.

                    No recovery possible.

  [Note]   Recovery from failed, or partially completed deliveries is
           not possible. The Consumer should use the Transaction Status
           Inquiry Transaction (see section 9.2.1) to determine up-to-
           date information on the current state.
  [Note End]

  7.15.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 StatusDes
  attribute is used to provide further explanation where appropriate.

       Value                           Description

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

                    Recovery is not possible.

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

NoAuthData

                    Recovery is not possible.

NoAuthReq           Authentication Data Request 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.

                    Recovery is not possible

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

                    Recovery may be possible by the Authenticatee
                    re-sending a revised Authentication Response
                    with corrected data.

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

                    Recovery may be possible by the Authenticator
                    re-sending a revised Authentication Request
                    Block with corrected information.

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

  6.15 Trading Role Data Component

                    Recovery is not possible.

TimedOutRcvr        Recoverable Time Out. Messages were resent but
                    no response received. The Trading Role Data Component contains opaque data which document exchange has
                    therefore "Timed Out". This code is needs to
  be communicated between only valid
                    on a Transaction Inquiry.

                    Recovery is possible if the Trading Roles involved in an IOTP
  Transaction. last message from
                    the other Trading Role Components identify:

  o the organisation that generated the component, and

  o is received again.

TimedOutNoRcvr      Non Recoverable Time Out. Messages were resent
                    but no response received. The document exchange
                    has therefore "Timed Out". This code is only
                    valid on a Transaction Inquiry.

                    No recovery possible.

  7.15.5 Undefined Completion Codes

  The Completion Code is only required if the organisation that ProcessState attribute is
  set to receive it.

  They are first generated Failed. The following table contains the valid values for the
  CompletionCode that may be used. It is recommended that the StatusDes
  attribute is used to provide further explanation where appropriate.

InMsgHardError      The type of Request Block could not be
                    identified or was inconsistent. Therefore no
                    single Document Exchange could be identified.
                    This will cause a Hard Error in the transaction

  7.15.6 Transaction Inquiry 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 StatusDes
  attribute is used to provide further explanation where appropriate.

UnAuthReq           The recipient of the Transaction Status Request
                    declines to respond to the request.

  7.16 Trading Role Data Component

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

  Trading Role Components identify:

      o the organisation that generated the component, and

      o the organisation that is to receive it.

  They are first generated and included in a "Response" Block, and then
  copied to the appropriate "Request" Block. For example a Payment
  Handler might need to inform a Delivery Handler that a credit card
  payment had been authorised but not captured. There may also be other
  information that the Payment Handler has generated where the format is i
  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+) >
<!ATTLIST TradingRoleData
  ID                ID      #REQUIRED
  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 as one or more
                    PackagedContent elements see section 3.8.

  6.15.1 3.7.

  7.16.1 Who Receives a Trading Role Data Component

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

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

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

  6.16
  7.17 Inquiry Type Component

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

<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
 ID                 ID      #REQUIRED
 Type               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.14).

  6.17 7.15).

  7.18 Signature Component

  [Note]   Definitions of the XML structures for signatures and
           certificates are described in the paper document titled "Digital
           Signatures for XML - Proposal", see [XMLDSIG]. As this is an the 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 Open Trading Protocol" by Kent
           Davidson published at the definitions contained in
           XMLDSIG, but has been modified to meet some specific IOTP
           requirements. same time as this document - see
           [IOTPDSIG].

           In the future it is anticipated that future versions of IOTP
           will adopt a stable version of the XMLDSIG once it whatever method for digitally signing XML
           becomes
           available. the standard.
  [Note End]

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

  The Signature Component:

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

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

      o signs the Manifest element using the optional certificate
        identified in the Certificate element within the Signature
        Block placing the result in a Value element within a
        Signature Component

  Note that there may be multiple Value elements that contain signatures signature
  of a Manifest Element.

  A Signature Component can be one of four types either:

      o an Offer Response Signature,

      o a Payment Response Signature,

      o a Delivery Response Signature, or

      o an Authentication Response Signature.

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

  The definition of a Signature Component 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

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

  SIGNATURE ELEMENT

  The ID attribute is mandatory.

  MANIFEST ELEMENT

  The optional LocatorHrefBase attribute contains text which should be
  concatenated before the text contained in the LocatorHREF attribute of o
  all Digest elements within the Manifest.

  Its purpose is to reduce the size of LocatorHREF attribute values
  since the first part of the LocatorHREF attributes in the same
  signature are likely to be the same.

  Typically, within IOTP, it will contain all the characters in a
  LocatorHref attribute up to the sharp ("#") character (see immediately immediatel
  below).

  ALGORITHM AND PARAMETER ELEMENTS

  The algorithm element identifies the algorithms used in generating the th
  signature. The type of the algorithm is defined by the value of the
  Type attribute which indicates if it is the algorithm is to be used as a
  a Digest algorithm, a Signature algorithm or a Key Agreement
  algorithm.

  The following Digest algorithms must be implemented:

      o a [DOM-HASH] algorithm. This is identified by setting the
        Name attribute of the Algorithm element to "urn:ibm:dom-hash" "urn:ibm:dom-
        hash"

      o a [SHA1] algorithm. This is identified by setting the Name
        attribute of the Algorithm element to "urn:fips:sha1", and

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

  The following Signature algorithms must be implemented:

      o a [DSA] algorithm. This is identified by setting the Name
        attribute of the Algorithm element to "urn:us.gov:dsa"

      o a [HMAC] algorithm. This is identified by setting the Name
        attribute of the Algorithm element to "urn:ibm:hmac"
  It is recommended that the following Signature algorithm is also
  implemented:

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

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

  One algorithm may make use of other algorithms by use of the Parameter Paramete
  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 IotpTransId attribute of the Transaction
        ID Component, followed by:

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

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

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

  ATTRIBUTE ELEMENT

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

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

  The Critical attribute must be set to true.

  ORIGINATORINFO ELEMENT

  The OriginatorRef attribute of the OriginatorInfo element must always
  be present and contain an Element Reference (see section 3.5) to the
  Organisation Component of the Organisation that generated the
  Signature Component.

  RECIPIENTINFO ELEMENT

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

  6.17.2

  7.18.2 Offer Response Signature Component

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

      o the Transaction Id Component (see section 3.3.1) of the
        IOTP message that contains the Offer Response Signature

      o the Transaction Reference Block (see section 3.3) of the
        IOTP Message that contains the Offer Response Signature

      o from the TPO Block:
       - the Protocol Options Component
       - each of the Organisation Components
       - each of the Brand List Components

      o optionally, all the Brand Selection Components if they were
        sent to the Merchant in a TPO Selection Block

      o from the Offer Response Block:
       - the Order Component
       - each of the Payment Components
       - the Delivery Component
       - each of the Authentication Data Request Components
       - any Trading Role Data Components

  The Offer Response Signature should also contain Digest elements for
  the components that describe each of the organisations that may or
  will need to verify the signature. This involves:

      o if the Merchant has received a TPO Selection Block
        containing Brand Selection Components, then generate a
        Digest element for the Payment Handler identified by the
        Brand Selection Component and the Delivery Handler
        identified by the Delivery Component. See section 5.3.1 6.3.1
        Check the Action Request Block was sent to the Correct
        Organisation for a description of how this can be done.

      o if the Merchant is not expecting to receive a TPO Selection
        Block then generate a Digest element for the Delivery
        Handler and all the Payment Handlers that are involved.

  6.17.3

  7.18.3 Payment Receipt Signature Component

  The Manifest Element of the Payment Receipt Signature Component should shoul
  contain Digest Elements for the following Components:

      o the Transaction Id Component (see section 3.3.1) of the
        IOTP message that contains the Payment Receipt Signature

      o the Transaction Reference Block (see section 3.3) of the
        IOTP Message that contains the Payment Receipt Signature

      o the Offer Response Signature Component

      o the Payment Receipt Component

      o the Status Component

      o the Brand Selection Component.

      o any Trading Role Data Components
  6.17.4

  7.18.4 Delivery Response Signature Component

  The Manifest Element of the Delivery Response Signature Component
  should contain Digest Elements for the following Components:

      o the Transaction Id Component (see section 3.3.1) of the
        IOTP message that contains the Delivery  Response Signature
      o the Transaction Reference Block (see section 3.3) of the
        IOTP Message that contains the Delivery  Response Signature

      o the Signature Components contained in the preceding
        Delivery Request (if any)

      o the Status Component

      o the Delivery Note Component

  6.17.5

  7.18.5 Authentication Request Signature Component

  The Manifest Element of the Authentication Request Signature Component Componen
  should contain Digest Elements for the following Components:

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message that contains information that describes the
        IOTP Message and IOTP Transaction

      o the Transaction Id Component (see section 3.3.1) which
        globally uniquely identifies the IOTP Transaction

      o the following components of the TPO Block :
       - the Protocol Options Component
       - the Organisation Component

      o the following components of the Authentication Request
        Block:
       - the Authentication Data Request Component(s) (if present)
       - the Trading Role Information Request Component

  6.17.6 (if present)

  7.18.6 Authentication Response Signature Component

  The Manifest Element of the Authentication Response Signature
  Component should contain Digest Elements for the following Components: Components

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message that contains information that describes the
        IOTP Message and IOTP Transaction

      o the Transaction Id Component (see section 3.3.1) which
        globally uniquely identifies the IOTP Transaction

      o the following components of the Authentication Request
        Block:

       - the Authentication Data Request Component that was used in the
         Authentication (if present)
       - the Trading Role Information Request Component (if present)

      o the Organisation Components contained in the Authentication
        Response Block

  6.17.7

  7.18.7 Ping Request Signature Component

  If the Ping Request is being singed (see section 8.2.2), 9.2.2), the Manifest
  Element of the Ping Request Signature Component should contain Digest
  elements for all the Organisation Components.

  6.17.8

  7.18.8 Ping Response Signature Component

  If the Ping Response is being singed (see section 8.2.2), 9.2.2), the Manifest Manifes
  Element of the Ping Response Signature Component should contain Digest Diges
  elements fir all the Organisation Components.

  6.18

  7.19 Certificate Component

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

           See note at the start of section 6.17 7.18 Signature Component
           for more details.
  [Note End]

  A Certificate Component contains a Digital Certificate. Its They are used
  only when required, for example, when asymmetric cryptography is bein
  used and the recipient of the signature that needs to check has not
  already received the Public Key.

  The structure of a Certificate Component is as 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

  7.19.1 IOTP usage of signature elements and attributes

  Detailed definitions of the above elements and attributes are
  contained in [XMLDSIG]. [IOTPDSIG]. The following contains additional information informatio
  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

  7.20 Error Component

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

  For clarity two phrases are defined which are used in the description
  of an Error Component:

      o message in error. An IOTP message which contains or causes
        an error of some kind
      o message reporting the error. An IOTP message that contains
        an Error Component that describes the error found in a
        message in error.

  The definition of the Error Component is as follows.

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

  Attributes:

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

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

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

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

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

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

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

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

  Content:

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

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

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

  6.19.1 3.7.

  7.20.1 Error Processing Guidelines

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

  6.19.1.1

  7.20.1.1 Severity - Warning

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

  If a message reporting the error is received with an Error Component
  where Severity is set to Warning, then:

      o it is recommended that information about the error is
        either logged, or otherwise reported to the user,

      o the implementer of the IOTP aware application must either,
        at their or the user's discretion:
       - continue the IOTP transaction as normal, or
       - fail the IOTP transaction by generating a message reporting
         the error with an Error Component with Severity set to
         HardError (see section 6.19.1.3). 7.20.1.3).

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

  6.19.1.2

  7.20.1.2 Severity - Transient Error

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

  If a message reporting the error is received with an Error Component
  where Severity is set to TransientError then:

      o if the MinRetrySecs attribute is present and a valid
        number, then use the MinRetrySecs value given. Otherwise if
        MinRetrySecs is missing or is invalid, then:
       - generate a message reporting the error containing an Error
         Component with a Severity of Warning and send it on the next
         IOTP message (if any) to be sent to the Trading Role which
         sent the message reporting the error with the invalid
         MinRetrySecs, and
       - use a value for MinRetrySecs which is set by the
         vendor/developer of the IOTP Aware Application.

      o check that only one ErrorLocation element is contained
        within the Error Component and that it refers to an IOTP
        Message which was sent by the recipient of the Error
        Component with a Severity of TransientError. If more than
        one ErrorLocation is present then generate a message
        reporting the error with a Severity of HardError.

  6.19.1.3

  7.20.1.3 Severity - Hard Error

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

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

  6.19.2

  7.20.2 Error Codes

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

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

       Value                           Description

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

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

       Value                           Description

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

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

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

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

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

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

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

       Value                           Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UnknownError        Unknown Error. Indicates that the transaction
                    cannot complete for some reason that is not
                    covered explicitly by any of the other errors.
                    The ErrorDesc attribute should be used to
                    indicate the nature of the problem.

                    This could be used to indicate, for example, an
                    internal error in a backend server or client
                    process of some kind.

  6.19.3

  7.20.3 Error Location Element

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

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

  Attributes:

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

OtpMsgRef

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

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

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

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

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

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

  7.

  8. Trading Blocks

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

  Each Trading Blocks consist of one or more Trading Components (see
  section 7).

  This is illustrated in the diagram below.

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

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

                         Figure 18 16 Trading Blocks

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

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

  The remainder of this section defines the Trading Blocks in this
  version of IOTP. They are:

      o Authentication Request Block

      o Authentication Response Block

      o Authentication Status Block

      o Cancel Block

      o Delivery Request Block
      o Delivery Response Block

      o Error Block

      o Inquiry Request Block

      o Inquiry Response Block

      o Offer Response Block

      o Payment Exchange Block

      o Payment Request Block

      o Payment Response Block

      o Signature Block

      o Trading Protocol Options Block

      o TPO Selection Block

  The Transaction Reference Block is described in section 3.3.

  7.1

  8.1 Trading Protocol Options Block

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

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

  Attributes:

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

  Content:

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

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

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

  The TPO Block should contain:

      o the Protocol Options Component

      o the Organisation Component with the Trading Role of
        Merchant

      o the Organisation Component with the Trading Role of
        Consumer

      o optionally, the Organisation Component with the Trading
        Role of DeliverTo, if there is a Delivery included in the
        IOTP Transaction

      o Brand List Components for each payment in the IOTP
        Transaction

      o Organisation Components for all the Payment Handlers
        involved

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

      o additional Organisation Components that the Merchant may
        want to include. For example
       - a Customer Care Provider
       - an Certificate Authority that offers Merchant "Credentials" or
         some other warranty on the goods or services being offered.

  7.2

  8.2 TPO Selection Block

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

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

  Attributes:

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

  Content:

BrandSelection      This identifies the choice of payment brand and
                    payment protocol to be used in a payment within
                    the IOTP Transaction. There is one Brand
                    Selection Component (see section 6.7) 7.8) 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

  8.3 Offer Response Block

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

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

  Attributes:

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

  Content:

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

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

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

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

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

TradingRoleData     The Trading Role Data Component contains opaque
                    data which is needs to be communicated between
                    the Trading Roles involved in an OTP IOTP
                    Transaction (see section 6.15). 7.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 the IOTP Transaction requires (if
        any).

  7.4

  8.4 Authentication Request Block

  This

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

<!ELEMENT AuthReqBlk (AuthData?) >

  In outline it contains:

      o information about how the authentication itself will be
        carried out, and/or

      o a request for additional information about the organisation
        being authenticated.

  Its definition is as follows.

<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
 ID                 ID      #REQUIRED >

  Attributes

  Attributes:

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

  Content

AuthData

  Content:

AuthReq             Each Authentication Request (see section 7.2)
                    component describes an alternative way in which
                    the recipient of the Authentication Request may
                    authenticate themselves by generating an
                    Authentication Response Component (see section
                    7.3).

                    If one Authentication Request Component is
                    present then that Authentication Request
                    Component should be used.

                    If more than one Authentication Request
                    Component is present then the recipient should
                    choose one of the components based on personal
                    preference of the recipient or their software.

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

TradingRoleInfoReq  The Trading Role Information Request Block.

                    If the optional Authentication Data Component
                    (see section 6.2) is present it 7.4) contains data
                    which describes the different types a list of Trading
                    Roles about which information is being requested

  There must be at least one Component (either an Authentication Reques
  or a Trading Role Information Request) within the consumer should provide.

  7.5 Authentication Bloc
  otherwise it is an error.

  8.5 Authentication Response Block

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

<!ELEMENT AuthRespBlk (AuthResp, (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 optional Authentication Response Component
                    which contains the results of processing the challenge
                    data in the
                    Authentication Data Request Component - see section 6.3.
                    7.3.

Org                 Optional Organisation Components which that contain
                    information corresponding to the Trading Roles
                    as requested by the TradingRoleList attribute of
                    the AuthData Trading Role Information Request component.

  7.6

  The components  present in the Authentication Response Block must
  match the requirement of the corresponding Authentication Request
  Block otherwise it is an error.

  8.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
  8.7 Payment Request Block

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

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

  Attributes:

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

  Content:

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

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

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

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

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

Org                 The Organisation Component contains details of
                    organisations involved in the payment (see
                    section 6.5). 7.6). The Organisations present are
                    dependent on the IOTP Transaction and the data
                    which is to be signed. See section 5 Security
                    Considerations 6 Digital
                    Signatures 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 IOTP
                    Transaction (see section 6.15). 7.16).

  The Payment Request Block should contain:

      o the Organisation Component with a Trading Role of Merchant

      o the Organisation Component with the Trading Role of
        Consumer

      o the Payment Component for the Payment

      o the Brand List Component for the Payment

      o the Brand Selection Component for the Brand List

      o the Organisation Component for the Payment Handler of the
        Payment

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

      o the Organisation Component for the organisation which is to
        carry out the next step, if any. This may be, for example,
        either a Delivery Handler or a Payment Handler.

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

      o an Optional Payment Scheme Data Component, if required by
        the Payment Method as defined in the IOTP supplement for
        the payment method

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

  7.8 7.16.1).

  8.8 Payment Exchange Block

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

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

  Attributes:

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

  Content:

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

  7.9

  8.9 Payment Response Block

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

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

  Attributes:

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

  Content:

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

PayReceipt          Contains payment scheme specific data which can
                    be used to verify the payment occurred. See
                    section 6.10 7.11 Payment Receipt Component. It must
                    be present if the ProcessState attribute of the
                    Status Component is set to CompletedOk.
                    PayReceipt is optional for other values as
                    specified by the appropriate Payment Scheme
                    supplement.

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

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

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

  7.10 7.16).

  8.10 Delivery Request Block

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

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

  Attributes:

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

  Content:

Status              Contains the Status Components (see section
                    6.12)
                    7.13) of the responses of the steps (e.g. a
                    Payment Response) on which this step is
                    dependent. It is used to indicate the success or
                    failure of those steps. Delivery should only
                    occur of if 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 7.5.

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

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

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

  The Delivery Request Block contains:

      o the Organisation Component with a Trading Role of Merchant

      o the Organisation Component for the Consumer and DeliverTo
        Trading Roles

      o the Delivery Component for the Delivery

      o the Organisation Component for the Delivery Handler.
        Specifically the Organisation Component identified by the
        ActionOrgRef attribute on the Delivery Component

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

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

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

  7.11 7.16.1).

  8.11 Delivery Response Block

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

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

  Attributes:

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

  Content:

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

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

  7.12 7.14).

  8.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.16) 7.17) that
                    contains the type of inquiry.

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

  7.13

  8.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
 LastReceivedIotpMsgRef NMTOKEN #IMPLIED
 LastSentOtpMsgRef
 LastSentIotpMsgRef  NMTOKEN #IMPLIED >

  Attributes:

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

LastReceivedOtpMsg

LastReceivedIotpMs  Contains an Element Reference (see section 3.5)
Ref
gRef                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

LastSentIotpMsgRef  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) 7.10) that
                    contains payment scheme specific inquiry
                    messages for inquiries on payments. This is
                    present when the Type attribute of StatusType
                    attribute of the Status Component is set to
                    Payment.

  7.14

  8.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).
                    7.6).

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

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

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

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

  7.15

  8.15 Ping Response Block

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

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

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

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

  Attributes:

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

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

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

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

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

  Content:

Org                 These are Organisation Components (see section
                    6.5).
                    7.6).

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

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

  7.16
  8.16 Signature Block

  The Signature Block contains one or more Signature Components and
  associated Certificates (if required) which sign data associated with
  the IOTP Transaction. For a general discussion and introduction to how ho
  IOTP uses signatures, see section 5 Security Considerations. 6 Digital Signatures. The definition definitio
  of the Signature Component and certificates is contained in the paper
  "Digital Signature Signatures for XML - Proposal", the Internet Open Trading Protocol", see [XMLDSIG].
  [IOTPDSIG]. Descriptions of how these are used by IOTP is contained in i
  sections 6.17 7.18 and 6.18. 7.19.

  The definition of a Signature Block is as follows:

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

  Attributes:

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

  Content:

Signature           A Signature Component. See section 6.17. 7.18.

Certificate         A Certificate Component. See section 6.18. 7.19.

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

  7.16.1

  8.16.1 Signature Block with Offer Response

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

  7.16.2 sectio
  7.18.2).

  8.16.2 Signature Block with Payment Request

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

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

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

  7.16.3

  8.16.3 Signature Block with Payment Response

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

  7.16.4

  8.16.4 Signature Block with Delivery Request

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

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

      o the Payment Receipt Signature Component (see section 6.17.3)
        7.18.3) generated by the previous step.

  7.17

  8.16.5 Signature Block with Delivery Response

  A Signature Block which is in the same message as a Delivery Response
  Block contains just a Delivery Response Signature component (see
  section 7.18.4) generated by the step.

  8.17 Error Block

  The Error Trading Block contains one or more Error Components (see
  section 6.19) 7.20) 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 o
  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 Components (see section 6.19) 7.20) that
                    contains information about an individual
                    Technical Error.

PaySchemeData       An optional Payment Scheme Component (see
                    section 6.9) 7.10) 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

  8.18 Cancel Block

  The Cancel Block is used by one Trading Role to inform a non-Consumer role such as a
  Merchant, Payment Handler or Delivery Handler any other that
  a transaction has been cancelled by the Consumer. It's main purpose is cancelled. Example usage includes:

      o a Consumer Role informing a non-Consumer role that it no
        longer plans to continue with the transaction. This will
        allow the server to close down the transaction tidily
        without a waiting for a time-out to occur. occur

      o a non-Consumer Role to inform a Consumer role that the
        Transaction is being stopped. In this case, the Consumer is
        then unlikely to re-send the previous message that was sent
        in the mistaken understanding that the original was not
        received.

  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.

  9. Internet Open Trading Protocol Transactions

  The Baseline Internet Open Trading Protocol supports four three types of
  transactions for different purposes. These are

      o an Authentication IOTP transaction which supports
        authentication of one party in a trade by another and/or
        requests information about another Trading Role

      o IOTP Transactions that involve one or more payments.
        Specifically:
       - Deposit
       - Purchase
       - Refund
       - Withdrawal, and
       - Value Exchange

      o IOTP Transactions designed to check the correct function of
        the IOTP infrastructure. Specifically:
       - Transaction Status Inquiry, and
       - Ping

  Although the Authentication IOTP Transaction can operate on its own,
  authentication can optionally precede any of the _payment_ "payment"
  transactions. Therefore, the rest of this section is divided into two
  parts covering:

      o Authentication and Payment transactions (Authentication,
        Deposit, Purchase, Refund, Withdrawal and Value Exchange)

      o Infrastructure Transactions (Transaction Status Inquiry and
        Ping) that are designed to support inquiries on whether or
        not a transaction has succeeded or a Trading Role's servers
        are operating correctly, and

  8.1

  9.1 Authentication and Payment Related IOTP Transactions

  The Authentication and Payment related IOTP Transactions consist of
  six Document Exchanges which are then combined in sequence to
  implement a specific transaction.

  Generally, there is a close, but not exact, correspondence between a
  Document Exchange and a Trading Exchange. The main difference is that
  some Document Exchanges implement part or all of two Trading Exchanges Exchange
  simultaneously in order to minimise the number of actual OTP Messages IOTP Message
  which must be sent over the Internet.

  The six Document Exchanges are:

      o Authentication. This is a direct implementation of the
        Authentication Trading Exchange

      o Brand Dependent Offer. This is the Offer Trading Exchange
        combined with the Brand Selection part of the Payment
        Trading Exchange. Its purpose is to provide the Merchant
        with information on the Brand selected so that the content
        of the Offer Response may be adapted accordingly

      o Brand Independent Offer. This is also an Offer Trading
        Exchange. However, in this instance, the content of the
        Offer Response does depend on the Brand selected.

      o Payment. This is a direct implementation of the Payment
        part of a Payment Trading Exchange

      o Delivery. This is a direct implementation of the Delivery
        Exchange

      o Delivery with Payment. This is an implementation of
        combined Payment and Delivery Trading Exchanges

  These Document Exchanges are combined together in different sequences
  to implement each IOTP Transaction. The way in which they may be
  combined is illustrated by the diagram below.

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

  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 17 Payment and Authentication Message Flow Combinations

  The combinations of Document Exchanges that are valid depend on the
  particular IOTP transaction.

  The remainder of this sub-section describes:

      o each Document Exchange in more detail including
        descriptions of the content of each Trading Block in the
        Document Exchanges, and

      o descriptions of how each IOTP Transaction uses the Document
    Exchange
        Exchanges to effect the desired result.

  [Note]   The descriptions of the Document Exchanges which follow
           describe the ways in which various Business Errors (see
           section 4.2) are handled. No reference is made however to
           the handling of Technical Errors (see section 4.1) in any of
           the messages since these are handled the same way
           irrespective of the context in which the message is being
           sent. See section 4 for more details.
  [Note End]

  8.1.1

  9.1.1 Authentication Document Exchange

  The Authentication Document Exchange is a direct implementation of the th
  Authentication Trading Exchange (see section 2.2.4). It involves:

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

      o an Authenticatee - the organisation being authenticated.

  The authentication consists of:

      o an Authentication Request being sent by the Authenticator
        to the Authenticatee,

      o an Authentication Response being sent in return by the
        Authenticatee to the Authenticator which is then checked,
        and

      o an Authentication Status being sent by the Authenticator to
        the Authenticatee to provide an indication of the success
        or failure of the authentication.

  An Authentication Document Exchange also:

      o provides an Authenticatee with an Organisation Component
        which describes the Authenticator, and

      o optionally provides the Authenticator with Organisation
        Components which describe the Authenticatee.

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

  The IOTP Messages which are involved are illustrated by the diagram
  below.

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

    ORGANISATION
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1           IOTP MESSAGE           ORGANISATION
 (Authenticatee)
     |   Organisation 2
   (AUTHENTICATEE)                                  (AUTHENTICATOR)
     |  (Authenticator)
STEP |     |
 1.          First organisation                               2. The second takes an action (for                           organisation generates example by
             pressing a  --------------------->     an Authentication button on an HTML     Authentication Need         Request Block page) which requires     (outside scope of      containing challenge that the
             organisation          IOTP)           data and list of the is authenticated                            Algorithms that may be
                                               used

     1 --> 2 Authentication Need (outside scope of IOTP)

 2.          The second organisation generates: an Authentication
             Request Block containing one or more Authentication
             Request Components and/or a Trading Role Information
             Request Component, then sends it to the first organisation
                                                          |
                                                          v

     1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
             Signature Block (optional); TPO Block; Auth Request Block

 3.          IOTP aware application                             IotpMsg:Trans started. If a Signature Block  <--------------------     Ref Block; is present
             present, the first               TPO &              Signature organisation may use this to       Authentication        Block; TPO check the
             credentials of the          Request           Block; Auth. second organisation. If it is                          Request Block;
  OK credentials are
             OK, the first organisation selects an Algorithm Authentication
             Request to use (if present and more than one), then uses
             the challenge data and
  the authentication method algorithm selected from the
Authentication Request Block to generate an
             Authentication Response Block and optional Block. If present, the Trading
             Role Information Request Component is used to generate
             Organisation and Components. Finally a Signature
  Components which Component is
             created if required and all components are then sent back
             to the second organisation for validation.
       |
       v
IotpMsg:

     1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
             Signature Block (optional) ; Auth Response Block

 4.          The second organisation
  Ref Block;     ----------------------> checks the Authentication
   Signature     Authentication Response Response
             against the
  Block; Auth                                challenge data in the
Response Block; Authentication Request Block
Organisation Block to
             check that the first
       | organisation is who they
       v appear to
             be, and sends an
     STOP Authentication Status Block to the first
             Organisation to indicate the Result result then stops.

                                                        |
                                                        v

     1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature
             Block (optional); Auth Response Block

 5.          The first organisation                            IotpMsg: Trans checks the Authentication    <--------------------     Ref Block; authentication Status
             Block and optionally   Authentication Status  Signature Block; keeps information on the IOTP                           Auth Response
   Transaction
             transaction for record                                   Block keeping purposes and stops.                                  |
              v                                               v
            STOP                                            STOP

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

                Figure 20 18 Authentication Document Exchange

  8.1.1.1

  9.1.1.1 Message Processing Guidelines

  On receiving a TPO & Authentication Request IOTP Message (see below),
  an Authenticatee may either:

      o generate and send an Authentication Response IOTP Message
        back to the Authenticator, or

      o indicate failure to comply with the Authentication Request
        by sending a Cancel Block back to the Authenticator
        containing a Status Component with a StatusType of
        Authentication a ProcessState of Failed and the
        CompletionCode (see section
    6.14.4) 7.15.4) set to either:
        AutEeCancel, NoAuthData, NoAuthReq, TradRolesIncon or Unspecified.

  On receiving an Authentication Response IOTP Message (see below), an
  Authenticator should send in return, an Authentication Status IOTP
  Message (see below) containing a Status Block with a Status Component
  where the StatusType is set to Authentication, and:

      o the ProcessState attribute of the Status Component is set
        to CompletedOk which indicates a successful completion, or
      o the ProcessState attribute is set to Failed and the
        CompletionCode attribute is set to either: AutOrCancel,
        AuthFailed or Unspecified which indicates a failed
        authentication,

  On receiving an Authentication Status IOTP Message (see below), the
  Authenticatee should check the Status Component in the Status Block.
  If this indicates:

      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
         Block containing a Status Component with a StatusType of
         Authentication, a ProcessState of Failed and the
         CompletionCode (see section
      6.14.4) 7.15.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,
  block from a Consumer, then the Authenticatee is likely to may go to the
  CancelNetLocn specified on the Trading Role Element in the
  Organisation Component for the Authenticator contained in the Authentication Request Trading
  Protocol Options Block.

  8.1.1.2

  9.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) 8.1)

      o an Authentication Request Block (see section 7.4), 8.4), and

      o an optional Signature Block (see section 7.16). 8.16).

  Each of these are described below.

  TRADING PROTOCOL OPTIONS BLOCK

  The Trading Protocol Options Block (see section 7.1) 8.1) must contain the
  following Trading Components:

      o one Protocol Options Component (see Section 6.1) 7.1) which
        defines the options which apply to the whole Authentication
        Document Exchange.

      o one Organisation Component (see section 6.5) 7.6) 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) 8.4) must contain the
  following Trading Components:

      o one Authentication Data Request Component (see section 6.2), 7.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 followin
  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 Request Component
       - the Trading Role Information Request Component

  8.1.1.3

  9.1.1.3 Authentication Response IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of:

      o an Authentication Response Block (see section 7.5), 8.5), and

      o an optional Signature Block (see section 7.16). 8.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) 7.3)

      o one Organisation Component for every Trading Role
        identified in the TradingRoleList attribute of the Authentication Data Trading
        Role Information Request Component contained in the
        Authentication Request Block.

  SIGNATURE BLOCK (AUTHENTICATION RESPONSE)

  If the AuthMethod attribute of Algorithm element (see section 12. IANA Considerations) within
  the Authentication Data Request 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 include
  in the same IOTP message that contains an Authentication Response
  Block. The Signature Component contains Digest Elements for the
  following XML elements:

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message that contains information that describes the
        IOTP Message and IOTP Transaction

      o the Transaction Id Component (see section 3.3.1) which
        globally uniquely identifies the IOTP Transaction

      o the following components of the Authentication Request
        Block:
       - the Authentication Data Request Component
       - the Trading Role Information Request Component

      o the Organisation Components contained in the Authentication
        Response Block

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

  8.1.1.4

  9.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), 8.5), and

      o an optional Signature Block (see section 7.16). 8.16).

  Each of these are described below.

  AUTHENTICATION STATUS BLOCK

  The Authentication Status Block (see section 7.6) 8.6) must contain the
  following Trading Components:

      o one Status Component (see section 6.14) 7.15) with a ProcessState
        attribute set to CompletedOk.

  SIGNATURE BLOCK (AUTHENTICATION STATUS)

  If the Authentication Status Block is being digitally signed then a
  Signature Block must be included that contains a Signature Component
  with Digest elements for the following XML elements:

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message that contains information that describes the
        IOTP Message and IOTP Transaction

      o the Transaction Id Component (see section 3.3.1) which
        globally uniquely identifies the IOTP Transaction

      o the following components of the Authentication Status
        Block:
       - the Status Component (see section 6.14). 7.15).

  [Note]   If the Authentication Document Exchange is followed by an
           Offer Document Exchange (see section 8.1.2) 9.1.2) then the
           Authentication Status Block and the Signature Block
           (Authentication Status) may be combined with either:

           o a TPO IOTP Message (see section 8.1.2.3), 9.1.2.3), or

           o a TPO and Offer Response IOTP Message (see section
             8.1.2.6)
             9.1.2.6)
  [Note End]

  8.1.2

  9.1.2 Offer Document Exchange

  The Offer Document Exchange occurs in two basic forms:

      o Brand Dependent Offer Exchange. Where the content of the
        offer, e.g. the order details, amount, delivery details,
        etc., are dependent on the payment brand and protocol
        selected by the consumer, and

      o Brand Independent Offer Exchange. Where the content of the
        offer is not dependent on the payment brand and protocol
        selected.

  Each of these types of Offer Document Exchange may be preceded by an
  Authentication Document Exchange (see section 8.1.1).

  8.1.2.1 9.1.1).

  9.1.2.1 Brand Dependent Offer Document Exchange

  In a Brand Dependent Offer Document Exchange the TPO Block and the
  Offer Response Block are sent separately by the Merchant to the
  Consumer, i.e.:

      o the Brand List Component is sent to the Consumer in a TPO
        Block,

      o the Consumer selects a Payment Brand, Payment Protocol and
        optionally a Currency and amount from the Brand List
        Component

      o the Consumer sends the selected brand, protocol and
        currency/amount back to the Merchant in a TPO Selection
        Block, and

      o the Merchant uses the information received to define the
        content of and then send the Offer Response Block to the
        Consumer.

  This is illustrated by the diagram below.

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

       CONSUMER              IOTP MESSAGE              MERCHANT
1.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer decides                         2.
     |  Merchant
STEP |     |
 1.          Consumer decides which to trade and sends                         payment brand protocols , to the Merchant
             information (e.g. using HTML) that    ------------------->    curencies and amounts enables the Merchant   Offer Information     apply, places them in a to
             create an offer    (outside offer,

     C --> M Offer information - outside scope of IOTP

 2.          Merchant decides which payment brand protocols, currencies
             and amounts apply, places then in a Brand List Component in
             inside a
  to the Merchant,           IOTP) TPO Block, Block and sends to
  e.g. using HTML Consumer
                                                               |
                                                               v

     C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block

 3.          IOTP aware application                            IotpMsg:Trans started. Consumer selects the   <-------------------  Ref Block; TPO
             payment brand, payment protocol           TPO               Block and currency/amount to use,
  records
             use. Records selection in a Brand Selection Component, Component and
             sends back to Merchant
       |
       v Merchant.

     C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
             Block
 4.          Merchant uses selected
Ref Block; TPO   --------------------> payment brand, payment
Selection Block      TPO Selection protocol,
             currency/amount and the offer information to create an
             Offer Response Block containing details about the IOTP
             Transaction including price, etc. optionally Optionally signs it and
             sends to the Consumer
                                                               |
                                                               v

     C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
             (optional); Offer Response Block

 5.          Consumer checks the Offer is OK,                       IotpMsg: Trans then combines components
             from the TPO                        Ref Block; Block, the TPO Selection Block and  <----------------     Signature the Offer
             Response Block to create    Offer Response    Block; Offer the next IOTP Message for the                        Response Block
             Transaction and sends it together with the Signature Block block
             if present to the required Trading Role
                |
                v

     CONTINUED ...

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

            Figure 21 19 Brand Dependent Offer Document Exchange

  Note, a Consumer identifies a Brand Dependent Offer Document Exchange, Exchange
  by the absence of an Offer Response Block in the first IOTP Message.

  MESSAGE PROCESSING GUIDELINES

  On receiving a TPO IOTP Message (see below), the Consumer may either:

      o generate and send a TPO Selection IOTP Message back to the
        Merchant, or

      o indicate failure to continue with the IOTP Transaction by
        sending a Cancel Block back to the Merchant containing a
        Status Component with a StatusType of Offer, a ProcessState
        of Failed and the CompletionCode (see section 6.14.4) 7.15.4) set
        to either: ConsCancelled or Unspecified.

  On receiving a TPO Selection IOTP Message (see below) the Merchant may ma
  either:

      o generate and send an Offer Response IOTP Message back to
        the Consumer, or

      o indicate failure to continue with the IOTP Transaction by
        sending a Cancel Block back to the Consumer containing a
        Status Component with a StatusType of Offer, a ProcessState
        of Failed and the CompletionCode (see section 6.14.4) 7.15.4) set
        to either: MerchCancelled or Unspecified.

  On receiving an Offer Response IOTP Message (see below) the Consumer
  may either:

      o generate and send the next IOTP Message in the IOTP
        transaction and send it to the required Trading Role. This
        is dependent on the IOTP Transaction, or

      o indicate failure to continue with the IOTP Transaction by
        sending a Cancel Block back to the Consumer containing a
        Status Component with a StatusType of Offer, a ProcessState
        of Failed and the CompletionCode (see section 6.14.4) 7.15.4) set
        to either: ConsCancelled or Unspecified.

  If the Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer is likely to go to the CancelNetLocn specified on
  the Trading Role Element in the Organisation Component for the
  Merchant.

  If the Consumer receives an IOTP Message containing a Cancel block,
  then the information contained in the IOTP Message should be reported
  to the Consumer but no further action taken.

  8.1.2.2

  9.1.2.2 Brand Independent Offer Document Exchange

  In a Brand Independent Offer Document Exchange the TPO Block and the
  Offer Response Block are sent together by the Merchant to the
  Consumer, i.e. there is one IOTP Message that contains both a TPO
  Block, and an Offer Response Block.

  The message flow is illustrated by the diagram below:

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

       CONSUMER               IOTP MESSAGE              MERCHANT
  1.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer                             2.
     |  Merchant decides which
STEP |     |
 1.          Consumer decides to                              payment brand, protocols , trade and sends  --------------------> to the Merchant
             information (e.g. using HTML) that enables the Merchant to
             create an offer,

     C --> M Offer information - outside scope of IOTP

 2.          Merchant decides which payment brand protocols, currencies
             and amounts apply,
  information      Offer Information places them then in a Brand List
 that enables      (outside scope of Component in
             inside a TPO Block,
the Merchant to          IOTP) creates an Offer Response
create an offer                         Block containing
             details about
    to the the IOTP Transaction including
Merchant, e.g. price, etc, etc.,
             optionally signs
  using HTML it  and sends to Consumer
                                                           |
                                                           v
   3. IOTP aware application

     C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref
 started. Consumer selects the    <------------- Block; Signature
   payment brand and payment          TPO &
             Block; TPO Block;
    protocol to use, records      Offer Response Offer Response Block
 3.          IOTP aware application started. Consumer selects the
             payment brand, payment protocol and currency/amount to
             use. Records selection in a Brand Selection Component,
             checks Offer offer is OK, combines the Brand Selection Component
             with information from the TPO Block and Offer Response
             Block to create the next IOTP Message for the Transaction
             and sends it together with the Signature Block if present
             to the required Trading Role
               |
               v Role.

     CONTINUED ...

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

                Figure 22 20 Brand Independent Offer Exchange

  Note that a Brand Independent Offer Document Exchange always occurs
  when only one payment brand, protocol and currency/amount is being
  offered to the Consumer by the Merchant. It is also likely to, but
  will not necessarily, occur when multiple brands are being offered,
  the Payment Handler is the same, and all brands use the same set of
  protocols.

  Note that the TPO Block and the Offer Response Block can be sent in
  separate IOTP messages (see Brand Dependent Offer Document Exchange)
  even if the Offer Response Block does not change. However this
  increases the number of messages in the transaction and is therefore
  likely to increase transaction response times.

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

  MESSAGE PROCESSING GUIDELINES

  On receiving a TPO and Offer Response IOTP Message (see below), the
  Consumer may either:

      o generate and send the next IOTP Message in the IOTP
        transaction and send it to the required Trading Role. This
        is dependent on the IOTP Transaction, or

      o indicate failure to continue with the IOTP Transaction by
        sending a Cancel Block back to the Merchant containing a
        Status Component with a StatusType of Offer, a ProcessState
        of Failed and the CompletionCode (see section 6.14.1) 7.15.1) set
        to either: ConsCancelled or Unspecified.

  If the Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer is likely to go to the CancelNetLocn specified on
  the Trading Role Element in the Organisation Component for the
  Merchant.

  8.1.2.3

  9.1.2.3 TPO IOTP Message

  The TPO IOTP Message is only used with a Brand Dependent Offer
  Document Exchange. Apart from a Transaction Reference Block (see
  section 3.3), this message consists of just a Trading Protocol Options Option
  Block (see section 7.1) 8.1) which is described below.

  TPO (TRADING PROTOCOL OPTIONS) BLOCK

  The Trading Protocol Options Block (see section 8.1) 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. 7.1.

      o one Brand List Component (see section 6.6) 7.7) for each Payment
        in the IOTP Transaction that contain one or more payment
        brands and protocols which may be selected for use in each
        payment

      o Organisation Components (see section 6.5) 7.6) with the
        following roles:
       - Merchant who is making the offer
       - Consumer who is carrying out the transaction
       - the PaymentHandler(s) for the payment. The "ID" of the Payment
         Handler Organisation Component is contained within the
         PhOrgRef attribute of the Payment Component

  If the IOTP Transaction includes a Delivery then the TPO Block must
  also contain:

      o Organisation Components with the following roles:
       - DeliveryHandler who will be delivering the goods or services
       - DelivTo i.e. the person or organisation which is to take
         delivery

  AUTHENTICATION STATUS AND SIGNATURE BLOCKS

  If the Offer Document Exchange was preceded by an Authentication
  Document Exchange, then the TPO IOTP Message may also contain:

      o an Authentication Status Block (see section 7.6), 8.6), and

      o an optional Signature Block (Authentication Status)
        Signature Block
  See section 8.1.1.4 9.1.1.4 Authentication Status IOTP Message for more
  details.

  8.1.2.4

  9.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 (se
  section 3.3), this message consists of just a TPO Selection Block (see (se
  section 7.1) 8.1) which is described below.

  TPO SELECTION BLOCK

  The TPO Selection Block (see section 7.2) 8.2) contains:

      o one Brand Selection Component (see section 6.7) 7.8) 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

  9.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 (se
  section 3.3), this message consists of:

      o an Offer Response Block (see section 7.1) 8.1) and

      o an optional Signature Block (see section 7.16). 8.16).

  OFFER RESPONSE BLOCK

  The Offer Response Block (see section 7.3) 8.3) contains the following
  components:

      o one Status Component (see section 6.14) 7.15) which indicates the
        status of the Offer Response. The ProcessState attribute
        should be set to CompletedOk

      o one Order Component (see section 6.4) 7.5) which contains
        details about the goods and services which are being
        purchased or the financial transaction which is taking
        place

      o one or more Payment Component(s) (see section 6.8) 7.9) for each
        payment which is to be made

      o zero or one Delivery Components (see section 6.12) 7.13)
        containing details of the delivery to be made if the IOTP
        Transaction includes a delivery
      o zero or more Trading Role Data Components (see section 6.15)
        7.16) if required by the Merchant.

  SIGNATURE BLOCK (OFFER RESPONSE)

  If the Authentication Status Block is being digitally signed then a
  Signature Block must be included that contains a Signature Component
  (see section 6.17) 7.18) with Digest Elements for the following XML
  elements:

  If the Offer Response is being digitally signed then a Signature Block Bloc
  must be included that contains a Signature Component (see section
  6.17)
  7.18) with Digest Elements for the following XML elements:

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message that contains information that describes the
        IOTP Message and IOTP Transaction

      o the Transaction Id Component (see section 3.3.1) which
        globally uniquely identifies the IOTP Transaction

      o the following components of the TPO Block :
       - the Protocol Options Component, and
       - the Brand List Component
       - all the Organisation Components present

      o the following components of the Offer Response Block:
       - the Order Component
       - all the Payment Components present
       - the Delivery Component if present
       - any Trading Role Data Components present

  8.1.2.6

  9.1.2.6 TPO and Offer Response IOTP Message

  The TPO and Offer Response IOTP Message is only used with a Brand
  Independent Offer Document Exchange. Apart from a Transaction
  Reference Block (see section 3.3), this message consists of:

      o a Trading Protocol Options Block (see section 7.1) 8.1)

      o an Offer Response Block (see section 7.1) 8.1) and

      o an optional Signature Block (see section 7.16). 8.16).

  TPO (TRADING PROTOCOL OPTIONS) BLOCK

  This is the same as the Trading Protocol Options Block described in
  TPO IOTP Message (see section 8.1.2.3). 9.1.2.3).

  OFFER RESPONSE BLOCK

  This the same as the Offer Response Block in the Offer Response IOTP
  Message (see section 8.1.2.5). 9.1.2.5).

  AUTHENTICATION STATUS

  If the Offer Document Exchange was preceded by an Authentication
  Document Exchange, then the TPO and Offer Response IOTP Message may
  also contain an Authentication Status Block (see section 7.6). 8.6).

  SIGNATURE BLOCK

  This is the same as the Signature Block in the Offer Response IOTP
  Message (see section 8.1.2.5) 9.1.2.5) with the addition that:

      o if the Offer Document Exchange is Brand Dependent then the
        Signature Component in the Signature Block additionally
        contains a Digest Element for the Brand Selection Component
        contained in the TPO Selection Block

      o if the Offer Document Exchange was preceded by an
        Authentication Document Exchange then the Signature
        Component in the Signature Block additionally contains a
        Digest Element for the Authentication Status Block.

  8.1.3

  9.1.3 Payment Document Exchange

  The Payment Document Exchange is a direct implementation of the last
  part of a Payment Trading Exchange (see section 2.2.2) after the Brand Bran
  has been selected by the Consumer. A Payment Exchange consists of:

      o the Consumer requesting that a payment starts by generating
        Payment Request IOTP Message using information from
        previous IOTP Messages in the Transaction and then sending
        it to the Payment Handler

      o the Payment Handler and the Consumer then swapping Payment
        Exchange IOTP Messages encapsulating payment protocol
        messages until the payment is complete, and finally

      o the Payment Handler sending a Payment Response IOTP Message
        to the Consumer containing a receipt for the payment.

  The IOTP Messages which are involved are illustrated by the diagram
  below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER               IOTP MESSAGE         PAYMENT HANDLER
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer
     |  Payment
     |  Handler
STEP |     |
 1.          Consumer generates Pay Request Block encapsulating a
             payment protocol message if required and sends to Payment
             Handler with the Signature Block if present
                 |
                 v

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block
             (optional); Pay Request Block

 2.          Payment Handler processes Pay
   Ref Block;     -------------> Request Block, checks
             optional
Signature Block;      Payment signature and starts exchanging
ay Request Block      Request payment protocol messages,
             messages encapsulated in a Pay Exchange Block, with the
             Consumer
                                                          |
                                                          v
  Consumer keeps <- ----->IotpMsg:

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans
 on exchanging Pay     Trans Ref   <-----------------> Ref Block; Pay
xchange Blocks with   Block; Pay     Payment Exchange Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange Block
                                                             |
                                                             v
                                     4. Eventually blocks until eventually payment protocol messages
             finish so Payment Handler creates a Pay Receipt Component
             inside a Pay Response Block, and an optional Signature
             Component inside
                                      the a Signature Block, sends them to the
             Consumer and stops
                                                       |
                                                       v
5. stops.

     C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block (optional); Pay Response Block

 4.          Consumer checks Pay Payment Response is                     IotpMsg: Trans OK. Optionally keeps
             information on  <---------------     Ref Block;
OTP IOTP Transaction for record keeping  Payment Response  Signature Block
             purposes and either stops or                         Pay Response creates the next IOTP Message message
             for                          Block the Transaction and sends it together with the
             Signature Block Block, if present present, to the required Trading Role

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

                   Figure 23 21 Payment Document Exchange

  8.1.3.1

  9.1.3.1 Message Processing Guidelines

  On receiving a Payment Request IOTP Message, the Payment Handler
  should check that they are authorised to carry out the Payment (see
  section 5 Security Considerations). 6 Digital Signatures). They may then either:

      o generate and send a Payment Exchange IOTP Message back to
        the Consumer, if more payment protocol messages need to be
        exchanged, or

      o generate and send a Payment Response IOTP Message if the
        exchange of payment protocol messages is complete, or
      o indicate failure to continue with the Payment by sending a
        Cancel Block back to the Consumer containing a Status
        Component with a StatusType of Payment, a ProcessState of
        Failed and the CompletionCode (see section 6.14.4) 7.15.4) set to
        either: BrandNotSupp, CurrNotSupp, PaymtCancelled,
        AuthError, InsuffFunds, InstBrandInvalid, InstNotValid,
        BadInstrument or Unspecified.

  On receiving a Payment Exchange IOTP Message, the Consumer may either: either

      o generate and send a Payment Exchange Message back to the
        Payment Handler or

      o indicate failure to continue with the Payment by sending a
        Cancel Block back to the Payment Handler containing a
        Status Component with a StatusType of Payment, a
        ProcessState of Failed and the CompletionCode (see section 6.14.2)
        7.15.2) set to either: ConsCancelled or Unspecified.

  On receiving a Payment Exchange IOTP Message, the Payment Handler may
  either:

      o generate and send a Payment Exchange IOTP Message back to
        the Consumer, if more payment protocol messages need to be
        exchanged, or

      o generate and send a Payment Response IOTP Message if the
        exchange of payment protocol messages is complete, or

      o indicate failure to continue with the Payment by sending a
        Cancel Block back to the Consumer containing a Status
        Component with a StatusType of Payment, a ProcessState of
        Failed and the CompletionCode (see section 6.14.2) 7.15.2) set to
        either: PaymtCancelled or Unspecified.

  On receiving a Payment Response IOTP Message, the Consumer may either: either

      o generate and send the next IOTP Message in the IOTP
        transaction and send it to the required Trading Role. This
        is dependent on the IOTP Transaction,

      o stop, since the IOTP Transaction has ended, or

      o indicate failure to continue with the IOTP Transaction by
        sending a Cancel Block back to the Merchant containing a
        Status Component with a StatusType of Payment, a
        ProcessState of Failed and the CompletionCode (see section 6.14.1)
        7.15.1) set to either: ConsCancelled or Unspecified.

  If the Consumer receives an IOTP Message containing a Cancel block,
  then the information contained in the IOTP Message should be reported
  to the Consumer but no further action taken.

  If the Payment Handler receives an IOTP Message containing a Cancel
  block, then the Consumer is likely to go to the CancelNetLocn
  specified on the Trading Role Element in the Organisation Component
  for the Payment Handler from which any further action may take place.

  If the Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer should have completed the payment but not continuing continuin
  with the transaction for some reason. In this case the Consumer is
  likely to go to the CancelNetLocn specified on the Trading Role
  Element in the Organisation Component for the Merchant from which any
  further action may take place.

  8.1.3.2

  9.1.3.2 Payment Request IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of:

      o a Payment Request Block, and

      o an optional Signature Block

  PAYMENT REQUEST BLOCK

  The Payment Request Block (see section 7.7) 8.7) contains:

      o the following components copied from the Offer Response
        Block from the preceding Offer Document Exchange:
       - the Status Component
       - the Payment Component for the payment which is being carried
         out
       - the Organisation Components with the roles of Merchant and for
         the PaymentHandler that is being sent the Payment Request
         Block

      o the  following component from the TPO Block:
       - the Brand List Component for the payment, i.e. the Brand List
         referred to by the BrandListRef attribute on the Payment
         Component

      o one Brand Selection Component for the Brand List, i.e. the
        Brand Selection Component where BrandListRef attribute
        points to the Brand List. This component can be either:
       - copied from the TPO Selection Block if the payment was
         preceded by a Brand Dependent Offer Document Exchange (see
         section 8.1.2.1), 9.1.2.1), or
       - created by the Consumer, containing the payment brand, payment
         protocol and currency/amount selected from the Brand List, if
         the payment was preceded by a Brand Independent Offer Document
         Exchange (see section 8.1.2.2) 9.1.2.2)

      o an optional Payment Scheme Component (see section 6.9) 7.10) if
        required by the payment method used (see the Payment Method
        supplement to determine if this is needed).

      o zero or more Trading Role Data Components (see section 6.15).
        7.16).

  Note that:

      o if there is more than one Payment Components in an Offer
        Response Block, then the second payment is the one within
        the Offer Response Block that contains a StartAfter
        attribute (see section 6.8) 7.9) that identifies the Payment
        Component for the first payment

      o the Payment Handler to include is identified by the Brand
        Selection Component (see section 6.7) 7.8) for the payment. Also
        see section 5.3.1 6.3.1 Check the Action Request Block was sent to the
        Correct Organisation for an explanation on how Payment
        Handlers are identified

      o the Brand List Component to include is the one identified
        by the BrandListRef attribute of the Payment Component for
        the identified payment

      o the Brand Selection Component to include from the Offer
        Response Block is the one that contains an BrandListRef
        attribute (see section 3.5) which identifies the Brand List
        Component for the second payment.

  SIGNATURE BLOCK (PAYMENT REQUEST)

  If the either the preceding Offer Document Exchange included an Offer
  Response Signature (see section 8.1.2.5 9.1.2.5 Offer Response IOTP Message),
  or a preceding Payment Exchange included a Payment Response Signature
  (see section 8.1.3.4 9.1.3.4 Payment Response IOTP Message) then they should
  both be copied to the Signature Block in the Payment Request IOTP
  Message.

  8.1.3.3

  9.1.3.3 Payment Exchange IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of just a Payment Exchange Block.

  PAYMENT EXCHANGE BLOCK

  The Payment Exchange Block (see section 7.8) 8.8) contains:

      o one Payment Scheme Component (see section 6.9) 7.10) 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

  9.1.3.4 Payment Response IOTP Message

  Apart from a Transaction Reference Block (see section 3.3), this
  message consists of:

      o a Payment Response Block, and

      o an optional Signature Block

  PAYMENT RESPONSE BLOCK

  The Payment Response Block (see section 7.9) 8.9) contains:

      o one Payment Receipt Component (see section 6.10) 7.11) which
        contains scheme specific data which can be used to verify
        the payment occurred

      o one Payment Scheme Component (see section 6.9) 7.10) 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 an optional Payment Note Component (see section 6.11) 7.12)

      o zero or more Trading Role Data Components (see section 6.15).
        7.16).

  SIGNATURE BLOCK (PAYMENT RESPONSE)

  If a signed Payment Receipt is being provided, indicated by the
  SignedPayReceipt attribute of the Payment Component being set to True, True
  then the Signature Block should contain a Signature Component which
  contains Digest Elements for the following:

      o the Transaction Reference Block (see section 3.3) for the
        IOTP Message which contains the first usage of the Payment
        Response Block,

      o the Transaction Id Component (see section 3.3.1) within the
        Transaction Reference Block that globally uniquely
        identifies the IOTP Transaction,
      o the Payment Receipt Component from the Payment Response
        Block,

      o the other Components referenced by the PayReceiptRefs
        attribute (if present) of the Payment Receipt Component,

      o the Status Component from the Payment Response Block,

      o any Trading Role Data Components in the Payment Response
        Block, and

      o all the Signature Components contained in the Payment
        Request Block if present.

  8.1.4

  9.1.4 Delivery Document Exchange

  The Delivery Document Exchange is a direct implementation of a
  Delivery Trading Exchange (see section 2.2.3). It consists of:

      o the Consumer requesting a Delivery by generating Delivery
        Request IOTP Message using information from previous IOTP
        Messages in the Transaction and then sending it to the
        Delivery Handler

      o the Delivery Handler sending a Delivery Response IOTP
        Message to the Consumer containing details about the
        Handler's response to the request together with an optional
        signature.

  The message flow is illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

       CONSUMER              IOTP MESSAGE          DELIVERY HANDLER
1.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer generates                            2.
     |  Delivery
     |  Handler
STEP |     |
 1.          Consumer generates Delivery Request                              checks the Status and Block and sends it to  --------------------->  Order Components in the
             the Delivery Handler with the Signature Block if present

     C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Request Block

 2.          Delivery Request Handler checks the Status and
 with Order Components in
             the Signature Delivery Request and the optional
  Block if present Signatures, creates
             a Delivery Response Block, sends to the Consumer and stops
                                                          |
                                                          v
             stops.

     C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Response Block

3.           Consumer checks Delivery                            IotpMsg:Trans Response Block is OK,      <--------------------     Ref Block;
optionally and optional
             Signature Block are OK. Optionally keeps information     Delivery Response        Delivery on
             IOTP Transaction for                             Response Block record keeping purposes and
            stops stops.

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

                   Figure 24 22 Delivery Document Exchange

  8.1.4.1

  9.1.4.1 Message Processing Guidelines

  On receiving a Delivery Request IOTP Message, the Delivery Handler
  should check that they are authorised to carry out the Delivery (see
  section 5 Security Considerations). 6 Digital Signatures). They may then either:

      o generate and send a Delivery Response IOTP Message to the
        Consumer, or

      o indicate failure to continue with the Delivery by sending a
        Cancel Block back to the Consumer containing a Status
        Component with a StatusType of Delivery, a ProcessState of
        Failed and the CompletionCode (see section 6.14.4) 7.15.4) set to
        either: DelivCanceled, or Unspecified.

  On receiving a Delivery Response IOTP Message, the Consumer should
  just stop since the IOTP Transaction is complete.

  If the Consumer receives an IOTP Message containing a Cancel block,
  then the information contained in the IOTP Message should be reported
  to the Consumer but no further action taken.

  8.1.4.2

  9.1.4.2 Delivery Request IOTP Message

  The Delivery Request IOTP Message consists of:

      o a Delivery Request Block, and

      o an optional Signature Block

  DELIVERY REQUEST BLOCK

  The Delivery Request Block (see section 7.10) 8.10) contains:

      o the following components copied from the Offer Response
        Block:
       - the Status Component (see section 6.14) 7.15)
       - the Order Component (see section 6.4) 7.5)
       - the Organisation Component (see section 6.5) 7.6) with the roles
         of: Merchant, DeliveryHandler and DeliverTo
       - the Delivery Component (see section 6.12) 7.13)
      o the following Component from the Payment Response Block:
       - the Status Component (see section 6.14). 7.15).

      o zero or more Trading Role Data Components (see section 6.15).
        7.16).

  SIGNATURE BLOCK (DELIVERY REQUEST)

  If the preceding Offer Document Exchange included an Offer Response
  Signature or the Payment Document Exchange included a Payment Response Respons
  Signature, then they should both be copied to the Signature Block.

  8.1.4.3

  9.1.4.3 Delivery Response IOTP Message

  The Delivery Response IOTP Message contains a Delivery Response Block
  and an options Signature Block.

  DELIVERY RESPONSE BLOCK

  The Delivery Response Block contains:

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

  SIGNATURE BLOCK (DELIVERY RESPONSE)

  The Signature Block should contain one Signature Component that
  contains Digest elements that refer to

      o the Transaction Id Component (see section 3.3.1) of the
        IOTP message that contains the Delivery  Response Signature

      o the Transaction Reference Block (see section 3.3) of the
        IOTP Message that contains the Delivery  Response Signature

      o the Signature Components contained in the Delivery Request
        (if any)

      o the Status Component

      o the Delivery Note Component

  8.1.5

  9.1.5 Payment and Delivery Document Exchange

  The Payment and Delivery Document Exchange is a combination of the
  last part of the Payment Trading Exchange (see section 2.2.2) and a
  Delivery Trading Exchange (see section 2.2.3). It consists of:

      o the Consumer requesting that a payment starts by generating
        Payment Request IOTP Message using information from
        previous IOTP Messages in the Transaction and then sending
        it to the Payment Handler

      o the Payment Handler and the Consumer then swapping Payment
        Exchange IOTP Messages encapsulating payment protocol
        messages until the payment is complete, and finally

      o the Payment Handler sending to the Consumer in one IOTP
        Message:
       - a Payment Response Block containing a receipt for the payment,
         and
       - a Delivery Response Block containing details of the goods or
         services to be delivered

  The IOTP Messages which are involved are illustrated by the diagram
  below.

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

       CONSUMER               IOTP MESSAGE             MERCHANT
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
     |  Payment
     |  Handler
STEP |     |
 1.          Consumer generates Pay Request Block encapsulating a
             payment protocol message if required and sends to Payment
             Handler with the Signature Block if present
                 |
                 v

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Pay Request Block

 2.          Payment Handler processes Pay
   Ref Block;     -------------> Request Block, checks
             optional
Signature Block;      Payment signature and starts exchanging
ay Request Block      Request payment protocol messages,
             messages encapsulated in a Pay Exchange Block, with the
             Consumer
                                                          |
                                                          v
  Consumer keeps <------->IotpMsg:

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans
 on exchanging Pay     Trans Ref   <----------------->  Ref Block; Pay
Exchange Blocks with Block; Pay     Payment Exchange Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange Block
                                                             |
                                                             v
                                     4. Eventually blocks until eventually payment protocol messages
             finish so Payment Handler creates a Pay Receipt Component
             inside a Pay Response Block Block, and an optional Signature Component,
             Component inside a Signature Block, then uses information
             from the Offer Response
                                   Block Bock to create crteate a Delivery
             Response
                                    Block, Block and sends both to the Consumer and
                                                  stops
                                                      |
                                                      v
5. stops.

     C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
             Block; Signature Block; Pay Response Block; Delivery
             Response Block
 4.          Consumer checks Pay Payment Response                       IotpMsg: Trans and Delivery Response
             Blocks are   <---------------      Ref Block;
OK, optionally OK. Optionally keeps information   Payment Response    Signature Block on IOTP
             Transaction for record       & Delivery        Pay Response keeping purposes and either stops          Response        Block; Delivery
                                                      Response Block
             or creates the next IOTP message for the Transaction and
             sends it together with the Signature Block, if present, to
             the required Trading Role

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

             Figure 25 23 Payment and Delivery Document Exchange

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

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

  8.1.5.1

  9.1.5.1 Message Processing Guidelines

  On receiving a Payment Request IOTP Message or a Payment Exchange IOTP IOT
  Message, the Payment Handler should carry out the same actions as for
  a Payment Document Exchange (see section 8.1.3.1). 9.1.3.1).

  On receiving a Payment Exchange IOTP Message, the Consumer should also als
  carry out the same actions as for a Payment Document Exchange (see
  section 8.1.3.1). 9.1.3.1).

  On receiving a Payment Response and Delivery Response IOTP Message
  then the IOTP Transaction is complete and should take no further
  action.

  If the Consumer receives an IOTP Message containing a Cancel block,
  then the information contained in the IOTP Message should be reported
  to the Consumer but no further action taken.

  If the Payment Handler receives an IOTP Message containing a Cancel
  block, then the Consumer is likely to go to the CancelNetLocn
  specified on the Trading Role Element in the Organisation Component
  for the Payment Handler from which any further action may take place.

  If the Merchant receives an IOTP Message containing a Cancel block,
  then the Consumer should have completed the payment but not continuing continuin
  with the transaction for some reason. In this case the Consumer is
  likely to go to the CancelNetLocn specified on the Trading Role
  Element in the Organisation Component for the Merchant from which any
  further action may take place.

  8.1.5.2

  9.1.5.2 Payment Request IOTP Message

  The content of this message is the same as for a Payment Request IOTP
  Message in a Payment Document Exchange (see section 8.1.3.2)

  8.1.5.3 9.1.3.2)

  9.1.5.3 Payment Exchange IOTP Message

  The content of this message is the same as for a Payment Exchange IOTP IOT
  Message in a Payment Document Exchange (see section 8.1.3.3).

  8.1.5.4 9.1.3.3).

  9.1.5.4 Payment Response and Delivery Response IOTP Message

  The content of this message consists of:

      o a Payment Response Block,

      o an optional Signature Block (Payment Response), and

      o a Delivery Response Block.

  PAYMENT RESPONSE BLOCK

  The content of this block is the same as the Payment Response Block in i
  the Payment Response IOTP Message associated with a Payment Document
  Exchange (see section 8.1.3.4). 9.1.3.4).

  SIGNATURE BLOCK (PAYMENT RESPONSE)

  The content of this block is the same as the Signature Block (Payment
  Response) in the Payment Response IOTP Message associated with a
  Payment Document Exchange (see section 8.1.3.4). 9.1.3.4).

  DELIVERY RESPONSE BLOCK

  The content of this block is the same as the Delivery Response Block
  in the Delivery Response IOTP Message associated with a Delivery
  Document Exchange (see section 8.1.4.3).

  8.1.6 9.1.4.3).

  9.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 IOTP Transactions. This
  means it could occur:

      o before another IOTP Transaction

      o at the same time as another IOTP Transaction

      o independently of any other IOTP Transaction.

  The Baseline Authentication IOTP Transaction consists of just an
  Authentication Document Exchange (see section 8.1.1) 9.1.1) as illustrated by b
  the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

START -------------------------------------------------------
                                                             v
                                                    ----------------
                                                   | AUTHENTICATION |
                                                    ----------------
                                                              |
                                                              |
                                                              |
                                                              |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                                                              |
                                                              |
                                                              |
                                                              |
                                                              |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                                                              |
                                                              |
                                                              |
      ----------        ---------                             |
     | DELIVERY |      | PAYMENT |                            |
     |          |      | {second)|                            |
      ----------        ---------                             |
                                                              v
                                                            STOP

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
            Figure 26 24 Baseline Authentication IOTP Transaction

  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) [SSL/TLS]) with a customer
       - authenticate the customer using the Baseline Authentication
         IOTP Transaction, and then
       - provide the customer with access to account information and
         other services with the confidence that they are communicating
         with a bona fide customer.

      o as a means of providing a Merchant role with Organisation
        Components that contain information about Consumer and
        DelivTo Trading Roles

      o so that a Consumer may authenticate a Payment Handler
        before starting a payment.

  8.1.7

  9.1.7 Baseline Deposit IOTP Transaction

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

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

  The Baseline Deposit IOTP Transaction consists of the following
  Document Exchanges:

      o an optional Authentication Document Exchange (see section
    8.1.1)
        9.1.1)

      o an Offer Document Exchange (see section 8.1.2), 9.1.2), and

      o a Payment Document Exchange (see section 8.1.3). 9.1.3).

  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   |
                   ---------           --------------
                       |
                        ----------------
                                        |
      ----------        ---------       |
     | DELIVERY |      | PAYMENT |      |
     |          |      | {second)|      |
      ----------        ---------       |
                                        |
                                         -----------------> STOP

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

               Figure 27 25 Baseline Deposit IOTP Transaction

  See section 8.1.12 _Valid 9.1.12 "Valid Combinations of Document Exchanges_ Exchanges" to
  determine which combination of document exchanges apply to a
  particular instance of an IOTP Transaction

  Note that:

      o a Merchant (Financial Institution) may be able to accept a
        deposit in several different types of electronic cash
        although, since the Consumer role that is depositing the
        electronic cash usually knows what type of cash they want
        to deposit, it is usually constrained in practice to only
        one type. However, there may be several different protocols
        which may be used for the same "brand" of electronic cash.

        In this case a Brand Dependent Offer may be appropriate to
        negotiate the protocol to be used.

      o the Merchant (Financial Institution) may use the results of
        the authentication to identify not only the consumer but
        also the account to which the payment is to be deposited.
        If no single account can be identified, then it must be
        obtained by other means. For example:
       - the consumer could specify the account number prior to the
         Baseline Deposit IOTP Transaction starting, or
       - the consumer could have been identified earlier, for example
         using a Baseline Authentication IOTP Transaction, and an
         account selected from a list provided by the Financial
         Institution.

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

  8.1.8

  9.1.8 Baseline Purchase IOTP Transaction

  The Baseline Purchase IOTP Transaction supports the purchase of goods
  or services using any payment method. It consists of the following
  Document Exchanges:

      o an optional Authentication Document Exchange (see section
    8.1.1)
        9.1.1)

      o an Offer Document Exchange (see section 8.1.2) 9.1.2)

      o either:
       - a Payment Document Exchange (see section 8.1.3) 9.1.3) followed by
       - a Delivery Document Exchange (see section 8.1.4) 9.1.4)

      o a Payment Document Exchange only, or

      o a combined Payment and Delivery Document Exchange (see
        section
    8.1.5). 9.1.5).

  The ways in which these Document Exchanges are combined is illustrated illustrate
  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 26 Baseline Purchase IOTP Transaction

  See section 8.1.12 9.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

  9.1.9 Baseline Refund IOTP Transaction

  In business terms the refund process typically consists of:

      o a request for a refund being made by the Consumer to the
        Merchant, typically supported by evidence to demonstrate:
       - the original trade took place, for example by providing a
         receipt for the original transaction
       - using some type of authentication, that the consumer
         requesting the refund is the consumer, or a representative of
         the consumer, who carried out the original trade
       - the reason why the merchant should make the refund

      o the merchant agreeing (or not) to the refund. This may
        involve some negotiation between the Consumer and the
        Merchant, and, if the merchant agrees,

      o a refund payment by the Merchant to the Consumer.

  The Baseline Refund IOTP Transaction supports a subset of the above,
  specifically it supports:

      o stand alone authentication of the Consumer using a separate
        Baseline Authentication IOTP Transaction (see section 8.1.6)
        9.1.6)

      o a refund payment by the Merchant to the Consumer using the
        following two Trading Exchanges:
       - an optional Authentication Document Exchange (see section 8.1.1)
         9.1.1)
       - an Offer Document Exchange (see section 8.1.2), 9.1.2), and
       - a Payment Document Exchange (see section 8.1.3). 9.1.3).

  The ways in which these Document Exchanges are combined is illustrated illustrate
  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 29 27 Baseline Refund IOTP Transaction

  A Baseline Refund IOTP Transaction without an Authentication Document
  Exchange might be used:

      o when authentication of the consumer has been achieved by
        some other means, for example, the consumer has entered
        some previously supplied code in order to identify herself
        and the refund to which the code applies. The code could be
        supplied, for example on a web page or by e-mail.

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

  9.1.10 Baseline Withdrawal IOTP Transaction

  The Baseline Withdrawal IOTP Transaction supports the withdrawal of
  electronic cash from a Financial Institution.

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

  The Baseline Withdrawal IOTP Transaction consists of the following
  Document Exchanges:

      o an optional Authentication Document Exchange (see section
    8.1.1)
        9.1.1)

      o an Offer Document Exchange (see section 8.1.2), 9.1.2), and

      o a Payment Document Exchange (see section 8.1.3). 9.1.3).

  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   |
                   ---------           --------------
                       |
                        ----------------
                                        |
      ----------        ---------       |
     | DELIVERY |      | PAYMENT |      |
     |          |      | {second)|      |
      ----------        ---------       |
                                        |
                                         -----------------> STOP

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

              Figure 30 28 Baseline Withdrawal IOTP Transaction

  Note that:

      o a Merchant (Financial Institution) may be able to offer
        withdrawal of several different types of electronic cash.
        In practice usually only one form of electronic cash may be
        offered. However, there may be several different protocols
        which may be used for the same "brand" of electronic cash

      o the Merchant (Financial Institution) may use the results of
        the authentication to identify not only the consumer but
        also the account from which the withdrawal is to be made.
        If no single account can be identified, then it must be
        obtained by other means. For example:
       - the consumer could specify the account number prior to the
         Baseline Withdrawal IOTP Transaction starting, or
       - the consumer could have been identified earlier, for example
         using a Baseline Authentication IOTP Transaction, and an
         account selected from a list provided by the Financial
         Institution.

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

  8.1.11

  9.1.11 Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange Transaction uses Payment Document
  Exchanges to support the exchange of value in one currency obtained
  using one payment method with value in the same or another currency
  using the same or another payment method. Examples of its use include: include

      o electronic cash advance on a credit card. For example the
        first payment could be a _dollar "dollar SET Payment_ Payment" using a
        credit card with the second payment being a download of
        Visa Cash e-cash in dollars.

      o foreign exchange using the same payment method. For example
        the payment could be an upload of Mondex value in British
        Pounds and the second a download of Mondex value in Euros

      o foreign exchange using different payment methods. For
        example the first payment could be a SET payment in
        Canadian Dollars followed a download of GeldKarte in
        Deutchmarks.

  The Baseline Value Exchange uses the following Document Exchanges:

      o an optional Authentication Document Exchange (see section
    8.1.1)
        9.1.1)

      o an Offer Document Exchange (see section 8.1.2), 9.1.2), which
        provides details of what values and currencies will be
        exchanged, and

      o two Payment Document Exchanges (see section 8.1.3) 9.1.3) which
        carry out the two payments involved.

  The way in which these Document Exchanges may be combined together is
  illustrated by the diagram below.

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

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 29 Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange IOTP Transaction occurs in two basic
  forms:

      o Brand Dependent Value Exchange. Where the content of the
        offer, for example the rate at which one form of value is
        exchanged for another, is dependent on the payment brands
        and protocols selected by the consumer, and

      o Brand Independent Value Exchange. Where the content of the
        offer is not dependent on the payment brands and protocols
        selected.

  [Note]   In the above the role is a Merchant even though the
           organisation carrying out the Value Exchange may be a Bank
           or some other Financial Institution. This is because the
           Bank is acting as a merchant in that they are making an
           offer which the Consumer can either accept or decline.
  [Note End]

  The TPO Block and Offer Response Block may only be combined into the
  same IOTP Message if the content of the Offer Response Block does not
  change as a result of selecting the payment brands and payment
  protocols to be used in the Value Exchange.

  BASELINE VALUE EXCHANGE SIGNATURES

  The use of signatures to ensure the integrity of a Baseline Value
  Exchange is illustrated by the diagram below.

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

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

Signature generated                  IotpMsg (TPO)
by Merchant ensures                  - Trans Ref Block
integrity of the Offer -------->  -  - Signature Block
                                 |   - TPO Block              MERCHANT
                                 |   - Offer Response Block
                                 |
Signature generated by           |

the Payment Handler of           |   IotpMsg (Pay Resp 1)
the first payment binds          |   - Trans Ref Block         PAYMENT
Pay Receipt for the first ----->  -> - Signature Block -----   HANDLER
payment to the Offer                 - Pay Response Block 1 |    1
                                                            |
Signature generated by                                      |
the Payment Handler of           IotpMsg (Pay Resp 2)       |  PAYMENT
the second payment binds           - Trans Ref Block        |  HANDLER
the second payment to the ----->   - Signature Block <------     2
first payment and therefore        - Pay Response Block 2
to the Offer

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

              Figure 32 30 Baseline Value Exchange Signatures
  8.1.12

  9.1.12 Valid Combinations of Document Exchanges

  The following diagram illustrates the data conditions in the various
  IOTP messages which can be used by a Consumer Trading Role to
  determine whether the combination of Document Exchanges are valid.

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

START
  |
  v
Auth Request Block in  =TRUE
 first IOTP Message ? ---------------------------------------
   | = FALSE                                                 |
   v                                                         v
Offer Response Block in                             ----------------
  first IOTP Message ?                             | AUTHENTICATION |
   |=TRUE         |=FALSE                           ----------------
   |              |                                        |
   |              |                                        v
   |                ----------------------       TPO & Offer Response
    -------------                         |    Blocks in last IOTP Msg
                 |                        |     |=TRUE        |=FALSE
                 |                        |     |             v
                 |          ------------- | ----      TPO Block only i if
                 |         |              |           last IOTP Message
                 |         |              |          of Authentication
                 |         |              |          |=TRUE   |=FALSE
                 v         v              v          v        |
               -------------------     -----------------      |
              | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
              |       OFFER       |   |      OFFER      |     |
               -------------------     -----------------      |
                       |                   |                  |
                       v                   v                  |
                    Offer Response Block contains             |
                          Delivery Component ?                |
                         |=FALSE        |=TRUE                |
                      ---               v                     |
                     |        Value of DelivAndPayResp        |
                     |    attribute of Delivery Component ?   |
                     |    |=FALSE         |=TRUE              |
                     |    |               |                   |
                     v    v               v                   |
                   ---------           --------------         |
                  | PAYMENT |         | PAYMENT WITH |        |
                  | (first) |         |   DELIVERY   |        |
                   ---------           --------------         |
                       |                      |               |
                       v                      |               |
         Offer and Response Block contains                    |     -------------->|
               Delivery Component ?                           |
               |=TRUE           |=FALSE                       |
               |                v                             |
               |         Two Payment Components               |
               |      present in Offer Response Block?        |
               |           |=TRUE             |=FALSE         |
               v           v                  |               |
      ----------        ---------             |               |
     | DELIVERY |      | PAYMENT |            |               |
     |          |      | {second)|            |               |
      ----------        ---------             |               |
           |                |                 |               v
            ----------------------------------------------> STOP

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

            Figure 33 31 Valid Combinations of Document Exchanges

1) If first IOTP Message of an IOTP Transaction contains an
   Authentication Request then:

   a) IOTP Transaction includes an Authentication Document Exchange
      (see section 8.1.1). 9.1.1). (Note 1)

   b) If the last IOTP Message of the Authentication Document
      Exchange includes a TPO Block and an Offer Response Block
      then:

      i) IOTP Transaction includes a Brand Independent Offer
         Document Exchange (see section 8.1.2.2). 9.1.2.2). (Note 2)
   c) Otherwise, if the last IOTP Message of the Authentication
      Exchange includes a TPO Block but NO Offer Response Block,
      then:

      i) IOTP Transaction includes a Brand Dependent Offer Document
         Exchange (see section 8.1.2.1). 9.1.2.1). (Note 2)

   d) Otherwise (Authentication Status IOTP Message of the
      Authentication Document Exchange contains neither a TPO Block
      but nor an Offer Response Block)

      i) IOTP Transaction consists of just an Authentication
         Document Exchange. (Note 3)

2) Otherwise (no Authentication Request in first IOTP Message):

   a) IOTP Transaction does not include an Authentication Document
      Exchange (Note 2)

   b) If first IOTP Message contains an Offer Response Block, then:

      i) the IOTP Transaction contains a Brand Independent Offer
         Document Exchange (Note 2)

   c) Otherwise (no Offer Response Block in first IOTP Message):

      i) the IOTP Transaction includes a Brand Dependent Offer
         Document Exchange (Note 2)

3) If an Offer Response Block exists in any IOTP message then:

   a) If the Offer Response Block contains a Delivery Component
      then:

      i) If the DelivAndPayResp attribute of the Delivery Component
         is set to True, then:

         .  the IOTP Transaction consists of a Payment And Delivery
            Document Exchange (see section 8.1.5) 9.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) 9.1.3) followed by a Delivery
            Document Exchange (see section 8.1.4) 9.1.4) (Note 4)

   b) otherwise (the Offer Response Block does not contain a
      Delivery Component)
      i) if the Offer Response Block contains just one Payment
         Component, then:

         .  the IOTP Transaction contains just one Payment Document
            Exchange (Note 5)

      ii)
         if the Offer Response Block contains two Payment
         Components, then:

         .  the IOTP Transaction contains two Payment Document
            Exchanges. The StartAfter attribute of the Payment
            Components is used to indicate which payment occurs
            first (Note 6)

      iii)
          if the Offer Response Block contains no or more than two
         Payment Components, then there is an error

4) Otherwise (no Offer Response Block) there is an error.

  The following table indicates the types of IOTP Transactions which can ca
  validly have the conditions indicated above.

Ref

Note                     IOTP Transaction Validity

  1. Any Payment and Authentication IOTP Transaction

  2. Any Payment and Authentication IOTP Transaction except Baseline
     Authentication

  3. Either Baseline Authentication, or a Baseline Purchase, Refund,
     Deposit, Withdrawal or Value Exchange with a failed
     Authentication

  4. Baseline Purchase only

  5. Baseline Purchase, Refund, Deposit or Withdrawal

  6. Baseline Value Exchange only

  8.1.13

  9.1.13 Combining Authentication Transactions with other Transactions

  In the previous sections an Authentication Document Exchange is shown
  preceding an Offer Document Exchange as part of a single IOTP
  Transaction with the same OTP IOTP Transaction Id.

  It is also possible to run a separate Authentication Transaction at
  any point, even in parallel with another IOTP Transaction. Typically
  this will be used:

      o by a Consumer to authenticate a Merchant, Payment Handler
        or a Delivery Handler, or

      o by a Payment Handler or Delivery Handler to authenticate a
        Consumer.

  In outline the basic process consists of:

      o the Trading Role that decides it wants to carry out an
        authentication of another role suspends the current IOTP
        transaction being carried out

      o a stand-alone Authentication transaction is then carried
        out. This may, at implementer's option, be linked to the
        original IOTP Transaction using a Related To Component (see
        section 3.3.3) in the Transaction Reference Block.

      o if the Authentication transaction is successful, then the
        original IOTP Transaction is restarted

      o if the Authentication fails then the original IOTP
        Transaction is cancelled.

  For example, a Consumer could:

      o authenticate the Payment Handler for a Payment between
        receiving an Offer Response from a Merchant and before
        sending the Payment Request to that Payment Handler

      o authenticate a Delivery Handler for a Delivery between
        receiving the Payment Response from a Payment Handler and
        before sending the Delivery Request

  A Payment Handler could authenticate a Consumer after receiving the
  Payment Request and before sending the next Payment related message.

  A Delivery Handler could authenticate a Consumer after receiving the
  Delivery Request and before sending the Delivery Response.

  [Note]   Some Payment Methods may carry out an authentication within
           the Payment Exchange. In this case the information required
           to carry out the authentication will be included in Payment
           Scheme Components.

           In this instance IOTP aware application will not be aware
           that an authentication has occurred since the Payment Scheme
           Components that contain authentication data request information
           will be indistinguishable from other Payment Scheme
           Components.
  [Note End]

  8.2
  9.2 Infrastructure Transactions

  Infrastructure Transactions are designed to support inquiries on about
  whether or not a transaction has succeeded or a Trading Role's servers server
  are operating correctly. There are two types of transaction:

      o a Transaction Status Inquiry Transaction which provides
        information on the status of an existing or complete IOTP
        transaction, and

      o Ping Transaction that enables one IOTP aware application to
        determine if the IOTP aware application at another Trading
        Role is operating and verify whether or not signatures can
        be handled.

  Each of these is described below

  8.2.1

  9.2.1 Baseline Transaction Status Inquiry IOTP Transaction

  The Baseline IOTP Transaction Status Inquiry provides information on
  the status of an existing or complete IOTP transaction.

  The Trading Blocks used by the Baseline Transaction Status Inquiry
  Transaction are:

      o an Inquiry Request Trading Block (see section 7.12), and 8.12),

      o an Inquiry Response Trading Block (see section 7.13).

  [Note]   Note that:

           o Consumer Inquiries on Authentication transaction are not
             supported. 8.13)

      o Authentication an optional Signature Block (see section 8.16).

  The Inquiry IOTP Transaction can be used for a variety of Consumers as part reasons. Fo
  example:

      o to help in resuming a suspended transaction to determine
        the current state of processing of one of the other roles,

      o for a merchant to determine if a payment, delivery, etc.
        was completed. For example, a Consumer might claim that
        payment was made but no signed IOTP payment receipt was
        available to prove it. If the Merchant makes an inquiry is not
             supported in of
        the Payment Handler then the Merchant can determine the
        whether or not payment was made.

  [Note]   Inquiries on Baseline version of IOTP. Ping IOTP Transactions (see section
           9.2.2) are ignored.
  [Note End]

  WHICH
  MAKING INQUIRIES OF ANOTHER TRADING ROLES CAN RECEIVE INQUIRY REQUESTS

  The ROLE

  One Trading Role may make an inquiry of any other Trading Role at any
  point in time.

  IOTP aware software that supports the Consumer can Trading Role may not:

      o digitally sign a response if requested, since it may not
        have the capability, or

      o respond to an Inquiry Request at all since it may not be
        on-line, or may consider that the request is not reasonable
        since, for example, the Request was not digitally signed.

  As a guideline:

      o the Consumer should send a Transaction Status Inquiry Block
        to the
  appropriate a Trading Role only after the following events have
        occurred:

  o
       - to the Merchant, after sending a TPO Selection Block,

  o
       - to the Payment Handler, after sending a Payment Request Block,

  o
       - to the Delivery Handler, after sending a 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
         Block,

      o other Trading Roles should send the a Transaction Status
        Inquiry Request Block to the Trading Role to which
  it sent the last IOTP message. If the Consumer is inquiring on only after receiving 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
        message from the Consumer IOTP software can send and before sending the inquiry request final
        "Response" 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

      o there are no restrictions on non-Consumer Trading Role is
  up Roles
        sending Inquiries to each implementation. other trading roles.

  TRANSACTION STATUS INQUIRY TRANSPORT SESSION

  For a Transaction Status Inquiry on an ongoing transaction, the
  Consumer shall establish with a Trading Role, transaction a different differen
  transport session from the ongoing transaction. transaction is used. For a
  Transaction Status Inquiry on a past transaction, how the IOTP module
  on the software at the Trading Role is started upon the receipt of
  Inquiry Request message is defined in each Mapping to Transport
  supplement for IOTP.

  TRANSACTION STATUS INQUIRY ERROR HANDLING

  Errors in a Transaction Status Inquiry can be categorised into one of
  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 whic
  was last sent to the Consumer. Consumer Role.

  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) 7.20.2) which describes the nature of the
  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 process.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  1st Role
     |  2nd Role
STEP |     |
 1.          The Consumer first role decides to inquire                     (Merchant, on an IOTP transaction Transaction
             by, for                    Payment Handler, example, clicking on the inquiry button                 Delivery Handler of the an IOTP
             Aware Application. This                    or Financial will then generate an Inquiry                       Institution)
             Request Block and send it to the appropriate Trading Role.
        |
        v

     1 --> 2 INQUIRY REQUEST. IotpMsg: Trans Ref TransRef Block; Signature Block
             (optional); Inquiry Request Block

 2.          The Trading Role checks the
  Block; Inquiry   ----------> digital signature (if
             present). If the recipient wants to respond, then the
             Trading Role checks the transaction status of the
             transaction
  Request Block      Inquiry that is being inquired upon by using
                     Request the
             IotpTransId in the Transaction Id ID Component of the
             Transaction Reference Block. He Block, then generates the
             appropriate Inquiry Response Block based on the status of
                                the transaction and Block, sends the message back
             to the Consumer
                                                          |
                                                          v
     3. The IOTP Aware 1st Role and stops

     1 <-- 2 INQUIRY RESPONSE. IotpMsg: Trans Ref
 Application displays the    <---------------- TransRef Block; Inquiry
 status information to
             Response Block

3.           First role checks the Inquiry Response      Response Block
         end user
             |
             v
           STOP

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

              Figure 34 Baseline Transaction Status Inquiry

  The remainder of and takes
             whatever action is appropriate or perhaps stops. This may
             include displaying status information to the end user.

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

              Figure 32 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.
  Note that the term "original transaction" is the transaction which a
  trading role wants to discover some information about.

  TRANSACTION REFERENCE BLOCK

  The Consumer

  A Trading Role making an inquiry must use the same identical Transaction Id I
  Component (see section 3.3.1) as that was in the inquired original transaction.
  The OtpTransId IotpTransId 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 any in the
  inquired original transaction (see section
  3.4.1).

  INQUIRY REQUEST BLOCK

  The Inquiry Request Block (see section 7.12) 8.12) contains the following
  components:

      o one Inquiry Type Component (see section 6.16). 7.17). This
        identifies whether the inquiry is on an offer, payment, or
        delivery.

      o zero or one Payment Scheme Component Components (see section 6.9). 7.10).
        This is for encapsulating payment scheme specific inquiry
        messages for inquiries on a payment.

  SIGNATURE BLOCK (INQUIRY REQUEST)

  If a signature block is present on the message containing the Inquiry
  Request Block then it may be checked to determine if the Inquiry
  Request is authorised.

  Inquiry Response Blocks should only be generated if the Transaction i
  authorised.

  [Note]   Determining if an Inquiry Request is authorised is at user
           discretion. For example, if the original transaction was
           processed over a secure link then it may be reasonable to
           presume that if the sender of the Inquiry knows the
           Transaction Id component of the original message (including
           for example the timestamp) then the inquiry is likely to be
           genuine.

           Checking for a digital signature is an optional additional
           check that may be used.
  [Note End]

  INQUIRY RESPONSE BLOCK

  The Inquiry Response Block (see section 7.13) 8.13) contains the following
  components:

      o one Status Component (see section 6.14). 7.15). This component hold
        holds the status information on the inquired transaction,

      o zero or one Payment Scheme Components. These contain for
        encapsulated payment scheme specific inquiry messages for
        inquiries on payment.

  8.2.2

  9.2.2 Baseline Ping IOTP Transaction

  The purpose of the Baseline IOTP Ping Transaction is to enable test basic
  connectivity between the Trading Roles that may take part in an IOTP
  Transaction.

  It enables IOTP aware application software to to:

      o determine if the IOTP aware application at another Trading
        Role is operating operating, and verifying

      o verify whether or not the two trading roles signatures can
        be handled. processed.

  For example it can be used by a Merchant to determine if a Payment
  Handler or Delivery Handler is up and running prior to starting a
  Purchase transaction that uses those trading roles.

  The Trading Blocks used by the Baseline Ping IOTP Transaction are:

      o a Ping Request Block (see section 7.14) 8.14)
      o a Ping Response Block (see section 7.15), 8.15), and

      o a Signature Block (see section 7.16). 8.16).

  PING MESSAGES

  The following figure outlines the message flows in the Baseline IOTP
  Ping Transaction.

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

     IOTP TRADING ROLE         IOTP MESSAGE       IOTP TRADING ROLE

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   1st Role
     |  2nd Role
STEP |     |
 1.          The IOTP Aware Application in an
IOTP the first Trading Role
             decides to check whether the counterparty IOTP application
             is up and running. It generates a Ping Request Block and
             optional Signature Block and sends them to the other IOTP Trading Role.
                 |
                 v second
             trading role.

     1 --> 2 PING REQUEST. IotpMsg: Trans Ref --------> Block; Signature Block
             (Optional); Ping Request Block

 2.          The IOTP second Trading Role which receives
   Block; Ping        Ping the Ping Request
             Block generates a Ping
  Request Block     Request Response Block and sends it back to
             the sender of the original Ping Request.
                                                       |
                                                       v
  3. The original sender of the Request with a signature
             block if required.

     1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
             (Optional); Ping Request Response Block

 3.          The first Trading Role checks the returned   <------------      Block; Ping Ping Response Block and
             takes       Ping Response     Response Block appropriate action, if necessary
                |
                v
              STOP

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

                     Figure 35 33 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 initiate an IOTP aware application, transaction, unlike other IOTP
        transaction messages such as TPO or Transaction Status
        Inquiry.

  All IOTP aware applications must return a Ping Response message to the th
  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,
  IotpTransId, 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 IotpTransId of a Ping transaction should be different from any
  other IOTP transaction.

  PING REQUEST BLOCK

  If the Ping Transaction is anonymous then no Organisation Components
  are included in the Ping Request Block (see section 7.7). 8.7).

  If the Ping Transaction is not anonymous then the Ping Request Block
  contains Organisation Components for:

      o the sender of the Ping Request Block, and

      o the verifier of the Signature Component

  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 receive
  the Ping Request Block.

  SIGNATURE BLOCK (PING REQUEST)

  The Ping Request Signature Block (see section 7.16) 8.16) contains the
  following components:

      o one Signature Component (see section 6.17) 7.18)

      o one or more Certificate Components, if required.

  PING RESPONSE BLOCK

  The Ping Response Block (see section 7.15) 8.15) contains the following
  component:

      o the Organisation Component of the sender of the Ping
        Response message

  If the Ping Transaction is not anonymous then the Ping Response
  additionally contains:

      o copies of the Organisation Components contained in the Ping
        Request Block.

  SIGNATURE BLOCK (PING RESPONSE)

  The Ping Response Signature Block (see section 7.16) 8.16) contains the
  following components:

      o one Signature Component (see section 6.17) 7.18)

      o one or more Certificate Components, if required.

  9.

  10. Retrieving Logos

  This section describes how to retrieve logos for display by IOTP aware awar
  software using the Logo Net Locations attribute contained in the Brand Bran
  Element (see section 6.6.1) 7.7.1) and the Organisation Component (see
  section 6.5). 7.6).

  The full address of a logo is defined as follows:
Logo_address ::= Logo_net_location "/" Logo_size
                                    Logo_color_depth ".GIF" ".gif"

  Where:

      o Logo_net_location is obtained from the LogoNetLocn
        attribute in the Brand Element (see section 6.6.1) 7.7.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" "gif" indicates that the logos are in GIF "gif@ format

  Logo_size and Logo_color_depth are specified by the implementer of the th
  IOTP software that is retrieving the logo depending on the size and
  colour that they want to use.

  9.1

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

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

  10.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" "http://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 "gif" format.
  [Note End]
  10.
  11. Brands

  11.1 Brand List Examples

  This example contains three examples Definitions and Brand Selection

  One of the XML key features of IOTP is the ability for a Brand List
  Component. It covers:

  o a simple credit card based example

  o merchant to offe
  a credit card based brand list including promotional credit
    card brands, of Brands from which a consumer may make a selection. This
  section provides an overview of what is involved and

  o provides guidanc
  on how selection of a complex electronic cash based brand list

  Note that:

  o brand lists 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 complex optionally a "Dual Brand" or as simple as required a
        "Promotional Brand",

      o all identification and selection of Promotional Brands -
        Promotional Brands offer a Consumer some additional
        benefit, for example techniques described in this appendix can be
    included in one brand list.

  10.1 Simple Credit Card Based 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 7.7) which contains
        definitions of the XML elements which contain the list of
        Brands offered by a simple example involving: Merchant to a Consumer, and

      o only major credit card Brand Selection Component (section 7.8) for details of how
        a Consumer records the Brand, currency, amount and payment brands
        protocol that was selected.

  11.1.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 single price in credit card such as MasterCard or Visa;

      o a single currency debit card such as MasterCard's Maestro;

      o a single smart card based electronic cash payment handler, and instrument such
        as a Mondex Card, a GeldKarte card or a Visa Cash card
      o a single software based electronic 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 account such as a
        CyberCash or DigiCash account.

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

  11.1.2 Definition of Brand List Including Promotional Brands

  An example

  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 Credit Card based selection. Each Brand List follows. It includes: may have a different Payment Handler.
  Examples of Brands include:

      o two ordinary card payment association brands and two promotional credit
    card brands. The proprietary Brands, for example
        MasterCard, Visa, American Express, Diners Club, Mondex,
        GeldKarte, CyberCash, etc.

      o promotional brands consist of one loyalty
    based (British Airways MasterCard) which offers additional
    loyalty points and one (see below). These include:
       - store based (Walmart) 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.

  11.1.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 offers can be used as either a
    discount on purchases over UC card or a certain amount
  regular MasterCard. The UC card Brand and the MasterCard Brand could
  each have their own separate Payment Handlers. This means that:

      o two payment protocols:
    - SET (Secure Electronic Transactions) see [SET], the merchant treats, for example "UC" 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 "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 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 user assistance, the correct Payment
        Instrument to pay use.

  [Note]   Dual Brands need no special treatment by 'British Airways' MasterCard using the example
  above using SET Merchant and
           therefore getting double air miles, no explicit reference is made to Dual Brands in
           the DTD. This is because, as far as the Merchant is
           concerned, each 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 in a Dual Brand List

  The following is an fairly complex example 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]

  11.1.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 includes:

  o payments using either Mondex, GeldKarte, CyberCash or DigiCash

  o can be
  received in currencies including US dollars, British Pounds, Italian
    Lira, German Marks and Canadian Dollars 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 price 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 payment Brand is made selected, the Merchant changes the relevant
         IOTP Components in Mondex using
    British pounds or US dollars, and the Offer Response to reflect the correct
         amount to be paid

      o more than one payment handler the second (obtaining a benefit through the Payment
        Instrument issuer) does not require that the Offer Response
        is used for payments involving
    Mondex or CyberCash changed

      o support for more than one version 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 CyberCash CyberCoin
    payment protocol.

<BrandList separate Brand.

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

  11.1.5.1 Merchant/Payment Handler Identification of Promotional Brand

  Correct identification that the Consumer is paying using a Promotiona
  Brand is important since a Consumer might fraudulently claim to have
  Promotional Brand that offers a reduced payment amount when in realit
  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 informatio
  (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.

  11.1.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 one of the Brand Identifiers defined by IOTP and pre-
        loaded into the Consumers IOTP Aware application or wallet
        by the developer of the Wallet,

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

  11.1.5.3 Consumer Software Brand Id recommendation

  New Brand Ids are allocated under IANA procedures (see section 12 IAN
  Considerations). Which also contains an initial list of Brand
  Identifiers.

  It is recommended that implementers of consumer IOTP aware
  applications (e.g. software wallets) pre-load their software with the
  then current set of Brand Ids and provide a method by which they can
  be updated. For example, by going to the software developer's web
  site.

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

  11.2.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='MasterCard'
    BrandName='MasterCard Credit'

                                    BrandLogoNetLocn='ftp://otpl
                                    ogos.mastercard.com/masterca
                                    rdcredit'
    ProtocolAmountRefs='M1.33'>
  </Brand>
  <Brand ID ='M.31'
    BrandId='Visa'
    BrandName='Visa Credit'
    BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit'
    ProtocolAmountRefs='M1.33'>
  </Brand>
  <Brand ID ='M1.32'
    BrandId='AmericanExpress'
    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.example.com/etill/sccd1' >
  </PayProtocol>
</BrandList>

  11.2.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='MasterCard'
    BrandName='MasterCard Credit'
    BrandLogoNetLocn='ftp://otplogos.mastercard.com'
    ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0'
                                    ProtocolBrandId='MasterCard:
                                    '>
    </ProtocolBrand>
  </Brand>
  <Brand ID ='M1.4'
    BrandId='Visa'
    BrandName='Visa Credit'
    BrandLogoNetLocn='ftp://otplogos.visa.com'
    ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
    </ProtocolBrand>
  </Brand>
  <Brand ID ='M1.5'
    BrandId='BritishAirwaysMC'
    BrandName='British Airways MasterCard'
    BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
    BrandNarrative='Double air miles with British Airways
                                    MasterCard'
    ProtocolAmountRefs ='M1.7 M1.8' >
    <ProtocolBrand ProtocolId='SET1.0'
                                    ProtocolBrandId='MasterCard:
                                    BA'>
    </ProtocolBrand>
  </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.8'>
  </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>
  </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.example.com/etill/set1' >
    <PackagedContent Transform="BASE64">
      8ueu26e482hd82he82
    </PackagedContent>
  </PayProtocol>
  <PayProtocol ID ='M1.11'
    ProtocolId='SCCD1.0'
    ProtocolName='Secure Channel Credit/Debit'
    PayReqNetLocn='http://www.example.com/etill/sccd1' >
    <PackagedContent Transform="BASE64">
       82hd82he8226e48ueu
    </PackagedContent>
  </PayProtocol>
 </BrandList>

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

  11.2.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 XYZ Co'
  PayDirection='Debit' >
  <Brand ID ='M1.13'
    BrandId='Mondex'
    BrandName='Mondex Electronic Cash'
    BrandLogoNetLocn='ftp://otplogos.mondex.com'
    ProtocolAmountRefs='M1.17 M1.18'>
  </Brand>
  <Brand ID ='M1.14'
    BrandId='GeldKarte'
    BrandName='GeldKarte Electronic Cash'
    BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de'
    ProtocolAmountRefs='M1.19'>
  </Brand>
  <Brand ID ='M1.15'
    BrandId='CyberCoin'
    BrandName='CyberCoin Eletronic Cash'
    BrandLogoNetLocn='http://otplogos.cybercash.com'
    ProtocolAmountRefs ='M1.20' >
  </Brand >
  <Brand ID ='M1.16'
    BrandId='DigiCash'
    BrandName='DigiCash Electronic Cash'
    BrandLogoNetLocn='http://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='CyberCoin Version 1.0'
    PayReqNetLocn='http://www.cybercash.com/ccoin' >
  </PayProtocol>
  <PayProtocol ID ='M1.34'
    ProtocolId='CCashv2.0'
    ProtocolName='CyberCoin Version 2.0'
    PayReqNetLocn='http://www.cybercash.com/ccoin' >
  </PayProtocol>
  <PayProtocol ID ='M1.35'
    ProtocolId='GKv1.0'
    ProtocolName='GeldKarte Version 1.0'
    PayReqNetLocn='http://www.example.com/pgway' >
  </PayProtocol>
  <PayProtocol ID ='M1.36'
    ProtocolId='DCashv1.0'
    ProtocolName='DigiCash Protocol Version 1.0'
    PayReqNetLocn='http://www.example.com/digicash' >
  </PayProtocol>
  </BrandList>
  12. IANA Considerations

  12.1 Codes Controlled by IANA

  To help ensure interoperability, there is a need for codes used by
  IOTP to be maintained in a controlled environment so that their
  meaning and usage are well defined and duplicate codes avoided. [IANA
  is the mechanism to be used for this purpose as described in RFC 2434

  The element types and attributes names to which this procedure applie
  is shown in the table below together with the initial values that are
  valid for these attributes.

  Note that:

      o the IETF Trade mailing list's email address is
        ietf-trade@elistx.com

      o "Designated Experts" (see [IANA]) are appointed by the
        IESG.

  Element Type/                      Attribute Values
 Attribute Name

Algorithm/        "sha1" - indicates that a [SHA1] authentication will
Name              apply
(When Algorithm
is a child of an  "signature" - indicates that authentication consists
AuthReq           of the generation of a digital signature.
component)
                  "Pay:ppp" where "ppp" may be set to any valid value
                  for "iotpbrand" (see below)

                  With the exception of Algorithms that begin with
                  "pay:", new values are allocated following review on
                  the IETF Trade mailing list and by the Designated
                  Expert.

                  [Note]   The Algorithm element is likely to be
                           eventually defined within the [DSIG] name
                           space. It is likely that the maintenance
                           procedure defined here may need to vary
                           over time, as the DSIG proposals become
                           more widely adopted.
                  [Note End]
  Element Type/                      Attribute Values
 Attribute Name

Brand/BrandId     The following list of initial BrandIds have been
                  taken from those organisations that have applied for
                  SET certificates as at 1st June 1999:

                  "Amex" - American Express

                  "Dankort" - Dankort

                  "JCB" - JCB

                  "Maestro" - Maestro

                  "MasterCard" - MasterCard

                  "NICOS" - NICOS

                  "VISA" - Visa

                  In addition the following Brand Id values are
                  defined:

                  "Mondex"

                  "GeldKarte"

                  New values of BrandId must be announced to the IETF
                  Trade mailing list and, if there are no objections
                  within three weeks, are allocated on a "first come
                  first served" basis.

CurrencyAmount/   Currency codes are dependent on CurrCodeType (see
CurrCode          below).

                  If CurrCodeType is "ISO4217-A" then the currency
                  code is an alphabetic currency code as defined by
                  [ISO4217].

                  If CurrCodeType is "IOTP" then new values must be
                  announced to the IETF Trade mailing list and, if
                  there are no objections within three weeks, are
                  allocated on a "first come first served" basis.

                  [Note]   The Currency Code Type of IOTP, is designed
                           to allow the support of "new" psuedo
                           currencies such as loyalty or frequent
                           flyer points. At the time of writing this
  Element Type/                      Attribute Values
 Attribute Name
                           specification, no currency codes of this
                           type have been defined.
                  [Note End]

CurrencyAmount/   "ISO4217-A"
CurrCodeType
                  "IOTP"

                  New values of CurrCodeType attribute are allocated
                  following review on the IETF Trade mailing list and
                  by the Designated Expert.

DeliveryData/     "Post"
DelivMethod
                  "Web"

                  "Email"

                  New values of Delivery Method attribute are
                  allocated following review on the IETF Trade mailing
                  list and by the Designated Expert. This may require
                  the publication of additional documentation to
                  describe how the delivery method is used.

PackagedContent/  "PCDATA"
Content
                  "MIME"

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

                  "XML"

                  If the Content attribute is of the form
                  "MIME"mimetype", then control of new values for
                  "mimetype" is as defined in [MIME].

                  Otherwise, new values of the Content attribute are
                  allocated following review on the IETF Trade mailing
                  list and by the Designated Expert. This may require
                  the publication of additional documentation to
                  describe how the new attribute is used within a
                  Packaged Content element.

RelatedTo/        "IotpTransaction"
RelationshipType
                  "Reference"
  Element Type/                      Attribute Values
 Attribute Name

                  New values of the RelationshipType attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the delivery method is
                  used.

Status/           Offer
StatusType
                  Payment

                  Delivery

                  Authentication

                  Unidentified

                  New values of the Status Type attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Status, and
                  o review of the document on the IETF Trade mailing
                    list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Status Type attribute may be combined with your Walmart Card
                           documents that describe new Trading Roles
                           and types of signatures (see below).
                  [Note End]

TradingRole/      "Consumer"
TradingRole
                  "Merchant"

                  "PaymentHandler"

                  "DeliveryHandler"

                  "DelivTo"

                  "CustCare"

                  New values of the Trading Role attribute are
                  allocated following:

  Element Type/                      Attribute Values
 Attribute Name
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Trading Role, and
                  o review of the document 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 the IETF Trade mailing
                    list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Trading Role attribute may be combined with
                           documents that describe new Status Types
                           (see above) and types of signatures (see
                           below).
                  [Note End]

TransId/          "BaselineAuthentication"
IotpTransType
                  "BaselineDeposit"

                  "BaselinePurchase"

                  "BaselineRefund"

                  "BaselineWithdrawal"

                  "BaselineValueExchange"

                  "BaselineInquiry"

                  "BaselinePing"

                  New values of the IotpTransType attribute are
                  allocated following:
                  o publication to the IETF Trade mailing list, of an
                    RFC describing the new IOTP Protocol Version 1.0'
    PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
  </PayProtocol>
  <PayProtocol ID ='M1.32'
    ProtocolId='MXv1.0'
    ProtocolName='Mondex Transaction, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

Attibute/ Content "OfferResponse"
(see Signature
Component)        "PaymentResponse"

                  "DeliveryResponse"

                  "AuthenticationRequest"

                  "AuthenticationResponse"
  Element Type/                      Attribute Values
 Attribute Name

                  "PingRequest"

                  "PingResponse"

                  New values of the code that define the type of a
                  signature are allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange where the
                    signature is being used, and
                  o review of the document on the IETF Trade mailing
                    list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           types of signatures may be combined with
                           documents that describe new Status Types
                           and Trading Roles (see above).
                  [Note End]

  12.2 Codes not controlled by IANA

  In addition to the formal development and registration of codes as
  described above, there is still a need for developers to experiment
  using new 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. codes. For this reason, "user defined codes" may be
  used to identify additional values for the codes contained within thi
  specification without 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.

  13. Internet Open Trading Protocol Data Type Definition

  This section contains the XML DTD for the Internet Open Trading
  Protocols.

<!--
******************************************************
*                                                    *
* INTERNET OPEN TRADING PROTOCOL DTD VERSION 1.0.1 04      *
* Filename: iotp-v1.0-protocol-04.dtd                *
*                                                    *
* Changes from version 1.0                           * 03 (iotp-v1.0-protocol-03.dtd)*
* - Added xmlns namespace attribute changed SigBlk to OtpMessage Signatures in the IotpMessage  *
*   element to make consistent with the new signature*
*   definition                                       *
* - Added SenderTradingRoleRef added LangPrefList and CharSetPrefList to MsgId Component  *
* - Added Name attribute   component to PackagedContent element indicate language and character set *
* - Changed usage   preference of PackagedContent in following    *
*   elements to support multiple PackagedContent     *
*   occurences: AuthData, AuthResp, Order, Brand,    *
*   ProtocolAmount, PayProtocol, BrandSelBrandInfo, sender of the message              *
*   BrandSelProtocolAmountInfo, - replace PayReceiptRefs attribute by              *
*   BrandSelCurrencyAmountInfo, PaySchemeData,   PayReceiptNameRefs in the Pay Receipt Component  *
*   PayReceipt, PaymentNote, Delivery, DeliveryData, - add PaymentRef as required attribute of          *
*   DeliveryNote and TradingRoleData.   Payment Scheme Data                              *
* - Changed the REQUIRED 'Otp' to IMPLIED on the           *
*   SenderNetLocn and SecureSenderNetLoc attributes  *
*   of the ProtocolOptions component 'Iotp' in OtpMessage element    *
* - Changed TradingRole element by: adding Id        *
*   attribute, changing CancelNetLocn and ErrorLocn  *
*   attributes 'Otp' to Required from Implied, adding 'Iotp' in following attribute   *
*   ErrorLogNetLocn attribute   names: OtpTransId, OtpTransType, RespOtpMsg,     *
* - Removed PackagedContent from Payment Component   OtpMsgIdPrefix, OtpMsgRef, LastReceivedOtpMsgRef,*
*   LastSentOtpMsgRef                                *
* - Removed Added AuthenticationId after the AuthDataRef Id attribute from the in *
*   Payment Component   the AuthResp block                               *
* - Changed PayReceiptRefs attribute of the Payment Deleted IotpMsgIdPrefix from Org Component and   *
*   Receipt component   added IotpMsgIdPrefix to Implied from Required Trading Role Component  *
* - Changed the permitted values occurence of StatusType       *
*   attribute AuthData in the Status Component and Type AuthReq     *
*   attribute in the Inquiry Type Component   block from '?' to be '*', so that each AuthData     *
*   NMTOKEN to allow extra Status types   component defines an authentication method to be defined*
* - Removed AuthData Component from the Offer *
*   Response Block                                   *
* - Removed Org Component from   chosen, and, in the AuthReq Block AuthData Component, changed  *
* - Removed Status Component   Packaged content occurences from the AuthResp Block '?' to '*' and  *
* - Added an AuthStatusBlk Block   removed AlgorithmRefs attribute                  *
* - Removed AuthData Added TradingRoleInfoReq component from PayReqBlk to request    *
* - Added   information about a CancelBlk Block Trading Role                 *
* - Added Status Component Changed Pay Response Block (PayRespBlk) to the Payment Instrument make  *
*   Customer Care Response Block   Pay Receipt Component (PayReeipt) optional       *
* - A number Changed occurence of layout changes to improve appearance PackagedContent within the  *
* - Removed references   PayReceipt component from '+' to payment instrument customer*
*   care. Specifically: removed PayInstCCExchBlk, '*'             *
*   PayInstCCReqBlk, PayInstCCRespBlk, and - Add ProtocolBrand element defintion as child of  *
*   PayMethodInfo and reference to these   Brand element                                    *
* - Removed OtpSig and OtpCert components and Changed IotpMsgRef in the ErrorLocation element  *
*   replaced with Signatures and Certificate   from Required to Implied                         *
*   components based on DSIG proposal - Change ElRef attribute in StatusComponent from   *
* - Added Algorithm Element   Required to AuthData Block Implied                              *
* - Removed AuthMethod Changed CancelNetLocn and added AlgorithmRefs ErroNetLocn attributes *
*   attribute   in TradingRole element from Required to AuthData Block Implied  *
* - Added SelectedAlgorithmRef Changed NMTOKEN to CDATA in the Name attribute   *
*   of the PackagedContent element                   *
* - Changed NMTOKEN to CDATA in the BrandId attribute*

*   of the Brand element                             *   AuthResp Block
* - Replaced IOTP signatures DTD with copy from      *
*   version '01' of the IOTP signatures specificaiton*
*                                                    *
* Copyright Internet Engineering Task Force 1998,99  *
*                                                    *
******************************************************

******************************************************
* OTP IOTP MESSAGE DEFINITION                            *
******************************************************
 -->

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

<!--
******************************************************
* 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
 IotpTransId        NMTOKEN #REQUIRED
 OtpTransType
 IotpTransType      CDATA   #REQUIRED
 TransTimeStamp     CDATA   #REQUIRED >

<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
 ID                 ID      #REQUIRED
 RespOtpMsg
 RespIotpMsg        NMTOKEN #IMPLIED
 xml:lang           NMTOKEN #REQUIRED
 LangPrefList       NMTOKENS #IMPLIED
 CharSetPrefList    NMTOKENS #IMPLIED
 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             CDATA     #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   #IMPLIED
 SecureSenderNetLocn CDATA  #IMPLIED
 SuccessNetLocn     CDATA   #REQUIRED >

<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthData (PackagedContent+, Algorithm+)> AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthData AuthReq
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 SelectedAlgorithmRef NMTOKEN #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
 ID                 ID      #REQUIRED
 TradingRoleList    NMTOKEN #REQUIRED >

<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 OrderIdentifier    CDATA   #REQUIRED
 ShortDesc          CDATA   #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 ApplicableLaw      CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- ORGANISATION COMPONENT -->

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

<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
 ID              ID      #REQUIRED
 TradingRole        NMTOKEN #REQUIRED
 IotpMsgIdPrefix    NMTOKEN #REQUIRED
 CancelNetLocn      CDATA   #REQUIRED   #IMPLIED
 ErrorNetLocn       CDATA   #REQUIRED   #IMPLIED
 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) 'False' >

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

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

<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
 ProtocolId         CDATA   #REQUIRED
 ProtocolBrandId    CDATA   #REQUIRED >

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

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

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

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

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

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

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

<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
 ID                 ID      #REQUIRED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 BrandListRef       NMTOKEN #REQUIRED
 SignedPayReceipt (True | False) #REQUIRED
 StartAfter         NMTOKENS #IMPLIED >

<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #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
 PayReceiptNameRefs NMTOKENS #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
  ID                ID      #REQUIRED
  ContentSoftwareId CDATA   #IMPLIED >

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

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

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

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

<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
  ID                ID      #REQUIRED
  OriginatorElRef   NMTOKEN #REQUIRED
  DestinationElRefs NMTOKENS #REQUIRED >

<!-- INQUIRY TYPE COMPONENT -->
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
 ID                 ID      #REQUIRED
 Type               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
 IotpMsgRef         NMTOKEN #REQUIRED #IMPLIED
 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, Order?, Payment*,
             Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthData?) (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp, (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
 ID                 ID      #REQUIRED >

<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
 ID                 ID      #REQUIRED >

<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, 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, 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 >

<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
 ID                 ID      #REQUIRED >

<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
 ID                 ID      #REQUIRED
 LastReceivedOtpMsgRef
 LastReceivedIotpMsgRef NMTOKEN #IMPLIED
 LastSentOtpMsgRef
 LastSentIotpMsgRef NMTOKEN #IMPLIED >

<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
 ID                 ID      #REQUIRED>

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

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

<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
 ID                 ID      #REQUIRED >

<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION                   *
******************************************************
-->

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

<!--
******************************************************
* IOTP SIGNAUTRE COMPPONENT SIGNATURE COMPONENT DEFINITION                *
******************************************************
-->

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

<!ELEMENT Manifest
  (Algorithm+,
        (       Algorithm+,
                Digest+,
   Attributes?,
                Attribute*,
                OriginatorInfo,
   RecipientInfo+,
                RecipientInfo+
        )
>

<!ATTLIST Manifest
        LocatorHRefBase       CDATA             #IMPLIED
>

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

<!ELEMENT Digest (Value) (Locator, 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                     CDATA           #REQUIRED
>

<!--
******************************************************
* IOTP CERTIFICATE COMPPONENT COMPONENT DEFINITION              *
******************************************************
-->

<!ELEMENT Certificate
  (
  IssuerAndSerialNumber  IssuerAndSerialNumber,  ( Value | Locator ) )> )
>

<!ATTLIST Certificate
        ID                        ID                #IMPLIED
        type                      NMTOKEN           #REQUIRED
>

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

<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION                   *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
        id              ID           #IMPLIED
        encoding ( base64 | none ) #REQUIRED    (base64|none)    #IMPLIED      'base64'
>

<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
        xml:link        CDATA         #FIXED        'simple'
        href            CDATA         #REQUIRED
>
  12.
  14. Glossary

  This section contains a glossary of some of the terms used within this thi
  specification in alphabetical order.

        NAME                           DESCRIPTION

Authenticator       The Organisation which is requesting the
                    authentication of another Organisation, and

Authenticatee       The Organisation being authenticated by an
                    Authenticator

Business Error      See Status Component.

Brand               A Brand is the mark which identifies a
                    particular type of Payment Instrument. A list of
                    Brands are the payment options which are
                    presented by the Merchant to the Consumer and
                    from which the Consumer makes a selection. Each
                    Brand may have a different Payment Handler.
                    Examples of Brands include:
                    o payment association and proprietary Brands,
                      for example MasterCard, Visa, American
                      Express, Diners Club, American Express,
                      Mondex, GeldKarte, CyberCash, etc.
                    o Promotional Brands (see below). These include:
                    o store Brands, where the Payment Instrument is
                      issued to a Consumer by a particular Merchant,
                      for example Walmart, Sears, or Marks and
                      Spencer (UK)
                    o coBrands, for example American Advantage Visa,
                      where an a company uses their own Brand in
                      conjunction with, typically, a payment
                      association Brand.

Consumer            The Organisation which is to receive the benefit
                    of and typically pay for the goods or services.

        NAME                           DESCRIPTION

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 whenever the software which generated
                    the content cannot be identified from the
                    SoftwareId attribute on the Message Id Component
                    (see section 3.3.2)

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 Organisation that physically directly delivers the
                    goods or services to the Consumer on behalf of
                    the Merchant. Delivery can be in the form of
                    either digital goods (e.g. a [MIME] message), or
                    physically delivered using the post or a
                    courier.

Document Exchange   A Document Exchange consists of a set of IOTP
                    Messages exchanged between two parties that
                    implement part or all of two Trading Exchanges
                    simultaneously in order to minimise the number
                    of actual IOTP Messages which must be sent over
                    the Internet.

                    Document Exchanges are combined together in
                    sequence to implement a particular IOTP
                    Transaction.

        NAME                           DESCRIPTION

Dual Brand          A Dual Brand means that a single Payment
                    Instrument may be used as if it were two
                    separate Brands. For example there could be a
                    single Japanese "UC" MasterCard which can be
                    used as either a UC card or a regular
                    MasterCard. The UC card Brand and the MasterCard
                    Brand could each have their own separate Payment
                    Handlers. This means that:
                    o the Merchant treats, for example "UC" and
                      "MasterCard" as two separate Brands when
                      offering a list of Brands to the Consumer,
                    o the Consumer chooses a Brand, for example
                      either "UC" or "MasterCard,
                    o the Consumer IOTP aware application determines
                      which Payment Instrument(s) match the chosen
                      Brand, and selects, perhaps with user
                      assistance, the correct Payment Instrument to
                      use.

Exchange Block      An Exchange Block is sent between the two
                    Trading Roles involved in a Trading Exchange. It
                    contains one or more Trading Components.
                    Exchange Blocks are always sent after a Request
                    Block and before a Response Block in a Trading
                    Exchange. The content of an Exchange Block is
                    dependent on Instrument(s) match the type of Trading Exchange being
                    carried out. chosen
                      Brand, and selects, perhaps with user
                      assistance, the correct Payment Instrument to
                      use.

Error Block         An Error Block reports that a Technical Error
                    was found in an IOTP Message that was previously
                    received. Typically Technical Errors are caused
                    by errors in the XML which has been received or
                    some technical failure of the processing of the
                    IOTP Message. Frequently the generation or
                    receipt of an Error Block will result in failure
                    of the IOTP Transaction. They are distinct from
                    Business Errors, reported in a Status Component,
                    which can also cause failure of an IOTP
                    Transaction.

Exchange Block      An Exchange Block is sent between the two
                    Trading Roles involved in a Trading Exchange. It
                    contains one or more Trading Components.
                    Exchange Blocks are always sent after a Request
                    Block and before a Response Block in a Trading
                    Exchange. The content of an Exchange Block is
                    dependent on the type of Trading Exchange being
                    carried out.

        NAME                           DESCRIPTION

IOTP Message        An IOTP Message is the outermost wrapper for the
                    document(s) which are sent between Trading Roles
                    that are taking part in a trade. It is a well
                    formed XML document. The documents it contains
                    consist of:
                    o a Transaction Reference Block to uniquely
                      identify the IOTP Transaction of which the
                      IOTP Message is part,
                    o an optional Signature Block to digitally sign
                      the Trading Blocks or Trading Components
                      associated with the IOTP Transaction
                    o an optional Error Block to report on technical
                      errors contained in a previously received IOTP
                      Message, and
                    o a collection of IOTP Trading Blocks which
                      carries the data required to carry out an IOTP
                      Transaction.

IOTP Transaction    An instance of an Internet Open Trading Protocol
                    Transaction consists of a set of IOTP Messages
                    transferred between Trading Roles. The rules for
                    what may be contained in the IOTP Messages is
                    defined by the Transaction Type of the IOTP
                    Transaction.

Document Exchange

IOTP Transaction    A Document Exchange consists of a set Transaction Type identifies the type an of
Type                IOTP
                    Messages exchanged between two parties that
                    implement part or all Transaction. Examples of two Transaction Type
                    include: Purchase, Refund, Authentication,
                    Withdrawal, Deposit (of electronic cash). The
                    Transaction Type specifies for an IOTP
                    Transaction:
                    o the Trading Exchanges
                    simultaneously which may be included in order
                      the transaction,
                    o how those Trading Exchanges may be combined to minimise
                      meet the number business needs of actual OTP Messages the transaction
                    o which must Trading Blocks may be sent over
                    the Internet.

                    Document Exchanges are combined together included in
                    sequence to implement a particular the
                      IOTP
                    Transaction. Messages that make up the transaction
                    o Consult this specification for the rules that
                      apply for each Transaction Type.

Merchant            The Organisation from whom the service or goods
                    are being obtained, who is legally responsible
                    for providing the goods or services and receives
                    the benefit of any payment made
        NAME                           DESCRIPTION

Merchant Customer   The Organisation that is involved with customer
Care Provider       dispute negotiation and resolution on behalf of
                    the 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 Organisation that physically receives the
                    payment from the Consumer on behalf of the
                    Merchant

Payment Instrument  A Payment Instrument is the means by which
                    Consumer pays for goods or services offered by a
                    Merchant. It can be, for example:
                    o a credit card such as MasterCard or Visa;
                    o a debit card such as MasterCard's Maestro;
                    o a smart card based electronic cash Payment
                      Instrument such as a Mondex Card, a GeldKarte
                      card or a Visa Cash card
                    o a software based electronic payment account
                      such as a CyberCash CyberCash's CyberCoin or DigiCash
                      account.

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

        NAME                           DESCRIPTION

Promotional Brand   A Promotional Brand means that, if the Consumer
                    pays with that Brand, then the Consumer will
                    receive some additional benefit which can be
                    received in two ways:
                    o at the time of purchase. For example if a
                      Consumer pays with a "Walmart MasterCard" at a
                      Walmart web site, then a 5% discount might
                      apply, which means the Consumer actually pays
                      less,
                    o from their Payment Instrument (card) issuer
                      when the payment appears on their statement.
                      For example loyalty points in a frequent flyer
                      scheme could be awarded based on the total
                      payments made with the Payment Instrument
                      since the last statement was issued.

                    Each Promotional Brand should be identified as a
                    separate Brand in the list of Brands offered by
                    the Merchant. For example: "Walmart", "Sears",
                    "Marks and Spencer" and "American Advantage
                    Visa", would each be a separate Brand.

Receipt Component   A Receipt Component is a record of the
                    successful completion of a Trading Exchange.
                    Examples of Receipt Components include: Payment
                    Receipts, and Delivery Notes. It's content may
                    dependent on the technology used to perform the
                    Trading Exchange. For example a Secure
                    Electronic Transaction (SET) payment receipt
                    consists of SET payment messages which record
                    the result of the payment.

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

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.

        NAME                           DESCRIPTION

Trading Block       A Trading Block consists of one or more Trading
                    Components. One or more Trading Blocks may be
                    contained within the IOTP Messages which are
                    physically sent in the form of [XML] documents
                    between the different Trading Roles that are
                    taking part in a trade. Trading Blocks are of
                    three main types:
                    o a Request Block,
                    o an Exchange Block, or a
                    o a Response Block

Trading Component   A Trading Component is a collection of XML
                    elements and attributes. Trading Components are
                    the child elements of the Trading Blocks.
                    Examples of Trading Components are: Offer, Brand
                    List, Payment Receipt, Delivery [information],
                    Payment Amount [information]
        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.

Trading Role        A Trading Role identifies the different ways in
                    which organisations can participate in a trade.
                    There are five Trading Roles: Consumer,
                    Merchant, Payment Handler, Delivery Handler, and
                    Merchant Customer Care Provider.

        NAME                           DESCRIPTION

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, and
                    Merchant Customer Care Provider.

Transaction Type    A Transaction Type identifies the type an of
                    IOTP Transaction. Examples of Transaction Type
                    include: Purchase, Refund, Authentication,
                    Withdrawal, Deposit (of electronic cash). The
                    Transaction Type specifies for an IOTP
                    Transaction:
                    o the Trading Exchanges which may be included in
                      the transaction,
                    o how those Trading Exchanges may be combined to
                      meet the business needs of the transaction
                    o which Trading Blocks may be included in the
                      IOTP Messages that make up the transaction
                    o Consult this specification for the rules that
                      apply for each Transaction Type.

  13.
  15. 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 an
  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 developin
  Internet standards in which case the procedures for copyrights defined define
  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 TAS
  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.

  14.

  16. 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 "OTP.org", the Domain
            Name for IOTP.       See RFC 1034: Domain names - concepts and facilities.
            P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain
            names - implementation and specification. P.V.
            Mockapetris. Nov-01-1987.

[DSA]       The Digital Signature Algorithm (DSA) published by the
            National Institute of Standards and Technology (NIST) in
            the Digital Signature Standard (DSS), which is a part of
            the US government's Capstone project.

[ECCDSA]    Elliptic Curve Cryptosystems Digital Signature Algorithm
            (ECCDSA). Elliptic curve cryptosystems are analogues of
            public-key cryptosystems such as RSA in which modular
            multiplication is replaced by the elliptic curve
            addition operation. See: V. S. Miller. Use of elliptic
            curves in cryptography. In Advances in Cryptology -
            Crypto '85, pages 417-426, Springer-Verlag, 1986.

[HMAC]      See RFC 2104 HMAC: Keyed-Hashing for Message Authentication Using hash Functions: the
            HMAC Construction. RSA Cryptobytes, Volume 2, Number 1,
            Spring 1996
            Authentication. H. Krawczyk, M. Bellare, R. Canetti.
            February 1997

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

[IOTPDSIG]  A document that describes how data contained in IOTP
            messages may be digitally signed. See
            http://www.ietf.org/internet-drafts/draft-ietf-trade-
            iotp-v1.0-dsig-*.txt.

[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).    See RFC 822: The Standard for the Format of ARPA
            Internet Messages

            . Messages. 13 August 1982, David H Crocker. 13
            August 1982.

[RFC1738]   IETF (Internet Engineering Task Force).   See RFC 1738: Uniform Resource Locators (URL), ed. T.
            Berners-Lee, L. Masinter, M. McCahill. 1994.

[RFC2434]   IETF (Internet Engineering Task Force).   See 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, 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. SSL/TLS. 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>. <http://www.setco.org>.

[SSL/TLS]   SSL is a standard developed by Netscape for encrypting
            data over IP networks. See
            http://home.netscape.com/eng/ssl3/index.html. TLS is the
            likely successor to SSL being developed by the IETF. See
            http://www.ietf.org/internet-drafts/draft-ietf-tls-
            protocol-05.txt

[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). See
            http://www.itl.nist.gov/div897/pubs/fip180-1.htm

[UTC]       Universal Time Co-ordinated. A method of defining time
            absolutely relative to Greenwich Mean Time (GMT).
            Typically of the form:  "CCYY-MM-DDTHH:MM:SS.sssZ+n"
            where the "+n" defines the number of hours from GMT. See
            ISO DIS8601.

[UTF16]     The Unicode Standard, Version 2.0.  The Unicode
            Consortium, Reading, Massachusetts. See ISO/IEC 10646 1
            Proposed Draft Amendment 1

[X.509]     ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995,
            Including Draft Amendment 1: Certificate Extensions
            (Version 3 Certificate)

[XML        Recommendation for Namespaces in XML, World Wide Web
Namespace]  Consortium, 14 January 1999, "http://www.w3.org/TR/REC-
            xml-names"

[XML]       Extensible Mark Up Language. A W3C recommendation. See
            http://www.w3.org/TR/PR-xml-971208
            http://www.w3.org/TR/1998/REC-xml-19980210 for the 8 December
            1997 10
            February 1998 version.

[XMLDSIG]   A proposal developed by Richard Brown, GlobeSet
            describing an approach to signing XML documents such as
            IOTP Messages. See http://www.ietf.org/internet-
            drafts/draft-brown-xml-dsig-00.txt and discussion on
            IETF Trade WG
  15.

  17. Author's Address

  The author of this document is:

  David Burdett
  Development Director
  Mondex International Ltd
  Advanced Technology Division
  111 Pine St
  San Francisco, 94111
  California
  USA

  Tel: +1 (415) 645 6973

  Email: david.burdett@mondex.com

  The author of this document appreciates the following contributors to
  this protocol (in alphabetic order of company) without which it could
  not have been developed.

      o Phillip Mullarkey, British Telecom plc

      o Andrew Marchewka, Canadian Imperial Bank of Commerce

      o Brian Boesch, CyberCash Inc.

      o Donald Eastlake 3rd, CyberCash Inc.

      o Mark Linehan, International Business Machines

      o Richard Brown, GlobeSet Inc.

      o Peter Chang, Hewlett Packard

      o Masaaki Hiroya, Hitachi Ltd

      o Yoshiaki Kawatsura, Hitachi Ltd

      o Jonathan Sowler, JCP Computer Services Ltd

      o John Wankmueller, MasterCard International

      o Steve Fabes, Mondex International Ltd

      o Surendra Reddy, Oracle Corporation

      o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
      o Chris Smith, Royal Bank of Canada

      o Hans Bernhard-Beykirch, SIZ (IT Development and
        Coordination Centre of the German Savings Banks
        Organisation)

      o W. Reid Carlisle, Spyrus (ex Citibank Universal Card
        Services, formally AT&T Universal Card Services)

      o Efrem Lipkin, Sun Microsystems

      o Terry Allen, Commerce One (formally Veo Systems)

  The author would also like to thank the following organisations for
  their support:

      o Amino Communications
      o DigiCash
      o Fujitsu
      o General Information Systems
      o Globe Id Software
      o Hyperion
      o InterTrader
      o Nobil I T Corp
      o Mercantec
      o Netscape
      o Nippon Telegraph and Telephone Corporation
      o Oracle Corporation
      o Smart Card Integrations Ltd.
      o Spyrus
      o Verifone
      o Unisource nv
      o Wells Fargo Bank

  File name: draft-ietf-trade-iotp-v1.0-protocol-03.txt name:draft-ietf-trade-iotp-v1.0-protocol-04.txt
  Expires:  28 August 1999   13 Februrary 2000