File: rfc2801.txt

package info (click to toggle)
doc-rfc 20170121-1
links: PTS, VCS
area: non-free
in suites: stretch
size: 541,932 kB
ctags: 32
sloc: xml: 267,963; sh: 101; python: 90; perl: 42; makefile: 13
file content (16243 lines) | stat: -rw-r--r-- 598,794 bytes
parent folder | download | duplicates (6)






Network Working Group                                          D. Burdett
Request for Comments: 2801                                   Commerce One
Category: Informational                                        April 2000


                 Internet Open Trading Protocol - IOTP
                              Version 1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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, CyberCoin, GeldKarte, etc. IOTP is able to
   handle cases where such merchant roles as the shopping site, the
   Payment Handler, the Delivery Handler of goods or services, and the
   provider of customer support are performed by different parties or by
   one party.

Table of Contents

   1.  Background .....................................................7
     1.1  Commerce on the Internet, a Different Model .................7
     1.2  Benefits of IOTP ............................................9
     1.3  Baseline IOTP ..............................................10
     1.4  Objectives of Document .....................................10
     1.5  Scope of Document ..........................................11
     1.6  Document Structure .........................................11
     1.7  Intended Readership ........................................13
         1.7.1  Reading Guidelines ...................................13
   2.  Introduction ..................................................14
     2.1  Trading Roles ..............................................16
     2.2  Trading Exchanges ..........................................18
         2.2.1  Offer Exchange .......................................19
         2.2.2  Payment Exchange .....................................21
         2.2.3  Delivery Exchange ....................................24
         2.2.4  Authentication Exchange ..............................26
     2.3  Scope of Baseline IOTP .....................................28



Burdett                      Informational                      [Page 1]

RFC 2801                       IOTP/1.0                       April 2000


   3.  Protocol Structure ............................................31
     3.1  Overview ...................................................32
         3.1.1  IOTP Message Structure ...............................32
         3.1.2  IOTP Transactions ....................................34
     3.2  IOTP Message ...............................................35
         3.2.1  XML Document Prolog ..................................37
     3.3  Transaction Reference Block ................................37
         3.3.1  Transaction Id Component .............................38
         3.3.2  Message Id Component .................................39
         3.3.3  Related To Component .................................41
     3.4  ID Attributes ..............................................42
         3.4.1  IOTP Message ID Attribute Definition .................43
         3.4.2  Block and Component ID Attribute Definitions .........44
         3.4.3  Example of use of ID Attributes ......................46
     3.5  Element References .........................................46
     3.6  Extending IOTP .............................................48
         3.6.1  Extra XML Elements ...................................49
         3.6.2  Opaque Embedded Data .................................50
     3.7  Packaged Content Element ...................................50
         3.7.1  Packaging HTML .......................................52
         3.7.2  Packaging XML ........................................53
     3.8  Identifying Languages ......................................54
     3.9  Secure and Insecure Net Locations ..........................54
     3.10 Cancelled Transactions .....................................55
         3.10.1 Cancelling Transactions ..............................55
         3.10.2 Handling Cancelled Transactions ......................56
   4.  IOTP Error Handling ...........................................56
     4.1  Technical Errors ...........................................57
     4.2  Business Errors ............................................57
     4.3  Error Depth ................................................58
         4.3.1  Transport Level ......................................58
         4.3.2  Message Level ........................................58
         4.3.3  Block Level ..........................................59
     4.4  Idempotency, Processing Sequence, and Message Flow .........61
     4.5  Server Role Processing Sequence ............................62
         4.5.1  Initiating Transactions ..............................62
         4.5.2  Processing Input Messages ............................63
         4.5.3  Cancelling a Transaction .............................70
         4.5.4  Retransmitting Messages ..............................70
     4.6  Client Role Processing Sequence ............................71
         4.6.1  Initiating Transactions ..............................71
         4.6.2  Processing Input Messages ............................72
         4.6.3  Cancelling a Transaction .............................74
         4.6.4  Retransmitting Messages ..............................74
   5.  Security Considerations .......................................74
     5.1  Determining whether to use digital signatures ..............74
     5.2  Symmetric and Asymmetric Cryptography ......................76
     5.3  Data Privacy ...............................................77



Burdett                      Informational                      [Page 2]

RFC 2801                       IOTP/1.0                       April 2000


     5.4  Payment Protocol Security ..................................77
   6.  Digital Signatures and IOTP ...................................77
     6.1  How IOTP uses Digital Signatures ...........................77
         6.1.1  IOTP Signature Example ...............................80
         6.1.2  OriginatorInfo and RecipientInfo Elements ............82
         6.1.3  Using signatures to Prove Actions Complete
                Successfully .........................................83
     6.2  Checking a Signature is Correctly Calculated ...............84
     6.3  Checking a Payment or Delivery can occur ...................85
         6.3.1  Check Request Block sent Correct Organisation ........86
         6.3.2  Check Correct Components present in Request Block ....91
         6.3.3  Check an Action is Authorised ........................91
   7.  Trading Components ............................................93
     7.1  Protocol Options Component .................................96
     7.2  Authentication Request Component ...........................97
     7.3  Authentication Response Component ..........................98
     7.4  Trading Role Information Request Component .................99
     7.5  Order Component ...........................................100
         7.5.1  Order Description Content ...........................101
         7.5.2  OkFrom and OkTo Timestamps ..........................101
     7.6  Organisation Component ....................................102
         7.6.1  Organisation IDs ....................................104
         7.6.2  Trading Role Element ................................105
         7.6.3  Contact Information Element .........................108
         7.6.4  Person Name Element .................................109
         7.6.5  Postal Address Element ..............................110
     7.7  Brand List Component ......................................111
         7.7.1  Brand Element .......................................113
         7.7.2  Protocol Brand Element ..............................115
         7.7.3  Protocol Amount Element .............................116
         7.7.4  Currency Amount Element .............................117
         7.7.5  Pay Protocol Element ................................118
     7.8  Brand Selection Component .................................120
         7.8.1  Brand Selection Brand Info Element ..................122
         7.8.2  Brand Selection Protocol Amount Info Element ........122
         7.8.3  Brand Selection Currency Amount Info Element ........123
     7.9  Payment Component .........................................123
     7.10 Payment Scheme Component ..................................125
     7.11 Payment Receipt Component .................................126
     7.12 Payment Note Component ....................................128
     7.13 Delivery Component ........................................129
         7.13.1 Delivery Data Element ...............................130
     7.14 Consumer Delivery Data Component ..........................132
     7.15 Delivery Note Component ...................................133
     7.16 Status Component ..........................................134
         7.16.1 Offer Completion Codes ..............................137
         7.16.2 Payment Completion Codes ............................138
         7.16.3 Delivery Completion Codes ...........................140



Burdett                      Informational                      [Page 3]

RFC 2801                       IOTP/1.0                       April 2000


         7.16.4 Authentication Completion Codes .....................142
         7.16.5 Undefined Completion Codes ..........................144
         7.16.6 Transaction Inquiry Completion Codes ................144
     7.17 Trading Role Data Component ...............................144
         7.17.1 Who Receives a Trading Role Data Component ..........145
     7.18 Inquiry Type Component ....................................146
     7.19 Signature Component .......................................147
         7.19.1 IOTP usage of signature elements and attributes .....148
         7.19.2 Offer Response Signature Component ..................150
         7.19.3 Payment Receipt Signature Component .................151
         7.19.4 Delivery Response Signature Component ...............152
         7.19.5 Authentication Request Signature Component ..........152
         7.19.6 Authentication Response Signature Component .........153
         7.19.7 Inquiry Request Signature Component .................153
         7.19.8 Inquiry Response Signature Component ................153
         7.19.9 Ping Request Signature Component ....................153
         7.19.10 Ping Response Signature Component...................154
     7.20 Certificate Component .....................................154
         7.20.1 IOTP usage of signature elements and attributes .....154
     7.21 Error Component ...........................................154
         7.21.1 Error Processing Guidelines .........................157
         7.21.2 Error Codes .........................................158
         7.21.3 Error Location Element ..............................162
   8.  Trading Blocks ...............................................163
     8.1  Trading Protocol Options Block ............................166
     8.2  TPO Selection Block .......................................167
     8.3  Offer Response Block ......................................168
     8.4  Authentication Request Block ..............................169
     8.5  Authentication Response Block .............................170
     8.6  Authentication Status Block ...............................171
     8.7  Payment Request Block .....................................171
     8.8  Payment Exchange Block ....................................173
     8.9  Payment Response Block ....................................173
     8.10 Delivery Request Block ....................................175
     8.11 Delivery Response Block ...................................176
     8.12 Inquiry Request Trading Block .............................177
     8.13 Inquiry Response Trading Block ............................177
     8.14 Ping Request Block ........................................179
     8.15 Ping Response Block .......................................179
     8.16 Signature Block ...........................................181
         8.16.1 Signature Block with Offer Response .................182
         8.16.2 Signature Block with Payment Request ................182
         8.16.3 Signature Block with Payment Response ...............182
         8.16.4 Signature Block with Delivery Request ...............182
         8.16.5 Signature Block with Delivery Response ..............182
     8.17 Error Block ...............................................183
     8.18 Cancel Block ..............................................184
   9.  Internet Open Trading Protocol Transactions ..................184



Burdett                      Informational                      [Page 4]

RFC 2801                       IOTP/1.0                       April 2000


     9.1  Authentication and Payment Related IOTP Transactions ......185
         9.1.1  Authentication Document Exchange ....................188
         9.1.2  Offer Document Exchange .............................194
         9.1.3  Payment Document Exchange ...........................203
         9.1.4  Delivery Document Exchange ..........................209
         9.1.5  Payment and Delivery Document Exchange ..............212
         9.1.6  Baseline Authentication IOTP Transaction ............216
         9.1.7  Baseline Deposit IOTP Transaction ...................218
         9.1.8  Baseline Purchase IOTP Transaction ..................220
         9.1.9  Baseline Refund IOTP Transaction ....................222
         9.1.10 Baseline Withdrawal IOTP Transaction ................224
         9.1.11 Baseline Value Exchange IOTP Transaction ............226
         9.1.12 Valid Combinations of Document Exchanges ............230
         9.1.13 Combining Authentication Transactions with other
                Transactions ........................................234
     9.2  Infrastructure Transactions ...............................235
         9.2.1  Baseline Transaction Status Inquiry IOTP Transaction 235
         9.2.2  Baseline Ping IOTP Transaction ......................241
   10. Retrieving Logos .............................................244
     10.1 Logo Size .................................................245
     10.2 Logo Color Depth ..........................................245
     10.3 Logo Net Location Examples ................................246
   11. Brands .......................................................246
     11.1 Brand Definitions and Brand Selection .....................246
         11.1.1 Definition of Payment Instrument ....................247
         11.1.2 Definition of Brand .................................247
         11.1.3 Definition of Dual Brand ............................248
         11.1.4 Definition of Promotional Brand .....................248
         11.1.5 Identifying Promotional Brands ......................249
     11.2 Brand List Examples .......................................251
         11.2.1 Simple Credit Card Based Example ....................252
         11.2.2 Credit Card Brand List Including Promotional Brands..253
         11.2.3 Brand Selection Example .............................254
         11.2.4 Complex Electronic Cash Based Brand List ............255
   12. IANA Considerations ..........................................257
     12.1 Codes Controlled by IANA ..................................257
     12.2 Codes not controlled by IANA ..............................263
   13. Internet Open Trading Protocol Data Type Definition ..........263
   14. Glossary .....................................................277
   15. References ...................................................284
   16. Author's Address .............................................287
   17. Full Copyright Statement .....................................290









Burdett                      Informational                      [Page 5]

RFC 2801                       IOTP/1.0                       April 2000


Table of Figures

   Figure 1 IOTP Trading Roles                                       16
   Figure 2 Offer Exchange                                           19
   Figure 3 Payment Exchange                                         22
   Figure 4 Delivery Exchange                                        25
   Figure 5 Authentication Exchange                                  27
   Figure 6 IOTP Message Structure                                   33
   Figure 7 An IOTP Transaction                                      34
   Figure 8 Example use of ID attributes                             46
   Figure 9 Element References                                       48
   Figure 10 Signature Digests                                       79
   Figure 11 Example use of Signatures for Baseline Purchase         81
   Figure 12 Checking a Payment Handler can carry out a Payment      87
   Figure 13 Checking a Delivery Handler can carry out a Delivery    90
   Figure 14 Trading Components                                      94
   Figure 15 Brand List Element Relationships                       113
   Figure 16 Trading Blocks                                         164
   Figure 17 Payment and Authentication Message Flow Combinations   187
   Figure 18 Authentication Document Exchange                       190
   Figure 19 Brand Dependent Offer Document Exchange                196
   Figure 20 Brand Independent Offer Exchange                       198
   Figure 21 Payment Document Exchange                              204
   Figure 22 Delivery Document Exchange                             210
   Figure 23 Payment and Delivery Document Exchange                 214
   Figure 24 Baseline Authentication IOTP Transaction               217
   Figure 25 Baseline Deposit IOTP Transaction                      219
   Figure 26 Baseline Purchase IOTP Transaction                     221
   Figure 27 Baseline Refund IOTP Transaction                       223
   Figure 28 Baseline Withdrawal IOTP Transaction                   225
   Figure 29 Baseline Value Exchange IOTP Transaction               228
   Figure 30 Baseline Value Exchange Signatures                     230
   Figure 31 Valid Combinations of Document Exchanges               231
   Figure 32 Baseline Transaction Status Inquiry                    238
   Figure 33 Baseline Ping Messages                                 242
















Burdett                      Informational                      [Page 6]

RFC 2801                       IOTP/1.0                       April 2000


1. Background

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

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

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

   In summary, IOTP supports:

   o Familiar trading models

   o New trading models

   o Global interoperability

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

1.1 Commerce on the Internet, a Different Model

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




Burdett                      Informational                      [Page 7]

RFC 2801                       IOTP/1.0                       April 2000


   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.




Burdett                      Informational                      [Page 8]

RFC 2801                       IOTP/1.0                       April 2000


1.2 Benefits of IOTP

   ELECTRONIC COMMERCE SOFTWARE VENDORS

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

   PAYMENT BRANDS

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

   MERCHANTS

   There are several benefits for Merchants:

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

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

   o  through receiving payment and delivery receipts from their
      customers, they will be able to provide customer care knowing that
      they are dealing with the individual or organisation with which
      they originally traded

   o  new merchants will be able to enter this new (Internet) market-
      place with new products and services, using the new trading
      opportunities which IOTP presents

   BANKS AND FINANCIAL INSTITUTIONS

   There are also several benefits for Banks and Financial Institutions:

   o  they will be able to provide IOTP support for merchants

   o  they will find new opportunities for IOTP related services:

      -  providing customer care for merchants
      -  fees from processing new payments and deposits





Burdett                      Informational                      [Page 9]

RFC 2801                       IOTP/1.0                       April 2000


   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, for example purchases and refunds.

   The group that has worked on the IOTP see an extended version being
   developed over time but feel a need to focus on a limited function
   but completely usable specification in order that implementers can
   develop solutions that work now.

   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 and earlier
   revisions of version 1.0 published during 1999) which prove that the
   IOTP works.

1.4 Objectives of Document

   The objectives of this document are to provide a 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.







Burdett                      Informational                     [Page 10]

RFC 2801                       IOTP/1.0                       April 2000


   The purpose of the document is:

   o  to allow potential developers of products based on the protocol to
      develop 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.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, eCash, 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.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.



Burdett                      Informational                     [Page 11]

RFC 2801                       IOTP/1.0                       April 2000


   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 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 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; how to check a
      signature is correctly calculated and how the various Trading
      Roles that participate in trade should check signatures when
      required.

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

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

   o  Section 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 10 - Retrieving Logos: This section describes how IOTP
      specific logos can be retrieved.







Burdett                      Informational                     [Page 12]

RFC 2801                       IOTP/1.0                       April 2000


   o  Section 11 - Brands: This section 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 of Brand Lists.

   o  Section 12 - IANA Considerations: This section describes how new
      values for codes used by IOTP are co-ordinated.

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

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

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

   o  Section 16 - The Author's Address

   o  Section 17 - Full Copyright Statement

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

   o Section 1 - Background

   o Section 2 - Introduction

   o Section 3 - Protocol Structure

   o Section 4 - IOTP Error Handling



Burdett                      Informational                     [Page 13]

RFC 2801                       IOTP/1.0                       April 2000


   o Section 5 - Security Considerations

   o Section 9 - Internet Open Trading Protocol Transactions

   o Section 11 - Brands

   o Section 12 - IANA Considerations

   o Section 10 - Retrieving Logos

   Review the detailed XML definitions:

   o Section 8 - Trading Blocks

   o Section 7 - Trading Components

   o Section 6 - Digital Signatures and IOTP

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






Burdett                      Informational                     [Page 14]

RFC 2801                       IOTP/1.0                       April 2000


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

































Burdett                      Informational                     [Page 15]

RFC 2801                       IOTP/1.0                       April 2000


2.1 Trading Roles

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

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

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

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

                    Figure 1 IOTP Trading Roles




















Burdett                      Informational                     [Page 16]

RFC 2801                       IOTP/1.0                       April 2000


   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 than an actual organisation.

   An individual organisation may take multiple roles. For example a
   company which is selling goods and services on the Internet could
   take the role of Merchant when selling goods or services and the role
   of Consumer when the company is buying goods or services itself.

   As roles occur in different places there is a need for the
   organisations involved in the trade to exchange data, i.e. to carry
   out Trading Exchanges, so that the trade can be completed.






Burdett                      Informational                     [Page 17]

RFC 2801                       IOTP/1.0                       April 2000


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
      goods, or delivery information about physical goods from the
      Delivery Handler to the Consumer, and

   o  Authentication. The Authentication Exchange can be used by any
      Trading Role to authenticate another Trading Role to check that
      they are who they appear to be.

   IOTP Transactions are composed of various combinations of these
   Trading Exchanges.  For example, an IOTP Purchase transaction
   includes Offer, Payment, and Delivery Trading Exchanges.  As another
   example, an IOTP Value Exchange transaction is composed of an Offer
   Trading Exchange and two Payment Trading Exchanges.

   Trading Exchanges consist of Trading Components that are transmitted
   between the various Trading Roles.  Where possible, the number of
   round-trip delays in an IOTP Transaction is minimised by packing the
   Components from several Trading Exchanges into combination IOTP
   Messages.  For example, the IOTP Purchase transaction combines a
   Delivery Organisation Component with an Offer Response Component in
   order to avoid an extra Consumer request and response.

   Each of the IOTP Trading Exchanges is described in more detail below.
   For clarity of description, these describe the Trading Exchanges as
   though they were standalone operations.  For performance reasons, the
   Trading Exchanges are intermingled in the actual IOTP Transaction
   definitions.









Burdett                      Informational                     [Page 18]

RFC 2801                       IOTP/1.0                       April 2000


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
     |  Merchant
STEP |     |
 1.          Consumer decides to trade and sends information about the
             transaction (requests an offer) to the Merchant e.g.,
             using HTML.

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

 2.          Merchant checks the information provided by the Consumer,
             creates an Offer optionally signs it and sends it to the
             Consumer.

     C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
             (Consumer, DelivTo, Merchant, Payment Handler, Customer
             Care); Order; Payment; Delivery; TradingRoleData (optional)
             Offer Response Signature (optional) that signs other
             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 Status component is used to indicate to other parties that a
      valid Offer Response has been generated

   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




Burdett                      Informational                     [Page 19]

RFC 2801                       IOTP/1.0                       April 2000


      -  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 Trading Role Data component contains data the Merchant wants
      to forward to another Trading Role such as a Payment Handler or
      Delivery Handler

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

   The exact content of the information provided by the Merchant to the
   Consumer will vary depending on the type of IOTP Transaction. For
   example:

   o  low value purchases may not need a signature

   o  the amount to be paid may vary depending on the payment brand and
      payment protocol used

   o  some offers may not involve the delivery of any goods

   o  a value exchange will involve two payments

   o  a merchant may not offer customer care.

   Information provided by the consumer to the merchant is provided
   using a variety of methods, for example, it could be provided:

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





Burdett                      Informational                     [Page 20]

RFC 2801                       IOTP/1.0                       April 2000


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

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer  Pay Handler
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to trade and sends information
                    about the transaction (requests an offer) to the
                    Merchant e.g., using HTML.

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

 2.                 Merchant decides which payment brand, payment
                    protocols and currencies/amounts to offer,
                    places then in a Brand List Component and sends
                    them to the Consumer

     C <-- M        Components: Brand List

 3.                 Consumer selects the payment brand, protocol and
                    currency/amount to use, creates a Brand Selection
                    component and sends it to the Merchant

     C --> M        Component: Brand List Selection






Burdett                      Informational                     [Page 21]

