RFC 2801
Internet Open Trading Protocol - IOTP Version 1.0
Pages: 290
Informational
Informational
Part 9 of 9 – Pages 277 to 290
14. Glossary
This section contains a glossary of some of the terms used within this specification in alphabetical order. NAME DESCRIPTION Authenticator The Organisation which is requesting the authentication of another Organisation, and Authenticatee The Organisation being authenticated by an Authenticator Business Error See Status Component. Brand A Brand is the mark which identifies a particular type of Payment Instrument. A list of Brands are the payment options which are presented by the Merchant to the Consumer and from which the Consumer makes a selection. Each Brand may have a different Payment Handler. Examples of Brands include: o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, etc. o Promotional Brands (see below). These include: o store Brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK) o coBrands, for example American Advantage Visa, where an a company uses their own Brand in conjunction with, typically, a payment association Brand.
Consumer The Organisation which is to receive the benefit
of and typically pay for the goods or services.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
whenever the software which generated the content
cannot be identified from the SoftwareId attribute
on the Message Id Component (see section 3.3.2)
Customer Care An Organisation that is providing customer care
Provider typically on behalf of a Merchant. Examples of
customer care include, responding to problems
raised by a Consumer arising from an IOTP
Transaction that the Consumer took part in.
Delivery Handler The Organisation that directly delivers the goods
or services to the Consumer on behalf of the
Merchant. Delivery can be in the form of either
digital goods (e.g., a [MIME] message), or
physically delivered using the post or a courier.
Document Exchange A Document Exchange consists of a set of IOTP
Messages exchanged between two parties that
implement part or all of two Trading Exchanges
simultaneously in order to minimise the number of
actual IOTP Messages which must be sent over the
Internet.
Document Exchanges are combined together in
sequence to implement a particular IOTP
Transaction.
Dual Brand A Dual Brand means that a single Payment
Instrument may be used as if it were two separate
Brands. For example there could be a single
Japanese "UC" MasterCard which can be used as
either a UC card or a regular MasterCard. The UC
card Brand and the MasterCard Brand could each
have their own separate Payment Handlers. This
means that:
o the Merchant treats, for example "UC" and
"MasterCard" as two separate Brands when
offering a list of Brands to the Consumer,
o the Consumer chooses a Brand, for example
either "UC" or "MasterCard,
o the Consumer IOTP aware application determines
which Payment Instrument(s) match the chosen
Brand, and selects, perhaps with user
assistance, the correct Payment Instrument to
use.
Error Block An Error Block reports that a Technical Error was
found in an IOTP Message that was previously
received. Typically Technical Errors are caused by
errors in the XML which has been received or some
technical failure of the processing of the IOTP
Message. Frequently the generation or receipt of
an Error Block will result in failure of the IOTP
Transaction. They are distinct from Business
Errors, reported in a Status Component, which can
also cause failure of an IOTP Transaction.
Exchange Block An Exchange Block is sent between the two Trading
Roles involved in a Trading Exchange. It contains
one or more Trading Components. Exchange Blocks
are always sent after a Request Block and before a
Response Block in a Trading Exchange. The content
of an Exchange Block is dependent on the type of
Trading Exchange being carried out.
IOTP Message An IOTP Message is the outermost wrapper for the
document(s) which are sent between Trading Roles
that are taking part in a trade. It is a well
formed XML document. The documents it contains
consist of:
o a Transaction Reference Block to uniquely
identify the IOTP Transaction of which the IOTP
Message is part,
o an optional Signature Block to digitally sign
the Trading Blocks or Trading Components
associated with the IOTP Transaction
o an optional Error Block to report on technical
errors contained in a previously received IOTP
Message, and
o a collection of IOTP Trading Blocks which
carries the data required to carry out an IOTP
Transaction.
IOTP Transaction An instance of an Internet Open Trading Protocol
Transaction consists of a set of IOTP Messages
transferred between Trading Roles. The rules for
what may be contained in the IOTP Messages is
defined by the Transaction Type of the IOTP
Transaction.
IOTP Transaction A Transaction Type identifies the type an of IOTP
Type Transaction. Examples of Transaction Type include:
Purchase, Refund, Authentication, Withdrawal,
Deposit (of electronic cash). The Transaction Type
specifies for an IOTP Transaction:
o the Trading Exchanges which may be included in
the transaction,
o how those Trading Exchanges may be combined to
meet the business needs of the transaction
o which Trading Blocks may be included in the
IOTP Messages that make up the transaction
o Consult this specification for the rules that
apply for each Transaction Type.
Merchant The Organisation from whom the service or goods
are being obtained, who is legally responsible for
providing the goods or services and receives the
benefit of any payment made
Merchant Customer The Organisation that is involved with customer
Care Provider dispute negotiation and resolution on behalf of
the Merchant
Organisation A company or individual that takes part in a Trade
as a Trading Role. The Organisations may take one
or more of the roles involved in the Trade
Payment Handler The Organisation that physically receives the
payment from the Consumer on behalf of the
Merchant
Payment A Payment Instrument is the means by which
Instrument Consumer pays for goods or services offered by a
Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash Payment
Instrument such as a Mondex Card, a GeldKarte
card or a Visa Cash card
o a software based electronic payment account
such as a CyberCash's CyberCoin or DigiCash
account.
All Payment Instruments have a number, typically
an account number, by which the Payment Instrument
can be identified.
Promotional Brand A Promotional Brand means that, if the Consumer
pays with that Brand, then the Consumer will
receive some additional benefit which can be
received in two ways:
o at the time of purchase. For example if a
Consumer pays with a "Walmart MasterCard" at a
Walmart web site, then a 5% discount might
apply, which means the Consumer actually pays
less,
o from their Payment Instrument (card) issuer
when the payment appears on their statement.
For example loyalty points in a frequent flyer
scheme could be awarded based on the total
payments made with the Payment Instrument since
the last statement was issued.
Each Promotional Brand should be identified as a
separate Brand in the list of Brands offered by
the Merchant.
Receipt Component A Receipt Component is a record of the successful
completion of a Trading Exchange. Examples of
Receipt Components include: Payment Receipts, and
Delivery Notes. It's content may dependent on the
technology used to perform the Trading Exchange.
For example a Secure Electronic Transaction (SET)
payment receipt consists of SET payment messages
which record the result of the payment.
Request Block A Request Block is Trading Block that contains a
request for a Trading Exchange to start. The
Trading Components in a Request Block may be
signed by a Signature Block so that their
authenticity may be checked and to determine that
the Trading Exchange being requested is
authorised. Authorisation for a Trading Exchange
to start can be provided by the signatures
contained on Receipt Components contained in
Response Blocks resulting from previously
completed Trading Exchanges. Examples of Request
Blocks are Payment Request and Delivery Request
Response Block A Response Block is a Trading Block that indicates
that a Trading Exchange is complete. It is sent by
the Trading Role that received a Request Block to
the Trading Role that sent the Request Block. The
Response Block contains a Status Component that
contains information about the completion of the
Trading Exchange, for example it indicates whether
or not the Trading Exchange completed
successfully. For some Trading Exchanges the
Response Block contains a Receipt Component that
forms a record of the Trading Exchange. Receipt
Components may be digitally signed using a
Signature Block to make completion non-refutable.
Examples of Response Blocks include Offer
Response, Payment Response and Delivery Response.
Signature Block A Signature Block is a Trading Block that contains
one or more digital signatures in the form of
Signature Components. A Signature Component may
digitally sign any Block or Component in any IOTP
Message in the same IOTP Transaction.
Status Component A Status Component contains information that
describes the state of a Trading Exchange.
Before the Trading Exchange is complete the Status
Component can indicate information about how the
Trading Exchange is progressing.
Once a Trading Exchange is complete the Status
Component can only indicate the success of the
Trading Exchange or that a Business Error has
occurred.
A Business Error indicates that continuation with
the Trading Exchange was not possible because of
some business rule or logic, for example,
"insufficient funds available", rather than any
Technical Error associated with the content or
format of the IOTP Messages in the IOTP
Transaction.
Technical Error See Error Block.
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.
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.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995. [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/ [HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC 2616, June 1999. [IANA] The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/ [ISO4217] ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO. [IOTPDSIG] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIME] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [MIME] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC 2047, November 1996.
[MIME] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC 2049, November 1996. [OPS] Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others. [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RSA] RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978. [SCCD] Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development. [SET] Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>. [SSL/TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm
[UTC] Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601. [UTF16] The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate) [XML-Namespace] Recommendation for Namespaces in XML, World Wide Web Consortium, 14 January 1999, "http://www.w3.org/TR/REC- xml-names" [XML] Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.16. Author's Address
The author of this document is: David Burdett Commerce One 4440 Rosewood Drive, Bldg 4 Pleasanton California 94588 USA Phone: +1 (925) 520 4422 EMail: david.burdett@commerceone.com The author of this document particularly wants to thank Mondex International Limited (www.mondex.com) for the tremendous support provided in the formative stages of the development of this specification.
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
- 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
17. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.