|
Network Working Group Request for Comments: 2801 Category: Informational |
D. Burdett Commerce One April 2000 |
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 © The Internet Society (2000). All Rights Reserved.
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.
1. Background
1.1 Commerce on the Internet, a Different Model
1.2 Benefits of IOTP
1.3 Baseline IOTP
1.4 Objectives of Document
1.5 Scope of Document
1.6 Document Structure
1.7 Intended Readership
1.7.1 Reading Guidelines
2. Introduction
2.1 Trading Roles
2.2 Trading Exchanges
2.2.1 Offer Exchange
2.2.2 Payment Exchange
2.2.3 Delivery Exchange
2.2.4 Authentication Exchange
2.3 Scope of Baseline IOTP
3. Protocol Structure
3.1 Overview
3.1.1 IOTP Message Structure
3.1.2 IOTP Transactions
3.2 IOTP Message
3.2.1 XML Document Prolog
3.3 Transaction Reference Block
3.3.1 Transaction Id Component
3.3.2 Message Id Component
3.3.3 Related To Component
3.4 ID Attributes
3.4.1 IOTP Message ID Attribute Definition
3.4.2 Block and Component ID Attribute Definitions
3.4.3 Example of use of ID Attributes
3.5 Element References
3.6 Extending IOTP
3.6.1 Extra XML Elements
3.6.2 Opaque Embedded Data
3.7 Packaged Content Element
3.7.1 Packaging HTML
3.7.2 Packaging XML
3.8 Identifying Languages
3.9 Secure and Insecure Net Locations
3.10 Cancelled Transactions
3.10.1 Cancelling Transactions
3.10.2 Handling Cancelled Transactions
4. IOTP Error Handling
4.1 Technical Errors
4.2 Business Errors
4.3 Error Depth
4.3.1 Transport Level
4.3.2 Message Level
4.3.3 Block Level
4.4 Idempotency, Processing Sequence, and Message Flow
4.5 Server Role Processing Sequence
4.5.1 Initiating Transactions
4.5.2 Processing Input Messages
4.5.3 Cancelling a Transaction
4.5.4 Retransmitting Messages
4.6 Client Role Processing Sequence
4.6.1 Initiating Transactions
4.6.2 Processing Input Messages
4.6.3 Cancelling a Transaction
4.6.4 Retransmitting Messages
5. Security Considerations
5.1 Determining whether to use digital signatures
5.2 Symmetric and Asymmetric Cryptography
5.3 Data Privacy
5.4 Payment Protocol Security
6. Digital Signatures and IOTP
6.1 How IOTP uses Digital Signatures
6.1.1 IOTP Signature Example
6.1.2 OriginatorInfo and RecipientInfo Elements
6.1.3 Using signatures to Prove Actions Complete
Successfully
6.2 Checking a Signature is Correctly Calculated
6.3 Checking a Payment or Delivery can occur
6.3.1 Check Request Block sent Correct Organisation
6.3.2 Check Correct Components present in Request Block
6.3.3 Check an Action is Authorised
7. Trading Components
7.1 Protocol Options Component
7.2 Authentication Request Component
7.3 Authentication Response Component
7.4 Trading Role Information Request Component
7.5 Order Component
7.5.1 Order Description Content
7.5.2 OkFrom and OkTo Timestamps
7.6 Organisation Component
7.6.1 Organisation IDs
7.6.2 Trading Role Element
7.6.3 Contact Information Element
7.6.4 Person Name Element
7.6.5 Postal Address Element
7.7 Brand List Component
7.7.1 Brand Element
7.7.2 Protocol Brand Element
7.7.3 Protocol Amount Element
7.7.4 Currency Amount Element
7.7.5 Pay Protocol Element
7.8 Brand Selection Component
7.8.1 Brand Selection Brand Info Element
7.8.2 Brand Selection Protocol Amount Info Element
7.8.3 Brand Selection Currency Amount Info Element
7.9 Payment Component
7.10 Payment Scheme Component
7.11 Payment Receipt Component
7.12 Payment Note Component
7.13 Delivery Component
7.13.1 Delivery Data Element
7.14 Consumer Delivery Data Component
7.15 Delivery Note Component
7.16 Status Component
7.16.1 Offer Completion Codes
7.16.2 Payment Completion Codes
7.16.3 Delivery Completion Codes
7.16.4 Authentication Completion Codes
7.16.5 Undefined Completion Codes
7.16.6 Transaction Inquiry Completion Codes
7.17 Trading Role Data Component
7.17.1 Who Receives a Trading Role Data Component
7.18 Inquiry Type Component
7.19 Signature Component
7.19.1 IOTP usage of signature elements and attributes
7.19.2 Offer Response Signature Component
7.19.3 Payment Receipt Signature Component
7.19.4 Delivery Response Signature Component
7.19.5 Authentication Request Signature Component
7.19.6 Authentication Response Signature Component
7.19.7 Inquiry Request Signature Component
7.19.8 Inquiry Response Signature Component
7.19.9 Ping Request Signature Component
7.19.10 Ping Response Signature Component
7.20 Certificate Component
7.20.1 IOTP usage of signature elements and attributes
7.21 Error Component
7.21.1 Error Processing Guidelines
7.21.2 Error Codes
7.21.3 Error Location Element
8. Trading Blocks
8.1 Trading Protocol Options Block
8.2 TPO Selection Block
8.3 Offer Response Block
8.4 Authentication Request Block
8.5 Authentication Response Block
8.6 Authentication Status Block
8.7 Payment Request Block
8.8 Payment Exchange Block
8.9 Payment Response Block
8.10 Delivery Request Block
8.11 Delivery Response Block
8.12 Inquiry Request Trading Block
8.13 Inquiry Response Trading Block
8.14 Ping Request Block
8.15 Ping Response Block
8.16 Signature Block
8.16.1 Signature Block with Offer Response
8.16.2 Signature Block with Payment Request
8.16.3 Signature Block with Payment Response
8.16.4 Signature Block with Delivery Request
8.16.5 Signature Block with Delivery Response
8.17 Error Block
8.18 Cancel Block
9. Internet Open Trading Protocol Transactions
9.1 Authentication and Payment Related IOTP Transactions
9.1.1 Authentication Document Exchange
9.1.2 Offer Document Exchange
9.1.3 Payment Document Exchange
9.1.4 Delivery Document Exchange
9.1.5 Payment and Delivery Document Exchange
9.1.6 Baseline Authentication IOTP Transaction
9.1.7 Baseline Deposit IOTP Transaction
9.1.8 Baseline Purchase IOTP Transaction
9.1.9 Baseline Refund IOTP Transaction
9.1.10 Baseline Withdrawal IOTP Transaction
9.1.11 Baseline Value Exchange IOTP Transaction
9.1.12 Valid Combinations of Document Exchanges
9.1.13 Combining Authentication Transactions with other
Transactions
9.2 Infrastructure Transactions
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 235
9.2.2 Baseline Ping IOTP Transaction
10. Retrieving Logos
10.1 Logo Size
10.2 Logo Color Depth
10.3 Logo Net Location Examples
11. Brands
11.1 Brand Definitions and Brand Selection
11.1.1 Definition of Payment Instrument
11.1.2 Definition of Brand
11.1.3 Definition of Dual Brand
11.1.4 Definition of Promotional Brand
11.1.5 Identifying Promotional Brands
11.2 Brand List Examples
11.2.1 Simple Credit Card Based Example
11.2.2 Credit Card Brand List Including Promotional Brands..253
11.2.3 Brand Selection Example
11.2.4 Complex Electronic Cash Based Brand List
12. IANA Considerations
12.1 Codes Controlled by IANA
12.2 Codes not controlled by IANA
13. Internet Open Trading Protocol Data Type Definition
14. Glossary
15. References
16. Author's Address
17. Full Copyright Statement
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
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:
The remainder of this section provides background to why IOTP was developed. The specification itself starts in the next chapter.
The growth of the Internet and the advent of electronic commerce are bringing about enormous changes around the world in society, politics and government, and in business. The ways in which trading partners communicate, conduct commerce, are governed have been enriched and changed forever.
One of the very fundamental changes about which IOTP is concerned is
taking place in the way consumers and merchants trade.
Characteristics of trading that have changed markedly include:
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:
BANKS AND FINANCIAL INSTITUTIONS
There are also several benefits for Banks and Financial Institutions:
- providing customer care for merchants
- fees from processing new payments and deposits
CUSTOMERS
For Customers there are several benefits:
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.
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.
The purpose of the document is:
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.
The document consists of the following sections:
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.
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:
Review the detailed XML definitions:
The Internet Open Trading Protocols (IOTP) define a number of different types of IOTP Transactions:
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:
Trading Roles, Trading Exchanges and Trading Components are described below.
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
The roles are:
Roles may be carried out by the same organisation or different organisations. For example:
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.
The Internet Open Trading Protocols identify four Trading Exchanges which involve the exchange of data between the Trading Roles. The Trading Exchanges are:
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.
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
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
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:
- the consumer provides information, about who the consumer is
and, if goods or services are being delivered, where the goods
or services are to be delivered to
- the merchant augments this information by providing information
about the merchant, the Payment Handler, the customer care
provider and, if goods or services are being delivered, the
Delivery Handler
The exact content of the information provided by the Merchant to the Consumer will vary depending on the type of IOTP Transaction. For example:
Information provided by the consumer to the merchant is provided using a variety of methods, for example, it could be provided:
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 |
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
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
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:
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.
- 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
Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols.
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).
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 |
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)
C <-- M Components: Delivery; Organisations (Delivery
Handler, Deliver To); Order, Optional Offer
Response Signature
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
- the Deliver To role indicates where the goods or services are
to be delivered to
- the Delivery Handler role is required so that the Delivery
Handler can check that she is the correct Delivery Handler to
do the delivery
- the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery
The 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:
This is illustrated in the diagram below.
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1
(Authenticatee)
| Organisation 2
| (Authenticator)
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
An Authentication Exchange uses the following Trading Components that are passed between the two Organisations:
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:
The following table defines, for each role, the IOTP Transactions and Trading Blocks which must be supported for that role.
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
TRANSACTIONS
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Depends Depends Depends
Depends Depends Depends
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
In the above table:
- if Baseline Authentication IOTP Transaction is supported;
- if required by a Payment Method as defined in its IOTP
Supplement document.
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".
The previous section provided an introduction which explained:
This section describes:
The structure of an IOTP Message and its relationship with Trading Blocks and Trading Components is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
| 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
the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component.
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 |
Message | N |
| | |
v | |
------------- | T | Process incoming
| IOTP Message | -------------- | | -----------> IOTP Message &
------------- | | generate next
| E | IOTP Message
| | |
| | v
Process incoming | R | -------------
IOTP Message <------------- | | ------------ | IOTP Message |
Message & stop | N |
| | |
v | |
------------- | E | Process last
| IOTP Message | -------------- | | -------------> incoming IOTP
------------- | | Message & stop
| | T | |
v | | v
STOP --- STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 7 An IOTP Transaction
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:
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?,
( 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.
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>
A Transaction Reference Block contains information which identifies the IOTP Transaction and IOTP Message. The Transaction Reference Block contains:
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.
RelatedTo See 3.3.3 Related To Component immediately below.
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:
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.
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.
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
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:
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.
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:
Values of RelationshipType are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
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.
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.
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.
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:
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:
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:
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.
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.
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:
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.
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)
|-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
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:
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:
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
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:
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:
The following rules apply:
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:
- 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
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'
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.
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:
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.
<!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:
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:
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.
The packaged content may contain HTML. In this case the following conventions are followed:
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
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:
Once these standards become W3C "Recommendations", then it is anticipated that this specification will be amended if practical.
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:
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.
IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types:
Note that either a Secure Net Location or an Insecure Net Location or both must be present.
If only one of the two Net Locations is present, then the one present must be used.
Where both types of net location are present then either may be used depending on the preference of the sender of the message.
Any Trading Role involved in an IOTP transaction may cancel that transaction at any time.
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:
If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient as an error.
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.
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:
- "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
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:
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.
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
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.
The three levels at which IOTP errors can occur are the transport level, the message level, and the block level. Each is described below.
This level of error indicates a fundamental problem in the transport mechanism over which the IOTP communication is taking place.
All transport level errors are technical errors and are indicated by either an explicit transport level error indication, such as a "No route to destination" error from TCP/IP, or by a time out where no response has been received to a request.
The only reasonable automatic action when faced with transport level errors is to retry and, after some number of automatic retries, to inform the user.
The explicit error indications that can be received are transport dependent and the documentation for the appropriate IOTP Transport supplement should be consulted for errors and appropriate actions.
Appropriate time outs to use are a function of both the transport being used and of the payment system if the request encapsulates payment information. The transport and payment system specific documentation should be consulted for time out and automatic retry parameters. Frequently there is no way to directly inform the other party of transport level errors but they should generally be logged and if automatic recovery is unsuccessful and there is a human user, the user should be informed.
This level of error indicates a fundamental technical problem with an entire IOTP message. For example, the XML is not "Well Formed", or the message is too large for the receiver to handle or there are errors in the Transaction Reference Block (see section 3.3) so it is not possible to figure out what transaction the message relates to.
All message level errors are technical errors and are indicated by Error Components (see section 7.21) sent to the other party. The Error Component includes a Severity attribute which indicates whether
the error is a Warning and may be ignored, a TransientError which indicates that a retry may resolve the problem or a HardError in which case the transaction must fail.
The Technical Errors (see section 7.21.2 Error Codes) that are Message Level errors are:
Note that checks on the Signature Block include checking, where possible, that each Signature Component is correctly calculated. If the Signature is incorrectly calculated then the data that should have been covered by the signature can not be trusted and must be treated as erroneous. A description of how to check a signature is correctly calculated is contained in section 6.2.
A Block level error indicates a problem with a block or one of its components in an IOTP message (apart from Transaction Reference or Signature Blocks). The message has been transported properly, the overall message structure and the block/component(s) including the Transaction Reference and Signature Blocks are meaningful but there is some error related to one o