RFC 2801                       IOTP/1.0                       April 2000


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

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

 5.                 Consumer checks the Payment Amount information and
                    if OK requests that the payment starts by sending
                    information to the Payment Handler

     C --------> P  PAYMENT REQUEST. Components: Status, Payment;
                    Organisations (Merchant and Payment Handler);
                    Trading Role Data (optional); Optional Offer
                    Response Signature that signs other components;
                    Pay Scheme Data

 6.                 Payment Handler checks information including
                    optional signature and if OK starts exchanging Pay
                    Scheme Data components for selected payment brand
                    and payment protocol

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme Data

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

     C <-------> P  PAYMENT RESPONSE. Components: Status, Pay Receipt;
                    Payment Note; Trading Role Data (optional);
                    Optional Offer Response Signature; Optional
                    Payment Receipt Signature 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



Burdett                      Informational                     [Page 22]

RFC 2801                       IOTP/1.0                       April 2000


      unauthorised access to account information is prevented through
      use of secure channel transport mechanisms such as 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 Status component is used to indicate to the Payment Handler
      that an earlier exchange (e.g., an Offer Exchange) has
      successfully completed and by the Payment Handler to indicate the
      completion status of the Payment Exchange.

   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 Trading Role Data component contains from other roles (e.g., a
      Merchant) that needs to be  forwarded to the Payment Handler

   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



Burdett                      Informational                     [Page 23]

RFC 2801                       IOTP/1.0                       April 2000


      Scheme Component is defined in the supplements that describe how
      IOTP works with various payment protocols.

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

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

   The example of a Payment Exchange above is the most general case.
   Simpler cases are also possible. For example, if the amount paid is
   not dependent on the payment brand and protocol selected then the
   payment information generated by step 3 can be sent to the Consumer
   at the same time as the Brand List Component generated by step 1.
   These and other variations are described in the Baseline Purchase
   IOTP Transaction (see section 9.1.8).

2.2.3 Delivery Exchange

   The goal of the Delivery Exchange is to cause purchased goods to be
   delivered to the consumer either online or via physical delivery. A
   second goal is to provide a "delivery note" to the consumer,
   providing details about the delivery, such as shipping tracking
   number. The result of the delivery may also be signed so that it can
   be used for customer care in the case of problems with physical
   delivery. The message flow is illustrated in the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  CONSUMER  DELIVERY
     |        HANDLER
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to trade and sends information
                    about what 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 occur, information about the Organisations
                    involved in the delivery and optionally sings it
                    and sends it to the Consumer



Burdett                      Informational                     [Page 24]

RFC 2801                       IOTP/1.0                       April 2000


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

 3.                 Consumer checks delivery information is OK,
                    obtains authorisation for the delivery, for
                    example by making a payment, and sends the
                    delivery information to the Delivery Handler

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

 4.                 Delivery Handler checks information and
                    authorisation. Starts or schedules delivery and
                    creates and then sends a delivery not tot the
                    Consumer which can optionally be signed.

     C <-------- D  DELIVERY RESPONSE. Components: Status; Delivery
                    Note, Trading Role Data (optional); Optional
                    Delivery Response Signature

 5.                 Consumer checks delivery note is OK and accepts or
                    waits for delivery as described in the the Delivery
                    Note.

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

                         Figure 4 Delivery Exchange

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

   o  the Status component is used to indicate to the Delivery Handler
      that an earlier exchange (e.g., an Offer Exchange or Payment
      Exchange) has successfully completed and by the Delivery Handler
      to indicate the completion status of the Delivery Exchange.

   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






Burdett                      Informational                     [Page 25]

RFC 2801                       IOTP/1.0                       April 2000


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

   An Authentication Exchange involves:

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

   o  an Authenticatee - the Organisation being authenticated.





Burdett                      Informational                     [Page 26]

RFC 2801                       IOTP/1.0                       April 2000


   This is illustrated in the diagram below.

 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1
 (Authenticatee)
     |   Organisation 2
     |  (Authenticator)
STEP |     |
 1.          First Organisation, e.g., a Consumer, takes an action (for
             example by pressing a button on an HTML page) which
             requires that the Organisation is authenticated

     1 --> 2 Need for Authentication (outside scope of IOTP)

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

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

 3.          The first Organisation optionally checks any signature
             associated with the Authentication Request then uses the
             specified authentication algorithm to generate an
             Authentication Response which is sent back to the second
             Organisation together with details of any Organisation
             information requested

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

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

     1 <-- 2 AUTHENTICATION STATUS. Component: Status

 5.          The first Organisation then optionally checks the results
             indicated by the Status and any associated signature and
             takes the appropriate action or stops.

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

                      Figure 5 Authentication Exchange



Burdett                      Informational                     [Page 27]

RFC 2801                       IOTP/1.0                       April 2000


   An Authentication Exchange uses the following Trading Components that
   are passed between the two Organisations:

   o  the Authentication Request Component that requests an
      Authentication and indicates the authentication algorithm and
      optional challenge data to be used.

   o  A Trading Role Information Request Component that requests
      information about an Organisation, for example a ship to address.

   o  The Authentication Response Component which contains the challenge
      response generated by the recipient of the Authentication Request
      Component.

   o  Organisation Components 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."

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

   Payment Handlers who can be of three types:

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

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

   o  those that issue value a withdrawal transaction

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







Burdett                      Informational                     [Page 28]

RFC 2801                       IOTP/1.0                       April 2000


                       Merchants

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

 TRANSACTIONS

Purchase        Must                        Must

                       Merchants

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

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

Ping            Must     Must    Must       May       Must      Must

TRADING BLOCKS

TPO             Must     Must    Must       Must

TPO Selection   Must     Must    Must       Must

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

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

Offer Response  Must     Must    Must       Must




Burdett                      Informational                     [Page 29]

RFC 2801                       IOTP/1.0                       April 2000


Payment                                     Must      Must
Request

Payment                                     Must      Must
Exchange

Payment                                     Must      Must
Response

Delivery                                    Must                Must
Request

Delivery                                    Must                Must
Response

                       Merchants

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

Inquiry         Must     Must    Must       Must      Must      Must
Request

Inquiry         Must     Must    Must       Must      Must      Must
Response

Ping Request    Must     Must    Must       Must      Must      Must

Ping Response   Must     Must    Must       Must      Must      Must

Signature       Must     Must    Must     Limited     Must      Must

Error           Must     Must    Must       Must      Must      Must

   In the above table:

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

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

   o  "Depends" means implementation of the Transaction or Trading Block
      depends on one of the following conditions:

      -  if Baseline Authentication IOTP Transaction is supported;




Burdett                      Informational                     [Page 30]

RFC 2801                       IOTP/1.0                       April 2000


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



Burdett                      Informational                     [Page 31]

RFC 2801                       IOTP/1.0                       April 2000


   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.





































Burdett                      Informational                     [Page 32]

RFC 2801                       IOTP/1.0                       April 2000


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

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 (Optional) Used to check
 |                        the signature.
 |-Trading Block <------- Trading Block - an XML Element within an IOTP
 |  |-Trading Comp.       Message that contains a predefined set of
 |  |-Trading Comp.      Trading Components
 |  |-Trading Comp.
 |  |-Trading Comp. <--- Trading Components - XML Elements within a
 |                        Trading Block that contain a predefined set
 |-Trading Block          of XML elements and attributes containing
 |  |-Trading Comp.       information required to support a Trading
 |  |-Trading Comp.       Exchange
 |  |-Trading Comp.
 |  |-Trading Comp.
 |  |-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 Transaction.  Therefore the combination of the ID attribute and




Burdett                      Informational                     [Page 33]

RFC 2801                       IOTP/1.0                       April 2000


   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





Burdett                      Informational                     [Page 34]

RFC 2801                       IOTP/1.0                       April 2000


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

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

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

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

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

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

3.2 IOTP Message

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

   The XML definition of an IOTP Message is as follows.

   <!ELEMENT IotpMessage
      ( TransRefBlk,
        SigBlk?,
        ErrorBlk?,



Burdett                      Informational                     [Page 35]

RFC 2801                       IOTP/1.0                       April 2000


        ( AuthReqBlk |
          AuthRespBlk |
          AuthStatusBlk |
          CancelBlk |
          DeliveryReqBlk |
          DeliveryRespBlk |
          InquiryReqBlk |
          InquiryRespBlk |
          OfferRespBlk |
          PayExchBlk |
          PayReqBlk |
          PayRespBlk |
          PingReqBlk |
          PingRespBlk |
          TpoBlk |
          TpoSelectionBlk
        )*
      ) >
   <!ATTLIST IotpMessage
     xmlns                     CDATA
     'iotp:ietf.org/iotp-v1.0'

   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 Message,
   DeliveryRespBlk    and the content of a Trading Block itself is
   ErrorBlk           dependent on the type of IOTP Transaction being
   InquiryReqBlk,     carried out - see the definition of each
   InquiryRespBlk,    transaction in section 9 Internet Open Trading
   OfferRespBlk,      Protocol Transactions.
   PayExchBlk,
   PayReqBlk,         Full definitions of each Trading Block are
   PayRespBlk,        described in section 8.
   PingReqBlk,
   PingRespBlk,
   SigBlk,
   TpoBlk,
   TpoSelectionBlk

   Attributes:

   xmlns              The [XML Namespace] definition for IOTP messages.



Burdett                      Informational                     [Page 36]

RFC 2801                       IOTP/1.0                       April 2000


3.2.1 XML Document Prolog

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

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

3.3 Transaction Reference Block

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

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

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

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

   The definition of a Transaction Reference Block is as follows:

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

   Attributes:

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

   Content:

   TransId            See 3.3.1 Transaction Id Component immediately
                      below.

   MsgId              See 3.3.2 Message Id Component immediately below.



Burdett                      Informational                     [Page 37]

RFC 2801                       IOTP/1.0                       April 2000


   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'
    IotpTransId        CDATA   #REQUIRED
    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.

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

   IotpTransTyp       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 IotpTransType are managed under the
                      procedure described in section 12 IANA
                      Considerations which also allows user defined
                      values of IotpTransType to be defined.



Burdett                      Informational                     [Page 38]

RFC 2801                       IOTP/1.0                       April 2000


                      In later versions of IOTP, this list will be
                      extended to support different types of standard
                      IOTP 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
    RespIotpMsg        NMTOKEN #IMPLIED
    xml:lang           NMTOKEN #REQUIRED
    LangPrefList       NMTOKENS #IMPLIED
    CharSetPrefList    NMTOKENS #IMPLIED
    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.

   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



Burdett                      Informational                     [Page 39]

