[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc2801                               
TRADE Working Group                               Surendra Reddy(Oracle)
Internet Draft                                     David Burdett(Mondex)
draft-ietf-trade-iotp-v1.0-protocol-00.txt             September 21,1998
Expires March 21, 1999


                 Internet Open Trading Protocol - IOTP


Status of this Memo

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

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

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

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

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

Abstract

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




Surendra Reddy et al.                                           [Page 1]


Internet Draft                  IOTP/1.0              September 21, 1998


  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.

Acknowledgements

  The Internet Open Trading Protocol has benefited from a large and
  active developer community who have participated on the otp-dev
  mailing list and has been most responsible for the successful
  completion of this specification.
  Phillip Mullarkey, British Telecom plc, Andrew Marchewka, Canadian
  Imperial Bank of Commerce, Brian Boesch, CyberCash Inc., Donald
  Eastlake 3rd, CyberCash Inc., Mark Linehan, International Business
  Machines, Peter  Chang,  Hewlett  Packard,  Masaaki  Hiroya,  Hitachi
  Ltd, Yoshiaki Kawatsura, Hitachi Ltd, Jonathan Sowler, JCP Computer
  Services Ltd, John Wankmueller, MasterCard International, Steve
  Fabes, Mondex International Ltd, 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, Terry Allen, Veo
  Systems  deserve  special  recognition  for  their  efforts  in
  defining early aspects of the protocol.

  Table of Contents

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

  ii.  Abstract .....................................................    1

  iii. Acknowledgements .............................................    2



Surendra Reddy et al.                                           [Page 2]


Internet Draft                  IOTP/1.0              September 21, 1998


  1 Introduction ....................................................    6
    1.1 Commerce on the Internet - a Different Model ................    6
    1.2 What is IOTP? ...............................................    7
    1.3 Benefits of IOTP ............................................    7
    1.4 Terminology .................................................    9
    1.5 IOTP - Abstract Model .......................................   11
    1.6 Interoperability Model ......................................   12
    1.7 Document Framework ..........................................   12
    1.8 Document Scope ..............................................   12
    1.9 Requirements ................................................   13

  2 Internet Open Trading Protocol ..................................   13
    2.1 Introduction ................................................   14
    2.2 Trading Roles ...............................................   15
    2.3 Trading Exchanges ...........................................   16
    2.4 Offer Exchange ..............................................   17
    2.5 Payment Exchange ............................................   18
    2.6 Delivery Exchange ...........................................   20
    2.7 Authentication Exchange .....................................   22
    2.8 Brands and Brand Selection ..................................   22

  3 IOTP Elements ...................................................   25
    3.1 IOTP Message Structure ......................................   25
    3.2 IOTP Transactions ...........................................   27
    3.3 IOTP Message ................................................   28
    3.4 XML Document Prolog .........................................   29
    3.5 Transaction Reference Block .................................   29
    3.6 ID Attributes ...............................................   34
    3.7 Element References ..........................................   37
    3.8 Packaged Content Element ....................................   37
    3.9 Extending IOTP ..............................................   39
    3.10 Identifying Languages ......................................   41
    3.11 Secure and Insecure Net Locations ..........................   42

  4 Internet Open Trading Protocol Transactions .....................   42
    4.1 Baseline Authentication IOTP Transaction ....................   43
    4.2 Baseline Deposit IOTP Transaction ...........................   44
    4.3 Baseline Purchase IOTP Transaction ..........................   49
    4.4 Baseline Refund IOTP Transaction ............................   56
    4.5 Baseline Withdrawal IOTP Transaction ........................   61
    4.6 Baseline Value Exchange IOTP Transaction ....................   67
    4.7 Payment Instrument Customer Care IOTP Transaction ...........   75
    4.8 Baseline Transaction Status Inquiry IOTP Transactin .........   77
    4.9 Baseline Ping IOTP Transaction ..............................   80

  5 Trading Blocks ..................................................   81
    5.1 Trading Protocol Options Block ..............................   82
    5.2 TPO Selection Block .........................................   83



Surendra Reddy et al.                                           [Page 3]


Internet Draft                  IOTP/1.0              September 21, 1998


    5.3 Offer Response Block ........................................   84
    5.4 Authentication Request Block ................................   85
    5.5 Authentication Response Block ...............................   86
    5.6 Payment Request Block .......................................   86
    5.7 Payment Exchange Block ......................................   88
    5.8 Payment Response Block ......................................   88
    5.9 Delivery Request Block ......................................   89
    5.10 Delivery Response Block ....................................   90
    5.11 Payment Instrument Customer Care Request Block .............   91
    5.12 Payment Instrument Customer Care Exchange Block ............   91
    5.13 Payment Instrument Customer Care Response Block ............   92
    5.14 Inquiry Request Trading Block ..............................   92
    5.15 Inquiry Response Trading Block .............................   93
    5.16 Ping Request Block .........................................   94
    5.17 Ping Response Block ........................................   95
    5.18 Signature Block ............................................   97
    5.19 Error Block ................................................   98

  6 Trading Components ..............................................   99
    6.1 Protocol Options Component ..................................  100
    6.2 Authentication Data Component ...............................  102
    6.3 Authentication Response Component ...........................  103
    6.4 Order Component .............................................  104
    6.5 Order Description Content ...................................  106
    6.6 OkFrom and OkTo Timestamps ..................................  106
    6.7 Organization Component ......................................  107
    6.8 Trading Role Element ........................................  110
    6.9 Contact Information Element .................................  111
    6.10 Person Name Element ........................................  112
    6.11 Postal Address Element .....................................  113
    6.12 Brand List Component .......................................  114
    6.13 Brand Element ..............................................  116
    6.14 Protocol Amount Element ....................................  118
    6.15 Currency Amount Element ....................................  120
    6.16 Pay Protocol Element .......................................  121
    6.17 Brand Selection Component ..................................  123
    6.18 Brand Selection Brand Info Element .........................  125
    6.19 Brand Selection Protocol Amount Info Element ...............  126
    6.20 Brand Selection Currency Amount Info Element ...............  126
    6.21 Payment Component ..........................................  127
    6.22 Payment Scheme Component ...................................  128
    6.23 Payment Receipt Component ..................................  130
    6.24 Delivery Component .........................................  131
    6.25 Delivery Data Element ......................................  133
    6.26 Delivery Note Component ....................................  135
    6.27 Payment Method Information Component .......................  137
    6.28 Status Component ...........................................  137
    6.29 Inquiry Type Component .....................................  142



Surendra Reddy et al.                                           [Page 4]


Internet Draft                  IOTP/1.0              September 21, 1998


    6.30 Signature Component ........................................  143
    6.31 Offer Response Signature Component .........................  144
    6.32 Payment Receipt Signature Component ........................  145
    6.33 Ping Signature Components ..................................  145
    6.34 Error Component ............................................  145
    6.35 Error Processing Guidelines ................................  148
    6.36 Error Codes ................................................  149
    6.37 Error Location Element .....................................  153

  7 IOTP Error Handling .............................................  154
    7.1 Technical Errors ............................................  155
    7.2 Business Errors .............................................  155
    7.3 Error Depth .................................................  156
    7.4 Idempotency, Processing Sequence, and Message Flow ..........  158
    7.5 Client Role Processing Sequence .............................  163

  8 Retrieving Logos ................................................  166
    8.1 Logo Size ...................................................  167
    8.2 Logo Color Depth ............................................  167
    8.3 Logo Net Location Examples ..................................  168

  9 Security Considerations .........................................  168
    9.1 Digital Signatures and IOTP .................................  168
    9.2 IOTP Signature Example ......................................  169
    9.3 SignerOrgRef and VerifierOrgRef Attributes ..................  169
    9.4 Symmetric and Asymmetric Cryptography .......................  170
    9.5 Mandatory and Optional Signatures ...........................  170
    9.6 Using signatures to Prove Actions Complete
        Successfully ................................................  171
    9.7 Check the Action Request was sent to the Correct
        Organization ................................................  173
    9.8 Check the Correct Components are present in the
        Request Block ...............................................  175
    9.9 Check an Action is Authorised ...............................  175
    9.10 Data Integrity and Privacy .................................  177

  10 Internationalization ...........................................  178

  11 IANA Considerations ............................................  178

  12 Copyrights .....................................................  178

  13 References .....................................................  179

  14 Appendices .....................................................  181
     14.1 IOTP DTD Specification ....................................  181

  15 Author's Address ...............................................  191



Surendra Reddy et al.                                           [Page 5]


Internet Draft                  IOTP/1.0              September 21, 1998


1.  Introduction

1.1.  Commerce on the Internet - a Different Model

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

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

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



Surendra Reddy et al.                                           [Page 6]


Internet Draft                  IOTP/1.0              September 21, 1998


      but may in fact have very high value. Or, maybe the value is
      not  high,  but  once  delivery  occurs  the  value  is
      irretrievably  delivered  so  payment  must  be  final  and
      non-refundable  but  delivery  nonetheless  must  still  be
      confirmed  before  payment.  Incremental  delivery  such  as
      listening or viewing time or playing time are other models
      that operate somewhat differently in the virtual world.

1.2.  What is IOTP?

  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 main goal of IOTP is 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 goal of the IOTP effort is to define 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.


1.3.  Benefits of IOTP
  1.   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.

  2.   IOTP provides a standard framework for encapsulating payment
       protocols. This means that it is easier for payment products



Surendra Reddy et al.                                           [Page 7]


Internet Draft                  IOTP/1.0              September 21, 1998


       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.

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

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

       o providing customer care for merchants

       o fees from processing new payments and deposits

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

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



Surendra Reddy et al.                                           [Page 8]


Internet Draft                  IOTP/1.0              September 21, 1998


         for  example,  to  feed  into  accounting  systems  or,
         potentially, to present to the tax authorities

1.4.  Terminology

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

  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

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

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

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

  Payment Instrument Customer Care Provider
       The entity that resolves problems with a particular Payment
       Instrument

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

       o a credit card such as MasterCard or Visa;

       o a debit card such as MasterCard's Maestro;

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

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

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



Surendra Reddy et al.                                           [Page 9]


Internet Draft                  IOTP/1.0              September 21, 1998


  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
         organisation uses their own brand in conjunction with,
         typically, a payment association Brand.


  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.

  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:




Surendra Reddy et al.                                          [Page 10]


Internet Draft                  IOTP/1.0              September 21, 1998


       o at the time of purchase. For example if a Consumer pays
         with a "Walmart MasterCard" at a Walmart web site, then a
         5%  discount  might  apply,  which  means  the  consumer
         actually pays less,

       o from their Payment Instrument (card) issuer when the
         payment appears on their statement. For example loyalty
         points in a frequent flyer scheme could be awarded based
         on the total payments made with the Payment Instrument
         since the last statement was issued.

       each Promotional Brand should be identified as a separate
       Brand in the list of Brands offered by the Merchant. For
       example:  "Walmart",  "Sears",  "Marks  and  Spencer"  and
       "American Advantage Visa", would each be a separate Brand.

1.5.  IOTP - Abstract Model
  The Internet Open Trading Protocol is described as a set of IOTP
  messages trasnferred between the Trading Roles. The IOTP message is
  a collection of IOTP Trading Blocks which carries the specification
  Trading Transaction. Following sections describe each component
  in detail:

1.5.1.  Trading Roles:
  Trading Roles identify the different parts which organizations
  can participate in trade. There are five trading roles: Consumer,
  Merchant, Payment Handler, Delivery Handler, Merchant Customer
  Care Provider and Payment Instrument Customer Care Provider. A
  Trading Role (OTR) performs a trading transactions using a IOTP
  USER AGENT (OUA). A OUA uses the IOTP Transport-Independent
  Interoperability Protocol (IOTP) to deliver Trading Components to
  a Trading Role.

1.5.2.  IOTP Messages

  IOTP messages are well formed XML document sent between the IOTP
  trading roles that are taking part in a trade.

1.5.3.  Trading Transactions
  A predefined set of IOTP Messages exchanged between the Trading
  Roles  constitute  an  IOTP  Transaction.

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



Surendra Reddy et al.                                          [Page 11]


Internet Draft                  IOTP/1.0              September 21, 1998


1.5.5.  Trading Components
  Trading Components are collections of property values.  Trading
  Components are the child elements of the Trading Blocks.

1.5.6.  Properties
  Properties are attributes of a Trading Component. They consist of
  a  name  and  a  value.  Properties  are  strongly  typed.  Some
  properties are multi-valued.

1.6.  Interoperability Model
  There are two distinct protocols relevant to interoperability: an
  "Application  Protocol"  and  a  "Transport  Protocol".  The
  Application Protocol defines the content of the IOTP objects sent
  between Trading Roles. The Transport Protocol defines how the IOTP
  objects are sent between the sender and reciver. This document
  focuses on the Application Protocol. Binding documents such as
  [IOTP/HTTP] focus on the Transport Protocol.

1.7.  Document Framework
  Internet Open Trading Protocol is contained in a series of
  related  documents.  This  section  describes  the  relationship
  between the documents.


1.7.1.  IOTP - Core Object Specification and Transport Independent
Trading Protocol
  The IOTP, this document, is the dictionary Trading Blocks, Trading
  Components and Transactions for Internet Trading protocol. It provides
  the authoritative definition of all properties that may be used in
  the Internet Open Trading protocols as well as the rules for
  encoding  and  representing  the  trading  objects  that  are
  constructed from those properties. This document also specifies
  how different systems use Trading Components to interoperate with
  other systems. It does so in a general way so as to allow
  multiple methods of communication between systems.


1.7.2.  IOTP/HTTP: Binding of IOTP to HTTP
  This document specifies an IOTP protocol over HTTP.

1.8.  Document Scope
  The Internet Open Trading Protocol (IOTP) is an application-level
  protocol to provide an interoperable framework for Internet
  commerce. The first version of  IOTP, referred to as IOTP/1.0,
  is a simple protocol  for  exchanging  IOTP  messages  between
  trading  roles participating in e-commerce over the Internet.

  This  specification  defines  the  protocol  referred  to  as



Surendra Reddy et al.                                          [Page 12]


Internet Draft                  IOTP/1.0              September 21, 1998


  "IOTP/1.0". This 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.

  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.

  Payment Scheme which IOTP could support include MasterCard Credit,
  Visa  Credit,  Mondex  Cash,  Visa  Cash,  GeldKarte,  DigiCash,
  CyberCoin, Millicent, Proton etc. Each  payment  scheme  contains
  some  message  flows  which  are specific to that scheme. These
  scheme-specific parts of the protocol are contained in a set of
  payment scheme supplements to this specification.

  The document does not prescribe the software and processes that
  will need to be implemented by each participant. It does describe
  the framework necessary for trading to take place.

  This document also does not address any legal or regulatory
  issues surrounding the implementation of the protocol or the
  information systems which use them.


1.9.  Requirements

  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL
  NOT,  SHOULD,  SHOULD  NOT,  RECOMMENDED,  MAY,  and
  OPTIONAL in this document are to be interpreted as described in
  RFC 2119.

  An implementation is not compliant if it fails to satisfy one or
  more of the MUST requirements for the protocols it implements. An
  implementation that satisfies all the MUST and all the SHOULD
  requirements for its protocols is said to be unconditionally
  compliant; one that satisfies all the MUST requirements but not
  all the SHOULD requirements for its protocols is said to be
  conditionally compliant.


2.  Internet Open Trading Protocol





Surendra Reddy et al.                                          [Page 13]


Internet Draft                  IOTP/1.0              September 21, 1998


2.1.  Introduction

  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.

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

    - Purchase. This supports a purchase involving an offer, a
      payment and optionally a delivery
    - Refund. This supports the refund of a payment as a result
      of, typically, an earlier purchase
    - Value Exchange. This involves two payments which result in
      the exchange of value from one combination of currency and
      payment method to another
    - Authentication. This supports the remote authentication of a
      Consumer  by  another  Trading  Role  using  a  variety  of
      authentication methods, and the provision of an Organisation
      Component about a Consumer to another Trading Role for use
      in, for example the creation of an offer
    - Withdrawal. This supports the withdrawal of electronic cash
      from a financial institution



Surendra Reddy et al.                                          [Page 14]


Internet Draft                  IOTP/1.0              September 21, 1998


    - Deposit. This supports the deposit of electronic cash at a
      financial institution
    - Payment  Instrument  Customer  Care.  This  supports  the
      provision  of  Payment  Brand  or  Payment  Method  specific
      customer care of a Payment Instrument
    - Inquiry This supports inquiries on the status of an IOTP
      transaction which is either in progress or is complete
    - 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:

    - a number organisations playing a Trading Role, and
    - a set of Trading Exchanges. Each Trading Exchange involves
      the exchange of data, between Trading Roles, in the form of
      a set of Trading Components.

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


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

    - Consumer
    - Merchant
    - Payment Handler
    - Delivery Handler
    - Merchant Customer Care Provider
    - Payment Instrument Customer Care Provider

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

    - 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
    - at the other extreme, a merchant could handle the purchase
      but instruct the consumer to pay a bank or financial



Surendra Reddy et al.                                          [Page 15]


Internet Draft                  IOTP/1.0              September 21, 1998


      institution, request that delivery be made by an overnight
      courier firm and to contact an organisation which provides
      24x7 service if problems arise.

  Note that in this specification, unless stated to the contrary,
  when the words Consumer, Merchant, Payment Handler, Delivery
  Handler or Customer Care Provider are used, they refer to the
  Trading Role rather than an actual organisation.

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

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


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

    - 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
    - Payment. The Payment Exchange results in a payment of some
      kind between the Consumer and the Payment Handler. This may
      occur in either direction
    - Delivery. The Delivery Exchange transmits either the on-line
      goods, or delivery information about physical goods from the
      Delivery Handler to the Consumer, and
    - 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



Surendra Reddy et al.                                          [Page 16]


Internet Draft                  IOTP/1.0              September 21, 1998


  minimised  by  packing  the  Components  from  several  Trading
  Exchanges into combination IOTP Messages.  For example,  the IOTP
  Purchase transaction combines a Delivery Organisation Component
  with an Offer Response Component in order to avoid an extra
  Consumer request and response.

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


2.4.  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 explained
  through following steps:

    - Consumer  decides  to  pay  (request  an  offer)  and  sends
      information on what to purchase to the merchant
    - Merchant checks the information provided by the Consumer,
      creates an Offer and sends it to the Consumer
    - Consumer  checks  the  information  from  the  merchant  and
      decides whether to continue

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

    - the  Organisation  Component  contains  information  which
      describes the organisations which are taking a role in the
      trade:
    - the consumer provides information, about who the consumer is
      and, if goods or services are being delivered, where the
      goods or services are to be delivered to
    - the  merchant  augments  this  information  by  providing
      information about the merchant, the Payment Handler, the
      customer care provider and, if goods or services are being
      delivered, the Delivery Handler
    - 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
    - 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



Surendra Reddy et al.                                          [Page 17]


Internet Draft                  IOTP/1.0              September 21, 1998


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

    - low value purchases may not need a signature
    - the amount to be paid may vary depending on the payment
      brand and payment protocol used
    - some offers may not involve the delivery of any goods
    - a value exchange will involve two payments
    - a merchant may not offer customer care.

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

    - using [HTML] pages as part of the "shopping experience" of
      the consumer.
    - using the Open Profiling Standard [OPS] which has recently
      been  proposed,  in  the  form  of  Organisation  and  Order
      Components in a later version of IOTP.

2.5.  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 decides to trade and sends information on what to
      purchase to the merchant
    - Merchant decides which payment brand and payment protocols



Surendra Reddy et al.                                          [Page 18]


Internet Draft                  IOTP/1.0              September 21, 1998


      to offer, places them in a Brand List Component and sends
      them to the Consumer
    - Consumer selects the payment brand and protocol to use,
      creates a Brand Selection Component and sends it to the
      Merchant
    - Merchant checks Brand  Selection, creates Payment Amount
      information, optionally signs it to authorize payment and
      sends it to the Consumer
    - Consumer checks the Payment Amount information and if OK
      requests that the payment starts by sending information to
      the Payment Handler
    - Payment  Handler  checks  information  including  optional
      signature and if OK starts exchanging Pay Scheme Component
      using  messages  for  selected  payment  brand  and  payment
      protocol
    - When payment protocol messages are finished Payment Hander
      sends Pay Receipt and optional signature to Consumer as
      proof of payment
    - Consumer checks if Pay Receipt is OK

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

    - The Brand List Component contains a list of payment brands
      (for  example,  MasterCard,  Visa,  Mondex,  GeldKarte)  and
      payment protocols (for example SET Version 1.0, Secure
      Channel Credit Debit (SCCD - the name used for a credit or
      debit card payment where unauthorised access to account
      information is prevented through use of secure channel
      transport mechanisms such as SSL). The Merchant sends the
      Brand List to the Consumer. The consumer compares the
      payment brands and protocols on offer with those that the
      Consumer supports and makes a selection.
    - The  Brand  Selection  Component  contains  the  Consumer's
      selection. Payment brand, protocol and possibly protocol-
      specific information is sent back to the Merchant. This
      information may be used to change information in the Offer
      Exchange. For example, a merchant could choose to offer a
      discount to encourage the use of a store card.
    - The Organisation Components are generated by the Merchant.
      They contain details of the Merchant and Payment Handler
      Roles:

       o 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



Surendra Reddy et al.                                          [Page 19]


Internet Draft                  IOTP/1.0              September 21, 1998


         credit or debit transaction to the Merchant's account
         held by the Payment Handler. These transactions are
         outside the scope of IOTP

       o 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

    - The  optional  Authentication  Data  Component  contains
      challenge data which is used by the payment protocol to
      authenticate the consumer. Authentication may not always
      occur
    - The Payment Component contains details of how much to pay,
      the currency and the payment direction, and identifies the
      Authentication Data Component to use.
    - 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.
    - The Payment Scheme Component contains messages from the
      payment protocol used in the Trade. For example they could
      be SET messages, Mondex messages, GeldKarte Messages or one
      of the other payment methods supported by IOTP. The content
      of  the  Payment  Scheme  Component  is  defined  in  the
      supplements that describe how IOTP works with various payment
      protocols.
    - The Payment Receipt Component contains a record of the
      payment. The content depends upon the payment protocol used.
    - The "Payment Receipt" Signature Component provides proof of
      payment  by  digitally  signing  both  the  Payment  Receipt
      Component and the Offer Signature. The signature on the
      offer digitally signs the Order, Organisation and Delivery
      Components  contained  in  the  Offer.  This  signature
      effectively binds the payment to the offer.
  The example of a Payment Exchange above is the most general case.
  Simpler cases are also possible. For example, if the amount paid
  is not dependent on the payment brand and protocol selected then
  the payment information generated can be sent to the Consumer at
  the same time as the Brand List Component generated. These and
  other variations are described in the Baseline Purchase IOTP
  Transaction (see section 5.20).


2.6.  Delivery Exchange

  The goal of the Delivery Exchange is to cause purchased goods to
  be delivered to the consumer either online or via physical



Surendra Reddy et al.                                          [Page 20]


Internet Draft                  IOTP/1.0              September 21, 1998


  delivery. A second goal is to provide a "delivery note" to the
  consumer, providing details about the delivery, such as shipping
  tracking number. A future goal is to have a signed delivery that
  can be used for customer care in the case of problems with
  physical delivery. This is illustrated in the diagram below.

    - Consumer decides to trade and sends information about what
      to deliver and who is to take delivery, to the merchant
    - Merchant checks the information provided by the Consumer,
      adds  information  about  how  the  delivery  will  occur,
      information about the organizations involved in the delivery
      and optionally signs it
    - Consumer checks the delivery information is OK, obtains
      authorization  for  delivery(for  example,  by  making  a
      payment), and sends the delivery information to the Delivery
      Handler
    - Delivery  Handler  checks  information  and  authorization,
      starts or schedule delivery and creates and then sends
      Delievery Note to the Consumer
    - Consumer checks delivery note is OK and accepts or waits for
      delivery as described in the Delivery Note


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

  The Organisation Component(s) contain details of the Deliver
  To, Delivery Handler and Merchant Roles:
    - the Deliver To role indicates where the goods or services
      are to be delivered to
    - the Delivery Handler role is required so that the Delivery
      Handler can check that she is the correct Delivery Handler
      to do the delivery
    - the Merchant role is required so that the Delivery Handler
      can identify which Merchant initiated the delivery
    - The Order Component, contains information about the goods or
      services to be delivered
    - The  Delivery  Component  contains  information  about  how
      delivery will occur, for example by post or using e-mail.
    - The  "Offer  Response"  Signature  Component,  if  present,
      digitally signs all of the above components to ensure their
      integrity.
    - 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
    - The  Delivery  Note  Component  contains  customer  care



Surendra Reddy et al.                                          [Page 21]


Internet Draft                  IOTP/1.0              September 21, 1998


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

2.7.  Authentication Exchange

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

    - First organization send a request for authentication to the
      second organization
    - The  Second  organization  generates  Authentication  Data
      containing challenge data and the method of authentication
      to be used and then sends it to the first organization
    - The first organization uses the challenge data with the
      specified   authentication   method   to   generate   an
      Authentication Response which is sent back to the second
      organization
    - The Authentication Response is checked against the challenge
      data to check that the first organization is who they appear
      to be.

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

    - the  Authentication  Data  Component  which  contains  the
      challenge  data  to  be  used  in  the  "challenge-response"
      mechanism and indicates the authentication method to be
      used. It is sent by one organisation to the other.
    - the Authentication Response Component which contains the
      challenge  response  generated  by  the  recipient  of  the
      Authentication Data Component. It is sent back to the first
      organisation for verification.

2.8.  Brands and Brand Selection

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



Surendra Reddy et al.                                          [Page 22]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  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:

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

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

2.8.1.  Identifying Promotional Brands

  There are two problems which need to handled in identifying
  Promotional Brands:

    - how does the Merchant or their Payment Handler positively
      identify the promotional brand being used at the time of
      purchase
    - 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.


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

    - 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
    - use  the  Payment  Instrument  (card)  number  to  look  up



Surendra Reddy et al.                                          [Page 23]


Internet Draft                  IOTP/1.0              September 21, 1998


      information  about  the  Payment  Instrument  on  a  Payment
      Instrument issuer database to determine if the Payment
      Instrument is a promotional brand
  Note that:

    - the first assumes that SET is available.
    - 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:

    - the  Merchant  would  have  to  assume  that  the  Payment
      Instrument selected was a valid Promotional Brand, or
    - 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.


2.8.3.  Consumer Selection of Promotional Brands
  Two ways by which a Consumer can correctly select a Promotional
  Brand are:

    - the Consumer visually matching a logo for the Promotional
      Brand which has been provided to the Consumer by the
      Merchant,
    - 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:

    - 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,
    - using some information contained in the software or other
      data associated with the Payment Instrument. This could be:

       o a SET certificate for Brands which use this payment



Surendra Reddy et al.                                          [Page 24]


Internet Draft                  IOTP/1.0              September 21, 1998


         method

       o a code provided by the payment software which handles the
         particular payment method, this could apply to, for
         example, GeldKarte, Mondex, CyberCash and DigiCash

    - the consumer making a initial "manual" link between a
      Promotional Brand in the list of Brands offered by the
      Merchant and an individual Payment Instrument, the first
      time  the  promotional  brand  is  used.  The  IOTP  Aware
      application  would  then  "remember"  the  code  for  the
      Promotional Brand for use in future purchases

  Note:  It  is  not  the  intention  of  the  developers  of  this
  specification to develop a prescriptive list of payment brands.

  It is anticipated that owners of brands will develop distinctive
  names  for  Brands  which  should  mean  that  name  clashes  are
  unlikely.


3.  IOTP Elements

  This section describes:

    - 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,
    - how IOTP Messages are exchanged between Trading Roles to
      create an IOTP Transaction
    - 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
    - the definitions of the XML ID Attributes which are used to
      identify IOTP Messages, Trading Blocks and Trading Components
      and how these are referred to using Element References from
      other XML elements such as
    - IOTP  Signature  Components  which  use  digital  signature
      techniques to preserve the integrity of IOTP Messages and
      provide the trust relationships required by IOTP
    - how extra XML Elements and new user defined values for
      existing IOTP codes can be used when Extending IOTP, and
      finally

3.1.  IOTP Message Structure

  The structure of an IOTP Message and its relationship with Trading
  Blocks and Trading Components is illustrated in the diagram



Surendra Reddy et al.                                          [Page 25]


Internet Draft                  IOTP/1.0              September 21, 1998


  below.


  IOTP Message
      |
      |
      +--------- Trans Ref Block
      |                |
      |                +- Tran Id Comp
      |                +- Msg Id Comp
      |                .
      +--------- Signature Block
      |                +- Signature
      |                +- Certificate
      |                .
      |                .
      +--------- Trading Block
      |                +- Component
      |                +- Component
      |                .
      |                .
      +--------- Trading Block
      |                +- Component
      |                +- Component
      .                .
      .                .
      .                .

                        IOTP Message Structure


  IOTP Message is  an XML document which is transported between the
  trading roles.

  Transaction Reference Block describes the IOTP transaction and IOTP
  message.

  Transaction Id Component uniquely identifies the IOTP transaction

  Message Id Component identifies and describes an IOTP message
  within an IOTP transaction

  Signature Block is optional and if present it contains one or
  more Signature Components and their associated certificates

  Trading Block is an XML element within an IOTP message that
  contains a predefined set of Trading Components




Surendra Reddy et al.                                          [Page 26]


Internet Draft                  IOTP/1.0              September 21, 1998


  Trading Components are XML elements within an IOTP message and
  contains  a  predefined  set  of  XML  elements  and  attributes
  containing information required to support trading exchange.

  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.6)
  which  is  unique  within  an  IOTP  Transaction.  Therefore  the
  combination  of  the  ID  attribute  and  the  globally  unique
  identifier in the Transaction Reference Block is sufficient to
  uniquely identify any Trading Block or Trading Component.


3.2.  IOTP Transactions

  A predefined set of IOTP Messages exchanged between the Trading
  Roles  constitute  an  IOTP  Transaction.  IOTP  Messages  can  be
  transported using a variety of transport mechanisms.

  The IOTP Transactions  in this version of IOTP are specifically:

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

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

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

    Authentication. This supports the remote authentication of a
       Consumer  by  another  Trading  Role  using  a  variety  of
       authentication methods, and the provision of an Organisation
       Component about a Consumer to another Trading Role for use
       in, for example the creation of an offer

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

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

    Payment Instrument Customer Care. This supports the provision
       of Payment Brand or Payment Method specific customer care of
       a Payment Instrument




Surendra Reddy et al.                                          [Page 27]


Internet Draft                  IOTP/1.0              September 21, 1998


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

    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.3.  IOTP Message

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

  The XML definition of an IOTP Message is as follows.

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

  Content:

  TransRefBlk        This contains information which describes an
                     IOTP Message within an IOTP Transaction (see
                     section 3.5 immediately below)

  AuthReqBlk, AuthRespBlk, DeliveryReqBlk, DeliveryRespBlk, ErrorBlk
  InquiryReqBlk, InquiryRespBlk, OfferRespBlk, PayExchBlk, PayReqBlk,
  PayInstCCExchBlk, PayInstCCReqBlk, PayInstCCRespBlk PayRespBlk,
  PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk




Surendra Reddy et al.                                          [Page 28]


Internet Draft                  IOTP/1.0              September 21, 1998


3.4.  XML Document Prolog

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

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


3.5.  Transaction Reference Block

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

    - 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,
    - 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
    - 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.6 ID Attributes).

  Content:

  TransId            See   3.5.1   Transaction   Id   Component
                     immediately below.

  MsgId              See 3.5.2 Message Id Component immediately



