 |
|
|
 |
|
|
|
|
RFC Index
rfc2801
Network Working Group D. Burdett
Request for Comments: 2801 Commerce One
Category: Informational April 2000
Internet Open Trading Protocol - IOTP
Version 1.0
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Secure Channel
Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to
handle cases where such merchant roles as the shopping site, the
Payment Handler, the Delivery Handler of goods or services, and the
provider of customer support are performed by different parties or by
one party.
Table of Contents
1. Background .....................................................7
1.1 Commerce on the Internet, a Different Model .................7
1.2 Benefits of IOTP ............................................9
1.3 Baseline IOTP ..............................................10
1.4 Objectives of Document .....................................10
1.5 Scope of Document ..........................................11
1.6 Document Structure .........................................11
1.7 Intended Readership ........................................13
1.7.1 Reading Guidelines ...................................13
2. Introduction ..................................................14
2.1 Trading Roles ..............................................16
2.2 Trading Exchanges ..........................................18
2.2.1 Offer Exchange .......................................19
2.2.2 Payment Exchange .....................................21
2.2.3 Delivery Exchange ....................................24
2.2.4 Authentication Exchange ..............................26
2.3 Scope of Baseline IOTP .....................................28
Burdett Informational [Page 1]
RFC 2801 IOTP/1.0 April 2000
3. Protocol Structure ............................................31
3.1 Overview ...................................................32
3.1.1 IOTP Message Structure ...............................32
3.1.2 IOTP Transactions ....................................34
3.2 IOTP Message ...............................................35
3.2.1 XML Document Prolog ..................................37
3.3 Transaction Reference Block ................................37
3.3.1 Transaction Id Component .............................38
3.3.2 Message Id Component .................................39
3.3.3 Related To Component .................................41
3.4 ID Attributes ..............................................42
3.4.1 IOTP Message ID Attribute Definition .................43
3.4.2 Block and Component ID Attribute Definitions .........44
3.4.3 Example of use of ID Attributes ......................46
3.5 Element References .........................................46
3.6 Extending IOTP .............................................48
3.6.1 Extra XML Elements ...................................49
3.6.2 Opaque Embedded Data .................................50
3.7 Packaged Content Element ...................................50
3.7.1 Packaging HTML .......................................52
3.7.2 Packaging XML ........................................53
3.8 Identifying Languages ......................................54
3.9 Secure and Insecure Net Locations ..........................54
3.10 Cancelled Transactions .....................................55
3.10.1 Cancelling Transactions ..............................55
3.10.2 Handling Cancelled Transactions ......................56
4. IOTP Error Handling ...........................................56
4.1 Technical Errors ...........................................57
4.2 Business Errors ............................................57
4.3 Error Depth ................................................58
4.3.1 Transport Level ......................................58
4.3.2 Message Level ........................................58
4.3.3 Block Level ..........................................59
4.4 Idempotency, Processing Sequence, and Message Flow .........61
4.5 Server Role Processing Sequence ............................62
4.5.1 Initiating Transactions ..............................62
4.5.2 Processing Input Messages ............................63
4.5.3 Cancelling a Transaction .............................70
4.5.4 Retransmitting Messages ..............................70
4.6 Client Role Processing Sequence ............................71
4.6.1 Initiating Transactions ..............................71
4.6.2 Processing Input Messages ............................72
4.6.3 Cancelling a Transaction .............................74
4.6.4 Retransmitting Messages ..............................74
5. Security Considerations .......................................74
5.1 Determining whether to use digital signatures ..............74
5.2 Symmetric and Asymmetric Cryptography ......................76
5.3 Data Privacy ...............................................77
Burdett Informational [Page 2]
RFC 2801 IOTP/1.0 April 2000
5.4 Payment Protocol Security ..................................77
6. Digital Signatures and IOTP ...................................77
6.1 How IOTP uses Digital Signatures ...........................77
6.1.1 IOTP Signature Example ...............................80
6.1.2 OriginatorInfo and RecipientInfo Elements ............82
6.1.3 Using signatures to Prove Actions Complete
Successfully .........................................83
6.2 Checking a Signature is Correctly Calculated ...............84
6.3 Checking a Payment or Delivery can occur ...................85
6.3.1 Check Request Block sent Correct Organisation ........86
6.3.2 Check Correct Components present in Request Block ....91
6.3.3 Check an Action is Authorised ........................91
7. Trading Components ............................................93
7.1 Protocol Options Component .................................96
7.2 Authentication Request Component ...........................97
7.3 Authentication Response Component ..........................98
7.4 Trading Role Information Request Component .................99
7.5 Order Component ...........................................100
7.5.1 Order Description Content ...........................101
7.5.2 OkFrom and OkTo Timestamps ..........................101
7.6 Organisation Component ....................................102
7.6.1 Organisation IDs ....................................104
7.6.2 Trading Role Element ................................105
7.6.3 Contact Information Element .........................108
7.6.4 Person Name Element .................................109
7.6.5 Postal Address Element ..............................110
7.7 Brand List Component ......................................111
7.7.1 Brand Element .......................................113
7.7.2 Protocol Brand Element ..............................115
7.7.3 Protocol Amount Element .............................116
7.7.4 Currency Amount Element .............................117
7.7.5 Pay Protocol Element ................................118
7.8 Brand Selection Component .................................120
7.8.1 Brand Selection Brand Info Element ..................122
7.8.2 Brand Selection Protocol Amount Info Element ........122
7.8.3 Brand Selection Currency Amount Info Element ........123
7.9 Payment Component .........................................123
7.10 Payment Scheme Component ..................................125
7.11 Payment Receipt Component .................................126
7.12 Payment Note Component ....................................128
7.13 Delivery Component ........................................129
7.13.1 Delivery Data Element ...............................130
7.14 Consumer Delivery Data Component ..........................132
7.15 Delivery Note Component ...................................133
7.16 Status Component ..........................................134
7.16.1 Offer Completion Codes ..............................137
7.16.2 Payment Completion Codes ............................138
7.16.3 Delivery Completion Codes ...........................140
Burdett Informational [Page 3]
RFC 2801 IOTP/1.0 April 2000
7.16.4 Authentication Completion Codes .....................142
7.16.5 Undefined Completion Codes ..........................144
7.16.6 Transaction Inquiry Completion Codes ................144
7.17 Trading Role Data Component ...............................144
7.17.1 Who Receives a Trading Role Data Component ..........145
7.18 Inquiry Type Component ....................................146
7.19 Signature Component .......................................147
7.19.1 IOTP usage of signature elements and attributes .....148
7.19.2 Offer Response Signature Component ..................150
7.19.3 Payment Receipt Signature Component .................151
7.19.4 Delivery Response Signature Component ...............152
7.19.5 Authentication Request Signature Component ..........152
7.19.6 Authentication Response Signature Component .........153
7.19.7 Inquiry Request Signature Component .................153
7.19.8 Inquiry Response Signature Component ................153
7.19.9 Ping Request Signature Component ....................153
7.19.10 Ping Response Signature Component...................154
7.20 Certificate Component .....................................154
7.20.1 IOTP usage of signature elements and attributes .....154
7.21 Error Component ...........................................154
7.21.1 Error Processing Guidelines .........................157
7.21.2 Error Codes .........................................158
7.21.3 Error Location Element ..............................162
8. Trading Blocks ...............................................163
8.1 Trading Protocol Options Block ............................166
8.2 TPO Selection Block .......................................167
8.3 Offer Response Block ......................................168
8.4 Authentication Request Block ..............................169
8.5 Authentication Response Block .............................170
8.6 Authentication Status Block ...............................171
8.7 Payment Request Block .....................................171
8.8 Payment Exchange Block ....................................173
8.9 Payment Response Block ....................................173
8.10 Delivery Request Block ....................................175
8.11 Delivery Response Block ...................................176
8.12 Inquiry Request Trading Block .............................177
8.13 Inquiry Response Trading Block ............................177
8.14 Ping Request Block ........................................179
8.15 Ping Response Block .......................................179
8.16 Signature Block ...........................................181
8.16.1 Signature Block with Offer Response .................182
8.16.2 Signature Block with Payment Request ................182
8.16.3 Signature Block with Payment Response ...............182
8.16.4 Signature Block with Delivery Request ...............182
8.16.5 Signature Block with Delivery Response ..............182
8.17 Error Block ...............................................183
8.18 Cancel Block ..............................................184
9. Internet Open Trading Protocol Transactions ..................184
Burdett Informational [Page 4]
RFC 2801 IOTP/1.0 April 2000
9.1 Authentication and Payment Related IOTP Transactions ......185
9.1.1 Authentication Document Exchange ....................188
9.1.2 Offer Document Exchange .............................194
9.1.3 Payment Document Exchange ...........................203
9.1.4 Delivery Document Exchange ..........................209
9.1.5 Payment and Delivery Document Exchange ..............212
9.1.6 Baseline Authentication IOTP Transaction ............216
9.1.7 Baseline Deposit IOTP Transaction ...................218
9.1.8 Baseline Purchase IOTP Transaction ..................220
9.1.9 Baseline Refund IOTP Transaction ....................222
9.1.10 Baseline Withdrawal IOTP Transaction ................224
9.1.11 Baseline Value Exchange IOTP Transaction ............226
9.1.12 Valid Combinations of Document Exchanges ............230
9.1.13 Combining Authentication Transactions with other
Transactions ........................................234
9.2 Infrastructure Transactions ...............................235
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 235
9.2.2 Baseline Ping IOTP Transaction ......................241
10. Retrieving Logos .............................................244
10.1 Logo Size .................................................245
10.2 Logo Color Depth ..........................................245
10.3 Logo Net Location Examples ................................246
11. Brands .......................................................246
11.1 Brand Definitions and Brand Selection .....................246
11.1.1 Definition of Payment Instrument ....................247
11.1.2 Definition of Brand .................................247
11.1.3 Definition of Dual Brand ............................248
11.1.4 Definition of Promotional Brand .....................248
11.1.5 Identifying Promotional Brands ......................249
11.2 Brand List Examples .......................................251
11.2.1 Simple Credit Card Based Example ....................252
11.2.2 Credit Card Brand List Including Promotional Brands..253
11.2.3 Brand Selection Example .............................254
11.2.4 Complex Electronic Cash Based Brand List ............255
12. IANA Considerations ..........................................257
12.1 Codes Controlled by IANA ..................................257
12.2 Codes not controlled by IANA ..............................263
13. Internet Open Trading Protocol Data Type Definition ..........263
14. Glossary .....................................................277
15. References ...................................................284
16. Author's Address .............................................287
17. Full Copyright Statement .....................................290
Burdett Informational [Page 5]
RFC 2801 IOTP/1.0 April 2000
Table of Figures
Figure 1 IOTP Trading Roles 16
Figure 2 Offer Exchange 19
Figure 3 Payment Exchange 22
Figure 4 Delivery Exchange 25
Figure 5 Authentication Exchange 27
Figure 6 IOTP Message Structure 33
Figure 7 An IOTP Transaction 34
Figure 8 Example use of ID attributes 46
Figure 9 Element References 48
Figure 10 Signature Digests 79
Figure 11 Example use of Signatures for Baseline Purchase 81
Figure 12 Checking a Payment Handler can carry out a Payment 87
Figure 13 Checking a Delivery Handler can carry out a Delivery 90
Figure 14 Trading Components 94
Figure 15 Brand List Element Relationships 113
Figure 16 Trading Blocks 164
Figure 17 Payment and Authentication Message Flow Combinations 187
Figure 18 Authentication Document Exchange 190
Figure 19 Brand Dependent Offer Document Exchange 196
Figure 20 Brand Independent Offer Exchange 198
Figure 21 Payment Document Exchange 204
Figure 22 Delivery Document Exchange 210
Figure 23 Payment and Delivery Document Exchange 214
Figure 24 Baseline Authentication IOTP Transaction 217
Figure 25 Baseline Deposit IOTP Transaction 219
Figure 26 Baseline Purchase IOTP Transaction 221
Figure 27 Baseline Refund IOTP Transaction 223
Figure 28 Baseline Withdrawal IOTP Transaction 225
Figure 29 Baseline Value Exchange IOTP Transaction 228
Figure 30 Baseline Value Exchange Signatures 230
Figure 31 Valid Combinations of Document Exchanges 231
Figure 32 Baseline Transaction Status Inquiry 238
Figure 33 Baseline Ping Messages 242
Burdett Informational [Page 6]
RFC 2801 IOTP/1.0 April 2000
1. Background
The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Mondex, CyberCash,
DigiCash, GeldKarte, etc. IOTP is able to handle cases where such
merchant roles as the shopping site, the Payment Handler, the
Delivery Handler of goods or services, and the provider of customer
support are performed by different parties or by one party.
The developers of IOTP seek to provide a virtual capability that
safely replicates the real world, the paper based, traditional,
understood, accepted methods of trading, buying, selling, value
exchanging that has existed for many hundreds of years. The
negotiation of who will be the parties to the trade, how it will be
conducted, the presentment of an offer, the method of payment, the
provision of a payment receipt, the delivery of goods and the receipt
of goods. These are events that are taken for granted in the course
of real world trade. IOTP has been produced to provide the same for
the virtual world, and to prepare and provide for the introduction of
new models of trading made possible by the expanding presence of the
virtual world.
The other fundamental ideal of the IOTP effort is to produce a
definition of these trading events in such a way that no matter where
produced, two unfamiliar parties using electronic commerce
capabilities to buy and sell that conform to the IOTP specifications
will be able to complete the business safely and successfully.
In summary, IOTP supports:
o Familiar trading models
o New trading models
o Global interoperability
The remainder of this section provides background to why IOTP was
developed. The specification itself starts in the next chapter.
1.1 Commerce on the Internet, a Different Model
The growth of the Internet and the advent of electronic commerce are
bringing about enormous changes around the world in society, politics
and government, and in business. The ways in which trading partners
communicate, conduct commerce, are governed have been enriched and
changed forever.
Burdett Informational [Page 7]
RFC 2801 IOTP/1.0 April 2000
One of the very fundamental changes about which IOTP is concerned is
taking place in the way consumers and merchants trade.
Characteristics of trading that have changed markedly include:
o Presence: Face-to-face transactions become the exception, not the
rule. Already with the rise of mail order and telephone order
placement this change has been felt in western commerce.
Electronic commerce over the Internet will further expand the
scope and volume of transactions conducted without ever seeing the
people who are a part of the enterprise with whom one does
business.
o Authentication: An important part of personal presence is the
ability of the parties to use familiar objects and dialogue to
confirm they are who they claim to be. The seller displays one or
several well known financial logos that declaim his ability to
accept widely used credit and debit instruments in the payment
part of a purchase. The buyer brings government or financial
institution identification that assures the seller she will be
paid. People use intangibles such as personal appearance and
conduct, location of the store, apparent quality and familiarity
with brands of merchandise, and a good clear look in the eye to
reinforce formal means of authentication.
o Payment Instruments: Despite the enormous size of bank card
financial payments associations and their members, most of the
world's trade still takes place using the coin of the realm or
barter. The present infrastructure of the payments business cannot
economically support low value transactions and could not survive
under the consequent volumes of transactions if it did accept low
value transactions.
o Transaction Values: New meaning for low value transactions arises
in the Internet where sellers may wish to offer for example, pages
of information for fractions of currency that do not exist in the
real world.
o Delivery: New modes of delivery must be accommodated such as
direct electronic delivery. The means by which receipt is
confirmed and the execution of payment change dramatically where
the goods or services have extremely low delivery cost but may in
fact have very high value. Or, maybe the value is not high, but
once delivery occurs the value is irretrievably delivered so
payment must be final and non-refundable but delivery nonetheless
must still be confirmed before payment. Incremental delivery such
as listening or viewing time or playing time are other models that
operate somewhat differently in the virtual world.
Burdett Informational [Page 8]
RFC 2801 IOTP/1.0 April 2000
1.2 Benefits of IOTP
ELECTRONIC COMMERCE SOFTWARE VENDORS
Electronic Commerce Software Vendors will be able to develop e-
commerce products which are more attractive as they will inter-
operate with any other vendors' software. However, since IOTP focuses
on how these solutions communicate, there is still plenty of
opportunity for product differentiation.
PAYMENT BRANDS
IOTP provides a standard framework for encapsulating payment
protocols. This means that it is easier for payment products to be
incorporated into IOTP solutions. As a result the payment brands will
be more widely distributed and available on a wider variety of
platforms.
MERCHANTS
There are several benefits for Merchants:
o they will be able to offer a wider variety of payment brands,
o they can be more certain that the customer will have the software
needed to complete the purchase
o through receiving payment and delivery receipts from their
customers, they will be able to provide customer care knowing that
they are dealing with the individual or organisation with which
they originally traded
o new merchants will be able to enter this new (Internet) market-
place with new products and services, using the new trading
opportunities which IOTP presents
BANKS AND FINANCIAL INSTITUTIONS
There are also several benefits for Banks and Financial Institutions:
o they will be able to provide IOTP support for merchants
o they will find new opportunities for IOTP related services:
- providing customer care for merchants
- fees from processing new payments and deposits
Burdett Informational [Page 9]
RFC 2801 IOTP/1.0 April 2000
o they have an opportunity to build relationships with new types of
merchants
CUSTOMERS
For Customers there are several benefits:
o they will have a larger selection of merchants with whom they can
trade
o there is a more consistent interface when making the purchase
o there are ways in which they can get their problems fixed through
the merchant (rather than the bank!)
o there is a record of their transaction which can be used, for
example, to feed into accounting systems or, potentially, to
present to the tax authorities
1.3 Baseline IOTP
This specification is Baseline IOTP. It is a Baseline in that it
contains ways of doing trades on the Internet which are the most
common, for example purchases and refunds.
The group that has worked on the IOTP see an extended version being
developed over time but feel a need to focus on a limited function
but completely usable specification in order that implementers can
develop solutions that work now.
During this period it is anticipated that there will be no changes to
the scope of this specification with the only changes made being
limited to corrections where problems are found. Software solutions
have been developed based on earlier versions of this specification
(for example version 0.9 published in early 1998 and earlier
revisions of version 1.0 published during 1999) which prove that the
IOTP works.
1.4 Objectives of Document
The objectives of this document are to provide a specification of
version 1.0 of the Internet Open Trading Protocols which can be used
to design and implement systems which support electronic trading on
the Internet using the Internet Open Trading Protocols.
Burdett Informational [Page 10]
RFC 2801 IOTP/1.0 April 2000
The purpose of the document is:
o to allow potential developers of products based on the protocol to
develop software/hardware solutions which use the protocol
o to allow the financial services industry to understand a
developing electronic commerce trading protocol that encapsulates
(without modification) any of the current or developing payment
schemes now being used or considered by their merchant customer
base
1.5 Scope of Document
The protocol describes the content, format and sequences of messages
that pass among the participants in an electronic trade - consumers,
merchants and banks or other financial institutions, and customer
care providers. These are required to support the electronic
commerce transactions outlined in the objectives above.
The protocol is designed to be applicable to any electronic payment
scheme since it targets the complete purchase process where the
movement of electronic value from the payer to the payee is only one,
but important, step of many that may be involved to complete the
trade.
Payment Scheme which IOTP could support include MasterCard Credit,
Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin,
Millicent, Proton, etc.
Each payment scheme contains some message flows which are specific to
that scheme. These scheme-specific parts of the protocol are
contained in a set of payment scheme supplements to this
specification.
The document does not prescribe the software and processes that will
need to be implemented by each participant. It does describe the
framework necessary for trading to take place.
This document also does not address any legal or regulatory issues
surrounding the implementation of the protocol or the information
systems which use them.
1.6 Document Structure
The document consists of the following sections:
o Section 1 - Background: This section gives a brief background on
electronic commerce and the benefits IOTP offers.
Burdett Informational [Page 11]
RFC 2801 IOTP/1.0 April 2000
o Section 2 - Introduction: This section describes the various
Trading Exchanges and shows how these trading exchanges are used
to construct the IOTP Transactions. This section also explains
various Trading Roles that would participate in electronic trade.
o Section 3 - Protocol Structure: This section summarises how
various IOTP transactions are constructed using the Trading Blocks
and Trading Components that are the fundamental building blocks
for IOTP transactions. All IOTP transaction messages are well
formed XML documents.
o Section 4 - IOTP Error Handling: This section describes how to
process exceptions and errors during the protocol message exchange
and trading exchange processing. This section provides a generic
overview of the exception handling. This section should be read
carefully.
o Section 5 - Security Considerations: This section considers from
an IETF perspective, how IOTP addresses security. It includes: how
to determine whether to use digital signatures with IOTP, how IOTP
address data privacy, and how security built into payment
protocols relate to IOTP security.
o Section 6 - Digital Signatures and IOTP: This section provides an
overview of how IOTP uses digital signatures; how to check a
signature is correctly calculated and how the various Trading
Roles that participate in trade should check signatures when
required.
o Section 7 - Trading Components: This section defines the XML
elements required by Trading Components.
o Section 8 - Trading Blocks: This section describes how Trading
Blocks are constructed from Trading Components.
o Section 9 - Internet Open Trading Protocol Transactions: This
section describes all the IOTP Baseline transactions. It refers to
Trading Blocks and Trading Components and Signatures. This section
doesn't directly link error handling during the protocol
exchanges, the reader is advised to understand Error Handling as
defined in section before reading this section.
o Section 10 - Retrieving Logos: This section describes how IOTP
specific logos can be retrieved.
Burdett Informational [Page 12]
RFC 2801 IOTP/1.0 April 2000
o Section 11 - Brands: This section provides: an overview of Brand
Definitions and Brand Selection which describe how a Consumer can
select a Brand from a list provided by the Merchant; as well as
some examples of Brand Lists.
o Section 12 - IANA Considerations: This section describes how new
values for codes used by IOTP are co-ordinated.
o Section 13 - Internet Open Trading Protocol Data Type Definition:
This section contains the XML Data Type Definitions for IOTP.
o Section 14 - Glossary. This describes all the major terminology
used by IOTP.
o Section 15 - A list of the other documents referenced by the IOTP
specification.
o Section 16 - The Author's Address
o Section 17 - Full Copyright Statement
1.7 Intended Readership
Software and hardware developers; development analysts; business and
technical planners; industry analysts; merchants; bank and other
payment handlers; owners, custodians, and users of payment protocols.
1.7.1 Reading Guidelines
This IOTP specification is structured primarily in a sequence
targeted at people who want to understand the principles of IOTP.
However from practical implementation experience by implementers of
earlier of versions of the protocol new readers who plan to implement
IOTP may prefer to read the document in a different sequence as
described below.
Review the transport independent parts of the specification. This
covers:
o Section 14 - Glossary
o Section 1 - Background
o Section 2 - Introduction
o Section 3 - Protocol Structure
o Section 4 - IOTP Error Handling
Burdett Informational [Page 13]
RFC 2801 IOTP/1.0 April 2000
o Section 5 - Security Considerations
o Section 9 - Internet Open Trading Protocol Transactions
o Section 11 - Brands
o Section 12 - IANA Considerations
o Section 10 - Retrieving Logos
Review the detailed XML definitions:
o Section 8 - Trading Blocks
o Section 7 - Trading Components
o Section 6 - Digital Signatures and IOTP
2. Introduction
The Internet Open Trading Protocols (IOTP) define a number of
different types of IOTP Transactions:
o Purchase. This supports a purchase involving an offer, a payment
and optionally a delivery
o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase
o Value Exchange. This involves two payments which result in the
exchange of value from one combination of currency and payment
method to another
o Authentication. This supports one organisation or individual to
check that another organisation or individual are who they appear
to be.
o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution
o Deposit. This supports the deposit of electronic cash at a
financial institution
o Inquiry. This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
Burdett Informational [Page 14]
RFC 2801 IOTP/1.0 April 2000
o Ping. This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running
elsewhere is working or not.
These IOTP Transactions are "Baseline" transactions since they have
been identified as a minimum useful set of transactions. Later
versions of IOTP may include additional types of transactions.
Each of the IOTP Transactions above involve:
o a number of organisations playing a Trading Role, and
o a set of Trading Exchanges. Each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set of
Trading Components.
Trading Roles, Trading Exchanges and Trading Components are described
below.
Burdett Informational [Page 15]
RFC 2801 IOTP/1.0 April 2000
2.1 Trading Roles
The Trading Roles identify the different parts which organisations
can take in a trade. The five Trading Roles used within IOTP are
illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Customer Care Provider resolves ----------
---------------------------------------------->| Merchant |
| Consumer disputes and problems |Cust.Care.|
| | Provider |
| ----------
|
Payment Handler accepts or makes ----------
| ------------------------------------------>| Payment |
| | Payment for Merchant | Handler |
| | ----------
v v
---------- Consumer makes purchases or obtains ----------
| Consumer |<--------------------------------------->| Merchant |
---------- refund from Merchant ----------
^
| Delivery Handler supplies goods or ----------
|---------------------------------------------->|Deliverer |
services for Merchant | Handler |
----------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 1 IOTP Trading Roles
Burdett Informational [Page 16]
RFC 2801 IOTP/1.0 April 2000
The roles are:
o Consumer. The person or organisation which is to receive and pay
for the goods or services
o Merchant. The person or organisation from whom the purchase is
being made and who is legally responsible for providing the goods
or services and receives the benefit of the payment made
o Payment Handler. The entity that physically receives the payment
from the Consumer on behalf of the Merchant
o Delivery Handler. The entity that physically delivers the goods or
services to the Consumer on behalf of the Merchant.
o Merchant Customer Care Provider. The entity that is involved with
customer dispute negotiation and resolution on behalf of the
Merchant
Roles may be carried out by the same organisation or different
organisations. For example:
o in the simplest case one physical organisation (e.g., a merchant)
could handle the purchase, accept the payment, deliver the goods
and provide merchant customer care
o at the other extreme, a merchant could handle the purchase but
instruct the consumer to pay a bank or financial institution,
request that delivery be made by an overnight courier firm and to
contact an organisation which provides 24x7 service if problems
arise.
Note that in this specification, unless stated to the contrary, when
the words Consumer, Merchant, Payment Handler, Delivery Handler or
Customer Care Provider are used, they refer to the Trading Role
rather than an actual organisation.
An individual organisation may take multiple roles. For example a
company which is selling goods and services on the Internet could
take the role of Merchant when selling goods or services and the role
of Consumer when the company is buying goods or services itself.
As roles occur in different places there is a need for the
organisations involved in the trade to exchange data, i.e. to carry
out Trading Exchanges, so that the trade can be completed.
Burdett Informational [Page 17]
RFC 2801 IOTP/1.0 April 2000
2.2 Trading Exchanges
The Internet Open Trading Protocols identify four Trading Exchanges
which involve the exchange of data between the Trading Roles. The
Trading Exchanges are:
o Offer. The Offer Exchange results in the Merchant providing the
Consumer with the reason why the trade is taking place. It is
called an Offer since the Consumer must accept the Offer if a
trade is to continue
o Payment. The Payment Exchange results in a payment of some kind
between the Consumer and the Payment Handler. This may occur in
either direction
o Delivery. The Delivery Exchange transmits either the on-line
goods, or delivery information about physical goods from the
Delivery Handler to the Consumer, and
o Authentication. The Authentication Exchange can be used by any
Trading Role to authenticate another Trading Role to check that
they are who they appear to be.
IOTP Transactions are composed of various combinations of these
Trading Exchanges. For example, an IOTP Purchase transaction
includes Offer, Payment, and Delivery Trading Exchanges. As another
example, an IOTP Value Exchange transaction is composed of an Offer
Trading Exchange and two Payment Trading Exchanges.
Trading Exchanges consist of Trading Components that are transmitted
between the various Trading Roles. Where possible, the number of
round-trip delays in an IOTP Transaction is minimised by packing the
Components from several Trading Exchanges into combination IOTP
Messages. For example, the IOTP Purchase transaction combines a
Delivery Organisation Component with an Offer Response Component in
order to avoid an extra Consumer request and response.
Each of the IOTP Trading Exchanges is described in more detail below.
For clarity of description, these describe the Trading Exchanges as
though they were standalone operations. For performance reasons, the
Trading Exchanges are intermingled in the actual IOTP Transaction
definitions.
Burdett Informational [Page 18]
RFC 2801 IOTP/1.0 April 2000
2.2.1 Offer Exchange
The goal of the Offer Exchange is for the Merchant to provide the
Consumer with information about the trade so that the Consumer can
decide whether to continue with the trade. This is illustrated in the
figure below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends information about the
transaction (requests an offer) to the Merchant e.g.,
using HTML.
C --> M Data: Information on what is being purchased (Offer Request)
- outside scope of IOTP
2. Merchant checks the information provided by the Consumer,
creates an Offer optionally signs it and sends it to the
Consumer.
C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
(Consumer, DelivTo, Merchant, Payment Handler, Customer
Care); Order; Payment; Delivery; TradingRoleData (optional)
Offer Response Signature (optional) that signs other
components
3. Consumer checks the information from the Merchant and
decides whether to continue.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 2 Offer Exchange
An Offer Exchange uses the following Trading Components that are
passed between the Consumer and the Merchant:
o the Status component is used to indicate to other parties that a
valid Offer Response has been generated
o the Organisation Component contains information which describes
the Organisations which are taking a role in the trade:
- the consumer provides information, about who the consumer is
and, if goods or services are being delivered, where the goods
or services are to be delivered to
Burdett Informational [Page 19]
RFC 2801 IOTP/1.0 April 2000
- the merchant augments this information by providing information
about the merchant, the Payment Handler, the customer care
provider and, if goods or services are being delivered, the
Delivery Handler
o the Order Component contains descriptions of the goods or services
which will result from the trade if the consumer agrees to the
offer. This information is sent by the Merchant to the consumer
who should verify it
o the Payment Component generated by the Merchant, contains details
of how much to pay, the currency and the payment direction, for
example the consumer could be asking for a refund. Note that there
may be more than one payment in a trade
o the Delivery Component, also generated by the Merchant, is used if
goods or services are being delivered. This contains information
about how delivery will occur, for example by post or using e-mail
o the Trading Role Data component contains data the Merchant wants
to forward to another Trading Role such as a Payment Handler or
Delivery Handler
o the "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity.
The exact content of the information provided by the Merchant to the
Consumer will vary depending on the type of IOTP Transaction. For
example:
o low value purchases may not need a signature
o the amount to be paid may vary depending on the payment brand and
payment protocol used
o some offers may not involve the delivery of any goods
o a value exchange will involve two payments
o a merchant may not offer customer care.
Information provided by the consumer to the merchant is provided
using a variety of methods, for example, it could be provided:
o using [HTML] pages as part of the "shopping experience" of the
consumer.
Burdett Informational [Page 20]
RFC 2801 IOTP/1.0 April 2000
o Using the Open Profiling Standard [OPS] which has recently been
proposed,
o in the form of Organisation Components associated with an
authentication of a Consumer by a Merchant
o as Order Components in a later version of IOTP.
2.2.2 Payment Exchange
The goal of the Payment Exchange is for a payment to be made from the
Consumer to a Payment Handler or vice versa using a payment brand and
payment protocol selected by the Consumer. A secondary goal is to
optionally provide the Consumer with a digitally signed Payment
Receipt which can be used to link the payment to the reason for the
payment as described in the Offer Exchange.
Payment Exchanges can work in a variety of ways. The most general
case where the trade is dependent on the payment brand and protocol
used is illustrated in the diagram below. Simpler payment exchanges
are possible.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Pay Handler
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about the transaction (requests an offer) to the
Merchant e.g., using HTML.
C --> M Information on what is being paid for (outside
scope of IOTP
2. Merchant decides which payment brand, payment
protocols and currencies/amounts to offer,
places then in a Brand List Component and sends
them to the Consumer
C <-- M Components: Brand List
3. Consumer selects the payment brand, protocol and
currency/amount to use, creates a Brand Selection
component and sends it to the Merchant
C --> M Component: Brand List Selection
Burdett Informational [Page 21]
RFC 2801 IOTP/1.0 April 2000
4. Merchant checks Brand Selection, creates a Payment
Amount information, optionally signs it to
authorise payment and sends it to the Consumer
C <-- M Component: Payment; Organisation(s) (Merchant and
Payment Handler); Optional Offer Response Signature
that signs other components
5. Consumer checks the Payment Amount information and
if OK requests that the payment starts by sending
information to the Payment Handler
C --------> P PAYMENT REQUEST. Components: Status, Payment;
Organisations (Merchant and Payment Handler);
Trading Role Data (optional); Optional Offer
Response Signature that signs other components;
Pay Scheme Data
6. Payment Handler checks information including
optional signature and if OK starts exchanging Pay
Scheme Data components for selected payment brand
and payment protocol
C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data
7. Eventually payment protocol messages finish so
Payment Handler sends Pay Receipt and optional
signature to the Consumer as proof of payment
C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt;
Payment Note; Trading Role Data (optional);
Optional Offer Response Signature; Optional
Payment Receipt Signature that binds the payment
to the Offer
8. Consumer checks Payment Receipt is OK
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 3 Payment Exchange
A Payment Exchange uses the following Trading Components that are
passed between the Consumer, the Merchant and the Payment Handler:
o The Brand List Component contains a list of payment brands (for
example, MasterCard, Visa, Mondex, GeldKarte), payment protocols
(for example SET Version 1.0, Secure Channel Credit Debit (SCCD -
the name used for a credit or debit card payment where
Burdett Informational [Page 22]
RFC 2801 IOTP/1.0 April 2000
unauthorised access to account information is prevented through
use of secure channel transport mechanisms such as SSL/TLS) as
well as currencies/amounts that apply. The Merchant sends the
Brand List to the Consumer. The consumer compares the payment
brands, protocols and currencies/amounts on offer with those that
the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's selection.
Payment brand, protocol, currency/amount and possibly protocol-
specific information is sent back to the Merchant. This
information may be used to change information in the Offer
Exchange. For example, a merchant could choose to offer a discount
to encourage the use of a store card.
o the Status component is used to indicate to the Payment Handler
that an earlier exchange (e.g., an Offer Exchange) has
successfully completed and by the Payment Handler to indicate the
completion status of the Payment Exchange.
o The Organisation Components are generated by the Merchant. They
contain details of the Merchant and Payment Handler Roles:
- the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the
result of the Payment Handler accepting (or making) a payment
on behalf of the Merchant will be a credit or debit transaction
to the Merchant's account held by the Payment Handler. These
transactions are outside the scope of this version of IOTP
- the Payment Handler role is required so that the Payment
Handler can check that it is the correct Payment Handler to be
used for the payment
o The Payment Component contains details of how much to pay, the
currency and the payment direction
o The "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity. Note
that the Brand List and Brand Selection Components are not signed
until the payment information is created (step 4 in the diagram)
o the Trading Role Data component contains from other roles (e.g., a
Merchant) that needs to be forwarded to the Payment Handler
o The Payment Scheme Component contains messages from the payment
protocol used in the Trade. For example they could be SET
messages, Mondex messages, GeldKarte Messages or one of the other
payment methods supported by IOTP. The content of the Payment
Burdett Informational [Page 23]
RFC 2801 IOTP/1.0 April 2000
Scheme Component is defined in the supplements that describe how
IOTP works with various payment protocols.
o The Payment Receipt Component contains a record of the payment.
The content depends upon the payment protocol used.
o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing both the Payment Receipt Component
and the Offer Response Signature. The signature on the offer
digitally signs the Order, Organisation and Delivery Components
contained in the Offer. This signature effectively binds the
payment to the offer.
The example of a Payment Exchange above is the most general case.
Simpler cases are also possible. For example, if the amount paid is
not dependent on the payment brand and protocol selected then the
payment information generated by step 3 can be sent to the Consumer
at the same time as the Brand List Component generated by step 1.
These and other variations are described in the Baseline Purchase
IOTP Transaction (see section 9.1.8).
2.2.3 Delivery Exchange
The goal of the Delivery Exchange is to cause purchased goods to be
delivered to the consumer either online or via physical delivery. A
second goal is to provide a "delivery note" to the consumer,
providing details about the delivery, such as shipping tracking
number. The result of the delivery may also be signed so that it can
be used for customer care in the case of problems with physical
delivery. The message flow is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER DELIVERY
| HANDLER
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about what to deliver and who is to take delivery,
to the Merchant e.g., using HTML.
C --> M Information on what is being delivered (outside
scope of IOTP)
2. Merchant checks the information provided by the
Consumer, adds information about how the delivery
will occur, information about the Organisations
involved in the delivery and optionally sings it
and sends it to the Consumer
Burdett Informational [Page 24]
RFC 2801 IOTP/1.0 April 2000
C <-- M Components: Delivery; Organisations (Delivery
Handler, Deliver To); Order, Optional Offer
Response Signature
3. Consumer checks delivery information is OK,
obtains authorisation for the delivery, for
example by making a payment, and sends the
delivery information to the Delivery Handler
C --------> D DELIVERY REQUEST. Components: Status; Delivery,
Organisations: (Merchant, Delivery Handler,
DelivTo); Order, Trading Role Data (optional);
Optional Offer Response Signature, Optional
Payment Receipt Signature (from Payment Exchange)
4. Delivery Handler checks information and
authorisation. Starts or schedules delivery and
creates and then sends a delivery not tot the
Consumer which can optionally be signed.
C <-------- D DELIVERY RESPONSE. Components: Status; Delivery
Note, Trading Role Data (optional); Optional
Delivery Response Signature
5. Consumer checks delivery note is OK and accepts or
waits for delivery as described in the the Delivery
Note.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 4 Delivery Exchange
A Delivery Exchange uses the following Trading Components that are
passed between the Consumer, the Merchant and the Delivery Handler:
o the Status component is used to indicate to the Delivery Handler
that an earlier exchange (e.g., an Offer Exchange or Payment
Exchange) has successfully completed and by the Delivery Handler
to indicate the completion status of the Delivery Exchange.
o The Organisation Component(s) contain details of the Deliver To,
Delivery Handler and Merchant Roles:
- the Deliver To role indicates where the goods or services are
to be delivered to
Burdett Informational [Page 25]
RFC 2801 IOTP/1.0 April 2000
- the Delivery Handler role is required so that the Delivery
Handler can check that she is the correct Delivery Handler to
do the delivery
- the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery
o The Order Component, contains information about the goods or
services to be delivered
o The Delivery Component contains information about how delivery
will occur, for example by post or using e-mail.
o The "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity.
o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing the Payment Receipt Component and the
Offer Signature. This is used by the Delivery Handler to check
that delivery is authorised
o The Delivery Note Component contains customer care information
related to a physical delivery, or alternatively the actual
"electronic goods". The Consumer's software does not interpret
information about a physical delivery but should have the ability
to display the information, both at the time of the delivery and
later if the Consumer selects the Trade to which this delivery
relates from a transaction list
o The "Delivery Response" Signature Component, if present, provides
proof of the results of the Delivery by digitally signing the
Delivery Note and any Offer Response or Payment Response
signatures that the Delivery Handler received.
2.2.4 Authentication Exchange
The goal of the Authentication Exchange is to allow one Organisation,
for example a financial institution, to be able to check that another
Organisation, for example a consumer, is who they appear to be.
An Authentication Exchange involves:
o an Authenticator - the Organisation which is requesting the
authentication, and
o an Authenticatee - the Organisation being authenticated.
Burdett Informational [Page 26]
RFC 2801 IOTP/1.0 April 2000
This is illustrated in the diagram below.
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1
(Authenticatee)
| Organisation 2
| (Authenticator)
STEP | |
1. First Organisation, e.g., a Consumer, takes an action (for
example by pressing a button on an HTML page) which
requires that the Organisation is authenticated
1 --> 2 Need for Authentication (outside scope of IOTP)
2. The second Organisation generates an Authentication
Request - including challenge data, and a list of the
algorithms that may be used for the authentication -
and/or a request for the Organisation information then
sends it to the first Organisation
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
Request, Trading Role Information Request
3. The first Organisation optionally checks any signature
associated with the Authentication Request then uses the
specified authentication algorithm to generate an
Authentication Response which is sent back to the second
Organisation together with details of any Organisation
information requested
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Response, Organisation(s)
4. The Authentication Response is checked against the
challenge data to check that the first Organisation is
who they appear to be and the result recorded in a Status
Component which is then sent back to the first
Organisation.
1 <-- 2 AUTHENTICATION STATUS. Component: Status
5. The first Organisation then optionally checks the results
indicated by the Status and any associated signature and
takes the appropriate action or stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 5 Authentication Exchange
Burdett Informational [Page 27]
RFC 2801 IOTP/1.0 April 2000
An Authentication Exchange uses the following Trading Components that
are passed between the two Organisations:
o the Authentication Request Component that requests an
Authentication and indicates the authentication algorithm and
optional challenge data to be used.
o A Trading Role Information Request Component that requests
information about an Organisation, for example a ship to address.
o The Authentication Response Component which contains the challenge
response generated by the recipient of the Authentication Request
Component.
o Organisation Components that contain the result of the Trading
Role Information Request
o the Status Component which contains the results of the second
party's verification of the Authentication Response.
2.3 Scope of Baseline IOTP
This specification describes the IOTP Transactions which make up
Baseline IOTP. As described in the preface, IOTP will evolve over
time. This section defines the initial conformance criteria for
implementations that claim to "support IOTP."
The main determinant on the scope of an IOTP implementation is the
roles which the solution is designed to support. The roles within
IOTP are described in more detail in section 2.1 Trading Roles. To
summarise the roles are: Merchant, Consumer, Payment Handler,
Delivery Handler and Customer Care Provider.
Payment Handlers who can be of three types:
o those who accept a payment as part of a purchase or make a payment
as part of a refund,
o those who accept value as part of a deposit transaction, or
o those that issue value a withdrawal transaction
The following table defines, for each role, the IOTP Transactions and
Trading Blocks which must be supported for that role.
Burdett Informational [Page 28]
RFC 2801 IOTP/1.0 April 2000
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
TRANSACTIONS
Purchase Must Must
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Refund Must b)
Depends
Authentication May Must May b)
Depends
Value Exchange May Must
Withdrawal Must b)
Depends
Deposit Must b)
Depends
Inquiry Must Must Must May Must Must
Ping Must Must Must May Must Must
TRADING BLOCKS
TPO Must Must Must Must
TPO Selection Must Must Must Must
Auth-Request a) a) a)
Depends Depends Depends
Auth-Reply a) a) a)
Depends Depends Depends
Offer Response Must Must Must Must
Burdett Informational [Page 29]
RFC 2801 IOTP/1.0 April 2000
Payment Must Must
Request
Payment Must Must
Exchange
Payment Must Must
Response
Delivery Must Must
Request
Delivery Must Must
Response
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Inquiry Must Must Must Must Must Must
Request
Inquiry Must Must Must Must Must Must
Response
Ping Request Must Must Must Must Must Must
Ping Response Must Must Must Must Must Must
Signature Must Must Must Limited Must Must
Error Must Must Must Must Must Must
In the above table:
o "Must" means that a Trading Role must support the Transaction or
Trading Block.
o "May" means that an implementation may support the Transaction or
Trading Block at the option of the developer.
o "Depends" means implementation of the Transaction or Trading Block
depends on one of the following conditions:
- if Baseline Authentication IOTP Transaction is supported;
Burdett Informational [Page 30]
RFC 2801 IOTP/1.0 April 2000
- if required by a Payment Method as defined in its IOTP
Supplement document.
o "Limited" means the Trading Block must be understood and its
content manipulated but not in every respect. Specifically, on the
Signature Block, Consumers do not have to be able to validate
digital signatures.
An IOTP solution must support all the IOTP Transactions and Trading
Blocks required by at least one role (column) as described in the
above table for that solution to be described as "supporting IOTP".
3. Protocol Structure
The previous section provided an introduction which explained:
o Trading Roles which are the different roles which Organisations
can take in a trade: Consumer, Merchant, Payment Handler, Delivery
Handler and Customer Care Provider, and
o Trading Exchanges where each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set of
Trading Components.
This section describes:
o 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,
o how IOTP Messages are exchanged between Trading Roles to create an
IOTP Transaction
o 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
o 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
o how extra XML Elements and new user defined values for existing
IOTP codes can be used when Extending IOTP,
o how IOTP uses the Packaged Content Element to embed data such as
payment protocol messages or detailed order definitions within an
IOTP Message
Burdett Informational [Page 31]
RFC 2801 IOTP/1.0 April 2000
o how IOTP Identifies Languages so that different languages can be
used within IOTP Messages
o how IOTP handles both Secure and Insecure Net Locations when
sending messages
o how an IOTP Transaction can be cancelled.
3.1 Overview
3.1.1 IOTP Message Structure
The structure of an IOTP Message and its relationship with Trading
Blocks and Trading Components is illustrated in the diagram below.
Burdett Informational [Page 32]
RFC 2801 IOTP/1.0 April 2000
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <---------- IOTP Message - an XML Document which is
| transported between the Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains information which
| | describes the IOTP Transaction and the IOTP
| | Message.
| |-Trans Id Comp. <--- Transaction Id Component - uniquely
| | identifies the IOTP Transaction. The Trans Id
| | Components are the same across all IOTP
| | messages that comprise a single IOTP
| | transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies and
| describes an IOTP Message within an IOTP
| Transaction
|-Signature Block <----- Signature Block (optional) - contains one or
| | more Signature Components and their
| | associated Certificates
| |-Signature Comp. <-- Signature Component - contains digital
| | signatures. Signatures may sign digests of
| | the Trans Ref Block and any Trading Component
| | in any IOTP Message in the same IOTP
| | transaction.
| |-Certificate Comp. < Certificate Component (Optional) Used to check
| the signature.
|-Trading Block <------- Trading Block - an XML Element within an IOTP
| |-Trading Comp. Message that contains a predefined set of
| |-Trading Comp. Trading Components
| |-Trading Comp.
| |-Trading Comp. <--- Trading Components - XML Elements within a
| Trading Block that contain a predefined set
|-Trading Block of XML elements and attributes containing
| |-Trading Comp. information required to support a Trading
| |-Trading Comp. Exchange
| |-Trading Comp.
| |-Trading Comp.
| |-Trading Comp.
*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 6 IOTP Message Structure
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.4) which is unique within an
IOTP Transaction. Therefore the combination of the ID attribute and
Burdett Informational [Page 33]
RFC 2801 IOTP/1.0 April 2000
the globally unique identifier in the Transaction Reference Block is
sufficient to uniquely identify any Trading Block or Trading
Component.
3.1.2 IOTP Transactions
A predefined set of IOTP Messages exchanged between the Trading Roles
constitute an IOTP Transaction. This is illustrated in the diagram
below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER MERCHANT
Generate first
IOTP Message
--- |
| | v
Process incoming | I | -------------
IOTP Message & <------------- | | ------------ | IOTP Message |
generate next IOTP | | -------------
Message | N |
| | |
v | |
------------- | T | Process incoming
| IOTP Message | -------------- | | -----------> IOTP Message &
------------- | | generate next
| E | IOTP Message
| | |
| | v
Process incoming | R | -------------
IOTP Message <------------- | | ------------ | IOTP Message |
generate last IOTP | | -------------
Message & stop | N |
| | |
v | |
------------- | E | Process last
| IOTP Message | -------------- | | -------------> incoming IOTP
------------- | | Message & stop
| | T | |
v | | v
STOP --- STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 7 An IOTP Transaction
Burdett Informational [Page 34]
RFC 2801 IOTP/1.0 April 2000
In the above diagram the Internet is shown as the transport
mechanism. This is not necessarily the case. IOTP Messages can be
transported using a variety of transport mechanisms.
The IOTP Transactions (see section 9) in this version of IOTP are
specifically:
o Purchase. This supports a purchase involving an offer, a payment
and optionally a delivery
o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase
o Value Exchange. This involves two payments which result in the
exchange of value from one combination of currency and payment
method to another
o Authentication. This supports the remote authentication of one
Trading Role by another Trading Role using a variety of
authentication algorithms, and the provision of an Organisation
Information about the Trading Role that is being authenticated for
use in, for example, the creation of an offer
o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution
o Deposit. This supports the deposit of electronic cash at a
financial institution
o Inquiry This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
o Ping This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running
elsewhere is working or not.
3.2 IOTP Message
As described earlier, IOTP Messages are [XML] documents which are
physically sent between the different Trading Roles that are taking
part in a trade.
The XML definition of an IOTP Message is as follows.
<!ELEMENT IotpMessage
( TransRefBlk,
SigBlk?,
ErrorBlk?,
Burdett Informational [Page 35]
RFC 2801 IOTP/1.0 April 2000
( AuthReqBlk |
AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
Content:
TransRefBlk This contains information which describes an IOTP
Message within an IOTP Transaction (see section
3.3 immediately below)
AuthReqBlk, These are the Trading Blocks.
AuthRespBlk,
DeliveryReqBlk, The Trading Blocks present within an IOTP Message,
DeliveryRespBlk and the content of a Trading Block itself is
ErrorBlk dependent on the type of IOTP Transaction being
InquiryReqBlk, carried out - see the definition of each
InquiryRespBlk, transaction in section 9 Internet Open Trading
OfferRespBlk, Protocol Transactions.
PayExchBlk,
PayReqBlk, Full definitions of each Trading Block are
PayRespBlk, described in section 8.
PingReqBlk,
PingRespBlk,
SigBlk,
TpoBlk,
TpoSelectionBlk
Attributes:
xmlns The [XML Namespace] definition for IOTP messages.
Burdett Informational [Page 36]
RFC 2801 IOTP/1.0 April 2000
3.2.1 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 IotpMessage >
<IotpMessage>
...
</IotpMessage>
3.3 Transaction Reference Block
A Transaction Reference Block contains information which identifies
the IOTP Transaction and IOTP Message. The Transaction Reference
Block contains:
o 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,
o 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
o 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.4 ID Attributes).
Content:
TransId See 3.3.1 Transaction Id Component immediately
below.
MsgId See 3.3.2 Message Id Component immediately below.
Burdett Informational [Page 37]
RFC 2801 IOTP/1.0 April 2000
RelatedTo See 3.3.3 Related To Component immediately below.
3.3.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'
IotpTransId CDATA #REQUIRED
IotpTransType 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.
IotpTransId Contains data which uniquely identifies the IOTP
Transaction. It must conform to the rules for
Message Ids in [RFC 822].
IotpTransTyp 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:
o BaselineAuthentication
o BaselineDeposit
o BaselinePurchase
o BaselineRefund
o BaselineWithdrawal
o BaselineValueExchange
o BaselineInquiry
o BaselinePing
Values of IotpTransType are managed under the
procedure described in section 12 IANA
Considerations which also allows user defined
values of IotpTransType to be defined.
Burdett Informational [Page 38]
RFC 2801 IOTP/1.0 April 2000
In later versions of IOTP, this list will be
extended to support different types of standard
IOTP Transaction. 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.3.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
RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
IOTP Message within the IOTP Transaction (see
section 3.4 ID Attributes). Note that if an
IOTP Message is resent then the value of this
attribute remains the same.
RespIotpMsg 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
Burdett Informational [Page 39]
RFC 2801 IOTP/1.0 April 2000
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.
SenderTradingRoleRef The Element Reference (see section 3.5) of the
Trading Role which has generated the IOTP
message. It is used to identify the Net
Locations (see section 3.9) of the Trading
Role to which problems Technical Errors (see
section 4.1) with any of Trading Blocks should
be reported.
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.8 Identifying
Languages.
LangPrefList Optional list of Language codes that conform
to [XML] Language Identification. It is used
by the sender to indicate, in preference
sequence, the languages that the receiver of
the message ideally should use when generating
a response. There is no obligation on the
receiver to respond using one of the indicated
languages, but using one of the languages is
likely to provide an improved user experience.
CharSetPrefList Optional list of Character Set identifiers
that conform to [XML] Characters. It is used
by the sender to indicate, in preference
sequence, the character sets that the receiver
of the message ideally should use when
generating a response. There is no obligation
on the receiver to respond using one of the
character sets indicated, but using one of the
character sets is likely to provide an
improved user experience.
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:
Burdett Informational [Page 40]
RFC 2801 IOTP/1.0 April 2000
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
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.3.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
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.8 Identifying Languages.
RelationshipType Defines the type of the relationship. Valid values
are:
o IotpTransaction. in which case the Packaged
Content Element contains an IotpTransId of
another IOTP Transaction
o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
Values of RelationshipType are controlled under
the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
Burdett Informational [Page 41]
RFC 2801 IOTP/1.0 April 2000
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 implementers 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 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 implementers.
Content:
PackagedContent The Packaged Content (see section 3.7) contains
data which identifies the related transaction. Its
format varies depending on the value of the
RelationshipType.
3.4 ID Attributes
IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading
Blocks), Trading Components (including the Transaction Id Component
and the Signature Component) and some of their child elements 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.
Burdett Informational [Page 42]
RFC 2801 IOTP/1.0 April 2000
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. Also, once the ID attribute of an element
has been assigned a value it is never changed. This means that
whenever an element is copied, the value of the ID attribute remains
the same.
As a result 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.5).
This section defines the rules for setting the values for the ID
attributes of IOTP Messages, Blocks and Components.
3.4.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 follows:
IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*
IotpMsgIdSuffix ::= Digit (Digit)*
IotpMsgIdPrefix Apart from messages which contain: an Inquiry
Request Trading Block, an Inquiry Response Trading
Block, a Ping Request Trading Block or a Ping
Response Trading Block; then the same prefix is
used for all messages sent by the Merchant or
Consumer role as follows:
o "M" - Merchant
o "C" - Consumer
For messages which contain an Inquiry Request
Trading Block or a Ping Request Trading Block, the
prefix is set to "I" for Inquiry.
For messages which contain an Inquiry Response
Trading Block or a Ping Response Trading Block,
the prefix is set to "Q".
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:
Burdett Informational [Page 43]
RFC 2801 IOTP/1.0 April 2000
o "P" - First (only) Payment Handler
o "R" - Second Payment Handler
o "D" - Delivery Handler
o "C" - Deliver To
As a guideline, prefixes should be limited to one
character.
NameChar has the same definition as the [XML]
definition of NameChar.
IotpMsgIdSuffix 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:
o the first IOTP Message sent by a trading role
is given the suffix "1"
o the second and subsequent IOTP Messages sent
by the same trading role are incremented by one
for each message
o no leading zeroes are included in the suffix
Put more simply the Message Id Component of 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.4.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 ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*
IotpMsgId_value 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.
Burdett Informational [Page 44]
RFC 2801 IOTP/1.0 April 2000
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:
o the first Block or Component sent by a trading
role is given the suffix "1"
o 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
o 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]
definition of Digit.
Burdett Informational [Page 45]
RFC 2801 IOTP/1.0 April 2000
3.4.3 Example of use of ID Attributes
The diagram below illustrates how ID attribute values are used.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
IOTP MESSAGE IOTP MESSAGE *
|-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp.
| | Copy Element | | ID=M1.2
| |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 *
| |
|-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5*
| |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15
| Copy Element |
|-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 *
| |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4
| | Copy Element |
| |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
| | Copy Element |
| |-Comp. ID=M1.6 |-Comp. ID=C1.3 *
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 *
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10 * = new elements
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 8 Example use of ID attributes
3.5 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:
o identifying an XML element whose Digest is included in a Signature
Component,
Burdett Informational [Page 46]
RFC 2801 IOTP/1.0 April 2000
o 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:
o belongs to the same IOTP Transaction (i.e. the Transaction Id
Components of the IOTP Messages match), and
o where the value of the ID attribute of the element matches the
value of the Element Reference.
Note: The term "match" in this specification has the same definition
as the [XML] definition of match.
An example of "matching" an Element Reference is illustrated in the
example below.
Burdett Informational [Page 47]
RFC 2801 IOTP/1.0 April 2000
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
IOTP MESSAGE IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1
| |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2
| | must be | |
| |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1
| ^ |
|-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5
| |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15
| AND |
|-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2
| |-Comp. ID=M1.4 | |-Comp. ID=M1.4
| | v |
| |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5
| | and El Ref |
| |-Comp. ID=M1.6 values must |-Comp. ID=C1.3
| | match--------|--> El Ref=M1.5
| |-Comp. ID=M1.7 |-Comp. ID=C1.4
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 9 Element References
Note: Element Reference attributes are defined as "NMTOKEN" rather
than "IDREF" (see [XML]). This is because an IDREF requires that the
XML element referred to is in the same XML Document. With IOTP this
is not necessarily the case.
3.6 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:
Burdett Informational [Page 48]
RFC 2801 IOTP/1.0 April 2000
o extra XML elements, and
o new values for existing IOTP codes.
3.6.1 Extra XML Elements
The XML element and attribute names used within IOTP constitute an
[XML Namespace] as identified by the xmlns attribute on the
IotpMessage element. This allows IOTP to support the inclusion of
additional XML elements within IOTP messages through the use of [XML
Namespaces].
Using XML Namespaces, extra XML elements may be included at any level
within an IOTP message including:
o new Trading Blocks
o new Trading Components
o new XML elements within a Trading Component.
The following rules apply:
o any new XML element must be declared according to the rules for
[XML Namespaces]
o 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,
IOTP: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:
o if an extra XML element has an "IOTP: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 has a Technical Error (see section 4.1) and must fail.
o if an extra XML element has an "IOTP: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:
Burdett Informational [Page 49]
RFC 2801 IOTP/1.0 April 2000
- 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
- the content of the extra element must be ignored except that it
must be included when it is used in the creation of a digest as
part of the generation of a signature
o if an extra XML element has no "IOTP:Critical" attribute then it
must be treated as if it had an "IOTP:Critical" attribute with a
value of "True"
o if an XML element contains an "IOTP:Critical" attribute, then the
value of that attribute is assumed to apply to all the child
elements within that element
In order to ensure that documents containing "IOTP:Critical" are
valid, it is declared as part of the DTD for the extra element as:
IOTP:Critical (True | False ) 'True'
3.6.2 Opaque Embedded Data
If IOTP is to be extended using Opaque Embedded Data then a Packaged
Content Element (see section 3.7) should be used to encapsulate the
data.
3.7 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:
o to encapsulate payment scheme messages, such as SET messages,
o to encapsulate a description of an order, a payment note, or a
delivery note.
In general it is used to encapsulate one or more data streams.
This data stream has three standardised attributes that allow for
identification, decoding and interpretation of the contents. Its
definition is as follows.
Burdett Informational [Page 50]
RFC 2801 IOTP/1.0 April 2000
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
Attributes:
Name Optional. Distinguishes between multiple
occurrences of Packaged Content Elements at the
same point in IOTP. For example:
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
The name attribute may be omitted, for example if
there is only one Packaged Content element.
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:
o PCDATA. The content of the Packaged Content
Element can be treated as PCDATA with no
further processing.
o 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.
o 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.
Burdett Informational [Page 51]
RFC 2801 IOTP/1.0 April 2000
o 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.
Values of the Content attribute are controlled
under the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
Transform This identifies the transformation that has been
done to the data before it was placed in the
content. Valid values are:
o 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.
o 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.7.1 Packaging HTML
The packaged content may contain HTML. In this case the following
conventions are followed:
o references to any documents, images or other things, such as
sounds or web pages, which can affect the recipient's
understanding of the data which is being packaged must refer to
other Packaged Elements contained within the same parent element,
e.g., an Order Description
Burdett Informational [Page 52]
RFC 2801 IOTP/1.0 April 2000
o if more than one Packaged Content element is included within a
parent element in order to meet the previous requirement, then the
Name attribute of the top level Packaged Content from which
references to all other Packaged Elements can be determined,
should have a value of Main
o relative references to other documents, images, etc. from one
Packaged Content element to another are realised by setting the
value of the relative reference to the Name attribute of another
Packaged Content element at the same level and within the same
parent element
o no external references that require the reference to be resolved
immediately should be used. As this could make the HTML difficult
or impossible to display completely
o [MIME] is used to encapsulate the data inside each Packaged
Element. This means that the information in the MIME header used
to identify the type of data which has been encapsulated and
therefore how it should be displayed.
If the above conventions are not followed by, for example, including
external references which must be resolved, then the recipient of the
HTML should be informed.
Note: As an implementation guideline the values of the Name
Attributes allocated to Packaged Content elements should make it
possible to extract each Packaged Content into a directory and then
display the HTML directly
3.7.2 Packaging XML
Support for XML is recommended. When XML needs to be displayed, for
example to display the content of an Order Description to a Consumer,
then implementers should follow the latest recommendations of the
World Wide Web Consortium.
Note: At the time of writing this specification, standards are under
development that specify XML style sheets that show how XML documents
should be displayed. See:
o "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl, and
o "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet.
Burdett Informational [Page 53]
RFC 2801 IOTP/1.0 April 2000
Once these standards become W3C "Recommendations", then it is
anticipated that this specification will be amended if practical.
3.8 Identifying Languages
IOTP uses [XML] Language Identification to specify which languages
are used within the content and attributes of IOTP Messages.
The following principles have been used in order to determine which
XML elements contain an xml:lang Attributes:
o 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
o 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 7.
A sender of a message, typically a Consumer can indicate a preference
for a language, and a character set by specifying a list of preferred
languages/character sets in a Message Id Component (see section
3.3.2). Note that there is no obligation on the receiver of such a
message to respond using one of the listed languages/character sets
as they may not have the technology to be able to do it. It also
means that the ability to handle these lists is not a requirement for
conformance to this specification. However the ability to respond,
for example using one of the stated languages/character sets is
likely to provide a better user experience.
3.9 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:
o "Secure" Net Locations which are net locations where privacy of
data is secured using, for example, encryption methods such as
[SSL/TLS], and
o "Insecure" Net Locations where privacy of data is not assured.
Note that either a Secure Net Location or an Insecure Net Location or
both must be present.
Burdett Informational [Page 54]
RFC 2801 IOTP/1.0 April 2000
If only one of the two Net Locations is present, then the one present
must be used.
Where both types of net location are present then either may be used
depending on the preference of the sender of the message.
3.10 Cancelled Transactions
Any Trading Role involved in an IOTP transaction may cancel that
transaction at any time.
3.10.1 Cancelling Transactions
IOTP Transactions are cancelled by sending an IOTP message containing
just a Cancel Block with an appropriate Status Component to the other
Trading Role involved in the Trading Exchange.
Note: The Cancel Block can be sent asynchronously of any other IOTP
Message. Specifically it can be sent either before sending or after
receiving an IOTP Message from the other Trading Role
If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
the interval between sending a "request" block and receiving the
matching "response" block) then the Cancel Block is sent to the same
location as the next IOTP Message in the Trading Exchange would have
been sent.
If a Consumer cancels a transaction after a Trading Exchange has
completed (i.e. the "response" block for the Trading Exchange has
been received), but before the IOTP Transaction has finished then the
Consumer sends a Cancel Block with an appropriate Status Component to
the net location identified by the SenderNetLocn or
SecureSenderNetLocn contained in the Protocol Options Component (see
section 7.1) contained in the TPO Block (see section 8.1) for the
transaction. This is normally the Merchant Trading Role.
A Consumer should not send a Cancel Block after the IOTP Transaction
has completed. Cancelling a complete transaction should be treated as
a technical error.
After cancelling the IOTP Transaction, the Consumer should go to the
net location specified by the CancelNetLocn attribute contained in
the Trading Role Element for the Organisation that was sent the
Cancel Block.
A non-Consumer Trading Role should only cancel a transaction:
o after a request block has been received and
Burdett Informational [Page 55]
RFC 2801 IOTP/1.0 April 2000
o before the response block has been sent
If a non-Consumer Trading Role cancels a transaction at any other
time it should be treated by the recipient as an error.
3.10.2 Handling Cancelled Transactions
If a Cancel Block is received by a Consumer at a point in the IOTP
Transaction when cancellation is allowed, then the Consumer should
stop the transaction.
If a Cancel Block is received by a non-Consumer role, then the
Trading Role should anticipate that the Consumer may go to the
location specified by the CancelNetLocn attribute contained in the
Trading Role Element for the Trading Role.
4. 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 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:
o the different types of errors which can occur. This is divided
into:
- "technical errors" which are independent of the purpose of the
IOTP Message,
- "business errors" which indicate that there is a problem
specific to the process (e.g., payment or delivery) which is
being carried out, and
o the depth of the error which indicates whether the error is at the
transport, message or block/component level
o how the different trading roles should handle the different types
of messages which they may receive.
Burdett Informational [Page 56]
RFC 2801 IOTP/1.0 April 2000
4.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:
o retrying the transmission, or
o cancelling the transaction.
When communications are operating sufficiently well, a technical
error is indicated by an Error Component (see section 7.21) in an
Error Block (see section 8.17) sent by the party which detected the
error in an IOTP message to the party which sent the erroneous
message.
If communications are 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 the
Error Component which lists all the different technical errors which
can be set.
4.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, delivery or authentication, 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 7.16) of a "response
block" of the appropriate 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 Offer (see section 9.1.2.2), the user
might wish to choose a different payment instrument/account of the
same brand or a different brand or payment system. Alternatively, if
Burdett Informational [Page 57]
RFC 2801 IOTP/1.0 April 2000
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.
4.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.
4.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 b | |