RFC 2801                       IOTP/1.0                       April 2000


                          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.

   SenderTradingRoleRef   The Element Reference (see section 3.5) of the
                          Trading Role which has generated the IOTP
                          message. It is used to identify the Net
                          Locations (see section 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.8 Identifying
                          Languages.

   LangPrefList           Optional list of Language codes that conform
                          to [XML] Language Identification. It is used
                          by the sender to indicate, in preference
                          sequence, the languages that the receiver of
                          the message ideally should use when generating
                          a response. There is no obligation on the
                          receiver to respond using one of the indicated
                          languages, but using one of the languages is
                          likely to provide an improved user experience.

   CharSetPrefList        Optional list of Character Set identifiers
                          that conform to [XML] Characters. It is used
                          by the sender to indicate, in preference
                          sequence, the character sets that the receiver
                          of the message ideally should use when
                          generating a response. There is no obligation
                          on the receiver to respond using one of the
                          character sets indicated, but using one of the
                          character sets is likely to provide an
                          improved user experience.

   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:



Burdett                      Informational                     [Page 40]

RFC 2801                       IOTP/1.0                       April 2000


                          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.8 Identifying Languages.

   RelationshipType   Defines the type of the relationship. Valid values
                      are:

                       o IotpTransaction. in which case the Packaged
                         Content Element contains an 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 12 IANA
                      Considerations which also allows user defined
                      values to be defined.




Burdett                      Informational                     [Page 41]

RFC 2801                       IOTP/1.0                       April 2000


   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.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 given an XML "ID" attribute which is used to identify an
   instance of these XML elements. These identifiers are used so that
   one element can be referenced by another. All these attributes are
   given the attribute name ID.




Burdett                      Informational                     [Page 42]

RFC 2801                       IOTP/1.0                       April 2000


   The values of each ID attribute are unique within an IOTP transaction
   i.e. the set of IOTP Messages which have the same globally unique
   Transaction ID Component. Also, once the ID attribute of an element
   has been assigned a value it is never changed. This means that
   whenever an element is copied, the value of the ID attribute remains
   the same.

   As a result it is possible to use these IDs to refer to and locate
   the content of any IOTP Message, Block or Component from any other
   IOTP Message, Block or Component in the same IOTP Transaction using
   Element References (see section 3.5).

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

3.4.1 IOTP Message ID Attribute Definition

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

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

   IotpMsgIdPrefix    Apart from messages which contain: an Inquiry
                      Request Trading Block, an Inquiry Response Trading
                      Block, a Ping Request Trading Block or a Ping
                      Response Trading Block; then 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 or a Ping Request Trading Block, the
                      prefix is set to "I" for Inquiry.

                      For messages which contain an Inquiry Response
                      Trading Block or a Ping Response Trading Block,
                      the prefix is set to "Q".

                      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:




Burdett                      Informational                     [Page 43]

RFC 2801                       IOTP/1.0                       April 2000


                       o "P" - First (only) Payment Handler
                       o "R" - Second Payment Handler
                       o "D" - Delivery Handler
                       o "C" - Deliver To

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

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

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

   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.



Burdett                      Informational                     [Page 44]

RFC 2801                       IOTP/1.0                       April 2000


   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.





























Burdett                      Informational                     [Page 45]

RFC 2801                       IOTP/1.0                       April 2000


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.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. ID=M1.4
 |  |                         Copy Element     |
 |  |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
 |  |                         Copy Element     |
 |  |-Comp. ID=M1.6                            |-Comp. ID=C1.3 *
 |  |-Comp. ID=M1.7                            |-Comp. ID=C1.4 *
 |
 |-Trading Block. ID=M1.9
    |-Comp. ID=M1.10                             * = new elements
    |-Comp. ID=M1.11
    |-Comp. ID=M1.12
    |-Comp. 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,




Burdett                      Informational                     [Page 46]

RFC 2801                       IOTP/1.0                       April 2000


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

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

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

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

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

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

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






























Burdett                      Informational                     [Page 47]

RFC 2801                       IOTP/1.0                       April 2000


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

         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 RefBlock. ID=C1.1
    |  |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId 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.5
    |  |-Comp. ID=M1.7                            |-Comp. ID=C1.4
    |
    |-Trading Block. ID=M1.9
       |-Comp. ID=M1.10
       |-Comp. ID=M1.11
       |-Comp. ID=M1.12
       |-Comp. 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.

3.6 Extending IOTP

   Baseline IOTP defines a minimum protocol which systems supporting
   IOTP must be able to accept. As new versions of IOTP are developed,
   additional types of IOTP Transactions will be defined. In addition to
   this, Baseline and future versions of IOTP will support user
   extensions to IOTP through two mechanisms:





Burdett                      Informational                     [Page 48]

RFC 2801                       IOTP/1.0                       April 2000


   o  extra XML elements, and

   o  new values for existing IOTP codes.

3.6.1 Extra XML Elements

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

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

   o  new Trading Blocks

   o  new Trading Components

   o  new XML elements within a Trading Component.

   The following rules apply:

   o  any new XML element must be declared according to the rules for
      [XML Namespaces]

   o  new XML elements which are either Trading Blocks or Trading
      Components must contain an ID attributes with an attribute name of
      ID.

   In order to make sure that extra XML elements can be processed
   properly, IOTP reserves the use of a special attribute,
   IOTP:Critical, which takes the values True or False and may appear in
   extra elements added to an IOTP message.

   The purpose of this attribute is to allow an IOTP aware application
   to determine if the IOTP transaction can safely continue.
   Specifically:

   o  if an extra XML element has an "IOTP:Critical" attribute with a
      value of "True" and an IOTP aware application does not know how to
      process the element and its child elements, then the IOTP
      transaction has a Technical Error (see section 4.1) and must fail.

   o  if an extra XML element has an "IOTP:Critical" attribute with a
      value of "False" then the IOTP transaction may continue if the
      IOTP aware application does not know how to process it. In this
      case:



Burdett                      Informational                     [Page 49]

RFC 2801                       IOTP/1.0                       April 2000


      -  any extra XML elements contained within an XML element defined
         within the IOTP namespace, must be included with that element
         whenever the IOTP XML element is used or copied by IOTP

      -  the content of the extra element must be ignored except that it
         must be included when it is used in the creation of a digest as
         part of the generation of a signature

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

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

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

   IOTP:Critical     (True | False ) 'True'

3.6.2 Opaque Embedded Data

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

3.7 Packaged Content Element

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

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

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

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

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







Burdett                      Informational                     [Page 50]

RFC 2801                       IOTP/1.0                       April 2000


   <!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
                      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
                      there is only one Packaged Content element.

   Content            This identifies what type of data is contained
                      within the Content of the Packaged Content
                      Element. The valid values for the Content
                      attribute are as follows:
                       o PCDATA. The content of the Packaged Content
                         Element can be treated as PCDATA with no
                         further processing.
                       o MIME. The content of the Packaged Content
                         Element is a complete MIME item. Processing
                         should include looking for MIME headers inside
                         the Packaged Content Element.
                       o MIME:mimetype. The content of the Packaged
                         Content Element is MIME content, with the
                         following header "Content-Type: mimetype".
                         Although it is possible to have MIME:mimetype
                         with the Transform attribute set to NONE, it is
                         far more likely to have Transform attribute set
                         to BASE64. Note that if Transform is NONE is
                         used, then the entire content must still
                         conform to PCDATA. Some characters will need to
                         be encoded either as the XML default entities,
                         or as numeric character entities.






Burdett                      Informational                     [Page 51]

RFC 2801                       IOTP/1.0                       April 2000


                       o XML. The content of the Packaged Content
                         Element can be treated as an XML document.
                         Entities and CDATA sections, or Transform set
                         to BASE64, must be used to ensure that the
                         Packaged Content Element contents are
                         legitimate PCDATA.

                      Values of the Content attribute are controlled
                      under the procedures defined in section 12 IANA
                      Considerations which also allows user defined
                      values to be defined.

   Transform          This identifies the transformation that has been
                      done to the data before it was placed in the
                      content. Valid values are:

                       o NONE. The PCDATA content of the Packaged
                         Content Element is the correct representation
                         of the data. Note that entity expansion must
                         occur first (i.e. replacement of &amp; and
                         &#9;) before the data is examined. CDATA
                         sections may legitimately occur in a Packaged
                         Content Element where the Transform attribute
                         is set to NONE.
                       o BASE64. The PCDATA content of the Packaged
                         Content Element represents a BASE64 encoding of
                         the actual content.

   Content:

   PCDATA             This is the actual data which has been embedded.
                      The format of the data and rules on how to decode
                      it are contained in the Content and the Transform
                      attributes

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

3.7.1 Packaging HTML

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

   o  references to any documents, images or other things, such as
      sounds or web pages, which can affect the recipient's
      understanding of the data which is being packaged must refer to
      other Packaged Elements contained within the same parent element,
      e.g., an Order Description



Burdett                      Informational                     [Page 52]

RFC 2801                       IOTP/1.0                       April 2000


   o  if more than one Packaged Content element is included within a
      parent element in order to meet the previous requirement, then the
      Name attribute of the top level Packaged Content from which
      references to all other Packaged Elements can be determined,
      should have a value of Main

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

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

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

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

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

3.7.2 Packaging XML

   Support for XML is recommended. When XML needs to be displayed, for
   example to display the content of an Order Description to a Consumer,
   then implementers should follow the latest recommendations of 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.





Burdett                      Informational                     [Page 53]

RFC 2801                       IOTP/1.0                       April 2000


   Once these standards become W3C "Recommendations", then it is
   anticipated that this specification will be amended if practical.

3.8 Identifying Languages

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

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

   o  a mandatory xml:lang attribute is contained on every Trading
      Component which contains attributes or content which may need to
      be displayed or printed in a particular language

   o  an optional xml:lang attribute is included on child elements of
      these Trading Components. In this case the value of xml:lang, if
      present, overrides the value for the Trading Component.

   xml:lang attributes which follow these principles are included in the
   Trading Components and their child XML elements defined in section 7.

   A sender of a message, typically a Consumer can indicate a preference
   for a language, and a character set by specifying a list of preferred
   languages/character sets in a Message Id Component (see section
   3.3.2).  Note that there is no obligation on the receiver of such a
   message to respond using one of the listed languages/character sets
   as they may not have the technology to be able to do it. It also
   means that the ability to handle these lists is not a requirement for
   conformance to this specification. However the ability to respond,
   for example using one of the stated languages/character sets is
   likely to provide a better user experience.

3.9 Secure and Insecure Net Locations

   IOTP contains several "Net Locations" which identify places where,
   typically, IOTP Messages may be sent. Net Locations come in two
   types:

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

   o  "Insecure" Net Locations where privacy of data is not assured.

   Note that either a Secure Net Location or an Insecure Net Location or
   both must be present.




Burdett                      Informational                     [Page 54]

RFC 2801                       IOTP/1.0                       April 2000


   If only one of the two Net Locations is present, then the one present
   must be used.

   Where both types of net location are present then either may be used
   depending on the preference of the sender of the message.

3.10 Cancelled Transactions

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

3.10.1 Cancelling Transactions

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

   Note: The Cancel Block can be sent asynchronously of any other IOTP
   Message. Specifically it can be sent either before sending or after
   receiving an IOTP Message from the other Trading Role

   If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
   the interval between sending a "request" block and receiving the
   matching "response" block) then the Cancel Block is sent to the same
   location as the next IOTP Message in the Trading Exchange would have
   been sent.

   If a Consumer cancels a transaction after a Trading Exchange has
   completed (i.e. the "response" block for the Trading Exchange has
   been received), but before the IOTP Transaction has finished then the
   Consumer sends a Cancel Block with an appropriate Status Component to
   the net location identified by the SenderNetLocn or
   SecureSenderNetLocn contained in the Protocol Options Component (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 Transaction
   has completed. Cancelling a complete transaction should be treated as
   a technical error.

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

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

   o after a request block has been received and



Burdett                      Informational                     [Page 55]

RFC 2801                       IOTP/1.0                       April 2000


   o before the response block has been sent

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

3.10.2 Handling Cancelled Transactions

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

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

4. IOTP Error Handling

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

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

   o  the different types of errors which can occur. This is divided
      into:

      -  "technical errors" which are independent of the purpose of the
         IOTP Message,

      -  "business errors" which indicate that there is a problem
         specific to the process (e.g., payment or delivery) which is
         being carried out, and

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

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






Burdett                      Informational                     [Page 56]

RFC 2801                       IOTP/1.0                       April 2000


4.1 Technical Errors

   Technical Errors are those which are independent of the meaning of
   the message. This means, they can affect any attempt at IOTP
   communication.  Typically they are handled in a standard fashion with
   a limited number of standard options for the user. Specifically these
   are:

   o retrying the transmission, or

   o cancelling the transaction.

   When communications are operating sufficiently well, a technical
   error is indicated by an Error Component (see section 7.21) in an
   Error Block (see section 8.17) sent by the party which detected the
   error in an IOTP message to the party which sent the erroneous
   message.

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

   The Error Codes associated with Technical Errors are recorded in the
   Error Component which lists all the different technical errors which
   can be set.

4.2 Business Errors

   Business Errors may occur when the IOTP messages are "technically"
   correct. They are connected with a particular process, for example,
   an offer, payment, delivery or authentication, where each process has
   a different set of possible business errors.

   For example, "Insufficient funds" is a reasonable payment error but
   makes no sense for a delivery while "Back ordered" is a reasonable
   delivery error but not meaningful for a payment. Business errors are
   indicated in the Status Component (see section 7.16) of a "response
   block" of the appropriate type, for example a Payment Response Block
   or a Delivery Response Block. This allows whatever additional
   response related information is needed to accompany the error
   indication.

   Business errors must usually be presented to the user so that they
   can decide what to do next. For example, if the error is insufficient
   funds in a Brand Independent Offer (see section 9.1.2.2), the user
   might wish to choose a different payment instrument/account of the
   same brand or a different brand or payment system. Alternatively, if





Burdett                      Informational                     [Page 57]

RFC 2801                       IOTP/1.0                       April 2000


   the IOTP based implementation allows it and it makes sense for that
   instrument, the user might want to put more funds into the
   instrument/account and try again.

4.3 Error Depth

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

4.3.1 Transport Level

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

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

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

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

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

4.3.2 Message Level

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

   All message level errors are technical errors and are indicated by
   Error Components (see section 7.21) sent to the other party. The
   Error Component includes a Severity attribute which indicates whether



Burdett                      Informational                     [Page 58]

RFC 2801                       IOTP/1.0                       April 2000


   the error is a Warning and may be ignored, a TransientError which
   indicates that a retry may resolve the problem or a HardError in
   which case the transaction must fail.

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

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

   o  XML not valid. The document is not valid XML (see [XML])

   o  block level technical errors (see section 4.3.3) on the
      Transaction Reference Block (see section 3.3) and the Signature
      Block only. Checks on these blocks should only be carried out if
      the XML is valid

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

4.3.3 Block Level

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

   Block level errors can be either:

   o  technical errors, or

   o  business errors

   Technical Errors are further divided into:

   o  Block Level Attribute and Element Checks, and

   o  Block and Component Consistency Checks

   o  Transient Technical Errors





Burdett                      Informational                     [Page 59]

RFC 2801                       IOTP/1.0                       April 2000


   If a technical error occurs related to a block or component, then an
   Error Component is generated for return.

4.3.3.1 Block Level Attribute and Element Checks

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

   The Block Level Attribute & Element checks are:

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

   o  checking that the content of each element conforms to any rules
      contained within this IOTP specification

   o  if the previous checks are OK, then checking the consistency of
      attribute values and element content against other attribute
      values or element content within any other components in the same
      block.

4.3.3.2 Block and Component Consistency Checks

   Block and Component Consistency Checks consist of:

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

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

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

   If the block passes the "Block Level Attribute and Element Checks"
   and the "Block and Component Consistency Checks" then it is processed
   either by the IOTP Aware application or perhaps by some "back-end"
   system such as a payment server.

4.3.3.3 Transient Technical Errors

   During the processing of the Block some temporary failure may occur
   that can potentially be recovered by the other trading role re-
   transmitting, at some slightly later time, the original message that
   they sent.  In this case the other role is informed of the Transient



Burdett                      Informational                     [Page 60]

RFC 2801                       IOTP/1.0                       April 2000


   Error by sending them an Error Component (see section 7.21) with the
   Severity Attribute set to TransientError and the MinRetrySecs
   attribute set to some value suitable for the Transport Mechanism
   and/or payment protocol being used (see appropriate Transport and
   payment protocol Supplements).

   Note that transient technical errors can be generated by any of the
   Trading Roles involved in transaction.

4.3.3.4 Block Level Business Errors

   If a business error occurs in a process such as a Payment or a
   Delivery, then the appropriate type of response block is returned
   containing a Status Component (see section 7.16) with the
   ProcessState attribute set to Failed and the CompletionCode
   indicating the nature of the problem.

   Some business errors may be "transient" in that the Consumer role may
   be able to recover and complete the transaction in some other way.
   For example if the Credit Card that a consumer provided had
   insufficient funds for a purchase, then the Consumer may recover by
   using a different credit card.

   Recovery from "transient" business errors is dependent on the
   CompletionCode. See the definition of the Status Component for what
   is possible.

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

4.4 Idempotency, Processing Sequence, and Message Flow

   IOTP messages are actually a combination of blocks and components as
   described in 3.1.1 IOTP Message Structure. Especially in future
   extensions of IOTP, a rich variety of combinations of such blocks and
   components can occur. It is important that the multiple
   transmission/receipt of the "same" request for 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
   order would want to pay the full amount only once. Most network
   transport mechanisms have some probability of delivering a message
   more than once or not at all, perhaps requiring retransmission. On
   the other hand, a request for status can reasonably be repeated and
   should be processed fresh each time it is received.







Burdett                      Informational                     [Page 61]

RFC 2801                       IOTP/1.0                       April 2000


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

4.5 Server Role Processing Sequence

   "Server roles" are any Trading Role which is not the Consumer role.
   They are "Server roles" since they typically receive a request which
   they must service and then produce a response. However server roles
   can also initiate transactions. More specifically Server Roles must
   be able to:

   o  Initiate a transaction (see section 4.5.1). These are divided
      into:

      -  payment related transactions and

      -  infrastructure transactions

   o  Accept and process a message received from another role (see
      section 4.5.2). This includes:

      -  identifying if the message belongs to a transaction that has
         been received before

      -  handling duplicate messages

      -  generating Transient errors if the servers that process the
         input message are too busy to handle it

      -  processing the message if it is 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 reasonable time (see section 4.5.4).

4.5.1 Initiating Transactions

   Server Roles may initiate a variety of different types of
   transaction.  Specifically:

   o  an Inquiry Transaction (see section 9.2.1)

   o  a Ping Transaction (see section 9.2.2)



Burdett                      Informational                     [Page 62]

RFC 2801                       IOTP/1.0                       April 2000


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

   o  checking the structure and identity of the message

   o  checking for and handling duplicate messages

   o  processing non-duplicate original messages which includes:

      -  checking for errors, then if no errors are found

      -  processing the message to produce an output message if
         appropriate

   Each of these is discussed in more detail below.

4.5.2.1 Checking Structure and Message Identity

   It is critical to check that the message is "well formed" XML and
   that the transaction identifier (IotpTransId attribute on the TransId
   Component) within the IOTP message can be successfully identified
   since an IotpTransId will be needed to generate a response.

   If the input message is not well formed then generate an Error
   Component with a Severity of HardError and ErrorCode of
   XmlNotWellFrmd.

   If the message is well formed but the IotpTransId cannot be
   identified then generate an ErrorComponent with:

   o  a Severity of HardError and an ErrorCode of AttMissing,





Burdett                      Informational                     [Page 63]

RFC 2801                       IOTP/1.0                       April 2000


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

   Insert the Error Component inside an Error Block with a new
   TransactionId component with a new IotpTransId and return it to the
   sender of the original message.

4.5.2.2 Checking/Handling Duplicate Messages

   If the input message can be identified as potentially a valid input
   message then check to see if an "identical" input message has been
   received before. Identical means that all blocks, components,
   elements, attribute values and element content in the input message
   are the same.

   Note: The recommended way of checking for identical messages is to
   check for equal values of their [DOM-HASH]

   If an identical message has been received before then check to see if
   the processing of the previous message has completed.

   If processing has not completed then generate an Error Component with
   a Severity of Transient Error and an Error Code of MsgBeingProc to
   indicate the message is being processed and send it back to the
   sender of the Input Message requesting that the original message be
   resent after an appropriate period of time.

   Otherwise, if processing has completed and resulted in an output
   message then retrieve the last message that was sent and send it
   again.

   If the message is not a duplicate then it should be processed.

4.5.2.3 Processing Non-Duplicate Message

   Once it's been established that the message is not a duplicate, then
   it can be processed. This involves:

   o  checking that a server is available to handle the message,
      generating a Transient Error if it is not

   o  checking the Transaction is Not Already in error or cancelled

   o  validating the input message. This includes:

      -  checking for message level errors

      -  checking for block level errors



Burdett                      Informational                     [Page 64]

RFC 2801                       IOTP/1.0                       April 2000


      -  checking any encapsulated data

   o  checking for errors in the sequence that blocks have been received

   o  generating error components for any errors that result

   o  if neither hard errors nor transient errors result, then
      processing the message and generating an output message, if
      required, for return to the sender of the Input Message

   Note: This approach to 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 reality the state of a transaction or the
   processing ability of the servers may have changed. If up-to-date
   status of transactions or servers is required, then an IOTP
   transaction with a new value for the ID attribute of the MsgId
   component must be used.

   Each of the above steps is discussed below.

   CHECKING A SERVER IS AVAILABLE

   The process that is handling the input message should check that the
   rest of the system is not so busy that a response in a reasonable
   time cannot be produced.

   If the server is too busy, then it should generate an Error Component
   with a Severity of Transient Error and an Error Code of SystemBusy
   and send it back to the sender of the Input Message requesting that
   the original message be 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.

   CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED

   Check that:

   o  previous messages received or sent did not contain or result in
      Hard Errors, and

   o  the Transaction has not been cancelled by either the Consumer or
      the Server Trading Role





Burdett                      Informational                     [Page 65]

RFC 2801                       IOTP/1.0                       April 2000


   If it has then, ignore the message. A transaction with hard errors or
   that has been cancelled, cannot be restarted.

   CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS

   If the transaction is still OK then check for message level errors.
   This involves:

   o  checking the XML is valid

   o  checking that the elements, attributes and content of the
      Transaction Reference Block are without error and conform to this
      specification

   o  checking the digital signature which involves:

      -  checking that the Signature value is correctly calculated, and

      -  the hash values in the digests are correctly calculated where
         the source of the hash value is available.

   Checking for block level errors involves:

   o  checking within each block (apart from the Transaction Reference
      Block) that:

      -  the attributes, elements and element contents are valid

      -  the values of the attributes, elements and element contents are
         consistent within the block

   o  checking that the combination of blocks are valid

   o  checking that the values of the attribute, elements and element
      contents are consistent between the blocks in the input message
      and blocks in earlier messages either sent or received. This
      includes checking that the presence of a block is valid for a
      particular transaction 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 Sequence

   Note: For reasons of brevity, the following explanations of how to
   check for errors in Block sequence, the phrase "refers to an IOTP
   transaction" is interpreted as "is contained in an IOTP Message where



Burdett                      Informational                     [Page 66]

RFC 2801                       IOTP/1.0                       April 2000


   the Trans Ref Block contains an IotpTransId that refers to". So, for
   example, " If an Error or Cancel Block refers to an IOTP transaction
   that is not recognised then ..."  should be interpreted as " If an
   Error or Cancel Block is contained in an IOTP Message where the Trans
   Ref Block contains an IotpTransId that refers to an IOTP transaction
   that is not recognised then ...

   Errors in the sequence that blocks arrive depends on the block.
   Blocks where checking for sequence is required are:

   o  Error and Cancel Blocks. If an Error or Cancel Block refers to an
      IOTP transaction that is not recognised then it is a Hard Error.
      Do not return an error if Error or Cancel Blocks have been
      received for the IOTP Transaction before to avoid looping.

   o  Inquiry Request and Response Blocks. If an Inquiry Request or an
      Inquiry Response Block refers to an IOTP transaction that is not
      recognised then it is a Hard Error

   o  Authentication Request Block. If an Authentication Request Block
      refers to an IOTP transaction that is recognised it is a Hard
      Error

   o  Authentication Response Block. Check as follows:

      -  if an Authentication Response Block does not refer to an IOTP
         transaction that is recognised it is a Hard Error, otherwise

      -  if the Authentication Response Block doesn't refer to an
         Authentication Request that had been previously sent then it is
         a Hard Error, otherwise

      -  if an Authentication Response for the same IOTP transaction has
         been received before and the Authentication was successful then
         it is a Hard Error.

   o  Authentication Status Block. Check as follows:

      -  if an Authentication Status Block does not refer to an IOTP
         transaction that is recognised it is a Hard Error, otherwise

      -  if the Authentication Status Block doesn't refer to an
         Authentication Response that had been previously sent then it
         is a Hard Error, otherwise

      -  if an Authentication Status for the same IOTP transaction has
         been received before then it is a Warning Error




Burdett                      Informational                     [Page 67]

RFC 2801                       IOTP/1.0                       April 2000


   o  TPO Selection Block (Merchant only). Check as follows:

      -  if the TPO Selection Block doesn't refer to an IOTP Transaction
         that is recognised then it is a Hard Error, otherwise

      -  if the TPO Selection Block refers to an IOTP Transaction where
         a TPO Block and Offer Response (in one message) had previously
         been sent then it is a Hard Error, otherwise

      -  if the 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 same TPO Block has been
         received before then it is a Hard Error

   o  Payment Request Block (Payment Handler only). Check as follows:

      -  if the Payment Request Block refers to 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 Payment then it is a Hard Error, otherwise

      -  if there was a previous payment that failed with a non-
         recoverable Completion Code then it is a Hard Error, otherwise

      -  if a previous payment is still in 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 recognised then it is a Hard Error,
         otherwise

      -  if the Payment Exchange doesn't refer to an IOTP Transaction
         where a Payment Exchange had previously been sent then it a
         Hard Error

   o  Delivery Request (Delivery Handler Only). If the Delivery Request
      Block refers to an IOTP Transaction that is recognised by the
      Server then it is a Hard Error







Burdett                      Informational                     [Page 68]

RFC 2801                       IOTP/1.0                       April 2000


   If any Error Components have been generated then collect them into an
   Error Block for sending to the sender of the Input message. Note that
   Error Blocks should be sent back to the sender of the message and to
   the ErrorLogNetLocn for the Trading Role of the sender if one is
   specified.

   Note: The above checking on the sequence of Authentication Responses
   and Payment Requests supports the Consumer re-submitting a repeat
   action request since the previous one failed, for example:

   o  because they did not know the correct response (e.g., a password)
      on an authentication or,

   o  they were unable to pay as there were insufficient funds on a
      credit card

   PROCESS THE ERROR FREE INPUT MESSAGE

   If the input message passes the previous checks then it can be
   processed to produce an output message if required. Note that:

   o  Inquiry Requests on Ping Transactions should be ignored

   o  if the Input message contains an Error Block with a Transient
      Error then wait for the required time then resend the previous
      message, if a response to the earlier message has not been
      received

   o  if the input message contains a Error Component with a  HardError
      or a Cancel Block then stop all further processing of the
      transaction. This includes suppressing the sending of any messages
      currently being generated or responding to any new non-duplicate
      messages that are received

   o  processing 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
      blocks and components have been generated and it is known which
      elements in the message need to be signed.

   If an output message is generated then it should be saved so that it
   can be resent as required if an identical input message is received
   again.  Note that output messages that contain transient errors are
   not saved so that they can be processed afresh when the input message
   is received again.





Burdett                      Informational                     [Page 69]

RFC 2801                       IOTP/1.0                       April 2000


4.5.3 Cancelling a Transaction

   This process is used to cancel a transaction running on an IOTP
   server.  It is initiated by some other process as a result of an
   external request from another system or server that is being run by
   the same Trading Role.  The processing required is as follows:

   o  if the IotpTransId of the transaction to be cancelled is not
      recognised, or complete then fail the request, otherwise

   o  if the IotpTransId refers to a Ping Transaction then fail the
      request, otherwise

   o  determine which Document Exchange to cancel and generate a Cancel
      Block and send it to the other party

   Note: Cancelling a transaction on an IOTP server typically arises for
   a business reason. For example a merchant may have attempted
   authentication several times without success and as a result decides
   to cancel the transaction. Therefore the process that decides to take
   this action needs to send a message from the process/server that made
   the business decision to the IOTP server with the instruction that
   the IOTP transaction should be cancelled.

4.5.4 Retransmitting Messages

   The server should periodically check for transactions where a message
   is expected in return but none has been received after a time that is
   dependent on factors such as:

   o  the Transport Mechanism being used;

   o  the time required to process encapsulated messages (e.g., Payment
      messages) and

   o  whether or not human input is required.

   If no message has been received the original message should be
   resent.  This should occur up to a maximum number of times dependent
   on the reliability of the Transport Mechanism being used.

   If no response is received after the required time then the
   Transaction should be "timed out". In this case, set the process
   state of the transaction to Failed, and a completion code of either:

   o  TimedOutRcvr if the transaction can potentially recovered later,
      or




Burdett                      Informational                     [Page 70]

RFC 2801                       IOTP/1.0                       April 2000


   o  TimedOutNoRcvr if the 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 purchases or
   downloading or withdrawing electronic cash.

   More specifically the Consumer Role must be able to:

   o  Initiate a 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 (see
      section 4.6.2). This includes:

      -  identifying if the message belongs to a transaction that has
         been received before

      -  handling duplicate messages

      -  generating Transient errors if the servers that process the
         input message are too busy to handle it

      -  processing the message if it is error free and, if appropriate,
         producing a response to send back to the other role

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

   o  Re-transmit messages if a response was expected but has not 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 Inquiry Transaction (see section 9.2.1)

   o a Ping Transaction (see section 9.2.2)




Burdett                      Informational                     [Page 71]

RFC 2801                       IOTP/1.0                       April 2000


   o an Authentication Transaction (see section 9.1.6)

4.6.2 Processing Input Messages

   Processing of Input Messages for a Consumer Role is the same as for
   an IOTP Server (see section 4.5.2) except in the area of checking for
   Errors in Block Sequence (for an IOTP Server see section 4.5.2.4).
   This is described below

   Note: The description of the processing for an IOTP Server includes
   consideration of multi-threading of input messages and multi-tasking
   of requests. For the Consumer Role - particularly if running on a
   stand-alone system such as a PC - use of multi-threading is a
   decision of the implementer of the consumer role IOTP solution.

4.6.2.1 Check for Errors in Block Sequence

   The handling of the following blocks is the same as for an IOTP
   Server (see section 4.5.2.4) except that the Consumer Role is
   substituted for 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 a Consumer role might receive, the potential
   errors in the sequence that blocks arrive depends on the block.
   Blocks where checking for sequence is required are:

   o  TPO Block. Check as follows:

      -  if the input message also contains an Authentication Request
         block and an Offer Response Block then there is a Hard Error,
         otherwise

      -  if the input message also contains an Authentication Request
         block and Authentication Status block then there is Hard Error
         otherwise,


      -  if the input message also contains an Authentication Request
         block and the IOTP Transaction is recognised by the Consumer
         role's system, then there is a Hard Error, otherwise






Burdett                      Informational                     [Page 72]

RFC 2801                       IOTP/1.0                       April 2000


      -  if the input message also contains an Authentication Status
         block and the IOTP Transaction is not recognised by the
         Consumer role's system then there is a Hard Error, otherwise

      -  if input message also contains an Authentication Status Block
         and the Authentication Status Block has not been sent after an
         earlier Authentication Response message then there is a hard
         error

      -  if input message also contains an Offer Response Block and the
         IOTP Transaction is recognised by the Consumer role's system
         then there is a Hard Error, otherwise

      -  if the TPO Block occurs on its own and the IOTP Transaction is
         recognised by the Consumer role's system then there is a Hard
         Error

   o Offer Response Block. Check as follows:

      -  if the Offer Response Block is part of a Brand Independent
         Offer Exchange (see section 9.1.2.2) then there is no sequence
         checking as it is part of the first message received, otherwise

      -  if the Offer Response Block is not part of an IOTP Transaction
         that is recognised by the Consumer role then there is a Hard
         Error, otherwise

      -  if the Offer Response Block does not refer to an IOTP
         transaction where a TPO Selection Block was the last message
         sent then there is a Hard Error

   o  Payment Exchange Block. Check as follows:

      -  if the Payment Exchange Block doesn't refer to an IOTP
         Transaction that is recognised by the Consumer role's system
         then there is a Hard Error, otherwise

      -  if the Payment Exchange doesn't refer to an IOTP Transaction
         where either a Payment Request or a Payment Exchange block was
         most recently sent then there is a Hard Error

   o  Payment Response Block. Check as follows:

      -  if the Payment Response Block doesn't refer to an IOTP
         Transaction that is recognised by the Consumer role's system
         then there is a Hard Error, otherwise





Burdett                      Informational                     [Page 73]

RFC 2801                       IOTP/1.0                       April 2000


      -  if the Payment Response doesn't refer to an IOTOP Transaction
         where either a Payment Request or a Payment Exchange block was
         most recently sent then there is a Hard Error

   o  Delivery Response Block. Check as follows:

      -  if the Delivery Response Block doesn't refer to an IOTP
         Transaction that is recognised by the Consumer role's system
         then there is a Hard Error, otherwise

      -  If the Delivery Response doesn't refer to an IOTP Transaction
         where either a Payment Request or 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 on an Consumer role's
   system as a result of an external request from the user, or another
   system or server in the Consumer's role. The processing is the same
   as for an IOTP Server (see section 4.5.3).

4.6.4 Retransmitting Messages

   The process of retransmitting messages is the same as for an IOTP
   Server (see section 4.5.4).

5. Security Considerations

   This section considers, from an 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 is up to the Merchant, or other trading role, to decide
   whether IOTP Messages will include signatures, and for the Consumer



Burdett                      Informational                     [Page 74]

RFC 2801                       IOTP/1.0                       April 2000


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

   o start using signatures,

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

   o accept a lower volume and value of business.

   A non-exhaustive list of the reasons why digital signatures might be
   used follows:

   o  the Merchant (or other trading role) wants to demonstrate that
      they can be trusted. If, for example, a merchant generates an
      Offer Response Signature (see section 7.19.2) using a certificate
      from a trusted third party, known to the Consumer, then the
      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 likely to be required

   o  the Merchant, or other Trading Role, want to generate a record of
      the transaction that is fit for a particular purpose. For example,
      with appropriate trust hierarchies, digital signatures could be
      checked by the Consumer to determine:

      -  if it would be accepted by tax authorities as a valid record of
         a transaction, or

      -  if some warranty, for example from a "Better Business Bureau"
         orsimilar was being provided

   o  the Payment Handler, or Delivery Handler, needs to know that the
      request is unaltered and authorised. For example, in IOTP, details
      of how much to pay is sent to the Consumer in the Offer Response
      and then forwarded to the Payment Handler in a Payment Request. If
      the request is not signed, the Consumer could change the amount
      due by, for example, removing a digit. If the Payment Handler has
      no access to the original payment information in the Offer
      Response, then, without signatures, the Payment Handler cannot be
      sure that the data has not been altered. Similarly, if the payment
      information is not digitally signed, the Payment Handler cannot be
      sure who is the Merchant that is requesting the payment

   o  a Payment Handler or Delivery Handler wants to provide a non-
      refutable record of the completion status of a Payment or
      Delivery. If a Payment Response or Delivery Response is signed,



Burdett                      Informational                     [Page 75]

RFC 2801                       IOTP/1.0                       April 2000


      then the Consumer can later use the record of the Payment or
      Delivery to prove that it occurred.  This could be used, for
      example, for customer care purposes.

   A non-exhaustive list of the reasons why digital signatures might not
   be used follows:

   o  trading roles are 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 some other party. However if the trading roles
      have access to the necessary data, then it might be possible to
      compare, for example, the payment information in the Payment
      Request with the payment information in the Offer Response. Access
      to the data necessary could be realised by, for example, the
      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 communicate in some way. (Note this type of
      communication is outside the current scope of IOTP)

   o  the processing cost of the cryptography is too high. For example,
      if a payment is being made of 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 using symmetric keys with IOTP is that no Public Key
   Infrastructure need be set up and just the Merchant, Payment Handler
   and Delivery Handler need to agree on the shared secrets to use.

   However the disadvantage of symmetric cryptography is that the
   Consumer cannot easily check the credentials of the Merchant, Payment
   Handler, etc. that they are dealing with. This is 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
   being used, the Consumer does not NEED to be provided with any
   digital certificates as the integrity of the transaction is
   determined by, for example, the Payment Handler checking the Offer
   Response Signature copied to the Payment Request.

   Note that symmetric, asymmetric or both types of cryptography may be
   used in a single transaction.



Burdett                      Informational                     [Page 76]

RFC 2801                       IOTP/1.0                       April 2000


5.3 Data Privacy

   Privacy of information is provided by sending IOTP Messages between
   the various Trading Roles using a 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 effect a payment. From the security perspective, this means
   that IOTP neither helps, nor hinders, the achievement of payment
   security.

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

   However what IOTP is designed to 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 and a Delivery.

6. Digital Signatures and IOTP

   IOTP can work successfully without using any digital signatures
   although in 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 describes how to use digital signatures in the
   many situations when they will be needed. Topics covered are:

   o  an overview of how IOTP uses digital signatures

   o  how to check a signature is correctly calculated

   o  how Payment Handlers and Delivery Handlers check they can carry
      out payments or deliveries on behalf of a Merchant.

6.1 How IOTP uses Digital Signatures

   In general, signatures when used with IOTP:

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

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



Burdett                      Informational                     [Page 77]

RFC 2801                       IOTP/1.0                       April 2000


   o  identify:

      -  which Organisation signed (originated) the signature, and

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








































Burdett                      Informational                     [Page 78]

RFC 2801                       IOTP/1.0                       April 2000


   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












Burdett                      Informational                     [Page 79]

RFC 2801                       IOTP/1.0                       April 2000


   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 that one Manifest may be associated with multiple signature
   "Value" elements where each Value element contains a digital
   signature over the same Manifest, perhaps using the same (or
   different) signature algorithm but using a different certificate or
   shared secret key. Specifically it will allow the Merchant to agree
   on different shared secrets keys with their Payment Handler and
   Delivery Handler.

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

   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

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












Burdett                      Informational                     [Page 80]

RFC 2801                       IOTP/1.0                       April 2000


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

TPO SELECTION BLOCK          TPO BLOCK           IOTPSIGNATURE BLOCK
                                                 | (Offer Response)
 Brand Selection             Organisation<---    |------Signature
   Component                 Component       |   |      Component
      |                       |              |           -Manifest
      |BrandList               -Trading Role |            |
      |  Ref                     Element     | Originator |-Orig.
      v                         (Merchant)    ------------|--Info
    Brand List                                    Ref     |
  >Component                                              |
 | |-Protocol       ------>  Organisation     Recipient   |-Recipient
 | | Amount Elem   |         Component <------------------|--Info
 | |   |           |          |                 Refs      |
 | |Pay|Protocol   |Action     -Trading Role              |
 | |   | Ref       |OrgRef       Element                  |
 | |   v           |          (Payment Handler)           |
 |  -PayProtocol--                                        |
 |    Elem                  ->Organisation    Recipient   |-Recipient
 |                         |  Component <--------------------Info
 |                         |  |                 Refs
 |                         |   -Trading Role
 |                         |     Element
 |                         | (Delivery Handler
 |
 |           OFFER RESPONSE BLOCK
 |                         |
 |BrandListRef             |ActionOrgRef
 |                         |
  --Payment                 ---Delivery
   Component                  Component

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

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

         Figure 11 Example use of Signatures for Baseline Purchase








Burdett                      Informational                     [Page 81]

RFC 2801                       IOTP/1.0                       April 2000


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 attribute set to IOTP Signature Type must match the Trading Role
   of the Organisation which signed it. If it does not, then it is an
   error. Valid combinations are given in the table below.

         IOTP Signature Type    Valid Trading Role

         OfferResponse           Merchant

         PaymentResponse         PaymentHandler

         DeliveryResponse        DeliveryHandler

         AuthenticationRequest   any role

         AuthenticationResponse  any role

         PingRequest             any role

         PingResponse            any role

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

   Note that if symmetric cryptography is being used then a separate
   RecipientInfo and Value elements for each different set of shared
   secret keys are likely within the Signature Component.





Burdett                      Informational                     [Page 82]

RFC 2801                       IOTP/1.0                       April 2000


   Alternatively if asymmetric cryptography is being used then the
   RecpientRefs attribute of one RecipientInfo element may refer to
   multiple Organisation Components if they are all using the 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

   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.




Burdett                      Informational                     [Page 83]

RFC 2801                       IOTP/1.0                       April 2000


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:

      -  use the SignatureValueRef and the SignatureAlgorithmRef
         attributes to identify, respectively: the Value element that
         contains the signature to be checked and the Signature
         Algorithm element that describes the signature algorithm to be
         used to verify the Signature, then

      -  if the Signature Algorithm element indicates that asymmetric
         cryptography is being used then use the SignatureCertRef to
         identify the Certificate to be used by the signature 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.



Burdett                      Informational                     [Page 84]

RFC 2801                       IOTP/1.0                       April 2000


6.3 Checking a Payment or Delivery can occur

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

   In outline the steps are:

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

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

   o  check that the payment or delivery is authorised

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

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

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







Burdett                      Informational                     [Page 85]

RFC 2801                       IOTP/1.0                       April 2000


6.3.1 Check Request Block sent Correct Organisation

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

6.3.1.1 Payment

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





































Burdett                      Informational                     [Page 86]

RFC 2801                       IOTP/1.0                       April 2000


   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 12 Checking a Payment Handler can carry out a Payment

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

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

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






Burdett                      Informational                     [Page 87]

RFC 2801                       IOTP/1.0                       April 2000


      -  identifying the Brand List Component (see section 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.

      -  identifying the Brand Selection Component (see section 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.

   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:

      -  the Brand Element (see section 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.

      -  the Protocol Amount Element (see section 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

      -  the Pay Protocol Element (see section 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

      -  the Currency Amount Element (see section 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

   o  Check the consistency of the references in the Brand List and
      Brand Selection Components:

      -  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






Burdett                      Informational                     [Page 88]

RFC 2801                       IOTP/1.0                       April 2000


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

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

   o  Check that the Payment Handler that received the Payment Request
      Block is the Payment Handler selected by the Consumer. This
      involves:

      -  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

      -  checking the Organisation Component has a Trading Role Element
         with a Role attribute of PaymentHandler. If not there is an
         error

      -  finally, if the identified Organisation Component is not the
         same as the Organisation that received the Payment Request
         Block, then there is an error.






















Burdett                      Informational                     [Page 89]

RFC 2801                       IOTP/1.0                       April 2000


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

   The steps involved are as follows:

   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

   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

   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

   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.







Burdett                      Informational                     [Page 90]

RFC 2801                       IOTP/1.0                       April 2000


6.3.2 Check Correct Components present in Request Block

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

   If components are missing, there is an error.

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

   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

   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:

      -  the Merchant is known and a pre-existing agreement exists for
         the Action Organisation to be their agent for the payment or
         delivery

      -  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

      -  any constraints in their agreement with the Merchant are being
         followed, for example, whether or not an Offer Response
         signature is required

   o  Check the signatures are correct. If signatures are required then
      they need to be checked. This involves:





Burdett                      Informational                     [Page 91]

RFC 2801                       IOTP/1.0                       April 2000


      -  Identifying the correct signatures to check. This involves the
         Action Organisation identifying the Signature Components that
         contain references to the Action Organisation (see 6.3.1).
         Depending on the IOTP Transaction being carried out (see
         section 9) either one or two signatures may be identified

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






Burdett                      Informational                     [Page 92]

RFC 2801                       IOTP/1.0                       April 2000


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.














































Burdett                      Informational                     [Page 93]

RFC 2801                       IOTP/1.0                       April 2000


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

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

                          Figure 14 Trading Components




Burdett                      Informational                     [Page 94]

RFC 2801                       IOTP/1.0                       April 2000


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








Burdett                      Informational                     [Page 95]

RFC 2801                       IOTP/1.0                       April 2000


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



Burdett                      Informational                     [Page 96]

RFC 2801                       IOTP/1.0                       April 2000


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

7.2 Authentication Request Component

   This Trading Component contains parameter data that is used in an
   Authentication of one Trading Role by another. Its definition is as
   follows.

   <!ELEMENT AuthReq (Algorithm, PackagedContent*)>
   <!ATTLIST AuthReq
    ID                 ID      #REQUIRED
    AuthenticationId   CDATA   #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   If required the Algorithm may use the challenge data, contained in
   the 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 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



Burdett                      Informational                     [Page 97]

RFC 2801                       IOTP/1.0                       April 2000


                      the Authenticator to identify which Authentication
                      is being referred to.

   ContentSoftwareId  See section 14.Glossary

   Content:

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

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

                      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 request.  It uses the Algorithm contained in the
   Authentication Request Component (see section 7.2) selected from the
   Authentication Request Block (see section 8.4).

   Depending on the Algorithm selected, the results of applying the
   algorithm will either be contained in a Signature Component that
   signs both the Authentication Response and potentially other data, or
   in the Packaged Content 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.





Burdett                      Informational                     [Page 98]

RFC 2801                       IOTP/1.0                       April 2000


   AuthenticationId       The Authentication identifier specified by the
                          Authenticator that was included in the
                          Authentication Request Component(see section
                          7.2). This will enable the Authenticator to
                          identify the Authentication that is being
                          referred to.

   SelectedAlgorithmRef   An Element Reference that identifies the
                          Algorithm element used to generate the
                          Authentication Response.

   ContentSoftwareId      See section 14.Glossary.

   Content:

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

                      For example, for a payment specific scheme, it may
                      contain scheme-specific data. Refer to the scheme-
                      specific supplemental 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    NMTOKENS #REQUIRED >






Burdett                      Informational                     [Page 99]

RFC 2801                       IOTP/1.0                       April 2000


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



Burdett                      Informational                    [Page 100]

RFC 2801                       IOTP/1.0                       April 2000


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

   Content:

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

7.5.1 Order Description Content

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

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

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

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 7.9) associated with this order, and



Burdett                      Informational                    [Page 101]

RFC 2801                       IOTP/1.0                       April 2000


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

   Note: Disclaimer. The following information provided in this note
   does not represent formal advice of any of 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 goods or 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.

7.6 Organisation Component

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

   o to describe the merchant who is selling the goods,

   o to identify who made a purchase,

   o to identify who will take delivery of goods,

   o to provide a customer care contact,

   o to describe who will be the Payment Handler.





Burdett                      Informational                    [Page 102]

RFC 2801                       IOTP/1.0                       April 2000


   Note that the Organisation Components which must be present in an
   IOTP Message are dependent on the particular transaction being
   carried out.  Refer to section 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
    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.8 Identifying Languages.

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

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

   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



Burdett                      Informational                    [Page 103]

RFC 2801                       IOTP/1.0                       April 2000


                      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 10 Retrieving Logos.

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

   Content:

   TradingRole        See 7.6.2 Trading Role Element below.

   ContactInfo        See 7.6.3 Contact Information Element below.

   PersonName         See 7.6.4 Person Name below.

   PostalAddress      See 7.6.5 Postal Address below.

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



Burdett                      Informational                    [Page 104]

RFC 2801                       IOTP/1.0                       April 2000


   ConsumerOrgId      The Organisation ID for a Consumer consists of:
                       o a standard prefix 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 not 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] optionally followed by additional
                      characters, if required, to make the
                      NonConsumerOrgId unique.

                      Note that a NonConsumerOrgId may not start with
                      the ConsumerOrgIdPrefix.

                      Use of upper and lower case is not significant.

   Examples of Organisation Ids follow:

   o  newjerseybooks.com - a merchant Organisation id

   o  westernbank.co.uk - a Payment Handler Organisation id

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

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   #IMPLIED
    ErrorNetLocn       CDATA   #IMPLIED



Burdett                      Informational                    [Page 105]

RFC 2801                       IOTP/1.0                       April 2000


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






Burdett                      Informational                    [Page 106]

RFC 2801                       IOTP/1.0                       April 2000


                      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.

   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 7.21.1 Error Processing Guidelines for
                      more details.

                      This attribute:
                       o must not be present when TradingRole is set to
                         Consumer 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,



Burdett                      Informational                    [Page 107]

RFC 2801                       IOTP/1.0                       April 2000


                       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 7.21.1 Error Processing Guidelines for
                      more details.

7.6.3 Contact Information Element

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

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

   Attributes:

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




Burdett                      Informational                    [Page 108]

RFC 2801                       IOTP/1.0                       April 2000


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

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




Burdett                      Informational                    [Page 109]

RFC 2801                       IOTP/1.0                       April 2000


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

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





Burdett                      Informational                    [Page 110]

RFC 2801                       IOTP/1.0                       April 2000


7.7 Brand List Component

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

   o  payment Brands (see also section 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.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.





Burdett                      Informational                    [Page 111]

RFC 2801                       IOTP/1.0                       April 2000


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
















Burdett                      Informational                    [Page 112]

RFC 2801                       IOTP/1.0                       April 2000


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

                    Brand List Component

                      |                   ProtocolAmountRefs
                      |-Brand Element-----------------------------
                      |  |                                        |
                      |   - Protocol Brand Element--------        |
                      |                                   |       |
                      |                         ProtocolId|       |
                      |                                   |       |
                      |-Protocol Amount Element<----------+-------
                      |  |                      |         |
                      |  |                      |         |
                      |  |CurrencyAmountRefs    |Pay      |
                      |  |                      |Protocol |
                      |  v                      |Ref      |
                      |-Currency Amount Element |         |
                      | Element                 |         |
                      |                         |         |
                       -PayProtocolElement<------<--------

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

                   Figure 15 Brand List Element Relationships

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

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 (ProtocolBrand*, PackagedContent*) >
   <!ATTLIST Brand
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #IMPLIED
    BrandId            CDATA   #REQUIRED
    BrandName          CDATA   #REQUIRED
    BrandLogoNetLocn   CDATA   #REQUIRED
    BrandNarrative     CDATA   #IMPLIED
    ProtocolAmountRefs IDREFS  #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >




Burdett                      Informational                    [Page 113]

RFC 2801                       IOTP/1.0                       April 2000


   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.8
                       Identifying Languages.

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

                       Values of BrandId are managed under the procedure
                       described in section 12 IANA Considerations.

                       As values of BrandId are controlled under the
                       procedures defined in section 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 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.



Burdett                      Informational                    [Page 114]

RFC 2801                       IOTP/1.0                       April 2000


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

   ContentSoftwareId   See section 14.Glossary.

   Content:

   ProtocolBrand      Protocol Brand elements contain brand information
                      to be used with a specific payment protocol (see
                      section 7.7.2)


   PackagedContent    Optional Packaged Content (see section 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.

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

7.7.2 Protocol Brand Element

   The Protocol Brand Element contains information that is specific to
   the use of a particular Protocol with a Brand. Its definition is as
   follows.

   <!ELEMENT ProtocolBrand (PackagedContent*) >
   <!ATTLIST ProtocolBrand
    ProtocolId         CDATA   #REQUIRED
    ProtocolBrandId    CDATA   #REQUIRED >


   Attributes:

   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.






Burdett                      Informational                    [Page 115]

RFC 2801                       IOTP/1.0                       April 2000


   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.



Burdett                      Informational                    [Page 116]

RFC 2801                       IOTP/1.0                       April 2000


   PayProtocolRef      Contains an Element Reference (see section 3.5)
                       that refers to the Pay Protocol Element (see
                       section 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 7.7.4) that describes the
                       currencies and amounts that can be used with the
                       Brand.

   ContentSoftwareId   See section 14. Glossary.

   Content:

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

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

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

   Attributes:

   ID                 Element identifier, potentially referenced in a
                      Brand element; or in a Brand Selection Component



Burdett                      Informational                    [Page 117]

RFC 2801                       IOTP/1.0                       April 2000


                      contained in a later Payment Request message which
                      uniquely identifies the Currency Amount Element
                      within the IOTP Transaction.

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

   CurrCodeType       Indicates the domain of the CurrCode. This
                      attribute is included so that the currency code
                      may support non-standard "currencies" such as
                      frequent flyer points, trading stamps, etc. Its
                      values may be:
                       o ISO4217-A (the default) indicates the currency
                         code is a three character alphabetic currency
                         code that conforms to [ISO 4217]
                       o IOTP indicates that values of CurrCode are
                         managed under the procedure described in
                         section 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 12 IANA
                      Considerations user defined values of CurrCodeType
                      may be defined.

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

7.7.5 Pay Protocol Element

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

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



Burdett                      Informational                    [Page 118]

RFC 2801                       IOTP/1.0                       April 2000


    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.8
                      Identifying Languages.

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

                      The values of ProtocolId are defined by the
                      payment scheme/method owners in the document that
                      describes how to encapsulate a payment 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.





Burdett                      Informational                    [Page 119]

RFC 2801                       IOTP/1.0                       April 2000


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

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

   ContentSoftwareId  See section 14. Glossary.

   Content:

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

   Examples of Pay Protocol Elements are contained in section 11.2 Brand
   List 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 Exchange 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



Burdett                      Informational                    [Page 120]

RFC 2801                       IOTP/1.0                       April 2000


    ID                 ID      #REQUIRED
    BrandListRef       NMTOKEN #REQUIRED
    BrandRef           NMTOKEN #REQUIRED
    ProtocolAmountRef  NMTOKEN #REQUIRED
    CurrencyAmountRef  NMTOKEN #REQUIRED >

   Attributes:

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

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

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

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

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

   Content:

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

   The following rules apply:

   o  the BrandListRef must contain the ID of a Brand List Component in
      the same IOTP Transaction

   o  every Brand List Component in the Trading Protocol Options Block
      (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






Burdett                      Informational                    [Page 121]

RFC 2801                       IOTP/1.0                       April 2000


   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 11.2 Brand
   List Examples.

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

   Content:

   PackagedContent    Packaged Content elements (see section 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.

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






Burdett                      Informational                    [Page 122]

RFC 2801                       IOTP/1.0                       April 2000


   Attributes:

   ContentSoftwareId  See section 14. Glossary.

   Content:

   PackagedContent    Packaged Content elements (see section 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.

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

   Content:

   PackagedContent    Packaged Content elements (see section 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.

7.9 Payment Component

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

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

   o  a reference to the Brand List (see section 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



Burdett                      Informational                    [Page 123]

RFC 2801                       IOTP/1.0                       April 2000


   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
    StartAfterRefs     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 8.7) containing
                      the Payment Component.

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

   BrandListRef       An Element Reference (see section 3.5) of a Brand
                      List Component (see section 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 (see section 8.9) generated by the Payment
                      Handler for the payment must be digitally signed.

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







Burdett                      Informational                    [Page 124]

RFC 2801                       IOTP/1.0                       April 2000


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 #IMPLIED
    ConsumerPaymentId  CDATA   #IMPLIED
    PaymentHandlerPayId CDATA  #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >

   Attributes:

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

   PaymentRef           An Element Reference (see section 3.5) to the
                        Payment Component (see section 7.9) to which
                        this Payment Scheme Component relates. It is
                        required unless the Payment Scheme Component is
                        part of an Transaction Inquiry Status
                        Transaction (see section 9.2.1).

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







Burdett                      Informational                    [Page 125]

RFC 2801                       IOTP/1.0                       April 2000


   Content:

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

                      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 money has been paid or received. It is distinct from a purchase
   receipt in that it contains no record of what was being purchased.

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

   o  the amount paid and its currency

   o  the date and time of the payment

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

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

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

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

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





Burdett                      Informational                    [Page 126]

RFC 2801                       IOTP/1.0                       April 2000


   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

    The definition of a Payment Receipt Component is as follows.

   <!ELEMENT PayReceipt (PackagedContent*) >
   <!ATTLIST PayReceipt
    ID                 ID      #REQUIRED
    PaymentRef         NMTOKEN #REQUIRED
    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 7.9) to
                       which this payment receipt applies

   PayReceiptNameRefs  Optionally contains 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 Names of the Packaged Content elements
                          that must be listed in this attribute (if
                          any).
                        o if a Payment Scheme Component contains
                          Packaged Content elements with a name that
                          matches a name within PayReceiptNameRefs, 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.



Burdett                      Informational                    [Page 127]

RFC 2801                       IOTP/1.0                       April 2000


   ContentSoftwareId   See section 14. Glossary.

   Content:

   PackagedContent    Optionally contains payment scheme payment receipt
                      information as Packaged Content elements (see
                      section 3.7). See the payment scheme supplement
                      for the definition of its content.

                      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

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

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 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", HTML and 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  See section 14. Glossary.



Burdett                      Informational                    [Page 128]

RFC 2801                       IOTP/1.0                       April 2000


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

7.13 Delivery Component

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

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

   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.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 8.11) and the Payment Response Block (see
                       section 8.9 ) are combined into one IOTP Message.
                       Valid values are:
                        o True indicates both blocks will be in the
                          same IOTP Message, and




Burdett                      Informational                    [Page 129]

RFC 2801                       IOTP/1.0                       April 2000


                        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.

   Content:

   DeliveryData       Contains details about how the delivery will be
                      carried out. See 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.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 >





Burdett                      Informational                    [Page 130]

RFC 2801                       IOTP/1.0                       April 2000


   Attributes:

   xml:lang            Defines the language used by attributes within
                       this component. See section 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 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 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
                       8.10) which contains the Delivery Component
                       should be sent.



Burdett                      Informational                    [Page 131]

RFC 2801                       IOTP/1.0                       April 2000


                       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 8.10) which
                       contains the Delivery Component should be sent.

                       A secured delivery request involves the use of a
                       secure channel such as [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.9 Secure and Insecure Net
                       Locations.

   ContentSoftwareId   See section 14. Glossary.

   Content:

   PackagedContent    Additional information about the delivery as one
                      or more Packaged Content elements (see section
                      3.7) provided to the Delivery Handler by the
                      merchant.

7.14 Consumer Delivery Data Component

   A Consumer Delivery Data Component is used by a Consumer to specify
   an identifier that can be used by the Consumer to identify the
   Delivery.

   Its definition is as follows:

   <!ELEMENT ConsumerDeliveryData EMPTY >
   <!ATTLIST ConsumerDeliveryData
    ID                 ID      #REQUIRED
    ConsumerDeliveryId CDATA   #REQUIRED>

   Attributes:

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






Burdett                      Informational                    [Page 132]

RFC 2801                       IOTP/1.0                       April 2000


   ConsumerDeliveryId  An identifier specified by the Consumer which, if
                       returned by the Delivery Handler will enable the
                       Consumer to identify which Delivery is being
                       referred to.

7.15 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, HTML and XML.

   It's definition is as follows.

   <!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.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    See section 14. Glossary.




Burdett                      Informational                    [Page 133]

RFC 2801                       IOTP/1.0                       April 2000


   Content:

   PackagedContent    Contains actual delivery note information as one
                      or more Packaged Content elements (see section
                      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.

7.16 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 #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.8 Identifying
                      Languages.

   StatusType         Indicates the type of Document Exchange which the
                      Status is reporting on. It may be set to either
                      Offer, Payment, Delivery, Authentication or
                      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.




Burdett                      Informational                    [Page 134]

RFC 2801                       IOTP/1.0                       April 2000


                      Values of StatusType are managed under the
                      procedure described in section 12 IANA
                      Considerations which also allows user defined
                      values of StatusType to be defined.

   ElRef              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 an Order Component (see section 7.5), if the
                         StatusType is Offer,
                       o a Payment Component (see section 7.9), if the
                         StatusType is Payment, or
                       o a Delivery Component (see section 7.13), if
                         the StatusType is Delivery
                       o an Authentication Request Component (see
                         section 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 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.







Burdett                      Informational                    [Page 135]

RFC 2801                       IOTP/1.0                       April 2000


   CompletionCode     Indicates how the process completed. Valid values
                      for the CompletionCode are given below together
                      with the conditions when it must be 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 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 inside an Inquiry
                      Response Block (see section 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.





Burdett                      Informational                    [Page 136]

RFC 2801                       IOTP/1.0                       April 2000


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

                    Recovery may be possible by the Consumer re-
                    submitting a new Authentication Response Block with
                    corrected information.

   ConsCancelled    Consumer Cancelled. The Consumer decides to cancel
                    the transaction for some reason. This code is only
                    valid in a Status Component contained in a Cancel
                    Block 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.

                    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.





Burdett                      Informational                    [Page 137]

RFC 2801                       IOTP/1.0                       April 2000


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





Burdett                      Informational                    [Page 138]

RFC 2801                       IOTP/1.0                       April 2000


   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.

                      See below for recovery options.

   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.





Burdett                      Informational                    [Page 139]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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



Burdett                      Informational                    [Page 140]

RFC 2801                       IOTP/1.0                       April 2000


                   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.

                   Recovery is not possible.

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

                   Recovery is not possible.

   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.




Burdett                      Informational                    [Page 141]

RFC 2801                       IOTP/1.0                       April 2000


                   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.

7.16.4 Authentication Completion Codes

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

        Value                           Description

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

                   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.

                   Recovery is not possible.




Burdett                      Informational                    [Page 142]

RFC 2801                       IOTP/1.0                       April 2000


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

                   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.





Burdett                      Informational                    [Page 143]

RFC 2801                       IOTP/1.0                       April 2000


   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.16.5 Undefined Completion Codes

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

        Value                           Description

   InMsgHardError  Input Message Hard Error. 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.16.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
   StatusDesc attribute is used to provide further explanation where
   appropriate.

        Value                           Description

   UnAuthReq       Unauthorised Request. The recipient of the
                   Transaction Status Request declines to respond to the
                   request.

7.17 Trading Role Data Component

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

   Trading Role Components identify:

   o the Organisation that generated the component, and

   o the Organisation that is to receive it.



Burdett                      Informational                    [Page 144]

RFC 2801                       IOTP/1.0                       April 2000


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

   Its definition is as follows.

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

7.17.1 Who Receives a Trading Role Data Component

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





Burdett                      Informational                    [Page 145]

RFC 2801                       IOTP/1.0                       April 2000


   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)

7.18 Inquiry Type Component

   The Inquiry Type Component contains the information which indicates
   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



Burdett                      Informational                    [Page 146]

RFC 2801                       IOTP/1.0                       April 2000


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

7.19 Signature Component

   Note: Definitions of the XML structures for signatures and
   certificates are described in the document titled "Digital Signatures
   for the Internet Open Trading Protocol" by Kent Davidson and Yoshiaki
   Kawatsura published at the same time as this document - see
   [IOTPDSIG].

   In the future it is anticipated that future versions of IOTP will
   adopt a whatever method for digitally signing XML becomes the
   standard.

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

   The Signature Component:

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

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

   o  signs the Manifest element using the optional certificate
      identified in the Certificate element within the Signature Block
      placing the result in a Value element within a Signature Component

   Note that there may be multiple Value elements that contain
   signatures of a Manifest Element.

   A Signature Component can be one of four types either:

   o an Offer Response Signature,

   o a Payment Response Signature,



Burdett                      Informational                    [Page 147]

RFC 2801                       IOTP/1.0                       April 2000


   o a Delivery Response Signature, or

   o an Authentication Response Signature.

   For a general explanation of signatures see section 6 Digital
   Signatures.

7.19.1 IOTP usage of signature elements and attributes

   Definitions of the elements and attributes are contained in
   [IOTPDSIG].  The following contains additional information that
   describes how these elements and attributes are used by IOTP.

   SIGNATURE ELEMENT

   The ID attribute is mandatory.

   MANIFEST ELEMENT

   The optional LocatorHrefBase attribute contains text which should be
   concatenated before the text contained in the LocatorHREF attribute
   of all Digest elements within the Manifest.

   Its purpose is to reduce the size of LocatorHREF attribute values
   since the first part of the LocatorHREF attributes in the same
   signature are likely to be the same.

   Typically, within IOTP, it will contain all the characters in a
   LocatorHref attribute up to the sharp ("#") character (see
   immediately below).

   ALGORITHM AND PARAMETER ELEMENTS

   The algorithm element identifies the algorithms used in generating
   the signature. The type of the algorithm is defined by the value of
   the Type attribute which indicates if it is to be used as a Digest
   algorithm, a Signature algorithm or a Key Agreement algorithm.

   The following Digest algorithms must be implemented:

   o  a [DOM-HASH] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:ibm:dom-hash"

   o  a [SHA1] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:fips:sha1", and

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



Burdett                      Informational                    [Page 148]

RFC 2801                       IOTP/1.0                       April 2000


   o  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 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 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 Manifest element (see immediately above).





Burdett                      Informational                    [Page 149]

RFC 2801                       IOTP/1.0                       April 2000


   ATTRIBUTE ELEMENT

   There must be one and only one Attribute Element that contains a Type
   attribute with a value of IOTP Signature Type 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 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 section 3.5), that point to the Organisations that might need to
   validate the signature. For details see below.

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





Burdett                      Informational                    [Page 150]

RFC 2801                       IOTP/1.0                       April 2000


   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 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 6.3.1 Check Request Block sent 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.

7.19.3 Payment Receipt Signature Component

   The Manifest Element of the Payment Receipt Signature Component
   should contain Digest Elements for the following Components:

   o  the Transaction Id Component (see section 3.3.1) of the IOTP
      message that contains the Payment Receipt Signature

   o  the Transaction Reference Block (see section 3.3) of the IOTP
      Message that contains the Payment Receipt Signature

   o  the Offer Response Signature Component

   o  the Payment Receipt Component

   o  the Payment Note Component

   o  the Status Component



Burdett                      Informational                    [Page 151]

RFC 2801                       IOTP/1.0                       April 2000


   o  the Brand Selection Component.

   o  any Trading Role Data Components

7.19.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 Consumer Delivery Data component contained in the preceding
      Delivery Request (if any)

   o  the Signature Components contained in the preceding Delivery
      Request (if any)

   o  the Status Component

   o  the Delivery Note Component

7.19.5 Authentication Request Signature Component

   The Manifest Element of the Authentication Request Signature
   Component should contain Digest Elements for the following
   Components:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the TPO Block :

      -  the Protocol Options Component

      -  the Organisation Component

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component(s) (if present)




Burdett                      Informational                    [Page 152]

RFC 2801                       IOTP/1.0                       April 2000


      -  the Trading Role Information Request Component (if present)

7.19.6 Authentication Response Signature Component

   The Manifest Element of the Authentication Response Signature
   Component should contain Digest Elements for the following
   Components:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the Authentication Request Block:

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

7.19.7 Inquiry Request Signature Component

   If the Inquiry Request is being signed (see section 9.2.1) the
   Manifest Element of the Inquiry Request Signature Component should
   contain Digest elements of the Inquiry Type Component, and if
   present, the Payment Scheme Component.

7.19.8 Inquiry Response Signature Component

   If the Inquiry Response is being signed (see section 9.2.1) the
   Manifest Element of the Inquiry Response Signature Component should
   contain Digest elements of the Trading Response Block and the Status
   Component.

7.19.9 Ping Request Signature Component

   If the Ping Request is being singed (see section 9.2.2), the Manifest
   Element of the Ping Request Signature Component should contain Digest
   elements for all the Organisation Components.







Burdett                      Informational                    [Page 153]

RFC 2801                       IOTP/1.0                       April 2000


7.19.10 Ping Response Signature Component

   If the Ping Response is being singed (see section 9.2.2), the
   Manifest Element of the Ping Response Signature Component should
   contain Digest elements fir all the Organisation Components.

7.20 Certificate Component

   Note: Definitions of the XML structures for signatures and
   certificates are described in the paper "Digital Signatures for the
   Internet Open Trading Protocol", see [IOTPDSIG].

   See note at the start of section 7.19 Signature Component for more
   details.

   A Certificate Component contains a Digital Certificate. They are used
   only when required, for example, when asymmetric cryptography is
   being 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 defined in [IOTPDSIG].

7.20.1 IOTP usage of signature elements and attributes

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

   CERTIFICATE COMPONENT

   The ID attribute is mandatory.

   VALUE ELEMENT

   The ID attribute is mandatory.

7.21 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



Burdett                      Informational                    [Page 154]

RFC 2801                       IOTP/1.0                       April 2000


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





Burdett                      Informational                    [Page 155]

RFC 2801                       IOTP/1.0                       April 2000


                       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 7.21.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 7.21.2 Error Codes) and at the
                      discretion of the vendor/developer of the IOTP
                      Aware Application. For a definition of
                      PackagedContent see section 3.7.






Burdett                      Informational                    [Page 156]

RFC 2801                       IOTP/1.0                       April 2000


7.21.1 Error Processing Guidelines

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

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

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





Burdett                      Informational                    [Page 157]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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

7.21.2 Error Codes

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

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







Burdett                      Informational                    [Page 158]

RFC 2801                       IOTP/1.0                       April 2000


        Value                           Description

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

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

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






Burdett                      Informational                    [Page 159]

RFC 2801                       IOTP/1.0                       April 2000


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

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

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

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

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

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

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

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

   AttValIllegal   Attribute value illegal. The attribute contains a
                   value which does not conform to the rules and
                   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.




Burdett                      Informational                    [Page 160]

RFC 2801                       IOTP/1.0                       April 2000


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

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

   ValueTooSmall   Value too small or early. The value of all or part of
                   the 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 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
                   specified in the IOTP supplement for the Transport
                   mechanism.

   MsgBeingProc    Message Being Processed. This error code is only used
                   with a Severity of Transient Error. It indicates that
                   the previous message, which may be an exchange
                   message or a request message, is being processed and,
                   if no response is received by the time indicated by
                   the MinRetrySecs attribute, then the original message
                   should be resent.

   SystemBusy      System Busy. This error code is only used with a
                   Severity of Transient Error. It indicates that the
                   server that received a message is currently too busy
                   to handle the message. If no response is received by



Burdett                      Informational                    [Page 161]

RFC 2801                       IOTP/1.0                       April 2000


                   the time indicated by the MinRetrySecs attribute,
                   then the original message should be resent.

   Note: If the server/system handling the Transport Mechanism (e.g.,
   HTTP) is busy then a Transport Specific error message should be used
   instead of an IOTP Error message. This code should be used in
   association with IOTP servers/systems or other servers/systems to
   which the IOTP server is connected.

   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.

7.21.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
    IotpMsgRef         NMTOKEN #IMPLIED
    BlkRef             NMTOKEN #IMPLIED
    CompRef            NMTOKEN #IMPLIED
    ElementRef         NMTOKEN #IMPLIED
    AttName            NMTOKEN #IMPLIED >

   Attributes:

   ElementType        This is the name of the type of the element where
                      the error is located. For example if the element
                      was declared as <!ELEMENT Org ... then its name is
                      "Org".

   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.





Burdett                      Informational                    [Page 162]

RFC 2801                       IOTP/1.0                       April 2000


   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.

8. Trading Blocks

   Trading Blocks are child elements of the top level IOTP Messages that
   are sent in the form of [XML] documents directly between the
   different 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.

















Burdett                      Informational                    [Page 163]

RFC 2801                       IOTP/1.0                       April 2000


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

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

                            Figure 16 Trading Blocks




Burdett                      Informational                    [Page 164]

RFC 2801                       IOTP/1.0                       April 2000


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

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




Burdett                      Informational                    [Page 165]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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
                      7.1)defines the options which apply to the whole
                      IOTP Transaction (see section 9).

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

   Org                The Organisation Components (see section 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 9.
                      Internet Open Trading Protocol Transactions.



Burdett                      Informational                    [Page 166]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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 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 7.8) for each payment to be
                      made in the IOTP Transaction.



Burdett                      Informational                    [Page 167]

RFC 2801                       IOTP/1.0                       April 2000


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

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

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

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

   The Offer Response Block should contain:




Burdett                      Informational                    [Page 168]

RFC 2801                       IOTP/1.0                       April 2000


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

8.4 Authentication Request Block

   The Authentication Request Block contains the data which is used by
   one Trading Role to obtain information about and optionally
   authenticate another Trading Role.

   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:

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

   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.







Burdett                      Informational                    [Page 169]

RFC 2801                       IOTP/1.0                       April 2000


                       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 Request Component is present
                       it means that the Authentication Request Block is
                       requesting the return of Organisation Components
                       as specified in the Trading Role Information
                       Request Component.

   TradingRoleInfoReq  The Trading Role Information Request Component
                       (see section 7.4) contains a list of Trading
                       Roles about which information is being requested

   There must be at least one Component (either an Authentication
   Request or a Trading Role Information Request) within the
   Authentication Block 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 follows.

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

   Attributes:

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

   Content:

   AuthResp           The optional Authentication Response Component
                      which contains the results of processing the
                      Authentication Request Component - see section
                      7.3.

   Org                Optional Organisation Components that contain
                      information corresponding to the Trading Roles as
                      requested by the TradingRoleList attribute of the
                      Trading Role Information Request component.





Burdett                      Informational                    [Page 170]

RFC 2801                       IOTP/1.0                       April 2000


   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

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 7.13)
                      of the responses of the steps (e.g., an Offer
                      Response and/or a Payment Response) on which this





Burdett                      Informational                    [Page 171]

RFC 2801                       IOTP/1.0                       April 2000


                      step depends. It is used to indicate the success
                      or failure of those steps. Payment should only
                      occur 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 7.7).

   BrandSelection     This identifies the choice of payment brand, the
                      payment protocol and the Payment Handler to be
                      used in a payment within the IOTP Transaction.
                      There is one Brand Selection Component (see
                      section 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 7.9.

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

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

   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





Burdett                      Informational                    [Page 172]

RFC 2801                       IOTP/1.0                       April 2000


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

8.8 Payment Exchange Block

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

   <!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 7.10 Payment Scheme
                      Component.

8.9 Payment Response Block

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







Burdett                      Informational                    [Page 173]

RFC 2801                       IOTP/1.0                       April 2000


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

   Attributes:

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

   Content:

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

   PayReceipt         Contains payment scheme specific data which can be
                      used to verify the payment occurred. See section
                      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 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 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 IOTP Transaction (see
                      section 7.17).








Burdett                      Informational                    [Page 174]

RFC 2801                       IOTP/1.0                       April 2000


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,
        ConsumerDeliveryData?, 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
                         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 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 7.5.

                         The Organisation Components (see section 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
                         9. Internet Open Trading Protocol Transactions.

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

   ConsumerDeliveryData  Optional. Contains an identifier specified by
                         the Consumer which, if returned by the Delivery
                         Handler will enable the Consumer to identify
                         which Delivery is being referred to.






Burdett                      Informational                    [Page 175]

RFC 2801                       IOTP/1.0                       April 2000


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

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





Burdett                      Informational                    [Page 176]

RFC 2801                       IOTP/1.0                       April 2000


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

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

   PaySchemeData      Payment Scheme Component (see section 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.

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.








Burdett                      Informational                    [Page 177]

RFC 2801                       IOTP/1.0                       April 2000


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

   Attributes:

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

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

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









Burdett                      Informational                    [Page 178]

RFC 2801                       IOTP/1.0                       April 2000


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

8.15 Ping Response Block

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

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



Burdett                      Informational                    [Page 179]

RFC 2801                       IOTP/1.0                       April 2000


   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




Burdett                      Informational                    [Page 180]

RFC 2801                       IOTP/1.0                       April 2000


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

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 IOTP uses signatures, see section 6 Digital Signatures. The
   definition of the Signature Component and certificates is contained
   in the paper "Digital Signatures for the Internet Open Trading
   Protocol", see [IOTPDSIG].  Descriptions of how these are used by
   IOTP is contained in sections 7.19 and 7.20.

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

   Certificate        A Certificate Component. See section 7.20.






Burdett                      Informational                    [Page 181]

RFC 2801                       IOTP/1.0                       April 2000


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

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 7.19.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 7.19.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 7.19.3) generated
      by the previous step

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 7.19.3) generated by the step.

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 7.19.2), and

   o  the Payment Receipt Signature Component (see section 7.19.3)
      generated by the previous step.

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.19.4) generated by the step.









Burdett                      Informational                    [Page 182]

RFC 2801                       IOTP/1.0                       April 2000


8.17 Error Block

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

   For clarity two phrases are defined which are used in the description
   of an Error Trading Block:

   o  message in error. An IOTP message which contains or causes an
      error of some kind

   o  message reporting the error. An IOTP message that contains an
      Error Trading Block that describes the error found in a message in
      error.

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

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

   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 7.21) that
                      contains information about an individual Technical
                      Error.

   PaySchemeData      An optional Payment Scheme Component (see section
                      7.10) which contains a Payment Scheme Message. See
                      the appropriate payment scheme supplement to




Burdett                      Informational                    [Page 183]

RFC 2801                       IOTP/1.0                       April 2000


                      determine whether or not this component needs to
                      be present and for the definition of what it must
                      contain.

8.18 Cancel Block

   The Cancel Block is used by one Trading Role to inform any other that
   a transaction has been 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

   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.

9. Internet Open Trading Protocol Transactions

   The Baseline Internet Open Trading Protocol supports 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








Burdett                      Informational                    [Page 184]

RFC 2801                       IOTP/1.0                       April 2000


   o  IOTP Transactions that involve one or more payments. Specifically:

      -  Deposit

      -  Purchase

      -  Refund

      -  Withdrawal, and

      -  Value Exchange

   o  IOTP Transactions designed to check the correct function of the
      IOTP infrastructure. Specifically:

      -  Transaction Status Inquiry, and

      -  Ping

   Although the Authentication IOTP Transaction can operate on its own,
   authentication can optionally precede any of the "payment"
   transactions.  Therefore, the rest of this section is divided into
   two parts covering:

   o  Authentication and Payment transactions (Authentication, Deposit,
      Purchase, Refund, Withdrawal and Value Exchange)

   o  Infrastructure Transactions (Transaction Status Inquiry and Ping)
      that are designed to support inquiries on whether or not a
      transaction has succeeded or a Trading Role's servers are
      operating correctly, and

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 simultaneously in order to minimise the number of actual
      IOTP Messages which must be sent over the Internet.

      The six Document Exchanges are:

   o  Authentication. This is a direct implementation of the
      Authentication Trading Exchange



Burdett                      Informational                    [Page 185]

RFC 2801                       IOTP/1.0                       April 2000


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






























Burdett                      Informational                    [Page 186]

RFC 2801                       IOTP/1.0                       April 2000


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

     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 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
      Exchanges to effect the desired result.



Burdett                      Informational                    [Page 187]

RFC 2801                       IOTP/1.0                       April 2000


   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.

9.1.1 Authentication Document Exchange

   The Authentication Document Exchange is a direct implementation of
   the Authentication Trading Exchange (see section 2.2.4). It involves:

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

   o  an Authenticatee - the Organisation being authenticated.

   The authentication consists of:

   o  an Authentication Request being sent by the Authenticator to the
      Authenticatee,

   o  an Authentication Response being sent in return by the
      Authenticatee to the Authenticator which is then checked, and

   o  an Authentication Status being sent by the Authenticator to the
      Authenticatee to provide an indication of the success or failure
      of the authentication.

   An Authentication Document Exchange also:

   o  provides an Authenticatee with an Organisation Component which
      describes the Authenticator, and

   o  optionally provides the Authenticator with Organisation Components
      which describe the Authenticatee.

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

   The IOTP Messages which are involved are illustrated by the diagram
   below.









Burdett                      Informational                    [Page 188]

RFC 2801                       IOTP/1.0                       April 2000


 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1
 (Authenticatee)
     |   Organisation 2
     |  (Authenticator)
STEP |     |
 1.          First Organisation takes an action (for example by
             pressing a button on an HTML page) which requires that
             the Organisation is authenticated

     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

     1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
             Signature Block (optional); TPO Block; Auth Request Block

 3.          IOTP aware application started. If a Signature Block is
             present, the first Organisation may use this to check the
             credentials of the second Organisation. If credentials are
             OK, the first Organisation selects an Authentication
             Request to use (if present and more than one), then uses
             the authentication algorithm selected to generate an
             Authentication Response Block. If present, the Trading
             Role Information Request Component is used to generate
             Organisation Components. Finally a Signature Component is
             created if required and all components are then sent back
             to the second Organisation for validation.

     1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
             Signature Block (optional) ; Auth Response Block

 4.          The second Organisation checks the Authentication
             Response against the data in the Authentication Request
             Block to check that the first Organisation is who they
             appear to be, and sends an Authentication Status Block to
             the first Organisation to indicate the result then
             stops.

     1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
             Signature Block (optional); Auth Response Block






Burdett                      Informational                    [Page 189]

RFC 2801                       IOTP/1.0                       April 2000


 5.          The first Organisation checks the authentication Status
             Block and optionally keeps information on the IOTP
             transaction for record keeping purposes and stops.

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

                 Figure 18 Authentication Document Exchange

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 7.16.4)
      set to either: AutEeCancel, 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








Burdett                      Informational                    [Page 190]

RFC 2801                       IOTP/1.0                       April 2000


      -  indicate a failure to continue with the rest of the IOTP
         Transaction, by sending back to the Authenticator a Cancel
         Block containing a Status Component with a StatusType of
         Authentication, a ProcessState of Failed and the CompletionCode
         (see section 7.16.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 from a Consumer, then the Authenticatee may go to the
   CancelNetLocn specified on the Trading Role Element in the
   Organisation Component for the Authenticator contained in the Trading
   Protocol Options Block.

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

   o an Authentication Request Block (see section 8.4), and

   o an optional Signature Block (see section 8.16).

   Each of these are described below.

   TRADING PROTOCOL OPTIONS BLOCK

   The Trading Protocol Options Block (see section 8.1) must contain the
   following Trading Components:

   o  one Protocol Options Component (see Section 7.1) which defines the
      options which apply to the whole Authentication Document Exchange.

   o  one Organisation Component (see section 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 8.4) must contain the
   following Trading Components:

   o  one Authentication Request Component (see section 7.2), and




Burdett                      Informational                    [Page 191]

RFC 2801                       IOTP/1.0                       April 2000


   SIGNATURE BLOCK (AUTHENTICATION REQUEST)

   If the Authentication Request is being digitally signed then a
   Signature Block must be included. It contains Digests of the
   following XML elements:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the TPO Block :

      -  the Protocol Options Component

      -  the Organisation Component

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component

      -  the Trading Role Information Request Component

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 8.5), and

   o  an optional Signature Block (see section 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 7.3)

   o  one Organisation Component for every Trading Role identified in
      the TradingRoleList attribute of the Trading Role Information
      Request Component contained in the Authentication Request Block.





Burdett                      Informational                    [Page 192]

RFC 2801                       IOTP/1.0                       April 2000


   SIGNATURE BLOCK (AUTHENTICATION RESPONSE)

   If the Algorithm element (see section 12. IANA Considerations) within
   the Authentication 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 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 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.

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 8.5), and

   o  an optional Signature Block (see section 8.16).

   Each of these are described below.

   AUTHENTICATION STATUS BLOCK

   The Authentication Status Block (see section 8.6) must contain the
   following Trading Components:

   o  one Status Component (see section 7.16) with a ProcessState
      attribute set to CompletedOk.



Burdett                      Informational                    [Page 193]

RFC 2801                       IOTP/1.0                       April 2000


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

   Note: If the Authentication Document Exchange is followed by an Offer
   Document Exchange (see section 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 9.1.2.3), or

   o a TPO and Offer Response IOTP Message (see section 9.1.2.6)

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





Burdett                      Informational                    [Page 194]

RFC 2801                       IOTP/1.0                       April 2000


   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.









































Burdett                      Informational                    [Page 195]

RFC 2801                       IOTP/1.0                       April 2000


 This is illustrated by the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to 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, places then in a Brand List
             Component inside a TPO Block and sends to Consumer

     C <-- M TPO. IotpMsg: Trans Ref Block; TPO 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 and
             sends back to Merchant.

     C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
             Block

 4.          Merchant uses selected payment brand, payment protocol,
             currency/amount and the offer information to create an
             Offer Response Block containing details about the IOTP
             Transaction including price, etc. Optionally signs it and
             sends to the Consumer

     C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
             (optional); Offer Response Block

 5.          Consumer checks the Offer is OK, then combines components
             from the TPO Block, the TPO Selection Block and the 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

     CONTINUED ...

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

              Figure 19 Brand Dependent Offer Document Exchange





Burdett                      Informational                    [Page 196]

RFC 2801                       IOTP/1.0                       April 2000


   Note, a Consumer identifies a Brand Dependent Offer Document
   Exchange, by the absence of an Offer Response Block in the first IOTP
   Message.

   MESSAGE PROCESSING GUIDELINES

   On receiving a TPO IOTP Message (see below), the Consumer may either:

   o  generate and send a TPO Selection IOTP Message back to the
      Merchant, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Merchant containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: ConsCancelled
      or Unspecified.

   On receiving a TPO Selection IOTP Message (see below) the Merchant
   may either:

   o  generate and send an Offer Response IOTP Message back to the
      Consumer, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Consumer containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.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 Merchant containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.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.





Burdett                      Informational                    [Page 197]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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
     |  Merchant
STEP |     |
 1.          Consumer decides to 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, places then in a Brand List
             Component inside a TPO Block, creates an Offer Response
             containing details about the IOTP Transaction including
             price, etc., optionally signs it  and sends to Consumer

     C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block; TPO Block; 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 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.

     CONTINUED ...

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

                 Figure 20 Brand Independent Offer Exchange





Burdett                      Informational                    [Page 198]

RFC 2801                       IOTP/1.0                       April 2000


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

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 Block (see section 8.1) which is described below.







Burdett                      Informational                    [Page 199]

RFC 2801                       IOTP/1.0                       April 2000


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

   o  one Brand List Component (see section 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 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 8.6), and

   o  an optional Signature Block (Authentication Status) Signature
      Block

   See section 9.1.1.4 Authentication Status IOTP Message for more
   details.






Burdett                      Informational                    [Page 200]

RFC 2801                       IOTP/1.0                       April 2000


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 section 3.3), this message consists of just a TPO Selection
   Block (see section 8.1) which is described below.

   TPO SELECTION BLOCK

   The TPO Selection Block (see section 8.2) contains:

   o  one Brand Selection Component (see section 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.

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 section 3.3), this message consists of:

   o  an Offer Response Block (see section 8.1) and

   o  an optional Signature Block (see section 8.16).

   OFFER RESPONSE BLOCK

   The Offer Response Block (see section 8.3) contains the following
   components:

   o  one Status Component (see section 7.16) which indicates the status
      of the Offer Response. The ProcessState attribute should be set to
      CompletedOk

   o  one Order Component (see section 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 7.9) for each
      payment which is to be made

   o  zero or one Delivery Components (see section 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 7.17) if
      required by the Merchant.



Burdett                      Informational                    [Page 201]

RFC 2801                       IOTP/1.0                       April 2000


   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 7.19) with Digest Elements for the following XML
   elements:

   If the Offer Response is being digitally signed then a Signature
   Block must be included that contains a Signature Component (see
   section 7.19) 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

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

   o  an Offer Response Block (see section 8.1) and

   o  an optional Signature Block (see section 8.16).




Burdett                      Informational                    [Page 202]

RFC 2801                       IOTP/1.0                       April 2000


   TPO (TRADING PROTOCOL OPTIONS) BLOCK

   This is the same as the Trading Protocol Options Block described in
   TPO IOTP Message (see section 9.1.2.3).

   OFFER RESPONSE BLOCK

   This the same as the Offer Response Block in the Offer Response IOTP
   Message (see section 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 8.6).

   SIGNATURE BLOCK

   This is the same as the Signature Block in the Offer Response IOTP
   Message (see section 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.

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





Burdett                      Informational                    [Page 203]

RFC 2801                       IOTP/1.0                       April 2000


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

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
             Block (optional); Pay Request Block

 2.          Payment Handler processes Pay Request Block, checks
             optional signature and starts exchanging payment protocol
             messages encapsulated in a Pay Exchange Block, with the
             Consumer

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange 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 a Signature Block, sends them
             to the Consumer and stops.

     C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block (optional); Pay Response Block

 4.          Consumer checks Payment Response is OK. Optionally keeps
             information on IOTP Transaction for record keeping
             purposes and either stops 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 21 Payment Document Exchange





Burdett                      Informational                    [Page 204]

RFC 2801                       IOTP/1.0                       April 2000


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 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 7.16.4) set to either: BrandNotSupp,
      CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds,
      InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.

   On receiving a Payment Exchange IOTP Message, the Consumer may
   either:

   o  generate and send a Payment Exchange Message back to the Payment
      Handler or

   o  indicate failure to continue with the Payment by sending a Cancel
      Block back to the Payment Handler containing a Status Component
      with a StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.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 7.16.2) set to either: PaymtCancelled
      or Unspecified.




Burdett                      Informational                    [Page 205]

RFC 2801                       IOTP/1.0                       April 2000


   On receiving a Payment Response IOTP Message, the Consumer may
      either:

   o  generate and send the next IOTP Message in the IOTP transaction
      and send it to the required Trading Role. This is dependent on the
      IOTP Transaction,

   o  stop, since the IOTP Transaction has ended, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Merchant containing a Status Component
      with a StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.1) set to either: ConsCancelled
      or Unspecified.

   If the Consumer receives an IOTP Message containing a Cancel block,
   then the information contained in the IOTP Message should be reported
   to the Consumer but no further action taken.

   If the Payment Handler receives an IOTP Message containing a Cancel
   block, then the Consumer is likely to go to the CancelNetLocn
   specified on the Trading Role Element in the Organisation Component
   for the Payment Handler from which any further action may take place.

   If the Merchant receives an IOTP Message containing a Cancel block,
   then the Consumer should have completed the payment but not
   continuing with the transaction for some reason. In this case the
   Consumer is likely to go to the CancelNetLocn specified on the
   Trading Role Element in the Organisation Component for the Merchant
   from which any further action may take place.

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 8.7) contains:

   o  the following components copied from the Offer Response Block from
      the preceding Offer Document Exchange:

      -  the Status Component