Surendra Reddy et al.                                          [Page 29]


Internet Draft                  IOTP/1.0              September 21, 1998


                     below.

  RelatedTo          See 3.5.3 Related To Component immediately
                     below.

3.5.1.  Transaction Id Component

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

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

  Attributes:

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

  Version            This identifies the version of IOTP, and
                     therefore the structure of the IOTP Messages,
                     which the IOTP Transaction is using.

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

  OtpTransType       This is the type of IOTP Transaction being
                     carried out. For Baseline IOTP it identifies
                     a "standard" IOTP Transaction and implies the
                     sequence and content of the IOTP Messages
                     exchanged between the Trading Roles. The
                     valid values for Baseline IOTP are:

                     BaselineAuthentication
                     BaselineDeposit
                     BaselinePurchase
                     BaselineRefund
                     BaselineWithdrawal
                     BaselineValueExchange
                     BaselineInquiry
                     BaselinePing
                     BaselinePayInstrumentCustomerCare



Surendra Reddy et al.                                          [Page 30]


Internet Draft                  IOTP/1.0              September 21, 1998


                     x-ddd:nnn

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

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

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

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

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

3.5.2.  Message Id Component

  The Message Id Component provides control information about the
  IOTP Message as well as uniquely identifying the IOTP Message
  within an IOTP Transaction. Its definition is as follows.

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

  ID                 An identifier which uniquely identifies the
                     IOTP Message within the IOTP Transaction (see
                     section 3.6 ID Attributes). Note that if an
                     IOTP Message is resent then the value of this



Surendra Reddy et al.                                          [Page 31]


Internet Draft                  IOTP/1.0              September 21, 1998


                     attribute remains the same.

  RespOtpMsg         This  contains  the  ID  attribute  of  the
                     Message Id Component of the IOTP Message to
                     which this IOTP Message is a response. In
                     this way all the IOTP Messages in an IOTP
                     Transaction   are   unambiguously   linked
                     together. This field is required on every
                     IOTP Message except the first IOTP Message in
                     an IOTP Transaction.

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

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

                     the name of the software manufacturer
                     the name of the software
                     the version of the software, and
                     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.5.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



Surendra Reddy et al.                                          [Page 32]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

                     OtpTransaction. in which case the Packaged
                     Content Element contains an OtpTransId of
                     another IOTP Transaction
                     Reference in which case the Packaged Content
                     Element  contains  the  reference  of  some
                     other, non-IOTP document.
                     x-ddd:nnn a user defined code (see section
                     3.9.3)

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

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

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



Surendra Reddy et al.                                          [Page 33]


Internet Draft                  IOTP/1.0              September 21, 1998


                     should contain in the Relation attribute
                     words  such  as  "refund  for"  rather  than
                     "refund to" or just "refund".

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

  Content:

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


3.6.  ID Attributes

  IOTP Messages, Blocks (i.e. Transaction Reference Blocks and
  Trading Blocks) and Trading Components (including the Transaction
  Id Component and the Signature Component) are each given an XML
  "ID" attribute which is used to identify an instance of these XML
  elements. These identifiers are used so that one element can be
  referenced  by  another.  All  these  attributes  are  given  the
  attribute name ID.

  The values of each ID attribute are unique within an IOTP
  transaction i.e. the set of IOTP Messages which have the same
  globally unique Transaction ID Component. This means that 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.7).

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


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



Surendra Reddy et al.                                          [Page 34]


Internet Draft                  IOTP/1.0              September 21, 1998


  follows:

  OtpMsgId_value  ::= OtpMsgIdPrefix OtpMsgIdSuffix
  OtpMsgIdPrefix  ::= NameChar (NameChar)*
  OtpMsgIdSuffix  ::= Digit (Digit)*

  OtpMsgIdPrefix   Apart from messages which contain an Inquiry
                    Request Trading Block (see section 4.14), the
                    same prefix is used for all messages sent by
                    the Merchant or Consumer role as follows:

                    "M" Merchant
                    "C" Consumer

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

                    The prefix for the other roles in a trade is
                    contained within the Organisation Component
                    for the role and are typically set by the
                    Merchant. The following is recommended as a
                    guideline and must not be relied upon:

                    "P" - First (only) Payment Handler
                    "R" - Second Payment Handler
                    "D" - Delivery Handler

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

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

  OtpMsgIdSuffix   The suffix consists of one or more digits. The
                    suffix must be unique within a Trading Role
                    within an IOTP Transaction. The following is
                    recommended as a guideline and must not be
                    relied upon:

                    the first IOTP Message sent by a trading role
                    is given the suffix "1"
                    the second and subsequent IOTP Messages sent by
                    the same trading role are incremented by one
                    for each message
                    no leading zeroes are included in the suffix

                    Put more simply the Message Id Component of



Surendra Reddy et al.                                          [Page 35]


Internet Draft                  IOTP/1.0              September 21, 1998


                    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.6.2.  Block and Component ID Attribute Definitions

  The ID Attribute of Blocks and Components must also be unique
  within an IOTP Transaction. Their definition is as follows:

  BlkOrCompId_value ::= OtpMsgId "." IdSuffix
  IdSuffix ::= Digit (Digit)*

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

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

  IdSuffix           The suffix consists of one or more digits.
                     The suffix must be unique within the ID
                     attribute of the Message ID Component used
                     to generate the ID attribute. The following
                     is recommended as a guideline and must not
                     be relied upon:

                     the first Block or Component sent by a
                     trading role is given the suffix "1"
                     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
                     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]



Surendra Reddy et al.                                          [Page 36]


Internet Draft                  IOTP/1.0              September 21, 1998


                     definition of Digit.


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

    - identifying an XML element whose hash value is included in a
      Signature Component,
    - 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:
    - belongs to the same IOTP Transaction (i.e. the Transaction Id
      Components of the IOTP Messages match), and
    - where the value of the ID attribute of the element matches
      the value of the Element Reference.


