Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 2801


Internet Open Trading Protocol - IOTP Version 1.0

Part 9 of 9, p. 277 to 290
Prev RFC Part


prevText      Top      Up      ToC       Page 277 
14. Glossary

   This section contains a glossary of some of the terms used within
   this specification in alphabetical order.

          NAME                            DESCRIPTION

   Authenticator      The Organisation which is requesting the
                      authentication of another Organisation, and

   Authenticatee      The Organisation being authenticated by an

   Business Error     See Status Component.

   Brand              A Brand is the mark which identifies a particular
                      type of Payment Instrument. A list of Brands are
                      the payment options which are presented by the
                      Merchant to the Consumer and from which the
                      Consumer makes a selection. Each Brand may have a
                      different Payment Handler. Examples of Brands
                       o payment association and proprietary Brands,
                         for example MasterCard, Visa, American Express,
                         Diners Club, American Express, Mondex,
                         GeldKarte, CyberCash, etc.
                       o Promotional Brands (see below). These include:
                       o store Brands, where the Payment Instrument is
                         issued to a Consumer by a particular Merchant,
                         for example Walmart, Sears, or Marks and
                         Spencer (UK)
                       o coBrands, for example American Advantage Visa,
                         where an a company uses their own Brand in
                         conjunction with, typically, a payment
                         association Brand.

Top      Up      ToC       Page 278 
   Consumer           The Organisation which is to receive the benefit
                      of and typically pay for the goods or services.

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

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

   Customer Care      An Organisation that is providing customer care
   Provider           typically on behalf of a Merchant. Examples of
                      customer care include, responding to problems
                      raised by a Consumer arising from an IOTP
                      Transaction that the Consumer took part in.

   Delivery Handler   The Organisation that directly delivers the goods
                      or services to the Consumer on behalf of the
                      Merchant. Delivery can be in the form of either
                      digital goods (e.g., a [MIME] message), or
                      physically delivered using the post or a courier.

   Document Exchange  A Document Exchange consists of a set of IOTP
                      Messages exchanged between two parties that
                      implement part or all of two Trading Exchanges
                      simultaneously in order to minimise the number of
                      actual IOTP Messages which must be sent over the

                      Document Exchanges are combined together in
                      sequence to implement a particular IOTP

   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

Top      Up      ToC       Page 279 
                      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

   Error Block        An Error Block reports that a Technical Error was
                      found in an IOTP Message that was previously
                      received. Typically Technical Errors are caused by
                      errors in the XML which has been received or some
                      technical failure of the processing of the IOTP
                      Message. Frequently the generation or receipt of
                      an Error Block will result in failure of the IOTP
                      Transaction. They are distinct from Business
                      Errors, reported in a Status Component, which can
                      also cause failure of an IOTP Transaction.

   Exchange Block     An Exchange Block is sent between the two Trading
                      Roles involved in a Trading Exchange. It contains
                      one or more Trading Components. Exchange Blocks
                      are always sent after a Request Block and before a
                      Response Block in a Trading Exchange. The content
                      of an Exchange Block is dependent on the type of
                      Trading Exchange being carried out.

   IOTP Message       An IOTP Message is the outermost wrapper for the
                      document(s) which are sent between Trading Roles
                      that are taking part in a trade. It is a well
                      formed XML document. The documents it contains
                      consist of:
                       o a Transaction Reference Block to uniquely
                         identify the IOTP Transaction of which the IOTP
                         Message is part,
                       o an optional Signature Block to digitally sign
                         the Trading Blocks or Trading Components
                         associated with the IOTP Transaction
                       o an optional Error Block to report on technical
                         errors contained in a previously received IOTP
                         Message, and

Top      Up      ToC       Page 280 
                       o a collection of IOTP Trading Blocks which
                         carries the data required to carry out an IOTP

   IOTP Transaction   An instance of an Internet Open Trading Protocol
                      Transaction consists of a set of IOTP Messages
                      transferred between Trading Roles. The rules for
                      what may be contained in the IOTP Messages is
                      defined by the Transaction Type of the IOTP

   IOTP Transaction   A Transaction Type identifies the type an of IOTP
   Type               Transaction. Examples of Transaction Type include:
                      Purchase, Refund, Authentication, Withdrawal,
                      Deposit (of electronic cash). The Transaction Type
                      specifies for an IOTP Transaction:
                       o the Trading Exchanges which may be included in
                         the transaction,
                       o how those Trading Exchanges may be combined to
                         meet the business needs of the transaction
                       o which Trading Blocks may be included in the
                         IOTP Messages that make up the transaction
                       o Consult this specification for the rules that
                         apply for each Transaction Type.

   Merchant           The Organisation from whom the service or goods
                      are being obtained, who is legally responsible for
                      providing the goods or services and receives the
                      benefit of any payment made

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

   Organisation       A company or individual that takes part in a Trade
                      as a Trading Role. The Organisations may take one
                      or more of the roles involved in the Trade

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

   Payment            A Payment Instrument is the means by which
   Instrument         Consumer pays for goods or services offered by a
                      Merchant. It can be, for example:
                       o a credit card such as MasterCard or Visa;
                       o a debit card such as MasterCard's Maestro;
                       o a smart card based electronic cash Payment