Burdett                      Informational                    [Page 206]

RFC 2801                       IOTP/1.0                       April 2000


      -  the Payment Component for the payment which is being carried
         out

   o  the following components from the TPO Block:

      -  the Organisation Components with the roles of Merchant and for
         the PaymentHandler that is being sent the Payment Request 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
         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 9.1.2.2)

   o  an optional Payment Scheme Component (see section 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 7.17).

   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
      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 7.8) for the payment. Also see
      section 6.3.1 Check Request Block sent 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





Burdett                      Informational                    [Page 207]

RFC 2801                       IOTP/1.0                       April 2000


   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 9.1.2.5 Offer Response IOTP Message),
   or a preceding Payment Exchange included a Payment Response Signature

   (see section 9.1.3.4 Payment Response IOTP Message) then they should
   both be copied to the Signature Block in the Payment Request IOTP
   Message.

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 8.8) contains:

   o  one Payment Scheme Component (see section 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.

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 8.9) contains:

   o  one Payment Receipt Component (see section 7.11) which contains
      scheme specific data which can be used to verify the payment
      occurred






Burdett                      Informational                    [Page 208]

RFC 2801                       IOTP/1.0                       April 2000


   o  one Payment Scheme Component (see section 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 7.12)

   o  zero or more Trading Role Data Components (see section 7.17).

   SIGNATURE BLOCK (PAYMENT RESPONSE)

   If a signed Payment Receipt is being provided, indicated by the
   SignedPayReceipt attribute of the Payment Component being set to
   True, then the Signature Block should contain a Signature Component
   which contains Digest Elements for the following:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message which contains the first usage of the Payment Response
      Block,

   o  the Transaction Id Component (see section 3.3.1) within the
      Transaction Reference Block that globally uniquely identifies the
      IOTP Transaction,

   o  the Payment Receipt Component from the Payment Response Block,

   o  the Payment Note Component from the Payment Response Block,

   o  the other Components referenced by the PayReceiptNameRefs
      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.

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