3.8.  Packaged Content Element

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

    - to  encapsulate  payment  scheme  messages,  such  as  SET
      messages,
    - to encapsulate a description of an order.

  In general it is used to encapsulate any data stream.

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

  <!ELEMENT PackagedContent (#PCDATA)>
  <!ATTLIST PackagedContent



Surendra Reddy et al.                                          [Page 37]


Internet Draft                  IOTP/1.0              September 21, 1998


    Content         NMTOKEN"PCDATA"
    Transform (NONE|BASE64)     "NONE" >

  Attributes:

  Content            This  identifies  what  type  of  data  is
                     contained within the Content of the Packaged
                     Content Element. The valid values for the
                     Content attribute are as follows:

                     PCDATA.The content of the Packaged Content
                     Element can be treated as PCDATA with no
                     further processing.
                     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.
                     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.
                     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.
                     x-ddd:usercode.  The  content  is  private,
                     where ddd represents a domain name of a
                     user, and usercode represents a particular
                     content format defined by that user. The
                     guidelines around a x-ddd are very loose.
                     Given   company   FFGGHH   Inc.,   all   of
                     x-www.ffgghh.com,    x-ffgghh.comand    and
                     x-ffgghh are legitimate examples. However,
                     only one should be the correct format, as
                     defined by FFGGHH Inc.

  Transform          This identifies the transformation that has
                     been done to the data before it was placed



Surendra Reddy et al.                                          [Page 38]


Internet Draft                  IOTP/1.0              September 21, 1998


                     in the content. Valid values are:

                     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.
                     BASE64. The PCDATA content of the Packaged
                     Content Element represents a BASE64 encoding
                     of the actual content.
  Content:

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

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

3.9.  Extending IOTP

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

  o extra XML elements, and

  o new user-defined values for existing IOTP codes.


3.9.1.  Extra XML Elements

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

  Extra XML elements may be included at any level within an IOTP
  message including:

    - new Trading Blocks
    - new Trading Components



Surendra Reddy et al.                                          [Page 39]


Internet Draft                  IOTP/1.0              September 21, 1998


    - new XML elements within a Trading Component.

  The following rules apply:

    - any new XML element must be declared according to the rules
      for [XML Namespaces]. This means that:

       o the namespace must be declared to the XML parser

       o each element must have a start and end tags which conform
         to the rules for XML Namespaces

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

    - if an extra XML element has an "Otp:Critical" attribute with
      a value of "True" and an IOTP aware application does not know
      how to process the element and its child elements, then the
      IOTP transaction must fail. See section 6.34 Error Component.
    - if an extra XML element has an "Otp: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:

       o 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

       o the content of the extra element must be ignored except
         that it must be included when it is hashed as part of the
         generation of a signature

    - if an extra XML element has no "Otp:Critical" attribute then
      it must be treated as if it had an "Otp:Critical" attribute
      with a value of "True"
    - if an XML element contains an "Otp:Critical" attribute, then



Surendra Reddy et al.                                          [Page 40]


Internet Draft                  IOTP/1.0              September 21, 1998


      the value of that attribute is assumed to apply to all the
      child elements within that element


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

  Otp:Critical(True | False ) #IMPLIED


3.9.2.  Opaque Embedded Data

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

3.9.3.  User Defined Codes

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

  The definition of a user defined code is as follows:

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

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

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

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


3.10.  Identifying Languages

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




Surendra Reddy et al.                                          [Page 41]


Internet Draft                  IOTP/1.0              September 21, 1998


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

    - 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
    - an optional xml:lang attribute is included on child elements
      of these Trading Components. In this case the value of
      xml:lang, if present, overrides the value for the Trading
      Component.

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


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

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

  Where both types of net location are present, the following rules
  apply:

    - either a Secure Net Location or an Insecure Net Location or
      both must be present
    - if only one of the two Net Locations is present, then the
      one present must be used
    - if both are present, then the either may be used depending
      on preference the preference of the sender of the message.


4.  Internet Open Trading Protocol Transactions
  The Baseline Internet Open Trading Protocol supports the following
  types of Baseline IOTP Transactions:

    - Authentication
    - Deposit
    - Purchase
    - Refund
    - Withdrawal
    - Baseline Value Exchange



Surendra Reddy et al.                                          [Page 42]


Internet Draft                  IOTP/1.0              September 21, 1998


    - Payment Instrument Customer Care
    - Transaction Status Inquiry, and
    - Ping
  Each of these transactions are described in more detail in the
  following sections providing descriptions of:

    - the Trading Blocks in each IOTP Transaction
    - the Trading Components in each Trading Block, and
    - how the Trading Components are signed

  Note: There are many similarities between the transactions within
  IOTP. This is because there is a lot of reuse of the Trading
  Blocks between the different transactions.
  This means that there should be significant opportunity for
  software re-use. For example, from an IOTP perspective, the
  Deposit, Refund and Withdrawal transactions are essentially the
  same, although the processing which will occur, especially at the
  server end, will differ.

4.1.  Baseline Authentication IOTP Transaction

  The Baseline Authentication IOTP Transaction supports:

    - the remote authentication of a Consumer by another Trading
      Role using a variety of authentication methods, and
    - the provision of Organization Component about a Consumer to
      another Trading Role.
  Typical use includes:

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

       o set up a secure channel (e.g. using SSL) with a customer

       o authenticate   the   customer   using   the   Baseline
         Authentication IOTP Transaction, and then

       o provide the customer with access to account information
         and other services with the confidence that they are
         communicating with a bona fide customer.

    - as a means of providing a Merchant role with Organization
      Components  that  contain  information  about  Consumer  and
      DelivTo Trading Roles.

  1.   The Baseline Authentication IOTP Transaction consists of just
       the  Authentication  Trading  Exchange.The  Authentication



Surendra Reddy et al.                                          [Page 43]


Internet Draft                  IOTP/1.0              September 21, 1998


       Exchange consists of a set of predefined IOTP Messages  which
       are exchanged between the Trading Roles.

  2.   OUA initiates the IOTP transaction using out-of-band process.

  3.   OTR SHALL send an Authentication Request Block containing
       challenge data and authentication method along with the TPO
       Block.

  4.   Trading Protocol Options Block MUST contain one Protocol
       Options Component which defines the options which apply to
       the whole IOTP Transaction. Authentication Request Block MUST
       contain one Authentication Data Component (see section 6.2)

  5.   OUA  uses  the  challenge  data,  authentication  method  to
       generate Authentication Response Block. OUA MAY store all or
       partial information on IOTP transaction for record keeping
       purposes.

  6.   OUA  SHALL  send  Authentication  Response  to  the  OTR.
       Authentication   Response   Block   MUST   contain   one
       Authentication Response Component (see section 6.3).

  7.   OTR SHALL checks the Authentication Response against the
       challenge data and authentication method to verify the
       validity of the OUA identity.

  8.   There are no variations of the Baseline Authentication IOTP
       Transaction.

4.2.  Baseline Deposit IOTP Transaction

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

  The Baseline Deposit IOTP Transaction occurs in two basic forms:

    - Baseline Deposit with Authentication. Where the Consumer
      making the deposit is authenticated before the deposit is
      made, and
    - Baseline Deposit without Authentication. Where the Consumer
      is not authenticated before the deposit is made.

4.2.1.  Baseline Desposit with Authentication

  1.   OUA sends information about how much to deposit, the brand
       to be used etc. to the OTR using out-of-band process.




Surendra Reddy et al.                                          [Page 44]


Internet Draft                  IOTP/1.0              September 21, 1998


  2.   OTR sets the payment brand, protocol to offer and generates
       the  Authentication  Request  and  sends  to  OUA.  Trading
       Protocol Options Block MUST contain one Protocol Options
       Component which defines the options which apply to the whole
       IOTP Transaction and one Brand List Component(see section
       6.12)  which contains the payment brand and protocols which
       may  be  selected  for  use  in  the  Payment  Exchange.
       Authentication Request Block MUST contain one Authentication
       Data Component (see section 6.2).

  3.   OUA selects the payment protocol to use, records selection
       in Brand Selection Component, generates an Authentication
       Response Block and sends back to the OTR. TPO Selection
       Block  MUST  contain  one  Brand  Selection  Component  (see
       section 6.17) for use in the Payment Exchange. It contains
       the results of the consumer selecting a Payment Brand and
       Payment Protocol from the list provided in the Brand List
       Component. Authentication Response Block MUST contain one
       Authentication Response Component (see section 6.3).

  4.   OTR checks the Authentication Response against the challenge
       data and authentication method to validate the OUA identity.

  5.   On  successful  authentication,  OTR  SHALL  generate  Offer
       Response Block containing information about the deposit. OTR
       MAY optionally include the Signature Block and sends it to
       the OUA. Offer Response Block MUST contain:

       o zero or one Authentication Data Component (see section
         6.2) An Authentication Data Component is required for
         each  Payment  Exchange,  where  its  Payment  Component
         contains an AuthDataRef attribute

       o one Order Component (see section 6.4) which contains
         details about the deposit, for example the amount of
         value being deposited and any fees which might apply

       o one Payment Component (see section 6.21) which contains
         information about the payment which is to be made

       o Organization  Components  (see  section  6.7)  with  the
         following roles:

         * the Merchant who is accepting the deposit

         * the Consumer who is making the deposit

         * the PaymentHandler for the payment. The "ID" of the



Surendra Reddy et al.                                          [Page 45]


Internet Draft                  IOTP/1.0              September 21, 1998


            Payment Handler Organization Component is contained
            within the VaOrgRef attribute of the Payment Component
            (see section 6.21)

       o one  Delivery  Component  (see  section  6.24)  with  the
         DelivExch attribute set to False.

  6.   If the Offer Response is being digitally signed then a
       Signature Block MUST be included in the same IOTP message
       that contains an "Offer Response" Signature Component (see
       section 6.30). The Signature Component contains hashes of
       the following XML elements:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Offer
         Response Block within the IOTP Transaction. It contains
         information that identifies the IOTP Message and IOTP
         Transaction

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

       o the Authentication Data Component if present, the Order
         Component, the Payment Component, all the Organization
         Components present, andthe Delivery Component of the
         Offer Response Block

       o the  Protocol  Options  Component,  and  the  Brand  List
         Component of the TPO Block.

       o the  Brand  Selection  Component  contained  in  the  TPO
         Selection Block.

  7.   OUA checks if Offer is OK, combines components from the TPO
       Block, the TPO Selection Block and the Offer Response Block
       to create the Payment Request Block and sends it to the
       Payment Handler with the Signature Block if it present. The
       Payment Request Block (see section 5.6) MUSTcontains:

       o the following components copied from the Offer Response
         Block:

         * the Authentication Data Component if present

         * the Payment Component

         * the Organization Components with the roles of: Merchant
           and PaymentHandler



Surendra Reddy et al.                                          [Page 46]


Internet Draft                  IOTP/1.0              September 21, 1998


       o the  following component from the TPO Block:

         * the Brand List Component

       o one Brand Selection Component either:

         * copied from the Offer Response Block if the deposit is
           a Baseline Deposit with Authentication, or

         * created by the Consumer, containing the payment brand
            and payment protocol selected, if the deposit is a
            Baseline Deposit without Authentication

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required by the payment method used (see the Payment
         Method supplement to determine if this is needed).

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

  9.   Payment Handlers SHOULD check that they are authorised to
       carry   out   the   Payment   (see   section   9   Security
       Considerations).  Payment  Handler  starts  exchanging  the
       payment  protocol  messages,  encapsulated  in  the  Payment
       Exchange Block. On successful completion of payment protocol
       messages, Payment Handler creates Payment Response Block
       with an optional Signature Block and sends it to the OUA.The
       Payment Exchange Block (see section 5.7) MUST contain one
       Payment Scheme Component (see section 6.22) which contains
       payment  method  specific  data.  See  the  Payment  Method
       supplement for the payment method being used to determine
       what this should contain. The Payment Response Block (see
       section 5.8) MUST contain

       o one Payment Receipt Component(see section 6.23) which
         contains scheme specific data which can be used to verify
         the payment occurred

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required which contains payment method specific data. See
         the Payment Method supplement for the payment method
         being used to determine what this should contain

       o the "Offer Response" Signature Component (see section
         6.30) from the Payment Request Block if present.




Surendra Reddy et al.                                          [Page 47]


Internet Draft                  IOTP/1.0              September 21, 1998


  10.  If a signed Payment Receipt is being provided, indicated by
       the SignedPayReceipt attribute of the Payment Component of
       the Offer Response Block being set to True, then the IOTP
       Message that contains the Payment Response Block must also
       contain a Signature Block with a "Payment Receipt" Signature
       Component which contains hashes of the following:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Payment
         Response Block,

       o the Transaction Id Component (see section 3.5.1) within
         the Transaction Reference Block that globally uniquely
         identifies the IOTP Transaction,

       o the Payment Receipt Component from the Payment Response
         Block and

       o the "Offer Response" Signature Component from the Payment
         Request Block if present.

  11.  OUA checks Payment Response is OK. OUA MAY store information
       on IOTP transaction for record keeping purposes.


4.2.2.  Baseline Deposit Without Authentication

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

  The Baseline Deposit without authentication 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
      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.

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



Surendra Reddy et al.                                          [Page 48]


Internet Draft                  IOTP/1.0              September 21, 1998


4.3.  Baseline Purchase IOTP Transaction

  The Baseline Purchase IOTP Transaction supports the purchase of
  goods or services using any payment method. The Baseline Purchase
  IOTP Transaction occurs in two basic forms:

    - Brand Dependent Purchase. Where the content of the offer,
      e.g. the order details, amount, delivery details, etc., are
      dependent on the payment brand and protocol selected by the
      consumer, and
    - Brand Independent Purchase. Where the content of the offer
      is not dependent on the payment brand and protocol selected.
  Further variation is supported in that:

    - the Delivery Exchange is optional, and
    - the Delivery Response Block may be sent to the consumer
      either:

       o at the same time as the Payment Response Block, or

       o after the Payment Response Block as the result of the
         Consumer sending the Delivery Handler a Delivery Request
         Block.

4.3.1.  Brand Dependent Purchases

  1.   In a Brand Dependent Purchase the TPO Block and the Offer
       Response Block MUST BE sent separately by the Merchant to
       the Consumer, i.e.:

       o the Brand List Component is sent to the Consumer in a TPO
         Block,

       o the Consumer selects a Payment Brand, Payment Protocol
         and optionally a Currency and amount from the Brand List
         Component

       o the Consumer sends the selected brand, protocol and
         currency/amount back to the Merchant in a TPO Selection
         Block, and

       o the Merchant uses the information received to define the
         content of and then send the Offer Response Block to the
         Consumer.

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



Surendra Reddy et al.                                          [Page 49]


Internet Draft                  IOTP/1.0              September 21, 1998


       Transaction.

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

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

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


4.3.2.  Combining Delivery Response Block and Payment Response Block

  1.   The Delivery Response Block and the Payment Response Block
       may be sent:

       o separately by the Payment Handler to the Consumer, i.e.:

         * the Payment Response Block containing a Payment Receipt
            and optional signature for the payment is sent by the
            Payment Handler to the Consumer,

         * the Consumer combines these components from the Payment
            Response Block with components from the Offer Response
            Block, to create a Delivery Request Block

         * the Consumer sends the Delivery Request Block to the
            Delivery Handler

         * the Delivery Handler processes the Delivery Request
            Block and sends a Delivery Response Block back to the
            Consumer, or

       o together, from the Payment Handler to the Consumer, when
         the Payment Exchange is complete.

  2.   The Delivery Response Block and the Payment Response Block
       are sent to the Consumer in separate IOTP Messages.



Surendra Reddy et al.                                          [Page 50]


Internet Draft                  IOTP/1.0              September 21, 1998


  3.   The Delivery Response Block and the Payment Response Block
       may be combined into the same IOTP Message only if the
       Payment Handler has the information available so that she
       can send the Delivery Response Block. This is likely to, but
       will not necessarily, occur when the Merchant, the Payment
       Handler and the Delivery Handler Roles are combined. The
       DelivAndPayResp attribute of the Delivery Component (see
       section 6.24) contained within the Offer Response Block (see
       section 5.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.

4.3.3.  Optional Delivery Exchange

  The final variation of the Baseline Purchase IOTP Transactions is
  a purchase without a delivery. The DelivExch attribute of the
  Delivery Component (see section 6.24) contained in the Offer
  Response Block (see section 5.3) is set to False if the Delivery
  Exchange is omitted and is set to True if the Delivery Exchange
  is included.


4.3.4.  Baseline Purchase Transaction

  1.   OUA  starts  the  IOTP  Purchase  Transaction  by  sending
       information about what to purchase using the out-of-band
       process.

  2.   OTR(Merchant) decides which payment brand and protocols to
       offer,    places  them  in  the  TPO  Block  and  sends  to
       OUA(Consumer).The Error! Reference source not found. (see
       section Error! Reference source not found.) MUST contain:

       o one Protocol Options Component which defines the options
         which apply to the whole IOTP Transaction. See Section
         6.1.

       o one  Brand  List  Component  (see  section  6.12)  which
         contains one or more payment brands and protocols which
         may be selected for use in the Payment Exchange.

  3.   OUA selects the payment brand and payment protocol and
       records the selection in a TPO Selection Block and sends
       back to the OTR(Merchant).The TPO Selection Block (see
       section 5.2) is only used by Brand Dependent Purchase. It
       MUST contain one Brand Selection Component (see section



Surendra Reddy et al.                                          [Page 51]


Internet Draft                  IOTP/1.0              September 21, 1998


       6.17) for use in the Payment Exchange. It contains the
       results of the consumer selecting a Payment Brand and
       Payment Protocol from the list provided in the Brand List
       Component.

  4.   The OTR(Merchant) uses payment brand and protocol selected
       and information on what being purchased to create an Offer
       Response Block containing details about goods ordered, price
       etc and MAY optionally include Signature Block and sends it
       to OUA(Consumer).The Offer Response Block (see section 5.3)
       MUST contain:

       o zero or one Authentication Data Component (see section
         6.2) An Authentication Data Component is required for
         each Payment Exchange, where its Payment Component (see
         section 6.21) contains an AuthDataRef attribute.

       o one Order Component (see section 6.4) which contains
         details  about  the  goods,  services  which  are  being
         purchased

       o one Payment Component (see section 6.21) which contains
         information about the payment which is to be made

       o Organization  Components  (see  section  6.7)  with  the
         following roles:

         * Merchant who is providing the goods or services

         * Consumer who is making the purchase

         * PaymentHandler for the payment. The "ID" of the Payment
            Handler Organization Component is contained within the
            VaOrgRef attribute of the Payment Component

       o one Delivery Component (see section 6.24) which contains
         details of the delivery to be made.

  5.   If the Baseline Purchase includes a Delivery Exchange then
       the Offer Response Block MUST also contain Organization
       Components with the following roles:

       o DeliveryHandler who will be delivering the goods or
         services

       o DelivTo i.e. the person or Organization which is to take
         delivery




Surendra Reddy et al.                                          [Page 52]


Internet Draft                  IOTP/1.0              September 21, 1998


  6.   If the Baseline Purchase Offer Response is being digitally
       signed then a Signature Block MUST BE included in the same
       IOTP message that contains an "Offer Response" Signature
       Component (see section 6.30). The Signature Component MUST
       contain hashes of the following XML elements:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Offer
         Response Block within the IOTP Transaction. It contains
         information that identifies the IOTP Message and IOTP
         Transaction

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

       o the following components of the Offer Response Block:

         * the Authentication Data Component if present

         * the Order Component

         * the Payment Component

         * all the Organization Components present, and

         * the Delivery Component,

       o the following components of the TPO Block :

         * the Protocol Options Component, and

         * the Brand List Component

       o If the Baseline Purchase is a Brand Dependent Purchase
         then the Signature Component additionally contains a hash
         of the following:

         * the Brand Selection Component contained in the TPO
            Selection Block.

  7.   OUA(Consumer) checks Offer is OK, combines components from
       the TPO Block, TPO Selection Block and ther Offer Response
       Block to create a Payment Request Block and sends it back to
       the Payment Handler together with the Signature Block if
       present. The Payment Request Block (see section 5.6) MUST
       contain:

       o the following components copied from the Offer Response



Surendra Reddy et al.                                          [Page 53]


Internet Draft                  IOTP/1.0              September 21, 1998


         Block:

         * the Authentication Data Component if present

         * the Payment Component

         * the Organization Components with the roles of: Merchant
            and PaymentHandler

       o the  following component from the TPO Block:

         * the Brand List Component

       o one Brand Selection Component either:

         * copied from the Offer Response Block if the purchase is
            a Brand Dependent Purchase, or

         * created by the Consumer, containing the payment brand
            and payment protocol selected, if the purchase is a
            Brand Independent Purchase

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required by the payment method used (see the Payment
         Method supplement to determine if this is needed).

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

  9.   The Payment Exchange Block (see section 5.7) MUST contain
       one  Payment  Scheme  Component  (see  section  6.22)  which
       contains payment method specific data. See the Payment
       Method supplement for the payment method being used to
       determine what this should contain.

  10.  Payment Handlers SHOULD check that they are authorised to
       carry   out   the   Payment   (see   section   9   Security
       Considerations). Payment Handler checks optional signature,
       processes  Payment  Request  Block  and  starts  exchanging
       payment  protocol  messages,  encapsulated  in  a  Payment
       Exchange  Block  with  the  OUA(Consumer).  On  successful
       completion of the payment protocol messages, Payment Handler
       creates   Payment   Response   Block   and   send   to   the
       OUA(Consumer).The Payment Response Block (see section 5.8)
       MUST contain:




Surendra Reddy et al.                                          [Page 54]


Internet Draft                  IOTP/1.0              September 21, 1998


       o one  Payment  Receipt  Component  (see  section)  which
         contains scheme specific data which can be used to verify
         the payment occurred

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required which contains payment method specific data. See
         the Payment Method supplement for the payment method
         being used to determine what this should contain

       o the "Offer Response" Signature Component (see section
         6.30) from the Payment Request Block if present.


  11.  If a signed Payment Receipt is being provided, indicated by
       the SignedPayReceipt attribute of the Payment Component of
       the Offer Response Block being set to True, then the IOTP
       Message that contains the Payment Response Block must also
       contain a Signature Block with a "Payment Receipt" Signature
       Component which contains hashes of the following:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Payment
         Response Block,

       o the Transaction Id Component (see section 3.5.1) within
         the Transaction Reference Block that globally uniquely
         identifies the IOTP Transaction,

       o the Payment Receipt Component from the Payment Response
         Block and

       o the "Offer Response" Signature Component from the Payment
         Request Block if present.

  12.  OUA(Consumer checks Payment Response is OK and creates a
       Delivery Request from Payment Response Block, Offer Response
       Block and Signature Block, if present, and sends to the
       Delivert Handler. The Delivery Request Block (see section
       5.9) MUSTcontain:

       o the following components copied from the Offer Response
         Block:

         * the Order Component (see section 6.4)

         * the Organization Component (see section 6.7) with the
            roles of: Merchant, DeliveryHandler and DeliverTo




Surendra Reddy et al.                                          [Page 55]


Internet Draft                  IOTP/1.0              September 21, 1998


         * the Delivery Component (see section 6.24)

  13.  Delivery Handler checks Payment Receipt, Order in Offer
       Response and the optional signatures, creates a Delivery
       Response Block, sends it to OUA(Consumer). The Delivery
       Response Block MUST contain one Delivery Note Component (see
       section 6.26) which contains delivery instructions about the
       delivery of goods or services

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

  If the Baseline Purchase Offer Response or Payment Response
  Blocks were signed then the IOTP Message that contains the
  Delivery Request Block MUST also contain a Signature Block with a
  copy of:

    - the "Offer Response" Signature Component if present, and/or
    - the "Payment Receipt" Signature Component, if present

4.4.  Baseline Refund IOTP Transaction

  In business terms the refund process typically consists of:

    - a request for a refund being made by the Consumer to the
      Merchant, typically supported by evidence to demonstrate:

       o the original trade took place, for example by providing a
         receipt for the original transaction

       o 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

       o the reason why the merchant should make the refund

    - the merchant agreeing (or not) to the refund. This may
      involve  some  negotiation  between  the  Consumer  and  the
      Merchant, and, if the merchant agrees,
    - a refund payment by the Merchant to the Consumer.

  The Baseline Refund IOTP Transaction supports a subset of the
  above, specifically it supports:

    - the  optional  authentication  of  the  Consumer  using  an
      Authentication Exchange (see section 2.7), and
    - the refund payment by the Merchant to the Consumer using the



Surendra Reddy et al.                                          [Page 56]


Internet Draft                  IOTP/1.0              September 21, 1998


      following two Trading Exchanges:

       o an Offer Exchange (see section 2.4), and

       o a Payment Exchange (see section 2.5).

  The Baseline Refund IOTP Transaction occurs in two basic forms:

    - Baseline Refund with Authentication. Where the Consumer
      requesting the refund is authenticated before the refund is
      made, and

    - Baseline Refund without Authentication. Where the Consumer
      is not authenticated before the refund is made.

4.4.1.  Baseline Refund with Authentication

  In Baseline Refund with Authentication an Authentication Exchange
  occurs before the Offer Exchange containing the details of the
  refund is provided by the Merchant.

  Following sequences of messages are exchanged between the trading
  roles for refund transaction:

  1.    OUA(Consumer) requests payment of previously agreed refund,
        sends information about refund, such as a reference number to
        the OTR(Merchant) using out-of-band process.

  2.    The OTR(Merchant) sets the payment brand and decided which
        protocol to offer in TPO Block, generates an Authentication
        Request Block containing challenge data and the authentication
        method and sends it to the Consumer. The  TPO Block  must
        contain:
        - one Protocol Options Component which defines the options
          which apply to the whole IOTP Transaction. See Section 6.1.
        - one Brand List Component (see section 6.12) which contains
          the payment brand and protocols which may be selected for
          use in the Payment Exchange.

        The Authentication Request Block (see section 5.4) MUST contain
        one Authentication Data Component (see section 6.2)

  3.    IOTP aware applications supporting the Consumer Trading Role must
        check for the existence of an Authentication Request Block in the
        first IOTP Message to determine whether the Baseline Refund
        includes an Authentication Exchange or not. The Consumer selects
        payment protocol to use, records selection in a Brand Selection
        Component, generates an Authentication Response Block and sends



Surendra Reddy et al.                                          [Page 57]


Internet Draft                  IOTP/1.0              September 21, 1998


        them back to the Merchant. The TPO Selection Block (see section 5.2)
        MUST contain:

        - one Brand Selection Component (see section 6.17) for use in
          the  Payment  Exchange.  It  contains  the  results  of  the
          consumer selecting a Payment Brand and Payment Protocol from
          the list provided in the Brand List Component.

        The Authentication Response Block (see section 5.5) MUST contain
        one Authentication Response Component (see section 6.3).

  4.    The OTR(Merchant) checks the Authentication Response against the
        challenge data and authentication method, based on the Consumer
        identity and refund information generates the Offer Response Block
        containing the information about the refund and optional Signature
        Block and sends them to the Consumer.  The Offer Response Block
        (see section 5.3) MUST contain:

        - zero or one Authentication Data Component (see section 6.2)
          An  Authentication  Data  Component  is  required  for  each
          Payment Exchange, where its Payment Component  contains an
          AuthDataRef attribute

        - one Order Component (see section 6.4) which contains details
          about the refund, for example the amount being refunded and
          any conditions which might apply
        - one Payment Component  (see section 5.2) which contains
          information about the payment which is to be made
        - Organization Components (see section 6.7) with the following
          roles:

                o the Merchant who is making the refund

                o the Consumer who is requesting the refund

                o the PaymentHandler for the payment. The "ID" of the
                  Payment  Handler  Organization  Component  is  contained
                  within the VaOrgRef attribute of the Payment Component

        - one Delivery Component (see section 6.24) with the DelivExch
          attribute set to False.

  5.    If the Baseline Refund Offer Response is being digitally signed
        then a Signature Block must be included in the same IOTP message
        that  contains  an  "Offer  Response"  Signature  Component  (see
        section 6.30). The Signature Component contains hashes of the
        following XML elements:




Surendra Reddy et al.                                          [Page 58]


Internet Draft                  IOTP/1.0              September 21, 1998


        - the Transaction Reference Block (see section 3.5) for the
          IOTP Message which contains the first usage of the Offer
          Response Block within the IOTP Transaction. It contains
          information  that  identifies  the  IOTP  Message  and  IOTP
          Transaction
        - the Transaction Id Component (see section 3.5.1) which
          globally uniquely identifies the IOTP Transaction
        - the following components of the Offer Response Block:

                o the Authentication Data Component if present

                o the Order Component

                o the Payment Component

                o all the Organization Components present, and

                o the Delivery Component,

        - the following components of the TPO Block :

                o the Protocol Options Component, and

                o the Brand List Component

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

  6.    OUA(Consumer) checks Offer is OK, combines components from
        the TPO Block, the TPO Selection Block and the Offer Response
        Block to create a Payment Request Block and sends to the
        Payment Handler together with the optional Signature Block.
        The Payment Request Block (see section 5.6) MUST contain:

        - the following components copied from the Offer Response
          Block:

                o the Authentication Data Component if present

                o the Payment Component

                o the Organization Components with the roles of: Merchant
                  and PaymentHandler

        - the  following component from the TPO Block:



Surendra Reddy et al.                                          [Page 59]


Internet Draft                  IOTP/1.0              September 21, 1998


                o the Brand List Component

        - one Brand Selection Component either:

                o copied from the Offer Response Block if the refund is a
                  Baseline Refund with Authentication, or

                o created by the Consumer, containing the payment brand and
                  payment protocol selected, if the refund is a Baseline
                  Refund with Authentication

        - one Payment Scheme Component (see section 6.22) if required
          by  the  payment  method  used  (see  the  Payment  Method
          supplement to determine if this is needed).


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

  8.    Payment Handlers should check that they are authorised to carry
        out the Payment (see section 9 Security Considerations). Payment
        Handler checks signature(if present), process Pay Request Block,
        starts payment protocol message exchanges with the Consumer.
        The Payment Exchange Block (see section 5.7) MUST contain one
        Payment  Scheme  Component  (see  section  6.22)  which  contains
        payment method specific data. See the Payment Method supplement
        for the payment method being used to determine what this should
        contain.

  9.    On successful completion of the payment protocol messages creates a
        Pay Receipt component inside Pay Response Block, sends to the
        Consumer with the optional Signature Block. The Payment Response
        Block (see section 5.8) contains:

        - one Payment Receipt Component (see section 6.23) which
          contains scheme specific data which can be used to verify
          the payment occurred
        - one Payment Scheme Component (see section 6.22) 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
        - the "Offer Response" Signature Component (see section 6.30)
          from the Payment Request Block if present.

 10.    If a signed Payment Receipt is being provided, indicated by the
        SignedPayReceipt attribute of the Payment Component of the Offer



Surendra Reddy et al.                                          [Page 60]


Internet Draft                  IOTP/1.0              September 21, 1998


        Response Block being set to True, then the IOTP Message that
        contains the Payment Response Block must also contain a Signature
        Block with a "Payment Receipt" Signature Component which contains
        hashes of the following:

        - the Transaction Reference Block (see section 3.5) for the
          IOTP Message which contains the first usage of the Payment
          Response Block,
        - the Transaction Id Component (see section 3.5.1) within the
          Transaction   Reference   Block   that   globally   uniquely
          identifies the IOTP Transaction,
        - the Payment Receipt Component from the Payment Response
          Block and
        - the "Offer Response" Signature Component from the Payment
          Request Block if present.

 11.    Consumer checks Pay Response is OK. OUA MAY optionally keep
        all information related to the transaction for record keeping
        purposes.

4.4.2.  Baseline Refund without Authentication
  In  Baseline  Refund  without  Authentication,  there  is  no
  Authentication Exchange and the Merchant provides details about
  the refund immediately at the start of the IOTP Transaction.

  The Baseline Refund without authentication might be used:

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


4.5.  Baseline Withdrawal IOTP Transaction

  The Baseline Withdrawal IOTP Transaction supports the withdrawal
  of electronic cash from a Financial Institution.

  Note: The Financial Institution has, in IOTP terminology, a role
  of merchant in that a service (i.e. a withdrawal of electronic
  cash) is being offered in return for a fee, for example bank
  charges of some kind. The term "Financial Institution" is used in



Surendra Reddy et al.                                          [Page 61]


Internet Draft                  IOTP/1.0              September 21, 1998


  the diagrams and in the text for clarity.

  The Baseline Withdrawal IOTP Transaction occurs in two basic
  forms:

    - Baseline Withdrawal with Authentication. Where the Consumer
      making the withdrawal is authenticated before the withdrawal
      is made, and
    - Baseline  Withdrawal  without  Authentication.  Where  the
      Consumer is not authenticated before the withdrawal is made.

4.5.1.  Baseline Withdrawal with Authentication

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

  Following sequences of messages are exchanged between the Consumer
  and the financial institution(OTR) for withdrawl transaction:

  1.    OUA(Consumer) decides to withdraw electronic cash and sends
        information about hoe much to withdraw to the OTR(Financial
        Institution playing a merchant role) using out-of-band process.

  2.    The OTR(Financial Institution) sets the payment brand and decided
        which protocol to offer in TPO Block, generates an Authentication
        Request Block containing challenge data and the authentication
        method and sends it to the Consumer. The  TPO Block  must
        contain:
        - one Protocol Options Component which defines the options
          which apply to the whole IOTP Transaction. See Section 6.1.
        - one Brand List Component (see section 6.12) which contains
          the payment brand and protocols which may be selected for
          use in the Payment Exchange.

        The Authentication Request Block (see section 5.4) MUST contain
        one Authentication Data Component (see section 6.2)

  3.    IOTP aware applications supporting the Consumer Trading Role must
        check for the existence of an Authentication Request Block in the
        first IOTP Message to determine whether the Baseline Withdrawal
        includes an Authentication Exchange or not. The Consumer selects
        payment protocol to use, records selection in a Brand Selection
        Component, generates an Authentication Response Block and sends
        them back to the Financial Institution. The TPO Selection Block
        (see section 5.2) MUST contain:

        - one Brand Selection Component (see section 6.17) for use in



Surendra Reddy et al.                                          [Page 62]


Internet Draft                  IOTP/1.0              September 21, 1998


          the  Payment  Exchange.  It  contains  the  results  of  the
          consumer selecting a Payment Brand and Payment Protocol from
          the list provided in the Brand List Component.

        The Authentication Response Block (see section 5.5) MUST contain
        one Authentication Response Component (see section 6.3).

  4.    The OTR(Financial Institution) checks the Authentication Response
        against the challenge data and authentication method, based on the
        Consumer identity and refund information generates the Offer
        Response Block containing the information about the withdrawal and
        optional Signature Block and sends them to the Consumer.
        The Offer Response Block (see section 5.3) MUST contain:

        - zero or one Authentication Data Component (see section 6.2)
          An  Authentication  Data  Component  is  required  for  each
          Payment Exchange, where its Payment Component  contains an
          AuthDataRef attribute

        - one Order Component (see section 6.4) which contains details
          about the refund, for example the amount being withdrawn and
          any conditions which might apply
        - one Payment Component  (see section 5.2) which contains
          information about the payment which is to be made
        - Organization Components (see section 6.7) with the following
          roles:

                o the Merchant who is making the refund

                o the Consumer who is requesting the refund

                o the PaymentHandler for the payment. The "ID" of the
                  Payment  Handler  Organization  Component  is  contained
                  within the VaOrgRef attribute of the Payment Component

        - one Delivery Component (see section 6.24) with the DelivExch
          attribute set to False.

  5.    If the Baseline Withdrawal Offer Response is being digitally signed
        then a Signature Block must be included in the same IOTP message
        that  contains  an  "Offer  Response"  Signature  Component  (see
        section 6.30). The Signature Component contains hashes of the
        following XML elements:

        - the Transaction Reference Block (see section 3.5) for the
          IOTP Message which contains the first usage of the Offer
          Response Block within the IOTP Transaction. It contains
          information  that  identifies  the  IOTP  Message  and  IOTP



Surendra Reddy et al.                                          [Page 63]


Internet Draft                  IOTP/1.0              September 21, 1998


          Transaction
        - the Transaction Id Component (see section 3.5.1) which
          globally uniquely identifies the IOTP Transaction
        - the following components of the Offer Response Block:

                o the Authentication Data Component if present

                o the Order Component

                o the Payment Component

                o all the Organization Components present, and

                o the Delivery Component,

        - the following components of the TPO Block :

                o the Protocol Options Component, and

                o the Brand List Component

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

  6.    OUA(Consumer) checks Offer is OK, combines components from
        the TPO Block, the TPO Selection Block and the Offer Response
        Block to create a Payment Request Block and sends to the
        Payment Handler together with the optional Signature Block.
        The Payment Request Block (see section 5.6) MUST contain:

        - the following components copied from the Offer Response
          Block:

                o the Authentication Data Component if present

                o the Payment Component

                o the Organization Components with the roles of: Merchant
                  and PaymentHandler

        - the  following component from the TPO Block:

                o the Brand List Component

        - one Brand Selection Component either:



Surendra Reddy et al.                                          [Page 64]


Internet Draft                  IOTP/1.0              September 21, 1998


                o copied from the Offer Response Block if the refund is a
                  Baseline Refund with Authentication, or

                o created by the Consumer, containing the payment brand and
                  payment protocol selected, if the refund is a Baseline
                  Refund with Authentication

        - one Payment Scheme Component (see section 6.22) if required
          by  the  payment  method  used  (see  the  Payment  Method
          supplement to determine if this is needed).


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

  8.    Payment Handlers should check that they are authorised to carry
        out the Payment (see section 9 Security Considerations). Payment
        Handler checks signature(if present), process Pay Request Block,
        starts payment protocol message exchanges with the Consumer.
        The Payment Exchange Block (see section 5.7) MUST contain one
        Payment  Scheme  Component  (see  section  6.22)  which  contains
        payment method specific data. See the Payment Method supplement
        for the payment method being used to determine what this should
        contain.

  9.    On successful completion of the payment protocol messages creates a
        Pay Receipt component inside Pay Response Block, sends to the
        Consumer with the optional Signature Block. The Payment Response
        Block (see section 5.8) MUST contains

        - one Payment Receipt Component (see section 6.23) which
          contains scheme specific data which can be used to verify
          the payment occurred
        - one Payment Scheme Component (see section 6.22) 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
        - the "Offer Response" Signature Component (see section 6.30)
          from the Payment Request Block if present.

 10.    If a signed Payment Receipt is being provided, indicated by the
        SignedPayReceipt attribute of the Payment Component of the Offer
        Response Block being set to True, then the IOTP Message that
        contains the Payment Response Block must also contain a Signature
        Block with a "Payment Receipt" Signature Component which contains
        hashes of the following:



Surendra Reddy et al.                                          [Page 65]


Internet Draft                  IOTP/1.0              September 21, 1998


        - the Transaction Reference Block (see section 3.5) for the
          IOTP Message which contains the first usage of the Payment
          Response Block,
        - the Transaction Id Component (see section 3.5.1) within the
          Transaction   Reference   Block   that   globally   uniquely
          identifies the IOTP Transaction,
        - the Payment Receipt Component from the Payment Response
          Block and
        - the "Offer Response" Signature Component from the Payment
          Request Block if present.

 11.    Consumer checks Pay Response is OK. OUA MAY optionally keep
        all information related to the transaction for record keeping
        purposes.

  Note:

  1. The Financial Institution can offer withdrawal of several different
     types of electronic cash. In practice usually only one form of
     electronic cash may be offered. However, there may be several
     different protocols  which  may  be  used  for  the  same  "brand"
     of electronic cash

  2. The  financial  institution  may  use  the  results  of  the
     authentication to identify not only the consumer but also
     the account from which the withdrawal is to be made. If no
     single account can be identified, then it must be obtained
     by other means. For example:
     - the consumer could specify the account number in the initial
       dialogue , 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.


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

  The Baseline Withdrawal without Authentication might be used:

    - when a previous IOTP transaction, for example a Baseline
      Deposit or a Baseline Authentication, authenticated the
      consumer,  and  a  secure  channel  has  been  maintained,
      therefore the authenticity of the consumer is known



Surendra Reddy et al.                                          [Page 66]


Internet Draft                  IOTP/1.0              September 21, 1998


    - when authentication is achieved as part of a proprietary
      payment protocol and is therefore included in the Payment
      Exchange
    - when authentication of the consumer has been achieved by
      some other means, for example, by using a pass phrase, or a
      proprietary banking software solution.


4.6.  Baseline Value Exchange IOTP Transaction

  The Baseline Value Exchange Transaction uses Payment Exchanges
  (see section 2.5) 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:

    - electronic cash advance on a credit card. For example the
      first payment could be a dollar SET Payment Exchange on a
      credit  card  with  the  second  Payment  Exchange  being  a
      download of DigiCash e-cash in dollars.
    - foreign exchange using the same payment method. For example
      the payment could be an upload of Mondex value in French
      Francs and the second a download of Mondex value in British
      Pounds
    - foreign  exchange  using  different  payment  methods.  For
      example the first payment could be a SET payment in Euros
      followed a download of GeldKarte in Deutchmarks.

  The Baseline Value Exchange IOTP Transaction occurs in two basic
  forms:

    - 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
    - Brand Independent Value Exchange. Where the content of the
      offer is not dependent on the payment brands and protocols
      selected.

4.6.1.  Brand Dependent Value Exchange

  In Brand Dependent Value Exchange the TPO Block and the Offer
  Response Block are sent separately by the Merchant to the
  Consumer, i.e.:

    - the Brand List Components for the two payments are sent to
      the Consumer in a TPO Block,
    - the Consumer selects a Payment Brand and Payment Protocol



Surendra Reddy et al.                                          [Page 67]


Internet Draft                  IOTP/1.0              September 21, 1998


      from the Brand List Component for each of the payments in
      the Value Exchange
    - the Consumer sends the selected brands and protocols back to
      the Merchant in a TPO Selection Block, and
    - the Merchant Uses the information received to define the
      content of the Offer Response Block and then sends it to the
      Consumer.

  Whether or not the Value Exchange is brand dependent, the
  exchange of Trading Blocks between the Consumer and the Payment
  Handlers are the same. The following sequences of messages are
  exchanged between the Trading Roles for the Value Exchange
  Transaction:

  1.   OUA(Consumer) sends information about the value exchange to
       the OTR(Merchant) using out-of-band process.

  2.   OTR(Merchant) decides which payment brand and protocols to
       offer for each payment, places them in Brand List Components
       in a TPO Block and sends them to OUA(Consumer). The  TPO
       Block MUST contain the following Trading Components:

       o one Protocol Options Component which defines the options
         which apply to the whole IOTP Transaction. See Section
         6.1.

       o two Brand List Components (see section 6.12) one for each
         Payment Exchange where each Brand List Component contains
         one or more payment brands and protocols which may be
         selected for use in the Payment Exchange.

  3.   OUA(Consumer) selects the payment brand and payment protocol
       to  use  each  payment,  records  selections  in  two  Brand
       Selection Components in TPO Selection Block, and sends back
       to OTR(Merchant). The TPO Selection Block (see section 5.2)
       is only used by Brand Dependent Value Exchange. It contains:

       o two Brand Selection Components (see section 6.17). One
         for each of the Payment Exchanges. Each Brand Selection
         Component contains the results of the consumer selecting
         a Payment Brand and Payment Protocol from the list
         provided in the Brand List Component.

  4.   OTR(Merchant) uses payments brands and protocols selected to
       create an Offer Response Block containing details about the
       value exchange and sends it to OUA(Consumer) together with
       the optional digital signature. The Offer Response Block
       (see section 5.3) contains the following components:



Surendra Reddy et al.                                          [Page 68]


Internet Draft                  IOTP/1.0              September 21, 1998


       o zero, one or two Authentication Data Component (see
         section  6.2).  An  Authentication  Data  Component  is
         required for each Payment Exchange, where its Payment
         Component contains an AuthDataRef attribute.

       o one Order Component (see section 6.4) which contains
         details about the Value Exchange, for example, exchange
         rates, commission, etc.

       o two Payment Components (see section 6.21) which contain
         information about each of the two payments which are to
         be made

       o Organization  Components  (see  section  6.7)  with  the
         following roles:

         * Merchant who is providing the goods or services

         * Consumer who is making the purchase

         * the PaymentHandlers for the payments. The "ID" of a
            Payment Handler Organization Component is contained
            within the VaOrgRef attribute of each of the Payment
            Components

  4.   If the Baseline Value Exchange Offer Response is being
       digitally signed then a Signature Block must be included in
       the same IOTP message that contains an "Offer Response"
       Signature  Component  (see  section  6.30).  The  Signature
       Component contains hashes of the following XML elements:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Offer
         Response Block within the IOTP Transaction. It contains
         information that identifies the IOTP Message and IOTP
         Transaction

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

       o the following components of the Offer Response Block:

         * the Authentication Data Component if present

         * the Order Component

         * the two Payment Components




Surendra Reddy et al.                                          [Page 69]


Internet Draft                  IOTP/1.0              September 21, 1998


         * all the Organization Components present, and

       o the following components of the TPO Block :

         * the Protocol Options Component, and

         * the Brand List Component

       o If the Baseline Value Exchange is a Brand Dependent Value
         Exchange  then  the  Signature  Component  additionally
         contains a hash of the following:

       o the two Brand Selection Components contained in the TPO
         Selection Block.

  5.   OUA(Consumer) checks Offer is OK, combines components from
       TPO Block, TPO Selection Block and Offer Response Block to
       create a Payment Request Block for the first payment and
       sends it to the Payment Handler 1 together with the optional
       Signature Block.The Payment Request Block (see section 5.6)
       for the first payment contains:

       o the following components copied from the Offer Response
         Block:

         * the Authentication Data Component for the first payment
            if required

         * the Payment Component  for the first payment

         * the Organization Components with the roles of: Merchant
            and PaymentHandler for the first payment

       o the following component copied from the TPO Block:

         * the Brand List Component for the first payment

       o one Brand Selection Component for the first payment which
         is either:

         * copied from the Offer Response Block if the purchase is
            a Brand Dependent Value Exchange, or

         * created by the Consumer, containing the payment brand
            and payment protocol selected, if the purchase is a
            Brand Independent Value Exchange

       o one  Payment  Scheme  Component  (see  section  6.22)  if



Surendra Reddy et al.                                          [Page 70]


Internet Draft                  IOTP/1.0              September 21, 1998


         required by the payment method used (see the Payment
         Method supplement to determine if this is needed).

  6.   If the Baseline Value Exchange Offer Response Block was
       signed then the IOTP Message that contains the Payment
       Request Block for the first payment must also contain a
       Signature  Block  with  a  copy  of  the  "Offer  Response"
       Signature Component. The Payment Exchange Block (see section
       5.7) for the first payment contains:

       o one Payment Scheme Component (see section 6.22) which
         contains payment method specific data for the payment
         method being used by the first payment. See the Payment
         Method supplement for the payment method being used to
         determine what this should contain.

  7.   Payment Handler 1 processes Payment Request Block for the
       first payment and starts payment protocol messages. On
       successful completion of the payment protocol messages,
       Payment Handler creates Payment Response Block and sends it
       to the OUA(Consumer) along with the optional Signature
       Block.The Payment Response Block for the first payment (see
       section 5.8) contains:

       o one Payment Receipt Component (see section 6.23) which
         contains scheme specific data which can be used to verify
         the first payment occurred

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required by the payment method used by the first payment
         which contains payment method specific data. See the
         Payment Method supplement for the payment method being
         used to determine what this should contain

       o the Signature Component (see section 6.30) from the
         Payment Request Block for the first payment if present.

  8.   If a signed Payment Receipt is being provided for the first
       payment, indicated by the SignedPayReceipt attribute of the
       Payment  Component  for  the  first  payment  in  the  Offer
       Response Block being set to True, then the IOTP Message that
       contains the Payment Response Block for the first payment
       must also contain a Signature Block with a "Payment Receipt"
       Signature Component which contains hashes of the following:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Payment
         Response Block for the first payment,



Surendra Reddy et al.                                          [Page 71]


Internet Draft                  IOTP/1.0              September 21, 1998


       o the Transaction Id Component (see section 3.5.1) within
         the Transaction Reference Block that globally uniquely
         identifies the IOTP Transaction,

       o the Payment Receipt Component from the Payment Response
         Block for the first payment and

       o the "Offer Response" Signature Component from the Payment
         Request Block for the first payment, if present.

  9.   OUA(Consumer) checks Payment Response for first payment is
       OK and create a Payment Request for Second payment using the
       Offer Response Block along with the optional Signature Block
       and sends it to Payment Handler 2.The Payment Request Block
       (see section 5.6) for the second payment contains:

       o the following components copied from the Offer Response
         Block:

         * the  Authentication  Data  Component  for  the  second
            payment if required

         * the Payment Component  for the second payment

         * the Organization Components with the roles of: Merchant
            and PaymentHandler for the second payment

       o the following component copied from the TPO Block:

         * the Brand List Component for the second payment

       o one Brand Selection Component for the second payment
         which is either:

         * copied from the Offer Response Block if the purchase is
            a Brand Dependent Value Exchange, or

         * created by the Consumer, containing the payment brand
            and payment protocol selected, if the purchase is a
            Brand Independent Value Exchange

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required by the payment method used (see the Payment
         Method supplement to determine if this is needed)

  10.  Payment Handler 2 processes Payment Request Block for the
       second payment and starts payment protocol messages.




Surendra Reddy et al.                                          [Page 72]


Internet Draft                  IOTP/1.0              September 21, 1998


  11.  The Payment Exchange Block (see section 5.7) for the second
       payment contains:

       o one Payment Scheme Component (see section 6.22) which
         contains payment method specific data for the payment
         method being used by the second payment. See the Payment
         Method supplement for the payment method being used to
         determine what this should contain.

  12.  On successful completion of the payment protocol messages,
       Payment Handler creates Payment Response Block and sends it
       to the OUA(Consumer) along with the optional Signature
       Block.The Payment Response Block for the second payment (see
       section 5.8) contains:

       o one Payment Receipt Component (see section 6.23) which
         contains scheme specific data which can be used to verify
         the second payment occurred

       o one  Payment  Scheme  Component  (see  section  6.22)  if
         required by the payment method used by the second payment
         which contains payment method specific data. See the
         Payment Method supplement for the payment method being
         used to determine what this should contain

       o all the Signature Components (see section 6.30) from the
         Payment Request Block for the second payment if present.

  13.  If a signed Payment Receipt is being provided for the second
       payment, indicated by the SignedPayReceipt attribute of the
       Payment Component for the second payment in the Offer
       Response Block being set to True, then the IOTP Message that
       contains the Payment Response Block for the second payment
       must also contain a Signature Block with a "Payment Receipt"
       Signature Component which contains hashes of the following:

       o the Transaction Reference Block (see section 3.5) for the
         IOTP Message which contains the first usage of the Payment
         Response Block for the second payment,

       o the Transaction Id Component (see section 3.5.1) within
         the Transaction Reference Block that globally uniquely
         identifies the IOTP Transaction,

       o the Payment Receipt Component from the Payment Response
         Block for the second payment

       o the "Offer Response" Signature Component from the Payment



Surendra Reddy et al.                                          [Page 73]


Internet Draft                  IOTP/1.0              September 21, 1998


         Request Block for the second payment, if present, and

       o the  "Payment  Receipt"  Signature  Component  from  the
         Payment Request Block for the first payment, if present.

  14.  OUA(Consumer) checks Payment Response for first payment is
       OK and create a Payment Request for Second payment using the
       Offer Response Block along with the optional Signature Block
       and sends it to Payment Handler 2.

  15.  If the Baseline Value Exchange Offer Response Block or the
       Payment Response Block for the first payment was signed then
       the IOTP Message that contains the Payment Request Block for
       the second payment must also contain a Signature Block with
       a copy of:

       o the "Offer Response" Signature Component, if present,
         and/or

       o the "Payment Receipt" Signature Component copied from the
         Payment Response Block for the first payment, if present.

  16.  If signatures are used then the Payment Handlers should
       check that all Signature Components they receive are valid
       (see section 9 Security Considerations).

  Note that:

    - the Payment Component  for the first payment is the one
      within the Offer Response Block that contains no StartAfter
      attribute (see section 6.21)
    - the Authentication Data Component to include is identified
      by the AuthDataRef attribute of the Payment Component for
      the first payment. If no AuthDataRef attribute is present
      then no Authentication Data Component is required
    - the Payment Handler to include is identified by the Brand
      Selection  Component  (see  section  6.17)  for  the  first
      payment. Also see section 9.7 Check the Action Request was
      sent to the Correct Organization for an explanation on how
      Payment Handlers are identified
    - the Brand List Component to include is the one identified by
      the BrandListRef attribute of the Payment Component for the
      first payment
    - the Brand Selection Component to include from the Offer
      Response Block is the one that contains an Element Reference
      (see section 3.7) which identifies the Brand List Component
      for the first payment
    - the Payment Component  for the second payment is the one



Surendra Reddy et al.                                          [Page 74]


Internet Draft                  IOTP/1.0              September 21, 1998


      within the Offer Response Block that contains a StartAfter
      attribute (see section 6.21) that identifies the Payment
      Component for the first payment
    - the Authentication Data Component to include is identified
      by the AuthDataRef attribute of the Payment Component  for
      the second payment. If no AuthDataRef attribute is present
      then no Authentication Data Component is required
    - the Payment Handler to include is identified by the Brand
      Selection  Component  (see  section  6.17)  for  the  second
      payment. Also see section 9.7 Check the Action Request was
      sent to the Correct Organization for an explanation on how
      Payment Handlers are identified
    - the Brand List Component to include is the one identified by
      the BrandListRef attribute of the Payment Component  for the
      second payment
    - the Brand Selection Component to include from the Offer
      Response Block is the one that contains an Element Reference
      (see section 3.7) which identifies the Brand List Component
      for the second payment

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

  The TPO Block and Offer Response Block may only be combined into
  the same IOTP Message if the content of the Offer Response Block
  does not change as a result of selecting the payment brands and
  payment protocols to be used in the Value Exchange.

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

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


4.7.  Payment Instrument Customer Care IOTP Transaction

  An IOTP  Payment Instrument Customer Care Transaction is used to
  provide Payment Brand or Payment Method specific customer care.
  It allows Consumer Payment Brand software to exchange information
  with a Payment Instrument Customer Care Provider.



Surendra Reddy et al.                                          [Page 75]


Internet Draft                  IOTP/1.0              September 21, 1998


  The circumstances under which this transaction is used, if any,
  is defined in the IOTP Supplement for the Payment Brand.

  Note that the IOTP Payment Instrument Customer Care Transaction:

    - is initiated by the Consumer Payment Brand software which
      must identify the need for the transaction to occur. Note
      that in other IOTP Transactions, the transaction is initiated
      by the Merchant
    - has no TPO Block, as it is initiated by the Consumer
    - relies on the Consumer Payment Brand software to identify
      the net location of the Payment Instrument Customer Care
      Provider to which the first message in the transaction must
      be sent
    - ends  when  the  Payment  Scheme  Customer  Care  Service
      determines that the exchange of messages with the Consumer
      is to stop.

  Note that a Payment Instrument Customer Care Transaction can be
  initiated at any time by a Consumer including in the middle of
  another IOTP Transaction. In this case, the transaction shall
  establish  a  different  transport  session  from  the  ongoing
  transaction. See the Mapping to Transport for the Transport
  Mechanism being used.

  Following OTP messages are exchanged between the Payment Instrument
  User and Payment Instrument Care Provider roles:

  1.    OUA(Consumer) identifies the need to contact Payment instrument
        Care Provider and generates Payment Instrument Customer Care
        Request Block and sends it to the Customer Care Provider. OUA
        determines the Customer Care Provider by Net Location. The Payment
        Instrument Customer Care Request Block MUST contain:

        - a Payment Method Information Component (see section 6.27)
          which describes the Payment Method for which Customer Care
          is requested, and
        - zero or more optional Payment Scheme Components (see section
          6.22) which contain optional Payment scheme data

  2.    OTR(Payment Instrument Customer Care Provider) process the  Payment
        Instrument Customer Care Request Block and starts exchaging
        Payment Instrument Customer Care Exchange Block with the
        OUA(Consumer). The Payment Instrument Customer Care Exchange
        Block MUST contain:

        - a Payment Method Information Component (see section 6.27)
          which describes the Payment Method for which Customer Care



Surendra Reddy et al.                                          [Page 76]


Internet Draft                  IOTP/1.0              September 21, 1998


          is being provided, and
        - zero or more optional Payment Scheme Components (see section
          6.22) which contain optional Payment scheme data
  3.    On successful completion of the Customer Care Exchange messages,
        OTR(Payment Instrument Customer Care Provider) generates the payment
        instrument customer care response block and sends it to the OUA(
        consumer). The Payment Instrument Customer Care Response Block
        MUST contain:

        - a Payment Method Information Component (see section 6.27)
          which describes the Payment Method for which Customer Care
          is complete, and
        - zero or more optional Payment Scheme Component (see section
          6.22) which contains optional Payment scheme data

  Any of the IOTP Messages which contain Payment Instrument Customer
  care blocks may also include a Signature Block (see section 5.18)
  containing a Signature Component (see section 6.30). How these
  are used and what it signs is dependent on the Payment Brand and
  Payment method being used.


4.8.  Baseline Transaction Status Inquiry IOTP Transaction

  The Baseline IOTP Transaction Status Inquiry provides a Consumer
  with information on the status of an existing or complete IOTP
  transaction.

  The Trading Blocks used by the Baseline Transaction Status
  Inquiry Transaction are:

    - an Inquiry Request Trading Block (see section 5.14), and
    - an Inquiry Response Trading Block (see section 5.15).

  Note that:
    - Consumer Inquiries on Authentication transaction are not
      supported.
    - Authentication of Consumers as part of an inquiry is not
      supported in the Baseline version of IOTP.

4.8.1.  Which Trading Roles can receive Inquiry Requests

  The Consumer can send a Transaction Status Inquiry Block to the
  appropriate  Trading  Role  after  the  following  events  have
  occurred:

    - to the Merchant, after sending TPO Selection Block,
    - to the Payment Handler, after sending Payment Request Block,



Surendra Reddy et al.                                          [Page 77]


Internet Draft                  IOTP/1.0              September 21, 1998


    - to the Delivery Handler, after sending Delivery Request
      Block.

  Note: IOTP does not support sending Inquiry Requests to the
  Consumer since the consumer may not be on-line to receive and
  process them.

  If the Consumer is inquiring on transaction that is not yet
  complete, it should send the Inquiry Request Block to the Trading
  Role to which it sent the last IOTP message. If the Consumer is
  inquiring on a transaction which is complete, there are two
  alternatives in deciding the Trading Roles that the Inquiry
  Request Block should be sent to:

    - the Consumer IOTP software can ask the end user to determine
      the type of inquiry they want to make, or
    - the Consumer IOTP software can send the inquiry request
      message to all the Trading Roles that were involved in the
      IOTP transaction.

  For the second case above, how the Consumer IOTP Aware Application
  displays the inquiry response data received from each Trading
  Role is up to each implementation.

4.8.2.  Transaction Status Inquiry Transport Session

  For a Transaction Status Inquiry on an ongoing transaction, the
  Consumer  SHALL  establish  with  a  Trading  Role,  a  different
  transport session from the ongoing transaction. For a Transaction
  Status Inquiry on a past transaction, how the IOTP module on the
  software at the Trading Role is started upon the receipt of
  Inquiry Request message is defined in each Mapping to Transport
  supplement for IOTP.

4.8.3.  Transaction Status Inquiry Error Handling

  Errors in a Transaction Status Inquiry can be categorised into
  one the following three cases:

    - Business errors (see section 7.2) in the original (inquired)
      messages
    - Technical errors (see section 7.1) - both IOTP and payment
      scheme specific ones - in the original IOTP (inquired)
      messages
    - Technical errors in the message containing the Inquiry
      Request Block itself

  The following outlines what the software should do in each case



Surendra Reddy et al.                                          [Page 78]


Internet Draft                  IOTP/1.0              September 21, 1998


  Business errors in the original messages: Return an Inquiry Response
  Block containing the Status Component which was last sent to the Consumer.

  Technical errors in the original messages: Return an Inquiry Response
  Block containing a Status Component. The Status Component should contain
  a ProcessState attribute set to ProcessError. In this case send back an
  Error Block indicating where the error was found in the original message.

  Technical errors in the Inquiry Request Block: Return an Error message. That
  is, send back an Error Block containing the Error Code (see section 6.36)
  which describes the nature of the error in the Inquiry Request message.


4.8.4.  Inquiry Transaction Messages


  Following messages are exchanged between trading roles for
  Inquiry Transaction:

  1.    OUA(Consumer) generates  an Inquiry Request Block and sends it
        to the appropriate  trading role. The  Inquiry  Request  Block
        (see  section  5.14)  MUST contain:

        - one  Inquiry  Type  Component  (see  section  6.29).  This
          identifies whether the inquiry is on an offer, payment, or
          delivery.
        - zero or one Payment Scheme Component (see section 6.22).
          This is for encapsulating payment scheme specific inquiry
          messages for inquiries on payment.

  2.    The Consumer must use the same Transaction Id Component (see
        section 3.5.1) as in the inquired transaction. The OtpTransId
        attribute in this component serves as the key in querying the
        transaction logs maintained at the Trading Role's site. The value
        of the ID attribute of the Message Id Component should be
        different from those of the inquired transaction (see section
        3.6.1).

  3.    The OTR checks the transaction status of the transaction being
        inquired upon by using the Transaction Id component of the
        Transaction Reference Block. OTR generates the appropriate
        response block based on the status of the transaction and sends
        it back to the OUA(Consumer). The Inquiry Response Block (see
        section 5.15) MUST contain:

        - one Status Component (see section 6.28). This component hold
          the status information on the inquired transaction,
        - zero or one Payment Scheme Components. These contain for



Surendra Reddy et al.                                          [Page 79]


Internet Draft                  IOTP/1.0              September 21, 1998


          encapsulated payment scheme specific inquiry messages for
          inquiries on payment.

4.9.  Baseline Ping IOTP Transaction

  The purpose of the Baseline IOTP Ping Transaction is to enable IOTP
  aware  application  software  to  determine  if  the  IOTP  aware
  application at another Trading Role is operating and verifying
  whether or not signatures can be handled.

  The Trading Blocks used by the Baseline Ping IOTP Transaction are:

    - a Ping Request Block (see section 5.16)
    - a Ping Response Block (see section 5.17), and
    - a Signature Block (see section 5.18).

  The verification that signatures can be handled is indicated by
  the sender of the Ping Request Block including:

    - Organization  Components  that  identify  itself  and  the
      intended recipient of the Ping Request Block, and
    - a Signature Block that signs data in the Ping Request.

  In this way the receiver of the Ping Request:

    - knows who is sending the Ping Request and can therefore
      verify the Signature on the Request, and
    - knows who to generate a signature for on the Ping Response.

  Note that a Ping Request:

    - does not affect any on-going transaction
    - does NOT start an IOTP aware application, unlike other IOTP
      transaction messages such as TPO or Transaction Status
      Inquiry.

  Following sequences of messages are exchanged bewteen the tranding
  roles for the Ping transaction:

  1.    The OUA in an IOTP Trading Role decides to check whether the
        counterparty IOTP application is running or not. It generates
        a Ping Request Block with an optional Signature Block and sends
        it to the other IOTP Trading Role. If  the  Ping  Transaction
        is  anonymous  then  no  Organization Components are included
        in the Ping Request Block (see section 5.6).

  2.    If the Ping Transaction is not anonymous then the Ping Request
        Block MUST contain Organization Components for:



Surendra Reddy et al.                                          [Page 80]


Internet Draft                  IOTP/1.0              September 21, 1998


        - the sender of the Ping Request Block, and
        - the verifier of the Signature Component
        - If Organization 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.

  3.    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. The
        Ping Request Signature Block MUST contain:

        - one Signature Component(see section 6.30)
        - one or more Certificate Components, if required.

  4.    The OTR which receives the Ping Request generates a Ping Response
        and sends it back to the sender of the original Ping Request. The
        Ping Response Block (see section 5.17) MUST contain:

        - the  Organization  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 Organization Components contained in the
            Ping Request Block.

  5.    The Ping Response Signature Block (see section 5.18) MUST contain:

        - one Signature Component (see section 6.30)
        - one or more Certificate Components, if required.
  Note:
  1.    For each Baseline Ping IOTP Transaction, each IOTP role shall
        establish  a  different  transport  session  from  other  IOTP
        transactions.

  2.    Any IOTP Trading Role can send a Ping request to any other IOTP
        Trading Role at any time it wants. A Ping message has its own
        OtpTransID, which is different from other IOTP transactions.

  3.    The OtpTransId of a Ping transaction SHOULD BE different from any
        other IOTP transaction.


5.  Trading Blocks

  Trading Blocks consist of one or more Trading Components and
  optionally one or more Signature Components. One or more Trading



Surendra Reddy et al.                                          [Page 81]


Internet Draft                  IOTP/1.0              September 21, 1998


  Blocks may be contained within the IOTP Messages which are
  physically sent in the form of [XML] documents between the
  different Organizations that are taking part in a trade.

  Trading Blocks are defined as part of the definition of an IOTP
  Message (see section 3.1).

  This section describes the Trading Blocks used in this version of
  IOTP. They are:

    - Authentication Request Block
    - Authentication Response Block
    - Delivery Request Block
    - Delivery Response Block
    - Error Block
    - Inquiry Request Block
    - Inquiry Response Block
    - Offer Response Block
    - Payment Exchange Block
    - Payment Request Block
    - Payment Response Block
    - Payment Instrument Customer Care Exchange Block
    - Payment Instrument Customer Care Request Block
    - Payment Instrument Customer Care Response Block
    - Signature Block
    - Trading Protocol Options Block
    - TPO Selection Block
  The Transaction Reference Block is described in section 3.5.

5.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.6  ID
                     Attributes).

  Content:

  ProtocolOptions    The Protocol Options Component (see section



Surendra Reddy et al.                                          [Page 82]


Internet Draft                  IOTP/1.0              September 21, 1998


                     6.1)defines the options which apply to the
                     whole IOTP Transaction (see section 4).

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

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


  The TPO Block should contain:

    - the Protocol Options Component
    - the Organization Component with the Trading Role of Merchant
    - the Organization Component with the Trading Role of Consumer
    - optionally, the Organization Component with the Trading Role
      of DeliverTo, if there is a Delivery included in the IOTP
      Transaction
    - Brand  List  Components  for  each  payment  in  the  IOTP
      Transaction
    - Organization  Components  for  all  the  Payment  Handlers
      involved
    - optionally, Organization Components for the Delivery Handler
      (if any) for the transaction
    - additional Organization Components that the Merchant may
      want to include. For example

       o a Customer Care Provider
       o an   Certificate   Authority   that   offers   Merchant
         "Credentials" or some other warranty on the goods or
services being offered.

5.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 5.1).The definition of a TPO Selection Block is as
  follows.

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



Surendra Reddy et al.                                          [Page 83]


Internet Draft                  IOTP/1.0              September 21, 1998


  Attributes:

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

  Content:

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

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

5.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 (AuthData*, Order?, Payment*, Delivery?,
  Status ) >
  <!ATTLIST OfferRespBlk
    ID  ID    #REQUIRED >

  Attributes:

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

  Content:

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

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

                     The Order Component must be present unless
                     the ProcessState attribute of the Status



Surendra Reddy et al.                                          [Page 84]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Component is set to Failed.

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

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

  Status             Contains  status  information  about  the
                     business  success  (see  section  7.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.


  The Offer Response Block should contain:

    - the Order Component for the IOTP Transaction
    - Payment Components for each Payment in the IOTP Transaction
    - the Delivery Component for IOTP Transaction requires (if any)
    - the Authentication Data Component (if required) for each
      Payment

5.4.  Authentication Request Block

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

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

  Attributes

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

  Content

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



Surendra Reddy et al.                                          [Page 85]


Internet Draft                  IOTP/1.0              September 21, 1998


                     the Consumer.

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

5.5.  Authentication Response Block

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

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

  Attributes:

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

  Content:

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

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


5.6.  Payment Request Block

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

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

  Attributes:




Surendra Reddy et al.                                          [Page 86]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Content:

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

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

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

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

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

  Org                The Organization Component contains details
                     of Organizations involved in the payment
                     (see section 6.7). The Organizations present
                     are dependent on the IOTP Transaction and the
                     data which is to be signed. See section 9
                     Security Considerations for more details.

  The Payment Request Block should contain:

    - the Organization Component with a Trading Role of Merchant
    - the Organization Component with the Trading Role of Consumer
    - the Payment Component for the Payment
    - the Brand List Component for the Payment
    - the Brand Selection Component for the Brand List
    - the Organization Component for the Payment Handler of the
      Payment
    - the Organization Component (if any) for the Organization
      which carried out the previous step, for example another



Surendra Reddy et al.                                          [Page 87]


Internet Draft                  IOTP/1.0              September 21, 1998


      Payment Handler
    - the Organization Component for the Organization which is to
      carry out the next step, if any. This may be, for example,
      either a Delivery Handler or a Payment Handler.
    - the Organization Components for any additional Organizations
      that the Merchant has included in the Offer Response Block
    - an Optional Payment Scheme Data Component, if required by
      the Payment Method as defined in the IOTP supplement for the
      payment method.

5.7.  Payment Exchange Block

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

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

  Attributes:

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

  Content:

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


5.8.  Payment Response Block

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


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

  Attributes:

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



Surendra Reddy et al.                                          [Page 88]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Transaction.

  Content:

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

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

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

5.9.  Delivery Request Block

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

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

  Attributes:

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

  Content:

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

  Org                The  Organization  Components  (see  section
                     6.7) identify the Organizations and their
                     roles in the IOTP Transaction. The roles and
                     Organizations which must be present will
                     depend  on  the  particular  type  of  IOTP
                     Transaction.  See  the  definition  of  each



Surendra Reddy et al.                                          [Page 89]


Internet Draft                  IOTP/1.0              September 21, 1998


                     transaction  in  section  4.  Open  Trading
                     Protocol Transactions.

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


  The Delivery Request Block contains:

    - the Organization Component with a Trading Role of Merchant
    - the Organization Component for the Consumer and DeliverTo
      Trading Roles
    - the Delivery Component for the Delivery
    - the  Organization  Component  for  the  Delivery  Handler.
      Specifically the Organization Component identified by the
      ActionOrgRef attribute on the Delivery Component
    - the Organization Component (if any) for the Organization
      which carried out the previous step, for example a Payment
      Handler
    - the Organization Components for any additional Organizations
      that the Merchant has included in the Offer Response Block

5.10.  Delivery Response Block

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

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

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

  Content:

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




Surendra Reddy et al.                                          [Page 90]


Internet Draft                  IOTP/1.0              September 21, 1998


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

5.11.  Payment Instrument Customer Care Request Block

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

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

  Attributes:

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

  Content:

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

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

5.12.  Payment Instrument Customer Care Exchange Block

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

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



Surendra Reddy et al.                                          [Page 91]


Internet Draft                  IOTP/1.0              September 21, 1998


  Attributes:

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

  Content:

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


5.13.  Payment Instrument Customer Care Response Block

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

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

  Attributes:

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

  Content:

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

5.14.  Inquiry Request Trading Block

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



Surendra Reddy et al.                                          [Page 92]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Attributes:

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

  Content:

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

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

5.15.  Inquiry Response Trading Block

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

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

  Attributes:

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

  LastReceivedOtpMs  Contains an Element Reference (see section
  gRef               3.7)  to  the  Message  Id  Component  (see
                     section 3.5.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



Surendra Reddy et al.                                          [Page 93]


Internet Draft                  IOTP/1.0              September 21, 1998


                     purposes.

  LastSentOtpMsgRef  Contains an Element Reference (see section
                     3.7)  to  the  Message  Id  Component  (see
                     section 3.5.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  7.2)  or
                     failure of a certain trading exchange (i.e.,
                     Offer, Payment, or Delivery).

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

5.16.  Ping Request Block

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

  The definition of a Ping Request Block is as follows.

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

  Attributes:

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

  Content:

  Org                Optional   Organization   Components   (see
                     section 6.7).

                     If no Organization Component is present then



Surendra Reddy et al.                                          [Page 94]


Internet Draft                  IOTP/1.0              September 21, 1998


                     the Ping Request is anonymous and simply
                     determines if the server is operating.

                     However  if  Organization  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:

                     an Organization Component that identifies
                     itself specifying the Trading Role(s) it is
                     taking  in  IOTP  transactions  (Merchant,
                     Payment Handler, etc)
                     an Organization Component that identifies
                     the intended recipient of the message.

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

5.17.  Ping Response Block

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

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

  If the Ping Request to which this block is a response contained
  Organization Components, then it also contains those Organization
  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



Surendra Reddy et al.                                          [Page 95]


Internet Draft                  IOTP/1.0              September 21, 1998


                     messages. Valid values are:

                     Ok. Everything with the service is working
                     normally,    including    the    signature
                     verification.
                     Busy. Things are working normally but there
                     may be some delays.
                     Down. The server is not functioning fully
                     but can still provide a Ping response.

  SigVerifyStatusCo  Contains a code which shows the status of
  de                 signature verification. This is present only
                     when the message containing the Ping Request
                     Block also contains a Signature Block. Valid
                     values are:

                     Ok.  The  signature  has  successfully  been
                     verified and proved compatible.
                     NotSupported  The  receiver  of  this  Ping
                     Request Block does not support validation of
                     signatures.
                     Fail. Signature verification failed.

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

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

  Content:

  Org                These  are  Organization  Components  (see
                     section 6.7).

                     The Organization Components of the sender of
                     the Ping Response is always included in
                     addition to the Organization 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



Surendra Reddy et al.                                          [Page 96]


Internet Draft                  IOTP/1.0              September 21, 1998


  back.

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

  The definition of a Signature Block is as follows:


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

  Attributes:

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

  Content:

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

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

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

5.18.1.  Offer Response

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

5.18.2.  Payment Request

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

    - an Offer Response Signature Component (see section 6.31),



Surendra Reddy et al.                                          [Page 97]


Internet Draft                  IOTP/1.0              September 21, 1998


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

5.18.3.  Payment Response

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


5.18.4.  Delivery Request

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

    - an Offer Response Signature Component (see section 6.31),
      and
    - the Payment Receipt Signature Component (see section 6.32)
      generated by the previous step.

5.19.  Error Block

  The Error Trading Block contains one or more Error Components
  (see section 6.34) which contain information about Technical
  Errors (see section 7.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:

    - message in error. An IOTP message which contains or causes an
      error of some kind
    - message reporting the error. An IOTP message that contains an
      Error Trading Block that describes the error found in a
      message in error.
  An Error Trading Block may be contained in any message reporting
  the error. The action which then follows depends on the severity
  of the error. See the definition of an Error Component, for an
  explanation of the different types of severity and the actions
  which can then occur.

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




Surendra Reddy et al.                                          [Page 98]


Internet Draft                  IOTP/1.0              September 21, 1998


  The structure of an Error Trading Block is as follows.

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

  Attributes:

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

  Content:

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

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



6.  Trading Components

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

  The Trading Components described in this section are listed below
  in approximately the sequence they are likely to be used:

    - Protocol Options Component
    - Authentication Data Component
    - Authentication Response Component
    - Order Component
    - Organization Component
    - Brand List Component
    - Brand Selection Component
    - Payment Component
    - Payment Scheme Component
    - Payment Receipt Component
    - Delivery Component



Surendra Reddy et al.                                          [Page 99]


Internet Draft                  IOTP/1.0              September 21, 1998


    - Delivery Note Component
    - Signature Component
    - Certificate Component
    - Error Component
  Note that the following components are listed in other sections
  of this specification:

    - Transaction Id Component (see section 3.5.1)
    - Message Id Component (see section 3.5.2)

6.1.  Protocol Options Component

  Protocol options are options which apply to the IOTP Transaction
  as a whole. Essentially it is used to identify what type of IOTP
  Transaction is being carried out. For Baseline IOTP it will
  identify one of the "Baseline" IOTP Transactions (see section 4.
  Internet Open Trading Protocol Transactions) by name.

  The definition of a Protocol Options Component is as follows.

  <!ELEMENT ProtocolOptions EMPTY>
  <!ATTLIST ProtocolOptions
    ID  ID    #REQUIRED
    xml:lang  NMTOKEN     #REQUIRED
    ShortDesc CDATA #REQUIRED
    SenderNetLocn   CDATA #REQUIRED
    SecureSenderNetLocn CDATA   #REQUIRED
    SuccessNetLocn  CDATA #REQUIRED
    CancelNetLocn   CDATA #REQUIRED
    ErrorNetLocn    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.10 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.



Surendra Reddy et al.                                         [Page 100]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

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

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

  CancelNetLocn      This contains the net location that should
                     be displayed by the Consumer after the IOTP
                     Transaction has been cancelled by one of the
                     Trading Roles.

                     For  this  purpose,  cancel  is  defined  as
                     sending or receiving a Fail Trading Block
                     (see section 5) where the FailType attribute
                     of all the FailReasons in the block are set
                     to Cancel.

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



Surendra Reddy et al.                                         [Page 101]


Internet Draft                  IOTP/1.0              September 21, 1998


  ErrorNetLocn       This contains the net location that should
                     be displayed after the IOTP Transaction has
                     failed due to an error.

                     For this purpose, an error is defined as
                     sending or receiving an Error Block (see
                     section 5.23) where the Severity attribute
                     of at least one of the Error Components (see
                     section 6.34) in the Error Block is set to
                     HardError,   or   there   has   been   an
                     irrecoverable loss of communication.

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


6.2.  Authentication Data Component

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

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

  Attributes:

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

  AuthMethod        This   identifies   the   content   of   the
                     Authentication Data Component. Valid values
                     are:

                     sha1 This indicates that the recipient of
                     the  Authentication  Data  Component  should
                     generate  a  hash.  See  6.3  Authentication
                     Response Component.
                     pay:ppp   A   payment   protocol   specific
                     authentication method. The "ppp" identifies
                     a payment protocol associated with a payment
                     exchange  which  is  part  of  the  IOTP
                     Transaction. In this case the content and



Surendra Reddy et al.                                         [Page 102]


Internet Draft                  IOTP/1.0              September 21, 1998


                     format of the  AuthData element is defined
                     in   the   appropriate   Payment   Scheme
                     supplement. For example if a payment method
                     "xzpay" provided an authentication method,
                     then this attribute would have the value
                     "pay:xzpay"
                     x-ddd:nnn  a  user  defined  authentication
                     scheme type see section (3.9.3 User Defined
                     Codes).

  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:

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

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

  Content:

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


6.3.  Authentication Response Component

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

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



Surendra Reddy et al.                                         [Page 103]


Internet Draft                  IOTP/1.0              September 21, 1998


  Attributes:

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

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

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

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

  Content:

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

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


6.4.  Order Component

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


  <!ELEMENT Order (PackagedContent?) >
  <!ATTLIST Order
    ID  ID    #REQUIRED



Surendra Reddy et al.                                         [Page 104]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

  ContentSoftwareId  This contains information which identifies



Surendra Reddy et al.                                         [Page 105]


Internet Draft                  IOTP/1.0              September 21, 1998


                     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:

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

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

  Content:

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


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

  The description of the order in the Packaged Content should  not
  include currency and amount information since this is contained
  in the payment related trading components (Brand List, Brand
  Selection and Payment).

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


6.6.  OkFrom and OkTo Timestamps

  Note that:

  the OkFrom date may be later than the OkFrom date on the
  Payment Component (see section 6.21) associated with this



Surendra Reddy et al.                                         [Page 106]


Internet Draft                  IOTP/1.0              September 21, 1998


  order, and

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

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

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

  If there is to be a time-limited offer, it recommended that
  merchants communicate this to the consumer and state in the order
  description in a manner which is clear to the consumer that:
    - the offer is time limited
    - the OkFrom and OkTo timestamps specify the validity of the
      offer
    - the clock, e.g. the merchant's clock, that will be used to
      determine the validity of the offer


6.7.  Organization Component

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

    - to describe the merchant who is selling the goods,
    - to identify who made a purchase,
    - to identify who will take delivery of goods,
    - to provide a customer care contact,
    - to describe who will be the Payment Handler.

  Its definition is as follows.


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



Surendra Reddy et al.                                         [Page 107]


Internet Draft                  IOTP/1.0              September 21, 1998


    OtpMsgIdPrefix  NMTOKEN     #REQUIRED
    LegalName CDATA #IMPLIED
    ShortDesc CDATA #IMPLIED
    LogoNetLocn     CDATA #IMPLIED >

  Attributes:

  ID                 An identifier which uniquely identifies the
                     Organization  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.10 Identifying
                     Languages.

  OrgId              A code which identifies the Organization
                     described by the Organization Component. See
                     6.7.1 Organization IDs, below.

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

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

  ShortDesc          A short description of the Organization in
                     the language defined by xml:lang. It is
                     typically the name by which the Organization
                     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  Organization  from  a  list  of
                     Organizations, for example from a database
                     of    Organizations    involved    in    IOTP
                     Transactions which has been stored by a
                     consumer.




Surendra Reddy et al.                                         [Page 108]


Internet Draft                  IOTP/1.0              September 21, 1998


  LogoNetLocn        The  net  location  which  can  be  used  to
                     download the logo for the Organization. See
                     section 0.

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

  Content:

  TradingRole        See 6.8 Trading Role Element below.

  ContactInfo        See 6.9 Contact Information Element below.

  PersonName         See 6.10 Person Name below.

  PostalAddress      See 6.11 Postal Address below.


6.7.1.  Organization IDs

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

    - the Organization Id for all trading roles, apart from the
      Consumer Trading Role, uses a domain name as their globally
      unique identifier,
    - the Organization 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'
      Organization Id,
    - once a Consumer is allocated an Organization Id within an
      IOTP Transaction the same Organization Id is used by all the
      other trading roles in that IOTP transaction to identify that
      Consumer.

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

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

  ConsumerOrgId      If the Organization ID  for a Consumer



Surendra Reddy et al.                                         [Page 109]


Internet Draft                  IOTP/1.0              September 21, 1998


                     consists of:

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

                     Use of upper and lower case is significant.

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

                     Note that a NonConsumerOrgId may not start
                     with the ConsumerOrgIdPrefix.

                     Use  of  upper  and  lower  case  is  not
                     significant.

  Examples of Organization Ids follow:

  newjerseybooks.com - a merchant Organization id

  westernbank.co.uk - a payment handler Organization id

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


6.8.  Trading Role Element

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

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

  Attributes:



Surendra Reddy et al.                                         [Page 110]


Internet Draft                  IOTP/1.0              September 21, 1998


  TradingRole        The trading role of the Organization. Valid
                     values are:

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

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

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

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


6.9.  Contact Information Element

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



Surendra Reddy et al.                                         [Page 111]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Tel                A telephone number by which the Organization
                     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 Organization 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 Organization
                     may  be  contacted.  Note  that  this  field
                     should  conform  to  the  conventions  for
                     address    specifications    contained    in
                     [RFC822].

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

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


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



Surendra Reddy et al.                                         [Page 112]


Internet Draft                  IOTP/1.0              September 21, 1998


    FamilyName      CDATA #IMPLIED >

  Attributes:

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

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

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

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

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


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




Surendra Reddy et al.                                         [Page 113]


Internet Draft                  IOTP/1.0              September 21, 1998


  Attributes:

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

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

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

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

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

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

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

6.12.  Brand List Component

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

  payment Brands (see also section 2.8 Brands and Brand
  Selection),

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

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

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



Surendra Reddy et al.                                         [Page 114]


Internet Draft                  IOTP/1.0              September 21, 1998


  <!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.10 Identifying
                     Languages.

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

  PayDirection       Indicates the direction in which the payment
                     for which a Brand is being selected is to be
                     made. Its values may be:

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



Surendra Reddy et al.                                         [Page 115]


Internet Draft                  IOTP/1.0              September 21, 1998


  ProtocolAmount     This links a particular Brand to:

                     the currencies and amounts in CurrencyAmount
                     elements that can be used with the Brand,
                     and
                     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.


6.13.  Brand Element

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


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

  Attributes:

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

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




Surendra Reddy et al.                                         [Page 116]


Internet Draft                  IOTP/1.0              September 21, 1998


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

                      The syntax for a BrandId is as follows:

                      BrandId     ::= UserDefinedCode |
                        BrandIdDomain  ":" BrandValue

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

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

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

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

  BrandLogoNetLocn   The net location which can be used to
                      download the logo for the Organization.
                      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.




Surendra Reddy et al.                                         [Page 117]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

  Content:

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


6.14.  Protocol Amount Element

  The Protocol Amount element links a Brand to:

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

  the Payment Protocols and Payment Handlers defined in a Pay



Surendra Reddy et al.                                         [Page 118]


Internet Draft                  IOTP/1.0              September 21, 1998


  Protocol Element (see section 6.16), which can be used with
  those currencies and amounts.
  Its definition is as follows:


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

  Attributes:

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

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

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

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




Surendra Reddy et al.                                         [Page 119]


Internet Draft                  IOTP/1.0              September 21, 1998


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


  Content:

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

6.15.  Currency Amount Element

  A Currency Amount element contains:

    - a currency code (and its type), and
    - an amount.
    - One or more of these elements is carried in each Brand List
      Component.

  Its definition is as follows:

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

  Attributes:

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

  Amount             Indicates the amount to be paid in whole and
                     fractional  units  of  the  currency.  For
                     example $245.35 would be expressed "245.35".
                     Note that values smaller than the smallest



Surendra Reddy et al.                                         [Page 120]


Internet Draft                  IOTP/1.0              September 21, 1998


                     denomination are allowed. For example one
                     tenth of a cent would be "0.001".

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

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

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

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

6.16.  Pay Protocol Element

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

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

  Attributes:

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




Surendra Reddy et al.                                         [Page 121]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

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

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

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

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

  ContentSoftwareId  This contains information which identifies
                     the software which generated the content of
                     the element. Its purpose is to help resolve
                     interoperability problems that might occur
                     as a result of incompatibilities between



Surendra Reddy et al.                                         [Page 122]


Internet Draft                  IOTP/1.0              September 21, 1998


                     messages produced by different software. It
                     is a single text string in the language
                     defined by xml:lang. It MUST contain, as a
                     minimum:
                     the name of the software manufacturer
                     the name of the software
                     the version of the software, and
                     the build of the software

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

  Content:

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

6.17.  Brand Selection Component

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

    - in Payment Request messages within Baseline Purchase and
      Baseline Value IOTP Transactions to identify the brand,
      protocol and payment handler for a payment, or
    - 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?,



Surendra Reddy et al.                                         [Page 123]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Attributes:

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

  BrandListRef       The Element Reference (see section 3.7) 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
  BrandSelProtocolAmount  may be required by a particular payment
  Info,                   brand or protocol. See sections 6.18,
  BrandSelCurrencyAmount  6.19, and 6.20.
  Info

  The following rules apply:

    - the BrandListRef MUST contain the ID of a Brand List
      Component in the same IOTP Transaction
    - every Brand List Component in the Trading Protocol Options
      Block must be referenced by one and only one Brand Selection
      Component
    - the BrandRef must refer to the ID of a Brand contained



Surendra Reddy et al.                                         [Page 124]


Internet Draft                  IOTP/1.0              September 21, 1998


      within the Brand List Component referred to by BrandListRef
    - the ProtocolAmountRef must refer to one of the Element IDs
      listed  in the ProtocolAmountRefs attribute of the Brand
      element identified by BrandRef
    - the CurrencyAmountRef must refer to one of the Element IDs
      listed in the CurrencyAmountRefs attribute of the Protocol
      Amount Element identified by ProtocolAmountRef.


6.18.  Brand Selection Brand Info Element

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

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

  Attributes:

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

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

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

  Content:

  PackagedContent    Packaged Content information (see section
                     3.8) that contains additional data that may



Surendra Reddy et al.                                         [Page 125]


Internet Draft                  IOTP/1.0              September 21, 1998


                     be required by a particular payment brand.
                     See the payment method supplement for IOTP
                     for rules on how this is used.


6.19.  Brand Selection Protocol Amount Info Element

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

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

  Attributes:

  ContentSoftwareId  See section 6.18 Brand Selection Brand Info
                     Element.

  Content:

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


6.20.  Brand Selection Currency Amount Info Element

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

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

  Attributes:

  ContentSoftwareId  See section 6.18 Brand Selection Brand Info



Surendra Reddy et al.                                         [Page 126]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Element.

  Content:

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


6.21.  Payment Component

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

    - the times within which a Payment with a Payment Handler may
      be started
    - a reference to the Brand List (see section 6.12) which
      identifies the Brands, protocols, currencies and amounts
      which can be used to make a payment
    - whether or not an authentication of the consumer is required
      as part of the payment
    - whether or not a payment receipt will be provided
    - whether another payment precedes this payment.

  Its definition is as follows.

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

  Attributes:

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

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



Surendra Reddy et al.                                         [Page 127]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Component.

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

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

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

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

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

  Contents

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


6.22.  Payment Scheme Component

  A Payment Scheme Component contains payment protocol information
  for a specific payment scheme which is transferred between the



Surendra Reddy et al.                                         [Page 128]


Internet Draft                  IOTP/1.0              September 21, 1998


  parties involved in a payment for example a [SET] message. Its
  definition is as follows.

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

  Attributes:

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

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

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

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

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




Surendra Reddy et al.                                         [Page 129]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Content:

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


6.23.  Payment Receipt Component

  A Payment Receipt Component contains payment scheme specific data
  which can be used after the payment has completed to verify the
  payment occurred. Its definition is as follows.


  <!ELEMENT PayReceipt (PackagedContent) >
  <!ATTLIST PayReceipt
    ID  ID    #REQUIRED
    PaymentRef      NMTOKEN     #REQUIRED
    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.7) to the Payment Component (see section
                     6.21) to which this payment receipt applies

  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:




Surendra Reddy et al.                                         [Page 130]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

  Content:

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


6.24.  Delivery Component

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

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

  Attributes:

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

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

  DelivExch          Indicates if this IOTP Transaction includes
                     the  messages  associated  with  a  Delivery



Surendra Reddy et al.                                         [Page 131]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Exchange. Valid values are:

                     True indicates it does include a Delivery
                     Exchange
                     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 5.10) and the Payment Response
                     Block (see section 5.8 ) are combined into
                     one IOTP Message. Valid values are:

                     True indicates both blocks will be in the
                     same IOTP Message, and
                     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 Organization since:

                     the Payment Handler must have access to
                     Order Component information so that they
                     know what to deliver, and
                     the Payment Handler must be able to carry
                     out the delivery

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

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

  Content:




Surendra Reddy et al.                                         [Page 132]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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


6.25.  Delivery Data Element

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

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

  Attributes:

  xml:lang           Defines the language used by attributes
                      within this component. See section 3.10
                      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 5.9).

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

  DelivMethod        Indicates the method by which goods or
                      services may be delivered. Valid values
                      are:

                      Post      the goods will be delivered by post or
                                courier
                      Web       the goods will be delivered electronically



Surendra Reddy et al.                                         [Page 133]


Internet Draft                  IOTP/1.0              September 21, 1998


                                in   the   Delivery   Note Component
                      Email     the   goods   will   be   delivered
                                electronically by e-mail
                      x-ddd:nnn a user defined delivery method
                                see 3.9.3 User Defined Codes.

  DelivToRef         The Element Reference (see section 3.6) of
                      an Organization 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:

                      Post, then the there must be a Postal
                      Address   Element   containing   sufficient
                      information for a postal delivery,
                      Web,   then   there   are   no   specific
                      requirements. The information will be sent
                      in a web page back to the Consumer
                      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 5.9) which contains the Delivery
                      Component should be sent.

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

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

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

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

                      See also Section 3.11 Secure and Insecure
                      Net Locations.