Top      Up      ToC       Page 281 
                         Instrument such as a Mondex Card, a GeldKarte
                         card or a Visa Cash card
                       o a software based electronic payment account
                         such as a CyberCash's CyberCoin or DigiCash

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

   Promotional Brand  A Promotional Brand means that, if the Consumer
                      pays with that Brand, then the Consumer will
                      receive some additional benefit which can be
                      received in two ways:
                       o at the time of purchase. For example if a
                         Consumer pays with a "Walmart MasterCard" at a
                         Walmart web site, then a 5% discount might
                         apply, which means the Consumer actually pays
                       o from their Payment Instrument (card) issuer
                         when the payment appears on their statement.
                         For example loyalty points in a frequent flyer
                         scheme could be awarded based on the total
                         payments made with the Payment Instrument since
                         the last statement was issued.

                      Each Promotional Brand should be identified as a
                      separate Brand in the list of Brands offered by
                      the Merchant.

   Receipt Component  A Receipt Component is a record of the successful
                      completion of a Trading Exchange. Examples of
                      Receipt Components include: Payment Receipts, and
                      Delivery Notes. It's content may dependent on the
                      technology used to perform the Trading Exchange.
                      For example a Secure Electronic Transaction (SET)
                      payment receipt consists of SET payment messages
                      which record the result of the payment.

   Request Block      A Request Block is Trading Block that contains a
                      request for a Trading Exchange to start. The
                      Trading Components in a Request Block may be
                      signed by a Signature Block so that their
                      authenticity may be checked and to determine that
                      the Trading Exchange being requested is
                      authorised. Authorisation for a Trading Exchange
                      to start can be provided by the signatures
                      contained on Receipt Components contained in

Top      Up      ToC       Page 282 
                      Response Blocks resulting from previously
                      completed Trading Exchanges.  Examples of Request
                      Blocks are Payment Request and Delivery Request

   Response Block     A Response Block is a Trading Block that indicates
                      that a Trading Exchange is complete. It is sent by
                      the Trading Role that received a Request Block to
                      the Trading Role that sent the Request Block. The
                      Response Block contains a Status Component that
                      contains information about the completion of the
                      Trading Exchange, for example it indicates whether
                      or not the Trading Exchange completed
                      successfully. For some Trading Exchanges the
                      Response Block contains a Receipt Component that
                      forms a record of the Trading Exchange. Receipt
                      Components may be digitally signed using a
                      Signature Block to make completion non-refutable.
                      Examples of Response Blocks include Offer
                      Response, Payment Response and Delivery Response.

   Signature Block    A Signature Block is a Trading Block that contains
                      one or more digital signatures in the form of
                      Signature Components. A Signature Component may
                      digitally sign any Block or Component in any IOTP
                      Message in the same IOTP Transaction.

   Status Component   A Status Component contains information that
                      describes the state of a Trading Exchange.

                      Before the Trading Exchange is complete the Status
                      Component can indicate information about how the
                      Trading Exchange is progressing.

                      Once a Trading Exchange is complete the Status
                      Component can only indicate the success of the
                      Trading Exchange or that a Business Error has

                      A Business Error indicates that continuation with
                      the Trading Exchange was not possible because of
                      some business rule or logic, for example,
                      "insufficient funds available", rather than any
                      Technical Error associated with the content or
                      format of the IOTP Messages in the IOTP

   Technical Error    See Error Block.

