One document matched: draft-ietf-trade-iotp-v1.0-protocol-00.txt
TRADE Working Group Surendra Reddy(Oracle)
Internet Draft David Burdett(Mondex)
draft-ietf-trade-iotp-v1.0-protocol-00.txt September 21,1998
Expires March 21, 1999
Internet Open Trading Protocol - IOTP
Status of this Memo
This document is an Internet draft. Internet drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas and its working groups. Note that other groups may also
distribute working information as Internet drafts.
Internet Drafts are draft documents valid for a maximum of six
months and can be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to use Internet drafts
as reference material or to cite them as other than as "work in
progress".
To learn the current status of any Internet draft please check
the "lid-abstracts.txt" listing contained in the Internet drafts
shadow directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
coast) or ftp.isi.edu (US West coast). Further information about
the IETF can be found at URL: http://www.ietf.org/
Distribution of this document is unlimited. Please send comments
to the TRADE working group at <ietf-trade@lists.elistx.com >,
which may be joined by sending a message with subject "subscribe"
to <ietf-trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at
http://www.elistx.com/archives/ietf-trade.
Abstract
The Internet Open Trading Protocol (IOTP) provides an
interoperable framework for Internet commerce. It is payment
system independent and encapsulates payment systems such as SET,
Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
handle cases where such merchant roles as the shopping site, the
payment handler, the Delivery Handler of goods or services, and
the provider of customer support are performed by different
parties or by one party.
Surendra Reddy et al. [Page 1]
Internet Draft IOTP/1.0 September 21, 1998
The developers of IOTP seek to provide a virtual capability that
safely replicates the real world, the paper based, traditional,
understood, accepted methods of trading, buying, selling, value
exchanging that has existed for many hundreds of years. The
negotiation of who will be the parties to the trade, how it will
be conducted, the presentment of an offer, the method of payment,
the provision of a payment receipt, the delivery of goods and the
receipt of goods. These are events that are taken for granted in
the course of real world trade. IOTP has been produced to provide
the same for the virtual world, and to prepare and provide for
the introduction of new models of trading made possible by the
expanding presence of the virtual world.
The other fundamental ideal of the IOTP effort is to produce a
definition of these trading events in such a way that no matter
where produced, two unfamiliar parties using electronic commerce
capabilities to buy and sell that conform to the IOTP
specifications will be able to complete the business safely and
successfully.
Acknowledgements
The Internet Open Trading Protocol has benefited from a large and
active developer community who have participated on the otp-dev
mailing list and has been most responsible for the successful
completion of this specification.
Phillip Mullarkey, British Telecom plc, Andrew Marchewka, Canadian
Imperial Bank of Commerce, Brian Boesch, CyberCash Inc., Donald
Eastlake 3rd, CyberCash Inc., Mark Linehan, International Business
Machines, Peter Chang, Hewlett Packard, Masaaki Hiroya, Hitachi
Ltd, Yoshiaki Kawatsura, Hitachi Ltd, Jonathan Sowler, JCP Computer
Services Ltd, John Wankmueller, MasterCard International, Steve
Fabes, Mondex International Ltd, Akihiro Nakano, Plat Home, Inc.
(ex Hitachi Ltd), Chris Smith, Royal Bank of Canada, Hans
Bernhard-Beykirch, SIZ (IT Development and Coordination Centre of
the German Savings Banks Organisation), W. Reid Carlisle, Spyrus
(ex Citibank Universal Card Services, formally AT&T Universal
Card Services), Efrem Lipkin, Sun Microsystems, Terry Allen, Veo
Systems deserve special recognition for their efforts in
defining early aspects of the protocol.
Table of Contents
i. Status of this Memo .......................................... 1
ii. Abstract ..................................................... 1
iii. Acknowledgements ............................................. 2
Surendra Reddy et al. [Page 2]
Internet Draft IOTP/1.0 September 21, 1998
1 Introduction .................................................... 6
1.1 Commerce on the Internet - a Different Model ................ 6
1.2 What is IOTP? ............................................... 7
1.3 Benefits of IOTP ............................................ 7
1.4 Terminology ................................................. 9
1.5 IOTP - Abstract Model ....................................... 11
1.6 Interoperability Model ...................................... 12
1.7 Document Framework .......................................... 12
1.8 Document Scope .............................................. 12
1.9 Requirements ................................................ 13
2 Internet Open Trading Protocol .................................. 13
2.1 Introduction ................................................ 14
2.2 Trading Roles ............................................... 15
2.3 Trading Exchanges ........................................... 16
2.4 Offer Exchange .............................................. 17
2.5 Payment Exchange ............................................ 18
2.6 Delivery Exchange ........................................... 20
2.7 Authentication Exchange ..................................... 22
2.8 Brands and Brand Selection .................................. 22
3 IOTP Elements ................................................... 25
3.1 IOTP Message Structure ...................................... 25
3.2 IOTP Transactions ........................................... 27
3.3 IOTP Message ................................................ 28
3.4 XML Document Prolog ......................................... 29
3.5 Transaction Reference Block ................................. 29
3.6 ID Attributes ............................................... 34
3.7 Element References .......................................... 37
3.8 Packaged Content Element .................................... 37
3.9 Extending IOTP .............................................. 39
3.10 Identifying Languages ...................................... 41
3.11 Secure and Insecure Net Locations .......................... 42
4 Internet Open Trading Protocol Transactions ..................... 42
4.1 Baseline Authentication IOTP Transaction .................... 43
4.2 Baseline Deposit IOTP Transaction ........................... 44
4.3 Baseline Purchase IOTP Transaction .......................... 49
4.4 Baseline Refund IOTP Transaction ............................ 56
4.5 Baseline Withdrawal IOTP Transaction ........................ 61
4.6 Baseline Value Exchange IOTP Transaction .................... 67
4.7 Payment Instrument Customer Care IOTP Transaction ........... 75
4.8 Baseline Transaction Status Inquiry IOTP Transactin ......... 77
4.9 Baseline Ping IOTP Transaction .............................. 80
5 Trading Blocks .................................................. 81
5.1 Trading Protocol Options Block .............................. 82
5.2 TPO Selection Block ......................................... 83
Surendra Reddy et al. [Page 3]
Internet Draft IOTP/1.0 September 21, 1998
5.3 Offer Response Block ........................................ 84
5.4 Authentication Request Block ................................ 85
5.5 Authentication Response Block ............................... 86
5.6 Payment Request Block ....................................... 86
5.7 Payment Exchange Block ...................................... 88
5.8 Payment Response Block ...................................... 88
5.9 Delivery Request Block ...................................... 89
5.10 Delivery Response Block .................................... 90
5.11 Payment Instrument Customer Care Request Block ............. 91
5.12 Payment Instrument Customer Care Exchange Block ............ 91
5.13 Payment Instrument Customer Care Response Block ............ 92
5.14 Inquiry Request Trading Block .............................. 92
5.15 Inquiry Response Trading Block ............................. 93
5.16 Ping Request Block ......................................... 94
5.17 Ping Response Block ........................................ 95
5.18 Signature Block ............................................ 97
5.19 Error Block ................................................ 98
6 Trading Components .............................................. 99
6.1 Protocol Options Component .................................. 100
6.2 Authentication Data Component ............................... 102
6.3 Authentication Response Component ........................... 103
6.4 Order Component ............................................. 104
6.5 Order Description Content ................................... 106
6.6 OkFrom and OkTo Timestamps .................................. 106
6.7 Organization Component ...................................... 107
6.8 Trading Role Element ........................................ 110
6.9 Contact Information Element ................................. 111
6.10 Person Name Element ........................................ 112
6.11 Postal Address Element ..................................... 113
6.12 Brand List Component ....................................... 114
6.13 Brand Element .............................................. 116
6.14 Protocol Amount Element .................................... 118
6.15 Currency Amount Element .................................... 120
6.16 Pay Protocol Element ....................................... 121
6.17 Brand Selection Component .................................. 123
6.18 Brand Selection Brand Info Element ......................... 125
6.19 Brand Selection Protocol Amount Info Element ............... 126
6.20 Brand Selection Currency Amount Info Element ............... 126
6.21 Payment Component .......................................... 127
6.22 Payment Scheme Component ................................... 128
6.23 Payment Receipt Component .................................. 130
6.24 Delivery Component ......................................... 131
6.25 Delivery Data Element ...................................... 133
6.26 Delivery Note Component .................................... 135
6.27 Payment Method Information Component ....................... 137
6.28 Status Component ........................................... 137
6.29 Inquiry Type Component ..................................... 142
Surendra Reddy et al. [Page 4]
Internet Draft IOTP/1.0 September 21, 1998
6.30 Signature Component ........................................ 143
6.31 Offer Response Signature Component ......................... 144
6.32 Payment Receipt Signature Component ........................ 145
6.33 Ping Signature Components .................................. 145
6.34 Error Component ............................................ 145
6.35 Error Processing Guidelines ................................ 148
6.36 Error Codes ................................................ 149
6.37 Error Location Element ..................................... 153
7 IOTP Error Handling ............................................. 154
7.1 Technical Errors ............................................ 155
7.2 Business Errors ............................................. 155
7.3 Error Depth ................................................. 156
7.4 Idempotency, Processing Sequence, and Message Flow .......... 158
7.5 Client Role Processing Sequence ............................. 163
8 Retrieving Logos ................................................ 166
8.1 Logo Size ................................................... 167
8.2 Logo Color Depth ............................................ 167
8.3 Logo Net Location Examples .................................. 168
9 Security Considerations ......................................... 168
9.1 Digital Signatures and IOTP ................................. 168
9.2 IOTP Signature Example ...................................... 169
9.3 SignerOrgRef and VerifierOrgRef Attributes .................. 169
9.4 Symmetric and Asymmetric Cryptography ....................... 170
9.5 Mandatory and Optional Signatures ........................... 170
9.6 Using signatures to Prove Actions Complete
Successfully ................................................ 171
9.7 Check the Action Request was sent to the Correct
Organization ................................................ 173
9.8 Check the Correct Components are present in the
Request Block ............................................... 175
9.9 Check an Action is Authorised ............................... 175
9.10 Data Integrity and Privacy ................................. 177
10 Internationalization ........................................... 178
11 IANA Considerations ............................................ 178
12 Copyrights ..................................................... 178
13 References ..................................................... 179
14 Appendices ..................................................... 181
14.1 IOTP DTD Specification .................................... 181
15 Author's Address ............................................... 191
Surendra Reddy et al. [Page 5]
Internet Draft IOTP/1.0 September 21, 1998
1. Introduction
1.1. Commerce on the Internet - a Different Model
The growth of the Internet and the advent of electronic commerce
are bringing about enormous changes around the world in society,
politics and government, and in business. The ways in which
trading partners communicate, conduct commerce, are governed have
been enriched and changed forever.
One of the very fundamental changes about which IOTP is concerned
is taking place in the way consumers and merchants trade.
Characteristics of trading that have changed markedly include:
- Presence: Face-to-face transactions become the exception,
not the rule. Already with the rise of mail order and
telephone order placement this change has been felt in
western commerce. Electronic commerce over the Internet will
further expand the scope and volume of transactions
conducted without ever seeing the people who are a part of
the enterprise with whom one does business.
- Authentication: An important part of personal presence is
the ability of the parties to use familiar objects and
dialogue to confirm they are who they claim to be. The
seller displays one or several well known financial logos
that declaim his ability to accept widely used credit and
debit instruments in the payment part of a purchase. The
buyer brings government or financial institution
identification that assures the seller she will be paid.
People use intangibles such as personal appearance and
conduct, location of the store, apparent quality and
familiarity with brands of merchandise, and a good clear
look in the eye to reinforce formal means of authentication.
- Payment Instruments: Despite the enormous size of bank card
financial payments associations and their members, most of
the world`s trade still takes place using the coin of the
realm or barter. The present infrastructure of the payments
business cannot economically support low value transactions
and could not survive under the consequent volumes of
transactions if it did accept low value transactions.
- Transaction Values: New meaning for low value transactions
arises in the Internet where sellers may wish to offer for
example, pages of information for fractions of currency that
do not exist in the real world.
- Delivery: New modes of delivery must be accommodated such as
direct electronic delivery. The means by which receipt is
confirmed and the execution of payment change dramatically
where the goods or services have extremely low delivery cost
Surendra Reddy et al. [Page 6]
Internet Draft IOTP/1.0 September 21, 1998
but may in fact have very high value. Or, maybe the value is
not high, but once delivery occurs the value is
irretrievably delivered so payment must be final and
non-refundable but delivery nonetheless must still be
confirmed before payment. Incremental delivery such as
listening or viewing time or playing time are other models
that operate somewhat differently in the virtual world.
1.2. What is IOTP?
The Internet Open Trading Protocol (IOTP) provides an
interoperable framework for Internet commerce. It is payment
system independent and encapsulates payment systems such as SET,
Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
handle cases where such merchant roles as the shopping site, the
payment handler, the Delivery Handler of goods or services, and
the provider of customer support are performed by different
parties or by one party.
The main goal of IOTP is to provide a virtual capability that
safely replicates the real world, the paper based, traditional,
understood, accepted methods of trading, buying, selling, value
exchanging that has existed for many hundreds of years. The
negotiation of who will be the parties to the trade, how it will
be conducted, the presentment of an offer, the method of payment,
the provision of a payment receipt, the delivery of goods and the
receipt of goods. These are events that are taken for granted in
the course of real world trade. IOTP has been produced to provide
the same for the virtual world, and to prepare and provide for
the introduction of new models of trading made possible by the
expanding presence of the virtual world.
The other fundamental goal of the IOTP effort is to define these
trading events in such a way that no matter where produced, two
unfamiliar parties using electronic commerce capabilities to buy
and sell that conform to the IOTP specifications will be able
to complete the business safely and successfully.
1.3. Benefits of IOTP
1. Electronic Commerce Software Vendors will be able to develop
e-commerce products which are more attractive as they will
inter-operate with any other vendors' software. However
since IOTP focuses on how these solutions communicate, there
is still plenty of opportunity for product differentiation.
2. IOTP provides a standard framework for encapsulating payment
protocols. This means that it is easier for payment products
Surendra Reddy et al. [Page 7]
Internet Draft IOTP/1.0 September 21, 1998
to be incorporated into IOTP solutions. As a result the
payment brands will be more widely distributed and available
on a wider variety of platforms.
3. There are several benefits for Merchants:
o they will be able to offer a wider variety of payment
brands,
o they can be more certain that the customer will have the
software needed to complete the purchase
o through receiving payment and delivery receipts from
their customers, they will be able to provide customer
care knowing that they are dealing with the individual or
organisation with which they originally traded
o new merchants will be able to enter this new (Internet)
market-place with new products and services, using the
new trading opportunities which IOTP presents
4. There are also several benefits for Banks and Financial
Institutions:
o they will be able to provide IOTP support for merchants
o they will find new opportunities for IOTP related
services:
o providing customer care for merchants
o fees from processing new payments and deposits
o they have an opportunity to build relationships with new
types of merchants
5. For Customers there are several benefits:
o they will have a larger selection of merchants with whom
they can trade
o there is a more consistent interface when making the
purchase
o there are ways in which they can get their problems fixed
through the merchant (rather than the bank!)
o there is a record of their transaction which can be used,
Surendra Reddy et al. [Page 8]
Internet Draft IOTP/1.0 September 21, 1998
for example, to feed into accounting systems or,
potentially, to present to the tax authorities
1.4. Terminology
Consumer
The person or organisation which is to receive and pay for
the goods or services
Merchant
The person or organisation from whom the purchase is being
made and who is legally responsible for providing the goods
or services and receives the benefit of the payment made
Payment Handler
The entity that physically receives the payment from the
Consumer on behalf of the Merchant
Delivery Handler
The entity that physically delivers the goods or services to
the Consumer on behalf of the Merchant.
Merchant Customer Care Provider
The entity that is involved with customer dispute
negotiation and resolution on behalf of the Merchant
Payment Instrument Customer Care Provider
The entity that resolves problems with a particular Payment
Instrument
Payment Instrument
A Payment Instrument is the means by which Consumer pays for
goods or services offered by a Merchant. It can be, for
example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash payment instrument
such as a Mondex Card, a GeldKarte card or a Visa Cash
card
o a software based electronic payment account such as a
CyberCash or DigiCash account.
All Payment Instruments have a number, typically an account
number, by which the Payment Instrument can be identified.
Surendra Reddy et al. [Page 9]
Internet Draft IOTP/1.0 September 21, 1998
Brand
A Brand is the mark which identifies a particular type of
Payment Instrument. A list of Brands are the payment
options which are presented by the Merchant to the Consumer
and from which the Consumer makes a selection. Each Brand
may have a different Payment Handler. Examples of Brands
include:
o payment association and proprietary Brands, for example
MasterCard, Visa, American Express, Diners Club, American
Express, Mondex, GeldKarte, CyberCash, etc.
o promotional brands (see below). These include:
o store brands, where the Payment Instrument is issued to a
Consumer by a particular Merchant, for example Walmart,
Sears, or Marks and Spencer (UK)
o cobrands, for example American Advantage Visa, where an
organisation uses their own brand in conjunction with,
typically, a payment association Brand.
Dual Brand
A Dual Brand means that a single payment instrument may be
used as if it were two separate Brands. For example there
could be a single Japanese "UC" MasterCard which can be used
as either a UC card or a regular MasterCard. The UC card
Brand and the MasterCard Brand could each have their own
separate Payment Handlers. This means that:
o the merchant treats, for example "UC" and "MasterCard" as
two separate Brands when offering a list of Brands to the
Consumer,
o the consumer chooses a Brand, for example either "UC" or
"MasterCard,
o the consumer IOTP aware application determines which
Payment Instrument(s) match the chosen Brand, and
selects, perhaps with user assistance, the correct
Payment Instrument to use.
Promotional Brand
A Promotional Brand means that, if the Consumer pays with
that Brand, then the Consumer will receive some additional
benefit which can be received in two ways:
Surendra Reddy et al. [Page 10]
Internet Draft IOTP/1.0 September 21, 1998
o at the time of purchase. For example if a Consumer pays
with a "Walmart MasterCard" at a Walmart web site, then a
5% discount might apply, which means the consumer
actually pays less,
o from their Payment Instrument (card) issuer when the
payment appears on their statement. For example loyalty
points in a frequent flyer scheme could be awarded based
on the total payments made with the Payment Instrument
since the last statement was issued.
each Promotional Brand should be identified as a separate
Brand in the list of Brands offered by the Merchant. For
example: "Walmart", "Sears", "Marks and Spencer" and
"American Advantage Visa", would each be a separate Brand.
1.5. IOTP - Abstract Model
The Internet Open Trading Protocol is described as a set of IOTP
messages trasnferred between the Trading Roles. The IOTP message is
a collection of IOTP Trading Blocks which carries the specification
Trading Transaction. Following sections describe each component
in detail:
1.5.1. Trading Roles:
Trading Roles identify the different parts which organizations
can participate in trade. There are five trading roles: Consumer,
Merchant, Payment Handler, Delivery Handler, Merchant Customer
Care Provider and Payment Instrument Customer Care Provider. A
Trading Role (OTR) performs a trading transactions using a IOTP
USER AGENT (OUA). A OUA uses the IOTP Transport-Independent
Interoperability Protocol (IOTP) to deliver Trading Components to
a Trading Role.
1.5.2. IOTP Messages
IOTP messages are well formed XML document sent between the IOTP
trading roles that are taking part in a trade.
1.5.3. Trading Transactions
A predefined set of IOTP Messages exchanged between the Trading
Roles constitute an IOTP Transaction.
1.5.4. Trading Blocks
Trading Blocks consist of one or more Trading Components and
optionally one or more Signature Components. One or more Trading
Blocks may be contained within the IOTP Messages which are
physically sent in the form of [XML] documents between the
different organizations that are taking part in a trade.
Surendra Reddy et al. [Page 11]
Internet Draft IOTP/1.0 September 21, 1998
1.5.5. Trading Components
Trading Components are collections of property values. Trading
Components are the child elements of the Trading Blocks.
1.5.6. Properties
Properties are attributes of a Trading Component. They consist of
a name and a value. Properties are strongly typed. Some
properties are multi-valued.
1.6. Interoperability Model
There are two distinct protocols relevant to interoperability: an
"Application Protocol" and a "Transport Protocol". The
Application Protocol defines the content of the IOTP objects sent
between Trading Roles. The Transport Protocol defines how the IOTP
objects are sent between the sender and reciver. This document
focuses on the Application Protocol. Binding documents such as
[IOTP/HTTP] focus on the Transport Protocol.
1.7. Document Framework
Internet Open Trading Protocol is contained in a series of
related documents. This section describes the relationship
between the documents.
1.7.1. IOTP - Core Object Specification and Transport Independent
Trading Protocol
The IOTP, this document, is the dictionary Trading Blocks, Trading
Components and Transactions for Internet Trading protocol. It provides
the authoritative definition of all properties that may be used in
the Internet Open Trading protocols as well as the rules for
encoding and representing the trading objects that are
constructed from those properties. This document also specifies
how different systems use Trading Components to interoperate with
other systems. It does so in a general way so as to allow
multiple methods of communication between systems.
1.7.2. IOTP/HTTP: Binding of IOTP to HTTP
This document specifies an IOTP protocol over HTTP.
1.8. Document Scope
The Internet Open Trading Protocol (IOTP) is an application-level
protocol to provide an interoperable framework for Internet
commerce. The first version of IOTP, referred to as IOTP/1.0,
is a simple protocol for exchanging IOTP messages between
trading roles participating in e-commerce over the Internet.
This specification defines the protocol referred to as
Surendra Reddy et al. [Page 12]
Internet Draft IOTP/1.0 September 21, 1998
"IOTP/1.0". This protocol is designed to be applicable to any
electronic payment scheme since it targets the complete purchase
process where the movement of electronic value from the payer to
the payee is only one, but important, step of many that may be
involved to complete the trade.
The protocol describes the content, format and sequences of
messages that pass among the participants in an electronic trade
- consumers, merchants and banks or other financial institutions,
and customer care providers. These are required to support the
electronic commerce transactions outlined in the objectives
above.
Payment Scheme which IOTP could support include MasterCard Credit,
Visa Credit, Mondex Cash, Visa Cash, GeldKarte, DigiCash,
CyberCoin, Millicent, Proton etc. Each payment scheme contains
some message flows which are specific to that scheme. These
scheme-specific parts of the protocol are contained in a set of
payment scheme supplements to this specification.
The document does not prescribe the software and processes that
will need to be implemented by each participant. It does describe
the framework necessary for trading to take place.
This document also does not address any legal or regulatory
issues surrounding the implementation of the protocol or the
information systems which use them.
1.9. Requirements
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL
NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
OPTIONAL in this document are to be interpreted as described in
RFC 2119.
An implementation is not compliant if it fails to satisfy one or
more of the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be unconditionally
compliant; one that satisfies all the MUST requirements but not
all the SHOULD requirements for its protocols is said to be
conditionally compliant.
2. Internet Open Trading Protocol
Surendra Reddy et al. [Page 13]
Internet Draft IOTP/1.0 September 21, 1998
2.1. Introduction
The Internet Open Trading Protocol (IOTP) provides an
interoperable framework for Internet commerce. It is payment
system independent and encapsulates payment systems such as SET,
Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
handle cases where such merchant roles as the shopping site, the
payment handler, the Delivery Handler of goods or services, and
the provider of customer support are performed by different
parties or by one party.
The developers of IOTP seek to provide a virtual capability that
safely replicates the real world, the paper based, traditional,
understood, accepted methods of trading, buying, selling, value
exchanging that has existed for many hundreds of years. The
negotiation of who will be the parties to the trade, how it will
be conducted, the presentment of an offer, the method of payment,
the provision of a payment receipt, the delivery of goods and the
receipt of goods. These are events that are taken for granted in
the course of real world trade. IOTP has been produced to provide
the same for the virtual world, and to prepare and provide for
the introduction of new models of trading made possible by the
expanding presence of the virtual world.
The other fundamental ideal of the IOTP effort is to produce a
definition of these trading events in such a way that no matter
where produced, two unfamiliar parties using electronic commerce
capabilities to buy and sell that conform to the IOTP
specifications will be able to complete the business safely and
successfully.
The Internet Open Trading Protocols (IOTP) define a number of
different types of IOTP Transactions:
- Purchase. This supports a purchase involving an offer, a
payment and optionally a delivery
- Refund. This supports the refund of a payment as a result
of, typically, an earlier purchase
- Value Exchange. This involves two payments which result in
the exchange of value from one combination of currency and
payment method to another
- Authentication. This supports the remote authentication of a
Consumer by another Trading Role using a variety of
authentication methods, and the provision of an Organisation
Component about a Consumer to another Trading Role for use
in, for example the creation of an offer
- Withdrawal. This supports the withdrawal of electronic cash
from a financial institution
Surendra Reddy et al. [Page 14]
Internet Draft IOTP/1.0 September 21, 1998
- Deposit. This supports the deposit of electronic cash at a
financial institution
- Payment Instrument Customer Care. This supports the
provision of Payment Brand or Payment Method specific
customer care of a Payment Instrument
- Inquiry This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
- Ping This supports a simple query which enables one IOTP
aware application to determine whether another IOTP
application running elsewhere is working or not.
These IOTP Transactions are "Baseline" transactions since they
have been identified as a minimum useful set of transactions.
Later versions of IOTP may include additional types of
transactions.
Each of the IOTP Transactions above involve:
- a number organisations playing a Trading Role, and
- a set of Trading Exchanges. Each Trading Exchange involves
the exchange of data, between Trading Roles, in the form of
a set of Trading Components.
Trading Roles, Trading Exchanges and Trading Components are
described below.
2.2. Trading Roles
The Trading Roles identify the different parts which
organisations can take in a trade. The five Trading Roles used
within IOTP are:
- Consumer
- Merchant
- Payment Handler
- Delivery Handler
- Merchant Customer Care Provider
- Payment Instrument Customer Care Provider
Roles may be carried out by the same organisation or different
organisations. For example:
- in the simplest case one physical organisation (e.g. a
merchant) could handle the purchase, accept the payment,
deliver the goods and provide merchant customer care
- at the other extreme, a merchant could handle the purchase
but instruct the consumer to pay a bank or financial
Surendra Reddy et al. [Page 15]
Internet Draft IOTP/1.0 September 21, 1998
institution, request that delivery be made by an overnight
courier firm and to contact an organisation which provides
24x7 service if problems arise.
Note that in this specification, unless stated to the contrary,
when the words Consumer, Merchant, Payment Handler, Delivery
Handler or Customer Care Provider are used, they refer to the
Trading Role rather than an actual organisation.
An individual organisation may take multiple roles. For example a
company which is selling goods and services on the Internet could
take the role of Merchant when selling goods or services and the
role of Consumer when the company is buying goods or services
itself.
As roles occur in different places there is a need for the
organisations involved in the trade to exchange data, i.e. to
carry out Trading Exchanges, so that the trade can be completed.
2.3. Trading Exchanges
The Internet Open Trading Protocols identify four Trading Exchanges
which involve the exchange of data between the Trading Roles. The
Trading Exchanges are:
- Offer. The Offer Exchange results in the Merchant providing
the Consumer with the reason why the trade is taking place.
It is called an Offer since the Consumer must accept the
Offer if a trade is to continue
- Payment. The Payment Exchange results in a payment of some
kind between the Consumer and the Payment Handler. This may
occur in either direction
- Delivery. The Delivery Exchange transmits either the on-line
goods, or delivery information about physical goods from the
Delivery Handler to the Consumer, and
- Authentication. The Authentication Exchange can be used by
any Trading Role to authenticate another Trading Role to
check that they are who they appear to be.
- IOTP Transactions are composed of various combinations of
these Trading Exchanges. For example, an IOTP Purchase
transaction includes Offer, Payment, and Delivery Trading
Exchanges. As another example, an IOTP Value Exchange
transaction is composed of an Offer Trading Exchange and two
Payment Trading Exchanges.
Trading Exchanges consist of Trading Components that are
transmitted between the various Trading Roles. Where possible,
the number of round-trip delays in an IOTP Transaction is
Surendra Reddy et al. [Page 16]
Internet Draft IOTP/1.0 September 21, 1998
minimised by packing the Components from several Trading
Exchanges into combination IOTP Messages. For example, the IOTP
Purchase transaction combines a Delivery Organisation Component
with an Offer Response Component in order to avoid an extra
Consumer request and response.
Each of the IOTP Trading Exchanges is described in more detail
below. For clarity of description, these describe the Trading
Exchanges as though they were standalone operations. For
performance reasons, the Trading Exchanges are intermingled in
the actual IOTP Transaction definitions.
2.4. Offer Exchange
The goal of the Offer Exchange is for the Merchant to provide the
Consumer with information about the trade so that the Consumer
can decide whether to continue with the trade. This is explained
through following steps:
- Consumer decides to pay (request an offer) and sends
information on what to purchase to the merchant
- Merchant checks the information provided by the Consumer,
creates an Offer and sends it to the Consumer
- Consumer checks the information from the merchant and
decides whether to continue
An Offer Exchange uses the following Trading Components that are
passed between the Consumer and the Merchant:
- the Organisation Component contains information which
describes the organisations which are taking a role in the
trade:
- the consumer provides information, about who the consumer is
and, if goods or services are being delivered, where the
goods or services are to be delivered to
- the merchant augments this information by providing
information about the merchant, the Payment Handler, the
customer care provider and, if goods or services are being
delivered, the Delivery Handler
- the Order Component contains descriptions of the goods or
services which will result from the trade if the consumer
agrees to the offer. This information is sent by the
Merchant to the consumer who should verify it
- the Payment Component generated by the Merchant, contains
details of how much to pay, the currency and the payment
direction, for example the consumer could be asking for a
refund. Note that there may be more than one payment in a
Surendra Reddy et al. [Page 17]
Internet Draft IOTP/1.0 September 21, 1998
trade
- the Delivery Component, also generated by the Merchant, is
used if goods or services are being delivered. This contains
information about how delivery will occur, for example by
post or using e-mail
- the "Offer Response" Signature Component, if present,
digitally signs all of the above components to ensure their
integrity.
The exact content of the information provided by the Merchant to
the Consumer will vary depending on the type of IOTP Transaction.
For example:
- low value purchases may not need a signature
- the amount to be paid may vary depending on the payment
brand and payment protocol used
- some offers may not involve the delivery of any goods
- a value exchange will involve two payments
- a merchant may not offer customer care.
Information provided by the consumer to the merchant could be
provided using a variety of methods, for example, it could be
provided:
- using [HTML] pages as part of the "shopping experience" of
the consumer.
- using the Open Profiling Standard [OPS] which has recently
been proposed, in the form of Organisation and Order
Components in a later version of IOTP.
2.5. Payment Exchange
The goal of the Payment Exchange is for a payment to be made from
the Consumer to a Payment Handler or vice versa using a payment
brand and payment protocol selected by the Consumer. A secondary
goal is to optionally provide the Consumer with a digitally
signed Payment Receipt which can be used to link the payment to
the reason for the payment as described in the Offer Exchange.
Payment Exchanges can work in a variety of ways. The most general
case where the trade is dependent on the payment brand and
protocol used is illustrated in the diagram below. Simpler
payment exchanges are possible.
- Consumer decides to trade and sends information on what to
purchase to the merchant
- Merchant decides which payment brand and payment protocols
Surendra Reddy et al. [Page 18]
Internet Draft IOTP/1.0 September 21, 1998
to offer, places them in a Brand List Component and sends
them to the Consumer
- Consumer selects the payment brand and protocol to use,
creates a Brand Selection Component and sends it to the
Merchant
- Merchant checks Brand Selection, creates Payment Amount
information, optionally signs it to authorize payment and
sends it to the Consumer
- Consumer checks the Payment Amount information and if OK
requests that the payment starts by sending information to
the Payment Handler
- Payment Handler checks information including optional
signature and if OK starts exchanging Pay Scheme Component
using messages for selected payment brand and payment
protocol
- When payment protocol messages are finished Payment Hander
sends Pay Receipt and optional signature to Consumer as
proof of payment
- Consumer checks if Pay Receipt is OK
A Payment Exchange uses the following Trading Components that are
passed between the Consumer, the Merchant and the Payment
Handler:
- The Brand List Component contains a list of payment brands
(for example, MasterCard, Visa, Mondex, GeldKarte) and
payment protocols (for example SET Version 1.0, Secure
Channel Credit Debit (SCCD - the name used for a credit or
debit card payment where unauthorised access to account
information is prevented through use of secure channel
transport mechanisms such as SSL). The Merchant sends the
Brand List to the Consumer. The consumer compares the
payment brands and protocols on offer with those that the
Consumer supports and makes a selection.
- The Brand Selection Component contains the Consumer's
selection. Payment brand, protocol and possibly protocol-
specific information is sent back to the Merchant. This
information may be used to change information in the Offer
Exchange. For example, a merchant could choose to offer a
discount to encourage the use of a store card.
- The Organisation Components are generated by the Merchant.
They contain details of the Merchant and Payment Handler
Roles:
o the Merchant role is required so that the Payment Handler
can identify which Merchant initiated the payment.
Typically, the result of the Payment Handler accepting
(or making) a payment on behalf of the Merchant will be a
Surendra Reddy et al. [Page 19]
Internet Draft IOTP/1.0 September 21, 1998
credit or debit transaction to the Merchant's account
held by the Payment Handler. These transactions are
outside the scope of IOTP
o the Payment Handler role is required so that the Payment
Handler can check that it is the correct Payment Handler
to be used for the payment
- The optional Authentication Data Component contains
challenge data which is used by the payment protocol to
authenticate the consumer. Authentication may not always
occur
- The Payment Component contains details of how much to pay,
the currency and the payment direction, and identifies the
Authentication Data Component to use.
- The "Offer Response" Signature Component, if present,
digitally signs all of the above components to ensure their
integrity. Note that the Brand List and Brand Selection
Components are not signed until the payment information is
created.
- The Payment Scheme Component contains messages from the
payment protocol used in the Trade. For example they could
be SET messages, Mondex messages, GeldKarte Messages or one
of the other payment methods supported by IOTP. The content
of the Payment Scheme Component is defined in the
supplements that describe how IOTP works with various payment
protocols.
- The Payment Receipt Component contains a record of the
payment. The content depends upon the payment protocol used.
- The "Payment Receipt" Signature Component provides proof of
payment by digitally signing both the Payment Receipt
Component and the Offer Signature. The signature on the
offer digitally signs the Order, Organisation and Delivery
Components contained in the Offer. This signature
effectively binds the payment to the offer.
The example of a Payment Exchange above is the most general case.
Simpler cases are also possible. For example, if the amount paid
is not dependent on the payment brand and protocol selected then
the payment information generated can be sent to the Consumer at
the same time as the Brand List Component generated. These and
other variations are described in the Baseline Purchase IOTP
Transaction (see section 5.20).
2.6. Delivery Exchange
The goal of the Delivery Exchange is to cause purchased goods to
be delivered to the consumer either online or via physical
Surendra Reddy et al. [Page 20]
Internet Draft IOTP/1.0 September 21, 1998
delivery. A second goal is to provide a "delivery note" to the
consumer, providing details about the delivery, such as shipping
tracking number. A future goal is to have a signed delivery that
can be used for customer care in the case of problems with
physical delivery. This is illustrated in the diagram below.
- Consumer decides to trade and sends information about what
to deliver and who is to take delivery, to the merchant
- Merchant checks the information provided by the Consumer,
adds information about how the delivery will occur,
information about the organizations involved in the delivery
and optionally signs it
- Consumer checks the delivery information is OK, obtains
authorization for delivery(for example, by making a
payment), and sends the delivery information to the Delivery
Handler
- Delivery Handler checks information and authorization,
starts or schedule delivery and creates and then sends
Delievery Note to the Consumer
- Consumer checks delivery note is OK and accepts or waits for
delivery as described in the Delivery Note
A Delivery Exchange uses the following Trading Components that
are passed between the Consumer, the Merchant and the Delivery
Handler:
The Organisation Component(s) contain details of the Deliver
To, Delivery Handler and Merchant Roles:
- the Deliver To role indicates where the goods or services
are to be delivered to
- the Delivery Handler role is required so that the Delivery
Handler can check that she is the correct Delivery Handler
to do the delivery
- the Merchant role is required so that the Delivery Handler
can identify which Merchant initiated the delivery
- The Order Component, contains information about the goods or
services to be delivered
- The Delivery Component contains information about how
delivery will occur, for example by post or using e-mail.
- The "Offer Response" Signature Component, if present,
digitally signs all of the above components to ensure their
integrity.
- The " Payment Receipt" Signature Component provides proof of
payment by digitally signing the Payment Receipt Component
and the Offer Signature. This is used by the Delivery
Handler to check that delivery is authorised
- The Delivery Note Component contains customer care
Surendra Reddy et al. [Page 21]
Internet Draft IOTP/1.0 September 21, 1998
information related to a physical delivery, or alternatively
the actual "electronic goods". The Consumer's software does
not interpret information about a physical delivery but
should have the ability to display the information, both at
the time of the delivery and later if the Consumer selects
the Trade to which this delivery relates from a transaction
list.
2.7. Authentication Exchange
The goal of the Authentication Exchange is to allow one
organisation, for example a financial institution, to be able to
check that another organisation, for example a consumer, is who
they appear to be. It uses a "challenge-response" mechanism. This
is illustrated in the diagram below.
- First organization send a request for authentication to the
second organization
- The Second organization generates Authentication Data
containing challenge data and the method of authentication
to be used and then sends it to the first organization
- The first organization uses the challenge data with the
specified authentication method to generate an
Authentication Response which is sent back to the second
organization
- The Authentication Response is checked against the challenge
data to check that the first organization is who they appear
to be.
An Authentication Exchange uses the following Trading Components
that are passed between the two organisations:
- the Authentication Data Component which contains the
challenge data to be used in the "challenge-response"
mechanism and indicates the authentication method to be
used. It is sent by one organisation to the other.
- the Authentication Response Component which contains the
challenge response generated by the recipient of the
Authentication Data Component. It is sent back to the first
organisation for verification.
2.8. Brands and Brand Selection
One of the key features of IOTP is the ability for a merchant to
offer a list of Brands from which a consumer may make a
selection. This section provides an overview of what is involved
and provides guidance on how selection of a brand and associated
payment instrument can be carried out by a Consumer. It covers:
Surendra Reddy et al. [Page 22]
Internet Draft IOTP/1.0 September 21, 1998
definitions of Payment Instruments and Brands - what are
Payment Instruments and Brands in an IOTP context. Further
categorises Brands as optionally a "Dual Brand" or a
"Promotional Brand",
identification and selection of Promotional Brands -
Promotional Brands offer a Consumer some additional benefit,
for example loyalty points or a discount. This means that
both Consumers and Merchant must be able to correctly
identify that a valid Promotional Brand is being used.
Also see the following sections:
Brand List Component (section 6.12) which contains
definitions of the XML elements which contain the list of
Brands offered by a Merchant to a Consumer, and
Brand Selection Component (section 6.17) for details of how
a Consumer records the Brand that was selected.
2.8.1. Identifying Promotional Brands
There are two problems which need to handled in identifying
Promotional Brands:
- how does the Merchant or their Payment Handler positively
identify the promotional brand being used at the time of
purchase
- how does the Consumer reliably identify the correct
promotional brand from the Brand List presented by the
Merchant
The following is a description of how this could be achieved.
2.8.2. Merchant/Payment Handler Identification of Promotional
Brands
Correct identification that the Consumer is paying using a
Promotional Brand is important since a Consumer might
fraudulently claim to have a Promotional Brand that offers a
reduced payment amount when in reality they do not.
Two approaches seem possible:
- use some feature of the Payment Instrument or the payment
method to positively identify the Brand being used. For
example, the SET certificate for the Brand could be used, if
one is available, or
- use the Payment Instrument (card) number to look up
Surendra Reddy et al. [Page 23]
Internet Draft IOTP/1.0 September 21, 1998
information about the Payment Instrument on a Payment
Instrument issuer database to determine if the Payment
Instrument is a promotional brand
Note that:
- the first assumes that SET is available.
- the second is only possible if the Merchant, or
alternatively the Payment Handler, has access to card issuer
information.
IOTP does not provide the Merchant with Payment Instrument
information (e.g. a card or account number). This is only sent as
part of the encapsulated payment protocol to a Payment Handler.
This means that:
- the Merchant would have to assume that the Payment
Instrument selected was a valid Promotional Brand, or
- the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the
payment if it was not.
A Payment Handler checking that a brand is a valid Promotional
Brand is most likely if the Payment Handler is also the Card
Issuer.
2.8.3. Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional
Brand are:
- the Consumer visually matching a logo for the Promotional
Brand which has been provided to the Consumer by the
Merchant,
- the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered
against a similar code contained in the list of Brands
offered by the Merchant.
In the latter case, the code contained in the Consumer wallet
must match exactly the code in the list offered by the Merchant
otherwise no match will be found. Ways in which the Consumer's
IOTP Aware Application could obtain such a code include:
- the Consumer types the code in directly. This is error prone
and not user friendly, also the consumer needs to be
provided with the code. This approach is not recommended,
- using some information contained in the software or other
data associated with the Payment Instrument. This could be:
o a SET certificate for Brands which use this payment
Surendra Reddy et al. [Page 24]
Internet Draft IOTP/1.0 September 21, 1998
method
o a code provided by the payment software which handles the
particular payment method, this could apply to, for
example, GeldKarte, Mondex, CyberCash and DigiCash
- the consumer making a initial "manual" link between a
Promotional Brand in the list of Brands offered by the
Merchant and an individual Payment Instrument, the first
time the promotional brand is used. The IOTP Aware
application would then "remember" the code for the
Promotional Brand for use in future purchases
Note: It is not the intention of the developers of this
specification to develop a prescriptive list of payment brands.
It is anticipated that owners of brands will develop distinctive
names for Brands which should mean that name clashes are
unlikely.
3. IOTP Elements
This section describes:
- how Trading Components are constructed into Trading Blocks
and the IOTP Messages which are physically sent in the form
of [XML] documents between the different Trading Roles,
- how IOTP Messages are exchanged between Trading Roles to
create an IOTP Transaction
- the XML definitions of an IOTP Message including a
Transaction Reference Block - an XML element which
identifies an IOTP Transaction and the IOTP Message within it
- the definitions of the XML ID Attributes which are used to
identify IOTP Messages, Trading Blocks and Trading Components
and how these are referred to using Element References from
other XML elements such as
- IOTP Signature Components which use digital signature
techniques to preserve the integrity of IOTP Messages and
provide the trust relationships required by IOTP
- how extra XML Elements and new user defined values for
existing IOTP codes can be used when Extending IOTP, and
finally
3.1. IOTP Message Structure
The structure of an IOTP Message and its relationship with Trading
Blocks and Trading Components is illustrated in the diagram
Surendra Reddy et al. [Page 25]
Internet Draft IOTP/1.0 September 21, 1998
below.
IOTP Message
|
|
+--------- Trans Ref Block
| |
| +- Tran Id Comp
| +- Msg Id Comp
| .
+--------- Signature Block
| +- Signature
| +- Certificate
| .
| .
+--------- Trading Block
| +- Component
| +- Component
| .
| .
+--------- Trading Block
| +- Component
| +- Component
. .
. .
. .
IOTP Message Structure
IOTP Message is an XML document which is transported between the
trading roles.
Transaction Reference Block describes the IOTP transaction and IOTP
message.
Transaction Id Component uniquely identifies the IOTP transaction
Message Id Component identifies and describes an IOTP message
within an IOTP transaction
Signature Block is optional and if present it contains one or
more Signature Components and their associated certificates
Trading Block is an XML element within an IOTP message that
contains a predefined set of Trading Components
Surendra Reddy et al. [Page 26]
Internet Draft IOTP/1.0 September 21, 1998
Trading Components are XML elements within an IOTP message and
contains a predefined set of XML elements and attributes
containing information required to support trading exchange.
The diagram also introduces the concept of a Transaction
Reference Block. This block contains, amongst other things, a
globally unique identifier for the IOTP Transaction. Also each
block and component is given an ID Attribute (see section 3.6)
which is unique within an IOTP Transaction. Therefore the
combination of the ID attribute and the globally unique
identifier in the Transaction Reference Block is sufficient to
uniquely identify any Trading Block or Trading Component.
3.2. IOTP Transactions
A predefined set of IOTP Messages exchanged between the Trading
Roles constitute an IOTP Transaction. IOTP Messages can be
transported using a variety of transport mechanisms.
The IOTP Transactions in this version of IOTP are specifically:
Purchase. This supports a purchase involving an offer, a
payment and optionally a delivery
Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase
Value Exchange. This involves two payments which result in the
exchange of value from one combination of currency and
payment method to another
Authentication. This supports the remote authentication of a
Consumer by another Trading Role using a variety of
authentication methods, and the provision of an Organisation
Component about a Consumer to another Trading Role for use
in, for example the creation of an offer
Withdrawal. This supports the withdrawal of electronic cash
from a financial institution
Deposit. This supports the deposit of electronic cash at a
financial institution
Payment Instrument Customer Care. This supports the provision
of Payment Brand or Payment Method specific customer care of
a Payment Instrument
Surendra Reddy et al. [Page 27]
Internet Draft IOTP/1.0 September 21, 1998
Inquiry This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
Ping This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application
running elsewhere is working or not.
3.3. IOTP Message
As described earlier, IOTP Messages are [XML] documents which are
physically sent between the different organisations that are
taking part in a trade.
The XML definition of an IOTP Message is as follows.
<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayInstCCExchBlk |
PayInstCCReqBlk |
PayInstCCRespBlk
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk |
)*
) >
Content:
TransRefBlk This contains information which describes an
IOTP Message within an IOTP Transaction (see
section 3.5 immediately below)
AuthReqBlk, AuthRespBlk, DeliveryReqBlk, DeliveryRespBlk, ErrorBlk
InquiryReqBlk, InquiryRespBlk, OfferRespBlk, PayExchBlk, PayReqBlk,
PayInstCCExchBlk, PayInstCCReqBlk, PayInstCCRespBlk PayRespBlk,
PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk
Surendra Reddy et al. [Page 28]
Internet Draft IOTP/1.0 September 21, 1998
3.4. XML Document Prolog
The IOTP Message is the root element of the XML document. It
therefore needs to be preceded by an appropriate XML Document
Prolog. For example:
<?XML Version='1.0'?>
<!DOCTYPE OtpMessage >
<OtpMessage>
...
</OtpMessage>
3.5. Transaction Reference Block
A Transaction Reference Block contains information which
identifies the IOTP Transaction and IOTP Message. The Transaction
Reference Block contains:
- a Transaction Id Component which globally uniquely
identifies the IOTP Transaction. The Transaction Id
Components are the same across all IOTP messages that
comprise a single IOTP transaction,
- a Message Id Component which provides control information
about the IOTP Message as well as uniquely identifying the
IOTP Message within an IOTP Transaction, and
- zero or more Related To Components which link this IOTP
Transaction to either other IOTP Transactions or other events
using the identifiers of those events.
The definition of a Transaction Reference Block is as follows:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Transaction Reference Block within the IOTP
Transaction (see section 3.6 ID Attributes).
Content:
TransId See 3.5.1 Transaction Id Component
immediately below.
MsgId See 3.5.2 Message Id Component immediately
Surendra Reddy et al. [Page 29]
Internet Draft IOTP/1.0 September 21, 1998
below.
RelatedTo See 3.5.3 Related To Component immediately
below.
3.5.1. Transaction Id Component
This contains information which globally uniquely identifies the
IOTP Transaction. Its definition is as follows:
<!ELEMENT TransId EMPTY>
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
OtpTransId NMTOKEN #REQUIRED
OtpTransType CDATA #REQUIRED >
TransTimeStamp CDATA #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP
Transaction.
Version This identifies the version of IOTP, and
therefore the structure of the IOTP Messages,
which the IOTP Transaction is using.
OtpTransId Contains data which uniquely identifies the
IOTP Transaction. It must conform to the
rules for Message Ids in [RFC 822].
OtpTransType This is the type of IOTP Transaction being
carried out. For Baseline IOTP it identifies
a "standard" IOTP Transaction and implies the
sequence and content of the IOTP Messages
exchanged between the Trading Roles. The
valid values for Baseline IOTP are:
BaselineAuthentication
BaselineDeposit
BaselinePurchase
BaselineRefund
BaselineWithdrawal
BaselineValueExchange
BaselineInquiry
BaselinePing
BaselinePayInstrumentCustomerCare
Surendra Reddy et al. [Page 30]
Internet Draft IOTP/1.0 September 21, 1998
x-ddd:nnn
A value for OtpTransType of x-ddd:nnn
indicates a user defined transaction type.
See section 3.9.3 User Defined Codes.
In later versions of IOTP, this list will be
extended to support different types of
standard IOTP Transaction based on market
demand. It is also likely to support the
type Dynamic which indicates that the
sequence of steps within the transaction are
non-standard.
TransTimeStamp Where the system initiating the IOTP
Transaction has an internal clock, it is set
to the time at which the IOTP Transaction
started in [UTC] format.
The main purpose of this attribute is to
provide an alternative way of identifying a
transaction by specifying the time at which
it started.
Some systems, for example, hand held devices
may not be able to generate a time stamp.
In this case this attribute should contain
the value "NA" for Not Available.
3.5.2. Message Id Component
The Message Id Component provides control information about the
IOTP Message as well as uniquely identifying the IOTP Message
within an IOTP Transaction. Its definition is as follows.
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespOtpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
IOTP Message within the IOTP Transaction (see
section 3.6 ID Attributes). Note that if an
IOTP Message is resent then the value of this
Surendra Reddy et al. [Page 31]
Internet Draft IOTP/1.0 September 21, 1998
attribute remains the same.
RespOtpMsg This contains the ID attribute of the
Message Id Component of the IOTP Message to
which this IOTP Message is a response. In
this way all the IOTP Messages in an IOTP
Transaction are unambiguously linked
together. This field is required on every
IOTP Message except the first IOTP Message in
an IOTP Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
SoftwareId This contains information which identifies
the software which generated the IOTP
Message. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
TimeStamp Where the device sending the message has an
internal clock, it is set to the time at
which the IOTP Message was created in [UTC]
format.
3.5.3. Related To Component
The Related To Component links IOTP Transactions to either other
IOTP Transactions or other events using the identifiers of those
events. Its definition is as follows.
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Surendra Reddy et al. [Page 32]
Internet Draft IOTP/1.0 September 21, 1998
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Related To Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
RelationshipType Defines the type of the relationship. Valid
values are:
OtpTransaction. in which case the Packaged
Content Element contains an OtpTransId of
another IOTP Transaction
Reference in which case the Packaged Content
Element contains the reference of some
other, non-IOTP document.
x-ddd:nnn a user defined code (see section
3.9.3)
Relation The Relation attribute contains a phrase in
the language defined by xml:lang which
describes the nature of the relationship
between the IOTP transaction that contains
this component and another IOTP Transaction
or other event. The exact words to be used
are left to the implementer of the IOTP
software.
The purpose of the attribute is to provide
the Trading Roles involved in an IOTP
Transaction with an explanation of the
nature of the relationship between the
transactions.
Care should be taken that the words used to
in the Relation attribute indicate the
"direction" of the relationship correctly.
For example: one transaction might be a
refund for another earlier transaction. In
this case the transaction which is a refund
Surendra Reddy et al. [Page 33]
Internet Draft IOTP/1.0 September 21, 1998
should contain in the Relation attribute
words such as "refund for" rather than
"refund to" or just "refund".
RelnKeyWords This attribute contains keywords which could
be used to help identify similar
relationships, for example all refunds. It
is anticipated that recommended keywords
will be developed through examination of
actual usage. In this version of the
specification there are no specific
recommendations and the keywords used are at
the discretion of the implementer.
Content:
PackagedContent The Packaged Content (see section 3.8)
contains data which identifies the related
transaction. Its format varies depending on
the value of the RelationshipType.
3.6. ID Attributes
IOTP Messages, Blocks (i.e. Transaction Reference Blocks and
Trading Blocks) and Trading Components (including the Transaction
Id Component and the Signature Component) are each given an XML
"ID" attribute which is used to identify an instance of these XML
elements. These identifiers are used so that one element can be
referenced by another. All these attributes are given the
attribute name ID.
The values of each ID attribute are unique within an IOTP
transaction i.e. the set of IOTP Messages which have the same
globally unique Transaction ID Component. This means that it is
possible to use these IDs to refer to and locate the content of
any IOTP Message, Block or Component from any other IOTP Message,
Block or Component in the same IOTP Transaction using Element
References (see section 3.7).
This section defines the rules for setting the values for the ID
attributes of IOTP Messages Blocks and Components.
3.6.1. IOTP Message ID Attribute Definition
The ID attribute of the Message Id Component of an IOTP Message
must be unique within an IOTP Transaction. It's definition is as
Surendra Reddy et al. [Page 34]
Internet Draft IOTP/1.0 September 21, 1998
follows:
OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix
OtpMsgIdPrefix ::= NameChar (NameChar)*
OtpMsgIdSuffix ::= Digit (Digit)*
OtpMsgIdPrefix Apart from messages which contain an Inquiry
Request Trading Block (see section 4.14), the
same prefix is used for all messages sent by
the Merchant or Consumer role as follows:
"M" Merchant
"C" Consumer
For messages which contain an Inquiry Request
Trading Block, the prefix is set to "I" for
Inquiry.
The prefix for the other roles in a trade is
contained within the Organisation Component
for the role and are typically set by the
Merchant. The following is recommended as a
guideline and must not be relied upon:
"P" - First (only) Payment Handler
"R" - Second Payment Handler
"D" - Delivery Handler
As a guideline, prefixes should be limited to
one character.
NameChar has the same definition as the [XML]
definition of NameChar.
OtpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role
within an IOTP Transaction. The following is
recommended as a guideline and must not be
relied upon:
the first IOTP Message sent by a trading role
is given the suffix "1"
the second and subsequent IOTP Messages sent by
the same trading role are incremented by one
for each message
no leading zeroes are included in the suffix
Put more simply the Message Id Component of
Surendra Reddy et al. [Page 35]
Internet Draft IOTP/1.0 September 21, 1998
the first IOTP Message sent by a Consumer would
have an ID attribute of, "C1", the second
"C2", the third "C3" etc.
Digit has the same definition as the [XML]
definition of Digit.
3.6.2. Block and Component ID Attribute Definitions
The ID Attribute of Blocks and Components must also be unique
within an IOTP Transaction. Their definition is as follows:
BlkOrCompId_value ::= OtpMsgId "." IdSuffix
IdSuffix ::= Digit (Digit)*
OtpMsgId The ID attribute of the Message ID Component
of the IOTP Message where the Block or
Component is first used.
In IOTP, Trading Components and Trading
Blocks are copied from one IOTP Message to
another. The ID attribute does not change
when an existing Trading Block or Component
is copied to another IOTP Message.
IdSuffix The suffix consists of one or more digits.
The suffix must be unique within the ID
attribute of the Message ID Component used
to generate the ID attribute. The following
is recommended as a guideline and must not
be relied upon:
the first Block or Component sent by a
trading role is given the suffix "1"
the ID attributes of the second and
subsequent Blocks or Components are
incremented by one for each new Block or
Component added to an IOTP Message
no leading zeroes are included in the suffix
Put more simply, the first new Block or
Component added to the second IOTP Message
sent, for example, by a consumer would have
a an ID attribute of "C2.1", the second
"C2.2", the third "C2.3" etc.
Digit has the same definition as the [XML]
Surendra Reddy et al. [Page 36]
Internet Draft IOTP/1.0 September 21, 1998
definition of Digit.
3.7. Element References
A Trading Component or one of its child XML elements, may contain
an XML attribute that refers to another Block (i.e. a Transaction
Reference Block or a Trading Block) or Trading Component
(including a Transaction Id and Signature Component). These
Element References are used for many purposes, a few examples
include:
- identifying an XML element whose hash value is included in a
Signature Component,
- referring to the Payment Handler Organisation Component
which is used when making a Payment
An Element Reference always contains the value of an ID attribute
of a Block or Component.
- Identifying the IOTP Message, Trading Block or Trading
Component which is referred to by an Element Reference,
involves finding the XML element which:
- belongs to the same IOTP Transaction (i.e. the Transaction Id
Components of the IOTP Messages match), and
- where the value of the ID attribute of the element matches
the value of the Element Reference.
3.8. Packaged Content Element
The Packaged Content element supports the concept of an embedded
data stream, transformed to both protect it against
misinterpretation by transporting systems and to ensure XML
compatibility. Examples of its use in IOTP include:
- to encapsulate payment scheme messages, such as SET
messages,
- to encapsulate a description of an order.
In general it is used to encapsulate any data stream.
This data stream has two standardised attributes that allow for
decoding and interpretation of the contents. Its definition is as
follows.
<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent
Surendra Reddy et al. [Page 37]
Internet Draft IOTP/1.0 September 21, 1998
Content NMTOKEN"PCDATA"
Transform (NONE|BASE64) "NONE" >
Attributes:
Content This identifies what type of data is
contained within the Content of the Packaged
Content Element. The valid values for the
Content attribute are as follows:
PCDATA.The content of the Packaged Content
Element can be treated as PCDATA with no
further processing.
MIME. The content of the Packaged Content
Element is a complete MIME item. Processing
should include looking for MIME headers
inside the Packaged Content Element.
MIME:mimetype. The content of the Packaged
Content Element is MIME content, with the
following header "Content-Type: mimetype".
Although it is possible to have
MIME:mimetype with the Transform attribute
set to NONE, it is far more likely to have
Transform attribute set to BASE64. Note that
if Transform is NONE is used, then the
entire content must still conform to PCDATA.
Some characters will need to be encoded
either as the XML default entities, or as
numeric character entities.
XML. The content of the Packaged Content
Element can be treated as an XML document.
Entities and CDATA sections, or Transform
set to BASE64, must be used to ensure that
the Packaged Content Element contents are
legitimate PCDATA.
x-ddd:usercode. The content is private,
where ddd represents a domain name of a
user, and usercode represents a particular
content format defined by that user. The
guidelines around a x-ddd are very loose.
Given company FFGGHH Inc., all of
x-www.ffgghh.com, x-ffgghh.comand and
x-ffgghh are legitimate examples. However,
only one should be the correct format, as
defined by FFGGHH Inc.
Transform This identifies the transformation that has
been done to the data before it was placed
Surendra Reddy et al. [Page 38]
Internet Draft IOTP/1.0 September 21, 1998
in the content. Valid values are:
NONE. The PCDATA content of the Packaged
Content Element is the correct
representation of the data. Note that entity
expansion must occur first (i.e. replacement
of & and ) before the data is
examined. CDATA sections may legitimately
occur in a Packaged Content Element where
the Transform attribute is set to NONE.
BASE64. The PCDATA content of the Packaged
Content Element represents a BASE64 encoding
of the actual content.
Content:
PCDATA This is the actual data which has been
embedded. The format of the data and rules
on how to decode it are contained in the
Content and the Transform attributes
Note that any special details, especially custom attributes, must
be represented at a higher level.
3.9. Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting
IOTP must be able to accept. As new versions of IOTP are developed,
additional types of IOTP Transactions will be defined. In addition
to this, Baseline and future versions of IOTP will support user
extensions to IOTP through two mechanisms:
o extra XML elements, and
o new user-defined values for existing IOTP codes.
3.9.1. Extra XML Elements
The XML element and attribute names used within IOTP constitute an
[XML Namespace]. This allows IOTP to support the inclusion of
additional XML elements within IOTP messages through the use of
[XML Namespaces].
Extra XML elements may be included at any level within an IOTP
message including:
- new Trading Blocks
- new Trading Components
Surendra Reddy et al. [Page 39]
Internet Draft IOTP/1.0 September 21, 1998
- new XML elements within a Trading Component.
The following rules apply:
- any new XML element must be declared according to the rules
for [XML Namespaces]. This means that:
o the namespace must be declared to the XML parser
o each element must have a start and end tags which conform
to the rules for XML Namespaces
- new XML elements which are either Trading Blocks or Trading
Components MUST contain an ID attributes with an attribute
name of ID.
In order to make sure that extra XML elements can be processed
properly, IOTP reserves the use of a special attribute,
Otp:Critical, which takes the values True or False and may appear
in extra elements added to an IOTP message.
The purpose of this attribute is to allow an IOTP aware
application to determine if the IOTP transaction can safely
continue. Specifically:
- if an extra XML element has an "Otp:Critical" attribute with
a value of "True" and an IOTP aware application does not know
how to process the element and its child elements, then the
IOTP transaction must fail. See section 6.34 Error Component.
- if an extra XML element has an "Otp:Critical" attribute with
a value of "False" then the IOTP transaction may continue if
the IOTP aware application does not know how to process it.
In this case:
o any extra XML elements contained within an XML element
defined within the IOTP namespace, must be included with
that element whenever the IOTP XML element is used or
copied by IOTP
o the content of the extra element must be ignored except
that it must be included when it is hashed as part of the
generation of a signature
- if an extra XML element has no "Otp:Critical" attribute then
it must be treated as if it had an "Otp:Critical" attribute
with a value of "True"
- if an XML element contains an "Otp:Critical" attribute, then
Surendra Reddy et al. [Page 40]
Internet Draft IOTP/1.0 September 21, 1998
the value of that attribute is assumed to apply to all the
child elements within that element
In order to ensure that documents containing "Otp:Critical" are
valid, it is declared as part of the DTD for the extra element
as:
Otp:Critical(True | False ) #IMPLIED
3.9.2. Opaque Embedded Data
If IOTP is to be extended using Opaque Embedded Data then a
Packaged Content Element (see section 3.8) should be used to
encapsulate the data.
3.9.3. User Defined Codes
User defined codes provide a simple way to identify additional
values for the codes contained within this specification.
The definition of a user defined code is as follows:
user_defined_code ::= ( "x-" | "X-" ) domain_name ":"
name
domain_name A name which identifies the organisation which is
creating the user defined code (see [DNS]). The
purpose of this field is to reduce the
probability of two organisations creating the
same user-defined name
name A name specified by the organisation which owns
the domain_name which identifies the user defined
code within the domain_name.
User defined codes are identified in this specification as "x-
ddd:nnn". The values of User Defined Codes must conform to the
rules for the specific code (see explanations of the individual
codes).
3.10. Identifying Languages
IOTP uses [XML] Language Identification to specify which languages
are used within the content and attributes of IOTP Messages.
Surendra Reddy et al. [Page 41]
Internet Draft IOTP/1.0 September 21, 1998
The following principles have been used in order to determine
which XML elements contain an xml:lang Attributes:
- a mandatory xml:lang attribute is contained on every Trading
Component which contains attributes or content which may
need to be displayed or printed in a particular language
- an optional xml:lang attribute is included on child elements
of these Trading Components. In this case the value of
xml:lang, if present, overrides the value for the Trading
Component.
xml:lang attributes which follow these principles are included in
the Trading Components and their child XML elements defined in
section 6.
3.11. Secure and Insecure Net Locations
IOTP contains several "Net Locations" which identify places where,
typically, IOTP Messages may be sent. Net Locations come in two
types:
- "Secure" Net Locations which are net locations where privacy
of data is secured using, for example, encryption methods
such as [SSL], and
- "Insecure" Net Locations where privacy of data is not
assured.
Where both types of net location are present, the following rules
apply:
- either a Secure Net Location or an Insecure Net Location or
both must be present
- if only one of the two Net Locations is present, then the
one present must be used
- if both are present, then the either may be used depending
on preference the preference of the sender of the message.
4. Internet Open Trading Protocol Transactions
The Baseline Internet Open Trading Protocol supports the following
types of Baseline IOTP Transactions:
- Authentication
- Deposit
- Purchase
- Refund
- Withdrawal
- Baseline Value Exchange
Surendra Reddy et al. [Page 42]
Internet Draft IOTP/1.0 September 21, 1998
- Payment Instrument Customer Care
- Transaction Status Inquiry, and
- Ping
Each of these transactions are described in more detail in the
following sections providing descriptions of:
- the Trading Blocks in each IOTP Transaction
- the Trading Components in each Trading Block, and
- how the Trading Components are signed
Note: There are many similarities between the transactions within
IOTP. This is because there is a lot of reuse of the Trading
Blocks between the different transactions.
This means that there should be significant opportunity for
software re-use. For example, from an IOTP perspective, the
Deposit, Refund and Withdrawal transactions are essentially the
same, although the processing which will occur, especially at the
server end, will differ.
4.1. Baseline Authentication IOTP Transaction
The Baseline Authentication IOTP Transaction supports:
- the remote authentication of a Consumer by another Trading
Role using a variety of authentication methods, and
- the provision of Organization Component about a Consumer to
another Trading Role.
Typical use includes:
- when the Baseline Authentication IOTP Transaction takes place
as an early part of a session where strong continuity
exists. For example, a Financial Institution could:
o set up a secure channel (e.g. using SSL) with a customer
o authenticate the customer using the Baseline
Authentication IOTP Transaction, and then
o provide the customer with access to account information
and other services with the confidence that they are
communicating with a bona fide customer.
- as a means of providing a Merchant role with Organization
Components that contain information about Consumer and
DelivTo Trading Roles.
1. The Baseline Authentication IOTP Transaction consists of just
the Authentication Trading Exchange.The Authentication
Surendra Reddy et al. [Page 43]
Internet Draft IOTP/1.0 September 21, 1998
Exchange consists of a set of predefined IOTP Messages which
are exchanged between the Trading Roles.
2. OUA initiates the IOTP transaction using out-of-band process.
3. OTR SHALL send an Authentication Request Block containing
challenge data and authentication method along with the TPO
Block.
4. Trading Protocol Options Block MUST contain one Protocol
Options Component which defines the options which apply to
the whole IOTP Transaction. Authentication Request Block MUST
contain one Authentication Data Component (see section 6.2)
5. OUA uses the challenge data, authentication method to
generate Authentication Response Block. OUA MAY store all or
partial information on IOTP transaction for record keeping
purposes.
6. OUA SHALL send Authentication Response to the OTR.
Authentication Response Block MUST contain one
Authentication Response Component (see section 6.3).
7. OTR SHALL checks the Authentication Response against the
challenge data and authentication method to verify the
validity of the OUA identity.
8. There are no variations of the Baseline Authentication IOTP
Transaction.
4.2. Baseline Deposit IOTP Transaction
The Baseline Deposit IOTP Transaction supports the deposit of
electronic cash with a Financial Institution.
The Baseline Deposit IOTP Transaction occurs in two basic forms:
- Baseline Deposit with Authentication. Where the Consumer
making the deposit is authenticated before the deposit is
made, and
- Baseline Deposit without Authentication. Where the Consumer
is not authenticated before the deposit is made.
4.2.1. Baseline Desposit with Authentication
1. OUA sends information about how much to deposit, the brand
to be used etc. to the OTR using out-of-band process.
Surendra Reddy et al. [Page 44]
Internet Draft IOTP/1.0 September 21, 1998
2. OTR sets the payment brand, protocol to offer and generates
the Authentication Request and sends to OUA. Trading
Protocol Options Block MUST contain one Protocol Options
Component which defines the options which apply to the whole
IOTP Transaction and one Brand List Component(see section
6.12) which contains the payment brand and protocols which
may be selected for use in the Payment Exchange.
Authentication Request Block MUST contain one Authentication
Data Component (see section 6.2).
3. OUA selects the payment protocol to use, records selection
in Brand Selection Component, generates an Authentication
Response Block and sends back to the OTR. TPO Selection
Block MUST contain one Brand Selection Component (see
section 6.17) for use in the Payment Exchange. It contains
the results of the consumer selecting a Payment Brand and
Payment Protocol from the list provided in the Brand List
Component. Authentication Response Block MUST contain one
Authentication Response Component (see section 6.3).
4. OTR checks the Authentication Response against the challenge
data and authentication method to validate the OUA identity.
5. On successful authentication, OTR SHALL generate Offer
Response Block containing information about the deposit. OTR
MAY optionally include the Signature Block and sends it to
the OUA. Offer Response Block MUST contain:
o zero or one Authentication Data Component (see section
6.2) An Authentication Data Component is required for
each Payment Exchange, where its Payment Component
contains an AuthDataRef attribute
o one Order Component (see section 6.4) which contains
details about the deposit, for example the amount of
value being deposited and any fees which might apply
o one Payment Component (see section 6.21) which contains
information about the payment which is to be made
o Organization Components (see section 6.7) with the
following roles:
* the Merchant who is accepting the deposit
* the Consumer who is making the deposit
* the PaymentHandler for the payment. The "ID" of the
Surendra Reddy et al. [Page 45]
Internet Draft IOTP/1.0 September 21, 1998
Payment Handler Organization Component is contained
within the VaOrgRef attribute of the Payment Component
(see section 6.21)
o one Delivery Component (see section 6.24) with the
DelivExch attribute set to False.
6. If the Offer Response is being digitally signed then a
Signature Block MUST be included in the same IOTP message
that contains an "Offer Response" Signature Component (see
section 6.30). The Signature Component contains hashes of
the following XML elements:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Offer
Response Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
o the Transaction Id Component (see section 3.5.1) which
globally uniquely identifies the IOTP Transaction
o the Authentication Data Component if present, the Order
Component, the Payment Component, all the Organization
Components present, andthe Delivery Component of the
Offer Response Block
o the Protocol Options Component, and the Brand List
Component of the TPO Block.
o the Brand Selection Component contained in the TPO
Selection Block.
7. OUA checks if Offer is OK, combines components from the TPO
Block, the TPO Selection Block and the Offer Response Block
to create the Payment Request Block and sends it to the
Payment Handler with the Signature Block if it present. The
Payment Request Block (see section 5.6) MUSTcontains:
o the following components copied from the Offer Response
Block:
* the Authentication Data Component if present
* the Payment Component
* the Organization Components with the roles of: Merchant
and PaymentHandler
Surendra Reddy et al. [Page 46]
Internet Draft IOTP/1.0 September 21, 1998
o the following component from the TPO Block:
* the Brand List Component
o one Brand Selection Component either:
* copied from the Offer Response Block if the deposit is
a Baseline Deposit with Authentication, or
* created by the Consumer, containing the payment brand
and payment protocol selected, if the deposit is a
Baseline Deposit without Authentication
o one Payment Scheme Component (see section 6.22) if
required by the payment method used (see the Payment
Method supplement to determine if this is needed).
8. If the Baseline Deposit Offer Response Block was signed then
the IOTP Message that contains the Payment Request Block must
also contain a Signature Block with a copy of the "Offer
Response" Signature Component.
9. Payment Handlers SHOULD check that they are authorised to
carry out the Payment (see section 9 Security
Considerations). Payment Handler starts exchanging the
payment protocol messages, encapsulated in the Payment
Exchange Block. On successful completion of payment protocol
messages, Payment Handler creates Payment Response Block
with an optional Signature Block and sends it to the OUA.The
Payment Exchange Block (see section 5.7) MUST contain one
Payment Scheme Component (see section 6.22) which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine
what this should contain. The Payment Response Block (see
section 5.8) MUST contain
o one Payment Receipt Component(see section 6.23) which
contains scheme specific data which can be used to verify
the payment occurred
o one Payment Scheme Component (see section 6.22) if
required which contains payment method specific data. See
the Payment Method supplement for the payment method
being used to determine what this should contain
o the "Offer Response" Signature Component (see section
6.30) from the Payment Request Block if present.
Surendra Reddy et al. [Page 47]
Internet Draft IOTP/1.0 September 21, 1998
10. If a signed Payment Receipt is being provided, indicated by
the SignedPayReceipt attribute of the Payment Component of
the Offer Response Block being set to True, then the IOTP
Message that contains the Payment Response Block must also
contain a Signature Block with a "Payment Receipt" Signature
Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block,
o the Transaction Id Component (see section 3.5.1) within
the Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
o the Payment Receipt Component from the Payment Response
Block and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
11. OUA checks Payment Response is OK. OUA MAY store information
on IOTP transaction for record keeping purposes.
4.2.2. Baseline Deposit Without Authentication
In Baseline Deposit without Authentication, there is no
Authentication Exchange and the OTR provides details about the
deposit immediately at the start of the IOTP Transaction.
The Baseline Deposit without authentication might be used:
- if a previous IOTP transaction, for example a Baseline
Withdrawal or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained,
therefore the authenticity of the consumer is known
- if authentication is achieved as part of a proprietary
payment protocol and is therefore included in the Payment
Exchange
- if authentication of the consumer has been achieved by some
other means outside of the scope of IOTP, for example, by
using a pass phrase.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Deposit
includes an Authentication Exchange or not.
Surendra Reddy et al. [Page 48]
Internet Draft IOTP/1.0 September 21, 1998
4.3. Baseline Purchase IOTP Transaction
The Baseline Purchase IOTP Transaction supports the purchase of
goods or services using any payment method. The Baseline Purchase
IOTP Transaction occurs in two basic forms:
- Brand Dependent Purchase. Where the content of the offer,
e.g. the order details, amount, delivery details, etc., are
dependent on the payment brand and protocol selected by the
consumer, and
- Brand Independent Purchase. Where the content of the offer
is not dependent on the payment brand and protocol selected.
Further variation is supported in that:
- the Delivery Exchange is optional, and
- the Delivery Response Block may be sent to the consumer
either:
o at the same time as the Payment Response Block, or
o after the Payment Response Block as the result of the
Consumer sending the Delivery Handler a Delivery Request
Block.
4.3.1. Brand Dependent Purchases
1. In a Brand Dependent Purchase the TPO Block and the Offer
Response Block MUST BE sent separately by the Merchant to
the Consumer, i.e.:
o the Brand List Component is sent to the Consumer in a TPO
Block,
o the Consumer selects a Payment Brand, Payment Protocol
and optionally a Currency and amount from the Brand List
Component
o the Consumer sends the selected brand, protocol and
currency/amount back to the Merchant in a TPO Selection
Block, and
o the Merchant uses the information received to define the
content of and then send the Offer Response Block to the
Consumer.
2. In a Brand Independent Purchase the TPO Block and the Offer
Response Block are sent together by the Merchant to the
Consumer in the same IOTP Message at the start of the IOTP
Surendra Reddy et al. [Page 49]
Internet Draft IOTP/1.0 September 21, 1998
Transaction.
3. A Brand Independent Purchase always occurs when only one
payment brand and protocol is being offered to the Consumer
by the Merchant. It is also likely to, but will not
necessarily, occur when multiple brands are being offered,
the Payment Handler is the same, and all brands use the same
set of protocols.
4. Note that the TPO Block and the Offer Response Block may be
sent in separate IOTP messages even if the Offer Response
Block does not change. However this increases the number of
messages in the transaction and is therefore likely to
increase transaction response times.
5. IOTP aware applications supporting the Consumer Trading Role
must check for the existence of an Offer Response Block in
the first IOTP Message to determine whether the Baseline
Purchase is brand dependent or not.
4.3.2. Combining Delivery Response Block and Payment Response Block
1. The Delivery Response Block and the Payment Response Block
may be sent:
o separately by the Payment Handler to the Consumer, i.e.:
* the Payment Response Block containing a Payment Receipt
and optional signature for the payment is sent by the
Payment Handler to the Consumer,
* the Consumer combines these components from the Payment
Response Block with components from the Offer Response
Block, to create a Delivery Request Block
* the Consumer sends the Delivery Request Block to the
Delivery Handler
* the Delivery Handler processes the Delivery Request
Block and sends a Delivery Response Block back to the
Consumer, or
o together, from the Payment Handler to the Consumer, when
the Payment Exchange is complete.
2. The Delivery Response Block and the Payment Response Block
are sent to the Consumer in separate IOTP Messages.
Surendra Reddy et al. [Page 50]
Internet Draft IOTP/1.0 September 21, 1998
3. The Delivery Response Block and the Payment Response Block
may be combined into the same IOTP Message only if the
Payment Handler has the information available so that she
can send the Delivery Response Block. This is likely to, but
will not necessarily, occur when the Merchant, the Payment
Handler and the Delivery Handler Roles are combined. The
DelivAndPayResp attribute of the Delivery Component (see
section 6.24) contained within the Offer Response Block (see
section 5.3) is set to True if the Delivery Response Block
and the Payment Response Block are combined into the same
IOTP Message and is set to False if the Delivery Response
Block and the Payment Response Block are sent in separate
IOTP Messages.
4.3.3. Optional Delivery Exchange
The final variation of the Baseline Purchase IOTP Transactions is
a purchase without a delivery. The DelivExch attribute of the
Delivery Component (see section 6.24) contained in the Offer
Response Block (see section 5.3) is set to False if the Delivery
Exchange is omitted and is set to True if the Delivery Exchange
is included.
4.3.4. Baseline Purchase Transaction
1. OUA starts the IOTP Purchase Transaction by sending
information about what to purchase using the out-of-band
process.
2. OTR(Merchant) decides which payment brand and protocols to
offer, places them in the TPO Block and sends to
OUA(Consumer).The Error! Reference source not found. (see
section Error! Reference source not found.) MUST contain:
o one Protocol Options Component which defines the options
which apply to the whole IOTP Transaction. See Section
6.1.
o one Brand List Component (see section 6.12) which
contains one or more payment brands and protocols which
may be selected for use in the Payment Exchange.
3. OUA selects the payment brand and payment protocol and
records the selection in a TPO Selection Block and sends
back to the OTR(Merchant).The TPO Selection Block (see
section 5.2) is only used by Brand Dependent Purchase. It
MUST contain one Brand Selection Component (see section
Surendra Reddy et al. [Page 51]
Internet Draft IOTP/1.0 September 21, 1998
6.17) for use in the Payment Exchange. It contains the
results of the consumer selecting a Payment Brand and
Payment Protocol from the list provided in the Brand List
Component.
4. The OTR(Merchant) uses payment brand and protocol selected
and information on what being purchased to create an Offer
Response Block containing details about goods ordered, price
etc and MAY optionally include Signature Block and sends it
to OUA(Consumer).The Offer Response Block (see section 5.3)
MUST contain:
o zero or one Authentication Data Component (see section
6.2) An Authentication Data Component is required for
each Payment Exchange, where its Payment Component (see
section 6.21) contains an AuthDataRef attribute.
o one Order Component (see section 6.4) which contains
details about the goods, services which are being
purchased
o one Payment Component (see section 6.21) which contains
information about the payment which is to be made
o Organization Components (see section 6.7) with the
following roles:
* Merchant who is providing the goods or services
* Consumer who is making the purchase
* PaymentHandler for the payment. The "ID" of the Payment
Handler Organization Component is contained within the
VaOrgRef attribute of the Payment Component
o one Delivery Component (see section 6.24) which contains
details of the delivery to be made.
5. If the Baseline Purchase includes a Delivery Exchange then
the Offer Response Block MUST also contain Organization
Components with the following roles:
o DeliveryHandler who will be delivering the goods or
services
o DelivTo i.e. the person or Organization which is to take
delivery
Surendra Reddy et al. [Page 52]
Internet Draft IOTP/1.0 September 21, 1998
6. If the Baseline Purchase Offer Response is being digitally
signed then a Signature Block MUST BE included in the same
IOTP message that contains an "Offer Response" Signature
Component (see section 6.30). The Signature Component MUST
contain hashes of the following XML elements:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Offer
Response Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
o the Transaction Id Component (see section 3.5.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
* the Authentication Data Component if present
* the Order Component
* the Payment Component
* all the Organization Components present, and
* the Delivery Component,
o the following components of the TPO Block :
* the Protocol Options Component, and
* the Brand List Component
o If the Baseline Purchase is a Brand Dependent Purchase
then the Signature Component additionally contains a hash
of the following:
* the Brand Selection Component contained in the TPO
Selection Block.
7. OUA(Consumer) checks Offer is OK, combines components from
the TPO Block, TPO Selection Block and ther Offer Response
Block to create a Payment Request Block and sends it back to
the Payment Handler together with the Signature Block if
present. The Payment Request Block (see section 5.6) MUST
contain:
o the following components copied from the Offer Response
Surendra Reddy et al. [Page 53]
Internet Draft IOTP/1.0 September 21, 1998
Block:
* the Authentication Data Component if present
* the Payment Component
* the Organization Components with the roles of: Merchant
and PaymentHandler
o the following component from the TPO Block:
* the Brand List Component
o one Brand Selection Component either:
* copied from the Offer Response Block if the purchase is
a Brand Dependent Purchase, or
* created by the Consumer, containing the payment brand
and payment protocol selected, if the purchase is a
Brand Independent Purchase
o one Payment Scheme Component (see section 6.22) if
required by the payment method used (see the Payment
Method supplement to determine if this is needed).
8. If the Baseline Purchase Offer Response Block was signed
then the IOTP Message that contains the Payment Request Block
must also contain a Signature Block with a copy of the
"Offer Response" Signature Component.
9. The Payment Exchange Block (see section 5.7) MUST contain
one Payment Scheme Component (see section 6.22) which
contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain.
10. Payment Handlers SHOULD check that they are authorised to
carry out the Payment (see section 9 Security
Considerations). Payment Handler checks optional signature,
processes Payment Request Block and starts exchanging
payment protocol messages, encapsulated in a Payment
Exchange Block with the OUA(Consumer). On successful
completion of the payment protocol messages, Payment Handler
creates Payment Response Block and send to the
OUA(Consumer).The Payment Response Block (see section 5.8)
MUST contain:
Surendra Reddy et al. [Page 54]
Internet Draft IOTP/1.0 September 21, 1998
o one Payment Receipt Component (see section) which
contains scheme specific data which can be used to verify
the payment occurred
o one Payment Scheme Component (see section 6.22) if
required which contains payment method specific data. See
the Payment Method supplement for the payment method
being used to determine what this should contain
o the "Offer Response" Signature Component (see section
6.30) from the Payment Request Block if present.
11. If a signed Payment Receipt is being provided, indicated by
the SignedPayReceipt attribute of the Payment Component of
the Offer Response Block being set to True, then the IOTP
Message that contains the Payment Response Block must also
contain a Signature Block with a "Payment Receipt" Signature
Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block,
o the Transaction Id Component (see section 3.5.1) within
the Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
o the Payment Receipt Component from the Payment Response
Block and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
12. OUA(Consumer checks Payment Response is OK and creates a
Delivery Request from Payment Response Block, Offer Response
Block and Signature Block, if present, and sends to the
Delivert Handler. The Delivery Request Block (see section
5.9) MUSTcontain:
o the following components copied from the Offer Response
Block:
* the Order Component (see section 6.4)
* the Organization Component (see section 6.7) with the
roles of: Merchant, DeliveryHandler and DeliverTo
Surendra Reddy et al. [Page 55]
Internet Draft IOTP/1.0 September 21, 1998
* the Delivery Component (see section 6.24)
13. Delivery Handler checks Payment Receipt, Order in Offer
Response and the optional signatures, creates a Delivery
Response Block, sends it to OUA(Consumer). The Delivery
Response Block MUST contain one Delivery Note Component (see
section 6.26) which contains delivery instructions about the
delivery of goods or services
Payment Handlers should check that they are authorised to carry
out the Payment (see section 9 Security Considerations).
If the Baseline Purchase Offer Response or Payment Response
Blocks were signed then the IOTP Message that contains the
Delivery Request Block MUST also contain a Signature Block with a
copy of:
- the "Offer Response" Signature Component if present, and/or
- the "Payment Receipt" Signature Component, if present
4.4. Baseline Refund IOTP Transaction
In business terms the refund process typically consists of:
- a request for a refund being made by the Consumer to the
Merchant, typically supported by evidence to demonstrate:
o the original trade took place, for example by providing a
receipt for the original transaction
o using some type of authentication, that the consumer
requesting the refund is the consumer, or a
representative of the consumer, who carried out the
original trade
o the reason why the merchant should make the refund
- the merchant agreeing (or not) to the refund. This may
involve some negotiation between the Consumer and the
Merchant, and, if the merchant agrees,
- a refund payment by the Merchant to the Consumer.
The Baseline Refund IOTP Transaction supports a subset of the
above, specifically it supports:
- the optional authentication of the Consumer using an
Authentication Exchange (see section 2.7), and
- the refund payment by the Merchant to the Consumer using the
Surendra Reddy et al. [Page 56]
Internet Draft IOTP/1.0 September 21, 1998
following two Trading Exchanges:
o an Offer Exchange (see section 2.4), and
o a Payment Exchange (see section 2.5).
The Baseline Refund IOTP Transaction occurs in two basic forms:
- Baseline Refund with Authentication. Where the Consumer
requesting the refund is authenticated before the refund is
made, and
- Baseline Refund without Authentication. Where the Consumer
is not authenticated before the refund is made.
4.4.1. Baseline Refund with Authentication
In Baseline Refund with Authentication an Authentication Exchange
occurs before the Offer Exchange containing the details of the
refund is provided by the Merchant.
Following sequences of messages are exchanged between the trading
roles for refund transaction:
1. OUA(Consumer) requests payment of previously agreed refund,
sends information about refund, such as a reference number to
the OTR(Merchant) using out-of-band process.
2. The OTR(Merchant) sets the payment brand and decided which
protocol to offer in TPO Block, generates an Authentication
Request Block containing challenge data and the authentication
method and sends it to the Consumer. The TPO Block must
contain:
- one Protocol Options Component which defines the options
which apply to the whole IOTP Transaction. See Section 6.1.
- one Brand List Component (see section 6.12) which contains
the payment brand and protocols which may be selected for
use in the Payment Exchange.
The Authentication Request Block (see section 5.4) MUST contain
one Authentication Data Component (see section 6.2)
3. IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Refund
includes an Authentication Exchange or not. The Consumer selects
payment protocol to use, records selection in a Brand Selection
Component, generates an Authentication Response Block and sends
Surendra Reddy et al. [Page 57]
Internet Draft IOTP/1.0 September 21, 1998
them back to the Merchant. The TPO Selection Block (see section 5.2)
MUST contain:
- one Brand Selection Component (see section 6.17) for use in
the Payment Exchange. It contains the results of the
consumer selecting a Payment Brand and Payment Protocol from
the list provided in the Brand List Component.
The Authentication Response Block (see section 5.5) MUST contain
one Authentication Response Component (see section 6.3).
4. The OTR(Merchant) checks the Authentication Response against the
challenge data and authentication method, based on the Consumer
identity and refund information generates the Offer Response Block
containing the information about the refund and optional Signature
Block and sends them to the Consumer. The Offer Response Block
(see section 5.3) MUST contain:
- zero or one Authentication Data Component (see section 6.2)
An Authentication Data Component is required for each
Payment Exchange, where its Payment Component contains an
AuthDataRef attribute
- one Order Component (see section 6.4) which contains details
about the refund, for example the amount being refunded and
any conditions which might apply
- one Payment Component (see section 5.2) which contains
information about the payment which is to be made
- Organization Components (see section 6.7) with the following
roles:
o the Merchant who is making the refund
o the Consumer who is requesting the refund
o the PaymentHandler for the payment. The "ID" of the
Payment Handler Organization Component is contained
within the VaOrgRef attribute of the Payment Component
- one Delivery Component (see section 6.24) with the DelivExch
attribute set to False.
5. If the Baseline Refund Offer Response is being digitally signed
then a Signature Block must be included in the same IOTP message
that contains an "Offer Response" Signature Component (see
section 6.30). The Signature Component contains hashes of the
following XML elements:
Surendra Reddy et al. [Page 58]
Internet Draft IOTP/1.0 September 21, 1998
- the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Offer
Response Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
- the Transaction Id Component (see section 3.5.1) which
globally uniquely identifies the IOTP Transaction
- the following components of the Offer Response Block:
o the Authentication Data Component if present
o the Order Component
o the Payment Component
o all the Organization Components present, and
o the Delivery Component,
- the following components of the TPO Block :
o the Protocol Options Component, and
o the Brand List Component
- If the Baseline Refund is a Baseline Refund with
Authentication then the Signature Component additionally
contains a hash of the following:
- the Brand Selection Component contained in the TPO Selection
Block.
6. OUA(Consumer) checks Offer is OK, combines components from
the TPO Block, the TPO Selection Block and the Offer Response
Block to create a Payment Request Block and sends to the
Payment Handler together with the optional Signature Block.
The Payment Request Block (see section 5.6) MUST contain:
- the following components copied from the Offer Response
Block:
o the Authentication Data Component if present
o the Payment Component
o the Organization Components with the roles of: Merchant
and PaymentHandler
- the following component from the TPO Block:
Surendra Reddy et al. [Page 59]
Internet Draft IOTP/1.0 September 21, 1998
o the Brand List Component
- one Brand Selection Component either:
o copied from the Offer Response Block if the refund is a
Baseline Refund with Authentication, or
o created by the Consumer, containing the payment brand and
payment protocol selected, if the refund is a Baseline
Refund with Authentication
- one Payment Scheme Component (see section 6.22) if required
by the payment method used (see the Payment Method
supplement to determine if this is needed).
7. If the Baseline Refund Offer Response Block was signed then the
IOTP Message that contains the Payment Request Block must also
contain a Signature Block with a copy of the "Offer Response"
Signature Component.
8. Payment Handlers should check that they are authorised to carry
out the Payment (see section 9 Security Considerations). Payment
Handler checks signature(if present), process Pay Request Block,
starts payment protocol message exchanges with the Consumer.
The Payment Exchange Block (see section 5.7) MUST contain one
Payment Scheme Component (see section 6.22) which contains
payment method specific data. See the Payment Method supplement
for the payment method being used to determine what this should
contain.
9. On successful completion of the payment protocol messages creates a
Pay Receipt component inside Pay Response Block, sends to the
Consumer with the optional Signature Block. The Payment Response
Block (see section 5.8) contains:
- one Payment Receipt Component (see section 6.23) which
contains scheme specific data which can be used to verify
the payment occurred
- one Payment Scheme Component (see section 6.22) if required
which contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain
- the "Offer Response" Signature Component (see section 6.30)
from the Payment Request Block if present.
10. If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
Surendra Reddy et al. [Page 60]
Internet Draft IOTP/1.0 September 21, 1998
Response Block being set to True, then the IOTP Message that
contains the Payment Response Block must also contain a Signature
Block with a "Payment Receipt" Signature Component which contains
hashes of the following:
- the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block,
- the Transaction Id Component (see section 3.5.1) within the
Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
- the Payment Receipt Component from the Payment Response
Block and
- the "Offer Response" Signature Component from the Payment
Request Block if present.
11. Consumer checks Pay Response is OK. OUA MAY optionally keep
all information related to the transaction for record keeping
purposes.
4.4.2. Baseline Refund without Authentication
In Baseline Refund without Authentication, there is no
Authentication Exchange and the Merchant provides details about
the refund immediately at the start of the IOTP Transaction.
The Baseline Refund without authentication might be used:
- when authentication of the consumer has been achieved by
some other means, for example, the consumer has entered some
previously supplied code in order to identify herself and
the refund to which the code applies. The code could be
supplied, for example on a web page or by e-mail.
- when a previous IOTP transaction, for example a Baseline
Authentication, authenticated the consumer, and a secure
channel has been maintained, therefore the authenticity of
the consumer is known and therefore the previously agreed
refund can be identified.
4.5. Baseline Withdrawal IOTP Transaction
The Baseline Withdrawal IOTP Transaction supports the withdrawal
of electronic cash from a Financial Institution.
Note: The Financial Institution has, in IOTP terminology, a role
of merchant in that a service (i.e. a withdrawal of electronic
cash) is being offered in return for a fee, for example bank
charges of some kind. The term "Financial Institution" is used in
Surendra Reddy et al. [Page 61]
Internet Draft IOTP/1.0 September 21, 1998
the diagrams and in the text for clarity.
The Baseline Withdrawal IOTP Transaction occurs in two basic
forms:
- Baseline Withdrawal with Authentication. Where the Consumer
making the withdrawal is authenticated before the withdrawal
is made, and
- Baseline Withdrawal without Authentication. Where the
Consumer is not authenticated before the withdrawal is made.
4.5.1. Baseline Withdrawal with Authentication
In Baseline Withdrawal with Authentication an Authentication
Exchange occurs before the Offer Exchange containing the details
of the withdrawal is provided by the Financial Institution.
Following sequences of messages are exchanged between the Consumer
and the financial institution(OTR) for withdrawl transaction:
1. OUA(Consumer) decides to withdraw electronic cash and sends
information about hoe much to withdraw to the OTR(Financial
Institution playing a merchant role) using out-of-band process.
2. The OTR(Financial Institution) sets the payment brand and decided
which protocol to offer in TPO Block, generates an Authentication
Request Block containing challenge data and the authentication
method and sends it to the Consumer. The TPO Block must
contain:
- one Protocol Options Component which defines the options
which apply to the whole IOTP Transaction. See Section 6.1.
- one Brand List Component (see section 6.12) which contains
the payment brand and protocols which may be selected for
use in the Payment Exchange.
The Authentication Request Block (see section 5.4) MUST contain
one Authentication Data Component (see section 6.2)
3. IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Withdrawal
includes an Authentication Exchange or not. The Consumer selects
payment protocol to use, records selection in a Brand Selection
Component, generates an Authentication Response Block and sends
them back to the Financial Institution. The TPO Selection Block
(see section 5.2) MUST contain:
- one Brand Selection Component (see section 6.17) for use in
Surendra Reddy et al. [Page 62]
Internet Draft IOTP/1.0 September 21, 1998
the Payment Exchange. It contains the results of the
consumer selecting a Payment Brand and Payment Protocol from
the list provided in the Brand List Component.
The Authentication Response Block (see section 5.5) MUST contain
one Authentication Response Component (see section 6.3).
4. The OTR(Financial Institution) checks the Authentication Response
against the challenge data and authentication method, based on the
Consumer identity and refund information generates the Offer
Response Block containing the information about the withdrawal and
optional Signature Block and sends them to the Consumer.
The Offer Response Block (see section 5.3) MUST contain:
- zero or one Authentication Data Component (see section 6.2)
An Authentication Data Component is required for each
Payment Exchange, where its Payment Component contains an
AuthDataRef attribute
- one Order Component (see section 6.4) which contains details
about the refund, for example the amount being withdrawn and
any conditions which might apply
- one Payment Component (see section 5.2) which contains
information about the payment which is to be made
- Organization Components (see section 6.7) with the following
roles:
o the Merchant who is making the refund
o the Consumer who is requesting the refund
o the PaymentHandler for the payment. The "ID" of the
Payment Handler Organization Component is contained
within the VaOrgRef attribute of the Payment Component
- one Delivery Component (see section 6.24) with the DelivExch
attribute set to False.
5. If the Baseline Withdrawal Offer Response is being digitally signed
then a Signature Block must be included in the same IOTP message
that contains an "Offer Response" Signature Component (see
section 6.30). The Signature Component contains hashes of the
following XML elements:
- the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Offer
Response Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Surendra Reddy et al. [Page 63]
Internet Draft IOTP/1.0 September 21, 1998
Transaction
- the Transaction Id Component (see section 3.5.1) which
globally uniquely identifies the IOTP Transaction
- the following components of the Offer Response Block:
o the Authentication Data Component if present
o the Order Component
o the Payment Component
o all the Organization Components present, and
o the Delivery Component,
- the following components of the TPO Block :
o the Protocol Options Component, and
o the Brand List Component
- If the Baseline Withdrawal is a Baseline withdrawal with
Authentication then the Signature Component additionally
contains a hash of the following:
- the Brand Selection Component contained in the TPO Selection
Block.
6. OUA(Consumer) checks Offer is OK, combines components from
the TPO Block, the TPO Selection Block and the Offer Response
Block to create a Payment Request Block and sends to the
Payment Handler together with the optional Signature Block.
The Payment Request Block (see section 5.6) MUST contain:
- the following components copied from the Offer Response
Block:
o the Authentication Data Component if present
o the Payment Component
o the Organization Components with the roles of: Merchant
and PaymentHandler
- the following component from the TPO Block:
o the Brand List Component
- one Brand Selection Component either:
Surendra Reddy et al. [Page 64]
Internet Draft IOTP/1.0 September 21, 1998
o copied from the Offer Response Block if the refund is a
Baseline Refund with Authentication, or
o created by the Consumer, containing the payment brand and
payment protocol selected, if the refund is a Baseline
Refund with Authentication
- one Payment Scheme Component (see section 6.22) if required
by the payment method used (see the Payment Method
supplement to determine if this is needed).
7. If the Baseline Withdrawal Offer Response Block was signed then the
IOTP Message that contains the Payment Request Block must also
contain a Signature Block with a copy of the "Offer Response"
Signature Component.
8. Payment Handlers should check that they are authorised to carry
out the Payment (see section 9 Security Considerations). Payment
Handler checks signature(if present), process Pay Request Block,
starts payment protocol message exchanges with the Consumer.
The Payment Exchange Block (see section 5.7) MUST contain one
Payment Scheme Component (see section 6.22) which contains
payment method specific data. See the Payment Method supplement
for the payment method being used to determine what this should
contain.
9. On successful completion of the payment protocol messages creates a
Pay Receipt component inside Pay Response Block, sends to the
Consumer with the optional Signature Block. The Payment Response
Block (see section 5.8) MUST contains
- one Payment Receipt Component (see section 6.23) which
contains scheme specific data which can be used to verify
the payment occurred
- one Payment Scheme Component (see section 6.22) if required
which contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain
- the "Offer Response" Signature Component (see section 6.30)
from the Payment Request Block if present.
10. If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
Response Block being set to True, then the IOTP Message that
contains the Payment Response Block must also contain a Signature
Block with a "Payment Receipt" Signature Component which contains
hashes of the following:
Surendra Reddy et al. [Page 65]
Internet Draft IOTP/1.0 September 21, 1998
- the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block,
- the Transaction Id Component (see section 3.5.1) within the
Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
- the Payment Receipt Component from the Payment Response
Block and
- the "Offer Response" Signature Component from the Payment
Request Block if present.
11. Consumer checks Pay Response is OK. OUA MAY optionally keep
all information related to the transaction for record keeping
purposes.
Note:
1. The Financial Institution can offer withdrawal of several different
types of electronic cash. In practice usually only one form of
electronic cash may be offered. However, there may be several
different protocols which may be used for the same "brand"
of electronic cash
2. The financial institution may use the results of the
authentication to identify not only the consumer but also
the account from which the withdrawal is to be made. If no
single account can be identified, then it must be obtained
by other means. For example:
- the consumer could specify the account number in the initial
dialogue , or
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an
account selected from a list provided by the Financial
Institution.
4.5.2. Baseline Withdrawal without Authentication
In Baseline Withdrawal without Authentication, there is no
Authentication Exchange and the Financial Institution provides
details about the withdrawal immediately at the start of the IOTP
Transaction.
The Baseline Withdrawal without Authentication might be used:
- when a previous IOTP transaction, for example a Baseline
Deposit or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained,
therefore the authenticity of the consumer is known
Surendra Reddy et al. [Page 66]
Internet Draft IOTP/1.0 September 21, 1998
- when authentication is achieved as part of a proprietary
payment protocol and is therefore included in the Payment
Exchange
- when authentication of the consumer has been achieved by
some other means, for example, by using a pass phrase, or a
proprietary banking software solution.
4.6. Baseline Value Exchange IOTP Transaction
The Baseline Value Exchange Transaction uses Payment Exchanges
(see section 2.5) to support the exchange of value in one
currency obtained using one payment method with value in the same
or another currency using the same or another payment method.
Examples of its use include:
- electronic cash advance on a credit card. For example the
first payment could be a dollar SET Payment Exchange on a
credit card with the second Payment Exchange being a
download of DigiCash e-cash in dollars.
- foreign exchange using the same payment method. For example
the payment could be an upload of Mondex value in French
Francs and the second a download of Mondex value in British
Pounds
- foreign exchange using different payment methods. For
example the first payment could be a SET payment in Euros
followed a download of GeldKarte in Deutchmarks.
The Baseline Value Exchange IOTP Transaction occurs in two basic
forms:
- Brand Dependent Value Exchange. Where the content of the
offer, for example the rate at which one form of value is
exchanged for another, is dependent on the payment brands
and protocols selected by the consumer, and
- Brand Independent Value Exchange. Where the content of the
offer is not dependent on the payment brands and protocols
selected.
4.6.1. Brand Dependent Value Exchange
In Brand Dependent Value Exchange the TPO Block and the Offer
Response Block are sent separately by the Merchant to the
Consumer, i.e.:
- the Brand List Components for the two payments are sent to
the Consumer in a TPO Block,
- the Consumer selects a Payment Brand and Payment Protocol
Surendra Reddy et al. [Page 67]
Internet Draft IOTP/1.0 September 21, 1998
from the Brand List Component for each of the payments in
the Value Exchange
- the Consumer sends the selected brands and protocols back to
the Merchant in a TPO Selection Block, and
- the Merchant Uses the information received to define the
content of the Offer Response Block and then sends it to the
Consumer.
Whether or not the Value Exchange is brand dependent, the
exchange of Trading Blocks between the Consumer and the Payment
Handlers are the same. The following sequences of messages are
exchanged between the Trading Roles for the Value Exchange
Transaction:
1. OUA(Consumer) sends information about the value exchange to
the OTR(Merchant) using out-of-band process.
2. OTR(Merchant) decides which payment brand and protocols to
offer for each payment, places them in Brand List Components
in a TPO Block and sends them to OUA(Consumer). The TPO
Block MUST contain the following Trading Components:
o one Protocol Options Component which defines the options
which apply to the whole IOTP Transaction. See Section
6.1.
o two Brand List Components (see section 6.12) one for each
Payment Exchange where each Brand List Component contains
one or more payment brands and protocols which may be
selected for use in the Payment Exchange.
3. OUA(Consumer) selects the payment brand and payment protocol
to use each payment, records selections in two Brand
Selection Components in TPO Selection Block, and sends back
to OTR(Merchant). The TPO Selection Block (see section 5.2)
is only used by Brand Dependent Value Exchange. It contains:
o two Brand Selection Components (see section 6.17). One
for each of the Payment Exchanges. Each Brand Selection
Component contains the results of the consumer selecting
a Payment Brand and Payment Protocol from the list
provided in the Brand List Component.
4. OTR(Merchant) uses payments brands and protocols selected to
create an Offer Response Block containing details about the
value exchange and sends it to OUA(Consumer) together with
the optional digital signature. The Offer Response Block
(see section 5.3) contains the following components:
Surendra Reddy et al. [Page 68]
Internet Draft IOTP/1.0 September 21, 1998
o zero, one or two Authentication Data Component (see
section 6.2). An Authentication Data Component is
required for each Payment Exchange, where its Payment
Component contains an AuthDataRef attribute.
o one Order Component (see section 6.4) which contains
details about the Value Exchange, for example, exchange
rates, commission, etc.
o two Payment Components (see section 6.21) which contain
information about each of the two payments which are to
be made
o Organization Components (see section 6.7) with the
following roles:
* Merchant who is providing the goods or services
* Consumer who is making the purchase
* the PaymentHandlers for the payments. The "ID" of a
Payment Handler Organization Component is contained
within the VaOrgRef attribute of each of the Payment
Components
4. If the Baseline Value Exchange Offer Response is being
digitally signed then a Signature Block must be included in
the same IOTP message that contains an "Offer Response"
Signature Component (see section 6.30). The Signature
Component contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Offer
Response Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
o the Transaction Id Component (see section 3.5.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
* the Authentication Data Component if present
* the Order Component
* the two Payment Components
Surendra Reddy et al. [Page 69]
Internet Draft IOTP/1.0 September 21, 1998
* all the Organization Components present, and
o the following components of the TPO Block :
* the Protocol Options Component, and
* the Brand List Component
o If the Baseline Value Exchange is a Brand Dependent Value
Exchange then the Signature Component additionally
contains a hash of the following:
o the two Brand Selection Components contained in the TPO
Selection Block.
5. OUA(Consumer) checks Offer is OK, combines components from
TPO Block, TPO Selection Block and Offer Response Block to
create a Payment Request Block for the first payment and
sends it to the Payment Handler 1 together with the optional
Signature Block.The Payment Request Block (see section 5.6)
for the first payment contains:
o the following components copied from the Offer Response
Block:
* the Authentication Data Component for the first payment
if required
* the Payment Component for the first payment
* the Organization Components with the roles of: Merchant
and PaymentHandler for the first payment
o the following component copied from the TPO Block:
* the Brand List Component for the first payment
o one Brand Selection Component for the first payment which
is either:
* copied from the Offer Response Block if the purchase is
a Brand Dependent Value Exchange, or
* created by the Consumer, containing the payment brand
and payment protocol selected, if the purchase is a
Brand Independent Value Exchange
o one Payment Scheme Component (see section 6.22) if
Surendra Reddy et al. [Page 70]
Internet Draft IOTP/1.0 September 21, 1998
required by the payment method used (see the Payment
Method supplement to determine if this is needed).
6. If the Baseline Value Exchange Offer Response Block was
signed then the IOTP Message that contains the Payment
Request Block for the first payment must also contain a
Signature Block with a copy of the "Offer Response"
Signature Component. The Payment Exchange Block (see section
5.7) for the first payment contains:
o one Payment Scheme Component (see section 6.22) which
contains payment method specific data for the payment
method being used by the first payment. See the Payment
Method supplement for the payment method being used to
determine what this should contain.
7. Payment Handler 1 processes Payment Request Block for the
first payment and starts payment protocol messages. On
successful completion of the payment protocol messages,
Payment Handler creates Payment Response Block and sends it
to the OUA(Consumer) along with the optional Signature
Block.The Payment Response Block for the first payment (see
section 5.8) contains:
o one Payment Receipt Component (see section 6.23) which
contains scheme specific data which can be used to verify
the first payment occurred
o one Payment Scheme Component (see section 6.22) if
required by the payment method used by the first payment
which contains payment method specific data. See the
Payment Method supplement for the payment method being
used to determine what this should contain
o the Signature Component (see section 6.30) from the
Payment Request Block for the first payment if present.
8. If a signed Payment Receipt is being provided for the first
payment, indicated by the SignedPayReceipt attribute of the
Payment Component for the first payment in the Offer
Response Block being set to True, then the IOTP Message that
contains the Payment Response Block for the first payment
must also contain a Signature Block with a "Payment Receipt"
Signature Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block for the first payment,
Surendra Reddy et al. [Page 71]
Internet Draft IOTP/1.0 September 21, 1998
o the Transaction Id Component (see section 3.5.1) within
the Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
o the Payment Receipt Component from the Payment Response
Block for the first payment and
o the "Offer Response" Signature Component from the Payment
Request Block for the first payment, if present.
9. OUA(Consumer) checks Payment Response for first payment is
OK and create a Payment Request for Second payment using the
Offer Response Block along with the optional Signature Block
and sends it to Payment Handler 2.The Payment Request Block
(see section 5.6) for the second payment contains:
o the following components copied from the Offer Response
Block:
* the Authentication Data Component for the second
payment if required
* the Payment Component for the second payment
* the Organization Components with the roles of: Merchant
and PaymentHandler for the second payment
o the following component copied from the TPO Block:
* the Brand List Component for the second payment
o one Brand Selection Component for the second payment
which is either:
* copied from the Offer Response Block if the purchase is
a Brand Dependent Value Exchange, or
* created by the Consumer, containing the payment brand
and payment protocol selected, if the purchase is a
Brand Independent Value Exchange
o one Payment Scheme Component (see section 6.22) if
required by the payment method used (see the Payment
Method supplement to determine if this is needed)
10. Payment Handler 2 processes Payment Request Block for the
second payment and starts payment protocol messages.
Surendra Reddy et al. [Page 72]
Internet Draft IOTP/1.0 September 21, 1998
11. The Payment Exchange Block (see section 5.7) for the second
payment contains:
o one Payment Scheme Component (see section 6.22) which
contains payment method specific data for the payment
method being used by the second payment. See the Payment
Method supplement for the payment method being used to
determine what this should contain.
12. On successful completion of the payment protocol messages,
Payment Handler creates Payment Response Block and sends it
to the OUA(Consumer) along with the optional Signature
Block.The Payment Response Block for the second payment (see
section 5.8) contains:
o one Payment Receipt Component (see section 6.23) which
contains scheme specific data which can be used to verify
the second payment occurred
o one Payment Scheme Component (see section 6.22) if
required by the payment method used by the second payment
which contains payment method specific data. See the
Payment Method supplement for the payment method being
used to determine what this should contain
o all the Signature Components (see section 6.30) from the
Payment Request Block for the second payment if present.
13. If a signed Payment Receipt is being provided for the second
payment, indicated by the SignedPayReceipt attribute of the
Payment Component for the second payment in the Offer
Response Block being set to True, then the IOTP Message that
contains the Payment Response Block for the second payment
must also contain a Signature Block with a "Payment Receipt"
Signature Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.5) for the
IOTP Message which contains the first usage of the Payment
Response Block for the second payment,
o the Transaction Id Component (see section 3.5.1) within
the Transaction Reference Block that globally uniquely
identifies the IOTP Transaction,
o the Payment Receipt Component from the Payment Response
Block for the second payment
o the "Offer Response" Signature Component from the Payment
Surendra Reddy et al. [Page 73]
Internet Draft IOTP/1.0 September 21, 1998
Request Block for the second payment, if present, and
o the "Payment Receipt" Signature Component from the
Payment Request Block for the first payment, if present.
14. OUA(Consumer) checks Payment Response for first payment is
OK and create a Payment Request for Second payment using the
Offer Response Block along with the optional Signature Block
and sends it to Payment Handler 2.
15. If the Baseline Value Exchange Offer Response Block or the
Payment Response Block for the first payment was signed then
the IOTP Message that contains the Payment Request Block for
the second payment must also contain a Signature Block with
a copy of:
o the "Offer Response" Signature Component, if present,
and/or
o the "Payment Receipt" Signature Component copied from the
Payment Response Block for the first payment, if present.
16. If signatures are used then the Payment Handlers should
check that all Signature Components they receive are valid
(see section 9 Security Considerations).
Note that:
- the Payment Component for the first payment is the one
within the Offer Response Block that contains no StartAfter
attribute (see section 6.21)
- the Authentication Data Component to include is identified
by the AuthDataRef attribute of the Payment Component for
the first payment. If no AuthDataRef attribute is present
then no Authentication Data Component is required
- the Payment Handler to include is identified by the Brand
Selection Component (see section 6.17) for the first
payment. Also see section 9.7 Check the Action Request was
sent to the Correct Organization for an explanation on how
Payment Handlers are identified
- the Brand List Component to include is the one identified by
the BrandListRef attribute of the Payment Component for the
first payment
- the Brand Selection Component to include from the Offer
Response Block is the one that contains an Element Reference
(see section 3.7) which identifies the Brand List Component
for the first payment
- the Payment Component for the second payment is the one
Surendra Reddy et al. [Page 74]
Internet Draft IOTP/1.0 September 21, 1998
within the Offer Response Block that contains a StartAfter
attribute (see section 6.21) that identifies the Payment
Component for the first payment
- the Authentication Data Component to include is identified
by the AuthDataRef attribute of the Payment Component for
the second payment. If no AuthDataRef attribute is present
then no Authentication Data Component is required
- the Payment Handler to include is identified by the Brand
Selection Component (see section 6.17) for the second
payment. Also see section 9.7 Check the Action Request was
sent to the Correct Organization for an explanation on how
Payment Handlers are identified
- the Brand List Component to include is the one identified by
the BrandListRef attribute of the Payment Component for the
second payment
- the Brand Selection Component to include from the Offer
Response Block is the one that contains an Element Reference
(see section 3.7) which identifies the Brand List Component
for the second payment
4.6.2. Brand Independent Value Exchange
In Brand Independent Value Exchange the TPO Block and the Offer
Response Block are sent together by the Merchant to the Consumer
in the same IOTP Message at the start of the IOTP Transaction.
The TPO Block and Offer Response Block may only be combined into
the same IOTP Message if the content of the Offer Response Block
does not change as a result of selecting the payment brands and
payment protocols to be used in the Value Exchange.
Note that the TPO Block and the Offer Response Block may be sent
in separate IOTP messages even if the Offer Response Block does
not change. However this increases the number of messages in the
transaction and is therefore likely to increase transaction
response times.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Offer Response Block in the first
IOTP Message to determine whether the Baseline Value Exchange is
brand dependent.
4.7. Payment Instrument Customer Care IOTP Transaction
An IOTP Payment Instrument Customer Care Transaction is used to
provide Payment Brand or Payment Method specific customer care.
It allows Consumer Payment Brand software to exchange information
with a Payment Instrument Customer Care Provider.
Surendra Reddy et al. [Page 75]
Internet Draft IOTP/1.0 September 21, 1998
The circumstances under which this transaction is used, if any,
is defined in the IOTP Supplement for the Payment Brand.
Note that the IOTP Payment Instrument Customer Care Transaction:
- is initiated by the Consumer Payment Brand software which
must identify the need for the transaction to occur. Note
that in other IOTP Transactions, the transaction is initiated
by the Merchant
- has no TPO Block, as it is initiated by the Consumer
- relies on the Consumer Payment Brand software to identify
the net location of the Payment Instrument Customer Care
Provider to which the first message in the transaction must
be sent
- ends when the Payment Scheme Customer Care Service
determines that the exchange of messages with the Consumer
is to stop.
Note that a Payment Instrument Customer Care Transaction can be
initiated at any time by a Consumer including in the middle of
another IOTP Transaction. In this case, the transaction shall
establish a different transport session from the ongoing
transaction. See the Mapping to Transport for the Transport
Mechanism being used.
Following OTP messages are exchanged between the Payment Instrument
User and Payment Instrument Care Provider roles:
1. OUA(Consumer) identifies the need to contact Payment instrument
Care Provider and generates Payment Instrument Customer Care
Request Block and sends it to the Customer Care Provider. OUA
determines the Customer Care Provider by Net Location. The Payment
Instrument Customer Care Request Block MUST contain:
- a Payment Method Information Component (see section 6.27)
which describes the Payment Method for which Customer Care
is requested, and
- zero or more optional Payment Scheme Components (see section
6.22) which contain optional Payment scheme data
2. OTR(Payment Instrument Customer Care Provider) process the Payment
Instrument Customer Care Request Block and starts exchaging
Payment Instrument Customer Care Exchange Block with the
OUA(Consumer). The Payment Instrument Customer Care Exchange
Block MUST contain:
- a Payment Method Information Component (see section 6.27)
which describes the Payment Method for which Customer Care
Surendra Reddy et al. [Page 76]
Internet Draft IOTP/1.0 September 21, 1998
is being provided, and
- zero or more optional Payment Scheme Components (see section
6.22) which contain optional Payment scheme data
3. On successful completion of the Customer Care Exchange messages,
OTR(Payment Instrument Customer Care Provider) generates the payment
instrument customer care response block and sends it to the OUA(
consumer). The Payment Instrument Customer Care Response Block
MUST contain:
- a Payment Method Information Component (see section 6.27)
which describes the Payment Method for which Customer Care
is complete, and
- zero or more optional Payment Scheme Component (see section
6.22) which contains optional Payment scheme data
Any of the IOTP Messages which contain Payment Instrument Customer
care blocks may also include a Signature Block (see section 5.18)
containing a Signature Component (see section 6.30). How these
are used and what it signs is dependent on the Payment Brand and
Payment method being used.
4.8. Baseline Transaction Status Inquiry IOTP Transaction
The Baseline IOTP Transaction Status Inquiry provides a Consumer
with information on the status of an existing or complete IOTP
transaction.
The Trading Blocks used by the Baseline Transaction Status
Inquiry Transaction are:
- an Inquiry Request Trading Block (see section 5.14), and
- an Inquiry Response Trading Block (see section 5.15).
Note that:
- Consumer Inquiries on Authentication transaction are not
supported.
- Authentication of Consumers as part of an inquiry is not
supported in the Baseline version of IOTP.
4.8.1. Which Trading Roles can receive Inquiry Requests
The Consumer can send a Transaction Status Inquiry Block to the
appropriate Trading Role after the following events have
occurred:
- to the Merchant, after sending TPO Selection Block,
- to the Payment Handler, after sending Payment Request Block,
Surendra Reddy et al. [Page 77]
Internet Draft IOTP/1.0 September 21, 1998
- to the Delivery Handler, after sending Delivery Request
Block.
Note: IOTP does not support sending Inquiry Requests to the
Consumer since the consumer may not be on-line to receive and
process them.
If the Consumer is inquiring on transaction that is not yet
complete, it should send the Inquiry Request Block to the Trading
Role to which it sent the last IOTP message. If the Consumer is
inquiring on a transaction which is complete, there are two
alternatives in deciding the Trading Roles that the Inquiry
Request Block should be sent to:
- the Consumer IOTP software can ask the end user to determine
the type of inquiry they want to make, or
- the Consumer IOTP software can send the inquiry request
message to all the Trading Roles that were involved in the
IOTP transaction.
For the second case above, how the Consumer IOTP Aware Application
displays the inquiry response data received from each Trading
Role is up to each implementation.
4.8.2. Transaction Status Inquiry Transport Session
For a Transaction Status Inquiry on an ongoing transaction, the
Consumer SHALL establish with a Trading Role, a different
transport session from the ongoing transaction. For a Transaction
Status Inquiry on a past transaction, how the IOTP module on the
software at the Trading Role is started upon the receipt of
Inquiry Request message is defined in each Mapping to Transport
supplement for IOTP.
4.8.3. Transaction Status Inquiry Error Handling
Errors in a Transaction Status Inquiry can be categorised into
one the following three cases:
- Business errors (see section 7.2) in the original (inquired)
messages
- Technical errors (see section 7.1) - both IOTP and payment
scheme specific ones - in the original IOTP (inquired)
messages
- Technical errors in the message containing the Inquiry
Request Block itself
The following outlines what the software should do in each case
Surendra Reddy et al. [Page 78]
Internet Draft IOTP/1.0 September 21, 1998
Business errors in the original messages: Return an Inquiry Response
Block containing the Status Component which was last sent to the Consumer.
Technical errors in the original messages: Return an Inquiry Response
Block containing a Status Component. The Status Component should contain
a ProcessState attribute set to ProcessError. In this case send back an
Error Block indicating where the error was found in the original message.
Technical errors in the Inquiry Request Block: Return an Error message. That
is, send back an Error Block containing the Error Code (see section 6.36)
which describes the nature of the error in the Inquiry Request message.
4.8.4. Inquiry Transaction Messages
Following messages are exchanged between trading roles for
Inquiry Transaction:
1. OUA(Consumer) generates an Inquiry Request Block and sends it
to the appropriate trading role. The Inquiry Request Block
(see section 5.14) MUST contain:
- one Inquiry Type Component (see section 6.29). This
identifies whether the inquiry is on an offer, payment, or
delivery.
- zero or one Payment Scheme Component (see section 6.22).
This is for encapsulating payment scheme specific inquiry
messages for inquiries on payment.
2. The Consumer must use the same Transaction Id Component (see
section 3.5.1) as in the inquired transaction. The OtpTransId
attribute in this component serves as the key in querying the
transaction logs maintained at the Trading Role's site. The value
of the ID attribute of the Message Id Component should be
different from those of the inquired transaction (see section
3.6.1).
3. The OTR checks the transaction status of the transaction being
inquired upon by using the Transaction Id component of the
Transaction Reference Block. OTR generates the appropriate
response block based on the status of the transaction and sends
it back to the OUA(Consumer). The Inquiry Response Block (see
section 5.15) MUST contain:
- one Status Component (see section 6.28). This component hold
the status information on the inquired transaction,
- zero or one Payment Scheme Components. These contain for
Surendra Reddy et al. [Page 79]
Internet Draft IOTP/1.0 September 21, 1998
encapsulated payment scheme specific inquiry messages for
inquiries on payment.
4.9. Baseline Ping IOTP Transaction
The purpose of the Baseline IOTP Ping Transaction is to enable IOTP
aware application software to determine if the IOTP aware
application at another Trading Role is operating and verifying
whether or not signatures can be handled.
The Trading Blocks used by the Baseline Ping IOTP Transaction are:
- a Ping Request Block (see section 5.16)
- a Ping Response Block (see section 5.17), and
- a Signature Block (see section 5.18).
The verification that signatures can be handled is indicated by
the sender of the Ping Request Block including:
- Organization Components that identify itself and the
intended recipient of the Ping Request Block, and
- a Signature Block that signs data in the Ping Request.
In this way the receiver of the Ping Request:
- knows who is sending the Ping Request and can therefore
verify the Signature on the Request, and
- knows who to generate a signature for on the Ping Response.
Note that a Ping Request:
- does not affect any on-going transaction
- does NOT start an IOTP aware application, unlike other IOTP
transaction messages such as TPO or Transaction Status
Inquiry.
Following sequences of messages are exchanged bewteen the tranding
roles for the Ping transaction:
1. The OUA in an IOTP Trading Role decides to check whether the
counterparty IOTP application is running or not. It generates
a Ping Request Block with an optional Signature Block and sends
it to the other IOTP Trading Role. If the Ping Transaction
is anonymous then no Organization Components are included
in the Ping Request Block (see section 5.6).
2. If the Ping Transaction is not anonymous then the Ping Request
Block MUST contain Organization Components for:
Surendra Reddy et al. [Page 80]
Internet Draft IOTP/1.0 September 21, 1998
- the sender of the Ping Request Block, and
- the verifier of the Signature Component
- If Organization Components are present, then it indicates
that the sender of the Ping Request message has generated a
Signature Block. The signature block must be verified by
the Trading Role that receives the Ping Request Block.
3. A Baseline IOTP Ping request can also contain an optional
Signature Block. IOTP aware applications can, for example, use the
Signature Block to check the recipient of a Ping Request can
successfully process and check signatures it has received. The
Ping Request Signature Block MUST contain:
- one Signature Component(see section 6.30)
- one or more Certificate Components, if required.
4. The OTR which receives the Ping Request generates a Ping Response
and sends it back to the sender of the original Ping Request. The
Ping Response Block (see section 5.17) MUST contain:
- the Organization Component of the sender of the Ping
Response message
- If the Ping Transaction is not anonymous then the Ping
Response additionally contains:
o copies of the Organization Components contained in the
Ping Request Block.
5. The Ping Response Signature Block (see section 5.18) MUST contain:
- one Signature Component (see section 6.30)
- one or more Certificate Components, if required.
Note:
1. For each Baseline Ping IOTP Transaction, each IOTP role shall
establish a different transport session from other IOTP
transactions.
2. Any IOTP Trading Role can send a Ping request to any other IOTP
Trading Role at any time it wants. A Ping message has its own
OtpTransID, which is different from other IOTP transactions.
3. The OtpTransId of a Ping transaction SHOULD BE different from any
other IOTP transaction.
5. Trading Blocks
Trading Blocks consist of one or more Trading Components and
optionally one or more Signature Components. One or more Trading
Surendra Reddy et al. [Page 81]
Internet Draft IOTP/1.0 September 21, 1998
Blocks may be contained within the IOTP Messages which are
physically sent in the form of [XML] documents between the
different Organizations that are taking part in a trade.
Trading Blocks are defined as part of the definition of an IOTP
Message (see section 3.1).
This section describes the Trading Blocks used in this version of
IOTP. They are:
- Authentication Request Block
- Authentication Response Block
- Delivery Request Block
- Delivery Response Block
- Error Block
- Inquiry Request Block
- Inquiry Response Block
- Offer Response Block
- Payment Exchange Block
- Payment Request Block
- Payment Response Block
- Payment Instrument Customer Care Exchange Block
- Payment Instrument Customer Care Request Block
- Payment Instrument Customer Care Response Block
- Signature Block
- Trading Protocol Options Block
- TPO Selection Block
The Transaction Reference Block is described in section 3.5.
5.1. Trading Protocol Options Block
The TPO Trading Block contains options which apply to the IOTP
Transaction. The definition of a TPO Trading Block is as follows.
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Trading Protocol Options Block within the
IOTP Transaction (see section 3.6 ID
Attributes).
Content:
ProtocolOptions The Protocol Options Component (see section
Surendra Reddy et al. [Page 82]
Internet Draft IOTP/1.0 September 21, 1998
6.1)defines the options which apply to the
whole IOTP Transaction (see section 4).
BrandList This Brand List Component contains one or
more payment brands and protocols which may
be selected (see section 6.12).
Org The Organization Components (see section
6.7) identify the Organizations and their
roles in the IOTP Transaction. The roles and
Organizations which must be present will
depend on the particular type of IOTP
Transaction. See the definition of each
transaction in section 4. Open Trading
Protocol Transactions.
The TPO Block should contain:
- the Protocol Options Component
- the Organization Component with the Trading Role of Merchant
- the Organization Component with the Trading Role of Consumer
- optionally, the Organization Component with the Trading Role
of DeliverTo, if there is a Delivery included in the IOTP
Transaction
- Brand List Components for each payment in the IOTP
Transaction
- Organization Components for all the Payment Handlers
involved
- optionally, Organization Components for the Delivery Handler
(if any) for the transaction
- additional Organization Components that the Merchant may
want to include. For example
o a Customer Care Provider
o an Certificate Authority that offers Merchant
"Credentials" or some other warranty on the goods or
services being offered.
5.2. TPO Selection Block
The TPO Selection Block contains the results of selections made
from the options contained in the Trading Protocol Options Block
(see section 5.1).The definition of a TPO Selection Block is as
follows.
TpoSelectionBlk (BrandSelection+) >
<!ATTLIST T<!ELEMENT poSelectionBlk
ID ID #REQUIRED >
Surendra Reddy et al. [Page 83]
Internet Draft IOTP/1.0 September 21, 1998
Attributes:
ID An identifier which uniquely identifies the
TPO Selection Block within the IOTP
Transaction.
Content:
BrandSelection This identifies the choice of payment brand
and payment protocol to be used in a payment
within the IOTP Transaction. There is one
Brand Selection Component (see section 6.17)
for each payment to be made in the IOTP
Transaction.
The TPO Selection Block should contain one Brand Selection
Component for each Brand List in the TPO Block.
5.3. Offer Response Block
The Offer Response Block contains details of the goods, services,
amount, delivery instructions or financial transaction which is
to take place. Its definition is as follows.
<!ELEMENT OfferRespBlk (AuthData*, Order?, Payment*, Delivery?,
Status ) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Offer Response Block within the IOTP
Transaction.
Content:
AuthData The Authentication Data Component contains
information about how Authentication
associated with the Offer will occur. See
section 6.2.
Order The Order Component contains details about
the goods, services or financial transaction
which is taking place see section 6.4.
The Order Component must be present unless
the ProcessState attribute of the Status
Surendra Reddy et al. [Page 84]
Internet Draft IOTP/1.0 September 21, 1998
Component is set to Failed.
Payment The Payment Components contain information
about the payments which are to be made see
section 6.21.
Delivery The Delivery Component contains details of
the delivery to be made (see section 6.24).
Status Contains status information about the
business success (see section 7.2) or
failure of the generation of the Offer. Note
that in an Offer Response Block, a
ProcessState of NotYetStarted or InProgress
are illegal values.
The Offer Response Block should contain:
- the Order Component for the IOTP Transaction
- Payment Components for each Payment in the IOTP Transaction
- the Delivery Component for IOTP Transaction requires (if any)
- the Authentication Data Component (if required) for each
Payment
5.4. Authentication Request Block
This Authentication Request Block contains the challenge data
which is used to obtain information about and optionally
authenticate a Consumer by another Trading Role. Its definition
is as follows.
<!ELEMENT AuthReqBlk (AuthData?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
Attributes
ID An identifier which uniquely identifies the
Authentication Request Block within the IOTP
Transaction.
Content
AuthData If the Authentication Data Component is not
present it means that the Authentication
Request Block is just requesting the return
of Organization Components which describe
Surendra Reddy et al. [Page 85]
Internet Draft IOTP/1.0 September 21, 1998
the Consumer.
If the optional Authentication Data
Component (see section 6.2) is present it
contains data which describes what
additional Authentication the consumer must
provide.
5.5. Authentication Response Block
The Authentication Response Block contains the response which
results from processing the Authentication Request Block. Its
definition is as follows.
<!ELEMENT AuthRespBlk (AuthResp, Org+) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Authentication Response Block within the IOTP
Transaction.
Content:
AuthResp The Authentication Response Component which
contains the results of processing the
challenge data in the Authentication Data
Component - see section 6.3.
Org Organization Components which contain
information corresponding to the Consumer
and DelivTo Trading Roles.
5.6. Payment Request Block
The Payment Request Block contains information which requests
that a payment is started. Its definition is as follows.
<!ELEMENT PayReqBlk (AuthData?, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
Attributes:
Surendra Reddy et al. [Page 86]
Internet Draft IOTP/1.0 September 21, 1998
ID An identifier which uniquely identifies the
Payment Request Block within the IOTP
Transaction.
Content:
AuthData The optional Authentication Data Component
contains data about how Authentication
associated with the payment, if any, will
occur. See section 6.2.
BrandList The Brand List Component contains a list of
one or more payment brands and protocols
which may be selected (see section 6.12).
BrandSelection This identifies the choice of payment brand,
the payment protocol and the payment handler
to be used in a payment within the IOTP
Transaction. There is one Brand Selection
Component (see section 6.17) for each
payment to be made in the IOTP Transaction.
Payment The Payment Components contain information
about the payment which is being made see
section 6.21.
PaySchemeData The Payment Scheme Component contains
payment scheme specific data see section
6.22.
Org The Organization Component contains details
of Organizations involved in the payment
(see section 6.7). The Organizations present
are dependent on the IOTP Transaction and the
data which is to be signed. See section 9
Security Considerations for more details.
The Payment Request Block should contain:
- the Organization Component with a Trading Role of Merchant
- the Organization Component with the Trading Role of Consumer
- the Payment Component for the Payment
- the Brand List Component for the Payment
- the Brand Selection Component for the Brand List
- the Organization Component for the Payment Handler of the
Payment
- the Organization Component (if any) for the Organization
which carried out the previous step, for example another
Surendra Reddy et al. [Page 87]
Internet Draft IOTP/1.0 September 21, 1998
Payment Handler
- the Organization Component for the Organization which is to
carry out the next step, if any. This may be, for example,
either a Delivery Handler or a Payment Handler.
- the Organization Components for any additional Organizations
that the Merchant has included in the Offer Response Block
- an Optional Payment Scheme Data Component, if required by
the Payment Method as defined in the IOTP supplement for the
payment method.
5.7. Payment Exchange Block
The Payment Exchange Block contains payment scheme specific data
which is exchanged between two of the roles in a trade. Its
definition is as follows.
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Exchange Block within the IOTP
Transaction.
Content:
PaySchemeData This Trading Component contains payment
scheme specific data see section 6.22
Payment Scheme Component.
5.8. Payment Response Block
This Payment Response Block contains a information about the
Payment Status, a Payment Receipt, and an optional payment
protocol message. Its definition is as follows.
<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Response Block within the IOTP
Surendra Reddy et al. [Page 88]
Internet Draft IOTP/1.0 September 21, 1998
Transaction.
Content:
Status Contains status information about the
business success (see section 7.2) or
failure of the payment. Note that in a Pay
Response Block, a ProcessState of
NotYetStarted or InProgress are illegal
values.
PayReceipt Contains payment scheme specific data which
can be used to verify the payment occurred.
See section 6.23 Payment Receipt Component.
PaySchemeData Contains payment scheme specific data see
section, for example a payment protocol
message. See 6.22 Payment Scheme Component.
5.9. Delivery Request Block
The Delivery Request Block contains details of the goods or
services which are to be delivered together with a signature
which can be used to check that delivery is authorised. Its
definition is as follows.
<!ELEMENT DeliveryReqBlk (Order, Org*, Delivery) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Request Block within the IOTP
Transaction.
Content:
Order The Order Component contains details about
the goods, services or financial transaction
which is taking place see section 6.4.
Org The Organization Components (see section
6.7) identify the Organizations and their
roles in the IOTP Transaction. The roles and
Organizations which must be present will
depend on the particular type of IOTP
Transaction. See the definition of each
Surendra Reddy et al. [Page 89]
Internet Draft IOTP/1.0 September 21, 1998
transaction in section 4. Open Trading
Protocol Transactions.
Delivery The Delivery Component contains details of
the delivery to be made (see section 6.24).
The Delivery Request Block contains:
- the Organization Component with a Trading Role of Merchant
- the Organization Component for the Consumer and DeliverTo
Trading Roles
- the Delivery Component for the Delivery
- the Organization Component for the Delivery Handler.
Specifically the Organization Component identified by the
ActionOrgRef attribute on the Delivery Component
- the Organization Component (if any) for the Organization
which carried out the previous step, for example a Payment
Handler
- the Organization Components for any additional Organizations
that the Merchant has included in the Offer Response Block
5.10. Delivery Response Block
The Delivery Response Block contains a Delivery Note containing
details on how the goods will be delivered. Its definition is as
follows. Note that in a Delivery Response Block a Delivery Status
Element with a DeliveryStatusCode of NotYetStarted or InProgress
is invalid.
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Response Block within the IOTP
Transaction.
Content:
Status Contains status information about the
business success (see section 7.2) or
failure of the delivery. Note that in a
Delivery Response Block, a ProcessState of
NotYetStarted or InProgress are illegal
values.
Surendra Reddy et al. [Page 90]
Internet Draft IOTP/1.0 September 21, 1998
DeliveryNote The Delivery Note Component contains details
about how the goods or services will be
delivered (see section 6.26).
5.11. Payment Instrument Customer Care Request Block
The Payment Instrument Customer Care Request Block contains
information which requests that an IOTP Payment Instrument
Customer Care Transaction is started in order to provide Customer
Care for the Consumer's Payment Instrument. Its definition is as
follows.
<!ELEMENT PayInstCCReqBlk (PaymethodInfo, PaySchemeData*) >
<!ATTLIST PayInstCCReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Request
Block within the IOTP Transaction.
Content:
PayMethodInfo The Payment Method Information Component
(see section 6.27) contains data which
describes the Payment Method which initiated
the Payment Instrument Customer Care
Transaction
PaySchemeData Optional Payment Scheme Components (see
section 6.22) that contain payment scheme
specific data. The sequence of the Payment
Scheme Components in the Block is the
sequence in which they should be processed
by the Payment Scheme software which
receives this message.
5.12. Payment Instrument Customer Care Exchange Block
The Payment Instrument Customer Care Exchange Block contains
payment scheme specific data which is exchanged between the
Payment Instrument User and the Payment Scheme Customer Care
Provider. Its definition is as follows.
<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
ID ID #REQUIRED >
Surendra Reddy et al. [Page 91]
Internet Draft IOTP/1.0 September 21, 1998
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Exchange
Block within the IOTP Transaction.
Content:
PaySchemeData Optional Payment Scheme Components (see
section 6.22) that contain payment scheme
specific data. The sequence of the Payment
Scheme Components in the Block is the
sequence in which they should be processed
by the Payment Scheme software which
receives this message.
5.13. Payment Instrument Customer Care Response Block
The Payment Instrument Customer Care Response Block contains the
final Payment Scheme Component of the IOTP Payment Instrument
Customer Care Transaction. Its definition is as follows.
<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Response
Block within the IOTP Transaction.
Content:
PaySchemeData Optional Payment Scheme Components (see
section 6.22) that contain payment scheme
specific data. The sequence of the Payment
Scheme Components in the Block is the
sequence in which they should be processed
by the Payment Scheme software which
receives this message.
5.14. Inquiry Request Trading Block
The Inquiry Request Trading Block contains an Inquiry Type
Component and an optional Payment Scheme Component to contain
payment scheme specific inquiry messages.
Surendra Reddy et al. [Page 92]
Internet Draft IOTP/1.0 September 21, 1998
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Request Trading Block within the IOTP
Transaction.
Content:
InquiryType Inquiry Type Component (see section 6.29)
that contains the type of inquiry.
PaySchemeData Payment Scheme Component (see section 6.22)
that contains payment scheme specific
inquiry messages for inquiries on payments.
This is present when the Type attribute of
Inquiry Type Component is Payment.
5.15. Inquiry Response Trading Block
The Inquiry Response Trading Block contains a Status Component
and an optional Payment Scheme Component to contain payment
scheme specific inquiry messages. Its purpose is to enquire on
the current status of an IOTP transaction at a server.
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedOtpMsgRef NMTOKEN #IMPLIED
LastSentOtpMsgRef NMTOKEN #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Response Trading Block within the
IOTP Transaction.
LastReceivedOtpMs Contains an Element Reference (see section
gRef 3.7) to the Message Id Component (see
section 3.5.2) of the last message this
server has received from the Consumer. If
there is no previously received message from
the Consumer in the pertinent transaction,
this attribute should be contain the value
Null. This attribute exists for debugging
Surendra Reddy et al. [Page 93]
Internet Draft IOTP/1.0 September 21, 1998
purposes.
LastSentOtpMsgRef Contains an Element Reference (see section
3.7) to the Message Id Component (see
section 3.5.2) of the last message this
server has sent to the Consumer. If there is
no previously sent message to the Consumer
in the pertinent transaction, this attribute
should contain the value Null. This
attribute exists for debugging purposes.
Content:
Status Contains status information about the
business success (see section 7.2) or
failure of a certain trading exchange (i.e.,
Offer, Payment, or Delivery).
PaySchemeData Payment Scheme Component (see section 6.22)
that contains payment scheme specific
inquiry messages for inquiries on payments.
This is present when the Type attribute of
StatusType attribute of the Status Component
is set to Payment.
5.16. Ping Request Block
The Ping Request Block is used to determine if a Server is
operating and whether or not cryptography is compatible.
The definition of a Ping Request Block is as follows.
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
Attributes:
ID An identifier which uniquely identifies the
Ping Request Trading Block within the IOTP
Transaction.
Content:
Org Optional Organization Components (see
section 6.7).
If no Organization Component is present then
Surendra Reddy et al. [Page 94]
Internet Draft IOTP/1.0 September 21, 1998
the Ping Request is anonymous and simply
determines if the server is operating.
However if Organization Components are
present, then it indicates that the sender
of the Ping Request wants to verify that
digital signatures can be handled.
In this case the sender includes:
an Organization Component that identifies
itself specifying the Trading Role(s) it is
taking in IOTP transactions (Merchant,
Payment Handler, etc)
an Organization Component that identifies
the intended recipient of the message.
These are then used to generate a signature
over the Ping Response Block.
5.17. Ping Response Block
The Ping Response Trading Block provides the result of a Ping
Request.
It contains an Organization Component that identifies the sender
of the Ping Response.
If the Ping Request to which this block is a response contained
Organization Components, then it also contains those Organization
Components.
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok|Busy|Down) #REQUIRED
SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
Attributes:
ID An identifier which uniquely identifies the
Ping Request Trading Block within the IOTP
Transaction.
PingStatusCode Contains a code which shows the status of
the sender software which processes IOTP
Surendra Reddy et al. [Page 95]
Internet Draft IOTP/1.0 September 21, 1998
messages. Valid values are:
Ok. Everything with the service is working
normally, including the signature
verification.
Busy. Things are working normally but there
may be some delays.
Down. The server is not functioning fully
but can still provide a Ping response.
SigVerifyStatusCo Contains a code which shows the status of
de signature verification. This is present only
when the message containing the Ping Request
Block also contains a Signature Block. Valid
values are:
Ok. The signature has successfully been
verified and proved compatible.
NotSupported The receiver of this Ping
Request Block does not support validation of
signatures.
Fail. Signature verification failed.
Xml:lang Defines the language used in PingStatusDesc.
This is present when PingStatusDesc is
present.
PingStatusDesc Contains a short description of the status
of the server which sends this Ping Response
Block. Servers, if their designers want, can
use this attribute to send more refined
status information than PingStatusCode which
can be used for debugging purposes, for
example.
Content:
Org These are Organization Components (see
section 6.7).
The Organization Components of the sender of
the Ping Response is always included in
addition to the Organization Components sent
in the Ping Request.
Note: Ping Status Code values do not include a value such as
Fail, since, when the software receiving the Ping Request message
is not working at all, no Ping Response message will be sent
Surendra Reddy et al. [Page 96]
Internet Draft IOTP/1.0 September 21, 1998
back.
5.18. Signature Block
The Signature Block contains one or more Signature Components and
associated Certificates which sign data associated with the IOTP
Transaction. For a general discussion and introduction to how IOTP
uses signatures, see section 9 Security Considerations. The
definition of the Signature Component and certificates is
contained in the paper "Digital Signature for XML - Proposal",
see [XMLSIG].
The definition of a Signature Block is as follows:
<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Signature Block within the IOTP Transaction.
Content:
OtpSig Contains a Digital Signature. See the paper
"Digital Signature for XML - Proposal"
[XMLSIG], for its definition
OtpCert Contains a Digital Certificate. See the
paper "Digital Signature for XML - Proposal"
[XMLSIG], for its definition
The contents of a Signature Block depends on the Trading Block
that is contained in the same IOTP Message as the Signature Block.
5.18.1. Offer Response
A Signature Block which is in the same message as an Offer
Response Block contains just an Offer Response Signature
Component (see section 6.31).
5.18.2. Payment Request
A Signature Block which is in the same message as a Payment
Request Block contains:
- an Offer Response Signature Component (see section 6.31),
Surendra Reddy et al. [Page 97]
Internet Draft IOTP/1.0 September 21, 1998
and
- if the Payment is dependent on an earlier step (as indicated
by the StartAfter attribute on the Payment Component), then
the Payment Receipt Signature Component (see section 6.32)
generated by the previous step
5.18.3. Payment Response
A Signature Block which is in the same message as a Payment
Response Block contains just a Payment Receipt Signature
Component (see section 6.32) generated by the step.
5.18.4. Delivery Request
A Signature Block which is in the same message as a Delivery
Request Block contains:
- an Offer Response Signature Component (see section 6.31),
and
- the Payment Receipt Signature Component (see section 6.32)
generated by the previous step.
5.19. Error Block
The Error Trading Block contains one or more Error Components
(see section 6.34) which contain information about Technical
Errors (see section 7.1) in an IOTP Message which has been
received by one of the Trading Roles involved in the trade.
For clarity two phrases are defined which are used in the
description of an Error Trading Block:
- message in error. An IOTP message which contains or causes an
error of some kind
- message reporting the error. An IOTP message that contains an
Error Trading Block that describes the error found in a
message in error.
An Error Trading Block may be contained in any message reporting
the error. The action which then follows depends on the severity
of the error. See the definition of an Error Component, for an
explanation of the different types of severity and the actions
which can then occur.
Note: Although, an Error Trading Block can report multiple
different errors using multiple Error Components, there is no
obligation on a developer of an IOTP Aware Application to do so.
Surendra Reddy et al. [Page 98]
Internet Draft IOTP/1.0 September 21, 1998
The structure of an Error Trading Block is as follows.
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies
the Error Trading Block within the IOTP
Transaction.
Content:
ErrorComp An Error Component (see section 6.34) that
contains information about an individual
Technical Error.
PaySchemeDat An optional Payment Scheme Component (see
a section 6.22) which contains a Payment
Scheme Message. See the appropriate
payment scheme supplement to determine
whether or not this component needs to be
present and for the definition of what it
MUST contain.
6. Trading Components
This section describes the Trading Components used within IOTP.
Trading Components are the child XML elements which occur
immediately below a Trading Block.
The Trading Components described in this section are listed below
in approximately the sequence they are likely to be used:
- Protocol Options Component
- Authentication Data Component
- Authentication Response Component
- Order Component
- Organization Component
- Brand List Component
- Brand Selection Component
- Payment Component
- Payment Scheme Component
- Payment Receipt Component
- Delivery Component
Surendra Reddy et al. [Page 99]
Internet Draft IOTP/1.0 September 21, 1998
- Delivery Note Component
- Signature Component
- Certificate Component
- Error Component
Note that the following components are listed in other sections
of this specification:
- Transaction Id Component (see section 3.5.1)
- Message Id Component (see section 3.5.2)
6.1. Protocol Options Component
Protocol options are options which apply to the IOTP Transaction
as a whole. Essentially it is used to identify what type of IOTP
Transaction is being carried out. For Baseline IOTP it will
identify one of the "Baseline" IOTP Transactions (see section 4.
Internet Open Trading Protocol Transactions) by name.
The definition of a Protocol Options Component is as follows.
<!ELEMENT ProtocolOptions EMPTY>
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #REQUIRED
SecureSenderNetLocn CDATA #REQUIRED
SuccessNetLocn CDATA #REQUIRED
CancelNetLocn CDATA #REQUIRED
ErrorNetLocn CDATA #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Protocol Options Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
ShortDesc This contains a short description of the IOTP
Transaction in the language defined by
xml:lang. Its purpose is to provide an
explanation of what type of IOTP Transaction
is being conducted by the parties involved.
Surendra Reddy et al. [Page 100]
Internet Draft IOTP/1.0 September 21, 1998
It is used to facilitate selecting an
individual transaction from a list of
similar transactions , for example from a
database of IOTP transactions which has been
stored by a Consumer, Merchant, etc.
SenderNetLocn This contains the non secured net location
of the sender of the TPO Block in which the
Protocol Options Component is contained.
It is the net location to which the
recipient of the TPO block should send a TPO
Selection Block if required.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
SecureSenderNetLo This contains the secured net location of
cn the sender of the TPO Block in which the
Protocol Options Component is contained.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
SuccessNetLocn This contains the net location that the
should be displayed after the IOTP
Transaction has successfully completed.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
CancelNetLocn This contains the net location that should
be displayed by the Consumer after the IOTP
Transaction has been cancelled by one of the
Trading Roles.
For this purpose, cancel is defined as
sending or receiving a Fail Trading Block
(see section 5) where the FailType attribute
of all the FailReasons in the block are set
to Cancel.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
Surendra Reddy et al. [Page 101]
Internet Draft IOTP/1.0 September 21, 1998
ErrorNetLocn This contains the net location that should
be displayed after the IOTP Transaction has
failed due to an error.
For this purpose, an error is defined as
sending or receiving an Error Block (see
section 5.23) where the Severity attribute
of at least one of the Error Components (see
section 6.34) in the Error Block is set to
HardError, or there has been an
irrecoverable loss of communication.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
6.2. Authentication Data Component
This Trading Component contains data about how an Authentication
within the IOTP Transaction will occur. Its definition is as
follows.
<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
ID ID #REQUIRED
AuthMethod NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Authentication Data Component within the IOTP
Transaction.
AuthMethod This identifies the content of the
Authentication Data Component. Valid values
are:
sha1 This indicates that the recipient of
the Authentication Data Component should
generate a hash. See 6.3 Authentication
Response Component.
pay:ppp A payment protocol specific
authentication method. The "ppp" identifies
a payment protocol associated with a payment
exchange which is part of the IOTP
Transaction. In this case the content and
Surendra Reddy et al. [Page 102]
Internet Draft IOTP/1.0 September 21, 1998
format of the AuthData element is defined
in the appropriate Payment Scheme
supplement. For example if a payment method
"xzpay" provided an authentication method,
then this attribute would have the value
"pay:xzpay"
x-ddd:nnn a user defined authentication
scheme type see section (3.9.3 User Defined
Codes).
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent This contains the challenge data as Packaged
Content (see section 3.8) that is to be
responded to using the method indicated by
AuthMethod.
6.3. Authentication Response Component
This Authentication Response Component contains the results of an
authentication. Its definition is as follows.
<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Surendra Reddy et al. [Page 103]
Internet Draft IOTP/1.0 September 21, 1998
Attributes:
ID An identifier which uniquely identifies the
Authentication Response Component within the
IOTP Transaction.
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent This contains the response to the content of
the Authentication Data Component see
section 6.2 as Packaged Content (see section
3.8).
For a payment specific scheme, it may
contain scheme-specific data. Refer to the
scheme-specific supplemental documentation.
6.4. Order Component
An Order Component contains information about an order. Its
definition is as follows.
<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
ID ID #REQUIRED
Surendra Reddy et al. [Page 104]
Internet Draft IOTP/1.0 September 21, 1998
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Order Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
OrderIdentifier This is a code, reference number or other
identifier which the creator of the Order
may use to identify the order. It must be
unique within an IOTP Transaction. If it is
used in this way, then it may remove the
need to specify any content for the Order
element as the reference can be used to look
up the necessary information in a database.
ShortDesc A short description of the order in the
language defined by xml:lang. It is used to
facilitate selecting an individual order
from a list of orders, for example from a
database of orders which has been stored by
a Consumer, Merchant, etc.
OkFrom The date and time in [UTC] format after
which the offer made by the Merchant lapses.
OkTo The date and time in [UTC] format before
which a Value Acquirer may accept the offer
made by the Merchant is not valid.
ApplicableLaw A phrase in the language defined by xml:lang
which describes the state or country of
jurisdiction which will apply in resolving
problems or disputes.
ContentSoftwareId This contains information which identifies
Surendra Reddy et al. [Page 105]
Internet Draft IOTP/1.0 September 21, 1998
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent An optional description of the order
information as Packaged Content (see section
3.8).
6.5. Order Description Content
The Packaged Content element will normally be required, however
it may be omitted where sufficient information about the purchase
can be provided in the ShortDesc attribute
The description of the order in the Packaged Content should not
include currency and amount information since this is contained
in the payment related trading components (Brand List, Brand
Selection and Payment).
For interoperability, implementations must support Plain Text as
a minimum so that it can be easily displayed.
6.6. OkFrom and OkTo Timestamps
Note that:
the OkFrom date may be later than the OkFrom date on the
Payment Component (see section 6.21) associated with this
Surendra Reddy et al. [Page 106]
Internet Draft IOTP/1.0 September 21, 1998
order, and
similarly, the OkTo date may be earlier that the OkTo date
on the Payment Component (see section 6.21).
Note: Disclaimer. The following information provided in this note
does not represent formal advice of the Internet Open Trading Protocol
Consortium, any of its members or the authors of this
specification. Readers of this specification must form their own
views and seek their own legal counsel on the usefulness and
applicability of this information.
The merchant in the context of Internet commerce with anonymous
consumers initially frames the terms of the offer on the web
page, and in order to obtain the good or service, the consumer
must accept them.
If there is to be a time-limited offer, it recommended that
merchants communicate this to the consumer and state in the order
description in a manner which is clear to the consumer that:
- the offer is time limited
- the OkFrom and OkTo timestamps specify the validity of the
offer
- the clock, e.g. the merchant's clock, that will be used to
determine the validity of the offer
6.7. Organization Component
The Organization Component provides information about an
individual or an Organization. This can be used for a variety of
purposes. For example:
- to describe the merchant who is selling the goods,
- to identify who made a purchase,
- to identify who will take delivery of goods,
- to provide a customer care contact,
- to describe who will be the Payment Handler.
Its definition is as follows.
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?,
PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
Surendra Reddy et al. [Page 107]
Internet Draft IOTP/1.0 September 21, 1998
OtpMsgIdPrefix NMTOKEN #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Organization Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
OrgId A code which identifies the Organization
described by the Organization Component. See
6.7.1 Organization IDs, below.
OtpMsgIdPrefix Contains the prefix which must be used for
all IOTP Messages sent by the Organization in
this IOTP Transaction. The values to be used
are defined in 3.6.1 IOTP Message ID
Attribute Definition.
LegalName For Organizations which are companies this
is their legal name in the language defined
by xml:lang. It is required for
Organizations who have a Trading Role other
than Consumer or DeliverTo.
ShortDesc A short description of the Organization in
the language defined by xml:lang. It is
typically the name by which the Organization
is commonly known. For example, if the legal
name was "Blue Meadows Financial Services
Inc.". Then its short name would likely be
"Blue Meadows".
It is used to facilitate selecting an
individual Organization from a list of
Organizations, for example from a database
of Organizations involved in IOTP
Transactions which has been stored by a
consumer.
Surendra Reddy et al. [Page 108]
Internet Draft IOTP/1.0 September 21, 1998
LogoNetLocn The net location which can be used to
download the logo for the Organization. See
section 0.
The content of this attribute must conform
to [RFC1738].
Content:
TradingRole See 6.8 Trading Role Element below.
ContactInfo See 6.9 Contact Information Element below.
PersonName See 6.10 Person Name below.
PostalAddress See 6.11 Postal Address below.
6.7.1. Organization IDs
Organization IDs are used by one IOTP Trading Role to identify
another. In order to avoid confusion, this means that these IDs
must be globally unique.
In principle this is achieved in the following way:
- the Organization Id for all trading roles, apart from the
Consumer Trading Role, uses a domain name as their globally
unique identifier,
- the Organization Id for a Consumer Trading Role is allocated
by one of the other Trading Roles in an IOTP Transaction and
is made unique by concatenating it with that other roles'
Organization Id,
- once a Consumer is allocated an Organization Id within an
IOTP Transaction the same Organization Id is used by all the
other trading roles in that IOTP transaction to identify that
Consumer.
Specifically, the content of the Organization ID is defined as
follows:
OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/"
NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
ConsumerOrgId If the Organization ID for a Consumer
Surendra Reddy et al. [Page 109]
Internet Draft IOTP/1.0 September 21, 1998
consists of:
a standard prefix is to identify that the
Organization Id is for a consumer, followed
by
one or more characters which conform to the
definition of an XML "namechar". See [XML]
specifications, followed by
the NonConsumerOrgId for the Organization
which allocated the ConsumerOrgId. It is
normally the Merchant role.
Use of upper and lower case is significant.
NonConsumerOrgId If the Role is not Consumer then this
contains the Canonical Name for the non-
consumer Organization being described by the
Organization Component. See [DNS].
Note that a NonConsumerOrgId may not start
with the ConsumerOrgIdPrefix.
Use of upper and lower case is not
significant.
Examples of Organization Ids follow:
newjerseybooks.com - a merchant Organization id
westernbank.co.uk - a payment handler Organization id
consumer:1000247ABH/newjerseybooks.com - a consumer
Organization id allocated by a merchant
6.8. Trading Role Element
This identifies the Trading Role of an individual or Organization
in the IOTP Transaction. Note, an Organization may have more than
one Trading Role and several roles may be present in one
Organization element. Its definition is as follows:
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
TradingRole NMTOKEN #REQUIRED
ErrorNetLocn CDATA #IMPLIED >
Attributes:
Surendra Reddy et al. [Page 110]
Internet Draft IOTP/1.0 September 21, 1998
TradingRole The trading role of the Organization. Valid
values are:
Consumer. The person or Organization that is
acting in the role of a consumer in the IOTP
Transaction.
Merchant. The person or Organization that is
acting in the role of merchant in the IOTP
Transaction.
PaymentHandler. The financial institution or
other Organization which is a Payment
Handler for the IOTP Transaction
DeliveryHandler. The person or Organization
that is the delivering the goods or services
for the IOTP Transaction
DelivTo. The person or Organization that is
receiving the delivery of goods or services
in the IOTP Transaction
CustCare. The Organization and/or individual
who will provide customer care for an IOTP
Transaction.
x-ddd:nnn a user defined role (see section
3.9.3 User Defined Codes).
ErrorNetLocn The net location to which IOTP messages
containing Error Components with a Severity
of either HardError or TransientError are
sent. See section 6.35 Error Processing
Guidelines for more details.
This attribute must be set when TradingRole
is set to PaymentHandler or DeliveryHandler.
The content of this attribute is dependent
on the Transport Mechanism see the Transport
Mechanism Supplement.
6.9. Contact Information Element
This contains information which can be used to contact an
Organization or an individual. All attributes are optional
however at least one item of contact information should be
present. Its definition is as follows.
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
Surendra Reddy et al. [Page 111]
Internet Draft IOTP/1.0 September 21, 1998
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes
within this element. See section 3.10
Identifying Languages.
Tel A telephone number by which the Organization
may be contacted. Note that this is a text
field and no validation is carried out on
it.
Fax A fax number by which the Organization may
be contacted. Note that this is a text field
and no validation is carried out on it.
Email An email address by which the Organization
may be contacted. Note that this field
should conform to the conventions for
address specifications contained in
[RFC822].
NetLocn A location on the Internet by which
information about the Organization may be
obtained that can be displayed using a web
browser.
The content of this attribute must conform
to [RFC1738].
6.10. Person Name Element
This contains the name of an individual person. All fields are
optional however as a minimum either the GivenName or the
FamilyName should be present. Its definition is as follows.
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
Surendra Reddy et al. [Page 112]
Internet Draft IOTP/1.0 September 21, 1998
FamilyName CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes
within this element. See section 3.10
Identifying Languages.
Title A distinctive name; personal appellation,
hereditary or not, denoting or implying
office (e.g. judge, mayor) or nobility (e.g.
duke, duchess, earl), or used in addressing
or referring to a person (e.g. Mr, Mrs,
Miss)
GivenName The primary or main name by which a person
is known amongst and identified by their
family, friends and acquaintances. Otherwise
known as first name or Christian Name.
Initials The first letter of the secondary names
(other than the Given Name) by which a
person is known amongst or identified by
their family, friends and acquaintances.
FamilyName The name by which family of related
individuals are known. It is typically the
part of an individual's name which is passed
on by parents to their children.
6.11. Postal Address Element
This contains an address which can be used, for example, for the
physical delivery of goods, services or letters. Its definition
is as follows.
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True|False) 'False' >
Surendra Reddy et al. [Page 113]
Internet Draft IOTP/1.0 September 21, 1998
Attributes:
xml:lang Defines the language used by attributes
within this element. See section 3.10
Identifying Languages.
AddressLine1 The first line of a postal address. e.g.
"The Meadows"
AddressLine2 The second line of a postal address. e.g.
"Sandy Lane"
CityOrTown The city of town of the address. e.g.
"Carpham"
StateOrRegion The state or region within a country where
the city or town is placed. e.g. "Surrey"
Country The country for the address. e.g. "UK"
LegalLocation This identifies whether the address is the
Registered Address for the Organization. At
least one address for the Organization must
have a value set to True unless the Trading
Role is either Consumer or DeliverTo.
6.12. Brand List Component
Brand List Components are contained within the Trading Protocol
Options Block (see section 5.1) of the IOTP Transaction. They
contains lists of:
payment Brands (see also section 2.8 Brands and Brand
Selection),
amounts to be paid in the currencies that are accepted or
offered by the Merchant,
the payment protocols which can be used to make payments
with a Brand, and
the net locations of the Payment Handlers which accept
payment for a payment protocol
The definition of a Brand List Component is as follows.
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
Surendra Reddy et al. [Page 114]
Internet Draft IOTP/1.0 September 21, 1998
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit ) #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Brand List Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
ShortDesc A text description in the language defined
by xml:Lang giving details of the purpose of
the Brand List. This information must be
displayed to the receiver of the Brand List
in order to assist with making the
selection. It is of particular benefit in
allowing a Consumer to distinguish the
purpose of a Brand List when an IOTP
Transaction involves more than one payment.
PayDirection Indicates the direction in which the payment
for which a Brand is being selected is to be
made. Its values may be:
Debit The sender of the Payment Request
Block (e.g. the Consumer) to which this
Brand List relates will make the payment to
the Payment Handler, or
Credit The sender of the Payment Request
Block to which this Brand List relates will
receive a payment from the Payment Handler.
Content:
Brand This describes a Brand. The sequence of the
Brand elements within the Brand List does not
indicate any preference.
It is recommended that software which
processes this Brand List presents Brands in
a sequence which the receiver of the Brand
List prefers.
Surendra Reddy et al. [Page 115]
Internet Draft IOTP/1.0 September 21, 1998
ProtocolAmount This links a particular Brand to:
the currencies and amounts in CurrencyAmount
elements that can be used with the Brand,
and
the Payment Protocols and Payment Handlers,
which can be used with those currencies and
amounts, and a particular Brand
CurrencyAmount This contains a currency code and an amount.
PayProtocol This contains information about a Payment
Protocol and the Payment Handler which may
be used with a particular Brand.
6.13. Brand Element
A Brand Element describes a brand that can be used for making a
payment. One or more of these elements is carried in each Brand
List Component that has the PayDirection attribute set to Debit.
Exactly one Brand Element may be carried in a Brand List
Component that has the PayDirection attribute set to Credit.
<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
Id ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId NMTOKEN #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced
in a Brand Selection Component contained in
a later Payment Request message and
uniquely identifies the Brand element
within the IOTP Transaction.
xml:lang Defines the language used by attributes and
content of this element. See section 3.10
Identifying Languages.
Surendra Reddy et al. [Page 116]
Internet Draft IOTP/1.0 September 21, 1998
BrandId This contains a unique identifier for the
brand or promotional brand. It is used to
match against a list of Payment Instruments
which the Consumer holds to determine
whether or not the Consumer can pay with
the Brand.
The syntax for a BrandId is as follows:
BrandId ::= UserDefinedCode |
BrandIdDomain ":" BrandValue
Currently the only valid value for the
BrandIdDomain is otp which indicates that
the BrandValue is registered with IOTP.
The valid values for BrandValue for brands
defined within the IOTP Brand domain are
obtainable from the IOTP web site
http:www.otp.org.
A user defined code follows the conventions
defined in section 3.9.3. Uniqueness of a
user defined BrandId is not guaranteed.
BrandName This contains the name of the brand, for
example MasterCard Credit. This is the
description of the Brand which is displayed
to the consumer in the Consumers language
defined by xml:lang. For example it might
be "American Airlines Advantage Visa". Note
that this attribute is not used for
matching against the payment instruments
held by the Consumer.
BrandLogoNetLocn The net location which can be used to
download the logo for the Organization.
The content of this attribute must conform
to [RFC1738].
BrandNarrative This optional attribute is designed to be
used by the Merchant to indicate some
special conditions or benefit which would
apply if the Consumer selected that brand.
For example "5% discount", "free shipping
and handling", "free breakage insurance for
1 year", "double air miles apply", etc.
Surendra Reddy et al. [Page 117]
Internet Draft IOTP/1.0 September 21, 1998
ProtocolAmountRefs Identifies the protocols and related
currencies and amounts which can be used
with this Brand. Specified as a list of
ID's of Protocol Amount Elements (see
section 6.14) contained within the Brand
List.
ContentSoftwareId This optional attribute contains
information which identifies the software
which generated the content of the element.
Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated
the content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Optional Packaged Content (see section 3.8)
containing information about the brand which
may be used by the payment protocol. The
content of this information is defined in
the supplement for a payment protocol which
describes how the payment protocol works
with IOTP.
6.14. Protocol Amount Element
The Protocol Amount element links a Brand to:
the currencies and amounts in Currency Amount Elements (see
section 6.15) that can be used with the Brand, and
the Payment Protocols and Payment Handlers defined in a Pay
Surendra Reddy et al. [Page 118]
Internet Draft IOTP/1.0 September 21, 1998
Protocol Element (see section 6.16), which can be used with
those currencies and amounts.
Its definition is as follows:
<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
Id ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced
in a Brand element; or in a Brand Selection
Component contained in a later Payment
Request message which uniquely identifies
the Protocol Amount element within the IOTP
Transaction.
PayProtocolRef Contains an Element Reference (see section
3.7) that refers to the Pay Protocol
Element (see section 6.16) that contains
the Payment Protocol and Payment Handlers
that can be used with the Brand.
CurrencyamountRefs Contains a list of Element References (see
section 3.7) that refer to the Currency
Amount Element (see section 6.15) that
describes the currencies and amounts that
can be used with the Brand.
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
Surendra Reddy et al. [Page 119]
Internet Draft IOTP/1.0 September 21, 1998
It is recommended that this attribute is
included if the software which generated
the content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Optional Packaged Content (see section 3.8)
containing information about the protocol
amount which may be used by the payment
protocol. The content of this information is
defined in the supplement for a payment
protocol which describes how the payment
protocol works with IOTP.
6.15. Currency Amount Element
A Currency Amount element contains:
- a currency code (and its type), and
- an amount.
- One or more of these elements is carried in each Brand List
Component.
Its definition is as follows:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
Id ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217'
CurrCode CDATA #REQUIRED >
Attributes:
Id Element identifier, potentially referenced
in a Brand element; or in a Brand Selection
Component contained in a later Payment
Request message which uniquely identifies
the Currency Amount Element within the IOTP
Transaction.
Amount Indicates the amount to be paid in whole and
fractional units of the currency. For
example $245.35 would be expressed "245.35".
Note that values smaller than the smallest
Surendra Reddy et al. [Page 120]
Internet Draft IOTP/1.0 September 21, 1998
denomination are allowed. For example one
tenth of a cent would be "0.001".
CurrCodeType Indicates the domain of the CurrCode. This
attribute is included so that the currency
code may support non-standard "currencies"
such as frequent flyer points, trading
stamps, etc. Its values may be:
ISO4217 indicates the currency code conforms
to [ISO 4217]
x-ddd:nnn a user defined currency code type
(see section 3.9.3 User Defined Codes).
CurrCode A code which identifies the currency to be
used in the payment. The domain of valid
currency codes is defined by CurrCodeType
Note that Amount, CurrCodeType and CurrCode have identical
meanings to the attributes of the same name on the Payment
Component (see section 6.21).
6.16. Pay Protocol Element
A Pay Protocol element specifies details of a Payment Protocol
and the Payment Handler that can be used with a Brand. One or
more of these elements is carried in each Brand List.
<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
Id ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced
in a Brand element; or in a Brand Selection
Component contained in a later Payment
Request message which uniquely identifies
the Pay Protocol element within the IOTP
Transaction.
Surendra Reddy et al. [Page 121]
Internet Draft IOTP/1.0 September 21, 1998
xml:lang Defines the language used by attributes and
content of this element. See section 3.10
Identifying Languages.
ProtocolId Consists of a protocol name and version. For
example "SETv1.0".
The value used for the ProtocolId is defined
in the payment supplement for the payment
method.
ProtocolName A narrative description of the payment
protocol and its version in the language
identified by xml:lang. For example "Secure
Electronic Transaction Version 1.0". Its
purpose is to help provide information on
the payment protocol being used if problems
arise.
ActionOrgRef An Element Reference (see section 3.7) to
the Organization Component for the Payment
Handler for the Payment Protocol.
PayReqNetLocn The Net Location indicating where an
unsecured Payment Request message should be
sent if this protocol choice is used.
The content of this attribute is dependent
on the Transport Mechanism (such must
conform to [RFC1738].
SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if
this protocol choice is used.
A secured payment involves the use of a
secure channel such as [SSL] in order to
communicate with the Payment Handler.
The content of this attribute must conform
to [RFC1738]. See also See section 3.11
Secure and Insecure Net Locations.
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
Surendra Reddy et al. [Page 122]
Internet Draft IOTP/1.0 September 21, 1998
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Optional Packaged Content information (see
section 3.8) about the protocol which is
used by the payment protocol. The content of
this information is defined in the
supplement for a payment protocol which
describes how the payment protocol works
with IOTP. An example of its use could be to
include a payment protocol message.
6.17. Brand Selection Component
A Brand Selection Component identifies the choice of payment
brand, payment protocol and the Payment Handler. This element is
used:
- in Payment Request messages within Baseline Purchase and
Baseline Value IOTP Transactions to identify the brand,
protocol and payment handler for a payment, or
- to, optionally, inform a merchant in a purchase of the
payment brand being used so that the offer and order details
can be amended accordingly.
In Baseline IOTP, the integrity of Brand Selection Components is
not guaranteed. However, modification of Brand Selection
Components can only cause denial of service if the payment
protocol itself is secure against message modification,
duplication, and swapping attacks.
The definition of a Brand Selection Component is as follows.
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
Surendra Reddy et al. [Page 123]
Internet Draft IOTP/1.0 September 21, 1998
BrandSelProtocolAmountInfo?, BrandSelCurrencyAmountInfo?)
>
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Brand Selection Component within the IOTP
Transaction.
BrandListRef The Element Reference (see section 3.7) of
the Brand List Component from which a Brand
is being selected
BrandRef The Element Reference of a Brand element
within the Brand List Component that is
being selected that is to be used in the
payment.
ProtocolAmountRef The Element Reference of a Protocol Amount
element within the Brand List Component
which is to be used when making the payment.
CurrencyAmountRef The Element Reference of a Currency Amount
element within the Brand List Component
which is to be used when making the payment.
Content:
BrandSelBrandInfo, This contains any additional data that
BrandSelProtocolAmount may be required by a particular payment
Info, brand or protocol. See sections 6.18,
BrandSelCurrencyAmount 6.19, and 6.20.
Info
The following rules apply:
- the BrandListRef MUST contain the ID of a Brand List
Component in the same IOTP Transaction
- every Brand List Component in the Trading Protocol Options
Block must be referenced by one and only one Brand Selection
Component
- the BrandRef must refer to the ID of a Brand contained
Surendra Reddy et al. [Page 124]
Internet Draft IOTP/1.0 September 21, 1998
within the Brand List Component referred to by BrandListRef
- the ProtocolAmountRef must refer to one of the Element IDs
listed in the ProtocolAmountRefs attribute of the Brand
element identified by BrandRef
- the CurrencyAmountRef must refer to one of the Element IDs
listed in the CurrencyAmountRefs attribute of the Protocol
Amount Element identified by ProtocolAmountRef.
6.18. Brand Selection Brand Info Element
The Brand Selection Brand Info Element contains any additional
data that may be required by a particular payment brand. See the
IOTP payment method supplement for a description of how and when
it used.
<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Packaged Content information (see section
3.8) that contains additional data that may
Surendra Reddy et al. [Page 125]
Internet Draft IOTP/1.0 September 21, 1998
be required by a particular payment brand.
See the payment method supplement for IOTP
for rules on how this is used.
6.19. Brand Selection Protocol Amount Info Element
The Brand Selection Protocol Amount Info Element contains any
additional data that is payment protocol specific that may be
required by a particular payment brand or payment protocol. See
the IOTP payment method supplement for a description of how and
when it used.
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 6.18 Brand Selection Brand Info
Element.
Content:
PackagedContent Packaged Content information (see section
3.8) that contains any additional data that
may be required by a particular payment
brand. See the payment method supplement for
IOTP for rules on how this is used.
6.20. Brand Selection Currency Amount Info Element
The Brand Selection Currency Amount Info Element contains any
additional data that is payment brand and currency specific that
may be required by a particular payment brand. See the IOTP
payment method supplement for a description of how and when it
used.
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 6.18 Brand Selection Brand Info
Surendra Reddy et al. [Page 126]
Internet Draft IOTP/1.0 September 21, 1998
Element.
Content:
PackagedContent Packaged Content information (see section
3.8) that contains any additional data
relating to the payment brand and currency.
See the payment method supplement for IOTP
for rules on how this is used.
6.21. Payment Component
A Payment Component contains information used to control how a
payment is carried out. Its provides information on:
- the times within which a Payment with a Payment Handler may
be started
- a reference to the Brand List (see section 6.12) which
identifies the Brands, protocols, currencies and amounts
which can be used to make a payment
- whether or not an authentication of the consumer is required
as part of the payment
- whether or not a payment receipt will be provided
- whether another payment precedes this payment.
Its definition is as follows.
<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt ('True'|'False') #REQUIRED
AuthDataRef NMTOKEN #IMPLIED
StartAfter NMTOKENS #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Component within the IOTP
Transaction.
OkFrom The date and time in [UTC] format after
which a Payment Handler may accept for
processing a Payment Request Block (see
section 5.6) containing the Payment
Surendra Reddy et al. [Page 127]
Internet Draft IOTP/1.0 September 21, 1998
Component.
OkTo The date and time in [UTC] format before
which a Payment Handler may for processing
accept a Payment Request Block containing
the Payment Component.
BrandListRef An Element Reference (see section 3.7) of a
Brand List Component (see section 6.12)
within the TPO Trading Block for the IOTP
Transaction. The Brand List identifies the
alternative ways in which the payment can be
made.
AuthDataRef An element reference (see section 3.6) of an
Authentication Data Component (see section
6.2) which is to be used for authentication
of the Trading Role which sends the Payment
Request Block containing the Payment
Component to the Payment Handler. If not
present, then no authentication is to take
place.
SignedPayReceipt Indicates whether or not the Payment
Response Block (5.8) generated by the
payment handler for the payment must be
digitally signed.
StartAfter Contains Element References (see section
3.7) of other Payment Components which
describe payments which must be complete
before this payment can start. If no
StartAfter attribute is present then there
are no dependencies and the payment can
start immediately
Contents
PackagedContent This optional element contains "user" data
defined by the Merchant which is required by
the Payment Handler. See section 3.8
Packaged Content Element.
6.22. Payment Scheme Component
A Payment Scheme Component contains payment protocol information
for a specific payment scheme which is transferred between the
Surendra Reddy et al. [Page 128]
Internet Draft IOTP/1.0 September 21, 1998
parties involved in a payment for example a [SET] message. Its
definition is as follows.
<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies
the Payment Scheme Component within the
IOTP Transaction.
ConsumerPaymentId An identifier specified by the Consumer
which, if returned by the Payment Handler
in another Payment Scheme Component or by
other means, will enable the Consumer to
identify which payment is being referred
to.
PaymentHandlerPayId An identifier specified by the Payment
Handler which, if returned by the Consumer
in another Payment Scheme Component, or by
other means, will enable the Payment
Handler to identify which payment is being
referred to. It is required on every
Payment Scheme Component apart from the
one contained in a Payment Request Block.
ContentSoftwareId This contains information which identifies
the software which generated the content
of the element. Its purpose is to help
resolve interoperability problems that
might occur as a result of
incompatibilities between messages
produced by different software. It is a
single text string in the language defined
by xml:lang. It must contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
Surendra Reddy et al. [Page 129]
Internet Draft IOTP/1.0 September 21, 1998
It is recommended that this attribute is
included if the software which generated
the content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Contains the payment scheme protocol
information as Packaged Content (see
section 3.8). See the payment scheme
supplement for the definition of its
content.
6.23. Payment Receipt Component
A Payment Receipt Component contains payment scheme specific data
which can be used after the payment has completed to verify the
payment occurred. Its definition is as follows.
<!ELEMENT PayReceipt (PackagedContent) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
PaymentRef Contains an Element Reference (see section
3.7) to the Payment Component (see section
6.21) to which this payment receipt applies
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
Surendra Reddy et al. [Page 130]
Internet Draft IOTP/1.0 September 21, 1998
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Contains the payment scheme specific record
of the payment which can be used for receipt
purposes as Packaged Content (see section
3.8). Each payment scheme defines in its
supplement the structure of the content.
6.24. Delivery Component
The Delivery Element contains information required to deliver
goods or services. Its definition is as follows.
<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True|False) #REQUIRED
DelivAndPayResp (True|False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED
ConsumerDeliveryId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
DelivExch Indicates if this IOTP Transaction includes
the messages associated with a Delivery
Surendra Reddy et al. [Page 131]
Internet Draft IOTP/1.0 September 21, 1998
Exchange. Valid values are:
True indicates it does include a Delivery
Exchange
False indicates it does not include a
Delivery Exchange
If set to true then a DeliveryData element
must be present. If set to false it may be
absent.
DelivAndPayResp Indicates if the Delivery Response Block
(see section 5.10) and the Payment Response
Block (see section 5.8 ) are combined into
one IOTP Message. Valid values are:
True indicates both blocks will be in the
same IOTP Message, and
False indicates each block will be in a
different IOTP Message
DelivAndPayResp should not be true if
DelivExch is False.
In practice combining the Delivery Response
Block and Payment Response Block is only
likely to be practical if the Merchant, the
Payment Handler and the Delivery Handler are
the same Organization since:
the Payment Handler must have access to
Order Component information so that they
know what to deliver, and
the Payment Handler must be able to carry
out the delivery
ActionOrgRef An Element Reference to the Organization
Component of the Delivery Handler for this
delivery.
ConsumerDeliveryI An identifier specified by the Consumer
d which, if returned by the Delivery Handler
in another Delivery Component, or by other
means, will enable the Consumer to identify
which Delivery is being referred to.
Content:
Surendra Reddy et al. [Page 132]
Internet Draft IOTP/1.0 September 21, 1998
DeliveryData Contains details about how the delivery will
be carried out. See 6.25 Delivery Data
Element below.
PackagedContent This optional element contains "user" data
defined for the Merchant which is required
by the Delivery Handler. See section 3.8
Packaged Content Element.
6.25. Delivery Data Element
The DeliveryData element contains information about where and how
goods are to be delivered. Its definition is as follows.
<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes
within this component. See section 3.10
Identifying Languages.
OkFrom The date and time in [UTC] format after
which the Delivery Handler may accept for
processing a Delivery Request Block (see
section 5.9).
OkTo The date and time in [UTC] format before
which the Delivery Handler may accept for
processing a Delivery Request Block.
DelivMethod Indicates the method by which goods or
services may be delivered. Valid values
are:
Post the goods will be delivered by post or
courier
Web the goods will be delivered electronically
Surendra Reddy et al. [Page 133]
Internet Draft IOTP/1.0 September 21, 1998
in the Delivery Note Component
Email the goods will be delivered
electronically by e-mail
x-ddd:nnn a user defined delivery method
see 3.9.3 User Defined Codes.
DelivToRef The Element Reference (see section 3.6) of
an Organization Component within the IOTP
Transaction which has a role of DelivTo.
The information in this block is used to
determine where delivery is to be made. It
must be compatible with DelivMethod.
Specifically if the DelivMethod is:
Post, then the there must be a Postal
Address Element containing sufficient
information for a postal delivery,
Web, then there are no specific
requirements. The information will be sent
in a web page back to the Consumer
Email, then there must be Contact
Information Element with a valid e-mail
address
DelivReqNetLocn This contains the Net Location to which an
unsecured Delivery Request Block (see
section 5.9) which contains the Delivery
Component should be sent.
The content of this attribute is dependent
on the Transport Mechanism must conform to
[RFC1738].
SecDelivReqNetLocn This contains the Net Location to which a
secured Delivery Request Block (see section
5.9) which contains the Delivery Component
should be sent.
A secured delivery request involves the use
of a secure channel such as [SSL] in order
to communicate with the Payment Handler.
The content of this attribute is dependent
on the Transport Mechanism must conform to
[RFC1738].
See also Section 3.11 Secure and Insecure
Net Locations.
Surendra Reddy et al. [Page 134]
Internet Draft IOTP/1.0 September 21, 1998
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
the name of the software manufacturer
the name of the software
the version of the software, and
the build of the software
It is recommended that this attribute is
included if the software which generated
the content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
PackagedContent Optional additional information about the
delivery as Packaged Content (see section
3.8). provided to the Delivery Handler by
the merchant.
6.26. Delivery Note Component
A Delivery Note contains delivery instructions about the delivery
of goods or services or potentially the actual Delivery
Information itself. It is information which the person or
Organization receiving the Delivery Note can use when delivery
occurs.
<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Note Component within the IOTP
Surendra Reddy et al. [Page 135]
Internet Draft IOTP/1.0 September 21, 1998
Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
DelivHandlerDeliv An optional identifier specified by the
Id Delivery Handler which, if returned by the
Consumer in another Delivery Component, or
by other means, will enable the Delivery
Handler to identify which Delivery is being
referred to. It is required on every
Delivery Component apart from the one
contained in a Delivery Request Block.
An example use of this attribute is to
contain a delivery tracking number.
ContentSoftwareId This contains information which identifies
the software which generated the content of
the element. Its purpose is to help resolve
interoperability problems that might occur
as a result of incompatibilities between
messages produced by different software. It
is a single text string in the language
defined by xml:lang. It MUST contain, as a
minimum:
- the name of the software manufacturer
- the name of the software
- the version of the software, and
- the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the
SoftwareId attribute on the Message Id
Component (see section 3.5.2)
Content:
DeliveryNote Contains the actual delivery note
information as Packaged Content (see section
3.8).
Note: If the content of the Delivery Message is a Mime message
Surendra Reddy et al. [Page 136]
Internet Draft IOTP/1.0 September 21, 1998
then the Delivery Note may trigger an application which causes
the actual delivery to occur.
6.27. Payment Method Information Component
A Payment Method Information Component contains data which
describes the Payment Method which initiated the Payment
Instrument Customer Care Transaction and the software which
generated the message. Its definition is as follows.
<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
ID ID #REQUIRED
BrandId NMTOKEN #REQUIRED
PayProtocolId NMTOKEN #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Method Information Component within
the IOTP Transaction.
BrandId The Brand Identifier attribute copied from
the BrandId attribute of the Brand Element
(see section 6.13)of the Payment Instrument
which needs customer care.
PayProtocolId The ProtocolId attribute copied from the Pay
Protocol Element (see section 6.16) of the
Brand being used. This may not be required
for all types of Payment Instrument. See the
IOTP Supplement for the Payment Method to
determine if this is to be used.
6.28. Status Component
A Status Component contains status information about the business
success or failure (see section 7.2) of a process.
Its definition is as follows.
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType (Offer|Payment|Delivery) #REQUIRED
Surendra Reddy et al. [Page 137]
Internet Draft IOTP/1.0 September 21, 1998
ElRef NMTOKEN #REQUIRED
ProcessState(NotYetStarted|InProgress|
CompletedOk|Failed|ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Status Component within the IOTP Transaction.
xml:lang Defines the language used by attributes
within this component. See section 3.10
Identifying Languages.
StatusType Indicates the type of process which the
Status is reporting on. It may be set to
either Offer, Payment or Delivery.
ElRef Contains an Element Reference (see section
3.7) to the Component for which the Status
is being described. It must refer to either:
a Trading Protocol Options Block (see
section 5.1), if the StatusType is Offer,
a Payment Component (see section 6.21), if
the StatusType is Payment, or
a Delivery Component (see section 6.24), if
the StatusType is Delivery.
ProcessState Contains a State Code which indicates the
current state of the process being carried
out. Valid values for ProcessState are:
NotYetStarted. A Request Block has been
received but the process has not yet started
InProgress. Processing of the Request Block
has started but it is not yet complete
CompletedOk. The processing of the Request
Block has completed successfully without any
errors
Failed. The processing of the Request Block
has failed because of a business error (see
section 7.2)
ProcessError. This value is only used when
the Status Component is being used in
connection with an Inquiry Request Trading
Surendra Reddy et al. [Page 138]
Internet Draft IOTP/1.0 September 21, 1998
Block (see section 5.14). It indicates there
was a Technical Error (see section 7.1) in
the Request Block which is being processed
or some internal processing error.
Note that this code reports on the
processing of a Request Block. Further,
asynchronous processing may occur after the
Response Block associated with the Process
has been sent to the Consumer.
CompletionCode Indicates how the process completed. Valid
values for the CompletionCode are given
below together with the conditions when it
must be present.
A CompletionCode is a maximum of 14
characters long.
ProcessReference This optional attribute holds a reference
for the process whose status is being
reported. It may hold the following values:
when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the
Payment Scheme Data Component
when StatusType is set to Delivery, it
should contain the DelivHandlerDelivId from
the Delivery Note Component
This attribute should be absent in the
Inquiry Request message when the Consumer
has not been given such a reference number
by the IOTP Service Provider.
This attribute can be used in an Inquiry
Response Block (see section 5.15) to give
the Consumer the reference number for a
transaction which has previously been
unavailable.
For example, the package tracking number
might not be assigned at the time of a
delivery response was received. However, if
the Consumer issues a Baseline Transaction
Surendra Reddy et al. [Page 139]
Internet Draft IOTP/1.0 September 21, 1998
Status Inquiry later, the Delivery Handler
can put the package tracking number into
this attribute in the Inquiry Response
message and send it back to the Consumer.
StatusDesc An optional textual description of the
current status of the payment in the
language identified by xml:lang.
6.28.1. Offer Completion Codes
The Completion Code is only required if the ProcessState
attribute is set to Failed. The following table contains the
valid values for the CompletionCode that may be used. It is
recommended that the StatusDesc attribute is used to provide
further explanation where appropriate.
Value Description
========= =============================================
AuthError Authentication Error. The authentication
check which was carried out has failed.
OfferDecl Offer Declined. The Merchant declines to
generate an offer for some reason.
Unspecified Unspecified error. There is some unknown
problem or error which does not fall into
one of the other CompletionCodes.
6.28.2. Payment Completion Codes
The CompletionCode is only required if the ProcessState attribute
is set to Failed. The following table contains the valid values
for the CompletionCode that may be used. It is recommended that
the StatusDesc attribute is used by individual payment schemes to
provide further explanation where appropriate.
Value Description
========= =============================================
BrandNotSupp Brand not supported. The payment brand is
not supported by the Payment Handler.
CurrNotSupp Currency not supported. The currency in
which the payment is to be made is not
Surendra Reddy et al. [Page 140]
Internet Draft IOTP/1.0 September 21, 1998
supported by either the Payment Instrument
or the Payment Handler.
AuthError Authentication Error. The Payment Scheme
specific authentication check which was
carried out has failed.
InsuffFunds Insufficient funds. There are insufficient
funds available for the payment to be made.
InstBrandInvalid Payment Instrument not valid for Brand. A
Payment Instrument is being used which does
not correspond with the Brand selected. For
example a Visa credit card is being used
when MasterCard was selected as the Brand.
PaymntDecl Payment declined. The Payment Handler
declines to accept the payment for some
reason.
InstNotValid Payment instrument not valid for trade. The
Payment Instrument cannot be used for the
proposed type of trade, for some reason.
BadInstrumenat Bad instrument. There is a problem with the
Payment Instrument being used which means
that it is unable to be used for the
payment.
Unspecified Unspecified error. There is some unknown
problem or error which does not fall into
one of the other CompletionCodes. The
StatusDesc attribute should provide the
explanation of the cause.
6.28.3. Delivery Completion Codes
The following table contains the valid values for the
CompletionCode attribute for a Delivery. It is recommended that
the StatusDesc attribute is used to provide further explanation
where appropriate.
Value Description
========= =============================================
BackOrdered Back Ordered. The goods to be delivered are
on order but they have not yet been
Surendra Reddy et al. [Page 141]
Internet Draft IOTP/1.0 September 21, 1998
received. Shipping will be arranged when
they are received. This is only valid if
ProcessState is CompletedOk.
PermNotAvail Permanently Not Available. The goods are
permanently unavailable and cannot be re-
ordered. This is only valid if ProcessState
is Failed.
TempNotAvail Temporarily Not Available. The goods are
temporarily unavailable and may become
available if they can be ordered. This is
only valid if ProcessState is CompletedOk.
ShipPending Shipping Pending. The goods are available
and are scheduled for shipping but they have
not yet been shipped. This is only valid if
ProcessState is CompletedOk.
Shipped Goods Shipped. The goods have been shipped.
Confirmation of delivery is awaited. This is
only valid if ProcessState is CompletedOk.
ShippedNoConf Shipped - No Delivery Confirmation. The
goods have been shipped but it is not
possible to confirm delivery of the goods.
This is only valid if ProcessState is
CompletedOk.
Confirmed Confirmed. All goods have been delivered and
confirmation of their delivery has been
received. This is only valid if ProcessState
is CompletedOk.
6.29. Inquiry Type Component
The Inquiry Component contains the information which indicates
what type of process is being inquired upon.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type (Offer|Payment|Delivery) #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
Attributes:
Surendra Reddy et al. [Page 142]
Internet Draft IOTP/1.0 September 21, 1998
ID An identifier which uniquely identifies the
Inquiry Type Component within the IOTP
Transaction.
Type Contains the type of inquiry. Valid values
for Type are:
Offer. The inquiry is about the status of an
offer and is addressed to the Merchant.
Payment. The inquiry is about the status of
a payment and is addressed to the Payment
Handler.
Delivery. The inquiry is about the status of
a delivery and addressed to the Delivery
Handler.
ElRef Contains an Element Reference (see section
3.7) to the component to which this Inquiry
Type Component applies. That is,
TPO Block when Type is Offer
Payment Component when Type is Payment
Delivery Component when Type is Delivery
ProcessReference Optionally contains a reference to the
process being inquired upon. It should be
set if the information is available. For the
definition of the values it may contain, see
the ProcessReference attribute of the Status
Component (see section 6.28).
6.30. Signature Component
Each Signature Component digitally signs one or more Blocks or
Components including other Signature Components.
For a general explanation of signatures see section 9 Security
Considerations. Detailed definitions of the XML structures for
signatures is described in the paper "Digital Signature for XML -
Proposal", see [XMLSIG].
The Signature Component:
- hashes one or more Blocks or Components in one or more IOTP
Messages within the same IOTP Transaction
- concatenates these hashes into a Signed Data element, and
- signs the SignedData element using the optional certificate
identified in the CertRef attribute of the Digital Signature
Surendra Reddy et al. [Page 143]
Internet Draft IOTP/1.0 September 21, 1998
element.
Note that a Signed Data Element may be signed by more than one
Digital Signature element.
A Signature Component can be one of two types either:
- an Offer Response Signature, or
- a Payment Response Signature
How these signatures are constructed is described below
6.31. Offer Response Signature Component
The Signed Data Element of the Offer Response Signature Component
should contain hashes of the following Components:
- the Transaction Id Component (see section 3.5.1) of the IOTP
message that contains the Offer Response Signature
- the Transaction Reference Block (see section 3.5) of the IOTP
Message that contains the Offer Response Signature
- from the TPO Block:
o the Protocol Options Component
o each of the Organization Components
o each of the Brand List Components
- optionally, all the Brand Selection Components if they were
sent to the Merchant in a TPO Selection Block
- from the Offer Response Block:
o the Order Component
o each of the Payment Components
o the Delivery Component
- each of the Authentication Data Components
The Offer Response Signature Component should also contain
Digital Signature Elements for each of the Organizations that may
or will need to verify the signature. This involves:
- if the Merchant has received a TPO Selection Block
containing Brand Selection Components, then generate a
Digital Signature Element for the Payment Handler identified
Surendra Reddy et al. [Page 144]
Internet Draft IOTP/1.0 September 21, 1998
by the Brand Selection Component and the Delivery Handler
identified by the Delivery Component. See section 9.7 Check
the Action Request was sent to the Correct Organization for
a description of how this can be done.
- if the Merchant is not expecting to receive a TPO Selection
Block then generate a Digital Signature Element for the
Delivery Handler and all the Payment Handlers that are
involved.
6.32. Payment Receipt Signature Component
The Signed Data Element of the Payment Receipt Signature
Component should contain hashes of the following Components:
- the Transaction Id Component (see section 3.5.1) of the IOTP
message that contains the Payment Receipt Signature
- the Transaction Reference Block (see section 3.5) of the IOTP
Message that contains the Payment Receipt Signature
- the Offer Response Signature Component
- the Payment Receipt Component
- the Status Component
- the Brand Selection Component.
6.33. Ping Signature Components
If the Ping Response Transaction is generating a signature (see
section 4.8), the Signed Data Element of the Ping Response or
Ping Request Signature Components should contain hashes of the
following Components:
- all the Organization Components.
6.34. Error Component
The Error Component contains information about Technical Errors
(see section 7.1) in an IOTP Message which has been received by
one of the Trading Roles involved in the trade.
For clarity two phrases are defined which are used in the
description of an Error Component:
- message in error. An IOTP message which contains or causes an
error of some kind
- message reporting the error. An IOTP message that contains an
Error Component that describes the error found in a message
in error.
The definition of the Error Component is as follows.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
Surendra Reddy et al. [Page 145]
Internet Draft IOTP/1.0 September 21, 1998
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Error Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a
child element. See section 3.10 Identifying
Languages.
ErrorCode Contains an error code which indicates the
nature of the error in the message in error.
Valid values for the ErrorCode are given in
section 6.36 Error Codes.
ErrorDesc Contains a narrative description of the
error in the language defined by xml:lang.
The content of this attribute is defined by
the vendor/developer of the software which
generated the Error Component
Severity Indicates the severity of the error. Valid
values are:
Warning. This indicates that although there
is a message in error the IOTP Transaction
can still continue.
TransientError. This indicates that the
error in the message in error may be
recovered if the message in error that is
referred to by the ErrorLocation element is
resent
HardError. This indicates that there is an
unrecoverable error in the message in error
and the IOTP Transaction must stop.
MinRetrySecs This attribute should be present if Severity
is set to TransientError. It is the minimum
Surendra Reddy et al. [Page 146]
Internet Draft IOTP/1.0 September 21, 1998
number of whole seconds which the IOTP aware
application which received the message
reporting the error should wait before re-
sending the message in error identified by
the ErrorLocation element.
If Severity is not set to TransientError
then the value of this attribute is ignored.
SwVendorErrorRef This attribute is a reference whose value is
set by the vendor/developer of the software
which generated the Error Component. It
should contain data which enables the vendor
to identify the precise location in their
software and the set of circumstances which
caused the software to generate a message
reporting the error. See also the SoftwareId
attribute of the Message Id element in the
Transaction Reference Block (section 3.5).
Content:
ErrorLocation This identifies the IOTP Transaction Id of
the message in error and, where possible,
the element and attribute in the message in
error that caused the Error Component to be
generated.
If the Severity of the error is not
TransientError, more than one ErrorLocation
may be specified as appropriate depending on
the nature of the error (see section 6.36
Error Codes) and at the discretion of the
vendor/developer of the IOTP Aware
Application.
PackagedContent This contains additional data which can be
used to understand the error. Its content
may vary as appropriate depending on the
nature of the error (see section 6.36 Error
Codes) and at the discretion of the
vendor/developer of the IOTP Aware
Application. For a definition of
PackagedContent see section 3.8.
Surendra Reddy et al. [Page 147]
Internet Draft IOTP/1.0 September 21, 1998
6.35. Error Processing Guidelines
If there is more than one Error Component in a message reporting
the error, carry out the actions appropriate for the Error
Component with the highest severity. In this context, HardError
has a higher severity than TransientError, which has a higher
severity than Warning.
6.35.1. Severity - Warning
If an IOTP aware application is generating a message reporting the
error with an Error Component where the Severity attribute is set
to Warning, then if the message reporting the error does not
contain another Error Component with a severity higher than
Warning, the IOTP Message must also include the Trading Blocks and
Trading Components that would have been included if no error was
being reported.
If a message reporting the error is received with an Error
Component where Severity is set to Warning, then:
it is recommended that information about the error is either
logged, or otherwise reported to the user,
the implementer of the IOTP aware application must either, at
their or the user's discretion:
- continue the IOTP transaction as normal, or
- fail the IOTP transaction by generating a message reporting
the error with an Error Component with Severity set to
HardError (see section 6.35.3).
If the intention is to continue the IOTP transaction then, if
there are no other Error Components with a higher severity, check
that the necessary Trading Blocks and Trading Components for
normal processing of the transaction to continue are present. If
they are not then generate a message reporting the error with an
Error Component with Severity set to HardError.
6.35.2. Severity - Transient Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute is set
to TransientError, then there should be only one Error Component
in the message reporting the error. In addition, the MinRetrySecs
attribute should be present.
If a message reporting the error is received with an Error
Component where Severity is set to TransientError then:
Surendra Reddy et al. [Page 148]
Internet Draft IOTP/1.0 September 21, 1998
if the MinRetrySecs attribute is present and a valid number,
then use the MinRetrySecs value given. Otherwise if
MinRetrySecs is missing or is invalid, then:
- generate a message reporting the error containing an Error
Component with a Severity of Warning and send it on the next
IOTP message (if any) to be sent to the Trading Role which
sent the message reporting the error with the invalid
MinRetrySecs, and
- use a value for MinRetrySecs which is set by the
vendor/developer of the IOTP Aware Application.
check that only one ErrorLocation element is contained
within the Error Component and that it refers to an IOTP
Message which was sent by the recipient of the Error
Component with a Severity of TransientError. If more than
one ErrorLocation is present then generate a message
reporting the error with a Severity of HardError.
6.35.3. Severity - Hard Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute set to
HardError, then there should be only one Error Component in the
message reporting the error.
If a message reporting the error is received with an Error
Component where Severity is set to HardError then terminate the
IOTP Transaction.
6.36. Error Codes
The following table contains the valid values for the ErrorCode
attribute of the Error Component. The first sentence of the
description contains the text that should be used to describe the
error when displayed or otherwise reported. Individual
implementations may translate this into alternative languages at
their discretion.
An Error Code must not be more that 14 characters long.
Value Description
========= =============================================
Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact
the vendor/developer of the software for
more information See the SoftwareId
Surendra Reddy et al. [Page 149]
Internet Draft IOTP/1.0 September 21, 1998
attribute of the Message Id element in the
Transaction Reference Block(section 3.5).
XmlNotWellFrmd XML not well formed. The XML document is not
well formed. See [XML] for the meaning of
"well formed". Even if the XML is not well
formed, it should still be scanned to find
the Transaction Reference Block so that a
properly formed Error Response may be
generated.
XmlNotValid XML not valid. The XML document is well
formed but the document is not valid. See
[XML] for the meaning of "valid".
Specifically:
the XML document does not comply with the
constraints defined in the IOTP document type
declaration (see section Error! Reference
source not found. Error! Reference source
not found.), and
the XML document does not comply with the
constraints defined in the document type
declaration of any additional [XML
Namespace] that are declared.
As for XML not well formed, attempts should
still be made to extract the Transaction
Reference Block so that a properly formed
Error Response may be generated.
ElUnexpected Unexpected element. Although the XML
document is well formed and valid, an
element is present that is not expected in
the particular context according to the
rules and constraints contained in this
specification.
ElNotSupp Element not supported. Although the document
is well formed and valid, an element is
present that:
is consistent with the rules and constraints
contained in this specification, but
is not supported by the IOTP Aware
Application which is processing the IOTP
Message.
Surendra Reddy et al. [Page 150]
Internet Draft IOTP/1.0 September 21, 1998
ElMissing Element missing. Although the document is
well formed and valid, an element is missing
that should have been present if the rules
and constraints contained in this
specification are followed.
In this case set the PackagedContent of the
Error Component to the type of the missing
element.
ElContIllegal Element content illegal. Although the
document is well formed and valid, the
element PackagedContent contains values
which do not conform to the rules and
constraints contained in this specification.
EncapProtErr Encapsulated protocol error. Although the
document is well formed and valid, the
PackagedContent of an element contains data
from an encapsulated protocol which contains
errors.
AttUnexpected Unexpected attribute. Although the XML
document is well formed and valid, the
presence of the attribute is not expected in
the particular context according to the
rules and constraints contained in this
specification.
AttNotSupp Attribute not supported. Although the XML
document is well formed and valid, and the
presence of the attribute in an element is
consistent with the rules and constraints
contained in this specification, it is not
supported by the IOTP Aware Application which
is processing the IOTP Message.
AttMissing Attribute missing. Although the document is
well formed and valid, an attribute is
missing that should have been present if the
rules and constraints contained in this
specification are followed.
In this case set the PackagedContent of the
Error Component to the type of the missing
attribute.
AttValIllegal Attribute value illegal. The attribute
contains a value which does not conform to
Surendra Reddy et al. [Page 151]
Internet Draft IOTP/1.0 September 21, 1998
the rules and constraints contained in this
specification.
AttValNotRecog Attribute Value Not Recognised. The
attribute contains a value which the IOTP
Aware Application generating the message
reporting the error could not recognise even
though it should have been able to since the
information had been provided in an earlier
IOTP message.
MsgTooLarge Message too large. The message is too large
to be processed by the IOTP Aware
Application.
ElTooLarge Element too large. The element is too large
to be processed by the IOTP Aware Application
ValueTooSmall Value too small or early. The value of all
or part of the PackagedContent of an
element or an attribute, although valid, is
too small.
ValueTooLarge Value too large or in the future. The value
of all or part of the PackagedContent of an
element or an attribute, although valid, is
too large.
ElInconsistent Element Inconsistent. Although the document
is well formed and valid, according to the
rules and constraints contained in this
specification:
the content of an element is inconsistent
with the content of other elements or their
attributes, or
the value of an attribute is inconsistent
with the value of one or more other
attributes.
In this case create ErrorLocation elements
which identify all the attributes or
elements which are inconsistent.
TransportError Transport Error. This error code is used to
indicate that there is a problem with the
Transport Mechanism which is preventing the
message from being received. It is typically
Surendra Reddy et al. [Page 152]
Internet Draft IOTP/1.0 September 21, 1998
associated with a Transient Error.
Explanation of the Transport Error is
contained within the ErrorDesc attribute.
The values which can be used inside
ErrorDesc with a TransportError is specified
in the IOTP supplement for the Transport
mechanism.
6.37. Error Location Element
An Error Location Element identifies an element and optionally an
attribute in the message in error which is associated with the
error. It contains a reference to the IOTP Message, Trading Block,
Trading Component, element and attribute, which is in error.
<!ELEMENT ErrorLocation EMPTY>
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
OtpMsgRef NMTOKEN #REQUIRED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
Attributes:
ElementType This is the "type" (see [XML]) of the
Element in the message in error where the
error is located.
OtpMsgRef This is the value of the ID attribute of the
of the Message Id Component (see section
3.5.2) of the message in error to which this
Error Component applies.
BlkRef If the error is associated with a specific
Trading Block, then this is the value of the
ID attribute of the Trading Block where the
error is located.
CompRef If the error is associated with a specific
Trading Component, then this is the value of
the ID attribute of the Trading Component
where the error is located.
ElementRef If the error is associated with a specific
element within a Trading Component then, if
Surendra Reddy et al. [Page 153]
Internet Draft IOTP/1.0 September 21, 1998
the element has an attribute with an
"attribute type" (see [XML]) of "ID", then
this is the value of that attribute.
AttName If the error is associated with the value of
an attribute, then this is the name of that
attribute. In this case the PackagedContent
of the Error Component should contain the
value of the attribute.
Note that as many as the attributes as possible should be
included. For example if an attribute in a child element of a
Trading Component contains an incorrect value, then all the
attributes of ErrorLocation should be present.
7. IOTP Error Handling
IOTP is designed as a request/response protocol where each message
is composed of a number of Trading Blocks which contain a number
of Trading Components. There are a several interrelated
considerations in handling errors, re-transmissions, duplicates,
and the like. These factors mean IOTP aware applications must
manage message flows more complex than the simple
request/response model. Also a wide variety of errors can occur
in messages as well as at the transport level or in Trading
Blocks or Components.
This section describes at a high level how IOTP handles errors,
retries and idempotency. It covers:
- the different types of errors which can occur. This is
divided into:
o "technical errors" which are independent of the meaning
of the IOTP Message,
o "business errors" which indicate that there is a problem
specific to the process (payment or delivery) which is
being carried out, and
- the depth of the error which indicates whether the error is
at the transport, message or block/component level
- how the different trading roles should handle the different
types of messages which they may receive.
Surendra Reddy et al. [Page 154]
Internet Draft IOTP/1.0 September 21, 1998
7.1. Technical Errors
Technical errors are those which are independent of the meaning
of the message. This means, they can affect any attempt at IOTP
communication. Typically they are handled in a standard fashion
with a limited number of standard options for the user.
Specifically these are:
- retrying the transmission, or
- cancelling the transaction.
When communications are operating sufficiently well, a technical
error is indicated by an Error Component in an Error Block (see
section 5.23) sent by the party which detected the error in an
IOTP message to the party which sent the erroneous message.
If communications too poor, a message which was sent may not
reach its destination. In this case a time-out might occur.
The Error codes associated with Technical Errors are recorded in
Error Components which lists all the different technical errors
which can be set.
7.2. Business Errors
Business errors may occur when the IOTP messages are "technically"
correct. They are connected with a particular process, for
example, an offer, payment, or delivery, where each process has a
different set of possible business errors.
For example, "Insufficient funds" is a reasonable payment error
but makes no sense for a delivery while "Back ordered" is a
reasonable delivery error but not meaningful for a payment.
Business errors are indicated in the Status Component (see
section 6.28) of a "response block" of the normal type, for
example a Payment Response Block or a Delivery Response Block.
This allows whatever additional response related information is
needed to accompany the error indication.
Business errors must usually be presented to the user so that
they can decide what to do next. For example, if the error is
insufficient funds in a Brand Independent Purchase (see section
Error! Reference source not found.), the user might wish to
choose a different payment instrument/account of the same brand
or a different brand or payment system. Alternatively, if the IOTP
based implementation allows it and it makes sense for that
instrument, the user might want to put more funds into the
instrument/account and try again.
Surendra Reddy et al. [Page 155]
Internet Draft IOTP/1.0 September 21, 1998
7.3. Error Depth
The three levels at which IOTP errors can occur are the transport
level, the message level, and the block level. Each is described
below.
7.3.1. Transport Level
This level of error indicates a fundamental problem in the
transport mechanism over which the IOTP communication is taking
place.
All transport level errors are technical errors and are indicated
by either an explicit transport level error indication, such as a
"No route to destination" error from TCP/IP, or by a time out
where no response has been received to a request.
The only reasonable automatic action when faced with transport
level errors is to retry and, after some number of automatic
retries, to inform the user.
The explicit error indications that can be received are transport
dependent and the documentation for appropriate IOTP Transport
supplement should be consulted for errors and appropriate
actions.
Appropriate time outs to use are a function of both the transport
being used and of the payment system if the request encapsulates
payment information. The transport and payment system specific
documentation should be consulted for time out and automatic
retry parameters. Frequently there is no way to directly inform
the other party of transport level errors but they should
generally be logged and if automatic recovery is unsuccessful and
there is a human user, the user should be informed.
7.3.2. Message Level
This level of error indicates a fundamental technical problem
with an entire IOTP message. For example, the XML is not Well
formed, or the message is too large for the receiver to handle or
there are errors in the Transaction Reference Block (see section
3.5) so it is not possible to figure out what transaction the
message relates to.
All message level errors are technical errors and are indicated
by an Error Component sent to the other party. The Error Component
includes a Severity attribute which indicates whether the error
Surendra Reddy et al. [Page 156]
Internet Draft IOTP/1.0 September 21, 1998
is a Warning and may be ignored, a TransientError which indicates
that a retry may resolve the problem or a HardError in which case
the transaction must fail.
The Technical Errors (see section 6.36 Error Codes) that are
Message Level errors are:
- XML not well formed. The document is not well formed XML
(see [XML])
- XML not valid. The document is not valid XML (see [XML])
- block level technical errors (see section 7.3.3) on the
Transaction Reference Block (see section 3.5) and the
Signature Block only. This should only be carried out if the
XML is valid
Note that checks on the Signature Block includes checking, where
possible, that each Signature Component is correctly calculated.
If the Digital Signature Element is incorrectly calculated then
the data that should have been covered by the signature can not
be trusted and must be treated as erroneous. A description of how
to check a signature is correctly calculate is contained in
section 9.6.1 Checking a Signature is Correctly Calculated.
7.3.3. Block Level
A Block level error indicates a problem with a block or one of
its components in an IOTP message (apart from Transaction
Reference or Signature Blocks). The message has been transported
properly, the overall message structure and the
block/component(s) including the Transaction Reference and
Signature Blocks are meaningful but there is some error related
to one of the other blocks.
Block level errors can be either:
- technical errors, or
- business errors
Technical Errors are further divided into:
- Block Level Attribute and Element Checks, and
- Block and Component Consistency Checks
If a technical error occurs related to a block or component, then
an Error Component is returned and, unless it is merely a
warning, the usual response block is suppressed.
Surendra Reddy et al. [Page 157]
Internet Draft IOTP/1.0 September 21, 1998
7.3.4.
Block Level Attribute and Element Checks
Block Level Attribute and Element Checks occur only within the
same block. Checks which involve cross-checking against other
blocks are covered by Block and Component Consistency Checks.
The Block Level Attribute & Element checks are:
- checking that each attribute value within each element in a
block conforms to any rules contained within this IOTP
specification
- checking that the content of each element conforms to any
rules contained within this IOTP specification
- if the previous checks are OK, then cross-checking attribute
values and element content against other attribute values or
element content within any other components in the same
block.
7.3.5. Block and Component Consistency Checks
Block and Component Consistency Checks consist of:
- checking that the combination of blocks and/or components
present in the IOTP Message are consistent with the rules
contained within this IOTP specification
- checking for consistency between attributes and element
content within the blocks within the same IOTP message.
- checking for consistency between attributes and elements in
blocks in this IOTP message and blocks received in earlier
IOTP messages for the same IOTP transaction
7.3.6. Block Business Errors
If a business error occurs in a process such as a Payment or a
Delivery, then the usual type of response block is returned. The
Status Component (see section 6.28) within that response block
indicates the error and its severity. No Error Component or Error
Block is generated for business errors.
7.4. Idempotency, Processing Sequence, and Message Flow
IOTP messages are actually a combination of blocks and components
as described in 3.1 IOTP Message Structure. Especially in future
extensions of IOTP, a rich variety of combinations of such blocks
and components can occur. It is important that the multiple
transmission/receipt of the "same" request for state changing
Surendra Reddy et al. [Page 158]
Internet Draft IOTP/1.0 September 21, 1998
action not result in that action occurring more than once. This
is called idempotency. For example, a customer paying for an
order would want to pay the full amount only once. Most network
transport mechanisms have some probability of delivering a
message more than once or not at all, perhaps requiring
retransmission. On the other hand, a request for status can
reasonably be repeated and should be processed fresh each time it
is received.
Correct implementation of IOTP can be modelled by a particular
processing order as detailed below. Any other method that is
indistinguishable in the messages sent between the parties is
equally acceptable.
7.4.1. Server Role Processing Sequence
"Server roles" are any Trading Role which is not the Consumer
role. They are "Server roles" since they typically receive a
request which they must service and then produce a response.
7.4.2. Check for Transport or Message Level Error
On receipt of an IOTP request message, first check for transport or
message level errors (see sections 7.3.1 and 7.3.2). These are
errors which indicate that the entire message is corrupt and can
not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information
in the message can not be reliably accessed.
If the OtpTransId attribute in the Transaction Id Component (see
section 3.5.1) can be determined, set up a response message with
an appropriate Error Component. Perform local actions such as
making log entries.
If the value of the OtpTransId attribute is not recognised as
belonging to an IOTP transaction when other Blocks in the IOTP
Message indicate that it should be recognised, then report the
error using an Error Component with a Severity of HardError, an
ErrorCode set to AttValNotRecog (attribute value not recognised),
and an Error Location element (see section 6.37) that points to
the OtpTransId attribute.
No idempotency related actions are necessary.
Surendra Reddy et al. [Page 159]
Internet Draft IOTP/1.0 September 21, 1998
7.4.3. Process all the blocks
If there are no message level errors, process each of the blocks
within the message which has not been processed.
Once all the blocks have been processed, generate a response
message and send it to the requester unless there are fatal transport
level problems. As recommended for the particular transport used, a
limited number of automatic response retransmission attempts may be
appropriate.
It may be desirable to log the complete response message at the
server. Failure of the requester to receive a response may lead
to a time-out and a retransmission of the request. Following the
procedures above, a duplicate request message should produce a
duplicate of the previous response except for changes in status
and transient error conditions that have changed.
7.4.4. Check the Block is OK
Check the block is OK (see section 7.3.3). For each block level
error found, an appropriate Error Component should be created to
be included in the IOTP Message sent back to the Consumer. Note
that some checking of the Transaction Reference Block and the
Signature Block has occurred as part of Message Level error
checking.
If one or more of the Error Components contain a Severity
attribute with a value of TransientError or HardError, then no
response block need be generated and no further processing of the
block, including idempotency related actions are necessary.
7.4.5. Determine the Type of the Block
Trading Blocks that survive the above steps and thus have no
errors, or at worst have added a warning error component to the
response, can receive further processing. The nature of the
processing depends on whether the block is a Status Request,
Action Request, an Error Block or contains an Encapsulated
Message.
7.4.6. Status Request Blocks
Status Request Blocks are either:
Surendra Reddy et al. [Page 160]
Internet Draft IOTP/1.0 September 21, 1998
- Inquiry Request Trading Block (see section 5.14), or
- Ping Request Block (see section 5.16).
These status requests do not change state and are processed fresh
to get the current status. The appropriate response block should
be added to the IOTP message being composed.
No idempotency actions are required.
7.4.7. Action Request Blocks
Blocks which request an action and change state need to be
subject to idempotency duplicate filtering by checking to see if
the same block for the same transaction has been previously
stored at the server as described later.
If the Block has been received previously then:
if processing of the previously stored block is complete
then the same IOTP Block as previously produced must be included
for resending to the Consumer.
if processing is not complete, wait until the processing is
complete before sending the response. If the block has not been
received before, the action request is processed normally producing
a response block that is added to the response message. This might
or might not indicate a business error.
If there is a transient error indicated by an Error Component
that contains a Severity attribute set to TransientError, then
apart from sending the Error Block, no further actions should be
taken so the action can be retried.
If there is no Transient Error, then the transaction id, the
request block, and the response block must be stored so they can be
found as described above should a duplicate IOTP action request block
be received for this transaction in the future.
Note: Most business errors should be labeled as a TransientError
as there is usually some possibility they will be corrected over
time or some user action exists that can fix them. Requesters are
expected to understand business errors and the appropriate time
scale for user actions for retrying.
Surendra Reddy et al. [Page 161]
Internet Draft IOTP/1.0 September 21, 1998
7.4.8. Encapsulating Blocks
Blocks which encapsulate a payment protocol pass along the enclosed
information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is
thus up to the payment system involved to handle error detection
and idempotency. Payment systems adapted for the Internet include
idempotency handling because duplicates are always possible.
Should a payment system have no idempotency handling, a layer
between IOTP and the payment system must be added to take care of
this.
No IOTP level idempotency actions are required for encapsulating
blocks. The payment system must return material to be
encapsulated in the IOTP response message along with indications
as to whether the exchange will continue or this is the final
response and an indication whether an error occurred. If a
payment protocol error has occurred, an Error Component is added
to the response block.
7.4.9. Error Block Received
An error block should not occur in a request and should be treated
as an unexpected element with a Severity of HardError. No response
to the block should be made in order to avoid the risk of loops.
Note: Consumers should send Error Blocks to a server specified in
the ErrorNetLocn attribute of the appropriate Trading Role
element as a response to the detection of an error in an IOTP
Message that has been received (see section 7.4.10 Generate Error
Block). This may be the same server as is used to accept IOTP
Messages which contain no error. In this case, the error block
must not considered as a fatal error.
7.4.10. Generate Error Block
If any of the previous steps resulted in an error being detected
and an Error Component being created then generate an Error Block
containing the Error Components that describe the error(s).
Unless the error is a "Transient Error", the Error Component(s)
and the request block which caused the Error Components to be
generated should be stored so that it can be reused if the action
request is received again.
Surendra Reddy et al. [Page 162]
Internet Draft IOTP/1.0 September 21, 1998
"Transient Errors" are not stored so that if the original
Response Block is received again, then it can be processed as if
it had never been received before.
7.4.11. Add Block to Output Message
Any Blocks which have been created as a result of processing the
block received are added to the output message.
7.5. Client Role Processing Sequence
The "Client role" in IOTP is the Consumer Trading Role.
Note: A company or Organization that is a Merchant, for example,
may take on the Trading Role of a Consumer when making a purchase
or downloading or withdrawing electronic cash.
7.5.1. Check for Transport or Message Level Error
On receipt of an IOTP response message, first check for transport
or message level errors (see sections 7.3.1 and 7.3.2). These are
errors which indicate that the entire message is corrupt and can
not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information
in the message can not be reliably accessed. Set up an error
indication message with an Error Component indicating the error.
If the value of the OtpTransId attribute is not recognised as
belonging to an IOTP transaction when other Blocks in the IOTP
Message indicate that it should be recognised, then report the
error using an Error Component with a Severity of HardError, an
ErrorCode set to AttValNotRecog (attribute value not recognised),
and an Error Location element (see section 6.37) that points to
the OtpTransId attribute.
On failure to receive an expected response message, the time out
strategy indicated in the documentation for the transport method
being used should be followed. This may include some number of
automatic retransmissions of the request. If a user is present,
they may be offered options of continuing to retransmit the
request or of cancelling the transaction.
7.5.2. Process all the blocks
If there are no message level errors, process each of the blocks
within the message which has not been processed.
Surendra Reddy et al. [Page 163]
Internet Draft IOTP/1.0 September 21, 1998
Once all the blocks have been processed, check to see if there
are any blocks to be sent. There may be no blocks to send if the
last response message received was the last message of the transaction.
If blocks are to be sent then generate a request message and send it
to the server. It may be desirable to log the complete request message
at the client. Failure of the server to receive a response may lead to
a time-out and a retransmission of the request.
7.5.3. Check the Block is OK
If there are no message level errors process each of the blocks
within the message.
Check the block is OK (see section 7.3.3). For each block level
error found, an appropriate Error Component should be created to
be included in an Error Component sent back to the Server.
If one or more of the Error Components contain a Severity
attribute with a value of TransientError or HardError, no further
processing of the block should occur and it is likely that this
will result in termination of the transaction.
7.5.4. Determine the Type of the Block
Trading Blocks that survive the above steps and thus have no
errors, or at worst have added a warning error component to the
error indication message, can receive further processing. The
nature of the processing depends on whether the block is
a Status Response, Action Response, an Error Block or contains an
Encapsulated Message.
7.5.5. Status Response Blocks
Status Response Blocks are either:
- Inquiry Response Trading Blocks (see section 5.15), or
- Ping Response Blocks (see section 5.17)
In general, such blocks should be considered a status update. The
best action to take at the requester may depend on whether this
is in response to a user originated or automatic status request,
whether a status display that could be updated is being presented
to the user, and whether the status response block shows a change
in status from a previous response block for the same type of
Surendra Reddy et al. [Page 164]
Internet Draft IOTP/1.0 September 21, 1998
status. Thus client detection of duplication in successive status
response blocks may be useful.
7.5.6. Action Response Blocks
Check to determine if the Block has been received previously. If it
has then it should be ignored.
These indicate an action taken at the server in response to an
action request block or a business error. If the response
indicates success the block should be processed and, if required by
the transaction, another Action Request Block generated and stored.
The Response Block should always be stored with the transaction
id and until the transaction is terminated. If the Response Block
indicates a transient business error, appropriate manually chosen
or automatic steps to fix the problem or cancel the transaction
should be provided.
7.5.7. Encapsulating Blocks
Blocks which encapsulate a payment protocol pass along the enclosed
information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is
up to the payment system involved to handle error detection and
idempotency. Payment systems adapted for the Internet include
idempotency handling because duplicates are always possible.
Should a payment system have no idempotency handling, a layer
between IOTP and the payment system must be added to take care of
this.
No IOTP level idempotency actions are required for encapsulating
blocks. The payment system must return an indication of whether
an error occurred. In addition, for a continuing exchange, it
must return material to be encapsulated in the next IOTP
request/exchange. If the response was a final response for that
payment exchange and there was an error, the payment system may
optionally return material to be encapsulated in the error indication.
7.5.8. Error Block
An error block in a response indicates some problem was detected by
the server. If all of the error components are warnings, they may be
optionally logged and/or presented to the user.
Surendra Reddy et al. [Page 165]
Internet Draft IOTP/1.0 September 21, 1998
Transient errors may be used to provide a manual or automatic
resending of a block previously stored or alternatively may result in
transaction cancellation. Hard errors will always terminate the transaction,
unless they are in optional blocks, with appropriate indication to he user.
7.5.9. Generate Error Block
If an error indication message was created above, try to send it
to the server unless all of the error components are of the
warning severity in which case attempted transmission to the
server is optional.
Note: To avoid error message loops, such an error indication from
a requester must be sent to the Error Net Location specified in
the Trading Role Element (see section 6.8) for the Organization
that is the server. Any errors encountered in sending such an
error indication should be, at most, logged and must not result
in any further attempts to transmit any error indication.
7.5.10. Add Block to Output Message
Any Blocks which have been created as a result of processing the
block received are added to the output message.
8. Retrieving Logos
This section describes how to retrieve logos for display by IOTP
aware software using the Logo Net Locations attribute contained
in the Brand Element (see section 6.13) and the Organization
Component (see section 6.7).
The full address of a logo is defined as follows:
Logo_address ::= Logo_net_location "/" Logo_size
Logo_color_depth
".GIF"
Where:
Logo_net_location is obtained from the LogoNetLocn attribute
in the Brand Element (see section 6.13) or the Organization
Component. Note that:
- the content of this attribute is dependent on the Transport
Mechanism (such as HTTP) that is used. See the Transport
Mechanism supplement,
Surendra Reddy et al. [Page 166]
Internet Draft IOTP/1.0 September 21, 1998
- implementers should check that if the rightmost character of
Logo Net Location is set to right-slash "/" then another,
right slash should not be included when generating the Logo
Address,
Logo_size identifies the size of the logo,
Logo_color_depth identifies the colour depth of the logo
"GIF" indicates that the logos are in GIF format
Logo_size and Logo_color_depth are specified by the implementer
of the IOTP software that is retrieving the logo depending on the
size and colour that they want to use.
8.1. Logo Size
There are five standard sizes for logos. The sizes in pixels and
the corresponding values for Logo Size are given in the table
below.
Size in Logo Size
Pixels Value
32 x 32 or exsmall
32 x 20
53 x 33 small
103 x 65 medium
180 x 114 large
263 x 166 exlarge
8.2. Logo Color Depth
There are three standard colour depths. The colour depth
(including bits per pixel) and the corresponding value for
Logo_Color_Depth are given in the table below.
Color Depth Logo Color
(bits per pixel) Depth Value
4 (16 colors) 4
Surendra Reddy et al. [Page 167]
Internet Draft IOTP/1.0 September 21, 1998
8 (256 colors) nothing
24 (16 million colors) 24
Note that if Logo Color Depth is omitted then a logo with the
default colour depth of 256 colours will be retrieved.
8.3. Logo Net Location Examples
If Logo Net Location was set to "ftp://logos.xzpay.com", then:
"ftp://logos.xzpay.com/medium.gif" would retrieve a medium
size 256 colour logo
"ftp://logos.xzpay.com/small4.gif" would retrieve a small
size 16 colour logo
Note: Organizations which make logos available for use with IOTP
should always make available "small" and "medium" size logos and
use the GIF format.
9. Security Considerations
This section considers the security associated with IOTP. It
covers:
- an overview of how IOTP uses digital signatures
- how to check a signature is correctly calculated
- how Payment Handlers and Delivery Handlers check they can
carry out payments or deliveries on behalf of a Merchant.
- how IOTP handles data integrity and privacy
9.1. Digital Signatures and IOTP
In general, signatures when used with IOTP:
- are always treated as a IOTP Components (see section 5)
- hash one or more IOTP Components or Trading Blocks, possibly
including other Signature Components, in any IOTP message
within the same IOTP Transaction
identify:
- which Organization signed (generated) the signature, and
- which Organization(s) should verify the signature in order
to check that the Action the Organization should take can
occur.
Surendra Reddy et al. [Page 168]
Internet Draft IOTP/1.0 September 21, 1998
Note: The classic example of one signature signing another in
IOTP, is when an Offer is first signed by a Merchant creating an
"Offer Response" signature, which is then later signed by a
Payment Handler together with a record of the payment creating a
"Payment Receipt" signature. In this way, the payment in an IOTP
Transaction is bound to the Merchant's offer.
The detailed definitions of how signatures are created is
contained in the paper "Digital Signature for XML - Proposal",
see [XMLSIG]. That document should be read in conjunction with
this section.
The remainder of this section contains:
- an example of how IOTP uses signatures
- how the SignerOrgRef and VerifierOrgRef attributes within a
Signature Component are used to identify the Organizations
associated with the signature
- how signatures may use either Symmetric or Asymmetric
Cryptography
- Mandatory and Optional use of Signatures by IOTP, and
- how IOTP uses signatures to prove actions complete
successfully
9.2. IOTP Signature Example
An example of how signatures are used is illustrated in the
figure below which shows how the various components and elements
in a Baseline Purchase relate to one another. Refer to this
example in the later description of how signatures are used to
check a payment or delivery can occur (see section 9.6.2).
Note: A Baseline Purchase transaction has been used for
illustration purposes. The usage of the elements and attributes
is the same for all types of IOTP Transactions.
9.3. SignerOrgRef and VerifierOrgRef Attributes
The SignerOrgRef attribute on the Signature Component contains an
Element Reference (see section 3.7) that points to the
Organization Component of the Organization which generated the
Signature. In this example its the Merchant.
Note that the type of the Signature Component must match the
Trading Role of the Organization which signed it. If it does not,
then it is an error. Valid combinations are given in the table
below.
Surendra Reddy et al. [Page 169]
Internet Draft IOTP/1.0 September 21, 1998
Signature Valid
Component Trading
Type Role
OfferResponse Merchant
PaymentResponse PaymentHandler
The VerifierOrgRef attribute on the DigSig elements, contains
Element References to the Organization Components of the
Organizations that should use the signature to verify that:
they have a pre-existing relationship with the Organization
that generated the signature,
the data which is secured by the signature has not been
changed,
the data has been signed correctly, and
the action they are required to undertake on behalf of the
Merchant is therefore authorised.
9.4. Symmetric and Asymmetric Cryptography
The Signer of an Action and a Verifier of an Action may have
agreed to use cryptography which is understood only by the two
Organizations involved. This requires that a separate Digital
Signature Element for use by the verifier is contained within the
Signature Component. This approach is more likely if symmetric
cryptography is being used between the Trading Roles.
Equally the same cryptography may be understood by several or all
of the Trading Roles. In this case one Digital Signature Element
may refer to multiple Verifiers of an Action. This is more likely
if public key/asymmetric cryptography is being used.
Note that one transaction may involve use of both symmetric and
asymmetric cryptography.
9.5. Mandatory and Optional Signatures
IOTP does not mandate the use of signatures. For example, if a
micro payment is being made for 0.1 cents, then the cost of the
cryptography required to generate the signature may be greater
than the income generated from the payment. Therefore it is up to
the Merchant to decide whether IOTP Messages will include
Surendra Reddy et al. [Page 170]
Internet Draft IOTP/1.0 September 21, 1998
signatures, and for the Consumer to decide whether carrying out a
transaction without signatures is an acceptable risk. If
Merchants discover that transactions without signatures are not
being accepted, then they will start using signatures or accept a
lower volume and value of business.
Additional optional signatures, over and above the ones required
by the Trading Roles may be included, for example, to identify a
Customer Care Provider or so that a Merchant can sign an Offer
using a certificate issued by a Certificate Authority which
offers Merchant "Credentials" or some other warranty on the goods
or services being offered.
9.6. Using signatures to Prove Actions Complete Successfully
Proving an action completed successfully, is achieved by signing
data on Response messages. Specifically:
on the Offer Response, when a Merchant is making an Offer to
the Consumer which can then be sent to either:
- a Payment Handler to prove that payment is authorised, or
- a Delivery Handler to prove that Delivery is authorised
on the Payment Response, when a Payment Handler is
generating a Payment Receipt which can be sent to either:
- a Delivery Handler, in a Delivery Request Block to prove
that delivery is authorised, or
- another Payment Handler, in a second Payment Request, to
prove that the second payment in a Value Exchange IOTP
Transaction is authorised.
This proof of an action may, in future versions of IOTP, also be
used to prove after the event that the IOTP transaction occurred.
For example to a Customer Care Provider.
9.6.1. Checking a Signature is Correctly Calculated
Checking a signature is correctly calculated is part of checking
for Message Level Errors (see section 7.3.2). It is included here
so that all signature and security related considerations are
kept together.
Before a Trading Role can check a signature it must identify
which of the potentially multiple digital signature elements
should be checked. The steps involved are as follows:
check that a Signature Block is present and it contains one
or more Signature Components
Surendra Reddy et al. [Page 171]
Internet Draft IOTP/1.0 September 21, 1998
identify the Organization Component which contains an OrgId
attribute for the Organization which is carrying out the
signature check. If no or more than one Organization
Component is found then it is an error
use the ID attribute of the Organization Component to
identify the Digital Signatures Elements which the Trading
Role should verify. Note there may be no signatures for a
Trading Role to verify.
verify the Signature Components that contain the Digital
Signature Elements as follows:
- check that the Digital Signature Element correctly signs the
Signed Data Element
- check that the Hash Elements in the Signed Data Element are
correctly calculated where Components or Blocks that are
hashed have been received by the Organization checking the
signature
9.6.2. Checking a Payment or Delivery can occur
This section describes the processes required for a Payment
Handler or Delivery Handler to check that a payment or delivery
can occur. This may include checking signatures if this is
specified by the Merchant.
In outline the steps are:
- check that the Payment Request or Delivery Request has been
sent to the correct Organization
- check that correct IOTP components are present in the
request, and
- check that the payment or delivery is authorised
For clarity and brevity the following terms or phrases are used
in this section:
- a "Request Block" is used to refer to either a Payment
Request Block (see section 5.6) or a Delivery Request Block
(see section 5.9) unless specified to the contrary
- a "Response Block" is used to refer to either a Payment
Response Block (see section 5.8) or a Delivery Response
Block (see section 5.10)
- an "Action" is used to refer to an action which occurs on
receipt of a Request Block. Actions can be either a Payment
or a Delivery
Surendra Reddy et al. [Page 172]
Internet Draft IOTP/1.0 September 21, 1998
- an "Action Organization", is used to refer to the Payment
Handler or Delivery Handler that carries out an Action
- a "Signer of an Action", is used to refer to the
Organizations that sign data about an Action to authorise
the Action, either in whole or in part
- a "Verifier of an Action", is used to refer to the
Organizations that verify data to determine if they are
authorised to carry out the Action
- an ActionOrgRef attribute contains Element References which
can be used to identify the "Action Organization" that
should carry out an Action
9.7. Check the Action Request was sent to the Correct Organization
Checking the Action Request was sent to the correct Organization
varies depending on whether the Action is a Payment or a
Delivery.
9.7.1. Payment
In outline a Payment Handler checks if it can accept or make a
payment by identifying the Payment Component in the Payment
Request Block it has received, then using the ID of the Payment
Component to track through the Brand List and Brand Selection
Components to identify the Organization selected by the Consumer
and then checking that this Organization is itself.
The following describes the steps involved and the checks which
need to be made:
- Identify the Payment Component (see section 6.21) in the
Payment Request Block that was received.
- Identify the Brand List and Brand Selection Components for
the Payment Component. This involves:
- identifying the Brand List Component (see section 6.12)
where the value of its ID attribute matches the BrandListRef
attribute of the Payment Component. If no or more than one
Brand List Component is found there is an error.
- identifying the Brand Selection Component (see section 6.17)
where the value of its BrandListRef attribute matches the
BrandListRef of the Payment Component. If no or more than
one matching Brand Selection Component is found there is an
error.
- Identify the Brand, Protocol Amount, Pay Protocol and
Currency Amount elements within the Brand List that have
been selected by the Consumer as follows:
Surendra Reddy et al. [Page 173]
Internet Draft IOTP/1.0 September 21, 1998
o the Brand Element selected is the element where the value
of its Id attribute matches the value of the BrandRef
attribute in the Brand Selection. If no or more than one
matching Brand Element is found then there is an error.
o the Protocol Amount Element selected is the element where
the value of its Id attribute matches the value of the
ProtocolAmountRef attribute in the Brand Selection Component.
If no or more than one matching Protocol Amount Element is
found there is an error
o the Pay Protocol Element (see section 6.16) selected is
the element where the value of its Id attribute matches
the value of the PayProtocolRef attribute in the
identified Protocol Amount Element. If no or more than
one matching Pay Protocol Element is found there is an
error
o the Currency Amount Element (see section 6.15) selected
is the element where the value of its Id attribute
matches the value of the CurrencyAmountRef attribute in
the Brand Selection Component. If no or more than one
matching Currency Amount element is found there is an
error
- Check the consistency of the references in the Brand List
and Brand Selection Components:
- check that an Element Reference exists in the
ProtocolAmountRefs attribute of the identified Brand Element
that matches the Id attribute of the identified Protocol
Amount Element. If no or more than one matching Element
Reference can be found there is an error
- check that the CurrencyAmountRefs attribute of the
identified Protocol Amount element contains an element
reference that matches the Id attribute of the identified
Currency Amount element. If no or more than one matching
Element Reference is found there is an error.
- check the consistency of the elements in the Brand List.
Specifically, the selected Brand, Protocol Amount, Pay
Protocol and Currency Amount Elements are all child elements
of the identified Brand List Component. If they are not
there is an error.
- Check that the Payment Handler that received the Payment
Request Block is the Payment Handler selected by the
Consumer. This involves:
o identifying the Organization Component for the Payment
Handler. This is the Organization Component where its ID
Surendra Reddy et al. [Page 174]
Internet Draft IOTP/1.0 September 21, 1998
attribute matches the ActionOrgRef attribute in the
identified Pay Protocol Element. If no or more than one
matching Organization Component is found there is an
error
o checking the Organization Component has a Trading Role
Element with a Role attribute of PaymentHandler. If not
there is an error
o finally, if the identified Organization Component is not
the same as the Organization that received the Payment
Request Block, then there is an error.
9.7.2. Delivery
The steps involved are as follows:
- Identify the Delivery Component in the Delivery Request
Block. If there is no or more than one matching Delivery
Component there is an error
- Use the ActionOrgRef attribute of the Delivery Component to
identify the Organization Component of the Delivery Handler.
If there is no or more than one matching Organization
Component there is an error
- If the Organization Component for the Delivery Handler does
not have a Trading Role Element with a Role attribute of
DeliveryHandler there is an error
- Finally, if the Organization that received the Delivery
Request Block does not identify the Organization Component
for the Delivery Handler as itself, then there is an error.
9.8. Check the Correct Components are present in the Request Block
Check that the correct components are present in the Payment
Request Block (see section 5.6) or in the Delivery Request Block
(see section 5.9).
If components are missing, there is an error.
9.9. Check an Action is Authorised
The previous steps identified the Action Organization and that
all the necessary components are present. This step checks that
the Action Organization is authorised to carry out the Action.
Surendra Reddy et al. [Page 175]
Internet Draft IOTP/1.0 September 21, 1998
In outline the Action Organization identifies the Merchant,
checks that it has a pre-existing agreement which allows it carry
out the Action and that any constraints implied by that agreement
are being followed, then, if signatures are required, it checks
that they sign the correct data.
The steps involved are as follows:
- Identify the Merchant. This is the Organization Component
with a Trading Role Element which has a Role attribute with
a value of Merchant. If no or more than one Trading Role
Element is found, there is an error
- Check the Action Organization's agreements with the Merchant
allows the Action to be carried out. To do this the Action
Organization must check that:
o the Merchant is known and a pre-existing agreement exists
for the Action Organization to be their agent for the
payment or delivery
o they are allowed to take part in the type of IOTP
transaction that is occurring. For example a Payment
Handler may have agreed to accept payments as part of a
Baseline Purchase, but not make payments as part of a
Baseline Refund
o any constraints in their agreement with the Merchant are
being followed, for example, whether or not an Offer
Response signature is required
- Check the signatures are correct. If signatures are required
then they need to be checked. This involves:
- Identifying the correct signatures to check. This involves
the Action Organization identifying the Signature Components
where the VerifierOrgRef attribute of the Digital Signature
element points to the Action Organization's Organization
Component. Depending on the IOTP Transaction being carried
out (see section 4) either one or two signatures may be
identified
- checking that the Signature Components are correct. This
involves checking that the necessary Trading Components have
been hashed (see section 9.9.1).
Note: Validation that the signature is correct and that the Hash
elements within the signature are correctly calculated is
described in section 7 IOTP Error Handling. This is because errors
in the signature or calculation of hashes is considered a Message
Level Error and is carried out before the Request Block is
Surendra Reddy et al. [Page 176]
Internet Draft IOTP/1.0 September 21, 1998
processed.
9.9.1. Check the Signatures Sign Correct Data
All Signature Components contained within IOTP Messages must
always hash:
the Transaction Id Component (see section 3.5.1) of the IOTP
message that contains the Signature Component. This binds
the globally unique OtpTransId to other components which
make up the IOTP Transaction
the Transaction Reference Block (see section 3.5) of the
first IOTP Message that contained the signature. This binds
the OtpTransId with information about the IOTP Message
contained inside the Message Id Component (see section
3.5.2).
Checking that each signature signs the correct data, involves
checking that hashes of the necessary components are present in
the SignedData element of the Signature Component.
The hashes that need to be present depend on the Trading Role of
the Organization which generated (signed) the signature:
if the signer of the signature is a Merchant then:
- hashes must be present for all the components in the Request
Block apart from the Brand Selection Component which is
optional
if the signer of the signature is a Payment Handler then
hashes should be present for:
- the Signature Component signed by the Merchant, and
optionally
- one or more Signature Components signed by the Payment
Handler(s) identified by the appropriate ActionSignerRefs
attribute.
9.10. Data Integrity and Privacy
The overall integrity of data in IOTP Messages is ensured by the
signing of hashes of Components and Trading Blocks contained in a
Signature Component (see section 6.30) in a Signature Block (see
section 5.18).
Privacy of information is provided by sending IOTP Messages
between the various Trading Roles using a secure channel such as
[SSL]. Use of a secure channel within IOTP is optional.
Surendra Reddy et al. [Page 177]
Internet Draft IOTP/1.0 September 21, 1998
10. Internationalization Considerations
In the realm of internationalization, this specification complies
with the IETF Character Set Policy [Alvestrand, 1998]. In this
specification, human-readable fields can be found either in the
value of a property, or in an error message returned in a response
entity body. In both cases, the human-readable content is encoded
using XML, which has explicit provisions for character set tagging
and encoding, and requires that XML processors read XML elements
encoded, at minimum, using the UTF-8 [Yergeau, 1998] encoding of the
ISO 10646 multilingual plane.
XML also provides a language tagging capability for specifying the
language of the contents of a particular XML element. XML uses
either IANA registered language tags (see RFC 1766, [Alvestrand,
1995]) or ISO 639 language tags [ISO-639] in the "xml:lang"
attribute of an XML element to identify the language of its content
and attributes.
IOTP applications MUST support the character set tagging,
character set encoding, and the language tagging functionality of
the XML specification.
Since interoperation of clients and servers does not require locale
information, this specification does not specify any mechanism for
transmission of this information.
11. IANA Considerations
This specification defines a distinguished set of XML elements that
are understood by all IOTP applications. The XML elements in this
specification are all derived from the base URI IOTP: by adding a
suffix to this URI.
To ensure correct interoperation based on this specification, IANA
must reserve the URI namespaces starting with "IOTP:" for use by
this specification, its revisions, and related IOTP specifications.
12. Copyrights
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
Surendra Reddy et al. [Page 178]
Internet Draft IOTP/1.0 September 21, 1998
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an AS IS basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
13. References
[Base64] Base64 Content-Transfer-Encoding. A method of transporting binary
data defined by MIME. See: RFC 2045: Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies. N.
Freed & N. Borenstein. November 1996.
[DNS] The Internet Domain Name System which allocates Internet names to
organisations for example "otp.org", the Domain Name for IOTP. See
RFC 1034: Domain names - concepts and facilities. P.V. Mockapetris.
Nov-01-1987, and RFC 1035: Domain names - implementation and
specification. P.V. Mockapetris. Nov-01-1987.
[DSA] The Digital Signature Algorithm (DSA) published by the National
Institute of Standards and Technology (NIST) in the Digital
Signature Standard (DSS), which is a part of the US government's
Capstone project.
[ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA).
Elliptic curve cryptosystems are analogs of public-key cryptosystems
such as RSA in which modular multiplication is replaced by the
elliptic curve addition operation. See: V. S. Miller. Use of
elliptic curves in cryptography. In Advances in Cryptology -
Crypto '85, pages 417-426, Springer-Verlag, 1986.
[HTML] Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML)
is a simple mark-up language used to create hypertext documents
that are platform independent. See RFC 1866 and the World Wide
Surendra Reddy et al. [Page 179]
Internet Draft IOTP/1.0 September 21, 1998
Web (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 1945:
Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding
& H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Protocol --
HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
T. Berners-Lee. January 1997.
[ISO4217] ISO 4217: Codes for the Representation of Currencies. Available
from ANSI or ISO.
[MIME] Multipurpose Internet Mail Extensions. See RFC822, RFC2045, RFC2046,
RFC2047, RFC2048 and RFC2049.
[OPS] Open Profiling Standard. A proposed standard which provides a
framework with built-in privacy safeguards for the trusted exchange
of profile information between individuals and web sites. Being
developed by Netscape and Microsoft amongst others.
[RFC822] IETF (Internet Engineering Task Force). RFC 822: The Standard for
the Format of ARPA Internet Messages . 13 August 1982, David H
Crocker. 13 August 1982.
[RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource
Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
[RSA] RSA is a public-key cryptosystem for both encryption and
authentication supported by RSA Data Security Inc. See: R. L.
Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital
signatures and public-key cryptosystems. Communications of the
ACM, 21(2): 120-126, February 1978.
[SCCD] Secure Channel Credit Debit. A method of conducting a credit or
debit card payment where unauthorised access to account information
is prevented through use of secure channel transport mechanisms such
as SSL. An IOTP supplement describing how SCCD works is under
development. Author. Jonathan Sowler JCP,
[SET] Secure Electronic Transaction Specification, Version 1.0, May 31,
1997. Supports credit and debit card payments using certificates at
the Consumer and Merchant to help ensure authenticity.
Download from: <http://www.mastercard.com/set/specs.html>.
[SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of Standards
and Technology, US Department Of Commerce, April 1995. Also known
as: 59 Fed Reg. 35317 (1994).
[UTC] Universal Time Co-ordinated. A method of defining time absolutely
Surendra Reddy et al. [Page 180]
Internet Draft IOTP/1.0 September 21, 1998
relative to Greenwich Mean Time (GMT). Typically of the form:
"CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of
hours from GMT. See ISO DIS8601.
[UTF16] The Unicode Standard, Version 2.0. The Unicode Consortium, Reading,
Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1
[X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including
Draft Amendment 1: Certificate Extensions (Version 3 Certificate)
[XML Namespace] See Design decisions reached at the XML Working Group
meeting in Montreal, Canada, August 22, 1987
[XML] Extensible Mark Up Language. See http://www.w3.org/TR/PR-xml-971208
for the 8 December 1997 version.
[XMLSIG] A proposal developed by the IOTP consortium describing an approach
to signing XML documents such as IOTP Messages. It is intended that
this document is submitted to W3C for consideration. Author.
Richard Brown. GlobeSet. (Under preparation August 1998)
14. Appendices
14.1. IOTP - XML DTD
<!--
******************************************************
* *
* OPEN TRADING PROTOCOL DTD *
* *
******************************************************
******************************************************
* IOTP MESSAGE DEFINITION *
******************************************************
-->
<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayInstCCExchBlk |
Surendra Reddy et al. [Page 181]
Internet Draft IOTP/1.0 September 21, 1998
PayInstCCReqBlk |
PayInstCCRespBlk
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk |
)*
) >
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
OtpTransId NMTOKEN #REQUIRED
OtpTransType CDATA #REQUIRED >
TransTimeStamp CDATA #REQUIRED >
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespOtpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!--
******************************************************
* Packaged Content Common Element *
******************************************************
Surendra Reddy et al. [Page 182]
Internet Draft IOTP/1.0 September 21, 1998
-->
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
<!--
******************************************************
* TRADING COMPONENTS *
******************************************************
-->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #REQUIRED
SecureSenderNetLocn CDATA #REQUIRED
SuccessNetLocn CDATA #REQUIRED
CancelNetLocn CDATA #REQUIRED
ErrorNetLocn CDATA #REQUIRED >
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
ID ID #REQUIRED
AuthMethod NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Surendra Reddy et al. [Page 183]
Internet Draft IOTP/1.0 September 21, 1998
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?,
PersonName?, PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
OtpMsgIdPrefix NMTOKEN #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
TradingRole NMTOKEN #REQUIRED
ErrorNetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True|False) 'False' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
Surendra Reddy et al. [Page 184]
Internet Draft IOTP/1.0 September 21, 1998
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED >
<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId NMTOKEN #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217'
CurrCode CDATA #REQUIRED >
<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
Surendra Reddy et al. [Page 185]
Internet Draft IOTP/1.0 September 21, 1998
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
AuthDataRef NMTOKEN #IMPLIED
StartAfter NMTOKENS #IMPLIED >
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- DELIVERY COMPONENT -->
<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
Surendra Reddy et al. [Page 186]
Internet Draft IOTP/1.0 September 21, 1998
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True|False) #REQUIRED
DelivAndPayResp (True|False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED
ConsumerDeliveryId CDATA #IMPLIED >
<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT METHOD INFORMATION COMPONENT -->
<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
ID ID #REQUIRED
BrandId NMTOKEN #REQUIRED
PayProtocolId NMTOKEN #IMPLIED >
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType (Offer|Payment|Delivery) #REQUIRED
ElRef NMTOKEN #REQUIRED
ProcessState (NotYetStarted|InProgress|
CompletedOk|Failed|ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
<!-- INQUIRY TYPE COMPONENT -->
Surendra Reddy et al. [Page 187]
Internet Draft IOTP/1.0 September 21, 1998
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type (Offer|Payment|Delivery) #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
OtpMsgRef NMTOKEN #REQUIRED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
<!--
******************************************************
* TRADING BLOCKS *
******************************************************
-->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (AuthData*, Order?, Payment*,
Delivery?, Status ) >
Surendra Reddy et al. [Page 188]
Internet Draft IOTP/1.0 September 21, 1998
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthData?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp, Org+) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (AuthData?, BrandList,
BrandSelection,
Payment, PaySchemeData?, Org*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?)>
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Order, Org*, Delivery) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
Surendra Reddy et al. [Page 189]
Internet Draft IOTP/1.0 September 21, 1998
<!-- PAYMENT INSTRUMENT CUSTOMER CARE REQUEST BLOCK -->
<!ELEMENT PayInstCCReqBlk (PaymethodInfo, PaySchemeData*)
>
<!ATTLIST PayInstCCReqBlk
ID ID #REQUIRED >
<!-- PAYMENT INSTRUMENT CUSTOMER CARE EXCHANGE BLOCK -->
<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
ID ID #REQUIRED >
<!-- PAYMENT INSTRUMENT CUSTOMER CARE RESPONSE BLOCK -->
<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
ID ID #REQUIRED >
<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedOtpMsgRef NMTOKEN #IMPLIED
LastSentOtpMsgRef NMTOKEN #IMPLIED >
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok|Busy|Down) #REQUIRED
SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
Surendra Reddy et al. [Page 190]
Internet Draft IOTP/1.0 September 21, 1998
<!-- SIGNATURE BLOCK -->
<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
ID ID #REQUIRED >
<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
15. Author's Address
Surendra K Reddy
Oracle Corporation
500 Oracle Parkway, M/S 4op12
Redwoodshores, CA 94065
USA
Tel: +1 (650) 506 5441
email: skreddy@us.oracle.com
David Burdett
Development Director
Mondex International Ltd
Advanced Technology Division
111 Pine St
San Francisco, CA 94111
USA
Tel: +1 (415) 645 6973
Email: david.burdett@mondex.com
Expires on March 21, 1999
Surendra Reddy et al. [Page 191]
| PAFTECH AB 2003-2026 | 2026-04-24 03:07:13 |