Burdett                      Informational                    [Page 209]

RFC 2801                       IOTP/1.0                       April 2000


   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
     |  Delivery
     |  Handler
STEP |     |
 1.          Consumer generates Delivery Request Block and sends it to
             the Delivery Handler with the Signature Block if present

     C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Request Block

 2.          Delivery Handler checks the Status and Order Components
             in the Delivery Request and the optional Signatures,
             creates a Delivery Response Block, sends to the Consumer
             and stops.

     C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Response Block

3.           Consumer checks Delivery Response Block and optional
             Signature Block are OK. Optionally keeps information on
             IOTP Transaction for record keeping purposes and stops.

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

                    Figure 22 Delivery Document Exchange

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 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 7.16.4) set to either: DelivCanceled,
      or Unspecified.




Burdett                      Informational                    [Page 210]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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 8.10) contains:

   o  the following components copied from the Offer Response Block:

      -  the Status Component (see section 7.16)

      -  the Order Component (see section 7.5)

      -  the Organisation Component (see section 7.6) with the roles of:
         Merchant, DeliveryHandler and DeliverTo

      -  the Delivery Component (see section 7.13)

   o  the following Component from the Payment Response Block:

      -  the Status Component (see section 7.16).

   o  zero or more Trading Role Data Components (see section 7.17).

   SIGNATURE BLOCK (DELIVERY REQUEST)

   If the preceding Offer Document Exchange included an Offer Response
   Signature or the Payment Document Exchange included a Payment
   Response Signature, then they should both be copied to the Signature
   Block.