Top      Up      ToC       Page 283 
   Trading Block      A Trading Block consists of one or more Trading
                      Components. One or more Trading Blocks may be
                      contained within the IOTP Messages which are
                      physically sent in the form of [XML] documents
                      between the different Trading Roles that are
                      taking part in a trade. Trading Blocks are of
                      three main types:
                       o a Request Block,
                       o an Exchange Block, or a
                       o a Response Block

   Trading Component  A Trading Component is a collection of XML
                      elements and attributes. Trading Components are
                      the child elements of the Trading Blocks. Examples
                      of Trading Components are: Offer, Brand List,
                      Payment Receipt, Delivery [information], Payment
                      Amount [information]

   Trading Exchange   A Trading Exchange consists of the exchange,
                      between two Trading Roles, of a sequence of
                      documents. The documents may be in the form of
                      Trading Blocks or they may be transferred by some
                      other means, for example through entering data
                      into a web page. Each Trading Exchange consists of
                      three main parts:
                       o the sending of a Request Block by one Trading
                         Role (the initiator) to another Trading Role
                         (the recipient),
                       o the optional exchange of one or more Exchange
                         Blocks between the recipient and the initiator,
                         until eventually,
                       o the Trading Role that received the Request
                         Block sends a Response Block to the initiator.

                      A Trading Exchange is designed to implement a
                      useful service of some kind. Examples of Trading
                      Exchanges/services are:
                       o Offer, which results in a Consumer receiving
                         an offer from a Merchant to carry out a
                         business transaction of some kind,
                       o Payment, where a Consumer makes a payment to a
                         Payment Handler,
                       o Delivery, where a Consumer requests, and
                         optionally obtains, delivery of goods or
                         services from a Delivery Handler, and
                       o Authentication, where any Trading Role may
                         request and receive information about another
                         Trading Role.

Top      Up      ToC       Page 284 
   Trading Role       A Trading Role identifies the different ways in
                      which Organisations can participate in a trade.
                      There are five Trading Roles: Consumer, Merchant,
                      Payment Handler, Delivery Handler, and Merchant
                      Customer Care Provider.

   Transaction        A Transaction Reference Block identifies an IOTP
   Reference Block    Transaction. It contains data that identifies:
                       o the Transaction Type,
                       o the IOTP Transaction uniquely, through a
                         globally unique transaction identifier
                       o the IOTP Message uniquely within the IOTP
                         Transaction, through a message identifier

                      The Transaction Reference Block may also contain
                      references to other transactions which may or may
                      not be IOTP Transactions

15. References

   This section contains references to related documents identified in
   this specification.

   [Base64]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [DOM-HASH]  Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values
               for DOM (DOMHASH)", RFC 2803, April 2000.

   [DNS]       Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.

   [DNS]       Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.

   [DSA]       The Digital Signature Algorithm (DSA) published by the
               National Institute of Standards and Technology (NIST) in
               the Digital Signature Standard (DSS), which is a part of
               the US government's Capstone project.

   [ECCDSA]    Elliptic Curve Cryptosystems Digital Signature Algorithm
               (ECCDSA). Elliptic curve cryptosystems are analogues of
               public-key cryptosystems such as RSA in which modular
               multiplication is replaced by the elliptic curve addition
               operation. See: V. S. Miller. Use of elliptic curves in
               cryptography. In Advances in Cryptology - Crypto '85,
               pages 417-426, Springer-Verlag, 1986.

Top      Up      ToC       Page 285 
   [HMAC]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
               Hashing for Message Authentication", RFC 2104, February

   [HTML]      Berners-Lee, T. and D. Connolly, "Hypertext Markup
               Language - 2.0", RFC 1866, November 1995.

   [HTML]      Hyper Text Mark Up Language. The Hypertext Mark-up
               Language (HTML) is a simple mark-up language used to
               create hypertext documents that are platform independent.
               See the World Wide Web (W3C) consortium web site at:

   [HTTP]      Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
               Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [HTTP]      Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T.
               Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.",
               RFC 2616, June 1999.

   [IANA]      The Internet Assigned Numbers Authority. The organisation
               responsible for co-ordinating the names and numbers
               associated with the Internet. See

   [ISO4217]   ISO 4217: Codes for the Representation of Currencies.
               Available from ANSI or ISO.

   [IOTPDSIG]  Davidson, K. and Y. Kawatsura, "Digital Signatures for
               the v1.0 Internet Open Trading Protocol (IOTP)", RFC
               2802, April 2000.

   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [MIME]      Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, August 1982.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Two: Media Types", RFC 2046,
               November 1996.

   [MIME]      Moore, K., "MIME (Multipurpose Internet Mail Extensions)
               Part Three: Message Header Extensions for Non-ASCII Text"
               RFC 2047, November 1996.

