tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2801

Informational
Pages: 290
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: TRADE

Internet Open Trading Protocol - IOTP Version 1.0

Part 1 of 9, p. 1 to 28
None       Next RFC Part

 


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


                 Internet Open Trading Protocol - IOTP
                              Version 1.0

Status of this Memo

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

Copyright Notice

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

Abstract

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

Table of Contents

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

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

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

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

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

Top      ToC       Page 6 
Table of Figures

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

Top      ToC       Page 7 
1. Background

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

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

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

   In summary, IOTP supports:

   o Familiar trading models

   o New trading models

   o Global interoperability

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

1.1 Commerce on the Internet, a Different Model

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

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

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

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

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

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

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

Top      ToC       Page 9 
1.2 Benefits of IOTP

   ELECTRONIC COMMERCE SOFTWARE VENDORS

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

   PAYMENT BRANDS

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

   MERCHANTS

   There are several benefits for Merchants:

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

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

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

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

   BANKS AND FINANCIAL INSTITUTIONS

   There are also several benefits for Banks and Financial Institutions:

   o  they will be able to provide IOTP support for merchants

   o  they will find new opportunities for IOTP related services:

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

Top      ToC       Page 10 
   o  they have an opportunity to build relationships with new types of
      merchants

   CUSTOMERS

   For Customers there are several benefits:

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

   o  there is a more consistent interface when making the purchase

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

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

1.3 Baseline IOTP

   This specification is Baseline IOTP. It is a Baseline in that it
   contains ways of doing trades on the Internet which are the most
   common, for example purchases and refunds.

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

   During this period it is anticipated that there will be no changes to
   the scope of this specification with the only changes made being
   limited to corrections where problems are found. Software solutions
   have been developed based on earlier versions of this specification
   (for example version 0.9 published in early 1998 and earlier
   revisions of version 1.0 published during 1999) which prove that the
   IOTP works.

1.4 Objectives of Document

   The objectives of this document are to provide a specification of
   version 1.0 of the Internet Open Trading Protocols which can be used
   to design and implement systems which support electronic trading on
   the Internet using the Internet Open Trading Protocols.

Top      ToC       Page 11 
   The purpose of the document is:

   o  to allow potential developers of products based on the protocol to
      develop software/hardware solutions which use the protocol

   o  to allow the financial services industry to understand a
      developing electronic commerce trading protocol that encapsulates
      (without modification) any of the current or developing payment
      schemes now being used or considered by their merchant customer
      base

1.5 Scope of Document

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

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

   Payment Scheme which IOTP could support include MasterCard Credit,
   Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin,
   Millicent, Proton, etc.

   Each payment scheme contains some message flows which are specific to
   that scheme. These scheme-specific parts of the protocol are
   contained in a set of payment scheme supplements to this
   specification.

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

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

1.6 Document Structure

   The document consists of the following sections:

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

Top      ToC       Page 12 
   o  Section 2 - Introduction: This section describes the various
      Trading Exchanges and shows how these trading exchanges are used
      to construct the IOTP Transactions. This section also explains
      various Trading Roles that would participate in electronic trade.

   o  Section 3 - Protocol Structure: This section summarises how
      various IOTP transactions are constructed using the Trading Blocks
      and Trading Components that are the fundamental building blocks
      for IOTP transactions. All IOTP transaction messages are well
      formed XML documents.

   o  Section 4 - IOTP Error Handling: This section describes how to
      process exceptions and errors during the protocol message exchange
      and trading exchange processing. This section provides a generic
      overview of the exception handling. This section should be read
      carefully.

   o  Section 5 - Security Considerations: This section considers from
      an IETF perspective, how IOTP addresses security. It includes: how
      to determine whether to use digital signatures with IOTP, how IOTP
      address data privacy, and how security built into payment
      protocols relate to IOTP security.

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

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

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

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

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

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

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

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

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

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

   o  Section 16 - The Author's Address

   o  Section 17 - Full Copyright Statement

1.7 Intended Readership

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

1.7.1 Reading Guidelines

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

   Review the transport independent parts of the specification. This
   covers:

   o Section 14 - Glossary

   o Section 1 - Background

   o Section 2 - Introduction

   o Section 3 - Protocol Structure

   o Section 4 - IOTP Error Handling

Top      ToC       Page 14 
   o Section 5 - Security Considerations

   o Section 9 - Internet Open Trading Protocol Transactions

   o Section 11 - Brands

   o Section 12 - IANA Considerations

   o Section 10 - Retrieving Logos

   Review the detailed XML definitions:

   o Section 8 - Trading Blocks

   o Section 7 - Trading Components

   o Section 6 - Digital Signatures and IOTP

2. Introduction

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

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

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

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

   o  Authentication. This supports one organisation or individual to
      check that another organisation or individual are who they appear
      to be.

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

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

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

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

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

   Each of the IOTP Transactions above involve:

   o  a number of organisations playing a Trading Role, and

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

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

Top      ToC       Page 16 
2.1 Trading Roles

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

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

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

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

                    Figure 1 IOTP Trading Roles

Top      ToC       Page 17 
   The roles are:

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

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

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

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

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

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

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

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

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

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

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

Top      ToC       Page 18 
2.2 Trading Exchanges

   The Internet Open Trading Protocols identify four Trading Exchanges
   which involve the exchange of data between the Trading Roles. The
   Trading Exchanges are:

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

   o  Payment. The Payment Exchange results in a payment of some kind
      between the Consumer and the Payment Handler. This may occur in
      either direction

   o  Delivery. The Delivery Exchange transmits either the on-line
      goods, or delivery information about physical goods from the
      Delivery Handler to the Consumer, and

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

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

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

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