Surendra Reddy et al.                                         [Page 134]


Internet Draft                  IOTP/1.0              September 21, 1998


  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:

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

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

  Content:

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


6.26.  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
  Organization receiving the Delivery Note can use when delivery
  occurs.

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

  Attributes:

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



Surendra Reddy et al.                                         [Page 135]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

  Content:

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

  Note: If the content of the Delivery Message is a Mime message



Surendra Reddy et al.                                         [Page 136]


Internet Draft                  IOTP/1.0              September 21, 1998


  then the Delivery Note may trigger an application which causes
  the actual delivery to occur.


6.27.  Payment Method Information Component

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

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

  Attributes:

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

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

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


6.28.  Status Component

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

  Its definition is as follows.

  <!ELEMENT Status EMPTY >
  <!ATTLIST Status
    ID  ID    #REQUIRED
    xml:lang  NMTOKEN     #REQUIRED
    StatusType (Offer|Payment|Delivery) #REQUIRED



Surendra Reddy et al.                                         [Page 137]


Internet Draft                  IOTP/1.0              September 21, 1998


    ElRef     NMTOKEN     #REQUIRED
    ProcessState(NotYetStarted|InProgress|
    CompletedOk|Failed|ProcessError) #REQUIRED
    CompletionCode  NMTOKEN     #IMPLIED
    ProcessReference      CDATA #IMPLIED
    StatusDesc      CDATA #IMPLIED >

  Attributes:

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

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

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

  ElRef              Contains an Element Reference (see section
                     3.7) to the Component for which the Status
                     is being described. It must refer to either:

                     a  Trading  Protocol  Options  Block  (see
                     section 5.1), if the StatusType is Offer,
                     a Payment Component (see section 6.21), if
                     the StatusType is Payment, or
                     a Delivery Component (see section 6.24), if
                     the StatusType is Delivery.

  ProcessState       Contains a State Code which indicates the
                     current state of the process being carried
                     out. Valid values for ProcessState are:

                     NotYetStarted.  A  Request  Block  has  been
                     received but the process has not yet started
                     InProgress. Processing of the Request Block
                     has started but it is not yet complete
                     CompletedOk. The processing of the Request
                     Block has completed successfully without any
                     errors
                     Failed. The processing of the Request Block
                     has failed because of a business error (see
                     section 7.2)
                     ProcessError. This value is only used when
                     the  Status  Component  is  being  used  in
                     connection with an Inquiry Request Trading