Top      Up      ToC       Page 286 
   [MIME]      Freed, N., Klensin, J. and J. Postel, "Multipurpose
               Internet Mail Extensions (MIME) Part Four: Registration
               Procedures", RFC 2048, November 1996.

   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Five: Conformance Criteria and
               Examples" RFC 2049, November 1996.

   [OPS]       Open Profiling Standard. A proposed standard which
               provides a framework with built-in privacy safeguards for
               the trusted exchange of profile information between
               individuals and web sites.  Being developed by Netscape
               and Microsoft amongst others.

   [RFC1738]   Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
               Resource Locators (URL)", RFC 1738, December 1994.

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

   [RSA]       RSA is a public-key cryptosystem for both encryption and
               authentication supported by RSA Data Security Inc. See:
               R. L. Rivest, A. Shamir, and L.M. Adleman. A method for
               obtaining digital signatures and public-key
               cryptosystems. Communications of the ACM, 21(2): 120-126,
               February 1978.

   [SCCD]      Secure Channel Credit Debit. A method of conducting a
               credit or debit card payment where unauthorised access to
               account information is prevented through use of secure
               channel transport mechanisms such as SSL/TLS. An IOTP
               supplement describing how SCCD works is under

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

   [SSL/TLS]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [SHA1]      [FIPS-180-1]"Secure Hash Standard", National Institute of
               Standards and Technology, US Department Of Commerce,
               April 1995. Also known as: 59 Fed Reg. 35317 (1994). See

Top      Up      ToC       Page 287 
   [UTC]       Universal Time Co-ordinated. A method of defining time
               absolutely relative to Greenwich Mean Time (GMT).
               Typically of the form:  "CCYY-MM-DDTHH:MM:SS.sssZ+n"
               where the "+n" defines the number of hours from GMT. See
               ISO DIS8601.

   [UTF16]     The Unicode Standard, Version 2.0.  The Unicode
               Consortium, Reading, Massachusetts. See ISO/IEC 10646 1
               Proposed Draft Amendment 1

   [X.509]     ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995,
               Including Draft Amendment 1: Certificate Extensions
               (Version 3 Certificate)

               Recommendation for Namespaces in XML, World Wide Web
               Consortium, 14 January 1999, "

   [XML]       Extensible Mark Up Language. A W3C recommendation. See
      for the 10
               February 1998 version.

16. Author's Address

   The author of this document is:

   David Burdett
   Commerce One
   4440 Rosewood Drive, Bldg 4
   California 94588

   Phone: +1 (925) 520 4422

   The author of this document particularly wants to thank Mondex
   International Limited ( for the tremendous support
   provided in the formative stages of the development of this

Top      Up      ToC       Page 288 
   In addition the author appreciates the following contributors to this
   protocol (in alphabetic order of company) without which it could not
   have been developed.

      -  Phillip Mullarkey, British Telecom plc

      -  Andrew Marchewka, Canadian Imperial Bank of Commerce

      -  Brian Boesch, CyberCash Inc.

      -  Tom Arnold, CyberSource

      -  Terry Allen, Commerce One (formally Veo Systems)

      -  Richard Brown, GlobeSet Inc.

      -  Peter Chang, Hewlett Packard

      -  Masaaki Hiroya, Hitachi Ltd

      -  Yoshiaki Kawatsura, Hitachi Ltd

      -  Mark Linehan, International Business Machines

      -  Jonathan Sowler, JCP Computer Services Ltd

      -  John Wankmueller, MasterCard International

      -  Steve Fabes, Mondex International Ltd

      -  Donald Eastlake 3rd, Motorola Inc (formerly International
         Business Machines Inc)

      -  Surendra Reddy, Oracle Corporation

      -  Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)

      -  Chris Smith, Royal Bank of Canada

      -  Hans Bernhard-Beykirch, SIZ (IT Development and Coordination

         Centre of the German Savings Banks Organisation)

      -  W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services,
         formally AT&T Universal Card Services)

      -  Efrem Lipkin, Sun Microsystems

Top      Up      ToC       Page 289 
      -  Tony Lewis, Visa International

   The author would also like to thank the following organisations for
   their support:

      -  Amino Communications

      -  DigiCash

      -  Fujitsu

      -  General Information Systems

      -  Globe Id Software

      -  Hyperion

      -  InterTrader

      -  Nobil I T Corp

      -  Mercantec

      -  Netscape

      -  Nippon Telegraph and Telephone Corporation

      -  Oracle Corporation

      -  Smart Card Integrations Ltd.

      -  Spyrus

      -  Verifone

      -  Unisource nv

      -  Wells Fargo Bank

Top      Up      ToC       Page 290 
17. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.