9.1.4.3 Delivery Response IOTP Message

   The Delivery Response IOTP Message contains a Delivery Response Block
   and an optional Signature Block.




Burdett                      Informational                    [Page 211]

RFC 2801                       IOTP/1.0                       April 2000


   DELIVERY RESPONSE BLOCK

   The Delivery Response Block contains:

   o  one Delivery Note Component (see section 7.15) which contains
      delivery instructions about the delivery of goods or services

      in3 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 Consumer Delivery Data component contained in the Delivery
      Request Block (if any)

   o  the Signature Components contained in the Delivery Request Block
      (if any)

   o  the Status Component

   o  the Delivery Note Component

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




Burdett                      Informational                    [Page 212]

RFC 2801                       IOTP/1.0                       April 2000


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














































Burdett                      Informational                    [Page 213]

RFC 2801                       IOTP/1.0                       April 2000


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

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Pay Request Block

 2.          Payment Handler processes Pay Request Block, checks
             optional signature and starts exchanging payment protocol
             messages encapsulated in a Pay Exchange Block, with the
             Consumer

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange 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 a Signature Block, then uses
             information from the Offer Response Bock to create a
             Delivery Response Block and sends both to the Consumer
             and stops.

     C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
             Block; Signature Block; Pay Response Block; Delivery
             Response Block

 4.          Consumer checks Payment Response and Delivery Response
             Blocks are OK. Optionally keeps information on IOTP
             Transaction for record keeping purposes and either stops
             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 23 Payment and Delivery Document Exchange