Surendra Reddy et al.                                         [Page 138]


Internet Draft                  IOTP/1.0              September 21, 1998


                     Block (see section 5.14). It indicates there
                     was a Technical Error (see section 7.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 to the Consumer.

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

                     A  CompletionCode  is  a  maximum  of  14
                     characters long.

  ProcessReference   This optional attribute holds a reference
                     for  the  process  whose  status  is  being
                     reported. It may hold the following values:

                     when StatusType is set to Offer, it should
                     contain the OrderIdentifier from the Order
                     Component
                     when StatusType is set to Payment, it should
                     contain  the  PaymentHandlerPayId  from  the
                     Payment Scheme Data Component
                     when  StatusType  is  set  to  Delivery,  it
                     should contain the DelivHandlerDelivId from
                     the Delivery Note Component

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

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

                     For example, the package tracking number
                     might not be assigned at the time of a
                     delivery response was received. However, if
                     the Consumer issues a Baseline Transaction



Surendra Reddy et al.                                         [Page 139]


Internet Draft                  IOTP/1.0              September 21, 1998


                     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  payment  in  the
                     language identified by xml:lang.


6.28.1.  Offer Completion Codes

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

  Value              Description
  =========          =============================================

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

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

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


6.28.2.  Payment Completion Codes

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

  Value              Description
  =========          =============================================

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

  CurrNotSupp        Currency  not  supported.  The  currency  in
                     which the payment is to be made is not



Surendra Reddy et al.                                         [Page 140]


Internet Draft                  IOTP/1.0              September 21, 1998


                     supported by either the Payment Instrument
                     or the Payment Handler.

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

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

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

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

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

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

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


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



Surendra Reddy et al.                                         [Page 141]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

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


6.29.  Inquiry Type Component

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

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

  Attributes:



Surendra Reddy et al.                                         [Page 142]


Internet Draft                  IOTP/1.0              September 21, 1998


  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:

                     Offer. The inquiry is about the status of an
                     offer and is addressed to the Merchant.
                     Payment. The inquiry is about the status of
                     a payment and is addressed to the Payment
                     Handler.
                     Delivery. The inquiry is about the status of
                     a delivery and addressed to the Delivery
                     Handler.

  ElRef              Contains an Element Reference (see section
                     3.7) to the component to which this Inquiry
                     Type Component applies. That is,

                     TPO Block when Type is Offer
                     Payment Component when Type is Payment
                     Delivery Component when Type is Delivery

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

6.30.  Signature Component

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

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

  The Signature Component:

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



Surendra Reddy et al.                                         [Page 143]


Internet Draft                  IOTP/1.0              September 21, 1998


      element.

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

  A Signature Component can be one of two types either:

    - an Offer Response Signature, or
    - a Payment Response Signature

  How these signatures are constructed is described below


6.31.  Offer Response Signature Component

  The Signed Data Element of the Offer Response Signature Component
  should contain hashes of the following Components:

    - the Transaction Id Component (see section 3.5.1) of the IOTP
      message that contains the Offer Response Signature
    - the Transaction Reference Block (see section 3.5) of the IOTP
      Message that contains the Offer Response Signature
    - from the TPO Block:

       o the Protocol Options Component

       o each of the Organization Components

       o each of the Brand List Components

    - optionally, all the Brand Selection Components if they were
      sent to the Merchant in a TPO Selection Block
    - from the Offer Response Block:

       o the Order Component

       o each of the Payment Components

       o the Delivery Component

    - each of the Authentication Data Components
  The  Offer  Response  Signature  Component  should  also  contain
  Digital Signature Elements for each of the Organizations that may
  or will need to verify the signature. This involves:

    - if  the  Merchant  has  received  a  TPO  Selection  Block
      containing  Brand  Selection  Components,  then  generate  a
      Digital Signature Element for the Payment Handler identified



Surendra Reddy et al.                                         [Page 144]


Internet Draft                  IOTP/1.0              September 21, 1998


      by the Brand Selection Component and the Delivery Handler
      identified by the Delivery Component. See section 9.7 Check
      the Action Request was sent to the Correct Organization for
      a description of how this can be done.
    - if the Merchant is not expecting to receive a TPO Selection
      Block then generate a Digital Signature Element for the
      Delivery Handler and all the Payment Handlers that are
      involved.

6.32.  Payment Receipt Signature Component
  The  Signed  Data  Element  of  the  Payment  Receipt  Signature
  Component should contain hashes of the following Components:

    - the Transaction Id Component (see section 3.5.1) of the IOTP
      message that contains the Payment Receipt Signature
    - the Transaction Reference Block (see section 3.5) of the IOTP
      Message that contains the Payment Receipt Signature
    - the Offer Response Signature Component
    - the Payment Receipt Component
    - the Status Component
    - the Brand Selection Component.

6.33.  Ping Signature Components

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

    - all the Organization Components.

6.34.  Error Component

  The Error Component contains information about Technical Errors
  (see section 7.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:

    - message in error. An IOTP message which contains or causes an
      error of some kind
    - 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*) >



Surendra Reddy et al.                                         [Page 145]


Internet Draft                  IOTP/1.0              September 21, 1998


  <!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.10 Identifying
                     Languages.

  ErrorCode          Contains an error code which indicates the
                     nature of the error in the message in error.
                     Valid values for the ErrorCode are given in
                     section 6.36 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:

                     Warning. This indicates that although there
                     is a message in error the IOTP Transaction
                     can still continue.
                     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
                     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



Surendra Reddy et al.                                         [Page 146]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Content:

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

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

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







Surendra Reddy et al.                                         [Page 147]


Internet Draft                  IOTP/1.0              September 21, 1998


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


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

  it is recommended that information about the error is either
  logged, or otherwise reported to the user,

  the implementer of the IOTP aware application must either, at
  their or the user's discretion:
    - continue the IOTP transaction as normal, or
    - fail the IOTP transaction by generating a message reporting
      the error with an Error Component with Severity set to
      HardError (see section 6.35.3).
  If the intention is to continue the IOTP transaction then, if
  there are no other Error Components with a higher severity, check
  that the necessary Trading Blocks and Trading Components for
  normal processing of the transaction to continue are present. If
  they are not then generate a message reporting the error with an
  Error Component with Severity set to HardError.


6.35.2.  Severity - Transient Error

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

  If a message reporting the error is received with an Error
  Component where Severity is set to TransientError then:



Surendra Reddy et al.                                         [Page 148]


Internet Draft                  IOTP/1.0              September 21, 1998


  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.

  check that only one ErrorLocation element is contained
  within the Error Component and that it refers to an IOTP
  Message which was sent by the recipient of the Error
  Component with a Severity of TransientError. If more than
  one  ErrorLocation  is  present  then  generate  a  message
  reporting the error with a Severity of HardError.

6.35.3.  Severity - Hard Error

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

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


6.36.  Error Codes

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

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


  Value              Description
  =========          =============================================
  Reserved           Reserved. This error is reserved by the
                     vendor/developer of the software. Contact
                     the vendor/developer of the software for
                     more   information   See   the   SoftwareId



Surendra Reddy et al.                                         [Page 149]


Internet Draft                  IOTP/1.0              September 21, 1998


                     attribute of the Message Id element in the
                     Transaction Reference Block(section 3.5).

  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:

                     the XML document does not comply with the
                     constraints defined in the IOTP document type
                     declaration (see section Error! Reference
                     source not found. Error! Reference source
                     not found.), and
                     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:

                     is consistent with the rules and constraints
                     contained in this specification, but
                     is  not  supported  by  the  IOTP  Aware
                     Application  which  is  processing  the  IOTP
                     Message.




Surendra Reddy et al.                                         [Page 150]


Internet Draft                  IOTP/1.0              September 21, 1998


  ElMissing          Element missing. Although the document is
                     well formed and valid, an element is missing
                     that should have been present if the rules
                     and   constraints   contained   in   this
                     specification are followed.
                     In this case set the PackagedContent of the
                     Error Component to the type of the missing
                     element.

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

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

  AttUnexpected      Unexpected  attribute.  Although  the  XML
                     document  is  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



Surendra Reddy et al.                                         [Page 151]


Internet Draft                  IOTP/1.0              September 21, 1998


                     the rules and constraints contained in this
                     specification.

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

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

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

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

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

  ElInconsistent     Element Inconsistent. Although the document
                     is well formed and valid, according to the
                     rules  and  constraints  contained  in  this
                     specification:

                     the content of an element is inconsistent
                     with the content of other elements or their
                     attributes, or
                     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



Surendra Reddy et al.                                         [Page 152]


Internet Draft                  IOTP/1.0              September 21, 1998


                     associated   with   a   Transient   Error.
                     Explanation  of  the  Transport  Error  is
                     contained within the ErrorDesc attribute.
                     The  values  which  can  be  used  inside
                     ErrorDesc with a TransportError is specified
                     in the IOTP supplement for the Transport
                     mechanism.


6.37.  Error Location Element

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

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

  Attributes:

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

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

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

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

  ElementRef         If the error is associated with a specific
                     element within a Trading Component then, if



Surendra Reddy et al.                                         [Page 153]


Internet Draft                  IOTP/1.0              September 21, 1998


                     the  element  has  an  attribute  with  an
                     "attribute type" (see [XML]) of "ID", then
                     this is the value of that attribute.

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

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


7.  IOTP Error Handling

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

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

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

       o "technical errors" which are independent of the meaning
         of the IOTP Message,

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

    - the depth of the error which indicates whether the error is
      at the transport, message or block/component level
    - how the different trading roles should handle the different
      types of messages which they may receive.






Surendra Reddy et al.                                         [Page 154]


Internet Draft                  IOTP/1.0              September 21, 1998


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

    - retrying the transmission, or
    - cancelling the transaction.
  When communications are operating sufficiently well, a technical
  error is indicated by an Error Component in an Error Block (see
  section 5.23) sent by the party which detected the error in an
  IOTP message to the party which sent the erroneous message.

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

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


7.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, or delivery, where each process has a
  different set of possible business errors.

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

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




Surendra Reddy et al.                                         [Page 155]


Internet Draft                  IOTP/1.0              September 21, 1998


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


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

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

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

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

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


7.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.5) so it is not possible to figure out what transaction the
  message relates to.

  All message level errors are technical errors and are indicated
  by an Error Component sent to the other party. The  Error Component
  includes  a  Severity  attribute  which indicates whether the error