Top      ToC       Page 19 
2.2.1 Offer Exchange

   The goal of the Offer Exchange is for the Merchant to provide the
   Consumer with information about the trade so that the Consumer can
   decide whether to continue with the trade. This is illustrated in the
   figure below.

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

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

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

     C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
             (Consumer, DelivTo, Merchant, Payment Handler, Customer
             Care); Order; Payment; Delivery; TradingRoleData (optional)
             Offer Response Signature (optional) that signs other
             components

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

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

                           Figure 2 Offer Exchange

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

   o  the Status component is used to indicate to other parties that a
      valid Offer Response has been generated

   o  the Organisation Component contains information which describes
      the Organisations which are taking a role in the trade:

      -  the consumer provides information, about who the consumer is
         and, if goods or services are being delivered, where the goods
         or services are to be delivered to

Top      ToC       Page 20 
      -  the merchant augments this information by providing information
         about the merchant, the Payment Handler, the customer care
         provider and, if goods or services are being delivered, the
         Delivery Handler

   o  the Order Component contains descriptions of the goods or services
      which will result from the trade if the consumer agrees to the
      offer.  This information is sent by the Merchant to the consumer
      who should verify it

   o  the Payment Component generated by the Merchant, contains details
      of how much to pay, the currency and the payment direction, for
      example the consumer could be asking for a refund. Note that there
      may be more than one payment in a trade

   o  the Delivery Component, also generated by the Merchant, is used if
      goods or services are being delivered. This contains information
      about how delivery will occur, for example by post or using e-mail

   o  the Trading Role Data component contains data the Merchant wants
      to forward to another Trading Role such as a Payment Handler or
      Delivery Handler

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

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

   o  low value purchases may not need a signature

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

   o  some offers may not involve the delivery of any goods

   o  a value exchange will involve two payments

   o  a merchant may not offer customer care.

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

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

Top      ToC       Page 21 
   o  Using the Open Profiling Standard [OPS] which has recently been
      proposed,

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

   o  as Order Components in a later version of IOTP.

2.2.2 Payment Exchange

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

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

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

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

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

     C <-- M        Components: Brand List

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

     C --> M        Component: Brand List Selection

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

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

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

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

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

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

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

     C <-------> P  PAYMENT RESPONSE. Components: Status, Pay Receipt;
                    Payment Note; Trading Role Data (optional);
                    Optional Offer Response Signature; Optional
                    Payment Receipt Signature that binds the payment
                    to the Offer

 8.                 Consumer checks Payment Receipt is OK

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

                          Figure 3 Payment Exchange

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

   o  The Brand List Component contains a list of payment brands (for
      example, MasterCard, Visa, Mondex, GeldKarte), payment protocols
      (for example SET Version 1.0, Secure Channel Credit Debit (SCCD -
      the name used for a credit or debit card payment where

Top      ToC       Page 23 
      unauthorised access to account information is prevented through
      use of secure channel transport mechanisms such as SSL/TLS) as
      well as currencies/amounts that apply. The Merchant sends the
      Brand List to the Consumer. The consumer compares the payment
      brands, protocols and currencies/amounts on offer with those that
      the Consumer supports and makes a selection.

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

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

   o  The Organisation Components are generated by the Merchant. They
      contain details of the Merchant and Payment Handler Roles:

      -  the Merchant role is required so that the Payment Handler can
         identify which Merchant initiated the payment. Typically, the
         result of the Payment Handler accepting (or making) a payment
         on behalf of the Merchant will be a credit or debit transaction
         to the Merchant's account held by the Payment Handler. These
         transactions are outside the scope of this version of IOTP

      -  the Payment Handler role is required so that the Payment
         Handler can check that it is the correct Payment Handler to be
         used for the payment

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

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

   o  the Trading Role Data component contains from other roles (e.g., a
      Merchant) that needs to be  forwarded to the Payment Handler

   o  The Payment Scheme Component contains messages from the payment
      protocol used in the Trade. For example they could be SET
      messages, Mondex messages, GeldKarte Messages or one of the other
      payment methods supported by IOTP. The content of the Payment

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

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

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

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

2.2.3 Delivery Exchange

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

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  CONSUMER  DELIVERY
     |        HANDLER
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to trade and sends information
                    about what to deliver and who is to take delivery,
                    to the Merchant e.g., using HTML.

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

 2.                 Merchant checks the information provided by the
                    Consumer, adds information about how the delivery
                    will occur, information about the Organisations
                    involved in the delivery and optionally sings it
                    and sends it to the Consumer

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

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

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

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

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

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

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

                         Figure 4 Delivery Exchange

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

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

   o  The Organisation Component(s) contain details of the Deliver To,
      Delivery Handler and Merchant Roles:

      -  the Deliver To role indicates where the goods or services are
         to be delivered to

Top      ToC       Page 26 
      -  the Delivery Handler role is required so that the Delivery
         Handler can check that she is the correct Delivery Handler to
         do the delivery

      -  the Merchant role is required so that the Delivery Handler can
         identify which Merchant initiated the delivery

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

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

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

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

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

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

2.2.4 Authentication Exchange

   The goal of the Authentication Exchange is to allow one Organisation,
   for example a financial institution, to be able to check that another
   Organisation, for example a consumer, is who they appear to be.

   An Authentication Exchange involves:

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

   o  an Authenticatee - the Organisation being authenticated.

Top      ToC       Page 27 
   This is illustrated in the diagram below.

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

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

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

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

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

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

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

     1 <-- 2 AUTHENTICATION STATUS. Component: Status

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

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

                      Figure 5 Authentication Exchange

Top      ToC       Page 28 
   An Authentication Exchange uses the following Trading Components that
   are passed between the two Organisations:

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

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

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

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

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



(page 28 continued on part 2)

Next RFC Part