Burdett                      Informational                    [Page 214]

RFC 2801                       IOTP/1.0                       April 2000


   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
   7.13) contained within the Offer Response Block (see section 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 separate IOTP Messages.

9.1.5.1 Message Processing Guidelines

   On receiving a Payment Request IOTP Message or a Payment Exchange
   IOTP Message, the Payment Handler should carry out the same actions
   as for a Payment Document Exchange (see section 9.1.3.1).

   On receiving a Payment Exchange IOTP Message, the Consumer should
   also carry out the same actions as for a Payment Document Exchange
   (see section 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 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.

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



Burdett                      Informational                    [Page 215]

RFC 2801                       IOTP/1.0                       April 2000


9.1.5.3 Payment Exchange IOTP Message

   The content of this message is the same as for a Payment Exchange
   IOTP Message in a Payment Document Exchange (see section 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 the Payment Response IOTP Message associated with a Payment
   Document Exchange (see section 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 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 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 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 9.1.1) as illustrated
   by the diagram below.



Burdett                      Informational                    [Page 216]

RFC 2801                       IOTP/1.0                       April 2000


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

   START -------------------------------------------------------
                                                                v
                                                       ----------------
                                                      | AUTHENTICATION |
                                                       ----------------
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                  -------------------     -----------------      |
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
                 |       OFFER       |   |      OFFER      |     |
                  -------------------     -----------------      |
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                      ---------           --------------         |
                     | PAYMENT |         | PAYMENT WITH |        |
                     | (first) |         |   DELIVERY   |        |
                      ---------           --------------         |
                                                                 |
                                                                 |
                                                                 |
         ----------        ---------                             |
        | DELIVERY |      | PAYMENT |                            |
        |          |      | {second)|                            |
         ----------        ---------                             |
                                                                 v
                                                               STOP

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

               Figure 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/TLS]) with a customer

      -  authenticate the customer using the Baseline Authentication
         IOTP Transaction, and then



Burdett                      Informational                    [Page 217]

RFC 2801                       IOTP/1.0                       April 2000


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

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.

   The Baseline Deposit IOTP Transaction consists of the following
   Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2), and

   o  a Payment Document Exchange (see section 9.1.3).

   The way in which these Document Exchanges may be combined together is
   illustrated by the diagram below.


















Burdett                      Informational                    [Page 218]

RFC 2801                       IOTP/1.0                       April 2000


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

   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 25 Baseline Deposit IOTP Transaction

   See section 9.1.12 "Valid Combinations of Document Exchanges" to
   determine which combination of document exchanges apply to a
   particular instance of an IOTP Transaction

   Note that:

   o  a Merchant (Financial Institution) may be able to accept a deposit
      in several different types of electronic cash although, since the
      Consumer role that is depositing the electronic cash usually knows
      what type of cash they want to deposit, it is usually constrained



Burdett                      Informational                    [Page 219]

RFC 2801                       IOTP/1.0                       April 2000


      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.

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

   o  an Offer Document Exchange (see section 9.1.2)

   o  either:

      -  a Payment Document Exchange (see section 9.1.3) followed by



Burdett                      Informational                    [Page 220]

RFC 2801                       IOTP/1.0                       April 2000


      -  a Delivery Document Exchange (see section 9.1.4)

   o  a Payment Document Exchange only, or

   o  a combined Payment and Delivery Document Exchange (see section
      9.1.5).

   The ways in which these Document Exchanges are combined is
   illustrated by the diagram below.

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

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |    |
                       |                     |              |    |
                       |      -------------- | -------------     |
                       v      v              v      v            |
                  -------------------     -----------------      |
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
                 |       OFFER       |   |      OFFER      |     |
                  -------------------     -----------------      |
                        |    |                   |   |           |
                        |     ---------------    |   |           |
                        |                    |   |   |           |
                        |     -------------- | --    |           |
                        v    v               v       v           |
                      ---------           --------------         |
                     | PAYMENT |         | PAYMENT WITH |        |
                     | (first) |         |   DELIVERY   |        |
                      ---------           --------------         |
                          |                      |               |
              -----------------------------      |               |
              v                            |     |               |
         ----------        ---------       |     |               |
        | DELIVERY |      | PAYMENT |      |     |               |
        |          |      | {second)|      |     |               |
         ----------        ---------       |     |               |
              |                            |     |               v
               ----------------------------------------------> STOP

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

                  Figure 26 Baseline Purchase IOTP Transaction




Burdett                      Informational                    [Page 221]

RFC 2801                       IOTP/1.0                       April 2000


   See section 9.1.12 "Valid Combinations of Document Exchanges" to
   determine which combination of document exchanges apply to a
   particular instance of an IOTP Transaction.

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

      -  an Offer Document Exchange (see section 9.1.2), and

      -  a Payment Document Exchange (see section 9.1.3).

   The ways in which these Document Exchanges are combined is
   illustrated by the diagram below.







Burdett                      Informational                    [Page 222]

RFC 2801                       IOTP/1.0                       April 2000


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

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |
                       |                     |              |
                       |      -------------- | -------------
                       v      v              v      v
                  -------------------     -----------------
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |
                 |       OFFER       |   |      OFFER      |
                  -------------------     -----------------
                        |                        |
                        |                        |
                        |                        |
                        |     -------------------
                        v    v
                      ---------           --------------
                     | PAYMENT |         | PAYMENT WITH |
                     | (first) |         |   DELIVERY   |
                      ---------           --------------
                          |
                           ----------------
                                           |
         ----------        ---------       |
        | DELIVERY |      | PAYMENT |      |
        |          |      | {second)|      |
         ----------        ---------       |
                                           |
                                            -----------------> STOP

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

                   Figure 27 Baseline 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.





Burdett                      Informational                    [Page 223]

RFC 2801                       IOTP/1.0                       April 2000


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

   The Baseline Withdrawal IOTP Transaction consists of the following
   Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2), and

   o  a Payment Document Exchange (see section 9.1.3).

   The way in which these Document Exchanges may be combined together is
   illustrated by the diagram below.




















Burdett                      Informational                    [Page 224]

RFC 2801                       IOTP/1.0                       April 2000


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

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






Burdett                      Informational                    [Page 225]

RFC 2801                       IOTP/1.0                       April 2000


   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.

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:

   o  electronic cash advance on a credit card. For example the first
      payment could be a "dollar SET Payment" using a credit card with
      the second payment being a download of Visa Cash e-cash in
      dollars.

   o  foreign exchange using the same payment method. For example the
      payment could be an upload of Mondex value in British Pounds and
      the second a download of Mondex value in Euros






Burdett                      Informational                    [Page 226]

RFC 2801                       IOTP/1.0                       April 2000


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

   o  an Offer Document Exchange (see section 9.1.2), which provides
      details of what values and currencies will be exchanged, and

   o  two Payment Document Exchanges (see section 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.



































Burdett                      Informational                    [Page 227]

RFC 2801                       IOTP/1.0                       April 2000


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

   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 29 Baseline Value Exchange IOTP Transaction














Burdett                      Informational                    [Page 228]

RFC 2801                       IOTP/1.0                       April 2000


   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.

   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.

























Burdett                      Informational                    [Page 229]

RFC 2801                       IOTP/1.0                       April 2000


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

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 30 Baseline Value Exchange Signatures

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






Burdett                      Informational                    [Page 230]

RFC 2801                       IOTP/1.0                       April 2000


      |                ----------------------       TPO & Offer Response
       -------------                         |   Blocks in last IOTP Msg
                    |                        |     |=TRUE        |=FALSE
                    |                        |     |             v
                    |          ------------- | ----    TPO Block only 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 31 Valid Combinations of Document Exchanges



Burdett                      Informational                    [Page 231]

RFC 2801                       IOTP/1.0                       April 2000


   1) If first IOTP Message of an IOTP Transaction contains an
      Authentication Request then:

      a) IOTP Transaction includes an Authentication Document Exchange
         (see section 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 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 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):

      e) IOTP Transaction does not include an Authentication Document
         Exchange (Note 2)

      f) If first IOTP Message contains an Offer Response Block, then:

         i) the IOTP Transaction contains a Brand Independent Offer
            Document Exchange (Note 2)

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

      h) If the Offer Response Block contains a Delivery Component then:

         i) If the DelivAndPayResp attribute of the Delivery Component
            is set to True, then:




Burdett                      Informational                    [Page 232]

RFC 2801                       IOTP/1.0                       April 2000


            (1) the IOTP Transaction consists of a Payment And Delivery
                Document Exchange (see section 9.1.5) (Note 4)

        ii) otherwise (the DelivAndPayResp attribute of the Delivery
            Component is set to False)

            (1) the IOTP Transaction consists of a Payment Document
                Exchange (see section 9.1.3) followed by a Delivery
                Document Exchange (see section 9.1.4) (Note 4)

      i) otherwise (the Offer Response Block does not contain a Delivery
         Component)

         i) if the Offer Response Block contains just one Payment
            Component, then:

            (1) the IOTP Transaction contains just one Payment Document
                Exchange (Note 5)

        ii) if the Offer Response Block contains two Payment Components,
            then:

            (1) 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 validly have the conditions indicated above.

   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



Burdett                      Informational                    [Page 233]

RFC 2801                       IOTP/1.0                       April 2000


   6. Baseline Value Exchange only

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




Burdett                      Informational                    [Page 234]

RFC 2801                       IOTP/1.0                       April 2000


   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 request information will be indistinguishable
   from other Payment Scheme Components.

9.2 Infrastructure Transactions

   Infrastructure Transactions are designed to support inquiries about
   whether or not a transaction has succeeded or a Trading Role's
   servers are operating correctly. There are two types of transaction:

   o  a Transaction Status Inquiry Transaction which provides
      information 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

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

   o  an Inquiry Response Trading Block (see section 8.13)

   o  an optional Signature Block (see section 8.16).

   The Inquiry IOTP Transaction can be used for a variety of reasons.
   For example:

   o  to help in resuming a suspended transaction to determine the
      current state of processing of one of the other roles,




Burdett                      Informational                    [Page 235]

RFC 2801                       IOTP/1.0                       April 2000


   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 of the Payment Handler then the
      Merchant can determine whether or not payment was made.

   Note: Inquiries on Baseline Ping IOTP Transactions (see section
   9.2.2) are ignored.

   MAKING INQUIRIES OF ANOTHER TRADING 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 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 a
      Trading Role only after the following events have occurred:

      - to the Merchant, after sending a TPO Selection Block,

      - to the Payment Handler, after sending a Payment Request Block,

      - to the Delivery Handler, after sending a Delivery Request Block,

   o  other Trading Roles should send a Transaction Status Inquiry Block
      to the Consumer only after receiving a message from the Consumer
      and before sending the final "Response" message to the Consumer

   o  there are no restrictions on non-Consumer Trading Roles sending
      Inquiries to other trading roles.

   TRANSACTION STATUS INQUIRY TRANSPORT SESSION

   For a Transaction Status Inquiry on an ongoing transaction a
   different transport session from the ongoing transaction is used. For
   a Transaction Status Inquiry on a past transaction, how the IOTP





Burdett                      Informational                    [Page 236]

RFC 2801                       IOTP/1.0                       April 2000


   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 was last sent to the 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 7.21.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 process.









Burdett                      Informational                    [Page 237]

RFC 2801                       IOTP/1.0                       April 2000


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

   1st Role
     |  2nd Role
STEP |     |
 1.          The first role decides to inquire on an IOTP Transaction
             by, for example, clicking on the inquiry button of an
             IOTP Aware Application. This will then generate an
             Inquiry Request Block and send it to the appropriate
             Trading Role.

     1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
             (optional); Inquiry Request Block

 2.          The Trading Role checks the digital signature (if
             present). If the recipient wants to respond, then the
             Trading Role checks the transaction status of the
             transaction that is being inquired upon by using the
             IotpTransId in the Transaction ID Component of the
             Transaction Reference Block, then generates the
             appropriate Inquiry Response Block, sends the message
             back to the 1st Role and stops

     1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry
             Response Block; Signature Block (Optional)

3.           First role checks the Inquiry Response Block and optional
             signature, 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

   A Trading Role making an inquiry must use a Transaction Id Component
   (see section 3.3.1) where both the IotpTransId and TransTimeStamp
   attributes are the same as in the Transaction Id Component of the
   original transaction that is being inquired upon. The IotpTransId
   attribute in this component serves as the key in querying the



Burdett                      Informational                    [Page 238]

RFC 2801                       IOTP/1.0                       April 2000


   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 original transaction (see section 3.4.1).

   If up-to-date status information is required then the MsgId
   Component, and in particular the ID attribute for the MsgId Component
   must be different from any other IOTP Message that has been sent by
   the Trading Role. This is required because of the way that
   Idempotency is handled by IOTP (see section 4.5.2.2 Checking/Handling
   Duplicate Messages).

   INQUIRY REQUEST BLOCK

   The Inquiry Request Block (see section 8.12) contains the following
   components:

   o  one Inquiry Type Component (see section 7.18). This identifies
      whether the inquiry is on an offer, payment, or delivery.

   o  zero or one Payment Scheme Components (see section 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.

   If present, the Inquiry Request Signature Block (see section 8.12)
   contains the following components:

   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.

   Inquiry Response Blocks should only be generated if the Transaction
   is authorised.

   Note: Digital signatures on an Inquiry Request is only likely to
   occur if the recipient of the request expects the Inquiry Request to
   be signed. In this version of IOTP this will require some kind of
   pre-existing agreement. This means that:

   o  Consumers are unlikely to generate requests with signatures,
      although it is not an error if they do





Burdett                      Informational                    [Page 239]

RFC 2801                       IOTP/1.0                       April 2000


   o  the other trading roles may agree that digital signatures are
      required. For example a Payment Handler may require that an
      Inquiry Request is digitally signed by the Merchant so that they
      can check that the request is valid.

   On the other hand if the original transaction to which the Inquiry
   relates was carried out over a secure channel (e.g., [SSL]) then it
   is probably 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.

   INQUIRY RESPONSE BLOCK

   The Inquiry Response Block (see section 8.13) contains the following
   components:

   o  one Status Component (see section 7.16). This component holds the
      status information on the inquired transaction,

   o  zero or one Payment Scheme Components. These contain encapsulated
      payment scheme specific inquiry messages for inquiries on payment.

   SIGNATURE BLOCK (INQUIRY RESPONSE)

   If a signature block is present on the message containing the Inquiry
   Response Block then it may be checked by the receiver of the block to
   determine if the Inquiry Response is valid.

   If present, the Inquiry Response Signature Block (see section 8.13)
   contains the following components:

   o one Signature Component (see section 7.19)

   o one or more Certificate Components, if required.

   Note: Digital signatures on an Inquiry Response is only likely to
   occur if the recipient of the response expects the Inquiry Request to
   be signed. In this version of IOTP this will require some kind of
   pre-existing agreement. This means that:

   o  Consumers are unlikely to generate responses with signatures,
      although it is not an error if they do

   o  the other trading roles may agree that digital signatures are
      required. For example a Merchant may require that an Inquiry
      Response is digitally signed by the Payment Handler so that they
      can check that the request response is valid.




Burdett                      Informational                    [Page 240]

RFC 2801                       IOTP/1.0                       April 2000


9.2.2 Baseline Ping IOTP Transaction

   The purpose of the Baseline IOTP Ping Transaction is to test basic
   connectivity between the Trading Roles that may take part in an IOTP
   Transaction.

   It enables IOTP aware application software to:

   o  determine if the IOTP aware application at another Trading Role is
      operating, and

   o  verify whether or not the two trading roles signatures can be
      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 8.14)

   o a Ping Response Block (see section 8.15), and

   o a Signature Block (see section 8.16).

   PING MESSAGES

   The following figure outlines the message flows in the Baseline IOTP
   Ping Transaction.





















Burdett                      Informational                    [Page 241]

RFC 2801                       IOTP/1.0                       April 2000


 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
    1st Role
     |  2nd Role
STEP |     |
 1.          The IOTP Aware Application in 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 second trading role.

     1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block
             (Optional); Ping Request Block

 2.          The second Trading Role which receives the Ping Request
             Block generates a Ping Response Block and sends it back
             to the sender of the original Ping Request with a
             signature block if required.

     1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
             (Optional); Ping Response Block

 3.          The first Trading Role checks the Ping Response Block and
             takes appropriate action, if necessary

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

                      Figure 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





Burdett                      Informational                    [Page 242]

RFC 2801                       IOTP/1.0                       April 2000


   o  does NOT initiate an IOTP 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 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
   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 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 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 the Ping Request Block.

   SIGNATURE BLOCK (PING REQUEST)

   The Ping Request Signature Block (see section 8.16) contains the
   following components:




Burdett                      Informational                    [Page 243]

RFC 2801                       IOTP/1.0                       April 2000


   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.

   PING RESPONSE BLOCK

   The Ping Response Block (see section 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 8.16) contains the
   following components:

   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.