Surendra Reddy et al.                                         [Page 156]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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


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

    - technical errors, or
    - business errors

  Technical Errors are further divided into:

    - Block Level Attribute and Element Checks, and
    - Block and Component Consistency Checks

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




Surendra Reddy et al.                                         [Page 157]


Internet Draft                  IOTP/1.0              September 21, 1998


7.3.4.

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:

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

7.3.5.  Block and Component Consistency Checks

  Block and Component Consistency Checks consist of:

    - checking that the combination of blocks and/or components
      present in the IOTP Message are consistent with the rules
      contained within this IOTP specification
    - checking for consistency between attributes and element
      content within the blocks within the same IOTP message.
    - 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

7.3.6.  Block Business Errors

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

7.4.  Idempotency, Processing Sequence, and Message Flow

  IOTP messages are actually a combination of blocks and components
  as described in 3.1 IOTP Message Structure. Especially in future
  extensions of IOTP, a rich variety of combinations of such blocks
  and components can occur. It is important that the multiple
  transmission/receipt of the "same" request for state changing



Surendra Reddy et al.                                         [Page 158]


Internet Draft                  IOTP/1.0              September 21, 1998


  action not result in that action occurring more than once. This
  is called idempotency. For example, a customer paying for an
  order would want to pay the full amount only once. Most network
  transport  mechanisms  have  some  probability  of  delivering  a
  message  more  than  once  or  not  at  all,  perhaps  requiring
  retransmission. On the other hand, a request for status can
  reasonably be repeated and should be processed fresh each time it
  is received.

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


7.4.1.  Server Role Processing Sequence

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


7.4.2.  Check for Transport or Message Level Error

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

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

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

  No idempotency related actions are necessary.






Surendra Reddy et al.                                         [Page 159]


Internet Draft                  IOTP/1.0              September 21, 1998


7.4.3.  Process all the blocks

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

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

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


7.4.4.  Check the Block is OK

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

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


7.4.5.  Determine the Type of the Block

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


7.4.6.  Status Request Blocks

  Status Request Blocks are either:




Surendra Reddy et al.                                         [Page 160]


Internet Draft                  IOTP/1.0              September 21, 1998


  - Inquiry Request Trading Block (see section 5.14), or

  - Ping Request Block (see section 5.16).

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

  No idempotency actions are required.


7.4.7.  Action Request Blocks

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

  If the Block has been received previously then:

  if processing of the previously stored block is complete
  then the same IOTP Block as previously produced must be included
  for resending to the Consumer.

  if processing is not complete, wait until the processing is
  complete before sending the response. If the block has not been
  received before, the action request is processed normally producing
  a response block that is added to the response message. This might
  or might not indicate a business error.

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

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

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






Surendra Reddy et al.                                         [Page 161]


Internet Draft                  IOTP/1.0              September 21, 1998


7.4.8.  Encapsulating Blocks

  Blocks which encapsulate a payment protocol pass along the enclosed
  information to the payment system involved.

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

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


7.4.9.  Error Block Received

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

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


7.4.10.  Generate Error Block

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

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




Surendra Reddy et al.                                         [Page 162]


Internet Draft                  IOTP/1.0              September 21, 1998


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


7.4.11.  Add Block to Output Message

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

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

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


7.5.1.  Check for Transport or Message Level Error

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

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

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


7.5.2.  Process all the blocks

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



Surendra Reddy et al.                                         [Page 163]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

7.5.3.  Check the Block is OK

  If there are no message level errors process each of the blocks
  within the message.

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

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


7.5.4.  Determine the Type of the Block

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


7.5.5.  Status Response Blocks

  Status Response Blocks are either:

  - Inquiry Response Trading Blocks (see section 5.15), or

  - Ping Response Blocks (see section 5.17)

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



Surendra Reddy et al.                                         [Page 164]


Internet Draft                  IOTP/1.0              September 21, 1998


  status. Thus client detection of duplication in successive status
  response blocks may be useful.


7.5.6.  Action Response Blocks

  Check to determine if the Block has been received previously. If it
  has then it should be ignored.

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

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


7.5.7.  Encapsulating Blocks

  Blocks which encapsulate a payment protocol pass along the enclosed
  information to the payment system involved.

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

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


7.5.8.  Error Block

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



Surendra Reddy et al.                                         [Page 165]


Internet Draft                  IOTP/1.0              September 21, 1998


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


7.5.9.  Generate Error Block

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


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


7.5.10.  Add Block to Output Message

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


8.  Retrieving Logos

  This section describes how to retrieve logos for display by IOTP
  aware software using the Logo Net Locations attribute contained
  in the Brand Element (see section 6.13) and the Organization
  Component (see section 6.7).

  The full address of a logo is defined as follows:

  Logo_address   ::=   Logo_net_location   "/"   Logo_size
                                      Logo_color_depth
                                      ".GIF"
  Where:

  Logo_net_location is obtained from the LogoNetLocn attribute
  in the Brand Element (see section 6.13) or the Organization
  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,



Surendra Reddy et al.                                         [Page 166]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  Logo_size identifies the size of the logo,

  Logo_color_depth identifies the colour depth of the logo

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


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


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



Surendra Reddy et al.                                         [Page 167]


Internet Draft                  IOTP/1.0              September 21, 1998


          8 (256 colors)           nothing

          24 (16 million colors)   24

  Note that if Logo Color Depth is omitted then a logo with the
  default colour depth of 256 colours will be retrieved.


8.3.  Logo Net Location Examples

  If Logo Net Location was set to "ftp://logos.xzpay.com", then:

  "ftp://logos.xzpay.com/medium.gif" would retrieve a medium
  size 256 colour logo

  "ftp://logos.xzpay.com/small4.gif" would retrieve a small
  size 16 colour logo

  Note: Organizations which make logos available for use with IOTP
  should always make available "small" and "medium" size logos and
  use the GIF format.


9.  Security Considerations

  This section considers the security associated with IOTP. It
  covers:

    - an overview of how IOTP uses digital signatures
    - how to check a signature is correctly calculated
    - how Payment Handlers and Delivery Handlers check they can
      carry out payments or deliveries on behalf of a Merchant.
    - how IOTP handles data integrity and privacy

9.1.  Digital Signatures and IOTP

  In general, signatures when used with IOTP:

    - are always treated as a IOTP Components (see section 5)
    - hash one or more IOTP Components or Trading Blocks, possibly
      including other Signature Components, in any IOTP message
      within the same IOTP Transaction

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



Surendra Reddy et al.                                         [Page 168]


Internet Draft                  IOTP/1.0              September 21, 1998


  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.

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

  The remainder of this section contains:

    - an example of how IOTP uses signatures
    - how the SignerOrgRef and VerifierOrgRef attributes within a
      Signature Component are used to identify the Organizations
      associated with the signature
    - how  signatures  may  use  either  Symmetric  or  Asymmetric
      Cryptography
    - Mandatory and Optional use of Signatures by IOTP, and
    - how  IOTP  uses  signatures  to  prove  actions  complete
      successfully

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


  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.