10. Retrieving Logos

   This section describes how to retrieve logos for display by IOTP
   aware software using the Logo Net Locations attribute contained in
   the Brand Element (see section 7.7.1) and the Organisation Component
   (see section 7.6).

   The full address of a logo is defined as follows:  Logo_address ::=
   Logo_net_location "/" Logo_size Logo_color_depth ".gif"

   Where:

   o  Logo_net_location is obtained from the LogoNetLocn attribute in
      the Brand Element (see section 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,





Burdett                      Informational                    [Page 244]

RFC 2801                       IOTP/1.0                       April 2000


      -  implementers should check that if the rightmost character of
         Logo Net Location is set to right-slash "/" then another, right
         slash should not be included when generating the Logo Address,

   o  Logo_size identifies the size of the logo,

   o  Logo_color_depth identifies the colour depth of the logo

   o  "gif" indicates that the logos are in "gif" format

   Logo_size and Logo_color_depth are specified by the implementer of
   the IOTP software that is retrieving the logo depending on the size
   and colour that they want to use.

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

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




Burdett                      Informational                    [Page 245]

RFC 2801                       IOTP/1.0                       April 2000


   Note that if Logo Color Depth is omitted then a logo with the default
   colour depth of 256 colours will be retrieved.

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

11. Brands

   This section contains:

   o  a definition of Brands and an outline of Brand Selection using
      Brand Lists, and

   o  some XML examples of Brand Lists

11.1 Brand Definitions and Brand Selection

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

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

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

   Also see the following sections:






Burdett                      Informational                    [Page 246]

RFC 2801                       IOTP/1.0                       April 2000


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

   o  Brand Selection Component (section 7.8) for details of how a
      Consumer records the Brand, currency, amount and payment 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 credit card such as MasterCard or Visa;

   o  a debit card such as MasterCard's Maestro;

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

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

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

11.1.2 Definition of Brand

   A Brand is the mark which identifies a particular type of Payment
   Instrument. A list of Brands are the payment options which are
   presented by the Merchant to the Consumer and from which the Consumer
   makes a selection. Each Brand may have a different Payment Handler.
   Examples of Brands include:

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

   o  promotional brands (see below). These include:

      -  store brands, where the Payment Instrument is issued to a
         Consumer by a particular Merchant, for example Walmart, Sears,
         or Marks and Spencer (UK)

      -  cobrands, for example American Advantage Visa, where an
         Organisation uses their own brand in conjunction with,
         typically, a payment association Brand.




Burdett                      Informational                    [Page 247]

RFC 2801                       IOTP/1.0                       April 2000


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 can be used as either a UC card or a
   regular MasterCard. The UC card Brand and the MasterCard Brand could
   each have their own separate Payment Handlers. This means that:

   o  the merchant treats, for example "UC" and "MasterCard" as two
      separate Brands when offering a list of Brands to the Consumer,

   o  the consumer chooses a Brand, for example either "UC" or
      "MasterCard,

   o  the consumer IOTP aware application determines which Payment
      Instrument(s) match the chosen Brand, and selects, perhaps with
      user assistance, the correct Payment Instrument to use.

   Note: Dual Brands need no special treatment by the Merchant and
   therefore no explicit reference is made to Dual Brands in the DTD.
   This is because, as far as the Merchant is concerned, each Brand in a
   Dual Brand is treated as a separate Brand. It is at the Consumer,
   that the matching of a Brand to a Dual Brand Payment Instrument needs
   to be done.

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 can be
   received in two ways:

   o  at the time of purchase. For example if a Consumer pays with a
      "Walmart MasterCard" at a Walmart web site, then a 5% discount
      might apply, which means the consumer actually pays less,

   o  from their Payment Instrument (card) issuer when the payment
      appears on their statement. For example loyalty points in a
      frequent flyer scheme could be awarded based on the total payments
      made with the Payment Instrument since the last statement was
      issued.

   Note that:

   o  the first example (obtaining the benefit at the time of purchase),
      requires that:

      -  the Consumer is informed of the benefits which arise if that
         Brand is selected



Burdett                      Informational                    [Page 248]

RFC 2801                       IOTP/1.0                       April 2000


      -  if the Brand is selected, the Merchant changes the relevant
         IOTP Components in the Offer Response to reflect the correct
         amount to be paid

   o  the second (obtaining a benefit through the Payment Instrument
      issuer) does not require that the Offer Response is changed

   o  each Promotional Brand should be identified as a separate Brand in
      the list of Brands offered by the Merchant. For example:
      "Walmart", "Sears", "Marks and Spencer" and "American Advantage
      Visa", would each be a separate Brand.

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.

11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands

   Correct identification that the Consumer is paying using a
   Promotional Brand is important since a Consumer might fraudulently
   claim to have a Promotional Brand that offers a reduced payment
   amount when in reality they do not.

   Two approaches seem possible:

   o  use some feature of the Payment Instrument or the payment method
      to positively identify the Brand being used. For example, the SET
      certificate for the Brand could be used, if one is available, or

   o  use the Payment Instrument (card) number to look up information
      about the Payment Instrument on a Payment Instrument issuer
      database to determine if the Payment Instrument is a promotional
      brand.





Burdett                      Informational                    [Page 249]

RFC 2801                       IOTP/1.0                       April 2000


   Note that:

   o  the first assumes that SET is available.

   o  the second is only possible if the Merchant, or alternatively the
      Payment Handler, has access to card issuer information.

   IOTP does not provide the Merchant with Payment Instrument
   information (e.g., a card or account number). This is only sent as
   part of the encapsulated payment protocol to a Payment Handler. This
   means that:

   o  the Merchant would have to assume that the Payment Instrument
      selected was a valid Promotional Brand, or

   o  the Payment Handler would have to check that the Payment
      Instrument was for the valid Promotional Brand and fail the
      payment if it was not.

   A Payment Handler checking that a brand is a valid Promotional Brand
   is most likely if the Payment Handler is also the Card Issuer.

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,




Burdett                      Informational                    [Page 250]

RFC 2801                       IOTP/1.0                       April 2000


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






Burdett                      Informational                    [Page 251]

RFC 2801                       IOTP/1.0                       April 2000


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://otplogos.mastercard.com/mastercardcredit'
       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>




Burdett                      Informational                    [Page 252]

RFC 2801                       IOTP/1.0                       April 2000


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'



Burdett                      Informational                    [Page 253]

RFC 2801                       IOTP/1.0                       April 2000


     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'



Burdett                      Informational                    [Page 254]

RFC 2801                       IOTP/1.0                       April 2000


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



Burdett                      Informational                    [Page 255]

RFC 2801                       IOTP/1.0                       April 2000


       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'



Burdett                      Informational                    [Page 256]

RFC 2801                       IOTP/1.0                       April 2000


       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

   This section describes the codes that are controlled by IANA, and
   also how new codes can be created for testing purposes that are not
   controlled by IANA.

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.




Burdett                      Informational                    [Page 257]

RFC 2801                       IOTP/1.0                       April 2000


   The element types and attributes names to which this procedure
   applies 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
   Name               will apply
   (When Algorithm
   is a child of an   "signature" - indicates that authentication
   AuthReq            consists 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.

     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




Burdett                      Informational                    [Page 258]

RFC 2801                       IOTP/1.0                       April 2000


                      "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 specification, no currency codes
   of this type have been defined.

     Element Type/                     Attribute Values
     Attribute Name

   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



Burdett                      Informational                    [Page 259]

RFC 2801                       IOTP/1.0                       April 2000


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

                      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

     Element Type/                     Attribute Values
     Attribute Name
                      delivery method is used.

   Status/            Offer
   StatusType
                      Payment



Burdett                      Informational                    [Page 260]

RFC 2801                       IOTP/1.0                       April 2000


                      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 documents that describe new Trading
   Roles and types of signatures (see below).

   TradingRole/       "Consumer"
   TradingRole
                      "Merchant"

                      "PaymentHandler"

                      "DeliveryHandler"

                      "DelivTo"

                      "CustCare"

                      New values of the Trading Role 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 Trading Role, 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 Trading Role
   attribute may be

     Element Type/                     Attribute Values
     Attribute Name
                                   combined with documents that describe
                                   new Status Types (see above) and
                                   types of signatures (see below).



Burdett                      Informational                    [Page 261]

RFC 2801                       IOTP/1.0                       April 2000


   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 Transaction, and
                       o review of the document on the IETF Trade
                         Working Group mailing list and by the
                         Designated Expert.

   Attribute/ Content
   (see Signature
                      "OfferResponse"
   Component)         "PaymentResponse"

                      "DeliveryResponse"

                      "AuthenticationRequest"

                      "AuthenticationResponse"

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





Burdett                      Informational                    [Page 262]

RFC 2801                       IOTP/1.0                       April 2000


     Element Type/                     Attribute Values
     Attribute Name

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

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 codes. For this reason, "user defined codes" may be
   used to identify additional values for the codes contained within
   this 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.





















Burdett                      Informational                    [Page 263]

RFC 2801                       IOTP/1.0                       April 2000


   <!--
   ******************************************************
   *                                                    *
   * INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD     *
   * Filename: ietf.org/rfc/rfc2801.dtd                 *
   *                                                    *
   * Changes from version 07 (iotp-v1.0-protocol-07.dtd)*
   *   - NO CHANGES                                     *
   *                                                    *
   *                                                    *
   *                                                    *
   *                                                    *
   * Copyright Internet Engineering Task Force 1998-2000*
   *                                                    *
   ******************************************************

   ******************************************************
   * IOTP MESSAGE DEFINITION                            *
   ******************************************************
    -->

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





Burdett                      Informational                    [Page 264]

RFC 2801                       IOTP/1.0                       April 2000


   <!--
   ******************************************************
   * 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'
    IotpTransId        CDATA   #REQUIRED
    IotpTransType      CDATA   #REQUIRED
    TransTimeStamp     CDATA   #REQUIRED >


   <!ELEMENT MsgId EMPTY >
   <!ATTLIST MsgId
    ID                 ID      #REQUIRED
    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                    *
   ******************************************************
    -->




Burdett                      Informational                    [Page 265]

RFC 2801                       IOTP/1.0                       April 2000


   <!ELEMENT PackagedContent (#PCDATA) >
   <!ATTLIST PackagedContent
    Name             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 AuthReq (Algorithm, PackagedContent*)>
   <!ATTLIST AuthReq
    ID                 ID      #REQUIRED
    AuthenticationId   CDATA   #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    NMTOKENS #REQUIRED >

   <!-- ORDER COMPONENT -->
   <!ELEMENT Order (PackagedContent*) >
   <!ATTLIST Order
    ID                 ID      #REQUIRED



Burdett                      Informational                    [Page 266]

RFC 2801                       IOTP/1.0                       April 2000


    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
    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   #IMPLIED
    ErrorNetLocn       CDATA   #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 >





Burdett                      Informational                    [Page 267]

RFC 2801                       IOTP/1.0                       April 2000


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



Burdett                      Informational                    [Page 268]

RFC 2801                       IOTP/1.0                       April 2000


    CurrCodeType       NMTOKEN 'ISO4217-A'
    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



Burdett                      Informational                    [Page 269]

RFC 2801                       IOTP/1.0                       April 2000


    SignedPayReceipt (True | False) #REQUIRED
    StartAfterRefs     NMTOKENS #IMPLIED >


   <!-- PAYMENT SCHEME COMPONENT -->
   <!ELEMENT PaySchemeData (PackagedContent+) >
   <!ATTLIST PaySchemeData
    ID                 ID      #REQUIRED
    PaymentRef         NMTOKEN #IMPLIED
    ConsumerPaymentId  CDATA   #IMPLIED
    PaymentHandlerPayId CDATA  #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >


   <!-- PAYMENT RECEIPT COMPONENT -->
   <!ELEMENT PayReceipt (PackagedContent*) >
   <!ATTLIST PayReceipt
    ID                 ID      #REQUIRED
    PaymentRef         NMTOKEN #REQUIRED
    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 >

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



Burdett                      Informational                    [Page 270]

RFC 2801                       IOTP/1.0                       April 2000


    ContentSoftwareId  CDATA   #IMPLIED >


   <!-- CONSUMER DELIVERY DATA COMPONENT -->
   <!ELEMENT ConsumerDeliveryData EMPTY >
   <!ATTLIST ConsumerDeliveryData
    ID                 ID      #REQUIRED
    ConsumerDeliveryId CDATA   #REQUIRED >


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





Burdett                      Informational                    [Page 271]

RFC 2801                       IOTP/1.0                       April 2000


   <!-- 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
    IotpMsgRef         NMTOKEN #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 >





Burdett                      Informational                    [Page 272]

RFC 2801                       IOTP/1.0                       April 2000


   <!-- AUTHENTICATION REQUEST BLOCK -->
   <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
   <!ATTLIST AuthReqBlk
    ID                 ID      #REQUIRED >


   <!-- AUTHENTICATION RESPONSE BLOCK -->
   <!ELEMENT AuthRespBlk (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?, PaySchemeData?,
        PaymentNote?, TradingRoleData*) >
   <!ATTLIST PayRespBlk
    ID                 ID      #REQUIRED >
   <!-- DELIVERY REQUEST BLOCK -->
   <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
        ConsumerDeliveryData?, TradingRoleData*) >
   <!ATTLIST DeliveryReqBlk
    ID                 ID      #REQUIRED >


   <!-- DELIVERY RESPONSE BLOCK -->
   <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
   <!ATTLIST DeliveryRespBlk
    ID                 ID      #REQUIRED >




Burdett                      Informational                    [Page 273]

RFC 2801                       IOTP/1.0                       April 2000


   <!-- INQUIRY REQUEST BLOCK -->
   <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
   <!ATTLIST InquiryReqBlk
    ID                 ID      #REQUIRED >


   <!-- INQUIRY RESPONSE BLOCK -->
   <!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
   <!ATTLIST InquiryRespBlk
    ID                 ID      #REQUIRED
    LastReceivedIotpMsgRef NMTOKEN #IMPLIED
    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                   *
   ******************************************************
   -->




Burdett                      Informational                    [Page 274]

RFC 2801                       IOTP/1.0                       April 2000


   <!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
   <!ATTLIST IotpSignatures
       ID        ID        #IMPLIED
   >

   <!--
   ******************************************************
   * IOTP SIGNATURE COMPONENT DEFINITION                *
   ******************************************************
   -->

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

   <!ELEMENT Manifest
       (       Algorithm+,
               Digest+,
               Attribute*,
               OriginatorInfo,
               RecipientInfo+
       )
   >

   <!ATTLIST Manifest
       LocatorHRefBase       CDATA             #IMPLIED
   >

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

   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
       DigestAlgorithmRef    IDREF             #REQUIRED
   >

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

   <!ELEMENT OriginatorInfo ANY >



Burdett                      Informational                    [Page 275]

RFC 2801                       IOTP/1.0                       April 2000


   <!ATTLIST OriginatorInfo
       OriginatorRef           NMTOKEN          #IMPLIED
   >

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

   <!ELEMENT KeyIdentifier EMPTY>
   <!ATTLIST KeyIdentifier
       value                    CDATA           #REQUIRED
   >

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
       type                     CDATA           #REQUIRED
   >


   <!--
   ******************************************************
   * IOTP CERTIFICATE COMPONENT DEFINITION              *
   ******************************************************
   -->

   <!ELEMENT Certificate
    (  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                   *
   ******************************************************



Burdett                      Informational                    [Page 276]

RFC 2801                       IOTP/1.0                       April 2000


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

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
       xml:link        CDATA         #FIXED        'simple'
       href            CDATA         #REQUIRED
   >

14. Glossary

   This section contains a glossary of some of the terms used within
   this specification in alphabetical order.

          NAME                            DESCRIPTION

   Authenticator      The Organisation which is requesting the
                      authentication of another Organisation, and

   Authenticatee      The Organisation being authenticated by an
                      Authenticator

   Business Error     See Status Component.

   Brand              A Brand is the mark which identifies a particular
                      type of Payment Instrument. A list of Brands are
                      the payment options which are presented by the
                      Merchant to the Consumer and from which the
                      Consumer makes a selection. Each Brand may have a
                      different Payment Handler. Examples of Brands
                      include:
                       o payment association and proprietary Brands,
                         for example MasterCard, Visa, American Express,
                         Diners Club, American Express, Mondex,
                         GeldKarte, CyberCash, etc.
                       o Promotional Brands (see below). These include:
                       o store Brands, where the Payment Instrument is
                         issued to a Consumer by a particular Merchant,
                         for example Walmart, Sears, or Marks and
                         Spencer (UK)
                       o coBrands, for example American Advantage Visa,
                         where an a company uses their own Brand in
                         conjunction with, typically, a payment
                         association Brand.



Burdett                      Informational                    [Page 277]

RFC 2801                       IOTP/1.0                       April 2000


   Consumer           The Organisation which is to receive the benefit
                      of and typically pay for the goods or services.

   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.

   Delivery Handler   The Organisation that 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.

   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



Burdett                      Informational                    [Page 278]

RFC 2801                       IOTP/1.0                       April 2000


                      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.

   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.

   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



Burdett                      Informational                    [Page 279]

RFC 2801                       IOTP/1.0                       April 2000


                       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.

   IOTP Transaction   A Transaction Type identifies the type an of IOTP
   Type               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.

   Merchant           The Organisation from whom the service or goods
                      are being obtained, who is legally responsible for
                      providing the goods or services and receives the
                      benefit of any payment made

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

   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            A Payment Instrument is the means by which
   Instrument         Consumer pays for goods or services offered by a
                      Merchant. It can be, for example:
                       o a credit card such as MasterCard or Visa;
                       o a debit card such as MasterCard's Maestro;
                       o a smart card based electronic cash Payment



Burdett                      Informational                    [Page 280]

RFC 2801                       IOTP/1.0                       April 2000


                         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's CyberCoin or DigiCash
                         account.

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

   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.

   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.

   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



Burdett                      Informational                    [Page 281]

RFC 2801                       IOTP/1.0                       April 2000


                      Response Blocks resulting from previously
                      completed Trading Exchanges.  Examples of Request
                      Blocks are Payment Request and Delivery Request

   Response Block     A Response Block is a Trading Block that indicates
                      that a Trading Exchange is complete. It is sent by
                      the Trading Role that received a Request Block to
                      the Trading Role that sent the Request Block. The
                      Response Block contains a Status Component that
                      contains information about the completion of the
                      Trading Exchange, for example it indicates whether
                      or not the Trading Exchange completed
                      successfully. For some Trading Exchanges the
                      Response Block contains a Receipt Component that
                      forms a record of the Trading Exchange. Receipt
                      Components may be digitally signed using a
                      Signature Block to make completion non-refutable.
                      Examples of Response Blocks include Offer
                      Response, Payment Response and Delivery Response.

   Signature Block    A Signature Block is a Trading Block that contains
                      one or more digital signatures in the form of
                      Signature Components. A Signature Component may
                      digitally sign any Block or Component in any IOTP
                      Message in the same IOTP Transaction.

   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.




Burdett                      Informational                    [Page 282]

RFC 2801                       IOTP/1.0                       April 2000


   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]

   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.



Burdett                      Informational                    [Page 283]

RFC 2801                       IOTP/1.0                       April 2000


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

15. References

   This section contains references to related documents identified in
   this specification.

   [Base64]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [DOM-HASH]  Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values
               for DOM (DOMHASH)", RFC 2803, April 2000.

   [DNS]       Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.

   [DNS]       Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 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.



Burdett                      Informational                    [Page 284]

RFC 2801                       IOTP/1.0                       April 2000


   [HMAC]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

   [HTML]      Berners-Lee, T. and D. Connolly, "Hypertext Markup
               Language - 2.0", RFC 1866, November 1995.

   [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 the World Wide Web (W3C) consortium web site at:
               http://www.w3.org/MarkUp/

   [HTTP]      Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
               Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [HTTP]      Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T.
               Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.",
               RFC 2616, June 1999.

   [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]  Davidson, K. and Y. Kawatsura, "Digital Signatures for
               the v1.0 Internet Open Trading Protocol (IOTP)", RFC
               2802, April 2000.

   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [MIME]      Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, August 1982.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Two: Media Types", RFC 2046,
               November 1996.

   [MIME]      Moore, K., "MIME (Multipurpose Internet Mail Extensions)
               Part Three: Message Header Extensions for Non-ASCII Text"
               RFC 2047, November 1996.



Burdett                      Informational                    [Page 285]

RFC 2801                       IOTP/1.0                       April 2000


   [MIME]      Freed, N., Klensin, J. and J. Postel, "Multipurpose
               Internet Mail Extensions (MIME) Part Four: Registration
               Procedures", RFC 2048, November 1996.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Five: Conformance Criteria and
               Examples" RFC 2049, November 1996.

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

   [RFC1738]   Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
               Resource Locators (URL)", RFC 1738, December 1994.

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

   [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/TLS. An IOTP
               supplement describing how SCCD works is under
               development.

   [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.setco.org>.

   [SSL/TLS]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [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



Burdett                      Informational                    [Page 286]

RFC 2801                       IOTP/1.0                       April 2000


   [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/1998/REC-xml-19980210 for the 10
               February 1998 version.

16. Author's Address

   The author of this document is:

   David Burdett
   Commerce One
   4440 Rosewood Drive, Bldg 4
   Pleasanton
   California 94588
   USA

   Phone: +1 (925) 520 4422
   EMail: david.burdett@commerceone.com

   The author of this document particularly wants to thank Mondex
   International Limited (www.mondex.com) for the tremendous support
   provided in the formative stages of the development of this
   specification.











Burdett                      Informational                    [Page 287]

RFC 2801                       IOTP/1.0                       April 2000


   In addition the author appreciates the following contributors to this
   protocol (in alphabetic order of company) without which it could not
   have been developed.

      -  Phillip Mullarkey, British Telecom plc

      -  Andrew Marchewka, Canadian Imperial Bank of Commerce

      -  Brian Boesch, CyberCash Inc.

      -  Tom Arnold, CyberSource

      -  Terry Allen, Commerce One (formally Veo Systems)

      -  Richard Brown, GlobeSet Inc.

      -  Peter Chang, Hewlett Packard

      -  Masaaki Hiroya, Hitachi Ltd

      -  Yoshiaki Kawatsura, Hitachi Ltd

      -  Mark Linehan, International Business Machines

      -  Jonathan Sowler, JCP Computer Services Ltd

      -  John Wankmueller, MasterCard International

      -  Steve Fabes, Mondex International Ltd

      -  Donald Eastlake 3rd, Motorola Inc (formerly International
         Business Machines Inc)

      -  Surendra Reddy, Oracle Corporation

      -  Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)

      -  Chris Smith, Royal Bank of Canada

      -  Hans Bernhard-Beykirch, SIZ (IT Development and Coordination

         Centre of the German Savings Banks Organisation)

      -  W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services,
         formally AT&T Universal Card Services)

      -  Efrem Lipkin, Sun Microsystems




Burdett                      Informational                    [Page 288]

RFC 2801                       IOTP/1.0                       April 2000


      -  Tony Lewis, Visa International

   The author would also like to thank the following organisations for
   their support:

      -  Amino Communications

      -  DigiCash

      -  Fujitsu

      -  General Information Systems

      -  Globe Id Software

      -  Hyperion

      -  InterTrader

      -  Nobil I T Corp

      -  Mercantec

      -  Netscape

      -  Nippon Telegraph and Telephone Corporation

      -  Oracle Corporation

      -  Smart Card Integrations Ltd.

      -  Spyrus

      -  Verifone

      -  Unisource nv

      -  Wells Fargo Bank













Burdett                      Informational                    [Page 289]

RFC 2801                       IOTP/1.0                       April 2000


17. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Burdett                      Informational                    [Page 290]