9.3.  SignerOrgRef and VerifierOrgRef Attributes

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

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



Surendra Reddy et al.                                         [Page 169]


Internet Draft                  IOTP/1.0              September 21, 1998


             Signature          Valid
             Component         Trading
                Type             Role

          OfferResponse       Merchant

          PaymentResponse     PaymentHandler

  The VerifierOrgRef attribute on the DigSig elements, contains
  Element  References  to  the  Organization  Components  of  the
  Organizations that should use the signature to verify that:

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

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

  the data has been signed correctly, and

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

9.4.  Symmetric and Asymmetric Cryptography

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

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

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


9.5.  Mandatory and Optional Signatures

  IOTP does not mandate the use of signatures. For example, if a
  micro payment is being made for 0.1 cents, then the cost of the
  cryptography required to generate the signature may be greater
  than the income generated from the payment. Therefore it is up to
  the  Merchant  to  decide  whether  IOTP  Messages  will  include



Surendra Reddy et al.                                         [Page 170]


Internet Draft                  IOTP/1.0              September 21, 1998


  signatures, and for the Consumer to decide whether carrying out a
  transaction  without  signatures  is  an  acceptable  risk.  If
  Merchants discover that transactions without signatures are not
  being accepted, then they will start using signatures or accept a
  lower volume and value of business.

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

9.6.  Using signatures to Prove Actions Complete Successfully

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

  on the Offer Response, when a Merchant is making an Offer to
  the Consumer which can then be sent to either:
    - a Payment Handler to prove that payment is authorised, or
    - a Delivery Handler to prove that Delivery is authorised

  on  the  Payment  Response,  when  a  Payment  Handler  is
  generating a Payment Receipt which can be sent to either:
    - a Delivery Handler, in a Delivery Request Block to prove
      that delivery is authorised, or
    - another Payment Handler, in a second Payment Request, to
      prove that the second payment in a Value Exchange IOTP
      Transaction is authorised.
  This proof of an action may, in future versions of IOTP, also be
  used to prove after the event that the IOTP transaction occurred.
  For example to a Customer Care Provider.


9.6.1.  Checking a Signature is Correctly Calculated

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

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

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



Surendra Reddy et al.                                         [Page 171]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  use the ID attribute of the Organization Component to
  identify the Digital Signatures Elements which the Trading
  Role should verify. Note there may be no signatures for a
  Trading Role to verify.

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


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

    - check that the Payment Request or Delivery Request has been
      sent to the correct Organization
    - check  that  correct  IOTP  components  are  present  in  the
      request, and
    - check that the payment or delivery is authorised


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

    - a "Request Block" is used to refer to either a Payment
      Request Block (see section 5.6) or a Delivery Request Block
      (see section 5.9) unless specified to the contrary
    - a "Response Block" is used to refer to either a Payment
      Response Block (see section 5.8) or a Delivery Response
      Block (see section 5.10)
    - 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



Surendra Reddy et al.                                         [Page 172]


Internet Draft                  IOTP/1.0              September 21, 1998


    - an "Action Organization", is used to refer to the Payment
      Handler or Delivery Handler that carries out an Action
    - a  "Signer  of  an  Action",  is  used  to  refer  to  the
      Organizations that sign data about an Action to authorise
      the Action, either in whole or in part
    - a  "Verifier  of  an  Action",  is  used  to  refer  to  the
      Organizations that verify data to determine if they are
      authorised to carry out the Action
    - an ActionOrgRef attribute contains Element References which
      can be used to identify the "Action Organization" that
      should carry out an Action


9.7.  Check the Action Request was sent to the Correct Organization

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


9.7.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 Organization selected by the Consumer
  and then checking that this Organization is itself.

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

    - Identify the Payment Component (see section 6.21) in the
      Payment Request Block that was received.
    - Identify the Brand List and Brand Selection Components for
      the Payment Component. This involves:
    - identifying the Brand List Component (see section 6.12)
      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 6.17)
      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.
    - Identify  the  Brand,  Protocol  Amount,  Pay  Protocol  and
      Currency Amount elements within the Brand List that have
      been selected by the Consumer as follows:



Surendra Reddy et al.                                         [Page 173]


Internet Draft                  IOTP/1.0              September 21, 1998


       o the Brand Element 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.

       o the Protocol Amount Element 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

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

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

    - 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
    - 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.
    - Check that the Payment Handler that received the Payment
      Request  Block  is  the  Payment  Handler  selected  by  the
      Consumer. This involves:

       o identifying the Organization Component for the Payment
         Handler. This is the Organization Component where its ID



Surendra Reddy et al.                                         [Page 174]


Internet Draft                  IOTP/1.0              September 21, 1998


         attribute  matches  the  ActionOrgRef  attribute  in  the
         identified Pay Protocol Element. If no or more than one
         matching Organization Component is found there is an
         error

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

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


9.7.2.  Delivery

  The steps involved are as follows:

    - Identify the Delivery Component in the Delivery Request
      Block. If there is no or more than one matching Delivery
      Component there is an error
    - Use the ActionOrgRef attribute of the Delivery Component to
      identify the Organization Component of the Delivery Handler.
      If there is no or more than one matching Organization
      Component there is an error
    - If the Organization Component for the Delivery Handler does
      not have a Trading Role Element with a Role attribute of
      DeliveryHandler there is an error
    - Finally, if the Organization that received the Delivery
      Request Block does not identify the Organization Component
      for the Delivery Handler as itself, then there is an error.


9.8.  Check the Correct Components are present in the Request Block

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

  If components are missing, there is an error.


9.9.  Check an Action is Authorised

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




Surendra Reddy et al.                                         [Page 175]


Internet Draft                  IOTP/1.0              September 21, 1998


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

  The steps involved are as follows:

    - Identify the Merchant. This is the Organization 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
    - Check the Action Organization's agreements with the Merchant
      allows the Action to be carried out. To do this the Action
      Organization must check that:

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

       o 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

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

    - Check the signatures are correct. If signatures are required
      then they need to be checked. This involves:
    - Identifying the correct signatures to check. This involves
      the Action Organization identifying the Signature Components
      where the VerifierOrgRef attribute of the Digital Signature
      element points to the Action Organization's Organization
      Component. Depending on the IOTP Transaction being carried
      out (see section 4) either one or two signatures may be
      identified
    - checking that the Signature Components are correct. This
      involves checking that the necessary Trading Components have
      been hashed (see section 9.9.1).

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



Surendra Reddy et al.                                         [Page 176]


Internet Draft                  IOTP/1.0              September 21, 1998


  processed.


9.9.1.  Check the Signatures Sign Correct Data

  All Signature Components contained within IOTP Messages must
  always hash:

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

  the Transaction Reference Block (see section 3.5) of the
  first IOTP Message that contained the signature. This binds
  the  OtpTransId  with  information  about  the  IOTP  Message
  contained inside the Message Id Component (see section
  3.5.2).
  Checking that each signature signs the correct data, involves
  checking that hashes of the necessary components are present in
  the SignedData element of the Signature Component.

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

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

  if the signer of the signature is a Payment Handler then
  hashes should be present for:
    - the  Signature  Component  signed  by  the  Merchant,  and
      optionally
    - one or more Signature Components signed by the Payment
      Handler(s) identified by the appropriate ActionSignerRefs
      attribute.

9.10.  Data Integrity and Privacy

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

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



Surendra Reddy et al.                                         [Page 177]


Internet Draft                  IOTP/1.0              September 21, 1998


10.  Internationalization Considerations

   In the realm of internationalization, this specification complies
   with the IETF Character Set Policy [Alvestrand, 1998]. In this
   specification, human-readable fields can be found either in the
   value of a property, or in an error message returned in a response
   entity body.  In both cases, the human-readable content is encoded
   using XML, which has explicit provisions for character set tagging
   and encoding, and requires that XML processors read XML elements
   encoded, at minimum, using the UTF-8 [Yergeau, 1998] encoding of the
   ISO 10646 multilingual plane.

   XML also provides a language tagging capability for specifying the
   language of the contents of a particular XML element.  XML uses
   either IANA registered language tags (see RFC 1766, [Alvestrand,
   1995]) or ISO 639 language tags [ISO-639] in the "xml:lang"
   attribute of an XML element to identify the language of its content
   and attributes.

   IOTP applications MUST support the character set tagging,
   character set encoding, and the language tagging functionality of
   the XML specification.

   Since interoperation of clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of this information.


11.  IANA Considerations
   This specification defines a distinguished set of XML elements that
   are understood by all IOTP applications.  The XML elements in this
   specification are all derived from the base URI IOTP: by adding a
   suffix to this URI.

   To ensure correct interoperation based on this specification, IANA
   must reserve the URI namespaces starting with "IOTP:" for use by
   this specification, its revisions, and related IOTP specifications.


12.  Copyrights
  Copyright (C) The Internet Society (1998). All Rights Reserved.

  This document and translations of it may be copied and furnished
  to others, and derivative works that comment on or otherwise
  explain it or assist in its implmentation 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



Surendra Reddy et al.                                         [Page 178]


Internet Draft                  IOTP/1.0              September 21, 1998


  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.


13.  References

[Base64] Base64 Content-Transfer-Encoding. A method of transporting binary
         data defined by MIME. See: RFC 2045: Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies. N.
         Freed & N. Borenstein. November 1996.

[DNS]    The Internet Domain Name System which allocates Internet names to
         organisations for example "otp.org", the Domain Name for IOTP. See
         RFC 1034: Domain names - concepts and facilities. P.V. Mockapetris.
         Nov-01-1987, and RFC 1035: Domain names - implementation and
         specification. P.V. Mockapetris. Nov-01-1987.

[DSA]    The Digital Signature Algorithm (DSA) published by the National
         Institute of Standards and Technology (NIST) in the Digital
         Signature Standard (DSS), which is a part of the US government's
         Capstone project.

[ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA).
         Elliptic curve cryptosystems are analogs 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.

[HTML]   Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML)
         is a simple mark-up language used to create hypertext documents
         that are platform independent. See RFC 1866 and the World Wide



Surendra Reddy et al.                                         [Page 179]


Internet Draft                  IOTP/1.0              September 21, 1998


         Web (W3C) consortium web site at: http://www.w3.org/MarkUp/

[HTTP]   Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 1945:
         Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding
         & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Protocol --
         HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
         T. Berners-Lee. January 1997.

[ISO4217] ISO 4217: Codes for the Representation of Currencies. Available
         from ANSI or ISO.

[MIME]   Multipurpose Internet Mail Extensions. See RFC822, RFC2045, RFC2046,
         RFC2047, RFC2048 and RFC2049.

[OPS]    Open Profiling Standard. A proposed standard which provides a
         framework with built-in privacy safeguards for the trusted exchange
         of profile information between individuals and web sites.  Being
         developed by Netscape and Microsoft amongst others.

[RFC822] IETF (Internet Engineering Task Force). RFC 822: The Standard for
         the Format of ARPA Internet Messages . 13 August 1982, David H
         Crocker. 13 August 1982.

[RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource
         Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.

[RSA]    RSA is 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. An IOTP supplement describing how SCCD works is under
         development. Author. Jonathan Sowler JCP,

[SET]    Secure Electronic Transaction Specification, Version 1.0, May 31,
         1997. Supports credit and debit card payments using certificates at
         the Consumer and Merchant to help ensure authenticity.
         Download from: <http://www.mastercard.com/set/specs.html>.

[SHA1]   [FIPS-180-1]"Secure Hash Standard", National Institute of Standards
         and Technology, US Department Of Commerce, April 1995. Also known
         as: 59 Fed Reg. 35317 (1994).

[UTC]    Universal Time Co-ordinated. A method of defining time absolutely



Surendra Reddy et al.                                         [Page 180]


Internet Draft                  IOTP/1.0              September 21, 1998


         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 Namespace] See Design decisions reached at the XML Working Group
         meeting in Montreal, Canada, August 22, 1987

[XML]    Extensible Mark Up Language. See http://www.w3.org/TR/PR-xml-971208
         for the 8 December 1997 version.

[XMLSIG] A proposal developed by the IOTP consortium describing an approach
         to signing XML documents such as IOTP Messages. It is intended that
         this document is submitted to W3C for consideration. Author.
         Richard Brown. GlobeSet. (Under preparation August 1998)


14.  Appendices

14.1.  IOTP - XML DTD
  <!--
  ******************************************************
  *                                                    *
  * OPEN TRADING PROTOCOL DTD                          *
  *                                                    *
  ******************************************************

  ******************************************************
  * IOTP MESSAGE DEFINITION                             *
  ******************************************************
   -->

  <!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
       ( AuthReqBlk |
         AuthRespBlk |
         DeliveryReqBlk |
         DeliveryRespBlk |
         InquiryReqBlk |
         InquiryRespBlk |
         OfferRespBlk |
         PayExchBlk |
         PayReqBlk |
         PayInstCCExchBlk |



Surendra Reddy et al.                                         [Page 181]


Internet Draft                  IOTP/1.0              September 21, 1998


         PayInstCCReqBlk |
         PayInstCCRespBlk
         PayRespBlk |
         PingReqBlk |
         PingRespBlk |
         TpoBlk |
         TpoSelectionBlk |
         )*
       ) >

  <!--
  ******************************************************
  * TRANSACTION REFERENCE BLOCK DEFINITION             *
  ******************************************************
   -->

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

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

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

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

  <!--
  ******************************************************
  * Packaged Content Common Element                    *
  ******************************************************



Surendra Reddy et al.                                         [Page 182]


Internet Draft                  IOTP/1.0              September 21, 1998


   -->

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

  <!--
  ******************************************************
  * TRADING COMPONENTS                                 *
  ******************************************************
   -->
  <!-- PROTOCOL OPTIONS COMPONENT -->
  <!ELEMENT ProtocolOptions EMPTY >
  <!ATTLIST ProtocolOptions
   ID                 ID      #REQUIRED
   xml:lang           NMTOKEN #REQUIRED
   ShortDesc          CDATA   #REQUIRED
   SenderNetLocn      CDATA   #REQUIRED
   SecureSenderNetLocn CDATA  #REQUIRED
   SuccessNetLocn     CDATA   #REQUIRED
   CancelNetLocn      CDATA   #REQUIRED
   ErrorNetLocn       CDATA   #REQUIRED >

  <!-- AUTHENTICATION DATA COMPONENT -->
  <!ELEMENT AuthData (PackagedContent)>
  <!ATTLIST AuthData
   ID                 ID      #REQUIRED
   AuthMethod         NMTOKEN #REQUIRED
   ContentSoftwareId  CDATA   #IMPLIED >

  <!-- AUTHENTICATION RESPONSE COMPONENT -->
  <!ELEMENT AuthResp (PackagedContent) >
  <!ATTLIST AuthResp
   ID                 ID      #REQUIRED
   ContentSoftwareId  CDATA   #IMPLIED >

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



Surendra Reddy et al.                                         [Page 183]


Internet Draft                  IOTP/1.0              September 21, 1998


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


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

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

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

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

  <!-- BRAND LIST COMPONENT -->
  <!ELEMENT BrandList (Brand+, ProtocolAmount+,
   CurrencyAmount+, PayProtocol+) >



Surendra Reddy et al.                                         [Page 184]


Internet Draft                  IOTP/1.0              September 21, 1998


  <!ATTLIST BrandList
   ID                 ID      #REQUIRED
   xml:lang           NMTOKEN #REQUIRED
   ShortDesc          CDATA   #REQUIRED
   PayDirection (Debit|Credit) #REQUIRED >

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

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

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

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

  <!-- BRAND SELECTION COMPONENT -->
  <!ELEMENT BrandSelection (BrandSelBrandInfo?,
       BrandSelProtocolAmountInfo?,
       BrandSelCurrencyAmountInfo?) >
  <!ATTLIST BrandSelection
   ID                 ID      #REQUIRED



Surendra Reddy et al.                                         [Page 185]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

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

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

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

  <!-- PAYMENT RECEIPT COMPONENT -->
  <!ELEMENT PayReceipt (PackagedContent) >
  <!ATTLIST PayReceipt
   ID                 ID      #REQUIRED
   PaymentRef         NMTOKEN #REQUIRED
   ContentSoftwareId  CDATA   #IMPLIED >

  <!-- DELIVERY COMPONENT -->
  <!ELEMENT Delivery (DeliveryData?, PackagedContent?) >



Surendra Reddy et al.                                         [Page 186]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

  <!-- PAYMENT METHOD INFORMATION COMPONENT -->
  <!ELEMENT PayMethodInfoData EMPTY >
  <!ATTLIST PayMethodInfoData
   ID                 ID      #REQUIRED
   BrandId            NMTOKEN #REQUIRED
   PayProtocolId      NMTOKEN #IMPLIED >

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

  <!-- INQUIRY TYPE COMPONENT -->



Surendra Reddy et al.                                         [Page 187]


Internet Draft                  IOTP/1.0              September 21, 1998


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

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

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

  <!--
  ******************************************************
  * TRADING BLOCKS                                     *
  ******************************************************
   -->

  <!-- TRADING PROTOCOL OPTIONS BLOCK -->
  <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
  <!ATTLIST TpoBlk
   ID                 ID      #REQUIRED >


  <!-- TPO SELECTION BLOCK -->
  <!ELEMENT TpoSelectionBlk (BrandSelection+) >
  <!ATTLIST TpoSelectionBlk
   ID                 ID      #REQUIRED >


  <!-- OFFER RESPONSE BLOCK -->
  <!ELEMENT OfferRespBlk (AuthData*, Order?, Payment*,
       Delivery?, Status ) >



Surendra Reddy et al.                                         [Page 188]


Internet Draft                  IOTP/1.0              September 21, 1998


  <!ATTLIST OfferRespBlk
   ID                 ID      #REQUIRED >


  <!-- AUTHENTICATION REQUEST BLOCK -->
  <!ELEMENT AuthReqBlk (AuthData?) >
  <!ATTLIST AuthReqBlk
   ID                 ID      #REQUIRED >


  <!-- AUTHENTICATION RESPONSE BLOCK -->
  <!ELEMENT AuthRespBlk (AuthResp, Org+) >
  <!ATTLIST AuthRespBlk
   ID                 ID      #REQUIRED >


  <!-- PAYMENT REQUEST BLOCK -->
  <!ELEMENT PayReqBlk (AuthData?, BrandList,
       BrandSelection,
       Payment, PaySchemeData?, Org*) >
  <!ATTLIST PayReqBlk
   ID                 ID      #REQUIRED >


  <!-- PAYMENT EXCHANGE BLOCK -->
  <!ELEMENT PayExchBlk (PaySchemeData) >
  <!ATTLIST PayExchBlk
   ID                 ID      #REQUIRED >


  <!-- PAYMENT RESPONSE BLOCK -->
  <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?)>
  <!ATTLIST PayRespBlk
   ID                 ID      #REQUIRED >


  <!-- DELIVERY REQUEST BLOCK -->
  <!ELEMENT DeliveryReqBlk (Order, Org*, Delivery) >
  <!ATTLIST DeliveryReqBlk
   ID                 ID      #REQUIRED >


  <!-- DELIVERY RESPONSE BLOCK -->
  <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
  <!ATTLIST DeliveryRespBlk
   ID                 ID      #REQUIRED >





Surendra Reddy et al.                                         [Page 189]


Internet Draft                  IOTP/1.0              September 21, 1998


  <!-- PAYMENT INSTRUMENT CUSTOMER CARE REQUEST BLOCK -->
  <!ELEMENT PayInstCCReqBlk (PaymethodInfo, PaySchemeData*)
       >
  <!ATTLIST PayInstCCReqBlk
   ID                 ID      #REQUIRED >


  <!-- PAYMENT INSTRUMENT CUSTOMER CARE EXCHANGE BLOCK -->
  <!ELEMENT PayInstCCExchBlk (PaySchemeData) >
  <!ATTLIST PayInstCCExchBlk
   ID                 ID      #REQUIRED >


  <!-- PAYMENT INSTRUMENT CUSTOMER CARE RESPONSE BLOCK -->
  <!ELEMENT PayInstCCRespBlk (PaySchemeData) >
  <!ATTLIST PayInstCCRespBlk
   ID                 ID      #REQUIRED >


  <!-- INQUIRY REQUEST BLOCK -->
  <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
  <!ATTLIST InquiryReqBlk
   ID                 ID      #REQUIRED >


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


  <!-- PING REQUEST BLOCK -->
  <!ELEMENT PingReqBlk (Org*)>
  <!ATTLIST PingReqBlk
   ID                 ID      #REQUIRED>

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





Surendra Reddy et al.                                         [Page 190]


Internet Draft                  IOTP/1.0              September 21, 1998


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


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


15.  Author's Address

  Surendra K Reddy
  Oracle Corporation
  500 Oracle Parkway, M/S 4op12
  Redwoodshores, CA 94065
  USA

  Tel:   +1 (650) 506 5441
  email: skreddy@us.oracle.com

  David Burdett
  Development Director
  Mondex International Ltd
  Advanced Technology Division
  111 Pine St
  San Francisco,  CA 94111
  USA

  Tel: +1 (415) 645 6973
  Email: david.burdett@mondex.com




Expires on March 21, 1999













Surendra Reddy et al.                                         [Page 191]