One document matched: draft-ietf-trade-iotp-v1.0-protocol-02.txt
Differences from draft-ietf-trade-iotp-v1.0-protocol-01.txt
TRADE Working Group David Burdett
Internet Draft Mondex International
draft-ietf-trade-iotp-v1.0-protocol-02.txt 23 October 1998
Expires: 23 March 1998
Internet Open Trading Protocol - IOTP
Version 1.0
Status of this Memo
This document is an Internet draft. Internet drafts are working
documents of the Internet Engineering Task Force (IETF), its areas and
its working groups. Note that other groups may also distribute working
information as Internet drafts.
Internet Drafts are draft documents valid for a maximum of six months
and can be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to use Internet drafts as reference material
or to cite them as other than as "work in progress".
To learn the current status of any Internet draft please check the
"lid-abstracts.txt" listing contained in the Internet drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East coast) or
ftp.isi.edu (US West coast). Further information about the IETF can be
found at URL: http://www.ietf.org/
Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at
http://www.elistx.com/archives/ietf-trade.
Abstract
The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash,
GeldKarte, etc. IOTP is able to handle cases where such merchant roles
as the shopping site, the payment handler, the Delivery Handler of
goods or services, and the provider of customer support are performed
by different parties or by one party.
David Burdett et al. [Page 1]
Internet Draft IOTP/1.0 23 October 1998
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Background......................................................9
1.1 Commerce on the Internet _ a Different Model................9
1.2 Benefits of IOTP...........................................10
1.3 Baseline IOTP..............................................12
1.4 Objectives of Document.....................................12
1.5 Purpose....................................................12
1.6 Scope of Document..........................................13
1.7 Document Structure.........................................13
1.8 Intended Readership........................................14
1.8.1 Reading Guidelines ....................................14
1.9 History....................................................15
2. Introduction...................................................16
2.1 Trading Roles..............................................16
2.2 Trading Exchanges..........................................18
2.2.1 Offer Exchange ........................................19
2.2.2 Payment Exchange ......................................20
2.2.3 Delivery Exchange .....................................23
2.2.4 Authentication Exchange ...............................24
2.3 Scope of Baseline IOTP.....................................25
3. Protocol Structure.............................................28
3.1 Overview...................................................29
3.1.1 IOTP Message Structure ................................29
3.1.2 IOTP Transactions .....................................30
3.2 IOTP Message...............................................31
3.2.1 XML Document Prolog ...................................33
3.3 Transaction Reference Block................................33
3.3.1 Transaction Id Component ..............................34
3.3.2 Message Id Component ..................................35
3.3.3 Related To Component ..................................36
3.4 ID Attributes..............................................37
3.4.1 IOTP Message ID Attribute Definition ..................38
3.4.2 Block and Component ID Attribute Definitions ..........39
3.4.3 Example of use of ID Attributes .......................40
3.5 Element References.........................................40
3.6 Brands and Brand Selection.................................42
3.6.1 Definition of Payment Instrument ......................42
3.6.2 Definition of Brand ...................................42
3.6.3 Definition of Dual Brand ..............................43
3.6.4 Definition of Promotional Brand .......................43
3.6.5 Identifying Promotional Brands ........................44
3.7 Extending IOTP.............................................46
3.7.1 Extra XML Elements ....................................46
3.7.2 Opaque Embedded Data ..................................47
3.7.3 User Defined Codes ....................................47
David Burdett et al. [Page 2]
Internet Draft IOTP/1.0 23 October 1998
3.8 Packaged Content Element...................................48
3.9 Identifying Languages......................................49
3.10 Secure and Insecure Net Locations.........................50
4. IOTP Error Handling............................................50
4.1 Technical Errors...........................................51
4.2 Business Errors............................................51
4.3 Error Depth................................................52
4.3.1 Transport Level .......................................52
4.3.2 Message Level .........................................52
4.3.3 4Block Level ..........................................53
4.4 Idempotency, Processing Sequence, and Message Flow.........54
4.4.1 Server Role Processing Sequence .......................55
4.4.2 Client Role Processing Sequence .......................59
5. Security Considerations........................................64
5.1 Digital Signatures and IOTP................................64
5.1.1 IOTP Signature Example ................................65
5.1.2 SignerOrgRef and VerifierOrgRef Attributes ............66
5.1.3 Symmetric and Asymmetric Cryptography .................67
5.1.4 Mandatory and Optional Signatures .....................67
5.1.5 Using signatures to Prove Actions Complete Successfully68
5.2 Checking a Signature is Correctly Calculated...............68
5.3 Checking a Payment or Delivery can occur...................69
5.3.1 Check the Action Request was sent to the Correct
Organisation ................................................69
5.3.2 Check the Correct Components are present in the Request
Block .......................................................73
5.3.3 Check an Action is Authorised .........................73
5.4 Data Integrity and Privacy.................................74
6. Trading Components.............................................75
6.1 Protocol Options Component.................................76
6.2 Authentication Data Component..............................77
6.3 Authentication Response Component..........................79
6.4 Order Component............................................80
6.4.1 Order Description Content .............................81
6.4.2 OkFrom and OkTo Timestamps ............................82
6.5 Organisation Component.....................................82
6.5.2 Trading Role Element ..................................85
6.5.3 Contact Information Element ...........................87
6.5.4 Person Name Element ...................................87
6.5.5 Postal Address Element ................................88
6.6 Brand List Component.......................................89
6.6.1 Brand Element .........................................91
6.6.2 Protocol Amount Element ...............................94
6.6.3 Currency Amount Element ...............................95
6.6.4 Pay Protocol Element ..................................96
6.7 Brand Selection Component..................................98
6.7.1 Brand Selection Brand Info Element ....................99
6.7.2 Brand Selection Protocol Amount Info Element .........100
6.7.3 Brand Selection Currency Amount Info Element .........100
6.8 Payment Component.........................................101
David Burdett et al. [Page 3]
Internet Draft IOTP/1.0 23 October 1998
6.9 Payment Scheme Component..................................102
6.10 Payment Receipt Component................................104
6.11 Payment Note Component...................................105
6.12 Delivery Component.......................................106
6.12.1 Delivery Data Element ...............................108
6.13 Delivery Note Component..................................110
6.14 Payment Method Information Component.....................111
6.15 Status Component.........................................112
6.16 Trading Role Data Component..............................117
6.16.1 Who Receives a Trading Role Data Component ..........118
6.17 Inquiry Type Component...................................118
6.18 Signature Component......................................119
6.18.1 Offer Response Signature Component ..................119
6.18.2 Payment Receipt Signature Component .................120
6.18.3 Ping Signature Components ...........................120
6.19 Error Component..........................................121
6.19.1 Error Processing Guidelines .........................123
6.19.2 Error Codes .........................................124
6.19.3 Error Location Element ..............................127
7. Trading Blocks................................................128
7.1 Trading Protocol Options Block............................130
7.2 TPO Selection Block.......................................131
7.3 Offer Response Block......................................132
7.4 Authentication Request Block..............................133
7.5 Authentication Response Block.............................134
7.6 Payment Request Block.....................................134
7.7 Payment Exchange Block....................................136
7.8 Payment Response Block....................................136
7.9 Delivery Request Block....................................137
7.10 Delivery Response Block..................................138
7.11 Payment Instrument Customer Care Request Block...........139
7.12 Payment Instrument Customer Care Exchange Block..........140
7.13 Payment Instrument Customer Care Response Block..........140
7.14 Inquiry Request Trading Block............................141
7.15 Inquiry Response Trading Block...........................141
7.16 Ping Request Block.......................................142
7.17 Ping Response Block......................................143
7.18 Signature Block..........................................144
7.18.1 Offer Response ......................................145
7.18.2 Payment Request .....................................145
7.18.3 Payment Response ....................................145
7.18.4 Delivery Request ....................................145
7.19 Error Block..............................................146
8. Open Trading Protocol Transactions............................147
8.1 Baseline Authentication IOTP Transaction..................147
8.1.1 Trading Protocol Options Block .......................150
8.1.2 Authentication Request Block .........................150
8.1.3 Signature Block (Authentication Request) .............150
8.1.4 Authentication Response Block ........................150
8.1.5 Signature Block (Authentication Response) ............150
8.2 Baseline Deposit IOTP Transaction.........................151
David Burdett et al. [Page 4]
Internet Draft IOTP/1.0 23 October 1998
8.2.1 Baseline Deposit Variations ..........................152
8.2.2 Baseline Deposit Authentication ......................152
8.2.3 Baseline Deposit Payment Messages ....................154
8.2.4 TPO (Trading Protocol Options) Block .................155
8.2.5 TPO Selection Block ..................................156
8.2.6 Authentication Request Block .........................156
8.2.7 Authentication Response Block ........................156
8.2.8 Offer Response Block .................................156
8.2.9 Signature Block (Offer Response) .....................157
8.2.10 Payment Request Block ...............................157
8.2.11 Signature Block (Payment Request) ...................158
8.2.12 Payment Exchange Block ..............................158
8.2.13 Payment Response Block ..............................158
8.2.14 Signature Block (Payment Response) ..................158
8.3 Baseline Purchase IOTP Transaction........................159
8.3.1 Baseline Purchase Variations .........................159
8.3.2 TPO (Trading Protocol Options) Block .................167
8.3.3 TPO Selection Block ..................................167
8.3.4 Offer Response Block .................................167
8.3.5 Signature Block (Offer Response) .....................168
8.3.6 Payment Request Block ................................169
8.3.7 Signature Block (Payment Request) ....................169
8.3.8 Payment Exchange Block ...............................169
8.3.9 Payment Response Block ...............................169
8.3.10 Signature Block (Payment Response) ..................170
8.3.11 Delivery Request Block ..............................170
8.3.12 Signature Block (Delivery Request) ..................171
8.3.13 Delivery Response Block .............................171
8.4 Baseline Refund IOTP Transaction..........................171
8.4.1 Baseline Refund Variations ...........................172
8.4.2 Baseline Refund Authentication .......................172
8.4.3 Baseline Refund Payment Messages .....................174
8.4.4 TPO (Trading Protocol Options) Block .................175
8.4.5 TPO Selection Block ..................................175
8.4.6 Authentication Request Block .........................176
8.4.7 Authentication Response Block ........................176
8.4.8 Offer Response Block .................................176
8.4.9 Signature Block (Offer Response) .....................176
8.4.10 Payment Request Block ...............................177
8.4.11 Signature Block (Payment Request) ...................177
8.4.12 Payment Exchange Block ..............................177
8.4.13 Payment Response Block ..............................178
8.4.14 Signature Block (Payment Response) ..................178
8.5 Baseline Withdrawal IOTP Transaction......................178
8.5.1 Baseline Withdrawal Variations .......................179
8.5.2 Baseline Withdrawal Authentication ...................179
8.5.3 Baseline Withdrawal Payment Messages .................182
8.5.4 TPO (Trading Protocol Options) Block .................183
8.5.5 TPO Selection Block ..................................183
8.5.6 Authentication Request Block .........................183
8.5.7 Authentication Response Block ........................184
8.5.8 Offer Response Block .................................184
8.5.9 Signature Block (Offer Response) .....................184
David Burdett et al. [Page 5]
Internet Draft IOTP/1.0 23 October 1998
8.5.10 Payment Request Block ...............................185
8.5.11 Signature Block (Payment Request) ...................185
8.5.12 Payment Exchange Block ..............................185
8.5.13 Payment Response Block ..............................186
8.5.14 Signature Block (Payment Response) ..................186
8.6 Baseline Value Exchange IOTP Transaction..................186
8.6.1 Baseline Value Exchange Variations ...................187
8.6.2 PO (Trading Protocol Options) Block ..................191
8.6.3 TPO Selection Block ..................................192
8.6.4 Offer Response Block .................................192
8.6.5 Signature Block (Offer Response) .....................192
8.6.6 Payment Request Block (first payment) ................193
8.6.7 Signature Block (Payment Request - first payment) ....194
8.6.8 Payment Exchange Block (first payment) ...............194
8.6.9 Payment Response Block (first payment) ...............194
8.6.10 Signature Block (Payment Response - first payment) ..195
8.6.11 Payment Request Block (second payment) ..............195
8.6.12 Signature Block (Payment Request - second payment) ..196
8.6.13 Payment Exchange Block (second payment) .............196
8.6.14 Payment Response Block (second payment) .............196
8.6.15 Signature Block (Payment Response - second payment) .197
8.6.16 Baseline Value Exchange Signatures ..................197
8.7 Payment Instrument Customer Care IOTP Transaction.........198
8.7.1 Payment Instrument Customer Care Request Block .......200
8.7.2 Payment Instrument Customer Care Exchange Block ......200
8.7.3 Payment Instrument Customer Care Response Block ......200
8.7.4 Signature Block ......................................200
8.8 Baseline Transaction Status Inquiry IOTP Transaction......201
8.8.1 Which Trading Roles can receive Inquiry Requests .....201
8.8.2 Transaction Status Inquiry Transport Session .........201
8.8.3 Transaction Status Inquiry Error Handling ............202
8.8.4 Inquiry Transaction Messages .........................202
8.8.5 Transaction Reference Block ..........................203
8.8.6 Inquiry Request Block ................................203
8.8.7 Inquiry Response Block ...............................203
8.9 Baseline Ping IOTP Transaction............................204
8.9.1 Ping Messages ........................................204
8.9.2 Transaction Reference Block ..........................205
8.9.3 Ping Request Block ...................................205
8.9.4 Signature Block (Ping Request) .......................206
8.9.5 Ping Response Block ..................................206
8.9.6 Signature Block (Ping Response) ......................206
9. Retrieving Logos..............................................206
9.1 Logo Size.................................................207
9.2 Logo Color Depth..........................................207
9.3 Logo Net Location Examples................................208
10. Brand List Examples..........................................208
10.1 Simple Credit Card Based Example.........................208
10.2 Credit Card Brand List Including Promotional Brands......209
10.3 Brand Selection Example..................................211
10.4 Complex Electronic Cash Based Brand List.................211
David Burdett et al. [Page 6]
Internet Draft IOTP/1.0 23 October 1998
11. XML Overview.................................................213
11.1 Document Definition......................................214
11.2 Element Declaration......................................214
11.2.1 Example 1 ...........................................215
11.2.2 Example 2 ...........................................215
11.2.3 Example 3 ...........................................215
11.2.4 Data Types used in element declarations .............216
11.3 Attribute declarations...................................216
11.3.1 Declared value ......................................216
11.3.2 Default value .......................................217
12. Open Trading Protocol Data Type Definition...................218
13. Glossary.....................................................229
14. Copyrights...................................................232
15. References...................................................233
16. Author's Address.............................................235
David Burdett et al. [Page 7]
Internet Draft IOTP/1.0 23 October 1998
Table of Figures
Figure 1 IOTP Trading Roles ......................................17
Figure 2 Offer Exchange ..........................................19
Figure 3 Payment Exchange ........................................21
Figure 4 Delivery Exchange .......................................24
Figure 5 Authentication Exchange .................................25
Figure 6 IOTP Message Structure ..................................29
Figure 7 An IOTP Transaction .....................................30
Figure 8 Example use of ID attributes ............................40
Figure 9 Element References ......................................41
Figure 10 Server Role Processing Sequence ........................56
Figure 11 Client Role Processing Sequence ........................61
Figure 12 Signature Hashing ......................................65
Figure 13 Example use of Signatures for Baseline Purchase ........66
Figure 14 Checking a Payment Handler can carry out a Payment .....70
Figure 15 Checking a Delivery Handler can carry out a Delivery ...72
Figure 16 Trading Components .....................................75
Figure 17 Brand List Element Relationships .......................91
Figure 18 Trading Blocks ........................................129
Figure 19 Baseline Authentication ...............................149
Figure 20 Baseline Deposit with Authentication ..................153
Figure 21 Baseline Deposit without Authentication ...............154
Figure 22 Baseline Deposit Payment Messages .....................155
Figure 23 Brand Dependent Baseline Purchase .....................161
Figure 24 Brand Independent Baseline Purchase ...................162
Figure 25 Baseline Purchase, Delivery Response Block and Payment
Response Blocks Not Combined .................................163
Figure 26 Baseline Purchase, Delivery Response Block and Payment
Response Block Combined ......................................164
Figure 27 Baseline Purchase, Purchase without Delivery Exchange .166
Figure 28 Baseline Purchase Variations ..........................167
Figure 29 Baseline Refund with Authentication ...................173
Figure 30 Baseline Refund without Authentication ................174
Figure 31 Baseline Refund Payment Messages ......................175
Figure 32 Baseline Withdrawal with Authentication ...............180
Figure 33 Baseline Withdrawal without Authentication ............181
Figure 34 Baseline Withdrawal Payment Messages ..................183
Figure 35 Brand Dependent Value Exchange ........................189
Figure 36 Brand Independent Value Exchange ......................189
Figure 37 Baseline Value Exchange Payment Messages ..............191
Figure 38 Baseline Value Exchange Signatures ....................198
Figure 39 IOTP Payment Instrument Customer Care Transaction Message
Flows ........................................................200
Figure 40 Baseline Transaction Status Inquiry ...................203
Figure 41 Baseline Ping Messages ................................204
David Burdett et al. [Page 8]
Internet Draft IOTP/1.0 23 October 1998
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.
David Burdett et al. [Page 9]
Internet Draft IOTP/1.0 23 October 1998
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.
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
David Burdett et al. [Page 10]
Internet Draft IOTP/1.0 23 October 1998
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
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
David Burdett et al. [Page 11]
Internet Draft IOTP/1.0 23 October 1998
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. The team working on the IOTP see an extended versions of this
specification being developed as needs demand but at this stage feel a
need to develop a limited function but usable specification in order
that technology providers can develop pathway-pilot products that will
be placed in the market in order to understand the real _market
place_ demands and requirements for electronic trading or electronic
commerce. To proceed otherwise would be presumptuous, time consuming,
expensive and foolish.
Accordingly the IOTP Baseline specification has been produced for
pathway-pilot product development, expecting to transact live trades
to prove the interoperability of solutions based on this specification
by end '98.
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
which prove that the basic concepts work.
1.4 Objectives of Document
The objectives of this document are to provide a functional
specification of version 1.0 of the Open Trading Protocols which can
be used to design and implement systems which support electronic
trading on the Internet using the Open Trading Protocols.
An overview of IOTP is provided the IOTP Business Description which
explains the Business Requirements for IOTP.
1.5 Purpose
The purpose of the document is:
o to allow potential developers of products based on the
protocol to start development of 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
David Burdett et al. [Page 12]
Internet Draft IOTP/1.0 23 October 1998
1.6 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, DigiCash, CyberCoin,
Millicent, Proton etc.
Each payment scheme contains some message flows which are specific to
that scheme. These scheme-specific parts of the protocol are contained
in a set of payment scheme supplements to this specification.
The document does not prescribe the software and processes that will
need to be implemented by each participant. It does describe the
framework necessary for trading to take place.
This document also does not address any legal or regulatory issues
surrounding the implementation of the protocol or the information
systems which use them.
1.7 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.
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.
David Burdett et al. [Page 13]
Internet Draft IOTP/1.0 23 October 1998
o Section 5 - Security Considerations: This section describes
security considerations and digital signatures for the XML
elements exchanged between the Trading Roles.
o Section 6 - Trading Components: This section defines the XML
elements required by Trading Components.
o Section 7 - Trading Blocks: This section describes how Trading
Blocks are constructed from Trading Components.
o Section 8 - 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 9 - Retrieving Logos: This section describes how IOTP
specific logos can be retrieved.
o Section 10 - Brand List Examples: This section gives some
examples for Brand List.
o Section 11 - XML Overview: This section gives brief
introduction to XML.
o Section 12 - Open Trading Protocol Data Type Definition: This
section contains the XML Data Type Definitions for IOTP.
o Section 12 - Glossary. This describes all the major
terminology used by IOTP.
1.8 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.8.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 12 - Glossary
o Section 1 - Background
o Section 2 - Introduction
o Section 3 - Protocol Structure
o Section 4 - IOTP Error Handling
o Section 8 - Open Trading Protocol Transactions
o Section 10 - Brand List Examples
o Section 4 - IOTP Error Handling
o Section 9 - Retrieving Logos
David Burdett et al. [Page 14]
Internet Draft IOTP/1.0 23 October 1998
Review the detailed XML definitions:
o Section 11 - XML Overview (if the reader does not know XML)
o Section 7 - Trading Blocks
o Section 6 - Trading Components
1.9 History
Version 0.1 20 February Initial draft for comment
1997
Version 0.2 14 April 1997 Revised draft including changes
arising from comments
Version 0.2a 24 April 1997 Same as version 0-2 with
typographic corrections
Version 0.3 9 October 1997 Revised draft for comment
including revised encoding
approach using [XML]
Version 0.4 31 October 1997 Published draft for limited public
review by groups working within
IOTP dev
Version 0.9 12 January 1998 Revisions following limited public
review _ draft for public comment
only.
Version 0.9.1 20 May 1998 Revisions following public review
- internal IOTP Consortium review.
Version 0.9.9 17 August 1998 Draft published for submission to
IETF for information.
Version 1.0 23 October 1998 Draft published incorporating
comments received on version
0.9.9.
David Burdett et al. [Page 15]
Internet Draft IOTP/1.0 23 October 1998
2. Introduction
The 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 the remote authentication of a
Consumer by another Trading Role using a variety of
authentication methods, and the provision of an Organisation
Component about a Consumer to another Trading Role for use in,
for example the creation of an offer
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 Payment Instrument Customer Care. This supports the provision
of Payment Brand or Payment Method specific customer care of a
Payment Instrument
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.
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 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.
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.
David Burdett et al. [Page 16]
Internet Draft IOTP/1.0 23 October 1998
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 ----------
|
| ----------
| Payment Instrument Customer Care Provider | Payment |
---------------------------------------------->|Instrument|
resolves problems with Payment Instruments |Cust.Care.|
| Provider |
----------
Figure 1 IOTP Trading Roles
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
o Payment Instrument Customer Care Provider. The entity that
resolves problems with a particular Payment Instrument
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,
David Burdett et al. [Page 17]
Internet Draft IOTP/1.0 23 October 1998
request that delivery be made by an overnight courier firm and
to contact an organisation which provides 24x7 service if
problems arise.
Note that in this specification, unless stated to the contrary, when
the words Consumer, Merchant, Payment Handler, Delivery Handler or
Customer Care Provider are used, they refer to the Trading Role rather
than an actual organisation.
An individual organisation may take multiple roles. For example a
company which is selling goods and services on the Internet could take
the role of Merchant when selling goods or services and the role of
Consumer when the company is buying goods or services itself.
As roles occur in different places there is a need for the
organisations involved in the trade to exchange data, i.e. to carry
out Trading Exchanges, so that the trade can be completed.
2.2 Trading Exchanges
The 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.
David Burdett et al. [Page 18]
Internet Draft IOTP/1.0 23 October 1998
Each of the IOTP Trading Exchanges is described in more detail below.
For clarity of description, these describe the Trading Exchanges as
though they were standalone operations. For performance reasons, the
Trading Exchanges are intermingled in the actual IOTP Transaction
definitions.
2.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 OTP MESSAGE MERCHANT
1. Consumer decides to ----------------------> 2. Merchant checks
pay (request an offer) Information on what is the information
and sends information being purchased (Offer provided by the
on what to purchase to Request) (outside scope Consumer, creates
the Merchant using e.g. of OTP) and Offer and sends
HTML it to the Consumer.
|
v
Components: Organisation(s)
3. Consumer checks the (Consumer, DeliverTo, Merchant,
information from the <---------- Payment Handler, Delivery
Merchant and decides Offer Handler, Cust Care); Order; Pay
whether to continue Response Amount; Delivery; Signature
(Offer Response)(which signs
other components)
Figure 2 Offer Exchange
An Offer Exchange uses the following Trading Components that are
passed between the Consumer and the Merchant:
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
- 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
David Burdett et al. [Page 19]
Internet Draft IOTP/1.0 23 October 1998
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 "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 could be 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.
o using the Open Profiling Standard [OPS] which has recently
been proposed,
o in the form of Organisation and 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 OTP MESSAGE MERCHANT
1. Consumer decides to 2. Merchant decides
trade and sends Information on what is which payment brand
information on what to being paid for and protocols to
purchase to the ----------------------> offer, places then
Merchant, e.g. using (outside scope of OTP) in a Brand List
HTML Component and sends
them to the
Consumer.
David Burdett et al. [Page 20]
Internet Draft IOTP/1.0 23 October 1998
|
v
3. Consumer selects the payment <----------------- Brand List
brand and protocol to use, creates a Brand List Component
Brand Selection Component and sends
it to the Merchant
|
v
Brand Selection ----------------> 4. Merchant checks Brand
Brand Selection Selection, creates Payment Amount
Information, optionally signs it
to authorise payment and send it
to the consumer
|
v
5. Consumer checks the Components:
Payment Amount information <-------- Pay Amount; Auth data;
and if OK requests that the Payment Organisation(s) (Merchant &
payment starts by sending Information Payment Handler); Signature
information to the Payment (Offer) (signs other
Handler components)
|
| ========================================
v PAYMENT HANDLER
Components: Pay Scheme; Auth 6. Payment Handler checks
Data; Brand List; Pay Amount; information including
Brand Selection; ----------> optional signature and if
Organisation(s) (Merchant & Payment OK starts exchanging Pay
Payment Handler); Signature Request Scheme Components using
(Offer) (signs all other messages for selected
components except payment brand and payment
------ Pay Scheme) protocol
| | |
| v v
| Component: Pay Scheme <------------------> Component: Pay Scheme
| Payment Exchange
| |
| v
| 7. Eventually payment protocol messages
---------- finish so Payment Handler sends Pay
| Receipt and optional signature to
| Consumer as proof of payment
| |
| v
v Components: Pay Receipt; Pay
8 Consumer checks Pay scheme; Signature (Offer);
Receipt is OK <------- Signature (Pay Receipt)
Payment (signs Pay Receipt and
Response Signature (Offer) components)
Figure 3 Payment Exchange
David Burdett et al. [Page 21]
Internet Draft IOTP/1.0 23 October 1998
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) and payment
protocols (for example SET Version 1.0, Secure Channel Credit
Debit (SCCD - the name used for a credit or debit card payment
where unauthorised access to account information is prevented
through use of secure channel transport mechanisms such as
SSL). The Merchant sends the Brand List to the Consumer. The
consumer compares the payment brands and protocols on offer
with those that the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's
selection. Payment brand, protocol and possibly protocol-
specific information is sent back to the Merchant. This
information may be used to change information in the Offer
Exchange. For example, a merchant could choose to offer a
discount to encourage the use of a store card.
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 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 optional Authentication Data Component contains challenge
data which is used by the payment protocol to authenticate the
consumer. Authentication may not always occur
o The Payment Component contains details of how much to pay, the
currency and the payment direction, and identifies the
Authentication Data Component to use.
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 3 in the diagram)
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 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 Signature. The signature on the offer
digitally signs the Order, Organisation and Delivery
David Burdett et al. [Page 22]
Internet Draft IOTP/1.0 23 October 1998
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 8.3).
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. A future
goal is to have a signed delivery that can be used for customer care
in the case of problems with physical delivery. This is illustrated in
the diagram below.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer decides to ------------> 2. Merchant checks the
trade and sends Information information provided by the
information about what on what is Consumer, adds information
to deliver and who is being about how the delivery will
to take delivery, to delivered occur, information about the
the Merchant, using for (outside organisations involved in the
example, HTML scope of OTP) delivery and optionally signs
it
|
v
3. Consumer checks the Components:
delivery information is OK, Delivery;
obtains authorisation for <----------------- Organisation(s)
the delivery, for example by Delivery Delivery Handler,
making a payment, and sends Information Deliver To; Order;
the delivery information to Signature (Offer)
the Delivery Handler.
|
v
Components: Delivery; 4. Delivery Handler checks
Organisation(s), Merchant, information and
Delivery Handler, DelivTo; --------> authorisation. Starts or
Order; Signature (Offer); Delivery schedules delivery and
Signature (Pay Receipt) Request creates and then sends a
(from Payment Exchange) delivery note to the Consumer
|
v
5. Consumer checks delivery <--------- Component: Delivery
note is OK and accepts or waits Delivery Note
for delivery as described in Response
David Burdett et al. [Page 23]
Internet Draft IOTP/1.0 23 October 1998
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 Organisation Component(s) contain details of the Deliver
To, Delivery Handler and Merchant Roles:
- the Deliver To role indicates where the goods or services are to
be delivered to
- the Delivery Handler role is required so that the Delivery
Handler can check that she is the correct Delivery Handler to do
the delivery
- the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery
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.
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. It
uses a "challenge-response" mechanism. This is illustrated in the
diagram below.
ORGANISATION 1 OTP MESSAGE ORGANISATION 2
1. First organisation, 2. The second
e.g a consumer, takes an organisation generates
action (for example by ----------------> Authentication Data
pressing a button on an Need for containing challenge data
HTML page) which Authentication and the method of
requires that the (outside scope of authentication to be used
organisation is OTP) then sends it to the
authenticated first organisation
David Burdett et al. [Page 24]
Internet Draft IOTP/1.0 23 October 1998
|
v
3. The first organisation uses Component:
the challenge data with the <------------ Authentication Data
specified authentication method Authentication
to generate an Authentication Request
Response which is sent back to
the second organisation
|
v
Component:
Authentication -------------> 4. The Authentication Response is
Response Authentication checked against the challenge data to
Response check that the first organisation is
who they appear to be
Figure 5 Authentication Exchange
An Authentication Exchange uses the following Trading Components that
are passed between the two organisations:
o the Authentication Data Component which contains the challenge
data to be used in the "challenge-response" mechanism and
indicates the authentication method to be used. It is sent by
one organisation to the other.
o the Authentication Response Component which contains the
challenge response generated by the recipient of the
Authentication Data Component. It is sent back to the first
organisation for verification.
2.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.
David Burdett et al. [Page 25]
Internet Draft IOTP/1.0 23 October 1998
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery Pay
Issuer Acquirer Handler Handler Inst.
Cuts
Care
TRANSACTIONS
Purchase Must Must
Refund Must b)
Depends
Authent- May Must May b)
ication Depends
Value May Must
Exchange
Withdrawal Must b)
Depends
Deposit Must b)
Depends
Inquiry Must Must Must Must Must Must Must
Ping Must Must Must Must Must Must Must
Pay Inst. b) Must
Cust. Care Depends
TRADING
BLOCKS
TPO Must Must Must Must
TPO Must Must Must Must
Selection
Auth-Requesta) a) a)
Depends Depends Depends
Auth-Reply a) a) a)
Depends Depends Depends
Offer Must Must Must Must
Response
Payment Must Must
David Burdett et al. [Page 26]
Internet Draft IOTP/1.0 23 October 1998
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery Pay
Issuer Acquirer Handler Handler Inst.
Cuts
Care
Request
Payment Must Must
Exchange
Payment Must Must
Response
Delivery Must Must
Request
Delivery Must Must
Response
Pay Inst. b) Must
Cust Care Depends
Req.
Pay Inst. b) Must
Cust Care Depends
Resp
Inquiry Must Must Must Must Must Must Must
Request
Inquiry Must Must Must Must Must Must Must
Response
Ping RequestMust Must Must Must Must Must Must
Ping Must Must Must Must Must Must Must
Response
Signature Must Must Must Limited Must Must b)
Depends
Error Must 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:
David Burdett et al. [Page 27]
Internet Draft IOTP/1.0 23 October 1998
- if Baseline Authentication IOTP Transaction is
supported;
- 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 Merchant and Payment Instrument
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 such as
o IOTP Signature Components which use digital signature
techniques to preserve the integrity of IOTP Messages and
provide the trust relationships required by IOTP
o how extra XML Elements and new user defined values for
existing IOTP codes can be used when Extending IOTP, and
finally
David Burdett et al. [Page 28]
Internet Draft IOTP/1.0 23 October 1998
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.
OTP MESSAGE <----------- OTP Message - an XML Document which is
| transported between the Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains information which
| | describes the OTP Transaction and the OTP
| | Message.
| |-Trans Id Comp. <--- Transaction Id Component - uniquely
| | identifies the OTP Transaction. The Trans Id
| | Components are the same across all OTP
| | messages that comprise a single OTP
| | transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies and
| describes an OTP Message within an OTP
| 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 hashes of the
| | Trans Ref Block and any Trading Component in
| | any OTP Message in the same OTP Transaction.
| |-Certificate Comp. < Certificate Component. Used to check the
| signature.
|-Trading Block <------- Trading Block - an XML Element within an OTP
| |-Component Message that contains a predefined set of
| |-Component Trading Components
| |-Component
| |-Component <-------- Trading Components - XML Elements within a
| Trading Block that contain a predefined set
|-Trading Block of XML elements and attributes containing
| |-Component information required to support a Trading
| |-Component Exchange
| |-Component
| |-Component
| |-Component
|
|
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
David Burdett et al. [Page 29]
Internet Draft IOTP/1.0 23 October 1998
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
OTP Message
--- |
| | v
Process incoming | I | -------------
OTP Message & <------------- | | -------------- | OTP Message |
generate next OTP | | -------------
Message | N |
| | |
v | |
------------- | T | Process incoming
| OTP Message | -------------- | | -------------> OTP Message &
------------- | | generate next OTP
| E | Message
| | |
| | v
Process incoming | R | -------------
OTP Message <------------- | | -------------- | OTP Message |
generate last OTP | | -------------
Message & stop | N |
| | |
v | |
------------- | E | Process last
| OTP Message | -------------- | | -------------> incoming OTP
------------- | | 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 8) in this version of IOTP are
specifically:
o Purchase. This supports a purchase involving an offer, a
payment and optionally a delivery
David Burdett et al. [Page 30]
Internet Draft IOTP/1.0 23 October 1998
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 a
Consumer by another Trading Role using a variety of
authentication methods, and the provision of an Organisation
Component about a Consumer to another Trading Role for use in,
for example the creation of an offer
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 Payment Instrument Customer Care. This supports the provision
of Payment Brand or Payment Method specific customer care of a
Payment Instrument
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 organisations that are taking
part in a trade.
The XML definition of an IOTP Message is as follows.
David Burdett et al. [Page 31]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayInstCCExchBlk |
PayInstCCReqBlk |
PayInstCCRespBlk
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk |
)*
) >
Content:
TransRefBlk This contains information which describes an
IOTP Message within an IOTP Transaction (see
section 3.3 immediately below)
AuthReqBlk, These are the Trading Blocks.
AuthRespBlk,
DeliveryReqBlk, The Trading Blocks present within an IOTP
DeliveryRespBlk Message, and the content of a Trading Block
ErrorBlk itself is dependent on the type of IOTP
InquiryReqBlk, Transaction being carried out - see the
InquiryRespBlk, definition of each transaction in section 8 Open
OfferRespBlk, Trading Protocol Transactions.
PayExchBlk,
PayReqBlk, Full definitions of each Trading Block are
PayInstCCExchBlk, described in section 7.
PayInstCCReqBlk,
PayInstCCRespBlk
PayRespBlk,
PingReqBlk,
PingRespBlk,
SigBlk,
TpoBlk,
TpoSelectionBlk
David Burdett et al. [Page 32]
Internet Draft IOTP/1.0 23 October 1998
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 OtpMessage >
<OtpMessage>
...
</OtpMessage>
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.
RelatedTo See 3.3.3 Related To Component immediately below.
David Burdett et al. [Page 33]
Internet Draft IOTP/1.0 23 October 1998
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'
OtpTransId NMTOKEN #REQUIRED
OtpTransType CDATA #REQUIRED >
TransTimeStamp CDATA #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP
Transaction.
Version This identifies the version of IOTP, and therefore
the structure of the IOTP Messages, which the IOTP
Transaction is using.
OtpTransId Contains data which uniquely identifies the IOTP
Transaction. It must conform to the rules for
Message Ids in [RFC 822].
OtpTransType This is the type of IOTP Transaction being carried
out. For Baseline IOTP it identifies a "standard"
IOTP Transaction and implies the sequence and
content of the IOTP Messages exchanged between the
Trading Roles. The valid values for Baseline IOTP
are:
o BaselineAuthentication
o BaselineDeposit
o BaselinePurchase
o BaselineRefund
o BaselineWithdrawal
o BaselineValueExchange
o BaselineInquiry
o BaselinePing
o BaselinePayInstrumentCustomerCare
o x-ddd:nnn
A value for OtpTransType of x-ddd:nnn indicates a
user defined transaction type. See section 3.7.3
User Defined Codes.
In later versions of IOTP, this list will be
extended to support different types of standard
IOTP Transaction based on market demand. It is
also likely to support the type Dynamic which
indicates that the sequence of steps within the
David Burdett et al. [Page 34]
Internet Draft IOTP/1.0 23 October 1998
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
RespOtpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the IOTP
Message within the IOTP Transaction (see section
3.4 ID Attributes). Note that if an IOTP Message
is resent then the value of this attribute remains
the same.
RespOtpMsg This contains the ID attribute of the Message Id
Component of the IOTP Message to which this IOTP
Message is a response. In this way all the IOTP
Messages in an IOTP Transaction are unambiguously
linked together. This field is required on every
IOTP Message except the first IOTP Message in an
IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.9 Identifying Languages.
SoftwareId This contains information which identifies the
David Burdett et al. [Page 35]
Internet Draft IOTP/1.0 23 October 1998
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:
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.9 Identifying Languages.
RelationshipType Defines the type of the relationship. Valid values
are:
o OtpTransaction. in which case the Packaged
Content Element contains an OtpTransId of
another IOTP Transaction
o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
o x-ddd:nnn a user defined code (see section
3.7.3)
Relation The Relation attribute contains a phrase in the
David Burdett et al. [Page 36]
Internet Draft IOTP/1.0 23 October 1998
language defined by xml:lang which describes the
nature of the relationship between the IOTP
transaction that contains this component and
another IOTP Transaction or other event. The exact
words to be used are left to the implementer of
the IOTP software.
The purpose of the attribute is to provide the
Trading Roles involved in an IOTP Transaction with
an explanation of the nature of the relationship
between the transactions.
Care should be taken that the words used to in the
Relation attribute indicate the "direction" of the
relationship correctly. For example: one
transaction might be a refund for another earlier
transaction. In this case the transaction which is
a refund should contain in the Relation attribute
words such as "refund for" rather than "refund to"
or just "refund".
RelnKeyWords This attribute contains keywords which could be
used to help identify similar relationships, for
example all refunds. It is anticipated that
recommended keywords will be developed through
examination of actual usage. In this version of
the specification there are no specific
recommendations and the keywords used are at the
discretion of the implementer.
Content:
PackagedContent The Packaged Content (see section 3.8) contains
data which identifies the related transaction. Its
format varies depending on the value of the
RelationshipType.
3.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.
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
David Burdett et al. [Page 37]
Internet Draft IOTP/1.0 23 October 1998
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:
OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix
OtpMsgIdPrefix ::= NameChar (NameChar)*
OtpMsgIdSuffix ::= Digit (Digit)*
OtpMsgIdPrefix Apart from messages which contain an Inquiry
Request Trading Block (see section 7.14), 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, the prefix is set to "I" for
Inquiry.
The prefix for the other roles in a trade is
contained within the Organisation Component for
the role and are typically set by the Merchant.
The following is recommended as a guideline and
must not be relied upon:
o "P" - First (only) Payment Handler
o "R" - Second Payment Handler
o "D" - Delivery Handler
As a guideline, prefixes should be limited to one
character.
NameChar has the same definition as the [XML]
definition of NameChar.
OtpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role within
an IOTP Transaction. The following is recommended
as a guideline and must not be relied upon:
o the first IOTP Message sent by a trading role
David Burdett et al. [Page 38]
Internet Draft IOTP/1.0 23 October 1998
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 ::= OtpMsgId "." IdSuffix
IdSuffix ::= Digit (Digit)*
OtpMsgId The ID attribute of the Message ID Component of
the IOTP Message where the Block or Component is
first used.
In IOTP, Trading Components and Trading Blocks are
copied from one IOTP Message to another. The ID
attribute does not change when an existing Trading
Block or Component is copied to another IOTP
Message.
IdSuffix The suffix consists of one or more digits. The
suffix must be unique within the ID attribute of
the Message ID Component used to generate the ID
attribute. The following is recommended as a
guideline and must not be relied upon:
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]
David Burdett et al. [Page 39]
Internet Draft IOTP/1.0 23 October 1998
definition of Digit.
3.4.3 Example of use of ID Attributes
The diagram below illustrates how ID attribute values are used.
1st OTP MESSAGE 2nd OTP MESSAGE
(e.g. from Merchant to (e.g. from Consumer to
Consumer Payment Handler)
OTP MESSAGE OTP MESSAGE *
|-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| |-Trans Id Comp. ID = M1. ------------->| |-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.3
|-Comp. ID=M1.4 * = new elements
|-Comp. ID=M1.5
|-Comp. ID=M1.6
|-Comp. ID=M1.7
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 hash value is included in a
Signature Component,
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.
David Burdett et al. [Page 40]
Internet Draft IOTP/1.0 23 October 1998
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.
[Note End]
An example of "matching" an Element Reference is illustrated in the
example below.
1st OTP MESSAGE 2nd OTP MESSAGE
(e.g. from Merchant to (e.g. from Consumer to
Consumer Payment Handler)
OTP MESSAGE OTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans Ref Block. ID=C1.1
| |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id 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.6
| |-Comp. ID=M1.7 |-Comp. ID=C1.4
|
|-Trading Block. ID=M1.3
|-Comp. ID=M1.4
|-Comp. ID=M1.5
|-Comp. ID=M1.6
|-Comp. ID=M1.7
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.
[Note End]
David Burdett et al. [Page 41]
Internet Draft IOTP/1.0 23 October 1998
3.6 Brands and Brand Selection
One of the key features of IOTP is the ability for a merchant to offer
a list of Brands from which a consumer may make a selection. This
section provides an overview of what is involved and provides guidance
on how selection of a brand and associated payment instrument can be
carried out by a Consumer. It covers:
o definitions of Payment Instruments and Brands - what are
Payment Instruments and Brands in an IOTP context. Further
categorises Brands as optionally a "Dual Brand" or a
"Promotional Brand",
o identification and selection of Promotional Brands -
Promotional Brands offer a Consumer some additional benefit,
for example loyalty points or a discount. This means that both
Consumers and Merchant must be able to correctly identify that
a valid Promotional Brand is being used.
Also see the following sections:
o Brand List Component (section 6.6) which contains definitions
of the XML elements which contain the list of Brands offered
by a Merchant to a Consumer, and
o Brand Selection Component (section 6.7) for details of how a
Consumer records the Brand that was selected.
3.6.1 Definition of Payment Instrument
A Payment Instrument is the means by which Consumer pays for goods or
services offered by a Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash payment instrument such as
a Mondex Card, a GeldKarte card or a Visa Cash card
o a software based electronic payment account such as a
CyberCash or DigiCash account.
All Payment Instruments have a number, typically an account number, by
which the Payment Instrument can be identified.
3.6.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are
presented by the Merchant to the Consumer and from which the Consumer
makes a selection. Each Brand may have a different Payment Handler.
Examples of Brands include:
o payment association and proprietary Brands, for example
MasterCard, Visa, American Express, Diners Club, American
Express, Mondex, GeldKarte, CyberCash, etc.
o promotional brands (see below). These include:
David Burdett et al. [Page 42]
Internet Draft IOTP/1.0 23 October 1998
- store brands, where the Payment Instrument is issued to a
Consumer by a particular Merchant, for example Walmart, Sears,
or Marks and Spencer (UK)
- cobrands, for example American Advantage Visa, where an
organisation uses their own brand in conjunction with,
typically, a payment association Brand.
3.6.3 Definition of Dual Brand
A Dual Brand means that a single payment instrument may be used as if
it were two separate Brands. For example there could be a single
Japanese "UC" MasterCard which can be used as either a UC card or a
regular MasterCard. The UC card Brand and the MasterCard Brand could
each have their own separate Payment Handlers. This means that:
o the merchant treats, for example "UC" and "MasterCard" as two
separate Brands when offering a list of Brands to the
Consumer,
o the consumer chooses a Brand, for example either "UC" or
"MasterCard,
o the consumer IOTP aware application determines which Payment
Instrument(s) match the chosen Brand, and selects, perhaps
with user assistance, the correct Payment Instrument to use.
[Note] Dual Brands need no special treatment by the Merchant and
therefore no explicit reference is made to Dual Brands in
the DTD. This is because, as far as the Merchant is
concerned, each Brand in a Dual Brand is treated as a
separate Brand. It is at the Consumer, that the matching of
a Brand to a Dual Brand Payment Instrument needs to be done.
[Note End]
3.6.4 Definition of Promotional Brand
A Promotional Brand means that, if the Consumer pays with that Brand,
then the Consumer will receive some additional benefit which can be
received in two ways:
o at the time of purchase. For example if a Consumer pays with a
"Walmart MasterCard" at a Walmart web site, then a 5% discount
might apply, which means the consumer actually pays less,
o from their Payment Instrument (card) issuer when the payment
appears on their statement. For example loyalty points in a
frequent flyer scheme could be awarded based on the total
payments made with the Payment Instrument since the last
statement was issued.
Note that:
o the first example (obtaining the benefit at the time of
purchase), requires that:
- the Consumer is informed of the benefits which arise if that
Brand is selected
David Burdett et al. [Page 43]
Internet Draft IOTP/1.0 23 October 1998
- if the Brand is selected, the Merchant changes the relevant IOTP
Components in the Offer Response to reflect the correct amount
to be paid
o the second (obtaining a benefit through the Payment Instrument
issuer) does not require that the Offer Response is changed
o each Promotional Brand should be identified as a separate
Brand in the list of Brands offered by the Merchant. For
example: "Walmart", "Sears", "Marks and Spencer" and "American
Advantage Visa", would each be a separate Brand.
3.6.5 Identifying Promotional Brands
There are two problems which need to handled in identifying
Promotional Brands:
o how does the Merchant or their Payment Handler positively
identify the promotional brand being used at the time of
purchase
o how does the Consumer reliably identify the correct
promotional brand from the Brand List presented by the
Merchant
The following is a description of how this could be achieved.
[Note] Please note that the approach described here is a model
approach that solves the problem. Other equivalent methods
may be used.
[Note End]
3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a Promotional
Brand is important since a Consumer might fraudulently claim to have a
Promotional Brand that offers a reduced payment amount when in reality
they do not.
Two approaches seem possible:
o use some feature of the Payment Instrument or the payment
method to positively identify the Brand being used. For
example, the SET certificate for the Brand could be used, if
one is available, or
o use the Payment Instrument (card) number to look up
information about the Payment Instrument on a Payment
Instrument issuer database to determine if the Payment
Instrument is a promotional brand
Note that:
o the first assumes that SET is available.
o the second is only possible if the Merchant, or alternatively
the Payment Handler, has access to card issuer information.
David Burdett et al. [Page 44]
Internet Draft IOTP/1.0 23 October 1998
IOTP does not provide the Merchant with Payment Instrument information
(e.g. a card or account number). This is only sent as part of the
encapsulated payment protocol to a Payment Handler. This means that:
o the Merchant would have to assume that the Payment Instrument
selected was a valid Promotional Brand, or
o the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the
payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer.
3.6.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand
are:
o the Consumer visually matching a logo for the Promotional
Brand which has been provided to the Consumer by the Merchant,
o the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered against
a similar code contained in the list of Brands offered by the
Merchant.
In the latter case, the code contained in the Consumer wallet must
match exactly the code in the list offered by the Merchant otherwise
no match will be found. Ways in which the Consumer's IOTP Aware
Application could obtain such a code include:
o the Consumer types the code in directly. This is error prone
and not user friendly, also the consumer needs to be provided
with the code. This approach is not recommended,
o using some information contained in the software or other data
associated with the Payment Instrument. This could be:
- a SET certificate for Brands which use this payment method
- a code provided by the payment software which handles the
particular payment method, this could apply to, for example,
GeldKarte, Mondex, CyberCash and DigiCash
o the consumer making a initial "manual" link between a
Promotional Brand in the list of Brands offered by the
Merchant and an individual Payment Instrument, the first time
the promotional brand is used. The IOTP Aware application
would then "remember" the code for the Promotional Brand for
use in future purchases
[Note] It is not the intention of the developers of this
specification to develop a prescriptive list of payment
brands. It is anticipated that owners of brands will develop
distinctive names for Brands which should mean that name
clashes are unlikely.
[Note End]
David Burdett et al. [Page 45]
Internet Draft IOTP/1.0 23 October 1998
3.7 Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting IOTP
must be able to accept. As new versions of IOTP are developed,
additional types of IOTP Transactions will be defined. In addition to
this, Baseline and future versions of IOTP will support user
extensions to IOTP through two mechanisms:
o extra XML elements, and
o new user-defined values for existing IOTP codes.
3.7.1 Extra XML Elements
The XML element and attribute names used within IOTP constitute an
[XML Namespace]. This allows IOTP to support the inclusion of
additional XML elements within IOTP messages through the use of [XML
Namespaces].
[Note] In drafts of the [XML] specification, the concept of
"Namespaces" have been discussed. However they are not
present in the XML documentation submitted for approval (see
XML draft dated 8 December 1997) although it appears as if
they may be included in version 1.1 of XML. It is considered
by the authors of this document that IOTP would be an ideal
example of a Namespace so that other XML elements with
potentially the same name can be included unambiguously in
XML documents which conform to this specification. If
Namespaces, or an equivalent, is not developed for XML as a
whole then IOTP is likely to propose its own equivalent. The
Views of other organisations on this topic are sought.
[Note End]
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]. This means that:
- the namespace must be declared to the XML parser
- each element must have a start and end tags which conform 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.
David Burdett et al. [Page 46]
Internet Draft IOTP/1.0 23 October 1998
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 must fail. See section 6.19 Error Component.
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:
- 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 hashed 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.7.2 Opaque Embedded Data
If IOTP is to be extended using Opaque Embedded Data then a Packaged
Content Element (see section 3.8) should be used to encapsulate the
data.
3.7.3 User Defined Codes
User defined codes provide a simple way to identify additional values
for the codes contained within this specification.
The definition of a user defined code is as follows:
user_defined_code ::= ( "x-" | "X-" ) domain_name ":" name
domain_name A name which identifies the organisation which is
creating the user defined code (see [DNS]). The
purpose of this field is to reduce the probability of
two organisations creating the same user-defined name
name A name specified by the organisation which owns the
domain_name which identifies the user defined code
within the domain_name.
David Burdett et al. [Page 47]
Internet Draft IOTP/1.0 23 October 1998
User defined codes are identified in this specification as "x-
ddd:nnn". The values of User Defined Codes must conform to the rules
for the specific code (see explanations of the individual codes).
3.8 Packaged Content Element
The Packaged Content element supports the concept of an embedded data
stream, transformed to both protect it against misinterpretation by
transporting systems and to ensure XML compatibility. Examples of its
use in IOTP include:
o to encapsulate payment scheme messages, such as SET messages,
o to encapsulate a description of an order.
In general it is used to encapsulate any data stream.
This data stream has two standardised attributes that allow for
decoding and interpretation of the contents. Its definition is as
follows.
<!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent
Content CDATA "PCDATA"
Transform (NONE|BASE64) "NONE" >
Attributes:
Content This identifies what type of data is contained
within the Content of the Packaged Content
Element. The valid values for the Content
attribute are as follows:
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.
o XML. The content of the Packaged Content
Element can be treated as an XML document.
Entities and CDATA sections, or Transform set to
David Burdett et al. [Page 48]
Internet Draft IOTP/1.0 23 October 1998
BASE64, must be used to ensure that the Packaged
Content Element contents are legitimate PCDATA.
o x-ddd:usercode. The content is private, where
ddd represents a domain name of a user, and
usercode represents a particular content format
defined by that user. The guidelines around a x-
ddd are very loose. Given company FFGGHH Inc.,
all of x-www.ffgghh.com, x-ffgghh.comand and
x-ffgghh are legitimate examples. However, only
one should be the correct format, as defined by
FFGGHH Inc.
Transform This identifies the transformation that has been
done to the data before it was placed 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.9 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.
David Burdett et al. [Page 49]
Internet Draft IOTP/1.0 23 October 1998
xml:lang attributes which follow these principles are included in the
Trading Components and their child XML elements defined in section 6.
3.10 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], and
o "Insecure" Net Locations where privacy of data is not assured.
Where both types of net location are present, the following rules
apply:
o either a Secure Net Location or an Insecure Net Location or
both must be present
o if only one of the two Net Locations is present, then the one
present must be used
o if both are present, then the either may be used depending on
preference the preference of the sender of the message.
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 a several interrelated considerations in
handling errors, re-transmissions, duplicates, and the like. These
factors mean IOTP aware applications must manage message flows more
complex than the simple request/response model. Also a wide variety of
errors can occur in messages as well as at the transport level or in
Trading Blocks or Components.
This section describes at a high level how IOTP handles errors,
retries and idempotency. It covers:
o the different types of errors which can occur. This is divided
into:
- "technical errors" which are independent of the meaning of the
IOTP Message,
- "business errors" which indicate that there is a problem
specific to the process (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.
David Burdett et al. [Page 50]
Internet Draft IOTP/1.0 23 October 1998
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 6.19) in an Error
Block (see section 7.19) sent by the party which detected the error in
an IOTP message to the party which sent the erroneous message.
If communications too poor, a message which was sent may not reach its
destination. In this case a time-out might occur.
The Error codes associated with Technical Errors are recorded in Error
Components (see section 6.19) 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 6.15) of a "response
block" of the normal type, for example a Payment Response Block or a
Delivery Response Block. This allows whatever additional response
related information is needed to accompany the error indication.
Business errors must usually be presented to the user so that they can
decide what to do next. For example, if the error is insufficient
funds in a Brand Independent Purchase (see section 8.3.1), 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.
David Burdett et al. [Page 51]
Internet Draft IOTP/1.0 23 October 1998
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 be received are transport
dependent and the documentation for appropriate IOTP Transport
supplement should be consulted for errors and appropriate actions.
Appropriate time outs to use are a function of both the transport
being used and of the payment system if the request encapsulates
payment information. The transport and payment system specific
documentation should be consulted for time out and automatic retry
parameters. Frequently there is no way to directly inform the other
party of transport level errors but they should generally be logged
and if automatic recovery is unsuccessful and there is a human user,
the user should be informed.
4.3.2 Message Level
This level of error indicates a fundamental technical problem with an
entire IOTP message. For example, the XML is not Well formed, or the
message is too large for the receiver to handle or there are errors in
the Transaction Reference Block (see section 3.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 an
Error Component (see section 6.19) 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 6.19.2 Error Codes) that are Message
Level errors are:
David Burdett et al. [Page 52]
Internet Draft IOTP/1.0 23 October 1998
o XML not well formed. The document is not well formed XML (see
[XML])
o XML not valid. The document is not valid XML (see [XML])
o block level technical errors (see section 4.3.3) on the
Transaction Reference Block (see section 3.3) and the
Signature Block only. This should only be carried out if the
XML is valid
Note that checks on the Signature Block includes checking, where
possible, that each Signature Component is correctly calculated. If
the Digital Signature Element is incorrectly calculated then the data
that should have been covered by the signature can not be trusted and
must be treated as erroneous. A description of how to check a
signature is correctly calculate is contained in section 5.2 Checking
a Signature is Correctly Calculated.
4.3.3 4Block Level
A Block level error indicates a problem with a block or one of its
components in an IOTP message (apart from Transaction Reference or
Signature Blocks). The message has been transported properly, the
overall message structure and the block/component(s) including the
Transaction Reference and Signature Blocks are meaningful but there is
some error related to one of the other blocks.
Block level errors can be either:
o technical errors, or
o business errors
Technical Errors are further divided into:
o Block Level Attribute and Element Checks, and
o Block and Component Consistency Checks
If a technical error occurs related to a block or component, then an
Error Component is returned and, unless it is merely a warning, the
usual response block is suppressed.
4.3.3.1 Block Level Attribute and Element Checks
Block Level Attribute and Element Checks occur only within the same
block. Checks which involve cross-checking against other blocks are
covered by Block and Component Consistency Checks.
The Block Level Attribute & Element checks are:
o checking that each attribute value within each element in a
block conforms to any rules contained within this IOTP
specification
o checking that the content of each element conforms to any
rules contained within this IOTP specification
David Burdett et al. [Page 53]
Internet Draft IOTP/1.0 23 October 1998
o if the previous checks are OK, then cross-checking attribute
values and element content against other attribute values or
element content within any other components in the same block.
4.3.3.2 Block and Component Consistency Checks
Block and Component Consistency Checks consist of:
o checking that the combination of blocks and/or components
present in the IOTP Message are consistent with the rules
contained within this IOTP specification
o checking for consistency between attributes and element
content within the blocks within the same IOTP message.
o checking for consistency between attributes and elements in
blocks in this IOTP message and blocks received in earlier
IOTP messages for the same IOTP transaction
4.3.3.3 Block Business Errors
If a business error occurs in a process such as a Payment or a
Delivery, then the usual type of response block is returned. The
Status Component (see section 6.15) within that response block
indicates the error and its severity. No Error Component or Error
Block is generated for business errors.
4.4 Idempotency, Processing Sequence, and Message Flow
IOTP messages are actually a combination of blocks and components as
described in 3.1.1 IOTP Message Structure. Especially in future
extensions of IOTP, a rich variety of combinations of such blocks and
components can occur. It is important that the multiple
transmission/receipt of the "same" request for state changing action
not result in that action occurring more than once. This is called
idempotency. For example, a customer paying for an order would want to
pay the full amount only once. Most network transport mechanisms have
some probability of delivering a message more than once or not at all,
perhaps requiring retransmission. On the other hand, a request for
status can reasonably be repeated and should be processed fresh each
time it is received.
Correct implementation of IOTP can be modelled by a particular
processing order as detailed below. Any other method that is
indistinguishable in the messages sent between the parties is equally
acceptable.
David Burdett et al. [Page 54]
Internet Draft IOTP/1.0 23 October 1998
4.4.1 Server Role Processing Sequence
"Server roles" are any Trading Role which is not the Consumer role.
They are "Server roles" since they typically receive a request which
they must service and then produce a response.
The model processing sequence for a Server role is indicated in the
diagram below.
-------------
| Input |
| OTP Message |
-------------
|
v
1. Check for transport -------------->
or message level errors Errors |
|OK |
v |
11. Generate output <-------2. More Blocks <------------------ +-
message No to process? | |
| |Yes | |
v v | |
------------- 3. Check Block OK ---------------> | |
| Output | | Errors | |
| OTP Message | |Checks OK | |
------------- v | |
----- ---4. Type of Block ? ------- | |
| | | | | |
----- ---Status Action Encapsulating Error | |
| Request Request Block Block | |
| | | | | |
| v v v | |
| 6a. Action 7. Process 8.Error | |
| Request - encapsulated Block ? | |
| received message and | | |
| before?-- generate -- v | |
| | | response | STOP ---- |
| |Yes |No OK| | | |
| v v | |Errors v |
| 6b. Processing 6e. Process Action | ------> 9. Gen |
| of Block Request & generate-+--------->Error |
| Complete ?- response block- | Errors Block & |
| | | ^ | | store |
| | | | | | | |
| |Yes |No | Ok or | | | |
| | --- | Warning | -------- | |
v v v | v | | |
5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | |
Status and resend process request & | | |
Response previous completion response | | |
Block Block block | | |
| | | v v |
David Burdett et al. [Page 55]
Internet Draft IOTP/1.0 23 October 1998
---------------------------------------------- 10. Add block--
to output
message
Figure 10 Server Role Processing Sequence
Each of the processes in the sequence is described in more detail
below.
4.4.1.1 Check for Transport or Message Level Error
On receipt of an IOTP request message (step 1), first check for
transport or message level errors (see sections 4.3.1 and 4.3.2).
These are errors which indicate that the entire message is corrupt and
can not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information in
the message can not be reliably accessed.
If the OtpTransId attribute in the Transaction Id Component (see
section 3.3.1) can be determined, set up a response message with an
appropriate Error Component. Perform local actions such as making log
entries.
If the value of the OtpTransId attribute is not recognised as
belonging to an IOTP transaction when other Blocks in the IOTP Message
indicate that it should be recognised, then report the error using an
Error Component with a Severity of HardError, an ErrorCode set to
AttValNotRecog (attribute value not recognised), and an Error Location
element (see section 6.19.3) that points to the OtpTransId attribute.
No idempotency related actions are necessary.
4.4.1.2 Process all the blocks
If there are no message level errors, process each of the blocks
within the message which has not been processed (step 2).
Once all the blocks have been processed, generate a response message
(step 11) and send it to the requester unless there are fatal
transport level problems. As recommended for the particular transport
used, a limited number of automatic response retransmission attempts
may be appropriate.
It may be desirable to log the complete response message at the
server. Failure of the requester to receive a response may lead to a
time-out and a retransmission of the request. Following the procedures
above, a duplicate request message should produce a duplicate of the
David Burdett et al. [Page 56]
Internet Draft IOTP/1.0 23 October 1998
previous response except for changes in status and transient error
conditions that have changed.
4.4.1.3 Check the Block is OK
Check the block is OK (see section 4.3.3). For each block level error
found, an appropriate Error Component should be created to be included
in the IOTP Message sent back to the Consumer. Note that some checking
of the Transaction Reference Block and the Signature Block has
occurred as part of Message Level error checking.
If one or more of the Error Components contain a Severity attribute
with a value of TransientError or HardError, then no response block
need be generated and no further processing of the block, including
idempotency related actions are necessary.
4.4.1.4 Determine the Type of the Block
Trading Blocks that survive the above steps and thus have no errors,
or at worst have added a warning error component to the response, can
receive further processing. The nature of the processing depends (step
4) on whether the block is a Status Request, Action Request, an Error
Block or contains an Encapsulated Message.
4.4.1.5 Status Request Blocks
Status Request Blocks (step 5) are either:
o Inquiry Request Trading Block (see section 7.14), or
o Ping Request Block (see section 7.16).
These status requests do not change state and are processed fresh to
get the current status. The appropriate response block should be added
to the IOTP message being composed.
No idempotency actions are required.
4.4.1.6 Action Request Blocks
Blocks which request an action and change state need to be subject to
idempotency duplicate filtering by checking to see if the same block
for the same transaction has been previously stored (step 6a) at the
server as described later.
If the Block has been received previously then:
David Burdett et al. [Page 57]
Internet Draft IOTP/1.0 23 October 1998
o if processing of the previously stored block is complete (step
6b) then the same IOTP Block as previously produced must be
included for resending to the Consumer (step 6c).
o if processing is not complete, wait until the processing is
complete (step 6d) before sending the response.
If the block has not been received before, the action request is
processed normally (step 6e) producing a response block that is added
to the response message. This might or might not indicate a business
error.
If there is a transient error indicated by an Error Component that
contains a Severity attribute set to TransientError, then apart from
sending the Error Block, no further actions should be taken so the
action can be retried.
If there is no Transient Error, then the transaction id, the request
block, and the response block must be stored (step 6f) so they can be
found as described above (step 6a) should a duplicate IOTP action
request block be received for this transaction in the future.
[Note] Most business errors should be labelled as a TransientError
as there is usually some possibility they will be corrected
over time or some user action exists that can fix them.
Requesters are expected to understand business errors and
the appropriate time scale for user actions for retrying.
[Note End]
4.4.1.7 Encapsulating Blocks
Blocks which encapsulate a payment protocol (step 7) pass along the
enclosed information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is thus
up to the payment system involved to handle error detection and
idempotency. Payment systems adapted for the Internet include
idempotency handling because duplicates are always possible. Should a
payment system have no idempotency handling, a layer between IOTP and
the payment system must be added to take care of this.
No IOTP level idempotency actions are required for encapsulating
blocks. The payment system must return material to be encapsulated in
the IOTP response message along with indications as to whether the
exchange will continue or this is the final response and an indication
whether an error occurred. If a payment protocol error has occurred,
an Error Component is added to the response block.
David Burdett et al. [Page 58]
Internet Draft IOTP/1.0 23 October 1998
4.4.1.8 Error Block Received
An error block (step 8) should not occur in a request and should be
treated as an unexpected element with a Severity of HardError. No
response to the block should be made in order to avoid the risk of
loops.
[Note] Consumers should send Error Blocks to a server specified in
the ErrorNetLocn attribute of the appropriate Trading Role
element as a response to the detection of an error in an
IOTP Message that has been received (see section 4.4.1.9
Generate Error Block). This may be the same server as is
used to accept IOTP Messages which contain no error. In this
case, the error block must not considered as a fatal error.
[Note End]
4.4.1.9 Generate Error Block
If any of the previous steps resulted in an error being detected and
an Error Component being created then generate an Error Block (step 9)
containing the Error Components that describe the error(s).
Unless the error is a "Transient Error", the Error Component(s) and
the request block which caused the Error Components to be generated
should be stored so that it can be reused if the action request is
received again (step 6a).
"Transient Errors" are not stored so that if the original Response
Block is received again, then it can be processed as if it had never
been received before.
4.4.1.10 Add Block to Output Message
Any Blocks which have been created as a result of processing the block
received are added to the output message.
4.4.2 Client Role Processing Sequence
The "Client role" in IOTP is the Consumer Trading Role.
[Note] A company or organisation that is a Merchant, for example,
may take on the Trading Role of a Consumer when making a
purchase or downloading or withdrawing electronic cash.
[Note End]
The model processing sequence for a Client role is indicted in the
diagram below.
David Burdett et al. [Page 59]
Internet Draft IOTP/1.0 23 October 1998
-------------
| Input |
| OTP Message |
-------------
|
v
1. Check for transport -->
or message level errors |Errors
|OK |
v |
11.Blocks to be sent?<---------2. More Blocks <-- --------------------
| |No No to process? | ^
Yes| v |Yes | |
v STOP v | |
12. Generate 3. Check Block OK - -->| |
output message | |Errors |
| |Checks OK | |
v v | |
------------- ------ 4. Type of Block ? -----| |
| Output | | | | | | |
| OTP Message | | ---- | | | |
------------- | | | | | |
------------ | | | | |
| -- | | | |
v v v v | |
Status Action Encapsulating Error | |
Request Response Block Block | |
| | | | | |
| v v v | |
| 6a. Action 7. Process 8a.Error Block---- > Transient |
| Response encapsulated severity ? | Error |
| received message |Hard Error | (retry) |
| before ? | | | | | |
| Yes| |No Ok| | v | WAIT |
| (Ig-| | | | STOP | | |
| nore|) v | | v v |
| | 6b. Process | ----- -> 9. Generate 8b. |
| | Action | Errors Error Block Retrieve |
| | Response---+-------- --> & store and resend |
| | Block | Errors | previous |
| | |Ok | | Block(s) |
| | v v | | |
| | 6c. New | | |
| | request | | |
| | required ? | | |
| | No| |Yes 6d. Generate | | |
| | | ---- > Request | | |
| | | Block & Store v v |
v | | | 10. Add Block to |
----------+-------+-------------------------> output message |
v v |
-------------------------------------------------->
David Burdett et al. [Page 60]
Internet Draft IOTP/1.0 23 October 1998
Figure 11 Client Role Processing Sequence
Each of the processes in the sequence is described in more detail
below.
4.4.2.1 Check for Transport or Message Level Error
On receipt of an IOTP response message (step 1), first check for
transport or message level errors (see sections 4.3.1 and 4.3.2).
These are errors which indicate that the entire message is corrupt and
can not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information in
the message can not be reliably accessed. Set up an error indication
message with an Error Component indicating the error.
If the value of the OtpTransId attribute is not recognised as
belonging to an IOTP transaction when other Blocks in the IOTP Message
indicate that it should be recognised, then report the error using an
Error Component with a Severity of HardError, an ErrorCode set to
AttValNotRecog (attribute value not recognised), and an Error Location
element (see section 6.19.3) that points to the OtpTransId attribute.
On failure to receive an expected response message, the time out
strategy indicated in the documentation for the transport method being
used should be followed. This may include some number of automatic
retransmissions of the request. If a user is present, they may be
offered options of continuing to retransmit the request or of
cancelling the transaction.
4.4.2.2 Process all the blocks
If there are no message level errors, process each of the blocks
within the message which has not been processed (step 2).
Once all the blocks have been processed, check to see if there are any
blocks to be sent (step 11). There may be no blocks to send if the
last response message received was the last message of the
transaction.
If blocks are to be sent then generate a request message (step 12) and
send it to the server. It may be desirable to log the complete request
message at the client. Failure of the server to receive a response may
lead to a time-out and a retransmission of the request.
David Burdett et al. [Page 61]
Internet Draft IOTP/1.0 23 October 1998
4.4.2.3 Check the Block is OK
If there are no message level errors process each of the blocks within
the message (step 2).
Check the block is OK (see section 4.3.3). For each block level error
found, an appropriate Error Component should be created to be included
in an Error Component sent back to the Server.
If one or more of the Error Components contain a Severity attribute
with a value of TransientError or HardError, no further processing of
the block should occur and it is likely that this will result in
termination of the transaction.
4.4.2.4 Determine the Type of the Block
Trading Blocks that survive the above steps and thus have no errors,
or at worst have added a warning error component to the error
indication message, can receive further processing. The nature of the
processing depends (step 4) on whether the block is a Status Response,
Action Response, an Error Block or contains an Encapsulated Message.
4.4.2.5 Status Response Blocks
Status Response Blocks (step 4) are either:
o Inquiry Response Trading Blocks (see section 7.15), or
o Ping Response Blocks (see section 7.17)
In general, such blocks should be considered a status update. The best
action to take at the requester may depend on whether this is in
response to a user originated or automatic status request, whether a
status display that could be updated is being presented to the user,
and whether the status response block shows a change in status from a
previous response block for the same type of status. Thus client
detection of duplication in successive status response blocks may be
useful.
4.4.2.6 Action Response Blocks
Check to determine if the Block has been received previously (step
6a). If it has then it should be ignored.
These indicate an action taken at the server in response to an action
request block or a business error. If the response indicates success
the block should be processed (step 6b) and, if required by the
transaction (step 6c) , another Action Request Block generated and
stored (step 6d).
David Burdett et al. [Page 62]
Internet Draft IOTP/1.0 23 October 1998
The Response Block should always be stored with the transaction id and
until the transaction is terminated. If the Response Block indicates a
transient business error, appropriate manually chosen or automatic
steps to fix the problem or cancel the transaction should be provided.
4.4.2.7 Encapsulating Blocks
Blocks which encapsulate a payment protocol (step 7) pass along the
enclosed information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is up
to the payment system involved to handle error detection and
idempotency. Payment systems adapted for the Internet include
idempotency handling because duplicates are always possible. Should a
payment system have no idempotency handling, a layer between IOTP and
the payment system must be added to take care of this.
No IOTP level idempotency actions are required for encapsulating
blocks. The payment system must return an indication of whether an
error occurred. In addition, for a continuing exchange, it must return
material to be encapsulated in the next IOTP request/exchange (step
6d). If the response was a final response for that payment exchange
and there was an error, the payment system may optionally return
material to be encapsulated in the error indication.
4.4.2.8 Error Block
An error block in a response (step 8a) indicates some problem was
detected by the server. If all of the error components are warnings,
they may be optionally logged and/or presented to the user.
Transient errors may be used to provide a manual or automatic
resending (step 8b) of a block previously stored or alternatively may
result in transaction cancellation. Hard errors will always terminate
the transaction, unless they are in optional blocks, with appropriate
indication to he user.
4.4.2.9 Generate Error Block
If an error indication message was created above, try to send it to
the server unless all of the error components are of the warning
severity in which case attempted transmission to the server is
optional.
[Note] To avoid error message loops, such an error indication from
a requester must be sent to the Error Net Location specified
in the Trading Role Element (see section 6.5.2) for the
David Burdett et al. [Page 63]
Internet Draft IOTP/1.0 23 October 1998
Organisation that is the server. Any errors encountered in
sending such an error indication should be, at most, logged
and must not result in any further attempts to transmit any
error indication.
[Note End]
4.4.2.10 Add Block to Output Message
Any Blocks which have been created as a result of processing the block
received are added to the output message.
5. Security Considerations
This section considers the security associated with IOTP. It covers:
o an overview of how IOTP uses digital signatures
o how to check a signature is correctly calculated
o how Payment Handlers and Delivery Handlers check they can
carry out payments or deliveries on behalf of a Merchant.
o how IOTP handles data integrity and privacy
5.1 Digital Signatures and IOTP
In general, signatures when used with IOTP:
o are always treated as a IOTP Components (see section 6)
o hash one or more IOTP Components or Trading Blocks, possibly
including other Signature Components, in any IOTP message
within the same IOTP Transaction
o identify:
- which Organisation signed (generated) the signature, and
- which Organisation(s) should verify the signature in order to
check that the Action the Organisation should take can occur.
The way in which Signatures Components hash one or more elements is
illustrated in the figure below.
OTP MESSAGE SIGNATURE COMPONENT
OTP MESSAGE OtpSignature Id = P1.3
|-Trans Ref Block hash TransRefBlk |-SignedData
| | ID=P1.1-------- ---------------------|->|-Hash of P1.1---
| |-Trans Id Comp hash TransIdComp | | |
| | ID = M1.2------- ---------------------|->|-Hash of M1.2---|
| |-Msg Id Comp. hash element | | |
| | ID = P1 -------------------|->|-Hash of M1.5---|
| | hash element | | |
|-Signature Block | -----------------|->|-Hash of M1.7---|
David Burdett et al. [Page 64]
Internet Draft IOTP/1.0 23 October 1998
| | ID=P1.2 | | hash element | | |
| |-Sig Comp. ID=P1.3 | | ---------------|->|-Hash of C1.4---|
| |-Sig Comp. ID=M1.5--- - | | | |
| |-Cert Comp. ID=P1.4 | | CertRef Iden- -DigSig |
| |-Cert Comp. ID=M1.6<- ---|-|---------------------CertRef=M1.6 |
| | | | tifies Certs Content: |
|-Trading Block. ID=P1.5 | | to use JtvwpMdmSfMbhK<-
| |-Comp. ID=M1.7------- --- | r1Ln3vovbMQttbBI
| | | J8pxLjoSRfe1o6k
| |-Comp. ID=P1.6 | OGG7nTFzTi+/0<--
| | | |
| |-Comp. ID=C1.4------- ----- Digital signature of-
| |-Comp. ID=C1.5 SignedData element
using certificate
identified by CertRef
Elements signed can be in any OTP Message
within the same OTP Transaction
Figure 12 Signature Hashing
[Note] The classic example of one signature signing another in
IOTP, is when an Offer is first signed by a Merchant
creating an "Offer Response" signature, which is then later
signed by a Payment Handler together with a record of the
payment creating a "Payment Receipt" signature. In this way,
the payment in an IOTP Transaction is bound to the
Merchant's offer.
[Note End]
The detailed definitions of how signatures are created is contained in
the paper "Digital Signature for XML - Proposal", see [XMLSIG]. That
document should be read in conjunction with this section.
The remainder of this section contains:
o an example of how IOTP uses signatures
o how the SignerOrgRef and VerifierOrgRef attributes within a
Signature Component are used to identify the organisations
associated with the signature
o how signatures may use either Symmetric or Asymmetric
Cryptography
o Mandatory and Optional use of Signatures by IOTP, and
o how IOTP uses signatures to prove actions complete
successfully
5.1.1 IOTP Signature Example
An example of how signatures are used is illustrated in the figure
below which shows how the various components and elements in a
Baseline Purchase relate to one another. Refer to this example in the
later description of how signatures are used to check a payment or
delivery can occur (see section 5.3).
David Burdett et al. [Page 65]
Internet Draft IOTP/1.0 23 October 1998
[Note] A Baseline Purchase transaction has been used for
illustration purposes. The usage of the elements and
attributes is the same for all types of IOTP Transactions.
[Note End]
TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK
(Offer Response)
Brand Selection Organisation<--- Signer Signature
Component Component | OrgRef Component
| | ----------(Offer
|BrandList -Trading Role Response)
| Ref Element |
v (Merchant) |
Brand List |
>Component |
| |-Protocol ------> Organisation<-------------- |-Dig Sig
| | Amount Elem | Component Verifier | | Element
| | | | | OrgRef -|-(Payment
| | Pa|Protocol |Action -Trading Role | Handler)
| | | Ref |OrgRef Element |
| | v | (Payment Handler) |
| -PayProtocol-- |
| Elem ->Organisation<------------- |-Dig Sig
| | Component Verifier | | Element
| | | OrgRef -|-(Delivery
| | -Trading Role | Handler)
| | Element |
| | (Delivery Handler) -SignedData
| | Element ^
| OFFER RESPONSE BLOCK |
| | Contains hashes of:-----
|BrandListRef |ActionOrgRef -Trans Ref Block (not
| | shown)
--Payment ---Delivery -Transaction Id Component
Component Component (not shown)
-Org Components (Merchant,
Payment Handler,
Delivery Handler
-Brand List Component
-Order Component
-Payment Component
-Delivery Component
-Brand Selection Component
(if Brand Dependent)
Figure 13 Example use of Signatures for Baseline Purchase
5.1.2 SignerOrgRef and VerifierOrgRef Attributes
The SignerOrgRef attribute on the Signature Component contains an
Element Reference (see section 3.5) that points to the Organisation
David Burdett et al. [Page 66]
Internet Draft IOTP/1.0 23 October 1998
Component of the Organisation which generated the Signature. In this
example its the Merchant.
Note that the type of the Signature Component must match the Trading
Role of the Organisation which signed it. If it does not, then it is
an error. Valid combinations are given in the table below.
Signature Valid
Component Trading
Type Role
OfferResponse Merchant
PaymentResponse PaymentHandler
The VerifierOrgRef attribute on the DigSig elements, contains Element
References to the Organisation Components of the Organisations that
should use the signature to verify that:
o they have a pre-existing relationship with the Organisation
that generated the signature,
o the data which is secured by the signature has not been
changed,
o the data has been signed correctly, and
o the action they are required to undertake on behalf of the
Merchant is therefore authorised.
5.1.3 Symmetric and Asymmetric Cryptography
The Signer of an Action and a Verifier of an Action may have agreed to
use cryptography which is understood only by the two organisations
involved. This requires that a separate Digital Signature Element for
use by the verifier is contained within the Signature Component. This
approach is more likely if symmetric cryptography is being used
between the Trading Roles.
Equally the same cryptography may be understood by several or all of
the Trading Roles. In this case one Digital Signature Element may
refer to multiple Verifiers of an Action. This is more likely if
public key/asymmetric cryptography is being used.
Note that one transaction may involve use of both symmetric and
asymmetric cryptography.
5.1.4 Mandatory and Optional Signatures
IOTP does not mandate the use of signatures. For example, if a micro
payment is being made for 0.1 cents, then the cost of the cryptography
required to generate the signature may be greater than the income
generated from the payment. Therefore it is up to the Merchant to
decide whether IOTP Messages will include signatures, and for the
Consumer to decide whether carrying out a transaction without
David Burdett et al. [Page 67]
Internet Draft IOTP/1.0 23 October 1998
signatures is an acceptable risk. If Merchants discover that
transactions without signatures are not being accepted, then they will
start using signatures or accept a lower volume and value of business.
Additional optional signatures, over and above the ones required by
the Trading Roles may be included, for example, to identify a Customer
Care Provider or so that a Merchant can sign an Offer using a
certificate issued by a Certificate Authority which offers Merchant
"Credentials" or some other warranty on the goods or services being
offered.
5.1.5 Using signatures to Prove Actions Complete Successfully
Proving an action completed successfully, is achieved by signing data
on Response messages. Specifically:
o on the Offer Response, when a Merchant is making an Offer to
the Consumer which can then be sent to either:
- a Payment Handler to prove that payment is authorised, or
- a Delivery Handler to prove that Delivery is authorised
o on the Payment Response, when a Payment Handler is generating
a Payment Receipt which can be sent to either:
- a Delivery Handler, in a Delivery Request Block to prove that
delivery is authorised, or
- another Payment Handler, in a second Payment Request, to prove
that the second payment in a Value Exchange IOTP Transaction is
authorised.
This proof of an action may, in future versions of IOTP, also be used
to prove after the event that the IOTP transaction occurred. For
example to a Customer Care Provider.
5.2 Checking a Signature is Correctly Calculated
Checking a signature is correctly calculated is part of checking for
Message Level Errors (see section 4.3.2). It is included here so that
all signature and security related considerations are kept together.
Before a Trading Role can check a signature it must identify which of
the potentially multiple digital signature elements should be checked.
The steps involved are as follows:
o check that a Signature Block is present and it contains one or
more Signature Components
o identify the Organisation Component which contains an OrgId
attribute for the Organisation which is carrying out the
signature check. If no or more than one Organisation Component
is found then it is an error
o use the ID attribute of the Organisation Component to identify
the Digital Signatures Elements which the Trading Role should
verify. Note there may be no signatures for a Trading Role to
verify.
David Burdett et al. [Page 68]
Internet Draft IOTP/1.0 23 October 1998
o verify the Signature Components that contain the Digital
Signature Elements as follows:
- check that the Digital Signature Element correctly signs the
Signed Data Element
- check that the Hash Elements in the Signed Data Element are
correctly calculated where Components or Blocks that are hashed
have been received by the organisation checking the signature
5.3 Checking a Payment or Delivery can occur
This section describes the processes required for a Payment Handler or
Delivery Handler to check that a payment or delivery can occur. This
may include checking signatures if this is specified by the Merchant.
In outline the steps are:
o check that the Payment Request or Delivery Request has been
sent to the correct organisation
o check that correct IOTP components are present in the request,
and
o check that the payment or delivery is authorised
For clarity and brevity the following terms or phrases are used in
this section:
o a "Request Block" is used to refer to either a Payment Request
Block (see section 7.6) or a Delivery Request Block (see
section 7.9) unless specified to the contrary
o a "Response Block" is used to refer to either a Payment
Response Block (see section 7.8) or a Delivery Response Block
(see section 7.10)
o an "Action" is used to refer to an action which occurs on
receipt of a Request Block. Actions can be either a Payment or
a Delivery
o an "Action Organisation", is used to refer to the Payment
Handler or Delivery Handler that carries out an Action
o a "Signer of an Action", is used to refer to the Organisations
that sign data about an Action to authorise the Action, either
in whole or in part
o a "Verifier of an Action", is used to refer to the
Organisations that verify data to determine if they are
authorised to carry out the Action
o an ActionOrgRef attribute contains Element References which
can be used to identify the "Action Organisation" that should
carry out an Action
5.3.1 Check the Action Request was sent to the Correct Organisation
Checking the Action Request was sent to the correct Organisation
varies depending on whether the Action is a Payment or a Delivery.
David Burdett et al. [Page 69]
Internet Draft IOTP/1.0 23 October 1998
5.3.1.1 Payment
In outline a Payment Handler checks if it can accept or make a payment
by identifying the Payment Component in the Payment Request Block it
has received, then using the ID of the Payment Component to track
through the Brand List and Brand Selection Components to identify the
Organisation selected by the Consumer and then checking that this
organisation is itself.
The way data is accessed to do this is illustrated in the figure
below.
Start
|
v
Brand List<--------------------------+-----------Payment
Component BrandListRef | Component
| |
|-Brand<-------------------------- |
| Element BrandRef | |
| | Brand Selection
| |Protocol Component
| | AmountRefs | |
| v Protocol | |
|-Protocol Amount<---------------- |
| Element---------- AmountRef |
| | | |
| |Currency |Pay |
| | AmountRefs |Protocol |
| v |Ref |
|-Currency Amount | |
| Element<---------|----------------
| |
-PayProtocol<-----
Element---------------------->Organisation
Action Component
OrgRef |
-Trading Role
Element
(Payment Handler)
Figure 14 Checking a Payment Handler can carry out a Payment
The following describes the steps involved and the checks which need
to be made:
1)
Identify the Payment Component (see section 6.8) in the
Payment Request Block that was received.
2)
Identify the Brand List and Brand Selection Components for the
Payment Component. This involves:
a)
identifying the Brand List Component (see section 6.6)
where the value of its ID attribute matches the
BrandListRef attribute of the Payment Component. If no or
David Burdett et al. [Page 70]
Internet Draft IOTP/1.0 23 October 1998
more than one Brand List Component is found there is an
error.
b)
identifying the Brand Selection Component (see section 6.7)
where the value of its BrandListRef attribute matches the
BrandListRef of the Payment Component. If no or more than
one matching Brand Selection Component is found there is an
error.
3)
Identify the Brand, Protocol Amount, Pay Protocol and Currency
Amount elements within the Brand List that have been selected
by the Consumer as follows:
a)
the Brand Element (see section 6.6.1) selected is the
element where the value of its Id attribute matches the
value of the BrandRef attribute in the Brand Selection. If
no or more than one matching Brand Element is found then
there is an error.
b)
the Protocol Amount Element (see section 6.6.2) selected is
the element where the value of its Id attribute matches the
value of the ProtocolAmountRef attribute in the Brand
Selection Component. If no or more than one matching
Protocol Amount Element is found there is an error
c)
the Pay Protocol Element (see section 6.6.4) selected is
the element where the value of its Id attribute matches the
value of the PayProtocolRef attribute in the identified
Protocol Amount Element. If no or more than one matching
Pay Protocol Element is found there is an error
d)
the Currency Amount Element (see section 6.6.3) selected is
the element where the value of its Id attribute matches the
value of the CurrencyAmountRef attribute in the Brand
Selection Component. If no or more than one matching
Currency Amount element is found there is an error
4)
Check the consistency of the references in the Brand List and
Brand Selection Components:
a)
check that an Element Reference exists in the
ProtocolAmountRefs attribute of the identified Brand
Element that matches the Id attribute of the identified
Protocol Amount Element. If no or more than one matching
Element Reference can be found there is an error
b)
check that the CurrencyAmountRefs attribute of the
identified Protocol Amount element contains an element
reference that matches the Id attribute of the identified
Currency Amount element. If no or more than one matching
Element Reference is found there is an error.
c)
check the consistency of the elements in the Brand List.
Specifically, the selected Brand, Protocol Amount, Pay
Protocol and Currency Amount Elements are all child
elements of the identified Brand List Component. If they
are not there is an error.
5)
Check that the Payment Handler that received the Payment
Request Block is the Payment Handler selected by the Consumer.
This involves:
a)
identifying the Organisation Component for the Payment
Handler. This is the Organisation Component where its ID
attribute matches the ActionOrgRef attribute in the
David Burdett et al. [Page 71]
Internet Draft IOTP/1.0 23 October 1998
identified Pay Protocol Element. If no or more than one
matching Organisation Component is found there is an error
b)
checking the Organisation Component has a Trading Role
Element with a Role attribute of PaymentHandler. If not
there is an error
c)
finally, if the identified Organisation Component is not
the same as the organisation that received the Payment
Request Block, then there is an error.
5.3.1.2 Delivery
The way data is accessed by a Delivery Handler in order to check that
it may carry out a delivery is illustrated in the figure below.
Start
|
v
Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)
Figure 15 Checking a Delivery Handler can carry out a Delivery
The steps involved are as follows:
1.
Identify the Delivery Component in the Delivery Request Block.
If there is no or more than one matching Delivery Component
there is an error
2.
Use the ActionOrgRef attribute of the Delivery Component to
identify the Organisation Component of the Delivery Handler.
If there is no or more than one matching Organisation
Component there is an error
3.
If the Organisation Component for the Delivery Handler does
not have a Trading Role Element with a Role attribute of
DeliveryHandler there is an error
4.
Finally, if the organisation that received the Delivery
Request Block does not identify the Organisation Component for
the Delivery Handler as itself, then there is an error.
David Burdett et al. [Page 72]
Internet Draft IOTP/1.0 23 October 1998
5.3.2 Check the Correct Components are present in the Request Block
Check that the correct components are present in the Payment Request
Block (see section 7.6) or in the Delivery Request Block (see section
7.9).
If components are missing, there is an error.
5.3.3 Check an Action is Authorised
The previous steps identified the Action Organisation and that all the
necessary components are present. This step checks that the Action
Organisation is authorised to carry out the Action.
In outline the Action Organisation identifies the Merchant, checks
that it has a pre-existing agreement which allows it carry out the
Action and that any constraints implied by that agreement are being
followed, then, if signatures are required, it checks that they sign
the correct data.
The steps involved are as follows:
1.
Identify the Merchant. This is the Organisation Component with
a Trading Role Element which has a Role attribute with a value
of Merchant. If no or more than one Trading Role Element is
found, there is an error
2.
Check the Action Organisation's agreements with the Merchant
allows the Action to be carried out. To do this the Action
Organisation must check that:
a) the Merchant is known and a pre-existing agreement exists
for the Action Organisation to be their agent for the
payment or delivery
b) they are allowed to take part in the type of IOTP
transaction that is occurring. For example a Payment
Handler may have agreed to accept payments as part of a
Baseline Purchase, but not make payments as part of a
Baseline Refund
c) any constraints in their agreement with the Merchant are
being followed, for example, whether or not an Offer
Response signature is required
3.
Check the signatures are correct. If signatures are required
then they need to be checked. This involves:
a) Identifying the correct signatures to check. This involves
the Action Organisation identifying the Signature
Components where the VerifierOrgRef attribute of the
Digital Signature element points to the Action
Organisation's Organisation Component. Depending on the
IOTP Transaction being carried out (see section 8) either
one or two signatures may be identified
b) checking that the Signature Components are correct. This
involves checking that the necessary Trading Components
have been hashed (see section 5.3.3.1).
David Burdett et al. [Page 73]
Internet Draft IOTP/1.0 23 October 1998
[Note] Validation that the signature is correct and that the Hash
elements within the signature are correctly calculated is
described in section 4 IOTP Error Handling. This is because
errors in the signature or calculation of hashes is
considered a Message Level Error and is carried out before
the Request Block is processed.
[Note End]
5.3.3.1 Check the Signatures Sign Correct Data
All Signature Components contained within IOTP Messages must always
hash:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Signature Component. This binds the
globally unique OtpTransId to other components which make up
the IOTP Transaction
o the Transaction Reference Block (see section 3.3) of the first
IOTP Message that contained the signature. This binds the
OtpTransId with information about the IOTP Message contained
inside the Message Id Component (see section 3.3.2).
Checking that each signature signs the correct data, involves checking
that hashes of the necessary components are present in the SignedData
element of the Signature Component.
The hashes that need to be present depend on the Trading Role of the
Organisation which generated (signed) the signature:
o if the signer of the signature is a Merchant then:
- hashes must be present for all the components in the Request
Block apart from the Brand Selection Component which is optional
o if the signer of the signature is a Payment Handler then
hashes should be present for:
- the Signature Component signed by the Merchant, and optionally
- one or more Signature Components signed by the Payment
Handler(s) identified by the appropriate ActionSignerRefs
attribute.
5.4 Data Integrity and Privacy
The overall integrity of data in IOTP Messages is ensured by the
signing of hashes of Components and Trading Blocks contained in a
Signature Component (see section 6.18) in a Signature Block (see
section 7.18).
Privacy of information is provided by sending IOTP Messages between
the various Trading Roles using a secure channel such as [SSL]. Use of
a secure channel within IOTP is optional.
David Burdett et al. [Page 74]
Internet Draft IOTP/1.0 23 October 1998
6. Trading Components
This section describes the Trading Components used within IOTP.
Trading Components are the child XML elements which occur immediately
below a Trading Block as illustrated in the diagram below.
OTP MESSAGE <----------- OTP Message - an XML Document
| which is transported between the
| Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains
| | information which describes the
| | OTP Transaction and the OTP
Message.
--------> | |-Trans Id Comp. <--- Transaction Id Component -
| | | uniquely identifies the OTP
| | | Transaction. The Trans Id
| | | Components are the same across
| | | all OTP messages that comprise a
| | | single OTP transaction.
| | |-Msg Id Comp. <----- Message Id Component -
| | identifies and describes an OTP
| | Message within an OTP
| | 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 hashes of the Trans Ref
| | | | Block and any Trading Component
| | | | in any OTP Message in the same
| | | | OTP Transaction.
| | | |-Certificate Comp. <- Certificate Component. Used to
| | | check the signature.
Trading |-Trading Block <-------- Trading Block - an XML Element
Components | |-Component within an OTP Message that
| | | |-Component contains a predefined set of
| ---> | |-Component Trading Components
| | |-Component
| | |-Component <--------- Trading Components - XML
| | Elements within a Trading Block
| |-Trading Block that contain a predefined set of
--------> | |-Component XML elements and attributes
| |-Component containing information required
| |-Component to support a Trading Exchange
| |-Component
| |-Component
|
|
Figure 16 Trading Components
David Burdett et al. [Page 75]
Internet Draft IOTP/1.0 23 October 1998
The Trading Components described in this section are listed below in
approximately the sequence they are likely to be used:
o Protocol Options Component
o Authentication Data Component
o Authentication Response Component
o Order Component
o Organisation Component
o Brand List Component
o Brand Selection Component
o Payment Component
o Payment Scheme Component
o Payment Receipt Component
o Delivery Component
o Delivery Note Component
o Signature Component
o Certificate Component
o Error Component
Note that the following components are listed in other sections of
this specification:
o Transaction Id Component (see section 3.3.1)
o Message Id Component (see section 3.3.2)
6.1 Protocol Options Component
Protocol options are options which apply to the IOTP Transaction as a
whole. Essentially it provides a short description of the entire
transaction and the net location which the Consumer role should branch
to if the IOTP Transaction is successful.
The definition of a Protocol Options Component is as follows.
<!ELEMENT ProtocolOptions EMPTY>
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #REQUIRED
SecureSenderNetLocn CDATA #REQUIRED
SuccessNetLocn CDATA #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Protocol Options Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.9 Identifying Languages.
David Burdett et al. [Page 76]
Internet Draft IOTP/1.0 23 October 1998
ShortDesc This contains a short description of the IOTP
Transaction in the language defined by xml:lang.
Its purpose is to provide an explanation of what
type of IOTP Transaction is being conducted by the
parties involved.
It is used to facilitate selecting an individual
transaction from a list of similar transactions ,
for example from a database of IOTP transactions
which has been stored by a Consumer, Merchant,
etc.
SenderNetLocn This contains the non secured net location of the
sender of the TPO Block in which the Protocol
Options Component is contained.
It is the net location to which the recipient of
the TPO block should send a TPO Selection Block if
required.
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
SecureSenderNetLo This contains the secured net location of the
cn sender of the TPO Block in which the Protocol
Options Component is contained.
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
SuccessNetLocn This contains the net location that the should be
displayed after the IOTP Transaction has
successfully completed.
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
6.2 Authentication Data Component
This Trading Component contains data about how an Authentication
within the IOTP Transaction will occur. Its definition is as follows.
David Burdett et al. [Page 77]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
AuthMethod NMTOKEN #REQUIRED
TradingRoleListNMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Authentication Data Component within the IOTP
Transaction.
AuthenticationId An identifier specified by the Authenticator
which, if returned by the Organisation that
receives the Authentication Request, will enable
the Authenticator to identify which Authentication
is being referred to.
AuthMethod This identifies the content of the Authentication
Data Component. Valid values are:
o sha1 This indicates that the recipient of the
Authentication Data Component should generate a
hash. See 6.3 Authentication Response Component.
o signature This indicates the recipient of the
Authentication Data Component should generate a
digital signature to include in the
Authentication Response
o pay:ppp A payment protocol specific
authentication method. The "ppp" identifies a
payment protocol associated with a payment
exchange which is part of the IOTP Transaction.
In this case the content and format of the
AuthData element is defined in the appropriate
Payment Scheme supplement. For example if a
payment method "xzpay" provided an
authentication method, then this attribute would
have the value "pay:xzpay"
o x-ddd:nnn a user defined authentication scheme
type see section (3.7.3 User Defined Codes).
TradingRoleList If present, contains a list of the Trading Roles
(see the TradingRole attribute of the Trading Role
Element - section 6.5.2) for which the
Authenticator is requesting the Authenticatee
provides Organisation Components in the
Authentication Response.
For example a Merchant could request that a
Consumer provides Organisation Components for the
Consumer and DelivTo Trading Roles.
David Burdett et al. [Page 78]
Internet Draft IOTP/1.0 23 October 1998
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent This contains the challenge data as Packaged
Content (see section 3.8) that is to be responded
to using the method indicated by AuthMethod.
6.3 Authentication Response Component
This Authentication Response Component contains the results of an
authentication. Its definition is as follows.
<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Authentication Response Component within the IOTP
Transaction.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
David Burdett et al. [Page 79]
Internet Draft IOTP/1.0 23 October 1998
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent This contains the response to the content of the
Authentication Data Component see section 6.2 as
Packaged Content (see section 3.8).
For a payment specific scheme, it may contain
scheme-specific data. Refer to the scheme-specific
supplemental documentation.
6.4 Order Component
An Order Component contains information about an order. Its definition
is as follows.
<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifierCDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the Order
Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.9 Identifying Languages.
OrderIdentifier This is a code, reference number or other
identifier which the creator of the Order may use
to identify the order. It must be unique within an
IOTP Transaction. If it is used in this way, then
it may remove the need to specify any content for
the Order element as the reference can be used to
look up the necessary information in a database.
David Burdett et al. [Page 80]
Internet Draft IOTP/1.0 23 October 1998
ShortDesc A short description of the order in the language
defined by xml:lang. It is used to facilitate
selecting an individual order from a list of
orders, for example from a database of orders
which has been stored by a Consumer, Merchant,
etc.
OkFrom The date and time in [UTC] format after which the
offer made by the Merchant lapses.
OkTo The date and time in [UTC] format before which a
Value Acquirer may accept the offer made by the
Merchant is not valid.
ApplicableLaw A phrase in the language defined by xml:lang which
describes the state or country of jurisdiction
which will apply in resolving problems or
disputes.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent An optional description of the order information
as Packaged Content (see section 3.8).
6.4.1 Order Description Content
The Packaged Content element will normally be required, however it may
be omitted where sufficient information about the purchase can be
provided in the ShortDesc attribute
Although the amount and currency are likely to appear in the Packaged
Content of the Order Description it is the amount and currency
contained in the payment related trading components (Brand List, Brand
David Burdett et al. [Page 81]
Internet Draft IOTP/1.0 23 October 1998
Selection and Payment) that is authoritative. This means it is
important that the amount actually being paid (as contained in the
payment related trading components) is prominently displayed to the
Consumer.
For interoperability, implementations must support Plain Text as a
minimum so that it can be easily displayed.
6.4.2 OkFrom and OkTo Timestamps
Note that:
o the OkFrom date may be later than the OkFrom date on the
Payment Component (see section 6.8) associated with this
order, and
o similarly, the OkTo date may be earlier that the OkTo date on
the Payment Component (see section 6.8).
[Note] Disclaimer. The following information provided in this note
does not represent formal advice of the Open Trading
Protocol Consortium, any of its members or the authors of
this specification. Readers of this specification must form
their own views and seek their own legal counsel on the
usefulness and applicability of this information.
The merchant in the context of Internet commerce with
anonymous consumers initially frames the terms of the offer
on the web page, and in order to obtain the good or service,
the consumer must accept them.
If there is to be a time-limited offer, it recommended that
merchants communicate this to the consumer and state in the
order description in a manner which is clear to the consumer
that:
- the offer is time limited
- the OkFrom and OkTo timestamps specify the validity of
the offer
- the clock, e.g. the merchant's clock, that will be used
to determine the validity of the offer
[Note End]
6.5 Organisation Component
The Organisation Component provides information about an individual or
an organisation. This can be used for a variety of purposes. For
example:
o to describe the merchant who is selling the goods,
o to identify who made a purchase,
David Burdett et al. [Page 82]
Internet Draft IOTP/1.0 23 October 1998
o to identify who will take delivery of goods,
o to provide a customer care contact,
o to describe who will be the Payment Handler.
Note that the Organisation Components which must be present in an OTP
Message are dependent on the particular transaction being carried out.
Refer to section 8. Open Trading Protocol Transactions, for more
details.
Its definition is as follows.
<!ELEMENT Org (TradingRole+, ContactInfo?, PersonName?,
PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
OtpMsgIdPrefix NMTOKEN #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Organisation 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.9 Identifying Languages.
OrgId A code which identifies the organisation described
by the Organisation Component. See 6.5.1.1
Organisation IDs, below.
OtpMsgIdPrefix Contains the prefix which must be used for all
IOTP Messages sent by the Organisation in this
IOTP Transaction. The values to be used are
defined in 3.4.1 IOTP Message ID Attribute
Definition.
LegalName For organisations which are companies this is
their legal name in the language defined by
xml:lang. It is required for Organisations who
have a Trading Role other than Consumer or
DeliverTo.
ShortDesc A short description of the organisation in the
language defined by xml:lang. It is typically the
name by which the organisation is commonly known.
For example, if the legal name was "Blue Meadows
David Burdett et al. [Page 83]
Internet Draft IOTP/1.0 23 October 1998
Financial Services Inc.". Then its short name
would likely be "Blue Meadows".
It is used to facilitate selecting an individual
organisation from a list of organisations, for
example from a database of organisations involved
in IOTP Transactions which has been stored by a
consumer.
LogoNetLocn The net location which can be used to download the
logo for the organisation.
See section 9 Retrieving Logos.
The content of this attribute must conform to
[RFC1738].
Content:
TradingRole See 6.5.2 Trading Role Element below.
ContactInfo See 6.5.3 Contact Information Element below.
PersonName See 6.5.4 Person Name below.
PostalAddress See 6.5.5 Postal Address below.
6.5.1.1 Organisation IDs
Organisation IDs are used by one IOTP Trading Role to identify
another. In order to avoid confusion, this means that these IDs must
be globally unique.
In principle this is achieved in the following way:
o the Organisation Id for all trading roles, apart from the
Consumer Trading Role, uses a domain name as their globally
unique identifier,
o the Organisation Id for a Consumer Trading Role is allocated
by one of the other Trading Roles in an IOTP Transaction and
is made unique by concatenating it with that other roles'
Organisation Id,
o once a Consumer is allocated an Organisation Id within an IOTP
Transaction the same Organisation Id is used by all the other
trading roles in that IOTP transaction to identify that
Consumer.
Specifically, the content of the Organisation ID is defined as
follows:
OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
David Burdett et al. [Page 84]
Internet Draft IOTP/1.0 23 October 1998
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/"
NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
ConsumerOrgId If the Organisation ID for a Consumer consists
of:
o a standard prefix is to identify that the
Organisation Id is for a consumer, followed by
o one or more characters which conform to the
definition of an XML "namechar". See [XML]
specifications, followed by
o the NonConsumerOrgId for the Organisation which
allocated the ConsumerOrgId. It is normally the
Merchant role.
Use of upper and lower case is significant.
NonConsumerOrgId If the Role is not Consumer then this contains the
Canonical Name for the non-consumer organisation
being described by the Organisation Component. See
[DNS].
Note that a NonConsumerOrgId may not start with
the ConsumerOrgIdPrefix.
Use of upper and lower case is not significant.
Examples of Organisation Ids follow:
o newjerseybooks.com - a merchant organisation id
o westernbank.co.uk - a payment handler organisation id
o consumer:1000247ABH/newjerseybooks.com - a consumer
organisation id allocated by a merchant
6.5.2 Trading Role Element
This identifies the Trading Role of an individual or organisation in
the IOTP Transaction. Note, an organisation may have more than one
Trading Role and several roles may be present in one organisation
element. Its definition is as follows:
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
TradingRole NMTOKEN #REQUIRED
ErrorNetLocn CDATA #IMPLIED >
Attributes:
TradingRole The trading role of the organisation. Valid values
are:
o Consumer. The person or organisation that is
acting in the role of a consumer in the IOTP
David Burdett et al. [Page 85]
Internet Draft IOTP/1.0 23 October 1998
Transaction.
o Merchant. The person or organisation that is
acting in the role of merchant in the IOTP
Transaction.
o PaymentHandler. The financial institution or
other organisation which is a Payment Handler
for the IOTP Transaction
o DeliveryHandler. The person or organisation
that is the delivering the goods or services for
the IOTP Transaction
o DelivTo. The person or organisation that is
receiving the delivery of goods or services in
the IOTP Transaction
o CustCare. The organisation and/or individual
who will provide customer care for an IOTP
Transaction.
o x-ddd:nnn a user defined role (see section
3.7.3 User Defined Codes).
ErrorNetLocn The net location to which IOTP messages containing
Error Components with a Severity of either
HardError or TransientError are sent. See section
6.19.1 Error Processing Guidelines for more
details.
This attribute must be set when TradingRole is set
to Merchant, PaymentHandler or DeliveryHandler.
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
CancelNetLocn This contains the net location that should be
displayed by the Consumer after the Consumer has
received an Error Block containing an Error
Component with the Severity attribute set to
either:
o HardError,
o Warning but the Consumer decides to not
continue with the transaction
o TransientError and the transaction has
subsequently timed out.
See section 6.19.1 Error Processing Guidelines for
more details.
This attribute must be set when TradingRole is set
to Merchant, PaymentHandler or DeliveryHandler.
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
David Burdett et al. [Page 86]
Internet Draft IOTP/1.0 23 October 1998
6.5.3 Contact Information Element
This contains information which can be used to contact an organisation
or an individual. All attributes are optional however at least one
item of contact information should be present. Its definition is as
follows.
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes within
this element. See section 3.9 Identifying
Languages.
Tel A telephone number by which the organisation may
be contacted. Note that this is a text field and
no validation is carried out on it.
Fax A fax number by which the organisation may be
contacted. Note that this is a text field and no
validation is carried out on it.
Email An email address by which the organisation may be
contacted. Note that this field should conform to
the conventions for address specifications
contained in [RFC822].
NetLocn A location on the Internet by which information
about the organisation may be obtained that can be
displayed using a web browser.
The content of this attribute must conform to
[RFC1738].
6.5.4 Person Name Element
This contains the name of an individual person. All fields are
optional however as a minimum either the GivenName or the FamilyName
should be present. Its definition is as follows.
David Burdett et al. [Page 87]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes within
this element. See section 3.9 Identifying
Languages.
Title A distinctive name; personal appellation,
hereditary or not, denoting or implying office
(e.g. judge, mayor) or nobility (e.g. duke,
duchess, earl), or used in addressing or referring
to a person (e.g. Mr, Mrs, Miss)
GivenName The primary or main name by which a person is
known amongst and identified by their family,
friends and acquaintances. Otherwise known as
first name or Christian Name.
Initials The first letter of the secondary names (other
than the Given Name) by which a person is known
amongst or identified by their family, friends and
acquaintances.
FamilyName The name by which family of related individuals
are known. It is typically the part of an
individual's name which is passed on by parents to
their children.
6.5.5 Postal Address Element
This contains an address which can be used, for example, for the
physical delivery of goods, services or letters. Its definition is as
follows.
David Burdett et al. [Page 88]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True|False) 'False' >
Attributes:
xml:lang Defines the language used by attributes within
this element. See section 3.9 Identifying
Languages.
AddressLine1 The first line of a postal address. e.g. "The
Meadows"
AddressLine2 The second line of a postal address. e.g. "Sandy
Lane"
CityOrTown The city of town of the address. e.g. "Carpham"
StateOrRegion The state or region within a country where the
city or town is placed. e.g. "Surrey"
Country The country for the address. e.g. "UK"
LegalLocation This identifies whether the address is the
Registered Address for the Organisation. At least
one address for the Organisation must have a value
set to True unless the Trading Role is either
Consumer or DeliverTo.
6.6 Brand List Component
Brand List Components are contained within the Trading Protocol
Options Block (see section 7.1) of the IOTP Transaction. They contains
lists of:
o payment Brands (see also section 3.6 Brands and Brand
Selection),
o amounts to be paid in the currencies that are accepted or
offered by the Merchant,
o the payment protocols which can be used to make payments with
a Brand, and
o the net locations of the Payment Handlers which accept payment
for a payment protocol
The definition of a Brand List Component is as follows.
David Burdett et al. [Page 89]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit ) #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the Brand
List Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.9 Identifying Languages.
ShortDesc A text description in the language defined by
xml:Lang giving details of the purpose of the
Brand List. This information must be displayed to
the receiver of the Brand List in order to assist
with making the selection. It is of particular
benefit in allowing a Consumer to distinguish the
purpose of a Brand List when an IOTP Transaction
involves more than one payment.
PayDirection Indicates the direction in which the payment for
which a Brand is being selected is to be made. Its
values may be:
o Debit The sender of the Payment Request Block
(e.g. the Consumer) to which this Brand List
relates will make the payment to the Payment
Handler, or
o Credit The sender of the Payment Request Block
to which this Brand List relates will receive a
payment from the Payment Handler.
Content:
Brand This describes a Brand. The sequence of the Brand
elements (see section 6.6.1) within the Brand List
does not indicate any preference. It is
recommended that software which processes this
Brand List presents Brands in a sequence which the
receiver of the Brand List prefers.
ProtocolAmount This links a particular Brand to:
o the currencies and amounts in CurrencyAmount
elements that can be used with the Brand, and
o the Payment Protocols and Payment Handlers,
which can be used with those currencies and
David Burdett et al. [Page 90]
Internet Draft IOTP/1.0 23 October 1998
amounts, and a particular Brand
CurrencyAmount This contains a currency code and an amount.
PayProtocol This contains information about a Payment Protocol
and the Payment Handler which may be used with a
particular Brand.
The relationships between the elements which make up the content of
the Brand List is illustrated in the diagram below.
Brand List
Component
|
|-Brand
| Element
| |
| |Protocol
| | AmountRefs
| v
|-Protocol Amount
| Element----------
| | |
| |Currency |Pay
| | AmountRefs |Protocol
| v |Ref
|-Currency Amount |
| Element |
| |
-PayProtocol<-----
Element
Figure 17 Brand List Element Relationships
Examples of complete Brand Lists are contained in section 10 Brand
List Examples.
6.6.1 Brand Element
A Brand Element describes a brand that can be used for making a
payment. One or more of these elements is carried in each Brand List
Component that has the PayDirection attribute set to Debit. Exactly
one Brand Element may be carried in a Brand List Component that has
the PayDirection attribute set to Credit.
David Burdett et al. [Page 91]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
Id ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId NMTOKEN #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced in a
Brand Selection Component contained in a later
Payment Request message and uniquely identifies
the Brand element within the IOTP Transaction.
xml:lang Defines the language used by attributes and
content of this element. See section 3.9
Identifying Languages.
BrandId This contains a unique identifier for the brand or
promotional brand. It is used to match against a
list of Payment Instruments which the Consumer
holds to determine whether or not the Consumer can
pay with the Brand.
The syntax for a BrandId is as follows:
BrandId ::= UserDefinedCode |
BrandIdDomain ":" BrandValue
Currently the only valid value for the
BrandIdDomain is IOTP which indicates that the
BrandValue is registered with IOTP.
The valid values for BrandValue for brands defined
within the IOTP Brand domain are obtainable from
the IOTP web site http:www.IOTP.org.
A user defined code follows the conventions
defined in section 3.7.3. Uniqueness of a user
defined BrandId is not guaranteed.
BrandName This contains the name of the brand, for example
MasterCard Credit. This is the description of the
Brand which is displayed to the consumer in the
Consumers language defined by xml:lang. For
example it might be "American Airlines Advantage
Visa". Note that this attribute is not used for
matching against the payment instruments held by
the Consumer.
David Burdett et al. [Page 92]
Internet Draft IOTP/1.0 23 October 1998
BrandLogoNetLocn The net location which can be used to download the
logo for the organisation. See section Retrieving
Logos (see section 9).
The content of this attribute must conform to
[RFC1738].
BrandNarrative This optional attribute is designed to be used by
the Merchant to indicate some special conditions
or benefit which would apply if the Consumer
selected that brand. For example "5% discount",
"free shipping and handling", "free breakage
insurance for 1 year", "double air miles apply",
etc.
ProtocolAmountRefs Identifies the protocols and related currencies
and amounts which can be used with this Brand.
Specified as a list of ID's of Protocol Amount
Elements (see section 6.6.2) contained within the
Brand List.
ContentSoftwareId This optional attribute contains information which
identifies the software which generated the
content of the element. Its purpose is to help
resolve interoperability problems that might occur
as a result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Optional Packaged Content (see section 3.8)
containing information about the brand which may
be used by the payment protocol. The content of
this information is defined in the supplement for
a payment protocol which describes how the payment
protocol works with IOTP.
Examples Brand Elements are contained in section 10 Brand List
Examples.
David Burdett et al. [Page 93]
Internet Draft IOTP/1.0 23 October 1998
6.6.2 Protocol Amount Element
The Protocol Amount element links a Brand to:
o the currencies and amounts in Currency Amount Elements (see
section 6.6.3) that can be used with the Brand, and
o the Payment Protocols and Payment Handlers defined in a Pay
Protocol Element (see section 6.6.4), which can be used with
those currencies and amounts.
Its definition is as follows:
<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
Id ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Protocol Amount element
within the IOTP Transaction.
PayProtocolRef Contains an Element Reference (see section 3.5)
that refers to the Pay Protocol Element (see
section 6.6.4) that contains the Payment Protocol
and Payment Handlers that can be used with the
Brand.
CurrencyamountRefs Contains a list of Element References (see
section 3.5) that refer to the Currency Amount
Element (see section 6.6.3) that describes the
currencies and amounts that can be used with the
Brand.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
David Burdett et al. [Page 94]
Internet Draft IOTP/1.0 23 October 1998
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Optional Packaged Content (see section 3.8)
containing information about the protocol amount
which may be used by the payment protocol. The
content of this information is defined in the
supplement for a payment protocol which describes
how the payment protocol works with IOTP.
Examples Protocol Amount Elements are contained in10 Brand List
Examples.
6.6.3 Currency Amount Element
A Currency Amount element contains:
o a currency code (and its type), and
o an amount.
One or more of these elements is carried in each Brand List Component.
Its definition is as follows:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
Id ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217'
CurrCode CDATA #REQUIRED >
Attributes:
Id Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Currency Amount Element
within the IOTP Transaction.
Amount Indicates the amount to be paid in whole and
fractional units of the currency. For example
$245.35 would be expressed "245.35". Note that
values smaller than the smallest denomination are
allowed. For example one tenth of a cent would be
"0.001".
CurrCodeType Indicates the domain of the CurrCode. This
attribute is included so that the currency code
may support non-standard "currencies" such as
frequent flyer points, trading stamps, etc. Its
values may be:
David Burdett et al. [Page 95]
Internet Draft IOTP/1.0 23 October 1998
o ISO4217 indicates the currency code conforms to
[ISO 4217]
o x-ddd:nnn a user defined currency code type
(see section 3.7.3 User Defined Codes).
CurrCode A code which identifies the currency to be used in
the payment. The domain of valid currency codes is
defined by CurrCodeType
Note that Amount, CurrCodeType and CurrCode have identical meanings to
the attributes of the same name on the Payment Component (see section
6.8).
Examples Currency Amount Elements are contained in 10 Brand List
Examples.
6.6.4 Pay Protocol Element
A Pay Protocol element specifies details of a Payment Protocol and the
Payment Handler that can be used with a Brand. One or more of these
elements is carried in each Brand List.
<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
Id ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
Id Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Pay Protocol element
within the IOTP Transaction.
xml:lang Defines the language used by attributes and
content of this element. See section 3.9
Identifying Languages.
ProtocolId Consists of a protocol name and version. For
example "SETv1.0".
The value used for the ProtocolId is defined in
the payment supplement for the payment method.
ProtocolName A narrative description of the payment protocol
David Burdett et al. [Page 96]
Internet Draft IOTP/1.0 23 October 1998
and its version in the language identified by
xml:lang. For example "Secure Electronic
Transaction Version 1.0". Its purpose is to help
provide information on the payment protocol being
used if problems arise.
ActionOrgRef An Element Reference (see section 3.5) to the
Organisation Component for the Payment Handler for
the Payment Protocol.
PayReqNetLocn The Net Location indicating where an unsecured
Payment Request message should be sent if this
protocol choice is used.
The content of this attribute is dependent on the
Transport Mechanism (such must conform to
[RFC1738].
SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if this
protocol choice is used.
A secured payment involves the use of a secure
channel such as [SSL] in order to communicate with
the Payment Handler.
The content of this attribute must conform to
[RFC1738]. See also See section 3.10 Secure and
Insecure Net Locations.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Optional Packaged Content information (see section
3.8) about the protocol which is used by the
payment protocol. The content of this information
David Burdett et al. [Page 97]
Internet Draft IOTP/1.0 23 October 1998
is defined in the supplement for a payment
protocol which describes how the payment protocol
works with IOTP. An example of its use could be to
include a payment protocol message.
Examples Pay Protocol Elements are contained in section 6.6 Brand List
Component.
6.7 Brand Selection Component
A Brand Selection Component identifies the choice of payment brand,
payment protocol and the Payment Handler. This element is used:
o in Payment Request messages within Baseline Purchase and
Baseline Value IOTP Transactions to identify the brand,
protocol and payment handler for a payment, or
o to, optionally, inform a merchant in a purchase of the payment
brand being used so that the offer and order details can be
amended accordingly.
In Baseline IOTP, the integrity of Brand Selection Components is not
guaranteed. However, modification of Brand Selection Components can
only cause denial of service if the payment protocol itself is secure
against message modification, duplication, and swapping attacks.
The definition of a Brand Selection Component is as follows.
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the Brand
Selection Component within the IOTP Transaction.
BrandListRef The Element Reference (see section 3.5) of the
Brand List Component from which a Brand is being
selected
BrandRef The Element Reference of a Brand element within
the Brand List Component that is being selected
that is to be used in the payment.
ProtocolAmountRef The Element Reference of a Protocol Amount element
within the Brand List Component which is to be
David Burdett et al. [Page 98]
Internet Draft IOTP/1.0 23 October 1998
used when making the payment.
CurrencyAmountRef The Element Reference of a Currency Amount element
within the Brand List Component which is to be
used when making the payment.
Content:
BrandSelBrandInfo, This contains any additional data that
BrandSelProtocolAmountInfo, may be required by a particular payment
BrandSelCurrencyAmountInfo brand or protocol. See sections 6.7.1,
6.7.2, and 6.7.3.
The following rules apply:
o the BrandListRef must contain the ID of a Brand List Component
in the same IOTP Transaction
o every Brand List Component in the Trading Protocol Options
Block must be referenced by one and only one Brand Selection
Component
o the BrandRef must refer to the ID of a Brand contained within
the Brand List Component referred to by BrandListRef
o the ProtocolAmountRef must refer to one of the Element IDs
listed in the ProtocolAmountRefs attribute of the Brand
element identified by BrandRef
o the CurrencyAmountRef must refer to one of the Element IDs
listed in the CurrencyAmountRefs attribute of the Protocol
Amount Element identified by ProtocolAmountRef.
An example of a Brand Selection Component is included in 10 Brand List
Examples.
6.7.1 Brand Selection Brand Info Element
The Brand Selection Brand Info Element contains any additional data
that may be required by a particular payment brand. See the IOTP
payment method supplement for a description of how and when it used.
<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
David Burdett et al. [Page 99]
Internet Draft IOTP/1.0 23 October 1998
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Packaged Content information (see section 3.8)
that contains additional data that may be required
by a particular payment brand. See the payment
method supplement for IOTP for rules on how this
is used.
6.7.2 Brand Selection Protocol Amount Info Element
The Brand Selection Protocol Amount Info Element contains any
additional data that is payment protocol specific that may be required
by a particular payment brand or payment protocol. See the IOTP
payment method supplement for a description of how and when it used.
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 6.7.1 Brand Selection Brand Info
Element.
Content:
PackagedContent Packaged Content information (see section 3.8)
that contains any additional data that may be
required by a particular payment brand. See the
payment method supplement for IOTP for rules on
how this is used.
6.7.3 Brand Selection Currency Amount Info Element
The Brand Selection Currency Amount Info Element contains any
additional data that is payment brand and currency specific that may
be required by a particular payment brand. See the IOTP payment method
supplement for a description of how and when it used.
David Burdett et al. [Page 100]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
Id ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 6.7.1 Brand Selection Brand Info
Element.
Content:
PackagedContent Packaged Content information (see section 3.8)
that contains any additional data relating to the
payment brand and currency. See the payment method
supplement for IOTP for rules on how this is used.
6.8 Payment Component
A Payment Component contains information used to control how a payment
is carried out. Its provides information on:
o the times within which a Payment with a Payment Handler may be
started
o a reference to the Brand List (see section 6.6) which
identifies the Brands, protocols, currencies and amounts which
can be used to make a payment
o whether or not an authentication of the consumer is required
as part of the payment
o whether or not a payment receipt will be provided
o whether another payment precedes this payment.
Its definition is as follows.
<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt ('True'|'False') #REQUIRED
AuthDataRef NMTOKEN #IMPLIED
StartAfter NMTOKENS #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Component within the IOTP Transaction.
OkFrom The date and time in [UTC] format after which a
Payment Handler may accept for processing a
David Burdett et al. [Page 101]
Internet Draft IOTP/1.0 23 October 1998
Payment Request Block (see section 7.6) containing
the Payment Component.
OkTo The date and time in [UTC] format before which a
Payment Handler may for processing accept a
Payment Request Block containing the Payment
Component.
BrandListRef An Element Reference (see section 3.5) of a Brand
List Component (see section 6.6) within the TPO
Trading Block for the IOTP Transaction. The Brand
List identifies the alternative ways in which the
payment can be made.
AuthDataRef An element reference (see section 3.4) of an
Authentication Data Component (see section 6.2)
which is to be used for authentication of the
Trading Role which sends the Payment Request Block
containing the Payment Component to the Payment
Handler. If not present, then no authentication is
to take place.
SignedPayReceipt Indicates whether or not the Payment Response
Block (7.8) generated by the payment handler for
the payment must be digitally signed.
StartAfter Contains Element References (see section 3.5) of
other Payment Components which describe payments
which must be complete before this payment can
start. If no StartAfter attribute is present then
there are no dependencies and the payment can
start immediately
Contents
PackagedContent This optional element contains "user" data defined
by the Merchant which is required by the Payment
Handler. See section 3.8 Packaged Content Element.
6.9 Payment Scheme Component
A Payment Scheme Component contains payment protocol information for a
specific payment scheme which is transferred between the parties
involved in a payment for example a [SET] message. Its definition is
as follows.
David Burdett et al. [Page 102]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Scheme Component within the IOTP
Transaction.
ConsumerPaymentId An identifier specified by the Consumer which,
if returned by the Payment Handler in another
Payment Scheme Component or by other means, will
enable the Consumer to identify which payment is
being referred to.
PaymentHandlerPayId An identifier specified by the Payment Handler
which, if returned by the Consumer in another
Payment Scheme Component, or by other means,
will enable the Payment Handler to identify
which payment is being referred to. It is
required on every Payment Scheme Component apart
from the one contained in a Payment Request
Block.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is
included if the software which generated the
content cannot be identified from the SoftwareId
attribute on the Message Id Component (see
section 3.3.2)
Content:
PackagedContent Contains the payment scheme protocol information
as Packaged Content (see section 3.8). See the
payment scheme supplement for the definition of
its content.
David Burdett et al. [Page 103]
Internet Draft IOTP/1.0 23 October 1998
6.10 Payment Receipt Component
A Payment Receipt is a record of a payment which demonstrates how much
money has been paid or received. It is distinct from a purchase
receipt in that it contains no record of what was being purchased.
Typically the content of a Payment Receipt Component will contain data
which describes:
o the amount paid and its currency
o the date and time of the payment
o internal reference numbers which identify the payment to the
payment system
o potentially digital signatures generated by the payment method
which can be used to prove after the event that the payment
occurred.
If the Payment Method being used provides the facility then the
Payment Receipt Component should contain payment protocol messages, or
references to messages, which prove the payment occurred.
The precise definition of the content is Payment Method dependent.
Refer to the supplement for the payment method being used to determine
the rules that apply.
Information contained in the Payment Receipt Component should be
displayed or otherwise made available to the Consumer.
[Note] If the Payment Receipt Component contains Payment Protocol
Messages, then the Messages will need to be processed by
Payment Method software to convert it into a format which
can be understood by the Consumer
[Note End]
The definition of a Payment Receipt Component is as follows.
<!ELEMENT PayReceipt (PackagedContent?) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
PaymentRef Contains an Element Reference (see section 3.5) to
the Payment Component (see section 6.8) to which
this payment receipt applies
PayReceiptRefs Optionally contains Element References to other
David Burdett et al. [Page 104]
Internet Draft IOTP/1.0 23 October 1998
Components (potentially including Pay Scheme
Components) which together make up the receipt.
Note that:
o each payment scheme defines in its supplement
the elements which must be referenced.
o each of the components referenced must be
hashed and signed in the Payment Response
signature component, if one is being used.
The client software should save all the components
referenced so that the payment receipt can be
reconstructed when required.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Optionally contains the payment scheme specific
record of the payment which can be used for
receipt purposes as Packaged Content (see section
3.8). Each payment scheme defines in its
supplement the structure of the content.
Note that either the PayReceiptRefs attribute, the PackagedContent
element, or both must be present.
6.11 Payment Note Component
The Payment Note Component contains additional, non payment related,
information which the Payment Handler wants to provide to the
Consumer. For example, if a withdrawal or deposit were being made then
it could contain information on the remaining balance on the account
after the transfer was complete. The information should duplicate
information contained within the Payment Receipt Component.
David Burdett et al. [Page 105]
Internet Draft IOTP/1.0 23 October 1998
Information contained in the Payment Note Component should be
displayed or otherwise made available to the Consumer. For
interoperability, the Payment Note Component should support, as a
minimum, a content type of "Plain/Text". Its definition is as follows.
<!ELEMENT PaymentNote (PackagedContent) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Contains additional, non payment related,
information which the Payment Handler wants to
provide to the Consumer as Packaged Content (see
section 3.8).
6.12 Delivery Component
The Delivery Element contains information required to deliver goods or
services. Its definition is as follows.
David Burdett et al. [Page 106]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True|False) #REQUIRED
DelivAndPayResp (True|False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED
ConsumerDeliveryId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless
overridden by an xml:lang attribute on a child
element. See section 3.9 Identifying Languages.
DelivExch Indicates if this IOTP Transaction includes the
messages associated with a Delivery Exchange.
Valid values are:
o True indicates it does include a Delivery
Exchange
o False indicates it does not include a Delivery
Exchange
If set to true then a DeliveryData element must
be present. If set to false it may be absent.
DelivAndPayResp Indicates if the Delivery Response Block (see
section 7.10) and the Payment Response Block
(see section 7.8 ) are combined into one IOTP
Message. Valid values are:
o True indicates both blocks will be in the same
IOTP Message, and
o False indicates each block will be in a
different IOTP Message
DelivAndPayResp should not be true if DelivExch
is False.
In practice combining the Delivery Response
Block and Payment Response Block is only likely
to be practical if the Merchant, the Payment
Handler and the Delivery Handler are the same
organisation since:
o the Payment Handler must have access to Order
Component information so that they know what
to deliver, and
o the Payment Handler must be able to carry out
the delivery
David Burdett et al. [Page 107]
Internet Draft IOTP/1.0 23 October 1998
ActionOrgRef An Element Reference to the Organisation
Component of the Delivery Handler for this
delivery.
ConsumerDeliveryId An identifier specified by the Consumer which,
if returned by the Delivery Handler in another
Delivery Component, or by other means, will
enable the Consumer to identify which Delivery
is being referred to.
Content:
DeliveryData Contains details about how the delivery will be
carried out. See 6.12.1 Delivery Data Element
below.
PackagedContent This optional element contains "user" data defined
for the Merchant which is required by the Delivery
Handler. See section 3.8 Packaged Content Element.
6.12.1 Delivery Data Element
The DeliveryData element contains information about where and how
goods are to be delivered. Its definition is as follows.
<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocnCDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes within
this component. See section 3.9 Identifying
Languages.
OkFrom The date and time in [UTC] format after which the
Delivery Handler may accept for processing a
Delivery Request Block (see section 7.9).
OkTo The date and time in [UTC] format before which the
Delivery Handler may accept for processing a
Delivery Request Block.
DelivMethod Indicates the method by which goods or services
David Burdett et al. [Page 108]
Internet Draft IOTP/1.0 23 October 1998
may be delivered. Valid values are:
o Post the goods will be delivered by post or
courier
o Web the goods will be delivered electronically
in the Delivery Note Component
o Email the goods will be delivered
electronically by e-mail
o x-ddd:nnn a user defined delivery method see
3.7.3 User Defined Codes.
DelivToRef The Element Reference (see section 3.4) of an
Organisation Component within the IOTP Transaction
which has a role of DelivTo. The information in
this block is used to determine where delivery is
to be made. It must be compatible with
DelivMethod. Specifically if the DelivMethod is:
o Post, then the there must be a Postal Address
Element containing sufficient information for a
postal delivery,
o Web, then there are no specific requirements.
The information will be sent in a web page back
to the Consumer
o Email, then there must be Contact Information
Element with a valid e-mail address
DelivReqNetLocn This contains the Net Location to which an
unsecured Delivery Request Block (see section 7.9)
which contains the Delivery Component should be
sent.
The content of this attribute is dependent on the
Transport Mechanism must conform to [RFC1738].
SecDelivReqNetLocn This contains the Net Location to which a secured
Delivery Request Block (see section 7.9) which
contains the Delivery Component should be sent.
A secured delivery request involves the use of a
secure channel such as [SSL] in order to
communicate with the Payment Handler.
The content of this attribute is dependent on the
Transport Mechanism must conform to [RFC1738].
See also Section 3.10 Secure and Insecure Net
Locations.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
David Burdett et al. [Page 109]
Internet Draft IOTP/1.0 23 October 1998
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
PackagedContent Optional additional information about the delivery
as Packaged Content (see section 3.8). provided to
the Delivery Handler by the merchant.
6.13 Delivery Note Component
A Delivery Note contains delivery instructions about the delivery of
goods or services or potentially the actual Delivery Information
itself. It is information which the person or organisation receiving
the Delivery Note can use when delivery occurs.
<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Note Component within the IOTP
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.9 Identifying Languages.
DelivHandlerDeliv An optional identifier specified by the Delivery
Id Handler which, if returned by the Consumer in
another Delivery Component, or by other means,
will enable the Delivery Handler to identify which
Delivery is being referred to. It is required on
every Delivery Component apart from the one
contained in a Delivery Request Block.
David Burdett et al. [Page 110]
Internet Draft IOTP/1.0 23 October 1998
An example use of this attribute is to contain a
delivery tracking number.
ContentSoftwareId This contains information which identifies the
software which generated the content of the
element. Its purpose is to help resolve
interoperability problems that might occur as a
result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by xml:lang.
It must contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
It is recommended that this attribute is included
if the software which generated the content cannot
be identified from the SoftwareId attribute on the
Message Id Component (see section 3.3.2)
Content:
DeliveryNote Contains the actual delivery note information as
Packaged Content (see section 3.8).
[Note] If the content of the Delivery Message is a Mime message
then the Delivery Note may trigger an application which
causes the actual delivery to occur.
[Note End]
6.14 Payment Method Information Component
A Payment Method Information Component contains data which describes
the Payment Method which initiated the Payment Instrument Customer
Care Transaction and the software which generated the message. Its
definition is as follows.
<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
ID ID #REQUIRED
BrandId NMTOKEN #REQUIRED
PayProtocolId NMTOKEN #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Method Information Component within the
IOTP Transaction.
David Burdett et al. [Page 111]
Internet Draft IOTP/1.0 23 October 1998
BrandId The Brand Identifier attribute copied from the
BrandId attribute of the Brand Element (see
section 6.6.1)of the Payment Instrument which
needs customer care.
PayProtocolId The ProtocolId attribute copied from the Pay
Protocol Element (see section 6.6.4) of the Brand
being used. This may not be required for all types
of Payment Instrument. See the IOTP Supplement for
the Payment Method to determine if this is to be
used.
6.15 Status Component
A Status Component contains status information about the business
success or failure (see section 4.2) of a process.
Its definition is as follows.
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType (Offer|Payment|Delivery|Authentication) #REQUIRED
ElRef NMTOKEN #REQUIRED
ProcessState (NotYetStarted|InProgress|
CompletedOk|Failed|ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the Status
Component within the IOTP Transaction.
xml:lang Defines the language used by attributes within
this component. See section 3.9 Identifying
Languages.
StatusType Indicates the type of process which the Status is
reporting on. It may be set to either Offer,
Payment, Delivery or Authentication
ElRef Contains an Element Reference (see section 3.5) to
the Component for which the Status is being
described. It must refer to either:
o a Trading Protocol Options Block (see section
7.1), if the StatusType is Offer,
o a Payment Component (see section 6.8), if the
David Burdett et al. [Page 112]
Internet Draft IOTP/1.0 23 October 1998
StatusType is Payment, or
o a Delivery Component (see section 6.12), if the
StatusType is Delivery
o an Authentication Data Component (see section
6.2) if the statusType is Authentication.
ProcessState Contains a State Code which indicates the current
state of the process being carried out. Valid
values for ProcessState are:
o NotYetStarted. A Request Block has been
received but the process has not yet started
o InProgress. Processing of the Request Block has
started but it is not yet complete
o CompletedOk. The processing of the Request
Block has completed successfully without any
errors
o Failed. The processing of the Request Block has
failed because of a business error (see section
4.2)
o ProcessError. This value is only used when the
Status Component is being used in connection
with an Inquiry Request Trading Block (see
section 7.14). It indicates there was a
Technical Error (see section 4.1) in the Request
Block which is being processed or some internal
processing error.
Note that this code reports on the processing of a
Request Block. Further, asynchronous processing
may occur after the Response Block associated with
the Process has been sent.
CompletionCode Indicates how the process completed. Valid values
for the CompletionCode are given below together
with the conditions when it must be present.
A CompletionCode is a maximum of 14 characters
long.
ProcessReference This optional attribute holds a reference for the
process whose status is being reported. It may
hold the following values:
o when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the Payment
Scheme Data Component
o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the
Delivery Note Component
o when StatusType is set to Authentication, it
should contain the AuthenticationId from the
David Burdett et al. [Page 113]
Internet Draft IOTP/1.0 23 October 1998
Authentication Data Component
This attribute should be absent in the Inquiry
Request message when the Consumer has not been
given such a reference number by the IOTP Service
Provider.
This attribute can be used in an Inquiry Response
Block (see section 7.15) to give the reference
number for a transaction which has previously been
unavailable.
For example, the package tracking number might not
be assigned at the time a delivery response was
received. However, if the Consumer issues a
Baseline Transaction Status Inquiry later, the
Delivery Handler can put the package tracking
number into this attribute in the Inquiry Response
message and send it back to the Consumer.
StatusDesc An optional textual description of the current
status of the process in the language identified
by xml:lang.
6.15.1.1 Offer Completion Codes
The Completion Code is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate.
Value Description
AuthError Authentication Error. The check of the
Authentication Response which was carried out has
failed.
OfferDecl Offer Declined. The Merchant declines to generate
an offer for some reason.
Unspecified Unspecified error. There is some unknown problem
or error which does not fall into one of the other
CompletionCodes.
6.15.1.2 Payment Completion Codes
The CompletionCode is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc
David Burdett et al. [Page 114]
Internet Draft IOTP/1.0 23 October 1998
attribute is used by individual payment schemes to provide further
explanation where appropriate.
Value Description
BrandNotSupp Brand not supported. The payment brand is not
supported by the Payment Handler.
CurrNotSupp Currency not supported. The currency in which the
payment is to be made is not supported by either
the Payment Instrument or the Payment Handler.
AuthError Authentication Error. The Payment Scheme specific
authentication check which was carried out has
failed.
InsuffFunds Insufficient funds. There are insufficient funds
available for the payment to be made.
InstBrandInvalid Payment Instrument not valid for Brand. A Payment
Instrument is being used which does not correspond
with the Brand selected. For example a Visa credit
card is being used when MasterCard was selected as
the Brand.
PaymntDecl Payment declined. The Payment Handler declines to
accept the payment for some reason.
InstNotValid Payment instrument not valid for trade. The
Payment Instrument cannot be used for the proposed
type of trade, for some reason.
BadInstrumenat Bad instrument. There is a problem with the
Payment Instrument being used which means that it
is unable to be used for the payment.
Unspecified Unspecified error. There is some unknown problem
or error which does not fall into one of the other
CompletionCodes. The StatusDesc attribute should
provide the explanation of the cause.
6.15.1.3 Delivery Completion Codes
The following table contains the valid values for the CompletionCode
attribute for a Delivery. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate.
Value Description
BackOrdered Back Ordered. The goods to be delivered are on
order but they have not yet been received.
David Burdett et al. [Page 115]
Internet Draft IOTP/1.0 23 October 1998
Shipping will be arranged when they are received.
This is only valid if ProcessState is CompletedOk.
PermNotAvail Permanently Not Available. The goods are
permanently unavailable and cannot be re-ordered.
This is only valid if ProcessState is Failed.
TempNotAvail Temporarily Not Available. The goods are
temporarily unavailable and may become available
if they can be ordered. This is only valid if
ProcessState is CompletedOk.
ShipPending Shipping Pending. The goods are available and are
scheduled for shipping but they have not yet been
shipped. This is only valid if ProcessState is
CompletedOk.
Shipped Goods Shipped. The goods have been shipped.
Confirmation of delivery is awaited. This is only
valid if ProcessState is CompletedOk.
ShippedNoConf Shipped - No Delivery Confirmation. The goods have
been shipped but it is not possible to confirm
delivery of the goods. This is only valid if
ProcessState is CompletedOk.
Confirmed Confirmed. All goods have been delivered and
confirmation of their delivery has been received.
This is only valid if ProcessState is CompletedOk.
6.15.1.4 Authentication Completion Codes
The Completion Code is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate.
Value Description
AuthDecl Authentication Declined. The Authenticatee
declines to be authenticated. This could be, for
example because the signature on an Authentication
Request was invalid or the Authenticator was not
known or acceptable to the Authenticatee.
TradRolesIncon Trading Roles Inconsistent. The Trading Roles
contained within the TradingRoleList attribute of
the Authentication Data Component are inconsistent
with the Trading Role which the Authenticatee is
taking in the OTP transaction or is able to take.
Examples of inconsistencies include:
David Burdett et al. [Page 116]
Internet Draft IOTP/1.0 23 October 1998
o asking a PaymentHandler for DeliveryHandler
information
o asking a Consumer for Merchant information
Unspecified Unspecified error. There is some unknown problem
or error which does not fall into one of the other
CompletionCodes.
6.16 Trading Role Data Component
The Trading Role Data Component contains opaque data which is needs to
be communicated between the Trading Roles involved in an OTP
Transaction.
Trading Role Components identify:
o the organisation that generated the component, and
o the organisation that is to receive it.
They are first generated and included in a "Response" Block, and then
copied to the appropriate "Request" Block. For example a Payment
Handler might need to inform a Delivery Handler that a credit card
payment had been authorised but not captured. There may also be other
information that the Payment Handler has generated who format is
privately agreed with the Delivery Handler which needs to be
communicated.
Its definition is as follows.
<!ELEMENT TradingRoleData (PackagedContent) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRefNMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Trading Role Data Component within the IOTP
Transaction.
OrginatorElRef Contains an element reference to the Organisation
Component of the Organisation that created the
Trading Role Data Component and included it in a
"Response" Block (e.g. an Offer Response or a
Payment Response Block).
DestinationElRefs Contains element references to the Organisation
Components of the Organisations that are to
receive the Trading Role Data Component in a
David Burdett et al. [Page 117]
Internet Draft IOTP/1.0 23 October 1998
"Request" Block (e.g. either a Payment Request or
a Delivery Request Block).
Content:
PackagedContent This contains the data which is to be sent between
the various Trading Roles. For a definition of
PackagedContent see section 3.8.
6.16.1 Who Receives a Trading Role Data Component
The rules for deciding what to do with Trading Role Data Components
are described below.
o whenever a Trading Role Data Component is received in a
"Response" block identify the Organisation Components of the
Organisations that are to receive it as identified by the
DestinationElRefs attribute.
o whenever a "Request" Block is being sent, check to see if it
is being sent to one of the Organisations identified by the
DestinationElRef attribute. If it is then include in the
"Request" block:
- the Trading Role Data Component as well as,
- the Organisation Component of the Organisation identified by the
OrignatorElRef attribute (if not already present)
6.17 Inquiry Type Component
The Inquiry Component contains the information which indicates what
type of process is being inquired upon. Its definition is as follows.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type (Offer|Payment|Delivery) #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Type Component within the IOTP
Transaction.
Type Contains the type of inquiry. Valid values for
Type are:
o Offer. The inquiry is about the status of an
offer and is addressed to the Merchant.
o Payment. The inquiry is about the status of a
payment and is addressed to the Payment Handler.
o Delivery. The inquiry is about the status of a
David Burdett et al. [Page 118]
Internet Draft IOTP/1.0 23 October 1998
delivery and addressed to the Delivery Handler.
ElRef Contains an Element Reference (see section 3.5) to
the component to which this Inquiry Type Component
applies. That is,
o TPO Block when Type is Offer
o Payment Component when Type is Payment
o Delivery Component when Type is Delivery
ProcessReference Optionally contains a reference to the process
being inquired upon. It should be set if the
information is available. For the definition of
the values it may contain, see the
ProcessReference attribute of the Status Component
(see section 6.15).
6.18 Signature Component
Each Signature Component digitally signs one or more Blocks or
Components including other Signature Components.
For a general explanation of signatures see section 5 Security
Considerations. Detailed definitions of the XML structures for
signatures is described in the paper "Digital Signature for XML -
Proposal", see [XMLSIG].
The Signature Component:
o hashes one or more Blocks or Components in one or more IOTP
Messages within the same IOTP Transaction
o concatenates these hashes into a Signed Data element, and
o signs the SignedData element using the optional certificate
identified in the CertRef attribute of the Digital Signature
element.
Note that a Signed Data Element may be signed by more than one Digital
Signature element.
A Signature Component can be one of two types either:
o an Offer Response Signature, or
o a Payment Response Signature
How these signatures are constructed is described below
6.18.1 Offer Response Signature Component
The Signed Data Element of the Offer Response Signature Component
should contain hashes of the following Components:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Offer Response Signature
David Burdett et al. [Page 119]
Internet Draft IOTP/1.0 23 October 1998
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Offer Response Signature
o from the TPO Block:
- the Protocol Options Component
- each of the Organisation Components
- each of the Brand List Components
o optionally, all the Brand Selection Components if they were
sent to the Merchant in a TPO Selection Block
o from the Offer Response Block:
- the Order Component
- each of the Payment Components
- the Delivery Component
- each of the Authentication Data Components
- any Trading Role Data Components
The Offer Response Signature Component should also contain Digital
Signature Elements for each of the organisations that may or will need
to verify the signature. This involves:
o if the Merchant has received a TPO Selection Block containing
Brand Selection Components, then generate a Digital Signature
Element for the Payment Handler identified by the Brand
Selection Component and the Delivery Handler identified by the
Delivery Component. See section 5.3.1 Check the Action Request
was sent to the Correct Organisation for a description of how
this can be done.
o if the Merchant is not expecting to receive a TPO Selection
Block then generate a Digital Signature Element for the
Delivery Handler and all the Payment Handlers that are
involved.
6.18.2 Payment Receipt Signature Component
The Signed Data Element of the Payment Receipt Signature Component
should contain hashes of the following Components:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Payment Receipt Signature
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Payment Receipt Signature
o the Offer Response Signature Component
o the Payment Receipt Component
o the Status Component
o the Brand Selection Component.
o any Trading Role Data Components
6.18.3 Ping Signature Components
If the Ping Response Transaction is generating a signature (see
section 8.9), the Signed Data Element of the Ping Response or Ping
Request Signature Components should contain hashes of the following
Components:
o all the Organisation Components.
David Burdett et al. [Page 120]
Internet Draft IOTP/1.0 23 October 1998
6.19 Error Component
The Error Component contains information about Technical Errors (see
section 4.1) in an IOTP Message which has been received by one of the
Trading Roles involved in the trade.
For clarity two phrases are defined which are used in the description
of an Error Component:
o message in error. An IOTP message which contains or causes an
error of some kind
o message reporting the error. An IOTP message that contains an
Error Component that describes the error found in a message in
error.
The definition of the Error Component is as follows.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the Error
Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.9 Identifying Languages.
ErrorCode Contains an error code which indicates the nature
of the error in the message in error. Valid values
for the ErrorCode are given in section 6.19.2
Error Codes.
ErrorDesc Contains a narrative description of the error in
the language defined by xml:lang. The content of
this attribute is defined by the vendor/developer
of the software which generated the Error
Component
Severity Indicates the severity of the error. Valid values
are:
o Warning. This indicates that although there is
a message in error the IOTP Transaction can
still continue.
o TransientError. This indicates that the error
David Burdett et al. [Page 121]
Internet Draft IOTP/1.0 23 October 1998
in the message in error may be recovered if the
message in error that is referred to by the
ErrorLocation element is resent
o HardError. This indicates that there is an
unrecoverable error in the message in error and
the IOTP Transaction must stop.
MinRetrySecs This attribute should be present if Severity is
set to TransientError. It is the minimum number of
whole seconds which the IOTP aware application
which received the message reporting the error
should wait before re-sending the message in error
identified by the ErrorLocation element.
If Severity is not set to TransientError then the
value of this attribute is ignored.
SwVendorErrorRef This attribute is a reference whose value is set
by the vendor/developer of the software which
generated the Error Component. It should contain
data which enables the vendor to identify the
precise location in their software and the set of
circumstances which caused the software to
generate a message reporting the error. See also
the SoftwareId attribute of the Message Id element
in the Transaction Reference Block (section 3.3).
Content:
ErrorLocation This identifies the IOTP Transaction Id of the
message in error and, where possible, the element
and attribute in the message in error that caused
the Error Component to be generated.
If the Severity of the error is not
TransientError, more than one ErrorLocation may be
specified as appropriate depending on the nature
of the error (see section 6.19.2 Error Codes) and
at the discretion of the vendor/developer of the
IOTP Aware Application.
PackagedContent This contains additional data which can be used to
understand the error. Its content may vary as
appropriate depending on the nature of the error
(see section 6.19.2 Error Codes) and at the
discretion of the vendor/developer of the IOTP
Aware Application. For a definition of
PackagedContent see section 3.8.
David Burdett et al. [Page 122]
Internet Draft IOTP/1.0 23 October 1998
6.19.1 Error Processing Guidelines
If there is more than one Error Component in a message reporting the
error, carry out the actions appropriate for the Error Component with
the highest severity. In this context, HardError has a higher severity
than TransientError, which has a higher severity than Warning.
6.19.1.1 Severity - Warning
If an IOTP aware application is generating a message reporting the
error with an Error Component where the Severity attribute is set to
Warning, then if the message reporting the error does not contain
another Error Component with a severity higher than Warning, the IOTP
Message must also include the Trading Blocks and Trading Components
that would have been included if no error was being reported.
If a message reporting the error is received with an Error Component
where Severity is set to Warning, then:
o it is recommended that information about the error is either
logged, or otherwise reported to the user,
o the implementer of the IOTP aware application must either, at
their or the user's discretion:
- continue the IOTP transaction as normal, or
- fail the IOTP transaction by generating a message reporting the
error with an Error Component with Severity set to HardError
(see section 6.19.1.3).
If the intention is to continue the IOTP transaction then, if there
are no other Error Components with a higher severity, check that the
necessary Trading Blocks and Trading Components for normal processing
of the transaction to continue are present. If they are not then
generate a message reporting the error with an Error Component with
Severity set to HardError.
6.19.1.2 Severity - Transient Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute is set to
TransientError, then there should be only one Error Component in the
message reporting the error. In addition, the MinRetrySecs attribute
should be present.
If a message reporting the error is received with an Error Component
where Severity is set to TransientError then:
o if the MinRetrySecs attribute is present and a valid number,
then use the MinRetrySecs value given. Otherwise if
MinRetrySecs is missing or is invalid, then:
- generate a message reporting the error containing an Error
Component with a Severity of Warning and send it on the next
David Burdett et al. [Page 123]
Internet Draft IOTP/1.0 23 October 1998
IOTP message (if any) to be sent to the Trading Role which sent
the message reporting the error with the invalid MinRetrySecs,
and
- use a value for MinRetrySecs which is set by the
vendor/developer of the IOTP Aware Application.
o check that only one ErrorLocation element is contained within
the Error Component and that it refers to an IOTP Message
which was sent by the recipient of the Error Component with a
Severity of TransientError. If more than one ErrorLocation is
present then generate a message reporting the error with a
Severity of HardError.
6.19.1.3 Severity - Hard Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute set to
HardError, then there should be only one Error Component in the
message reporting the error.
If a message reporting the error is received with an Error Component
where Severity is set to HardError then terminate the IOTP
Transaction.
6.19.2 Error Codes
The following table contains the valid values for the ErrorCode
attribute of the Error Component. The first sentence of the
description contains the text that should be used to describe the
error when displayed or otherwise reported. Individual implementations
may translate this into alternative languages at their discretion.
An Error Code must not be more that 14 characters long.
Value Description
Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact the
vendor/developer of the software for more
information See the SoftwareId attribute of the
Message Id element in the Transaction Reference
Block(section 3.3).
XmlNotWellFrmd XML not well formed. The XML document is not well
formed. See [XML] for the meaning of "well
formed". Even if the XML is not well formed, it
should still be scanned to find the Transaction
Reference Block so that a properly formed Error
Response may be generated.
David Burdett et al. [Page 124]
Internet Draft IOTP/1.0 23 October 1998
Value Description
XmlNotValid XML not valid. The XML document is well formed but
the document is not valid. See [XML] for the
meaning of "valid". Specifically:
o the XML document does not comply with the
constraints defined in the IOTP document type
declaration (see section 12 Open Trading
Protocol Data Type Definition), and
o the XML document does not comply with the
constraints defined in the document type
declaration of any additional [XML Namespace]
that are declared.
As for XML not well formed, attempts should still
be made to extract the Transaction Reference Block
so that a properly formed Error Response may be
generated.
ElUnexpected Unexpected element. Although the XML document is
well formed and valid, an element is present that
is not expected in the particular context
according to the rules and constraints contained
in this specification.
ElNotSupp Element not supported. Although the document is
well formed and valid, an element is present that:
o is consistent with the rules and constraints
contained in this specification, but
o is not supported by the IOTP Aware Application
which is processing the IOTP Message.
ElMissing Element missing. Although the document is well
formed and valid, an element is missing that
should have been present if the rules and
constraints contained in this specification are
followed.
In this case set the PackagedContent of the Error
Component to the type of the missing element.
ElContIllegal Element content illegal. Although the document is
well formed and valid, the element PackagedContent
contains values which do not conform to the rules
and constraints contained in this specification.
EncapProtErr Encapsulated protocol error. Although the document
is well formed and valid, the PackagedContent of
an element contains data from an encapsulated
protocol which contains errors.
AttUnexpected Unexpected attribute. Although the XML document is
David Burdett et al. [Page 125]
Internet Draft IOTP/1.0 23 October 1998
Value Description
well formed and valid, the presence of the
attribute is not expected in the particular
context according to the rules and constraints
contained in this specification.
AttNotSupp Attribute not supported. Although the XML document
is well formed and valid, and the presence of the
attribute in an element is consistent with the
rules and constraints contained in this
specification, it is not supported by the IOTP
Aware Application which is processing the IOTP
Message.
AttMissing Attribute missing. Although the document is well
formed and valid, an attribute is missing that
should have been present if the rules and
constraints contained in this specification are
followed.
In this case set the PackagedContent of the Error
Component to the type of the missing attribute.
AttValIllegal Attribute value illegal. The attribute contains a
value which does not conform to the rules and
constraints contained in this specification.
AttValNotRecog Attribute Value Not Recognised. The attribute
contains a value which the IOTP Aware Application
generating the message reporting the error could
not recognise even though it should have been able
to since the information had been provided in an
earlier IOTP message.
MsgTooLarge Message too large. The message is too large to be
processed by the IOTP Aware Application.
ElTooLarge Element too large. The element is too large to be
processed by the IOTP Aware Application
ValueTooSmall Value too small or early. The value of all or part
of the PackagedContent of an element or an
attribute, although valid, is too small.
ValueTooLarge Value too large or in the future. The value of all
or part of the PackagedContent of an element or
an attribute, although valid, is too large.
ElInconsistent Element Inconsistent. Although the document is
well formed and valid, according to the rules and
constraints contained in this specification:
o the content of an element is inconsistent with
David Burdett et al. [Page 126]
Internet Draft IOTP/1.0 23 October 1998
Value Description
the content of other elements or their
attributes, or
o the value of an attribute is inconsistent with
the value of one or more other attributes.
In this case create ErrorLocation elements which
identify all the attributes or elements which are
inconsistent.
TransportError Transport Error. This error code is used to
indicate that there is a problem with the
Transport Mechanism which is preventing the
message from being received. It is typically
associated with a Transient Error. Explanation of
the Transport Error is contained within the
ErrorDesc attribute. The values which can be used
inside ErrorDesc with a TransportError is
specified in the IOTP supplement for the Transport
mechanism.
6.19.3 Error Location Element
An Error Location Element identifies an element and optionally an
attribute in the message in error which is associated with the error.
It contains a reference to the IOTP Message, Trading Block, Trading
Component, element and attribute, which is in error.
<!ELEMENT ErrorLocation EMPTY>
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
OtpMsgRef NMTOKEN #REQUIRED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
Attributes:
ElementType This is the "type" (see [XML]) of the Element in
the message in error where the error is located.
OtpMsgRef This is the value of the ID attribute of the of
the Message Id Component (see section 3.3.2) of
the message in error to which this Error Component
applies.
BlkRef If the error is associated with a specific Trading
Block, then this is the value of the ID attribute
of the Trading Block where the error is located.
David Burdett et al. [Page 127]
Internet Draft IOTP/1.0 23 October 1998
CompRef If the error is associated with a specific Trading
Component, then this is the value of the ID
attribute of the Trading Component where the error
is located.
ElementRef If the error is associated with a specific element
within a Trading Component then, if the element
has an attribute with an "attribute type" (see
[XML]) of "ID", then this is the value of that
attribute.
AttName If the error is associated with the value of an
attribute, then this is the name of that
attribute. In this case the PackagedContent of the
Error Component should contain the value of the
attribute.
Note that as many as the attributes as possible should be included.
For example if an attribute in a child element of a Trading Component
contains an incorrect value, then all the attributes of ErrorLocation
should be present.
7. Trading Blocks
Trading Blocks consist of one or more Trading Components and
optionally one or more Signature Components. One or more Trading
Blocks may be contained within the IOTP Messages which are physically
sent in the form of [XML] documents between the different
organisations that are taking part in a trade.
This is illustrated in the diagram below.
OTP MESSAGE <----------- OTP Message - an XML Document
| which is transported between the
| Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains
| | information which describes the
| | OTP Transaction and the OTP
| | Message.
| |-Trans Id Comp. <--- Transaction Id Component -
| | uniquely identifies the OTP
| | Transaction. The Trans Id
| | Components are the same across
| | all OTP messages that comprise a
| | single OTP transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies
| and describes an OTP Message
| within an OTP Transaction
|-Signature Block <----- Signature Block (optional) -
David Burdett et al. [Page 128]
Internet Draft IOTP/1.0 23 October 1998
| | contains one or more Signature
| | Components and their associated
| | Certificates
| |-Signature Comp. <-- Signature Component - contains
| | digital signatures. Signatures
| | may sign hashes of the Trans Ref
| | Block and any Trading Component
| | in any OTP Message in the same
| | OTP Transaction.
| |-Certificate Comp. <- Certificate Component. Used to
| check the signature.
------> |-Trading Block <-------- Trading Block - an XML Element
| | |-Component within an OTP Message that
Trading | |-Component contains a predefined set of
Blocks | |-Component Trading Components
| | |-Component
| | |-Component <--------- Trading Components - XML Elements
| | within a Trading Block that
------> |-Trading Block contain a predefined set of XML
| |-Component elements and attributes
| |-Component containing information required
| |-Component to support a Trading Exchange
| |-Component
| |-Component
|
|
Figure 18 Trading Blocks
Trading Blocks are defined as part of the definition of an IOTP
Message (see section 3.1.1). The definition of an IOTP Message element
is repeated here:
David Burdett et al. [Page 129]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayInstCCExchBlk |
PayInstCCReqBlk |
PayInstCCRespBlk
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk |
)*
) >
The remainder of this section defines the Trading Blocks in this
version of IOTP. They are:
o Authentication Request Block
o Authentication Response Block
o Delivery Request Block
o Delivery Response Block
o Error Block
o Inquiry Request Block
o Inquiry Response Block
o Offer Response Block
o Payment Exchange Block
o Payment Request Block
o Payment Response Block
o Payment Instrument Customer Care Exchange Block
o Payment Instrument Customer Care Request Block
o Payment Instrument Customer Care Response Block
o Signature Block
o Trading Protocol Options Block
o TPO Selection Block
The Transaction Reference Block is described in section 3.3.
7.1 Trading Protocol Options Block
The TPO Trading Block contains options which apply to the IOTP
Transaction. The definition of a TPO Trading Block is as follows.
David Burdett et al. [Page 130]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Trading Protocol Options Block within the IOTP
Transaction (see section 3.4 ID Attributes).
Content:
ProtocolOptions The Protocol Options Component (see section
6.1)defines the options which apply to the whole
IOTP Transaction (see section 8).
BrandList This Brand List Component contains one or more
payment brands and protocols which may be selected
(see section 6.6).
Org The Organisation Components (see section 6.5)
identify the organisations and their roles in the
IOTP Transaction. The roles and organisations
which must be present will depend on the
particular type of IOTP Transaction. See the
definition of each transaction in section 8. Open
Trading Protocol Transactions.
The TPO Block should contain:
o the Protocol Options Component
o the Organisation Component with the Trading Role of Merchant
o the Organisation Component with the Trading Role of Consumer
o optionally, the Organisation Component with the Trading Role
of DeliverTo, if there is a Delivery included in the IOTP
Transaction
o Brand List Components for each payment in the IOTP Transaction
o Organisation Components for all the Payment Handlers involved
o optionally, Organisation Components for the Delivery Handler
(if any) for the transaction
o additional Organisation Components that the Merchant may want
to include. For example
- a Customer Care Provider
- an Certificate Authority that offers Merchant "Credentials" or
some other warranty on the goods or services being offered.
7.2 TPO Selection Block
The TPO Selection Block contains the results of selections made from
the options contained in the Trading Protocol Options Block (see
section 7.1).The definition of a TPO Selection Block is as follows.
David Burdett et al. [Page 131]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the TPO
Selection Block within the IOTP Transaction.
Content:
BrandSelection This identifies the choice of payment brand and
payment protocol to be used in a payment within
the IOTP Transaction. There is one Brand Selection
Component (see section 6.7) for each payment to be
made in the IOTP Transaction.
The TPO Selection Block should contain one Brand Selection Component
for each Brand List in the TPO Block.
7.3 Offer Response Block
The Offer Response Block contains details of the goods, services,
amount, delivery instructions or financial transaction which is to
take place. Its definition is as follows.
<!ELEMENT OfferRespBlk (Status, AuthData*, Order?, Payment*,
Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the Offer
Response Block within the IOTP Transaction.
Content:
Status Contains status information about the business
success (see section 4.2) or failure of the
generation of the Offer. Note that in an Offer
Response Block, a ProcessState of NotYetStarted or
InProgress are illegal values.
AuthData The Authentication Data Component contains
information about how Authentication associated
with the Offer will occur. See section 6.2.
Order The Order Component contains details about the
goods, services or financial transaction which is
taking place see section 6.4.
David Burdett et al. [Page 132]
Internet Draft IOTP/1.0 23 October 1998
The Order Component must be present unless the
ProcessState attribute of the Status Component is
set to Failed.
Payment The Payment Components contain information about
the payments which are to be made see section 6.8.
Delivery The Delivery Component contains details of the
delivery to be made (see section 6.12).
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an OTP Transaction (see
section 6.16).
The Offer Response Block should contain:
o the Order Component for the IOTP Transaction
o Payment Components for each Payment in the IOTP Transaction
o the Delivery Component for IOTP Transaction requires (if any)
o the Authentication Data Component (if required) for each
Payment
7.4 Authentication Request Block
This Authentication Request Block contains the challenge data which is
used to obtain information about and optionally authenticate a
Consumer by another Trading Role. Its definition is as follows.
<!ELEMENT AuthReqBlk (AuthData?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
Attributes
ID An identifier which uniquely identifies the
Authentication Request Block within the IOTP
Transaction.
Content
AuthData If the Authentication Data Component is not
present it means that the Authentication Request
Block is just requesting the return of
Organisation Components which describe the
Consumer.
If the optional Authentication Data Component (see
section 6.2) is present it contains data which
describes what additional Authentication the
consumer must provide.
David Burdett et al. [Page 133]
Internet Draft IOTP/1.0 23 October 1998
7.5 Authentication Response Block
The Authentication Response Block contains the response which results
from processing the Authentication Request Block. Its definition is as
follows.
<!ELEMENT AuthRespBlk (AuthResp, Org+) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Authentication Response Block within the IOTP
Transaction.
Content:
AuthResp The Authentication Response Component which
contains the results of processing the challenge
data in the Authentication Data Component - see
section 6.3.
Org Organisation Components which contain information
corresponding to the Consumer and DelivTo Trading
Roles.
7.6 Payment Request Block
The Payment Request Block contains information which requests that a
payment is started. Its definition is as follows.
<!ELEMENT PayReqBlk (Status+, AuthData?, BrandList,
BrandSelection, Payment, PaySchemeData?, Org*,
TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Request Block within the IOTP Transaction.
Content:
Status Contains the Status Components (see section 6.12)
of the responses of the steps (e.g. an Offer
Response and/or a Payment Response) on which this
step depends. It is used to indicate the success
or failure of those steps. Payment should only
occur of the previous steps were successful.
David Burdett et al. [Page 134]
Internet Draft IOTP/1.0 23 October 1998
AuthData The optional Authentication Data Component
contains data about how Authentication associated
with the payment, if any, will occur. See section
6.2.
BrandList The Brand List Component contains a list of one or
more payment brands and protocols which may be
selected (see section 6.6).
BrandSelection This identifies the choice of payment brand, the
payment protocol and the payment handler to be
used in a payment within the IOTP Transaction.
There is one Brand Selection Component (see
section 6.7) for each payment to be made in the
IOTP Transaction.
Payment The Payment Components contain information about
the payment which is being made see section 6.8.
PaySchemeData The Payment Scheme Component contains payment
scheme specific data see section 6.9.
Org The Organisation Component contains details of
organisations involved in the payment (see section
6.5). The Organisations present are dependent on
the IOTP Transaction and the data which is to be
signed. See section 5 Security Considerations for
more details.
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an OTP Transaction (see
section 6.16).
The Payment Request Block should contain:
o the Organisation Component with a Trading Role of Merchant
o the Organisation Component with the Trading Role of Consumer
o the Payment Component for the Payment
o the Brand List Component for the Payment
o the Brand Selection Component for the Brand List
o the Organisation Component for the Payment Handler of the
Payment
o the Organisation Component (if any) for the Organisation which
carried out the previous step, for example another Payment
Handler
o the Organisation Component for the organisation which is to
carry out the next step, if any. This may be, for example,
either a Delivery Handler or a Payment Handler.
o the Organisation Components for any additional Organisations
that the Merchant has included in the Offer Response Block
David Burdett et al. [Page 135]
Internet Draft IOTP/1.0 23 October 1998
o an Optional Payment Scheme Data Component, if required by the
Payment Method as defined in the IOTP supplement for the
payment method
o any Trading Role Data Components that may be required (see
section 6.16.1).
7.7 Payment Exchange Block
The Payment Exchange Block contains payment scheme specific data which
is exchanged between two of the roles in a trade. Its definition is as
follows.
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Exchange Block within the IOTP
Transaction.
Content:
PaySchemeData This Trading Component contains payment scheme
specific data see section 6.9 Payment Scheme
Component.
7.8 Payment Response Block
This Payment Response Block contains a information about the Payment
Status, a Payment Receipt, and an optional payment protocol message.
Its definition is as follows.
<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Response Block within the IOTP
Transaction.
Content:
Status Contains status information about the business
success (see section 4.2) or failure of the
David Burdett et al. [Page 136]
Internet Draft IOTP/1.0 23 October 1998
payment. Note that in a Pay Response Block, a
ProcessState of NotYetStarted or InProgress are
illegal values.
PayReceipt Contains payment scheme specific data which can be
used to verify the payment occurred. See section
6.10 Payment Receipt Component.
PaySchemeData Contains payment scheme specific data see section,
for example a payment protocol message. See 6.9
Payment Scheme Component.
PaymentNote Contains additional, non payment related,
information which the Payment Handler wants to
provide to the Consumer. For example, if a
withdrawal or deposit were being made then it
could contain information on the remaining balance
on the account after the transfer was complete.
See section 6.11 Payment Note Component.
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an OTP Transaction (see
section 6.16).
7.9 Delivery Request Block
The Delivery Request Block contains details of the goods or services
which are to be delivered together with a signature which can be used
to check that delivery is authorised. Its definition is as follows.
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Request Block within the IOTP
Transaction.
Content:
Status Contains the Status Components (see section 6.12)
of the responses of the steps (e.g. a Payment
Response) on which this step is dependent. It is
used to indicate the success or failure of those
steps. Delivery should only occur of the previous
steps were successful.
David Burdett et al. [Page 137]
Internet Draft IOTP/1.0 23 October 1998
Order The Order Component contains details about the
goods, services or financial transaction which is
taking place see section 6.4.
Org The Organisation Components (see section 6.5)
identify the organisations and their roles in the
IOTP Transaction. The roles and organisations
which must be present will depend on the
particular type of IOTP Transaction. See the
definition of each transaction in section 8. Open
Trading Protocol Transactions.
Delivery The Delivery Component contains details of the
delivery to be made (see section 6.12).
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an OTP Transaction (see
section 6.16).
The Delivery Request Block contains:
o the Organisation Component with a Trading Role of Merchant
o the Organisation Component for the Consumer and DeliverTo
Trading Roles
o the Delivery Component for the Delivery
o the Organisation Component for the Delivery Handler.
Specifically the Organisation Component identified by the
ActionOrgRef attribute on the Delivery Component
o the Organisation Component (if any) for the Organisation which
carried out the previous step, for example a Payment Handler
o the Organisation Components for any additional Organisations
that the Merchant has included in the Offer Response Block
o any Trading Role Data Components that may be required (see
section 6.16.1).
7.10 Delivery Response Block
The Delivery Response Block contains a Delivery Note containing
details on how the goods will be delivered. Its definition is as
follows. Note that in a Delivery Response Block a Delivery Status
Element with a DeliveryStatusCode of NotYetStarted or InProgress is
invalid.
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
David Burdett et al. [Page 138]
Internet Draft IOTP/1.0 23 October 1998
Delivery Response Block within the IOTP
Transaction.
Content:
Status Contains status information about the business
success (see section 4.2) or failure of the
delivery. Note that in a Delivery Response Block,
a ProcessState of NotYetStarted or InProgress are
illegal values.
DeliveryNote The Delivery Note Component contains details about
how the goods or services will be delivered (see
section 6.13).
7.11 Payment Instrument Customer Care Request Block
The Payment Instrument Customer Care Request Block contains
information which requests that an IOTP Payment Instrument Customer
Care Transaction is started in order to provide Customer Care for the
Consumer's Payment Instrument. Its definition is as follows.
<!ELEMENT PayInstCCReqBlk (PaymethodInfo, PaySchemeData*) >
<!ATTLIST PayInstCCReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Request Block
within the IOTP Transaction.
Content:
PayMethodInfo The Payment Method Information Component (see
section 6.14) contains data which describes the
Payment Method which initiated the Payment
Instrument Customer Care Transaction
PaySchemeData Optional Payment Scheme Components (see section
6.9) that contain payment scheme specific data.
The sequence of the Payment Scheme Components in
the Block is the sequence in which they should be
processed by the Payment Scheme software which
receives this message.
David Burdett et al. [Page 139]
Internet Draft IOTP/1.0 23 October 1998
7.12 Payment Instrument Customer Care Exchange Block
The Payment Instrument Customer Care Exchange Block contains payment
scheme specific data which is exchanged between the Payment Instrument
User and the Payment Scheme Customer Care Provider. Its definition is
as follows.
<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Exchange Block
within the IOTP Transaction.
Content:
PaySchemeData Optional Payment Scheme Components (see section
6.9) that contain payment scheme specific data.
The sequence of the Payment Scheme Components in
the Block is the sequence in which they should be
processed by the Payment Scheme software which
receives this message.
7.13 Payment Instrument Customer Care Response Block
The Payment Instrument Customer Care Response Block contains the final
Payment Scheme Component of the IOTP Payment Instrument Customer Care
Transaction. Its definition is as follows.
<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Instrument Customer Care Response Block
within the IOTP Transaction.
Content:
PaySchemeData Optional Payment Scheme Components (see section
6.9) that contain payment scheme specific data.
The sequence of the Payment Scheme Components in
the Block is the sequence in which they should be
processed by the Payment Scheme software which
receives this message.
David Burdett et al. [Page 140]
Internet Draft IOTP/1.0 23 October 1998
7.14 Inquiry Request Trading Block
The Inquiry Request Trading Block contains an Inquiry Type Component
and an optional Payment Scheme Component to contain payment scheme
specific inquiry messages.
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Request Trading Block within the IOTP
Transaction.
Content:
InquiryType Inquiry Type Component (see section 6.17) that
contains the type of inquiry.
PaySchemeData Payment Scheme Component (see section 6.9) that
contains payment scheme specific inquiry messages
for inquiries on payments. This is present when
the Type attribute of Inquiry Type Component is
Payment.
7.15 Inquiry Response Trading Block
The Inquiry Response Trading Block contains a Status Component and an
optional Payment Scheme Component to contain payment scheme specific
inquiry messages. Its purpose is to enquire on the current status of
an IOTP transaction at a server.
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedOtpMsgRef NMTOKEN #IMPLIED
LastSentOtpMsgRef NMTOKEN #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Response Trading Block within the IOTP
Transaction.
LastReceivedOtpMsgRef Contains an Element Reference (see section
3.5) to the Message Id Component (see section
3.3.2) of the last message this server has
received from the Consumer. If there is no
previously received message from the Consumer
David Burdett et al. [Page 141]
Internet Draft IOTP/1.0 23 October 1998
in the pertinent transaction, this attribute
should be contain the value Null. This
attribute exists for debugging purposes.
LastSentOtpMsgRef Contains an Element Reference (see section
3.5) to the Message Id Component (see section
3.3.2) of the last message this server has
sent to the Consumer. If there is no
previously sent message to the Consumer in the
pertinent transaction, this attribute should
contain the value Null. This attribute exists
for debugging purposes.
Content:
Status Contains status information about the business
success (see section 4.2) or failure of a certain
trading exchange (i.e., Offer, Payment, or
Delivery).
PaySchemeData Payment Scheme Component (see section 6.9) that
contains payment scheme specific inquiry messages
for inquiries on payments. This is present when
the Type attribute of StatusType attribute of the
Status Component is set to Payment.
7.16 Ping Request Block
The Ping Request Block is used to determine if a Server is operating
and whether or not cryptography is compatible.
The definition of a Ping Request Block is as follows.
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
Attributes:
ID An identifier which uniquely identifies the Ping
Request Trading Block within the IOTP Transaction.
Content:
Org Optional Organisation Components (see section
6.5).
If no Organisation Component is present then the
Ping Request is anonymous and simply determines if
the server is operating.
David Burdett et al. [Page 142]
Internet Draft IOTP/1.0 23 October 1998
However if Organisation Components are present,
then it indicates that the sender of the Ping
Request wants to verify that digital signatures
can be handled.
In this case the sender includes:
o an Organisation Component that identifies
itself specifying the Trading Role(s) it is
taking in IOTP transactions (Merchant, Payment
Handler, etc)
o an Organisation Component that identifies the
intended recipient of the message.
These are then used to generate a signature over
the Ping Response Block.
7.17 Ping Response Block
The Ping Response Trading Block provides the result of a Ping Request.
It contains an Organisation Component that identifies the sender of
the Ping Response.
If the Ping Request to which this block is a response contained
Organisation Components, then it also contains those Organisation
Components.
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok|Busy|Down) #REQUIRED
SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
Attributes:
ID An identifier which uniquely identifies the Ping
Request Trading Block within the IOTP
Transaction.
PingStatusCode Contains a code which shows the status of the
sender software which processes IOTP messages.
Valid values are:
o Ok. Everything with the service is working
normally, including the signature
verification.
o Busy. Things are working normally but there
may be some delays.
o Down. The server is not functioning fully but
David Burdett et al. [Page 143]
Internet Draft IOTP/1.0 23 October 1998
can still provide a Ping response.
SigVerifyStatusCode Contains a code which shows the status of
signature verification. This is present only
when the message containing the Ping Request
Block also contains a Signature Block. Valid
values are:
o Ok. The signature has successfully been
verified and proved compatible.
o NotSupported The receiver of this Ping Request
Block does not support validation of
signatures.
o Fail. Signature verification failed.
Xml:lang Defines the language used in PingStatusDesc.
This is present when PingStatusDesc is present.
PingStatusDesc Contains a short description of the status of
the server which sends this Ping Response Block.
Servers, if their designers want, can use this
attribute to send more refined status
information than PingStatusCode which can be
used for debugging purposes, for example.
Content:
Org These are Organisation Components (see section
6.5).
The Organisation Components of the sender of the
Ping Response is always included in addition to
the Organisation Components sent in the Ping
Request.
[Note] Ping Status Code values do not include a value such as Fail,
since, when the software receiving the Ping Request message
is not working at all, no Ping Response message will be sent
back.
[Note End]
7.18 Signature Block
The Signature Block contains one or more Signature Components and
associated Certificates which sign data associated with the IOTP
Transaction. For a general discussion and introduction to how IOTP
uses signatures, see section 5 Security Considerations. The definition
of the Signature Component and certificates is contained in the paper
"Digital Signature for XML - Proposal", see [XMLSIG].
The definition of a Signature Block is as follows:
David Burdett et al. [Page 144]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Signature Block within the IOTP Transaction.
Content:
OtpSig Contains a Digital Signature. See the paper
"Digital Signature for XML - Proposal" [XMLSIG],
for its definition
OtpCert Contains a Digital Certificate. See the paper
"Digital Signature for XML - Proposal" [XMLSIG],
for its definition
The contents of a Signature Block depends on the Trading Block that is
contained in the same IOTP Message as the Signature Block.
7.18.1 Offer Response
A Signature Block which is in the same message as an Offer Response
Block contains just an Offer Response Signature Component (see section
6.18.1).
7.18.2 Payment Request
A Signature Block which is in the same message as a Payment Request
Block contains:
o an Offer Response Signature Component (see section 6.18.1),
and
o if the Payment is dependent on an earlier step (as indicated
by the StartAfter attribute on the Payment Component), then
the Payment Receipt Signature Component (see section 6.18.2)
generated by the previous step
7.18.3 Payment Response
A Signature Block which is in the same message as a Payment Response
Block contains just a Payment Receipt Signature Component (see section
6.18.2) generated by the step.
7.18.4 Delivery Request
A Signature Block which is in the same message as a Delivery Request
Block contains:
David Burdett et al. [Page 145]
Internet Draft IOTP/1.0 23 October 1998
o an Offer Response Signature Component (see section 6.18.1),
and
o the Payment Receipt Signature Component (see section 6.18.2)
generated by the previous step.
7.19 Error Block
The Error Trading Block contains one or more Error Components (see
section 6.19) which contain information about Technical Errors (see
section 4.1) in an IOTP Message which has been received by one of the
Trading Roles involved in the trade.
For clarity two phrases are defined which are used in the description
of an Error Trading Block:
o message in error. An IOTP message which contains or causes an
error of some kind
o message reporting the error. An IOTP message that contains an
Error Trading Block that describes the error found in a
message in error.
An Error Trading Block may be contained in any message reporting the
error. The action which then follows depends on the severity of the
error. See the definition of an Error Component, for an explanation of
the different types of severity and the actions which can then occur.
[Note] Although, an Error Trading Block can report multiple
different errors using multiple Error Components, there is
no obligation on a developer of an IOTP Aware Application to
do so.
[Note End]
The structure of an Error Trading Block is as follows.
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the Error
Trading Block within the IOTP Transaction.
Content:
ErrorComp An Error Component (see section 6.19) that
contains information about an individual
Technical Error.
PaySchemeData An optional Payment Scheme Component (see section
6.9) which contains a Payment Scheme Message. See
the appropriate payment scheme supplement to
David Burdett et al. [Page 146]
Internet Draft IOTP/1.0 23 October 1998
determine whether or not this component needs to
be present and for the definition of what it must
contain.
8. Open Trading Protocol Transactions
The Baseline Open Trading Protocol supports the following types of
Baseline IOTP Transactions:
o Authentication
o Deposit
o Purchase
o Refund
o Withdrawal
o Baseline Value Exchange
o Payment Instrument Customer Care
o Transaction Status Inquiry, and
o Ping
Each of these transactions are described in more detail in the
following sections providing descriptions of:
o the Trading Blocks in each IOTP Transaction
o the Trading Components in each Trading Block, and
o how the Trading Components are signed
[Note] There are many similarities between the transactions within
IOTP. This is because there is a lot of reuse of the Trading
Blocks between the different transactions.
This means that there should be significant opportunity for
software re-use. For example, from an IOTP perspective, the
Deposit, Refund and Withdrawal transactions are essentially
the same, although the processing which will occur,
especially at the server end, will differ.
[Note End]
8.1 Baseline Authentication IOTP Transaction
In a Baseline Authentication IOTP Transaction:
o the Authenticator is the organisation which is requesting the
authentication, and
o the Authenticatee is the organisation being authenticated.
A Baseline Authentication IOTP Transaction may occur at any time
between any of the Trading Roles involved in OTP Transactions. This
means it could occur:
o before another IOTP Transaction
o at the same time as another IOTP Transaction
o independently of any other IOTP Transaction.
David Burdett et al. [Page 147]
Internet Draft IOTP/1.0 23 October 1998
The authentication consists of:
o an Authentication Request being sent by the Authenticator to
the Authenticatee, and
o an Authentication Response being sent in return by the
Authenticatee to the Authenticator which is then checked.
A Baseline Authentication IOTP Transaction also:
o provides an Authenticatee with an Organisation Component which
describes the Authenticator, and
o optionally provides the Authenticator with Organisation
Components which describe the Authenticatee
The Authentication Request may also be digitally signed which allows
the Authenticatee to verify the credentials of the organisation which
requesting the authentication.
An Authenticatee may decline to be authenticated by sending setting
the CompletionCode of the Status Component in the Authentication
Response Block to Declined.
Example uses of the Baseline Authentication IOTP Transaction include:
o when the Baseline Authentication IOTP Transaction takes place
as an early part of a session where strong continuity exists.
For example, a Financial Institution could:
- set up a secure channel (e.g. using SSL) with a customer
- authenticate the customer using the Baseline Authentication IOTP
Transaction, and then
- provide the customer with access to account information and
other services with the confidence that they are communicating
with a bona fide customer.
o as a means of providing a Merchant role with Organisation
Components that contain information about Consumer and DelivTo
Trading Roles
o so that a Consumer may authenticate a Payment Handler before
starting a payment.
The Baseline Authentication IOTP Transaction consists of just the
Authentication Trading Exchange (see section 2.2.4).
The Trading Blocks used by the Baseline Authentication IOTP
Transaction are:
o Trading Protocol Options Block
o Signature Block
o Authentication Request Block, and
o Authentication Response Block
There are no variations of the Baseline Authentication IOTP
Transaction.
The IOTP Messages used in a Baseline Authentication are illustrated in
the diagram below.
ORGANISATION 1 OTP MESSAGE ORGANISATION 2
David Burdett et al. [Page 148]
Internet Draft IOTP/1.0 23 October 1998
1. First organisation 2. The second
takes an action (for organisation generates
example by pressing a ---------------------> an Authentication
button on an HTML Authentication Need Request Block
page) which requires (outside scope of OTP) containing challenge
that the organisation data and the method of
is authenticated authentication to be
used then sends it to
the first organisation
|
v
3. OTP aware application OTPMsg:Trans
started. If a Signature Block <-------------------- Ref Block;
is present the first TPO & Signature
organisation may use this to Authentication Block; TPO
check the credentials of the Request Block; Auth.
second organisation. If it is Response Block;
OK the first organisation
uses the challenge data and
the authentication method
specified in the
Authentication Request Block
to generate an Authentication
Response Block which is sent
back to the first
organisation. Optionally
keeps information on OTP
Transaction for record
keeping purposes and stops
|
v
OTPMsg: Trans 4. The second organisation
Ref Block; ----------------------> checks the Authentication
Signature Authentication Response Response against the
Block; Auth challenge data in the
Response Block Authentication Request Block
| to check that the first
v organisation is who they
STOP appear to be, and stops.
|
v
STOP
Figure 19 Baseline Authentication
The remainder of this sub-section on the Baseline Authentication IOTP
Transaction defines the contents of each Trading Block.
David Burdett et al. [Page 149]
Internet Draft IOTP/1.0 23 October 1998
8.1.1 Trading Protocol Options Block
The TPO (Trading Protocol Options) Block (see section 7.1) must
contain the following Trading Component:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
8.1.2 Authentication Request Block
The Authentication Request Block (see section 7.4) must contain the
following Trading Component:
o one Authentication Data Component (see section 6.2)
o one Organisation Component (see section 6.5) which describes
the Authenticator
8.1.3 Signature Block (Authentication Request)
If the Authentication Request is being digitally signed then a
Signature Block must be included in the same IOTP message that
contains an Authentication Request Block. The Signature Component
contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Authentication
Request Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the TPO Block :
- the Protocol Options Component
o the following components of the Authentication Request Block:
- the Authentication Data Component
8.1.4 Authentication Response Block
The Authentication Response Block (see section 7.5) must contain the
following Trading Component:
o one Authentication Response Component (see section 6.3)
o one Organisation Component for every Trading Role identified
in the TradingRoleList attribute of the Authentication Data
Component contained in the Authentication Request Block.
8.1.5 Signature Block (Authentication Response)
If the AuthMethod attribute of the Authentication Data Component
contained in the Authentication Request Block indicates that the
Authentication Response should consist of a digital signature then a
Signature Block must be included in the same IOTP message that
David Burdett et al. [Page 150]
Internet Draft IOTP/1.0 23 October 1998
contains an Authentication Response Block. The Signature Component
contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Authentication
Request Block within the IOTP Transaction. It contains
information that identifies the IOTP Message and IOTP
Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Authentication Request Block:
- the Authentication Data Component
o the Organisation Components contained in the Authentication
Response Block
[Note] It should not be assumed that all trading roles can support
the signing of data. Particularly it should not be assumed
that Consumers support the signing of data.
[Note End]
8.2 Baseline Deposit IOTP Transaction
The Baseline Deposit IOTP Transaction supports the deposit of
electronic cash with a Financial Institution.
[Note] The Financial Institution has, in IOTP terminology, a role
of merchant in that a service (i.e. a deposit of electronic
cash) is being offered in return for a fee, for example bank
charges of some kind. The term "Financial Institution" is
used in the diagrams and in the text for clarity.
[Note End]
The Baseline Deposit IOTP Transaction consists of the following
Trading Exchanges:
o an optional Authentication Exchange (see section 2.2.4),
o an Offer Exchange (see section 2.2.1), and
o a Payment Exchange (see section 2.2.2).
These Trading Exchanges are implemented by a set of predefined IOTP
Messages (see section o) which are exchanged between the Trading Roles
(see section 2.1). Each IOTP Message contains Trading Blocks (see
section 7) which contain the Trading Components (see section 6) which
are required by the Trading Exchanges.
The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
o Trading Protocol Options Block
o TPO Selection Block
o Authentication Request Block
o Authentication Response Block
o Offer Response Block
o Payment Request Block
o Payment Exchange Block
David Burdett et al. [Page 151]
Internet Draft IOTP/1.0 23 October 1998
o Payment Response Block
o Signature Block
8.2.1 Baseline Deposit Variations
The Baseline Deposit IOTP Transaction occurs in two basic forms:
o Baseline Deposit with Authentication. Where the Consumer
making the deposit is authenticated before the deposit is
made, and
o Baseline Deposit without Authentication. Where the Consumer is
not authenticated before the deposit is made.
In both these forms it is assumed that the Payment Brand being used is
determined before the Baseline Deposit transaction starts. This means
that Brand Selection is limited to Payment Protocol selection only.
8.2.2 Baseline Deposit Authentication
In Baseline Deposit with Authentication an Authentication Exchange
occurs before the Offer Exchange containing the details of the deposit
is provided by the Financial Institution.
In Baseline Deposit without Authentication, there is no Authentication
Exchange and the Financial Institution provides details about the
deposit immediately at the start of the IOTP Transaction.
These two alternatives are illustrated in the two diagrams below. The
first diagram illustrates the case when an Authentication Exchange is
included.
CONSUMER OTP MESSAGE FINANCIAL INSTITUTION
1. Consumer decides 2. The Financial
to deposit Institution sets the
electronic cash and -------------------- payment brand and decides
sends information > which protocols to offer,
about how much to Deposit Information generates an
deposit, the brand (outside scope of Authentication Request
to be used, etc to OTP) Block containing challenge
the Financial data and the method of
Institution, e.g. authentication and sends
using HTML to the Consumer
|
v
3. OTP aware application started. OTPMsg:Tran
The consumer selects the payment <--------------------- s Ref
protocol to use, records TPO & Block; TPO
selection in a Brand Selection Authentication Request Block;
Component, generates an Auth.Respon
Authentication Response Component se Block
and sends back to the Financial
Institution.
David Burdett et al. [Page 152]
Internet Draft IOTP/1.0 23 October 1998
|
v
OTPMsg: Trans 4. The Financial Institution
Ref Block; Auth --------------------> checks the Authentication
Response Block; TPO Selection & Response against the challenge
TPO Selection Authentication data in the Authentication
Response Request Block, uses the
information to identify the
consumer, generates an Offer
Response Block containing
information about the deposit,
and optional Signature Block
and sends to the Consumer
|
v
5. Consumer checks Offer is OK, OTPMsg: Trans
combines components from the TPO Ref Block;
Block, the TPO Selection Block and <---------------- Signature
the Offer Response Block to create a Offer Response Block; Offer
Pay Request Block and sends to the Response Block
Payment Handler with the Signature
Block if present
| Note that the Financial Institution
v has, in OTP terminology, a role of
CONTINUED "Merchant".
Figure 20 Baseline Deposit with Authentication
Note that the above diagram:
o describes the general case where a Merchant can accept a
deposit in several different types of electronic cash. In
practice usually only one form of electronic cash may be
accepted. However, there may be several different protocols
which may be used for the same "brand" of electronic cash.
o the financial institution may use the results of the
authentication to identify not only the consumer but also the
account to which the payment is to be deposited. If no single
account can be identified, then it must be obtained by other
means. For example:
- the consumer could specify the account number in the initial
dialogue (see step 1), or
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an account
selected from a list provided by the Financial Institution.
The second diagram illustrates the case when an Authentication
Exchange is not included.
CONSUMER OTP MESSAGE FINANCIAL INSTITUTION
1. Consumer decides 2. Financial Institution
to deposit electronic sets the payment brand and
cash and sends ------------------> decides which protocols to
David Burdett et al. [Page 153]
Internet Draft IOTP/1.0 23 October 1998
information about how Deposit Information offer, generates an Offer
much to deposit, the (outside scope of Response Block containing
brand to use, etc to OTP) information about the
the Financial deposit, an optional
Institution, e.g. Signature Block and sends
using HTML to the Consumer
|
v
3. OTP aware application started. OTPMsg:Trans
Consumer selects the payment protocol to <------------ Ref Block;
use, records selection in a Brand TPO & Signature
Selection Component, checks Offer is Offer Block; TPO
OK, combines the Brand Selection Response Block; Offer
Component with information from the TPO Response
Block and Offer Response Block to create Block
a Pay Request Block and sends it to the
Payment Handler together with optional
Signature Block
|
v Note that the Financial Institution has,
CONTINUED in OTP terminology, a role of "Merchant".
Figure 21 Baseline Deposit without Authentication
The Baseline Deposit without authentication might be used:
o if a previous IOTP transaction, for example a Baseline
Withdrawal or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained, therefore
the authenticity of the consumer is known
o if authentication is achieved as part of a proprietary payment
protocol and is therefore included in the Payment Exchange
o if authentication of the consumer has been achieved by some
other means outside of the scope of IOTP, for example, by
using a pass phrase.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Deposit includes
an Authentication Exchange or not.
8.2.3 Baseline Deposit Payment Messages
Once the Offer Response Trading Block has been received, the sequence
of IOTP Messages illustrated in Figure 22 occurs. These are the same
whether or not an Authentication of the Consumer has occurred. Note
that these continue where the previous diagrams (Figure 20 and Figure
21) finish.
CONSUMER OTP MESSAGE PAYMENT HANDLER
3/5. Consumer generates Pay
Request Block encapsulating a
David Burdett et al. [Page 154]
Internet Draft IOTP/1.0 23 October 1998
payment protocol message if
required and sends to Payment
Handler with the Signature Block
if present
|
v
OtpMsg: Trans 6. Payment Handler processes Pay Request
Ref Block; ----------> Block, checks optional signature and
Signature Payment starts exchanging payment protocol
Block; Pay Request messages, encapsulated in a Pay Exchange
Request Block Block, with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <-----------------> Ref Block; Pay
Exchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block
|
v
8. Eventually payment protocol messages
finish so Payment Handler creates Pay
Receipt Component inside a Pay Response
Block, and an optional Signature
Component inside the Signature Block,
sends to Consumer and stops
|
v
9. Consumer checks Pay OtpMsg: Trans Ref Block;
Response is OK. Optionally <------------- Signature Block; Pay
keeps information on OTP Payment Response Block
Transaction for record Response |
keeping purposes and stops v
| STOP
v
STOP
Figure 22 Baseline Deposit Payment Messages
The remainder of this sub-section on the Baseline Deposit IOTP
Transaction defines the contents of each Trading Block. For most
Trading Blocks, the content does not alter with the variations
described above. Where differences apply, these are stated.
8.2.4 TPO (Trading Protocol Options) Block
The TPO (Trading Protocol Options) Block (see section 8.3.2) must
contain the following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
David Burdett et al. [Page 155]
Internet Draft IOTP/1.0 23 October 1998
o one Brand List Component (see section 6.6) which contains the
payment brand and protocols which may be selected for use in
the Payment Exchange
o Organisation Components (see section 6.5) with the following
roles:
- the Merchant who is accepting the deposit
- the Consumer who is making the deposit
- the PaymentHandlers for the payment
8.2.5 TPO Selection Block
The TPO Selection Block (see section 7.2) is only used by Baseline
Deposit with Authentication. It contains:
o one Brand Selection Component (see section 6.7) for use in the
Payment Exchange. It contains the results of the consumer
selecting a Payment Brand and Payment Protocol from the list
provided in the Brand List Component.
8.2.6 Authentication Request Block
The Authentication Request Block (see section 7.4) must contain the
following Trading Component:
o one Authentication Data Component (see section 6.2)
8.2.7 Authentication Response Block
The Authentication Response Block (see section 7.5) must contain the
following Trading Component:
o one Authentication Response Component (see section 6.3).
8.2.8 Offer Response Block
The Offer Response Block (see section 7.3) must contain the following
components:
o zero or one Authentication Data Component (see section 6.2) An
Authentication Data Component is required for each Payment
Exchange, where its Payment Component contains an AuthDataRef
attribute
o one Order Component (see section 6.4) which contains details
about the deposit, for example the amount of value being
deposited and any fees which might apply
o one Payment Component (see section 6.8) which contains
information about the payment which is to be made
o one Delivery Component (see section 6.12) with the DelivExch
attribute set to False
The Offer Response Block may also contain one or more Trading Role
Data Components (see section 6.16).
David Burdett et al. [Page 156]
Internet Draft IOTP/1.0 23 October 1998
[Note] A role of Merchant is used in the above description since a
service (i.e. a deposit of electronic cash) is being offered
in return for a fee, for example bank charges of some kind.
The term "Financial Institution" is used in the diagrams and
in the text for clarity.
[Note End]
8.2.9 Signature Block (Offer Response)
If the Baseline Deposit Offer Response is being digitally signed then
a Signature Block must be included in the same IOTP message that
contains an "Offer Response" Signature Component (see section 6.18).
The Signature Component contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Offer Response
Block within the IOTP Transaction. It contains information
that identifies the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
- the Authentication Data Component if present
- the Order Component
- the Payment Component
- all the Organisation Components present, and
- the Delivery Component
- any Trading Role Data Components
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
If the Baseline Deposit is a Baseline Deposit with Authentication then
the Signature Component additionally contains a hash of the following:
o the Brand Selection Component contained in the TPO Selection
Block.
8.2.10 Payment Request Block
The Payment Request Block (see section 7.6) contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component if present
- the Payment Component
- the Organisation Components with the roles of: Merchant and
PaymentHandler
o the following component from the TPO Block:
- the Brand List Component
o one Brand Selection Component either:
- copied from the Offer Response Block if the deposit is a
Baseline Deposit with Authentication, or
David Burdett et al. [Page 157]
Internet Draft IOTP/1.0 23 October 1998
- created by the Consumer, containing the payment brand and
payment protocol selected, if the deposit is a Baseline Deposit
without Authentication
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed).
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Payment Handlers should check that they are authorised to carry out
the Payment (see section 5 Security Considerations).
8.2.11 Signature Block (Payment Request)
If the Baseline Deposit Offer Response Block was signed then the IOTP
Message that contains the Payment Request Block must also contain a
Signature Block with a copy of the "Offer Response" Signature
Component.
8.2.12 Payment Exchange Block
The Payment Exchange Block (see section 7.7) contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain.
8.2.13 Payment Response Block
The Payment Response Block (see section 7.8) contains:
o one Payment Receipt Component(see section 6.10) which contains
scheme specific data which can be used to verify the payment
occurred
o one Payment Scheme Component (see section 6.9) if required
which contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain
o the "Offer Response" Signature Component (see section 6.18)
from the Payment Request Block if present.
The Payment Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
8.2.14 Signature Block (Payment Response)
If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
David Burdett et al. [Page 158]
Internet Draft IOTP/1.0 23 October 1998
Response Block being set to True, then the IOTP Message that contains
the Payment Response Block must also contain a Signature Block with a
"Payment Receipt" Signature Component which contains hashes of the
following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block,
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block,
o any Trading Role Data Components in the Payment Response
Block, and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
8.3 Baseline Purchase IOTP Transaction
The Baseline Purchase IOTP Transaction supports the purchase of goods
or services using any payment method. It consists of the following
Trading Exchanges:
o an Offer Exchange (see section 2.2.1),
o a Payment Exchange (see section 2.2.2), and
o an optional Delivery Exchange (see section 2.2.3)
These Trading Exchanges are implemented by a set of predefined IOTP
Messages (see section o) which are exchanged between the Trading Roles
(see section 2.1). Each IOTP Message contains Trading Blocks (see
section 7) which contain the Trading Components (see section 6) which
are required by the Trading Exchanges.
The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
o Trading Protocol Options Block
o TPO Selection Block
o Offer Response Block
o Payment Request Block
o Payment Exchange Block
o Payment Response Block
o Delivery Request Block
o Delivery Response Block
o Signature Block
8.3.1 Baseline Purchase Variations
The Baseline Purchase IOTP Transaction occurs in two basic forms:
o Brand Dependent Purchase. Where the content of the offer, e.g.
the order details, amount, delivery details, etc., are
David Burdett et al. [Page 159]
Internet Draft IOTP/1.0 23 October 1998
dependent on the payment brand and protocol selected by the
consumer, and
o Brand Independent Purchase. Where the content of the offer is
not dependent on the payment brand and protocol selected.
Further variation is supported in that:
o the Delivery Exchange is optional, and
o the Delivery Response Block may be sent to the consumer
either:
- at the same time as the Payment Response Block, or
- after the Payment Response Block as the result of the Consumer
sending the Delivery Handler a Delivery Request Block.
8.3.1.1 Brand Dependent Purchases
In a Brand Dependent Purchase the TPO Block and the Offer Response
Block are sent separately by the Merchant to the Consumer, i.e.:
o the Brand List Component is sent to the Consumer in a TPO
Block,
o the Consumer selects a Payment Brand, Payment Protocol and
optionally a Currency and amount from the Brand List Component
o the Consumer sends the selected brand, protocol and
currency/amount back to the Merchant in a TPO Selection Block,
and
o the Merchant uses the information received to define the
content of and then send the Offer Response Block to the
Consumer.
In a Brand Independent Purchase the TPO Block and the Offer Response
Block are sent together by the Merchant to the Consumer in the same
IOTP Message at the start of the IOTP Transaction.
These two alternatives are illustrated in the two diagrams below. The
first diagram illustrates a Brand Dependent Purchase.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer decides 2. Merchant decides which
to trade and sends payment brand and
information about --------------------> protocols to offer, places
what to purchase to Purchase Information them in a Brand List
the Merchant, e.g. (outside scope of Component in a TPO Block,
using HTML OTP) and sends to Consumer
|
v
3. OTP aware application started. Consumer OTPMsg:
selects the payment brand and payment <----------- Trans Ref
protocol to use, records selection in a TPO Block; TPO
Brand Selection Component, and sends back Block
to Merchant
|
v
David Burdett et al. [Page 160]
Internet Draft IOTP/1.0 23 October 1998
OTPMsg:Trans 4. Merchant uses payment brand and
Ref Block; TPO ------------> protocol selected and information on
Selection TPO Selection what is being purchased to create an
Block Offer Response Block containing details
about goods ordered, price, etc.
optionally signs it and sends to
Consumer
|
v
5. Consumer checks Offer is OK, OTPMsg:Trans
combines components from the TPO <--------------- Ref Block;
Block, the TPO Selection Block and Offer Response Signature
the Offer Response Block to create Block; Offer
a Pay Request Block and sends it to Response Block
the Payment Handler together with
the Signature Block if present
|
v
CONTINUED
Figure 23 Brand Dependent Baseline Purchase
The second diagram illustrates the Brand Independent Purchase.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer 2. Merchant decides which
decides to payment brand and protocols to
trade and sends --------------------> offer, places them in a Brand
information Purchase Information List Component in a TPO Block,
about what to (outside scope of creates an Offer Response
purchase to the OTP) Block containing details about
Merchant, e.g. goods ordered, price, etc,
using HTML optionally signs it and sends
to Consumer
|
v
3. OTP aware application OTPMsg: Trans Ref
started. Consumer selects the <------------- Block; Signature
payment brand and payment TPO & Block; TPO Block;
protocol to use, records Offer Response Offer Response Block
selection in a Brand Selection
Component, checks Offer is OK,
combines the Brand Selection
Component with information from
the TPO Block and Offer Response
Block to create a Pay Request
Block and sends it to the
Payment Handler together with
the Signature Block if present
|
v
CONTINUED
David Burdett et al. [Page 161]
Internet Draft IOTP/1.0 23 October 1998
Figure 24 Brand Independent Baseline Purchase
A Brand Independent Purchase always occurs when only one payment brand
and protocol is being offered to the Consumer by the Merchant. It is
also likely to, but will not necessarily, occur when multiple brands
are being offered, the Payment Handler is the same, and all brands use
the same set of protocols.
Note that the TPO Block and the Offer Response Block may be sent in
separate IOTP messages even if the Offer Response Block does not
change. However this increases the number of messages in the
transaction and is therefore likely to increase transaction response
times.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Offer Response Block in the first IOTP
Message to determine whether the Baseline Purchase is brand dependent
or not.
8.3.1.2 Combining Delivery Response Block and Payment Response Block
The Delivery Response Block and the Payment Response Block may be
sent:
o separately by the Payment Handler to the Consumer, i.e.:
- the Payment Response Block containing a Payment Receipt and
optional signature for the payment is sent by the Payment
Handler to the Consumer,
- the Consumer combines these components from the Payment Response
Block with components from the Offer Response Block, to create a
Delivery Request Block
- the Consumer sends the Delivery Request Block to the Delivery
Handler
- the Delivery Handler processes the Delivery Request Block and
sends a Delivery Response Block back to the Consumer, or
o together, from the Payment Handler to the Consumer, when the
Payment Exchange is complete.
These two alternatives are illustrated in the two diagrams below.
The first diagram illustrates when the Delivery Response Block and the
Payment Response Block are sent to the Consumer in separate IOTP
Messages. Note, these diagrams continue where the previous diagrams
(Figure 23 and Figure 24) finish.
CONSUMER OTP MESSAGE PAYMENT HANDLER
3/5. Consumer generates Pay Request
Block encapsulating a payment
protocol message if required and
sends to Payment Handler
|
David Burdett et al. [Page 162]
Internet Draft IOTP/1.0 23 October 1998
v
tpMsg: Trans Ref 6. Payment Handler checks optional
Block; Signature -------------> signature, processes Pay Request
Block; Pay Payment Block, and starts exchanging payment
Request Block Request protocol messages, encapsulated in a
Pay Exchange Block, with the
Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <-----------------> Ref Block; Pay
xchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block
|
v
8. Eventually payment protocol
messages finish so Payment Handler
creates Pay Receipt Component and
inside a Pay Response Block, and an
optional Signature Component in the
Signature Block, sends to Consumer
and stops
|
v
9. Consumer checks Pay Response is OtpMsg: Trans
OK, and creates Delivery Request <--------------- Ref Block;
from Pay Response Block, Offer Payment Response Signature Block
Response Block and Signature Block Pay Response
and sends to the Delivery Handler Block
| ====================================================
v DELIVERY HANDLER
tpMsg: Trans Ref 10. Delivery Handler checks Pay
Block; Signature -------------> Receipt, Order in Offer Response and
Block Delivery Delivery the optional Signatures, creates a
Request Block Request Delivery Response Block, sends to
Consumer and stops
|
v
10. Consumer checks Delivery OtpMsg: Trans Ref
Response Block is OK, <------------- Block; Delivery
ptionally keeps information on Delivery Response Block
OTP Transaction for record Response |
keeping purposes and stops v
STOP
|
v
STOP
Figure 25 Baseline Purchase, Delivery Response Block and Payment
Response Blocks Not Combined
David Burdett et al. [Page 163]
Internet Draft IOTP/1.0 23 October 1998
The second diagram illustrates the case when the Delivery Response
Block and the Payment Response Block are combined into one IOTP
Message.
CONSUMER OTP MESSAGE MERCHANT
3/5. Consumer generates Pay
Request Block encapsulating a
payment protocol message if
required and sends to Payment
Handler together with Signature
Block if present
|
v
OtpMsg: Trans 6. Payment Handler processes Pay
Ref Block; -------------> Request, and starts exchanging
Signature Block; Payment payment protocol messages,
Pay Request Request encapsulated in a Pay Exchange
Block Block, with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <-----------------> Ref Block; Pay
xchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block
|
v
8. Eventually payment protocol
messages finish so Payment
Handler creates Pay Receipt
Component inside a Pay Response
Block and an optional Signature
Component, then uses information
from the Offer Response Block to
create a Delivery Response Block,
sends both to Consumer and stops
|
v
9. Consumer checks Pay OtpMsg: Trans Ref Block;
Response and Delivery <--------------- Signature Block; Pay
Response Blocks are OK, Payment Response Response Block; Delivery
optionally keeps & Delivery Response Block
information on OTP Response |
Transaction for record v
keeping purposes and stops STOP
|
v
STOP
Figure 26 Baseline Purchase, Delivery Response Block and Payment
Response Block Combined
David Burdett et al. [Page 164]
Internet Draft IOTP/1.0 23 October 1998
The Delivery Response Block and the Payment Response Block may be
combined into the same IOTP Message only if the Payment Handler has
the information available so that she can send the Delivery Response
Block. This is likely to, but will not necessarily, occur when the
Merchant, the Payment Handler and the Delivery Handler Roles are
combined.
The DelivAndPayResp attribute of the Delivery Component (see section
6.12) contained within the Offer Response Block (see section 7.3) is
set to True if the Delivery Response Block and the Payment Response
Block are combined into the same IOTP Message and is set to False if
the Delivery Response Block and the Payment Response Block are sent in
separate IOTP Messages.
8.3.1.3 Optional Delivery Exchange
The final variation of the Baseline Purchase IOTP Transactions is a
purchase without a delivery step. This is illustrated in the following
diagram which continues where the earlier diagrams (Figure 23and
Figure 24) finish.
CONSUMER OTP MESSAGE MERCHANT
3/5. Consumer generates Pay
Request Block encapsulating a
payment protocol message if
required and sends to Payment
Handler together with Signature
Block if present
|
v
OtpMsg: Trans Ref 6. Payment Handler checks
Block; Signature ---------------> signature, processes Pay Request
Block; Pay Request Payment Request Block, and starts exchanging
Block payment protocol messages,
encapsulated in a Pay Exchange
Block, with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <-----------------> Ref Block; Pay
Exchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block |
|
v
8. Eventually payment protocol
messages finish so Payment
Handler creates Pay Receipt
Component inside a Pay
Response Block and optional
Signature Component, sends to
Consumer and stops
David Burdett et al. [Page 165]
Internet Draft IOTP/1.0 23 October 1998
|
v
9. Consumer checks Pay OtpMsg: Trans Ref Block;
Response is OK, <------------ Signature Block; Pay
optionally keeps Payment Response Block
information on OTP Response |
Transaction for record v
keeping purposes and STOP
stops
|
v
STOP
Figure 27 Baseline Purchase, Purchase without Delivery Exchange
The DelivExch attribute of the Delivery Component (see section 6.12)
contained in the Offer Response Block (see section 7.3) is set to
False if the Delivery Exchange is omitted and is set to True if the
Delivery Exchange is included.
8.3.1.4 Combining Variations
The diagram below shows how the different variations in the Baseline
Purchase Transaction may be combined.
START
|
v
Offer Response Block in first OTP Message?
|=True |=False
v v
Brand Brand
Independent Dependent
Purchase Purchase
| =True =False |
------------ -----------
| |
v v
DelivExch ?
=True | | =False
----------- ------------
| |
v v
DelivAndPayResp ? Purchase without
| | Delivery Exchange
=False| |=True |
-------- -------- v
| | STOP
v v
Delivery Response Delivery
David Burdett et al. [Page 166]
Internet Draft IOTP/1.0 23 October 1998
Block and Pay Response Block
Response Blocks and Pay Response
Not Combined Blocks Combined
| |
v v
STOP STOP
Figure 28 Baseline Purchase Variations
The remainder of this sub-section on the Baseline Purchase IOTP
Transaction defines the contents of each Trading Block. For most
Trading Blocks, the content does not alter with the variations
described above. Where differences apply, these are stated.
8.3.2 TPO (Trading Protocol Options) Block
The TPO (Trading Protocol Options) Block (see section 8.3.2) must
contain the following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
o one Brand List Component (see section 6.6) which contains one
or more payment brands and protocols which may be selected for
use in the Payment Exchange
o Organisation Components (see section 6.5) with the following
roles:
- Merchant who is providing the goods or services
- Consumer who is making the purchase
- PaymentHandlers for the payment.
8.3.3 TPO Selection Block
The TPO Selection Block (see section 7.2) is only used by Brand
Dependent Purchase. It contains:
o one Brand Selection Component (see section 6.7) for use in the
Payment Exchange. It contains the results of the consumer
selecting a Payment Brand and Payment Protocol from the list
provided in the Brand List Component.
8.3.4 Offer Response Block
The Offer Response Block (see section 7.3) contains the following
components:
o zero or one Authentication Data Component (see section 6.2) An
Authentication Data Component is required for each Payment
Exchange, where its Payment Component (see section 6.8)
contains an AuthDataRef attribute.
o one Order Component (see section 6.4) which contains details
about the goods, services which are being purchased
David Burdett et al. [Page 167]
Internet Draft IOTP/1.0 23 October 1998
o one Payment Component (see section 6.8) which contains
information about the payment which is to be made
o Organisation Components (see section 6.5) with the following
roles:
- Merchant who is providing the goods or services
- Consumer who is making the purchase
- PaymentHandler for the payment. The "ID" of the Payment Handler
Organisation Component is contained within the VaOrgRef
attribute of the Payment Component
o one Delivery Component (see section 6.12) which contains
details of the delivery to be made.
If the Baseline Purchase includes a Delivery Exchange then the Offer
Response Block must also contain:
o Organisation Components with the following roles:
- DeliveryHandler who will be delivering the goods or services
- DelivTo i.e. the person or organisation which is to take
delivery
The Offer Response Block may also contain one or more Trading Role
Data Components (see section 6.16).
8.3.5 Signature Block (Offer Response)
If the Baseline Purchase Offer Response is being digitally signed then
a Signature Block must be included in the same IOTP message that
contains an "Offer Response" Signature Component (see section 6.18).
The Signature Component contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Offer Response
Block within the IOTP Transaction. It contains information
that identifies the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
- the Authentication Data Component if present
- the Order Component
- the Payment Component
- all the Organisation Components present, and
- the Delivery Component,
- any Trading Role Data Components
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
If the Baseline Purchase is a Brand Dependent Purchase then the
Signature Component additionally contains a hash of the following:
o the Brand Selection Component contained in the TPO Selection
Block.
David Burdett et al. [Page 168]
Internet Draft IOTP/1.0 23 October 1998
8.3.6 Payment Request Block
The Payment Request Block (see section 7.6) contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component if present
- the Payment Component
- the Organisation Components with the roles of: Merchant and
PaymentHandler
o the following component from the TPO Block:
- the Brand List Component
o one Brand Selection Component either:
- copied from the Offer Response Block if the purchase is a Brand
Dependent Purchase, or
- created by the Consumer, containing the payment brand and
payment protocol selected, if the purchase is a Brand
Independent Purchase
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed).
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Payment Handlers should check that they are authorised to carry out
the Payment (see section 5 Security Considerations).
8.3.7 Signature Block (Payment Request)
If the Baseline Purchase Offer Response Block was signed then the IOTP
Message that contains the Payment Request Block must also contain a
Signature Block with a copy of the "Offer Response" Signature
Component.
8.3.8 Payment Exchange Block
The Payment Exchange Block (see section 7.7) contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain.
8.3.9 Payment Response Block
The Payment Response Block (see section 7.8) contains:
o one Payment Receipt Component (see section 6.10) which
contains scheme specific data which can be used to verify the
payment occurred
o one Payment Scheme Component (see section 6.9) if required
which contains payment method specific data. See the Payment
David Burdett et al. [Page 169]
Internet Draft IOTP/1.0 23 October 1998
Method supplement for the payment method being used to
determine what this should contain
o the "Offer Response" Signature Component (see section 6.18)
from the Payment Request Block if present
The Payment Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
8.3.10 Signature Block (Payment Response)
If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
Response Block being set to True, then the IOTP Message that contains
the Payment Response Block must also contain a Signature Block with a
"Payment Receipt" Signature Component which contains hashes of the
following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block
o any Trading Role Data Components in the Payment Response
Block, and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
8.3.11 Delivery Request Block
The Delivery Request Block (see section 7.9) contains:
o the following components copied from the Offer Response Block:
- the Status Component (see section 6.15)
- the Order Component (see section 6.4)
- the Organisation Component (see section 6.5) with the roles of:
Merchant, DeliveryHandler and DeliverTo
- the Delivery Component (see section 6.12)
o the following Component from the Payment Response Block:
- the Status Component (see section 6.15).
The Delivery Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Payment Handlers should check that they are authorised to carry out
the Payment (see section 5 Security Considerations).
David Burdett et al. [Page 170]
Internet Draft IOTP/1.0 23 October 1998
8.3.12 Signature Block (Delivery Request)
If the Baseline Purchase Offer Response or Payment Response Blocks
were signed then the IOTP Message that contains the Delivery Request
Block must also contain a Signature Block with a copy of:
o the "Offer Response" Signature Component if present, and/or
o the "Payment Receipt" Signature Component, if present
8.3.13 Delivery Response Block
The Delivery Response Block contains:
o one Delivery Note Component (see section 6.13) which contains
delivery instructions about the delivery of goods or services
8.4 Baseline Refund IOTP Transaction
In business terms the refund process typically consists of:
o a request for a refund being made by the Consumer to the
Merchant, typically supported by evidence to demonstrate:
- the original trade took place, for example by providing a
receipt for the original transaction
- using some type of authentication, that the consumer requesting
the refund is the consumer, or a representative of the consumer,
who carried out the original trade
- the reason why the merchant should make the refund
o the merchant agreeing (or not) to the refund. This may involve
some negotiation between the Consumer and the Merchant, and,
if the merchant agrees,
o a refund payment by the Merchant to the Consumer.
The Baseline Refund IOTP Transaction supports a subset of the above,
specifically it supports:
o the optional authentication of the Consumer using an
Authentication Exchange (see section 2.2.4), and
o the refund payment by the Merchant to the Consumer using the
following two Trading Exchanges:
- an Offer Exchange (see section 2.2.1), and
- a Payment Exchange (see section 2.2.2).
These Trading Exchanges are implemented by a set of predefined IOTP
Messages (see section o) which are exchanged between the Trading Roles
(see section 2.1). Each IOTP Message contains Trading Blocks (see
section 7) which contain the Trading Components (see section 6) which
are required by the Trading Exchanges.
The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
o Trading Protocol Options Block
o TPO Selection Block
o Authentication Request Block
o Authentication Response Block
David Burdett et al. [Page 171]
Internet Draft IOTP/1.0 23 October 1998
o Offer Response Block
o Payment Request Block
o Payment Exchange Block
o Payment Response Block
o Signature Block
8.4.1 Baseline Refund Variations
The Baseline Refund IOTP Transaction occurs in two basic forms:
o Baseline Refund with Authentication. Where the Consumer
requesting the refund is authenticated before the refund is
made, and
o Baseline Refund without Authentication. Where the Consumer is
not authenticated before the refund is made.
8.4.2 Baseline Refund Authentication
In Baseline Refund with Authentication an Authentication Exchange
occurs before the Offer Exchange containing the details of the refund
is provided by the Merchant.
In Baseline Refund without Authentication, there is no Authentication
Exchange and the Merchant provides details about the refund
immediately at the start of the IOTP Transaction.
These two alternatives are illustrated in the two diagrams below. The
first diagram illustrates the case when an Authentication Exchange is
included.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer requests 2. The Merchant sets the
payment of payment brand and decides
previously agreed ------------------> which protocols to offer,
refund, sends Refund Information generates an
information about (outside scope of Authentication Request
refund, such as a OTP) Block containing challenge
reference number to data and the method of
the Merchant, e.g. authentication and sends
using HTML to the Consumer
|
v
3. OTP aware application OTPMsg:Trans Ref
started. The consumer selects <-------------- Block; TPO Block;
payment protocol to use, TPO & Auth.Response Block
records selection in a Brand Authentication
Selection Component, generates Request
an Authentication Response
Component and sends both back
to the Merchant.
|
v
David Burdett et al. [Page 172]
Internet Draft IOTP/1.0 23 October 1998
OTPMsg: Trans 4. The Merchant checks the
Ref Block; ---------------> Authentication Response against the
Auth Response TPO Selection & challenge data in the Authentication
Block; TPO Authentication Request Block, uses the information
Selection Response to identify the consumer and refund,
Block generates an Offer Response Block
containing information about the
refund, an optional Signature Block
and sends to the Consumer
|
v
5. Consumer checks Offer is OK, OTPMsg: Trans
combines components from the TPO <--------------- Ref Block;
Block, the TPO Selection Block and Offer Response Signature
the Offer Response Block to create Block; Offer
a Pay Request Block and sends to Response Block
the Payment Handler together with
optional Signature
|
v
CONTINUED
Figure 29 Baseline Refund with Authentication
The second diagram illustrates the case when an Authentication
Exchange is not included.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer requests 2. Merchant sets the payment
payment of previously brand and decides which
agreed refund, sends --------------> protocols to offer,
information about Refund generates an Offer Response
refund to the Merchant, Information Block containing information
such as a reference (outside scope about the refund, an
number, using, for of OTP) optional Signature Block and
example, HTML sends to the Consumer
|
v
3. OTP aware application started. OTPMsg:Trans
Consumer selects the payment protocol <-------------- Ref Block;
to use, records selection in a Brand TPO & Signature
Selection Component, checks Offer is Offer Response Block; TPO
OK, combines the Brand Selection Block; Offer
Component with information from the TPO Response
Block and Offer Response Block to Block
create a Pay Request Block and sends it
to the Payment Handler together with
optional Signature Block
|
v
CONTINUED
David Burdett et al. [Page 173]
Internet Draft IOTP/1.0 23 October 1998
Figure 30 Baseline Refund without Authentication
The Baseline Refund without authentication might be used:
o when authentication of the consumer has been achieved by some
other means, for example, the consumer has entered some
previously supplied code in order to identify herself and the
refund to which the code applies. The code could be supplied,
for example on a web page or by e-mail.
o when a previous IOTP transaction, for example a Baseline
Authentication, authenticated the consumer, and a secure
channel has been maintained, therefore the authenticity of the
consumer is known and therefore the previously agreed refund
can be identified.
o when the authentication of the consumer is carried out by the
Payment Handler using a payment scheme authentication method.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Refund includes
an Authentication Exchange or not.
8.4.3 Baseline Refund Payment Messages
Once the Offer Response Trading Block has been received, the sequence
of IOTP Messages illustrated in Figure 31 occurs. These are the same
whether or not an Authentication of the Consumer has occurred. Note
that these continue where the previous diagrams (Figure 29 and Figure
30) finish.
CONSUMER OTP MESSAGE PAYMENT HANDLER
3/5. Consumer generates Pay
Request Block encapsulating a
payment protocol message if
required and sends to Payment
Handler together with optional
Signature Block
|
v
tpMsg: Trans Ref 6. Payment Handler checks signature,
Block; Signature ------------> processes Pay Request Block, and
Block; Pay Payment starts exchanging payment protocol
Request Block Request messages, encapsulated in a Pay
Exchange Block, with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <-----------------> Ref Block; Pay
xchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block
|
v
David Burdett et al. [Page 174]
Internet Draft IOTP/1.0 23 October 1998
8. Eventually payment protocol
messages finish so Payment Handler
creates Pay Receipt Component
inside a Pay Response Block, sends
to Consumer with and optional
Signature Component and stops
|
v
9. Consumer checks Pay OtpMsg: Trans Ref Block;
esponse is OK. Optionally <--------------- Signature Block; Pay
keeps information on OTP Payment Response Response Block
Transaction for record |
eeping purposes and stops v
| STOP
v
STOP
Figure 31 Baseline Refund Payment Messages
The remainder of this sub-section on the Baseline Refund IOTP
Transaction defines the contents of each Trading Block. For most
Trading Blocks, the content does not alter with the variations
described above. Where differences apply, these are stated.
8.4.4 TPO (Trading Protocol Options) Block
The TPO (Trading Protocol Options) Block (see section 8.3.2) must
contain the following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
o one Brand List Component (see section 6.6) which contains the
payment brand and protocols which may be selected for use in
the Payment Exchange
o Organisation Components (see section 6.5) with the following
roles:
- the Merchant who is making the refund
- the Consumer who is requesting the refund
- the PaymentHandlers for the payment.
8.4.5 TPO Selection Block
The TPO Selection Block (see section 7.2) is only used by Baseline
Refund with Authentication. It contains:
o one Brand Selection Component (see section 6.7) for use in the
Payment Exchange. It contains the results of the consumer
selecting a Payment Brand and Payment Protocol from the list
provided in the Brand List Component.
David Burdett et al. [Page 175]
Internet Draft IOTP/1.0 23 October 1998
8.4.6 Authentication Request Block
The Authentication Request Block (see section 7.4) must contain the
following Trading Component:
o one Authentication Data Component (see section 6.2)
8.4.7 Authentication Response Block
The Authentication Response Block (see section 7.5) must contain the
following Trading Component:
o one Authentication Response Component (see section 6.3).
8.4.8 Offer Response Block
The Offer Response Block (see section 7.3) must contain the following
components:
o zero or one Authentication Data Component (see section 6.2) An
Authentication Data Component is required for each Payment
Exchange, where its Payment Component contains an AuthDataRef
attribute
o one Order Component (see section 6.4) which contains details
about the refund, for example the amount being refunded and
any conditions which might apply
o one Payment Component (see section 7.2) which contains
information about the payment which is to be made
o one Delivery Component (see section 6.12) with the DelivExch
attribute set to False.
The Offer Response Block may also contain one or more Trading Role
Data Components (see section 6.16).
8.4.9 Signature Block (Offer Response)
If the Baseline Refund Offer Response is being digitally signed then a
Signature Block must be included in the same IOTP message that
contains an "Offer Response" Signature Component (see section 6.18).
The Signature Component contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Offer Response
Block within the IOTP Transaction. It contains information
that identifies the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
- the Authentication Data Component if present
- the Order Component
- the Payment Component
- all the Organisation Components present, and
- the Delivery Component,
- any Trading Role Data Components
David Burdett et al. [Page 176]
Internet Draft IOTP/1.0 23 October 1998
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
If the Baseline Refund is a Baseline Refund with Authentication then
the Signature Component additionally contains a hash of the following:
o the Brand Selection Component contained in the TPO Selection
Block.
8.4.10 Payment Request Block
The Payment Request Block (see section 7.6) contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component if present
- the Payment Component
- the Organisation Components with the roles of: Merchant and
PaymentHandler
o the following component from the TPO Block:
- the Brand List Component
o one Brand Selection Component either:
- copied from the Offer Response Block if the refund is a Baseline
Refund with Authentication, or
- created by the Consumer, containing the payment brand and
payment protocol selected, if the refund is a Baseline Refund
with Authentication
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed).
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Payment Handlers should check that they are authorised to carry out
the Payment (see section 5 Security Considerations).
8.4.11 Signature Block (Payment Request)
If the Baseline Refund Offer Response Block was signed then the IOTP
Message that contains the Payment Request Block must also contain a
Signature Block with a copy of the "Offer Response" Signature
Component.
8.4.12 Payment Exchange Block
The Payment Exchange Block (see section 7.7) contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain.
David Burdett et al. [Page 177]
Internet Draft IOTP/1.0 23 October 1998
8.4.13 Payment Response Block
The Payment Response Block (see section 7.8) contains:
o one Payment Receipt Component (see section 6.10) which
contains scheme specific data which can be used to verify the
payment occurred
o one Payment Scheme Component (see section 6.9) if required
which contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain
o the "Offer Response" Signature Component (see section 6.18)
from the Payment Request Block if present
The Payment Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
8.4.14 Signature Block (Payment Response)
If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
Response Block being set to True, then the IOTP Message that contains
the Payment Response Block must also contain a Signature Block with a
"Payment Receipt" Signature Component which contains hashes of the
following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block,
o any Trading Role Data Components in the Payment Response
Block, and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
8.5 Baseline Withdrawal IOTP Transaction
The Baseline Withdrawal IOTP Transaction supports the withdrawal of
electronic cash from a Financial Institution.
[Note] The Financial Institution has, in IOTP terminology, a role
of merchant in that a service (i.e. a withdrawal of
electronic cash) is being offered in return for a fee, for
example bank charges of some kind. The term "Financial
David Burdett et al. [Page 178]
Internet Draft IOTP/1.0 23 October 1998
Institution" is used in the diagrams and in the text for
clarity.
[Note End]
The Baseline Withdrawal IOTP Transaction consists of the following
Trading Exchanges:
o an optional Authentication Exchange (see section 2.2.4),
o an Offer Exchange (see section 2.2.1), and
o a Payment Exchange (see section 2.2.2).
These Trading Exchanges are implemented by a set of predefined IOTP
Messages (see section o) which are exchanged between the Trading Roles
(see section 2.1). Each IOTP Message contains Trading Blocks (see
section 7) which contain the Trading Components (see section 6) which
are required by the Trading Exchanges.
The Trading Blocks used by the Baseline Purchase IOTP Transaction are:
o Trading Protocol Options Block
o TPO Selection Block
o Authentication Request Block
o Authentication Response Block
o Offer Response Block
o Payment Request Block
o Payment Exchange Block
o Payment Response Block
o Signature Block
8.5.1 Baseline Withdrawal Variations
The Baseline Withdrawal IOTP Transaction occurs in two basic forms:
o Baseline Withdrawal with Authentication. Where the Consumer
making the withdrawal is authenticated before the withdrawal
is made, and
o Baseline Withdrawal without Authentication. Where the Consumer
is not authenticated before the withdrawal is made.
In both these forms it is assumed that the Payment Brand being used is
determined before the Baseline Withdrawal transaction starts. This
means that Brand Selection is limited to Payment Protocol selection
only.
8.5.2 Baseline Withdrawal Authentication
In Baseline Withdrawal with Authentication an Authentication Exchange
occurs before the Offer Exchange containing the details of the
withdrawal is provided by the Financial Institution.
In Baseline Withdrawal without Authentication, there is no
Authentication Exchange and the Financial Institution provides details
about the withdrawal immediately at the start of the IOTP Transaction.
David Burdett et al. [Page 179]
Internet Draft IOTP/1.0 23 October 1998
These two alternatives are illustrated in the two diagrams below. The
first diagram illustrates the case when an Authentication Exchange is
included.
CONSUMER OTP MESSAGE FINANCIAL
INSTITUTION
1. Consumer decides to 2. The Financial Institution
withdraw electronic sets the payment brand and
cash and sends --------------> decides the protocols to
information about how Withdrawal offer, generates an
much to withdraw to the Information Authentication Request Block
Financial Institution, (outside scope containing challenge data
e.g. using HTML of OTP) and the method of
authentication and sends to
the Consumer
|
v
3. OTP aware application OTPMsg:Trans Ref
started. The consumer selects <----------------- Block; TPO
the payment protocol to use, TPO & Block; Auth.
records selection in a Brand Authentication Response Block
Selection Component, generates Request
an Authentication Response
Component and sends back to the
Financial Institution.
|
v
OTPMsg: 4. The Financial Institution checks
Trans Ref ---------------> the Authentication Response against
Block; Auth TPO Selection & the challenge data in the
Response Authentication Authentication Request Block, uses the
Block; TPO Response information to identify the consumer,
Selection generates an Offer Response Block
containing information about the
withdrawal, an optional signature and
sends to the Consumer
|
v
5. Consumer checks Offer is OK, OTPMsg: Trans
combines components from the Ref Block;
TPO Block, the TPO Selection <------------------ Signature Block;
Block and the Offer Response Offer Response Offer Response
Block to create a Pay Request Block
Block and sends to the Payment
Handler together with optional
Signature Block
|
v Note that the Financial Institution
CONTINUED has, in OTP terminology, a role of
"Merchant".
Figure 32 Baseline Withdrawal with Authentication
David Burdett et al. [Page 180]
Internet Draft IOTP/1.0 23 October 1998
Note that the above diagram:
o describes the general case where a Financial Institution can
offer withdrawal of several different types of electronic
cash. In practice usually only one form of electronic cash may
be offered. However, there may be several different protocols
which may be used for the same "brand" of electronic cash
o the financial institution may use the results of the
authentication to identify not only the consumer but also the
account from which the withdrawal is to be made. If no single
account can be identified, then it must be obtained by other
means. For example:
- the consumer could specify the account number in the initial
dialogue (see step 1), or
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an account
selected from a list provided by the Financial Institution.
The second diagram illustrates the case when an Authentication
Exchange is not included.
CONSUMER OTP MESSAGE FINANCIAL
INSTITUTION
1. Consumer decides to 2. Financial Institution
withdraw electronic decides sets the payment
cash and sends ------------> brand and decides which
information about how Withdrawal protocols to offer for
much to withdraw, etc. Information withdrawal, generates an
to the Financial (outside Offer Response Block
Institution, e.g. using scope of OTP) containing information about
HTML the withdrawal, an optional
signature and sends to the
Consumer
|
v
3. OTP aware application started. OTPMsg: Trans
Consumer selects the payment protocol <-------------- Ref Block;
to use, records selection in a Brand TPO & Signature
Selection Component, checks Offer is Offer Response Block; TPO
OK, combines the Brand Selection Block; Offer
Component with information from the Response
TPO Block and Offer Response Block to Block
create a Pay Request Block and sends
it to the Payment Handler together
with optional Signature Block
|
v Note that the Financial
CONTINUED Institution has, in OTP
terminology, a role of
"Merchant".
Figure 33 Baseline Withdrawal without Authentication
David Burdett et al. [Page 181]
Internet Draft IOTP/1.0 23 October 1998
The Baseline Withdrawal without Authentication might be used:
o when a previous IOTP transaction, for example a Baseline
Deposit or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained, therefore
the authenticity of the consumer is known
o when authentication is achieved as part of a proprietary
payment protocol and is therefore included in the Payment
Exchange
o when authentication of the consumer has been achieved by some
other means, for example, by using a pass phrase, or a
proprietary banking software solution.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Authentication Request Block in the
first IOTP Message to determine whether the Baseline Withdrawal
includes an Authentication Exchange or not.
8.5.3 Baseline Withdrawal Payment Messages
Once the Offer Response Trading Block has been received, the sequence
of IOTP Messages illustrated in Figure 34 occurs. These are the same
whether or not an Authentication of the Consumer has occurred. Note
that these continue where the previous diagrams (Figure 32 and Figure
33) finish.
CONSUMER OTP MESSAGE PAYMENT HANDLER
3/5. Consumer generates Pay
Request Block encapsulating a
payment protocol message if
required and sends to Payment
Handler together with optional
Signature Block
|
v
OtpMsg: Trans 6. Payment Handler checks
Ref Block; ---------------> optional signature, processes Pay
Signature Block; Payment Request Request Block, and starts
Pay Request exchanging payment protocol
Block messages, encapsulated in a Pay
Exchange Block, with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <----------------->Ref Block; Pay
Exchange Blocks with Block; Pay Payment Exchange Exchange Block
Payment Handler Exchange Block
|
v
8. Eventually payment protocol
messages finish so Payment
Handler creates Pay Receipt
Component inside a Pay Response
David Burdett et al. [Page 182]
Internet Draft IOTP/1.0 23 October 1998
Block, an optional signature,
sends to Consumer and stops
|
v
9. Consumer checks Pay OtpMsg: Trans Ref Block;
Response is OK. Optionally <------------ Signature Block
keeps information on OTP Payment Pay Response Block
Transaction for record Response |
keeping purposes and stops v
| STOP
v
STOP
Figure 34 Baseline Withdrawal Payment Messages
The remainder of this sub-section on the Baseline Withdrawal IOTP
Transaction defines the contents of each Trading Block. For most
Trading Blocks, the content does not alter with the variations
described above. Where differences apply, these are stated.
8.5.4 TPO (Trading Protocol Options) Block
The TPO (Trading Protocol Options) Block (see section 8.3.2) must
contain the following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
o one Brand List Component (see section 6.6) which contains the
payment brand and protocols which may be selected for use in
the Payment Exchange
o Organisation Components (see section 6.5) with the following
roles:
- the Merchant who is accepting the withdrawal
- the Consumer who is making the withdrawal
- the PaymentHandler for the payment.
8.5.5 TPO Selection Block
The TPO Selection Block (see section 7.2) is only used by Baseline
Withdrawal with Authentication. It contains:
o one Brand Selection Component (see section 6.7) for use in the
Payment Exchange. It contains the results of the consumer
selecting a Payment Brand and Payment Protocol from the list
provided in the Brand List Component.
8.5.6 Authentication Request Block
The Authentication Request Block (see section 7.4) must contain the
following Trading Component:
o one Authentication Data Component (see section 6.2)
David Burdett et al. [Page 183]
Internet Draft IOTP/1.0 23 October 1998
8.5.7 Authentication Response Block
The Authentication Response Block (see section 7.5) must contain the
following Trading Component:
o one Authentication Response Component (see section 6.3).
8.5.8 Offer Response Block
The Offer Response Block (see section 7.3) must contain the following
components:
o zero or one Authentication Data Components (see section 6.2)
An Authentication Data Component is required for each Payment
Exchange, where its Payment Component contains an AuthDataRef
attribute
o one Order Component (see section 6.4) which contains details
about the withdrawal, for example the amount being withdrawn
and any fees which might apply
o one Payment Component (see section 7.2) which contains
information about the payment which is to be made
o one Delivery Component (see section 6.12) with the DelivExch
attribute set to False.
The Offer Response Block may also contain one or more Trading Role
Data Components (see section 6.16).
[Note] In the above an Organisation with a role of Merchant is used
in that a service (i.e. a withdrawal of electronic cash) is
being offered in return for a fee, for example bank charges
of some kind. The term "Financial Institution" is used in
the diagrams and in the text for clarity.
[Note End]
8.5.9 Signature Block (Offer Response)
If the Baseline Withdrawal Offer Response is being digitally signed
then a Signature Block must be included in the same IOTP message that
contains an "Offer Response" Signature Component (see section 6.18).
The Signature Component contains hashes of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Offer Response
Block within the IOTP Transaction. It contains information
that identifies the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
- the Authentication Data Component if present
- the Order Component
- the Payment Component
- all the Organisation Components present
- the Delivery Component,
- any Trading Role Data Components
David Burdett et al. [Page 184]
Internet Draft IOTP/1.0 23 October 1998
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
If the Baseline Withdrawal is a Baseline Withdrawal with
Authentication then the Signature Component additionally contains a
hash of the following:
o the Brand Selection Component contained in the TPO Selection
Block.
8.5.10 Payment Request Block
The Payment Request Block (see section 7.6) contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component if present
- the Payment Component
- the Organisation Components with the roles of: Merchant and
PaymentHandler
o the following component from the TPO Block:
- the Brand List Component
o one Brand Selection Component either:
- copied from the Offer Response Block if the withdrawal is a
Baseline Withdrawal with Authentication, or
- created by the Consumer, containing the payment brand and
payment protocol selected, if the withdrawal is a Baseline
Withdrawal without Authentication
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed).
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Payment Handlers should check that they are authorised to carry out
the Payment (see section 5 Security Considerations).
8.5.11 Signature Block (Payment Request)
If the Baseline Withdrawal Offer Response Block was signed then the
IOTP Message that contains the Payment Request Block must also contain
a Signature Block with a copy of the "Offer Response" Signature
Component.
8.5.12 Payment Exchange Block
The Payment Exchange Block (see section 7.7) contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data. See the Payment Method
David Burdett et al. [Page 185]
Internet Draft IOTP/1.0 23 October 1998
supplement for the payment method being used to determine what
this should contain.
8.5.13 Payment Response Block
The Payment Response Block (see section 7.8) contains:
o one Payment Receipt Component (see section 6.10) which
contains scheme specific data which can be used to verify the
payment occurred
o one Payment Scheme Component (see section 6.9) if required
which contains payment method specific data. See the Payment
Method supplement for the payment method being used to
determine what this should contain
o the "Offer Response" Signature Component (see section 6.18)
from the Payment Request Block if present
The Offer Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
8.5.14 Signature Block (Payment Response)
If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component of the Offer
Response Block being set to True, then the IOTP Message that contains
the Payment Response Block must also contain a Signature Block with a
"Payment Receipt" Signature Component which contains hashes of the
following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block,
o any Trading Role Data Components in the Payment Response
Block, and
o the "Offer Response" Signature Component from the Payment
Request Block if present.
8.6 Baseline Value Exchange IOTP Transaction
The Baseline Value Exchange Transaction uses Payment Exchanges (see
section 2.2.2) to support the exchange of value in one currency
obtained using one payment method with value in the same or another
David Burdett et al. [Page 186]
Internet Draft IOTP/1.0 23 October 1998
currency using the same or another payment method. Examples of its use
include:
o electronic cash advance on a credit card. For example the
first payment could be a dollar SET Payment Exchange on a
credit card with the second Payment Exchange being a download
of DigiCash e-cash in dollars.
o foreign exchange using the same payment method. For example
the payment could be an upload of Mondex value in French
Francs and the second a download of Mondex value in British
Pounds
o foreign exchange using different payment methods. For example
the first payment could be a SET payment in Euros followed a
download of GeldKarte in Deutchmarks.
The Baseline Value Exchange uses three Trading Exchanges:
o an Offer Exchange (see section 2.2.1) which provides details
of what values and currencies will be exchanged, and
o two Payment Exchanges (see section 2.2.2) which carry out the
two payments involved
These Trading Exchanges are implemented by a set of predefined IOTP
Messages (see section o) which are exchanged between the Trading Roles
(see section 2.1). Each IOTP Message contains Trading Blocks (see
section 7) which contain the Trading Components (see section 6) which
are required by the Trading Exchanges.
The Trading Blocks used by the Baseline Value Exchange IOTP
Transaction are:
o Trading Protocol Options Block
o TPO Selection Block
o Offer Response Block
o Payment Request Block
o Payment Exchange Block
o Payment Response Block
o Signature Block
8.6.1 Baseline Value Exchange Variations
The Baseline Value Exchange IOTP Transaction occurs in two basic
forms:
o Brand Dependent Value Exchange. Where the content of the
offer, for example the rate at which one form of value is
exchanged for another, is dependent on the payment brands and
protocols selected by the consumer, and
o Brand Independent Value Exchange. Where the content of the
offer is not dependent on the payment brands and protocols
selected.
In Brand Dependent Value Exchange the TPO Block and the Offer Response
Block are sent separately by the Merchant to the Consumer, i.e.:
o the Brand List Components for the two payments are sent to the
Consumer in a TPO Block,
David Burdett et al. [Page 187]
Internet Draft IOTP/1.0 23 October 1998
o the Consumer selects a Payment Brand and Payment Protocol from
the Brand List Component for each of the payments in the Value
Exchange
o the Consumer sends the selected brands and protocols back to
the Merchant in a TPO Selection Block, and
o the Merchant Uses the information received to define the
content of the Offer Response Block and then sends it to the
Consumer.
[Note] In the above the role is a Merchant even though the
organisation carrying out the Value Exchange may be a Bank
or some other Financial Institution. This is because the
Bank is acting as a merchant in that they are making an
offer which the Consumer can either accept or decline.
[Note End]
In Brand Independent Value Exchange the TPO Block and the Offer
Response Block are sent together by the Merchant to the Consumer in
the same IOTP Message at the start of the IOTP Transaction.
These two alternatives are illustrated in the two diagrams below. The
first diagram illustrates a Brand Dependent Value Exchange.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer decides to 2. Merchant decides which
conduct a Value Exchange --------------> payment brand and protocols
and sends information Value Exchange to offer for each payment,
about the exchange to Information places them in Brand List
the Merchant, e.g. using (outside scope Components in a TPO Block,
HTML of OTP) and sends to Consumer
|
v
3. OTP aware application started. OTPMsg: Trans
Consumer selects the payment brand <--------------- Ref Block; TPO
and payment protocol to use for TPO Block
each payment, records selections
in two Brand Selection Components,
and sends back to Merchant
|
v
OTPMsg:Trans 4. Merchant uses payment brands and
Ref Block; TPO protocols selected to create an Offer
Selection -------------> Response Block containing details
Block TPO Selection about the Value Exchange, e.g.
exchange rates, commission, etc. and
sends to Consumer together with
optional signature
|
v
5. Consumer checks Offer is OK, OTPMsg:Trans
combines components from the TPO <---------------- Ref Block;
Block, the TPO Selection Block Offer Response Signature
and the Offer Response Block to Block; Offer
David Burdett et al. [Page 188]
Internet Draft IOTP/1.0 23 October 1998
create a Pay Request Block for Response Block
the first payment and sends it to
Payment Handler 1 together with
the optional signature
|
v
CONTINUED
Figure 35 Brand Dependent Value Exchange
The second diagram illustrates the a Brand Independent Value Exchange.
CONSUMER OTP MESSAGE MERCHANT
1. Consumer 2. Merchant decides which payment
decides to brand and protocols to offer for each
conduct a Value -----------> payment, places them in Brand List
Exchange and Value Components in a TPO Block, creates an
sends information Exchange Offer Response Block containing
about the Information details about the Value Exchange,
exchange to the (outside e.g. exchange rates, commission, etc.
Merchant, e.g. scope of and sends to Consumer together with
using HTML OTP) optional Signature Block
|
v
3. OTP aware application started. OTPMsg:Trans
Consumer selects the payment brand and <------------- Ref Block;
payment protocol to use for each TPO & Signature
payment, records selections in two Brand Offer Response Block; TPO
Selection Components, checks Offer is Block; Offer
OK, combines the Brand Selection Response
Component for the first payment with Block
information from the TPO Block and Offer
Response Block to create a Pay Request
Block for the first payment and sends it
to Payment Handler 1 with the optional
Signature Block
|
v
CONTINUED
Figure 36 Brand Independent Value Exchange
The TPO Block and Offer Response Block may only be combined into the
same IOTP Message if the content of the Offer Response Block does not
change as a result of selecting the payment brands and payment
protocols to be used in the Value Exchange.
Note that the TPO Block and the Offer Response Block may be sent in
separate IOTP messages even if the Offer Response Block does not
change. However this increases the number of messages in the
David Burdett et al. [Page 189]
Internet Draft IOTP/1.0 23 October 1998
transaction and is therefore likely to increase transaction response
times.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Offer Response Block in the first IOTP
Message to determine whether the Baseline Value Exchange is brand
dependent.
Whether or not the Value Exchange is brand dependent, the exchange of
Trading Blocks between the Consumer and the Payment Handlers are the
same. This is illustrated in the diagram below. Note that this diagram
continues where the previous diagrams (Figure 35 and Figure 36)
finish.
CONSUMER OTP MESSAGE PAYMENT HANDLER 1
3/5. Consumer generates Pay
Request Block encapsulating a
payment protocol message if
required and sends to Payment
Handler 1 with optional
Signature Block
|
v
OtpMsg: Trans 6. Payment Handler 1 processes checks
Ref Block; -----------> signature, Pay Request Block for the
Signature Payment first payment, and starts exchanging
Block; Pay Request 1 payment protocol messages ,
Request Block 1 encapsulated in a Pay Exchange Block,
with the Consumer
|
v
7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <----------------->Ref Block; Pay
Exchange Blocks with Block; Pay Payment Exchange 1 Exchange Block
Payment Handler 1 Exchange Block
|
v
8. Eventually payment protocol
messages finish so Payment
Handler 1 creates Pay Receipt
Component and optional Signature
Component inside a Pay Response
Block for first payment, sends
to Consumer with optional
Signature Block and stops
|
v
9. Consumer checks Pay OtpMsg: Trans Ref
Response for first payment is <----------------- Block; Signature
OK, and creates Pay Request Payment Response 1 Block; Pay
for second payment using Response Block 1
Offer Response Block and |
optionally the signatures and v
David Burdett et al. [Page 190]
Internet Draft IOTP/1.0 23 October 1998
sends to Payment Handler 2 STOP
| ====================================================
v PAYMENT HANDLER 2
OtpMsg: Trans 10. Payment Handler 2 checks signature,
Ref Block; -------> processes Pay Request Block for the second
Signature Block Payment payment, and starts exchanging payment
Pay Request Request protocol messages , encapsulated in a Pay
Block (2) 2 Exchange Block, with the Consumer
|
v
11. Consumer keeps<------>OtpMsg: OtpMsg: Trans
on exchanging Pay Trans Ref <----------------->Ref Block; Pay
Exchange Blocks with Block; Pay Payment Exchange 2 Exchange Block
Payment Handler 2 Exchange Block |
|
12. Eventually payment protocol
messages finish so Payment
Handler 2 creates Pay Receipt
Component and inside a Pay
Response Block for second
payment, sends to Consumer with
optional signature and stops
|
v
13. Consumer checks Payment OtpMsg: Trans Ref
Response Block for second <------------- Block; Signature Block
payment is OK, optionally Payment Pay Response Block 2
keeps information on OTP Response 2 |
Transaction for record keeping v
purposes and stops STOP
|
v
STOP
Figure 37 Baseline Value Exchange Payment Messages
The remainder of this sub-section on the Baseline Value Exchange IOTP
Transaction defines the contents of each Trading Block. The content
does not alter with the variations described above.
8.6.2 PO (Trading Protocol Options) Block
The TPO (Trading Protocol Options) Block (see section 8.3.2) must
contain the following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 6.1.
o two Brand List Components (see section 6.6) one for each
Payment Exchange where each Brand List Component contains one
or more payment brands and protocols which may be selected for
use in the Payment Exchange
David Burdett et al. [Page 191]
Internet Draft IOTP/1.0 23 October 1998
o Organisation Components (see section 6.5) with the following
roles:
- Merchant who is providing the goods or services
- Consumer who is making the purchase
- the PaymentHandlers for the payments.
8.6.3 TPO Selection Block
The TPO Selection Block (see section 7.2) is only used by Brand
Dependent Value Exchange. It contains:
o two Brand Selection Components (see section 6.7). One for each
of the Payment Exchanges. Each Brand Selection Component
contains the results of the consumer selecting a Payment Brand
and Payment Protocol from the list provided in the Brand List
Component.
8.6.4 Offer Response Block
The Offer Response Block (see section 7.3) contains the following
components:
o zero, one or two Authentication Data Component (see section
6.2). An Authentication Data Component is required for each
Payment Exchange, where its Payment Component contains an
AuthDataRef attribute.
o one Order Component (see section 6.4) which contains details
about the Value Exchange, for example, exchange rates,
commission, etc.
o two Payment Components (see section 6.8) which contain
information about each of the two payments which are to be
made
The Offer Response Block may also contain one or more Trading Role
Data Components (see section 6.16).
8.6.5 Signature Block (Offer Response)
If the Baseline Value Exchange Offer Response is being digitally
signed then a Signature Block must be included in the same IOTP
message that contains an "Offer Response" Signature Component (see
section 6.18). The Signature Component contains hashes of the
following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Offer Response
Block within the IOTP Transaction. It contains information
that identifies the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which
globally uniquely identifies the IOTP Transaction
o the following components of the Offer Response Block:
- the Authentication Data Component if present
- the Order Component
David Burdett et al. [Page 192]
Internet Draft IOTP/1.0 23 October 1998
- the two Payment Components
- all the Organisation Components present, and
- any Trading Role Data Components
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
If the Baseline Value Exchange is a Brand Dependent Value Exchange
then the Signature Component additionally contains a hash of the
following:
o the two Brand Selection Components contained in the TPO
Selection Block.
8.6.6 Payment Request Block (first payment)
The Payment Request Block (see section 7.6) for the first payment
contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component for the first payment if
required
- the Payment Component for the first payment
- the Organisation Components with the roles of: Merchant and
PaymentHandler for the first payment
o the following component copied from the TPO Block:
- the Brand List Component for the first payment
o one Brand Selection Component for the first payment which is
either:
- copied from the Offer Response Block if the purchase is a Brand
Dependent Value Exchange, or
- created by the Consumer, containing the payment brand and
payment protocol selected, if the purchase is a Brand
Independent Value Exchange
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed).
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Note that:
o the Payment Component for the first payment is the one within
the Offer Response Block that contains no StartAfter attribute
(see section 6.8)
o the Authentication Data Component to include is identified by
the AuthDataRef attribute of the Payment Component for the
first payment. If no AuthDataRef attribute is present then no
Authentication Data Component is required
o the Payment Handler to include is identified by the Brand
Selection Component (see section 6.7) for the first payment.
Also see section 5.3.1 Check the Action Request was sent to
David Burdett et al. [Page 193]
Internet Draft IOTP/1.0 23 October 1998
the Correct Organisation for an explanation on how Payment
Handlers are identified
o the Brand List Component to include is the one identified by
the BrandListRef attribute of the Payment Component for the
first payment
o the Brand Selection Component to include from the Offer
Response Block is the one that contains an Element Reference
(see section 3.5) which identifies the Brand List Component
for the first payment
8.6.7 Signature Block (Payment Request - first payment)
If the Baseline Value Exchange Offer Response Block was signed then
the IOTP Message that contains the Payment Request Block for the first
payment must also contain a Signature Block with a copy of the "Offer
Response" Signature Component.
8.6.8 Payment Exchange Block (first payment)
The Payment Exchange Block (see section 7.7) for the first payment
contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data for the payment method being used
by the first payment. See the Payment Method supplement for
the payment method being used to determine what this should
contain.
8.6.9 Payment Response Block (first payment)
The Payment Response Block for the first payment (see section 7.8)
contains:
o one Payment Receipt Component (see section 6.10) which
contains scheme specific data which can be used to verify the
first payment occurred
o one Payment Scheme Component (see section 6.9) if required by
the payment method used by the first payment which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain
o the Signature Component (see section 6.18) from the Payment
Request Block for the first payment if present.
The Payment Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
David Burdett et al. [Page 194]
Internet Draft IOTP/1.0 23 October 1998
8.6.10 Signature Block (Payment Response - first payment)
If a signed Payment Receipt is being provided for the first payment,
indicated by the SignedPayReceipt attribute of the Payment Component
for the first payment in the Offer Response Block being set to True,
then the IOTP Message that contains the Payment Response Block for the
first payment must also contain a Signature Block with a "Payment
Receipt" Signature Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block for the first payment,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block
for the first payment
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component for
the first payment,
o the Status Component from the Payment Response Block for the
first payment,
o any Trading Role Data Components in the Payment Response
Block, and
o the "Offer Response" Signature Component from the Payment
Request Block for the first payment, if present.
8.6.11 Payment Request Block (second payment)
The Payment Request Block (see section 7.6) for the second payment
contains:
o the following components copied from the Offer Response Block:
- the Status Component
- the Authentication Data Component for the second payment if
required
- the Payment Component for the second payment
- the Organisation Components with the roles of: Merchant and
PaymentHandler for the second payment
o the following component copied from the TPO Block:
- the Brand List Component for the second payment
o one Brand Selection Component for the second payment which is
either:
- copied from the Offer Response Block if the purchase is a Brand
Dependent Value Exchange, or
- created by the Consumer, containing the payment brand and
payment protocol selected, if the purchase is a Brand
Independent Value Exchange
o one Payment Scheme Component (see section 6.9) if required by
the payment method used (see the Payment Method supplement to
determine if this is needed)
o the following components copied from the Payment Response
Block for the first payment:
- the Status Component
David Burdett et al. [Page 195]
Internet Draft IOTP/1.0 23 October 1998
The Payment Request Block may also contain one or more Trading Role
Data Components (see section 6.16).
Note that:
o the Payment Component for the second payment is the one
within the Offer Response Block that contains a StartAfter
attribute (see section 6.8) that identifies the Payment
Component for the first payment
o the Authentication Data Component to include is identified by
the AuthDataRef attribute of the Payment Component for the
second payment. If no AuthDataRef attribute is present then no
Authentication Data Component is required
o the Payment Handler to include is identified by the Brand
Selection Component (see section 6.7) for the second payment.
Also see section 5.3.1 Check the Action Request was sent to
the Correct Organisation for an explanation on how Payment
Handlers are identified
o the Brand List Component to include is the one identified by
the BrandListRef attribute of the Payment Component for the
second payment
o the Brand Selection Component to include from the Offer
Response Block is the one that contains an Element Reference
(see section 3.5) which identifies the Brand List Component
for the second payment
8.6.12 Signature Block (Payment Request - second payment)
If the Baseline Value Exchange Offer Response Block or the Payment
Response Block for the first payment was signed then the IOTP Message
that contains the Payment Request Block for the second payment must
also contain a Signature Block with a copy of:
o the "Offer Response" Signature Component, if present, and/or
o the "Payment Receipt" Signature Component copied from the
Payment Response Block for the first payment, if present.
8.6.13 Payment Exchange Block (second payment)
The Payment Exchange Block (see section 7.7) for the second payment
contains:
o one Payment Scheme Component (see section 6.9) which contains
payment method specific data for the payment method being used
by the second payment. See the Payment Method supplement for
the payment method being used to determine what this should
contain.
8.6.14 Payment Response Block (second payment)
The Payment Response Block for the second payment (see section 7.8)
contains:
David Burdett et al. [Page 196]
Internet Draft IOTP/1.0 23 October 1998
o one Payment Receipt Component (see section 6.10) which
contains scheme specific data which can be used to verify the
second payment occurred
o one Payment Scheme Component (see section 6.9) if required by
the payment method used by the second payment which contains
payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain
o all the Signature Components (see section 6.18) from the
Payment Request Block for the second payment if present
The Payment Response Block may also contain:
o a Payment Note Component (see section 6.11)
o one or more Trading Role Data Components (see section 6.16).
8.6.15 Signature Block (Payment Response - second payment)
If a signed Payment Receipt is being provided for the second payment,
indicated by the SignedPayReceipt attribute of the Payment Component
for the second payment in the Offer Response Block being set to True,
then the IOTP Message that contains the Payment Response Block for the
second payment must also contain a Signature Block with a "Payment
Receipt" Signature Component which contains hashes of the following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block for the second payment,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies
the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block
for the second payment
o the Status Component from the Payment Response Block for the
second payment, and
o the other Components referenced by the PayReceiptRefs
attribute (if present) of the Payment Receipt Component for
the second payment,
o any Trading Role Data Components in the Payment Response Block
o the "Offer Response" Signature Component from the Payment
Request Block for the second payment, if present, and
o the "Payment Receipt" Signature Component from the Payment
Request Block for the first payment, if present.
8.6.16 Baseline Value Exchange Signatures
The use of signatures to ensure the integrity of a Baseline Value
Exchange is illustrated by the diagram below.
Signature generated OtpMsg (TPO)
by Merchant ensures - Trans Ref Block
integrity of the Offer --------> - - Signature Block
| - TPO Block MERCHANT
David Burdett et al. [Page 197]
Internet Draft IOTP/1.0 23 October 1998
| - Offer Response Block
|
Signature generated by |
the Payment Handler of | OtpMsg (Pay Resp 1)
the first payment binds | - Trans Ref Block PAYMENT
Pay Receipt for the first -----> -> - Signature Block ----- HANDLER
payment to the Offer - Pay Response Block 1 | 1
|
Signature generated by |
the Payment Handler of OtpMsg (Pay Resp 2) | PAYMENT
the second payment binds - Trans Ref Block | HANDLER
the second payment to the -----> - Signature Block <------ 2
first payment and therefore - Pay Response Block 2
to the Offer
Figure 38 Baseline Value Exchange Signatures
If signatures are used then the Payment Handlers should check that all
Signature Components they receive are valid (see section 5 Security
Considerations).
8.7 Payment Instrument Customer Care IOTP Transaction
An IOTP Payment Instrument Customer Care Transaction is used to
provide Payment Brand or Payment Method specific customer care. It
allows Consumer Payment Brand software to exchange information with a
Payment Instrument Customer Care Provider.
The circumstances under which this transaction is used, if any, is
defined in the IOTP Supplement for the Payment Brand.
Note that the IOTP Payment Instrument Customer Care Transaction:
o is initiated by the Consumer Payment Brand software which must
identify the need for the transaction to occur. Note that in
other IOTP Transactions, the transaction is initiated by the
Merchant
o has no TPO Block, as it is initiated by the Consumer
o relies on the Consumer Payment Brand software to identify the
net location of the Payment Instrument Customer Care Provider
to which the first message in the transaction must be sent
o ends when the Payment Scheme Customer Care Service determines
that the exchange of messages with the Consumer is to stop.
Note that a Payment Instrument Customer Care Transaction can be
initiated at any time by a Consumer including in the middle of another
IOTP Transaction. In this case, the transaction shall establish a
different transport session from the ongoing transaction. See the
Mapping to Transport for the Transport Mechanism being used.
David Burdett et al. [Page 198]
Internet Draft IOTP/1.0 23 October 1998
The transaction consists of three types of IOTP messages as
illustrated in the figure below.
CONSUMER OTP MESSAGE PAYMENT INSTRUMENT
(PAYMENT INSTRUMENT CUSTOMER CARE
USER) PROVIDER
1. Consumer Payment Instrument Software
identifies need to contact Payment
Instrument Customer Care Provider then
generates data to place in a Payment
Instrument Customer Care Request Block
and the net location it needs to be
sent to. OTP aware application uses
data to generate the Payment Instrument
Customer Care Request Block then sends
it to the Customer Care Provider.
|
v
OtpMsg: Trans Ref 2. Payment Instrument Customer
Block; Signature --------------> Care Provider processes Payment
Block (Optional); Payment Instrument Customer Care Request
Payment Instrument Instrument Block, and starts exchanging
Cust Care Request Cust. Care Payment Instrument Customer Care
Block Request Exchange Blocks, with the
Consumer.
|
v
3. Consumer keeps on OtpMsg: Trans OtpMsg: Trans
exchanging Payment Ref Block; <-----------------> Ref Block;
Instrument Customer Signature Block Payment Instrument Signature Block
Care Exchange Blocks (optional) Cust. Care Exchange (optional)
with Payment Payment Payment
Instrument Customer Instrument Instrument
Care Provider Cust. Care Cust. Care
Exchange Block Exchange Block
|
v
4. Eventually Payment Instrument
Customer Care Provider software
identifies Payment Instrument
Customer Care Exchanges finished
so generates a Payment Instrument
Customer Care Response Block,
sends it to the Consumer and
stops.
|
v
5. Consumer checks Pay OtpMsg: Trans Ref
Instrument Response is OK, <---------------- Block; Signature Block
optionally keeps Payment (Optional);
information on OTP Instrument Payment Instrument
Transaction for record Cust. Care Cust. Care Response
David Burdett et al. [Page 199]
Internet Draft IOTP/1.0 23 October 1998
keeping purposes and stops Response Block
| |
v v
STOP STOP
Figure 39 IOTP Payment Instrument Customer Care Transaction Message
Flows
The remainder of this sub-section on the Payment Instrument Customer
Care Transaction defines the contents of each Trading Block.
8.7.1 Payment Instrument Customer Care Request Block
The Payment Instrument Customer Care Request Block contains:
o a Payment Method Information Component (see section 6.14)
which describes the Payment Method for which Customer Care is
requested, and
o zero or more optional Payment Scheme Components (see section
6.9) which contain optional Payment scheme data
8.7.2 Payment Instrument Customer Care Exchange Block
The Payment Instrument Customer Care Exchange Block contains:
o a Payment Method Information Component (see section 6.14)
which describes the Payment Method for which Customer Care is
being provided, and
o zero or more optional Payment Scheme Components (see section
6.9) which contain optional Payment scheme data
8.7.3 Payment Instrument Customer Care Response Block
The Payment Instrument Customer Care Response Block contains:
o a Payment Method Information Component (see section 6.14)
which describes the Payment Method for which Customer Care is
complete, and
o zero or more optional Payment Scheme Component (see section
6.9) which contains optional Payment scheme data
8.7.4 Signature Block
Any of the IOTP Messages which contain Payment Instrument Customer
care blocks may also include a Signature Block (see section 7.18)
containing a Signature Component (see section 6.18). How these are
used and what it signs is dependent on the Payment Brand and Payment
method being used. See the IOTP Payment Supplement for the payment
method.
David Burdett et al. [Page 200]
Internet Draft IOTP/1.0 23 October 1998
8.8 Baseline Transaction Status Inquiry IOTP Transaction
The Baseline IOTP Transaction Status Inquiry provides a Consumer with
information on the status of an existing or complete IOTP transaction.
The Trading Blocks used by the Baseline Transaction Status Inquiry
Transaction are:
o an Inquiry Request Trading Block (see section 7.14), and
o an Inquiry Response Trading Block (see section 7.15).
[Note] Note that:
. Consumer Inquiries on Authentication transaction are not
supported.
. Authentication of Consumers as part of an inquiry is not
supported in the Baseline version of IOTP.
[Note End]
8.8.1 Which Trading Roles can receive Inquiry Requests
The Consumer can send a Transaction Status Inquiry Block to the
appropriate Trading Role after the following events have occurred:
o to the Merchant, after sending TPO Selection Block,
o to the Payment Handler, after sending Payment Request Block,
o to the Delivery Handler, after sending Delivery Request Block.
[Note] IOTP does not support sending Inquiry Requests to the
Consumer since the consumer may not be on-line to receive
and process them.
[Note End]
If the Consumer is inquiring on transaction that is not yet complete,
it should send the Inquiry Request Block to the Trading Role to which
it sent the last IOTP message. If the Consumer is inquiring on a
transaction which is complete, there are two alternatives in deciding
the Trading Roles that the Inquiry Request Block should be sent to:
o the Consumer IOTP software can ask the end user to determine
the type of inquiry they want to make, or
o the Consumer IOTP software can send the inquiry request
message to all the Trading Roles that were involved in the
IOTP transaction.
For the second case above, how the Consumer IOTP Aware Application
displays the inquiry response data received from each Trading Role is
up to each implementation.
8.8.2 Transaction Status Inquiry Transport Session
For a Transaction Status Inquiry on an ongoing transaction, the
Consumer shall establish with a Trading Role, a different transport
David Burdett et al. [Page 201]
Internet Draft IOTP/1.0 23 October 1998
session from the ongoing transaction. For a Transaction Status Inquiry
on a past transaction, how the IOTP module on the software at the
Trading Role is started upon the receipt of Inquiry Request message is
defined in each Mapping to Transport supplement for IOTP.
8.8.3 Transaction Status Inquiry Error Handling
Errors in a Transaction Status Inquiry can be categorised into one the
following three cases:
o Business errors (see section 4.2) in the original (inquired)
messages
o Technical errors (see section 4.1) - both IOTP and payment
scheme specific ones - in the original IOTP (inquired)
messages
o Technical errors in the message containing the Inquiry Request
Block itself
The following outlines what the software should do in each case
Business errors in the original messages
Return an Inquiry Response Block containing the Status Component which
was last sent to the Consumer.
Technical errors in the original messages
Return an Inquiry Response Block containing a Status Component. The
Status Component should contain a ProcessState attribute set to
ProcessError. In this case send back an Error Block indicating where
the error was found in the original message.
Technical errors in the Inquiry Request Block
Return an Error message. That is, send back an Error Block containing
the Error Code (see section 6.19.2) which describes the nature of the
error in the Inquiry Request message.
8.8.4 Inquiry Transaction Messages
The following Figure outlines the Baseline IOTP Transaction Status
Inquiry processes on both Consumer and Service Provider sides.
CONSUMER OTP MESSAGE TRADING ROLE
1. The Consumer decides to inquire (Merchant,
on an OTP transaction by, for Payment Handler,
example, cliking the inquiry button Delivery Handler
of the OTP Aware Application. This or Financial
will then generate an Inquiry Institution)
Request Block and send it to the
appropriate Trading Role.
|
David Burdett et al. [Page 202]
Internet Draft IOTP/1.0 23 October 1998
v
OtpMs: Trans Ref 2. The Trading Role checks the
Block; Inquiry ----------> transaction status of the transaction
Request Block Inquiry that is being inquired upon by using
Request the Transaction Id Component of the
Transaction Reference Block. He then
generates the appropriate Inquiry
Response Block based on the status of
the transaction and sends the message
back to the Consumer
|
v
3. The OTP Aware OtpMsg: Trans Ref
Application displays the <---------------- Block; Inquiry
status information to the Inquiry Response Response Block
end user
|
v
STOP
Figure 40 Baseline Transaction Status Inquiry
The remainder of this sub-section on the Baseline Transaction Status
Inquiry IOTP Transaction defines the contents of each Trading Block.
8.8.5 Transaction Reference Block
The Consumer must use the same Transaction Id Component (see section
3.3.1) as in the inquired transaction. The OtpTransId attribute in
this component serves as the key in querying the transaction logs
maintained at the Trading Role's site. The value of the ID attribute
of the Message Id Component should be different from those of the
inquired transaction (see section 3.4.1).
8.8.6 Inquiry Request Block
The Inquiry Request Block (see section 7.14) contains the following
components:
o one Inquiry Type Component (see section 6.17). This identifies
whether the inquiry is on an offer, payment, or delivery.
o zero or one Payment Scheme Component (see section 6.9). This
is for encapsulating payment scheme specific inquiry messages
for inquiries on payment.
8.8.7 Inquiry Response Block
The Inquiry Response Block (see section 7.15) contains the following
components:
David Burdett et al. [Page 203]
Internet Draft IOTP/1.0 23 October 1998
o one Status Component (see section 6.15). This component hold
the status information on the inquired transaction,
o zero or one Payment Scheme Components. These contain for
encapsulated payment scheme specific inquiry messages for
inquiries on payment.
8.9 Baseline Ping IOTP Transaction
The purpose of the Baseline IOTP Ping Transaction is to enable IOTP
aware application software to determine if the IOTP aware application
at another Trading Role is operating and verifying whether or not
signatures can be handled.
The Trading Blocks used by the Baseline Ping IOTP Transaction are:
o a Ping Request Block (see section 7.16)
o a Ping Response Block (see section 7.17), and
o a Signature Block (see section 7.18).
8.9.1 Ping Messages
The following figure outlines the message flows in the Baseline IOTP
Ping Transaction.
OTP TRADING ROLE OTP MESSAGE OTP TRADING ROLE
1. The OTP Aware Application in an
OTP Trading Role decides to check
whether the counterparty OTP
application is up and running. It
generates a Ping Block and optional
Signature Block and sends them to
the other OTP Trading Role.
|
v
OtpMs: Trans Ref --------> 2. The OTP Trading Role which receives
Block; Ping Ping the Ping Request generates a Ping
Request Block Request Response and sends it back to the
sender of the original Ping Request.
|
v
3. The original sender of the OtpMsg: Trans Ref
Ping Request checks the returned <------------ Block; Ping
Ping Response and takes Ping Response Response Block
appropriate action, if necessary
|
v
STOP
Figure 41 Baseline Ping Messages
David Burdett et al. [Page 204]
Internet Draft IOTP/1.0 23 October 1998
The verification that signatures can be handled is indicated by the
sender of the Ping Request Block including:
o Organisation Components that identify itself and the intended
recipient of the Ping Request Block, and
o a Signature Block that signs data in the Ping Request.
In this way the receiver of the Ping Request:
o knows who is sending the Ping Request and can therefore verify
the Signature on the Request, and
o knows who to generate a signature for on the Ping Response.
Note that a Ping Request:
o does not affect any on-going transaction
o does NOT start an IOTP aware application, unlike other IOTP
transaction messages such as TPO or Transaction Status
Inquiry.
All IOTP aware applications must return a Ping Response message to the
sender of a Ping Request message when it is received.
A Baseline IOTP Ping request can also contain an optional Signature
Block. IOTP aware applications can, for example, use the Signature
Block to check the recipient of a Ping Request can successfully
process and check signatures it has received.
For each Baseline Ping IOTP Transaction, each IOTP role shall
establish a different transport session from other IOTP transactions.
Any IOTP Trading Role can send a Ping request to any other IOTP
Trading Role at any time it wants. A Ping message has its own
OtpTransID, which is different from other IOTP transactions.
The remainder of this sub-section on the Baseline Ping IOTP
Transaction defines the contents of each Trading Block.
8.9.2 Transaction Reference Block
The OtpTransId of a Ping transaction should be different from any
other IOTP transaction.
8.9.3 Ping Request Block
If the Ping Transaction is anonymous then no Organisation Components
are included in the Ping Request Block (see section 7.6).
If the Ping Transaction is not anonymous then the Ping Request Block
contains Organisation Components for:
o the sender of the Ping Request Block, and
o the verifier of the Signature Component
David Burdett et al. [Page 205]
Internet Draft IOTP/1.0 23 October 1998
If Organisation Components are present, then it indicates that the
sender of the Ping Request message has generated a Signature Block.
The signature block must be verified by the Trading Role that receives
the Ping Request Block.
8.9.4 Signature Block (Ping Request)
The Ping Request Signature Block (see section 7.18) contains the
following components:
o one Signature Component (see section 6.18)
o one or more Certificate Components, if required.
8.9.5 Ping Response Block
The Ping Response Block (see section 7.17) contains the following
component:
o the Organisation Component of the sender of the Ping Response
message
If the Ping Transaction is not anonymous then the Ping Response
additionally contains:
o copies of the Organisation Components contained in the Ping
Request Block.
8.9.6 Signature Block (Ping Response)
The Ping Response Signature Block (see section 7.18) contains the
following components:
o one Signature Component (see section 6.18)
o one or more Certificate Components, if required.
9. Retrieving Logos
This section describes how to retrieve logos for display by IOTP aware
software using the Logo Net Locations attribute contained in the Brand
Element (see section 6.6.1) and the Organisation Component (see
section 6.5).
The full address of a logo is defined as follows:
Logo_address ::= Logo_net_location "/" Logo_size
Logo_color_depth ".GIF"
Where:
o Logo_net_location is obtained from the LogoNetLocn attribute
in the Brand Element (see section 6.6.1) or the Organisation
Component. Note that:
David Burdett et al. [Page 206]
Internet Draft IOTP/1.0 23 October 1998
- the content of this attribute is dependent on the Transport
Mechanism (such as HTTP) that is used. See the Transport
Mechanism supplement,
- implementers should check that if the rightmost character of
Logo Net Location is set to right-slash "/" then another, right
slash should not be included when generating the Logo Address,
o Logo_size identifies the size of the logo,
o Logo_color_depth identifies the colour depth of the logo
o "GIF" indicates that the logos are in GIF format
Logo_size and Logo_color_depth are specified by the implementer of the
IOTP software that is retrieving the logo depending on the size and
colour that they want to use.
9.1 Logo Size
There are five standard sizes for logos. The sizes in pixels and the
corresponding values for Logo Size are given in the table below.
Size in Logo Size
Pixels Value
32 x 32 or exsmall
32 x 20
53 x 33 small
103 x 65 medium
180 x 114 large
263 x 166 exlarge
9.2 Logo Color Depth
There are three standard colour depths. The colour depth (including
bits per pixel) and the corresponding value for Logo_Color_Depth are
given in the table below.
Color Depth Logo Color
(bits per pixel) Depth Value
4 (16 colors) 4
8 (256 colors) nothing
24 (16 million colors) 24
David Burdett et al. [Page 207]
Internet Draft IOTP/1.0 23 October 1998
Note that if Logo Color Depth is omitted then a logo with the default
colour depth of 256 colours will be retrieved.
9.3 Logo Net Location Examples
If Logo Net Location was set to "ftp://logos.xzpay.com", then:
o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium
size 256 colour logo
o "ftp://logos.xzpay.com/small4.gif" would retrieve a small size
16 colour logo
[Note] Organisations which make logos available for use with IOTP
should always make available "small" and "medium" size logos
and use the GIF format.
[Note End]
10. Brand List Examples
This example contains three examples of the XML for a Brand List
Component. It covers:
o a simple credit card based example
o a credit card based brand list including promotional credit
card brands, and
o a complex electronic cash based brand list
Note that:
o brand lists can be as complex or as simple as required
o all example techniques described in this appendix can be
included in one brand list.
10.1 Simple Credit Card Based Example
This is a simple example involving:
o only major credit card payment brands
o a single price in a single currency
o a single payment handler, and
o a single payment protocol
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30'
BrandId='MC'
BrandName='MasterCard'
BrandLogoNetLocn='ftp:otplogos.mastercard.com'
David Burdett et al. [Page 208]
Internet Draft IOTP/1.0 23 October 1998
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31'
BrandId='Visa'
BrandName='Visa'
BrandLogoNetLocn='ftp:otplogos.visa.com'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32'
BrandId='Amex'
BrandName='American Express'
BrandLogoNetLocn='ftp:otplogos.amex.com'
ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34'
Amount='10.95'
CurrCode='USD'/>
<PayProtocol ID ='M1.35'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.merchant.com/etill/sccd1' >
</PayProtocol>
</BrandList>
10.2 Credit Card Brand List Including Promotional Brands
An example of a Credit Card based Brand List follows. It includes:
o two ordinary card association brands and two promotional
credit card brands. The promotional brands consist of one
loyalty based (British Airways MasterCard) which offers
additional loyalty points and one store based (Walmart) which
offers a discount on purchases over a certain amount
o two payment protocols:
- SET (Secure Electronic Transactions) see [SET], and
- SCCD (Secure Channel Credit Debit) see [SCCD].
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase ladies coat'
PayDirection='Debit' >
<Brand ID ='M1.3'
BrandId='MC'
BrandName='MasterCard'
BrandLogoNetLocn='ftp:otplogos.mastercard.com'
ProtocolAmountRefs='M1.7 M1.8'>
</Brand>
<Brand ID ='M1.4'
David Burdett et al. [Page 209]
Internet Draft IOTP/1.0 23 October 1998
BrandId='Visa'
BrandName='Visa'
BrandLogoNetLocn='ftp:otplogos.visa.com'
ProtocolAmountRefs='M1.7 M1.8'>
</Brand>
<Brand ID ='M1.5'
BrandId='MC/BritishAirways'
BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp:otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways
MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
</Brand >
<Brand ID ='M1.6'
BrandId='Walmart'
BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp:otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.7'>
</Brand>
<ProtocolAmount ID ='M1.7'
PayProtocolRef='M1.10'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
<PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8'
PayProtocolRef='M1.11'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
<PackagedContent Transform="BASE64">
</ProtocolAmount>
<CurrencyAmount ID ='M1.9'
Amount='157.53'
CurrCode='USD'/>
<PayProtocol ID ='M1.10'
ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.merchant.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
<PackagedContent Transform="BASE64">
</PayProtocol>
<PayProtocol ID ='M1.11'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.merchant.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
<PackagedContent Transform="BASE64">
David Burdett et al. [Page 210]
Internet Draft IOTP/1.0 23 October 1998
</PayProtocol>
</BrandList>
10.3 Brand Selection Example
In order to pay by 'British Airways' MasterCard using the example
above using SET and therefore getting double air miles, the Brand
Selection would be:
<BrandSelection ID='C1.2'
BrandListRef='M1.3'
BrandRef='M1.5'
ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
10.4 Complex Electronic Cash Based Brand List
The following is an fairly complex example which includes:
o payments using either Mondex, GeldKarte, CyberCash or DigiCash
o in currencies including US dollars, British Pounds, Italian
Lira, German Marks and Canadian Dollars
o a discount on the price if the payment is made in Mondex using
British pounds or US dollars, and
o more than one payment handler is used for payments involving
Mondex or CyberCash
o support for more than one version of a CyberCash CyberCoin
payment protocol.
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Company report on XYZ Co'
PayDirection='Debit' >
<Brand ID ='M1.13'
BrandId='MX'
BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp:otplogos.mondex.com'
ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14'
BrandId='GK'
BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp:otplogos.geldkarte.co.de'
ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15'
BrandId='CCash'
BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='ftp:otplogos.cybercash.com'
David Burdett et al. [Page 211]
Internet Draft IOTP/1.0 23 October 1998
ProtocolAmountRefs ='M1.20' >
</Brand >
<Brand ID ='M1.16'
BrandId='DigiCash'
BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='ftp:otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17'
PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18'
PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20'
PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21'
PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23'
Amount='20.00'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.24'
Amount='12.00'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25'
Amount='19.50'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.26'
Amount='11.75'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27'
Amount='36.00'
CurrCode='DEM'/>
<CurrencyAmount ID ='M1.28'
Amount='100.00'
CurrCode='FFR'/>
<CurrencyAmount ID ='M1.29'
Amount='22.00'
CurrCode='CAD'/>
<CurrencyAmount ID ='M1.30'
Amount='15000'
David Burdett et al. [Page 212]
Internet Draft IOTP/1.0 23 October 1998
CurrCode='ITL'/>
<PayProtocol ID ='M1.31'
ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
</PayProtocol>
<PayProtocol ID ='M1.32'
ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >
</PayProtocol>
<PayProtocol ID ='M1.33'
ProtocolId='Ccashv1.0'
ProtocolName='CyberCash Version 1.0'
PayReqNetLocn='http://www.ccash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.34'
ProtocolId='CCashv2.0'
ProtocolName='CyberCash Version 2.0'
PayReqNetLocn='http://www.ccash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.35'
ProtocolId='GKv1.0'
ProtocolName='GeldKarte Version 1.0'
PayReqNetLocn='http://www.merchant.com/pgway' >
</PayProtocol>
<PayProtocol ID ='M1.36'
ProtocolId='DCashv1.0'
ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.merchant.com/digicash' >
</PayProtocol>
</BrandList>
11. XML Overview
This section contains an overview of [XML]. Its purpose is to provide
sufficient explanation so that the XML examples in this document may
be understood. This description is not complete. For more detail and
the full specification see the reference contained in the Preface to
this document.
XML is based on SGML has the goal of enabling "generic SGML to be
served, received, and processed on the Web in the way that is now
possible with HTML. XML has been designed for ease of implementation
and for interoperability with both SGML and HTML."
XML is designed as a universal, open data format for the Internet and
allows the structure of data in messages to be clearly and
unambiguously defined.
David Burdett et al. [Page 213]
Internet Draft IOTP/1.0 23 October 1998
In the following examples, underlined words are to be replaced by
proper names; for example, document name could be OtpMessage,
EDIMessage, and so on.
The structure of data in XML is defined using a number of key
components. These are:
o document definitions
o element declarations and
o attribute declarations.
These are described below.
11.1 Document Definition
A document definition has the following form:
<!DOCTYPE DocumentName [DocumentStructureDefinition] >
DocumentName For IOTP this is always OtpMessage.
DocumentStructure This contains the declarations of elements,
Definition attributes and entities.
For example:
<!DOCTYPE X [
<!ELEMENT Y (Y1, Y2) >
<!ATTLIST Y ('a' | 'b' | 'c') 'a' >
<!ELEMENT Z (Z1 | Z2) >
<!ATTLIST Z CDATA #REQUIRED>
]>
11.2 Element Declaration
An element declaration has the following form:
<!ELEMENT ElementName (ElementContents)>
ElementContent This defines the relationships among the elements,
the order of occurrences of the elements, and
their number of occurrences.
David Burdett et al. [Page 214]
Internet Draft IOTP/1.0 23 October 1998
11.2.1 Example 1
An element X consists of elements A, B, and C in that order. This
would be declared as follows:
<!ELEMENT X (A, B, C) >
If the elements A, B, and C can appear in any order, "&" is used in
place of ",".
As XML this would be expressed as follows:
<X>
<A> DataA </A>
<B> DataB </B>
<C> DataC </C>
</X>
In this example
o "<X>" is a start tag and "</x>" is an end tag
o "DataA", "DataB", and "DataC" is the content of the element
and can consist of other elements, or character data or may
even be empty.
11.2.2 Example 2
An element X consists of one of the elements A, B, or C. This would be
declared as follows:
<!ELEMENT X ( A | B | C ) >
If element A is selected then this would be expressed as:
<X>
<A> DataA </A>
</X>
11.2.3 Example 3
An element X consists of element A occurring zero or more times and
element B occurring one or more times in that order. This would be
declared as follows:
<!ELEMENT X ( A*, B+ ) >
The "*" indicates zero or more, and the "+" indicates one or more.
If A occurred zero times and b occurred twice then this would be
expressed as:
<X>
David Burdett et al. [Page 215]
Internet Draft IOTP/1.0 23 October 1998
<B> DataB </B>
<B> DataB </B>
</X>
11.2.4 Data Types used in element declarations
The previous examples described how one element can be defined as
having "children" elements. In element declarations XML also supports
data types. The data types used in this IOTP specification are shown
below.
Data Types Descriptions
#PCDATA The element content contains data which the XML
parser can search to look for tags or entity
declarations.
ANY The element content can contain any element
defined in any order.
EMPTY The element content contains no data.
11.3 Attribute declarations
Attribute declarations describe information about an element. More
than one attribute can be defined for one element. Attributes are
contained within the start tag of an element. They are defined as
follows:
<!ATTLIST ElementName AttributeName1 DeclaredValue1
DefaultValue1
AttributeName2 DeclaredValue2 DefaultValue2
...
AttributeNameN DeclaredValueN DefaultValueN >
11.3.1 Declared value
When the permissible values of an attribute are known, those values
are declared as a list in the declared value.
When the list of permissible values are not pre-defined, data types
are specified instead. The data types which can be used for attribute
declarations are listed below. Only the ones used in this IOTP
specification are shown.
Attribute Types Descriptions
David Burdett et al. [Page 216]
Internet Draft IOTP/1.0 23 October 1998
CDATA Character data. Characters other than attribute
value delimiters such as (_ ') can be used.
Characters of zero length are allowed.
NMTOKEN An attribute which conforms with the rules for an
XML name. In outline it must start with a letter
and be followed by any combination of letters,
digits, or a few special characters. No spaces are
allowed
NMTOKENS One or more NMTOKEN separated by spaces.
ID Identifier. This value of this attribute is unique
for each element.
IDREF This value of this attribute matches the value of
some ID attribute of an element in the same XML
document. It is used to point to that element.
IDREFS One or more IDREFs separated by spaces.
11.3.2 Default value
Default values indicate whether or not the attribute must be present
in an element.
For default values, the following default keywords as well as some
concrete values can be specified. Only the default keywords used in
this IOTP specification are shown.
Values Descriptions
#REQUIRED CANNOT abbreviate. Some value must be specified
for this attribute.
#IMPLIED When an attribute with this default value is not
specified, the application gives the pre-
determined attribute value.
'value' The 'value specified is the default. Other values
may be used.
#FIXED 'value' The value must and can only be the value specified
Example
An example of an attribute declaration follows:
<!ATTLIST X
Att1 ( A, B ) #REQUIRED >
David Burdett et al. [Page 217]
Internet Draft IOTP/1.0 23 October 1998
In this example a value for ATT1 must be present as it is "#REQUIRED"
and it must be either "A" or "B" for the XML document to be valid. For
example:
<X Att1='B'> DataX </X>
12. Open Trading Protocol Data Type Definition
This section contains a copy of the XML DTD for the Open Trading
Protocols for information purposes.
The master copy of the DTD for IOTP, which should be relied upon is
available for download from the IOTP web site (http://www.IOTP.org).
David Burdett et al. [Page 218]
Internet Draft IOTP/1.0 23 October 1998
<!--
******************************************************
* *
* OPEN TRADING PROTOCOL DTD VERSION 1.0 *
* *
* Changes from version 0.9.9 *
* - corrects typos in OTP Message and *
* Payment Method Information component *
* - adds "place holder" definitions of OtpSig and *
* OtpCert Components *
* - adds Status Component to the Delivery Request *
* block *
* - moves the Status Component to the start of the*
* content of the Offer Response Block to make it*
* consistent with other Response and Request *
* blocks *
* - adds the Status Component to the Payment *
* Request Block *
* - adds the PayReceiptRefs attribute to the *
* Payment Receipt Component *
* - changes the Type of the Content Attribute of *
* the PackagedContent element to CDATA from *
* NMTOKEN *
* - adds the Trading Role Data Component *
* - adds the Trading Role Data Component to the *
* Offer Response, Payment Request, Payment *
* Response and Delivery Request Blocks *
* - adds Payment Note Component *
* - adds the Payment Note Component to the *
* response block *
* - adds an Org Component to the Authentication *
* Request Block *
* - adds an Org Component and a Status Component *
* to the Authentication Request Block *
* - adds a TradingRoleList and AuthenticationId *
* attributes to the Authentication Data *
* Component *
* - adds Authentication as a valid value of the *
* StatusType attribute of the Status Component *
* - removes ErrorNetLocn and CancelNetLocn attri- *
* butes from the Protocol Options Component *
* - adds the CancelNetLocn attribute to the *
* Trading Role element *
* *
* Copyright Open Trading Protocol Consortium ,1998 *
* (note copyright will be assigned to IETF/ISOC) *
******************************************************
******************************************************
* OTP MESSAGE DEFINITION *
******************************************************
-->
David Burdett et al. [Page 219]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT OtpMessage (TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayInstCCExchBlk |
PayInstCCReqBlk |
PayInstCCRespBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
OtpTransId NMTOKEN #REQUIRED
OtpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED >
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespOtpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
David Burdett et al. [Page 220]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!--
******************************************************
* Packaged Content Common Element *
******************************************************
-->
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
<!--
******************************************************
* TRADING COMPONENTS *
******************************************************
-->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #REQUIRED
SecureSenderNetLocn CDATA #REQUIRED
SuccessNetLocn CDATA #REQUIRED >
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthData (PackagedContent)>
<!ATTLIST AuthData
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
TradingRoleList NMTOKEN #IMPLIED
AuthMethod NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent) >
<!ATTLIST AuthResp
David Burdett et al. [Page 221]
Internet Draft IOTP/1.0 23 October 1998
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent?) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?,
PersonName?, PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
OtpMsgIdPrefix NMTOKEN #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
TradingRole NMTOKEN #REQUIRED
ErrorNetLocn CDATA #IMPLIED
CancelNetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
David Burdett et al. [Page 222]
Internet Draft IOTP/1.0 23 October 1998
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True|False) 'False' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED >
<!ELEMENT Brand (PackagedContent?) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId NMTOKEN #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT ProtocolAmount (PackagedContent?) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217'
CurrCode CDATA #REQUIRED >
<!ELEMENT PayProtocol (PackagedContent?) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
David Burdett et al. [Page 223]
Internet Draft IOTP/1.0 23 October 1998
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
<!ELEMENT BrandSelBrandInfo (PackagedContent) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment (PackagedContent?) >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
AuthDataRef NMTOKEN #IMPLIED
StartAfter NMTOKENS #IMPLIED >
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
David Burdett et al. [Page 224]
Internet Draft IOTP/1.0 23 October 1998
<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptRefs NMTOKENS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- DELIVERY COMPONENT -->
<!ELEMENT Delivery (DeliveryData?, PackagedContent?) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True|False) #REQUIRED
DelivAndPayResp (True|False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED
ConsumerDeliveryId CDATA #IMPLIED >
<!ELEMENT DeliveryData (PackagedContent?) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT METHOD INFORMATION COMPONENT -->
<!ELEMENT PayMethodInfoData EMPTY >
<!ATTLIST PayMethodInfoData
ID ID #REQUIRED
David Burdett et al. [Page 225]
Internet Draft IOTP/1.0 23 October 1998
BrandId NMTOKEN #REQUIRED
PayProtocolId NMTOKEN #IMPLIED >
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType (Offer|Payment|Delivery|
Authentication) #REQUIRED
ElRef NMTOKEN #REQUIRED
ProcessState (NotYetStarted|InProgress|
CompletedOk|Failed|ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
<!-- INQUIRY TYPE COMPONENT -->
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type (Offer|Payment|Delivery) #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
OtpMsgRef NMTOKEN #REQUIRED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
David Burdett et al. [Page 226]
Internet Draft IOTP/1.0 23 October 1998
AttName NMTOKEN #IMPLIED >
<!--
******************************************************
* TRADING BLOCKS *
******************************************************
-->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, AuthData*, Order?,
Payment*, Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthData?, Org) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp, Org+, Status) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, AuthData?, BrandList,
BrandSelection, Payment, PaySchemeData?, Org*,
TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
David Burdett et al. [Page 227]
Internet Draft IOTP/1.0 23 October 1998
<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
<!-- PAYMENT INSTRUMENT CUSTOMER CARE REQUEST BLOCK -->
<!ELEMENT PayInstCCReqBlk (PayMethodInfoData, PaySchemeData*) >
<!ATTLIST PayInstCCReqBlk
ID ID #REQUIRED >
<!-- PAYMENT INSTRUMENT CUSTOMER CARE EXCHANGE BLOCK -->
<!ELEMENT PayInstCCExchBlk (PaySchemeData) >
<!ATTLIST PayInstCCExchBlk
ID ID #REQUIRED >
<!-- PAYMENT INSTRUMENT CUSTOMER CARE RESPONSE BLOCK -->
<!ELEMENT PayInstCCRespBlk (PaySchemeData) >
<!ATTLIST PayInstCCRespBlk
ID ID #REQUIRED >
<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedOtpMsgRef NMTOKEN #IMPLIED
LastSentOtpMsgRef NMTOKEN #IMPLIED >
David Burdett et al. [Page 228]
Internet Draft IOTP/1.0 23 October 1998
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok|Busy|Down) #REQUIRED
SigVerifyStatusCode (Ok|NotSupported|Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
<!-- SIGNATURE BLOCK -->
<!ELEMENT SigBlk (OtpSig+, OtpCert*) >
<!ATTLIST SigBlk
ID ID #REQUIRED >
<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
<!-- placeholders for content models to come from XMLSIG -->
<!ELEMENT OtpSig (#PCDATA)>
<!ELEMENT OtpCert (#PCDATA)>
13. Glossary
This section contains a glossary of some of the terms used within this
specification in alphabetical order.
NAME DESCRIPTION
Authenticator The organisation which is requesting the
authentication of another organisation, and
Authenticatee The organisation being authenticated by
authenticated by an Authenticator
Brand A Brand is the mark which identifies a particular
type of Payment Instrument. A list of Brands are
the payment options which are presented by the
David Burdett et al. [Page 229]
Internet Draft IOTP/1.0 23 October 1998
NAME DESCRIPTION
Merchant to the Consumer and from which the
Consumer makes a selection. Each Brand may have a
different Payment Handler. Examples of Brands
include:
o payment association and proprietary
Brands, for example MasterCard, Visa,
American Express, Diners Club, American
Express, Mondex, GeldKarte, CyberCash,
etc.
o Promotional Brands (see below). These
include:
o store Brands, where the Payment
Instrument is issued to a Consumer by a
particular Merchant, for example Walmart,
Sears, or Marks and Spencer (UK)
o coBrands, for example American Advantage
Visa, where an organisation uses their
own Brand in conjunction with, typically,
a payment association Brand.
Consumer The person or organisation which is to receive
and pay for the goods or services
Delivery The entity that physically delivers the goods or
Handler services to the Consumer on behalf of the
Merchant.
Dual Brand A Dual Brand means that a single Payment
Instrument may be used as if it were two separate
Brands. For example there could be a single
Japanese "UC" MasterCard which can be used as
either a UC card or a regular MasterCard. The UC
card Brand and the MasterCard Brand could each
have their own separate Payment Handlers. This
means that:
o the Merchant treats, for example "UC" and
"MasterCard" as two separate Brands when
offering a list of Brands to the
Consumer,
o the Consumer chooses a Brand, for example
either "UC" or "MasterCard,
o the Consumer IOTP aware application
determines which Payment Instrument(s)
match the chosen Brand, and selects,
perhaps with user assistance, the correct
Payment Instrument to use.
IOTP Message An IOTP Message is a collection of IOTP Trading
Blocks which carries the data required to carry
out an IOTP Transaction. They are a well formed
XML document sent between the Trading Roles that
David Burdett et al. [Page 230]
Internet Draft IOTP/1.0 23 October 1998
NAME DESCRIPTION
are taking part in a trade.
IOTP An Internet Open Trading Protocol Transaction is
Transaction described as a predefined set of IOTP Messages
transferred between the Trading Roles.
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
Merchant The entity that is involved with customer dispute
Customer Care negotiation and resolution on behalf of the
Provider Merchant
Payment The entity that physically receives the payment
Handler from the Consumer on behalf of the Merchant
Payment A Payment Instrument is the means by which
Instrument Consumer pays for goods or services offered by a
Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's
Maestro;
o a smart card based electronic cash
Payment Instrument such as a Mondex Card,
a GeldKarte card or a Visa Cash card
o a software based electronic payment
account such as a CyberCash or DigiCash
account.
All Payment Instruments have a number, typically
an account number, by which the Payment
Instrument can be identified.
Payment The entity that resolves problems with a
Instrument particular Payment Instrument
Customer Care
Provider
Promotional A Promotional Brand means that, if the Consumer
Brand pays with that Brand, then the Consumer will
receive some additional benefit which can be
received in two ways:
o at the time of purchase. For example if a
Consumer pays with a "Walmart MasterCard"
at a Walmart web site, then a 5% discount
might apply, which means the Consumer
actually pays less,
o from their Payment Instrument (card)
issuer when the payment appears on their
David Burdett et al. [Page 231]
Internet Draft IOTP/1.0 23 October 1998
NAME DESCRIPTION
statement. For example loyalty points in
a frequent flyer scheme could be awarded
based on the total payments made with the
Payment Instrument since the last
statement was issued.
Each Promotional Brand should be identified as a
separate Brand in the list of Brands offered by
the Merchant. For example: "Walmart", "Sears",
"Marks and Spencer" and "American Advantage
Visa", would each be a separate Brand.
Trading Block A Trading Block consists of one or more Trading
Components. One or more Trading Blocks may be
contained within the IOTP Messages which are
physically sent in the form of [XML] documents
between the different organisations that are
taking part in a trade.
Trading A Trading Component is collections of XML
Component elements and attributes. Trading Components are
the child elements of the Trading Blocks.
Trading Role A Trading Role identifies the different ways in
which organisations can participate in a trade.
There are five Trading Roles: Consumer, Merchant,
Payment Handler, Delivery Handler, Merchant
Customer Care Provider and Payment Instrument
Customer Care Provider.
14. Copyrights
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
David Burdett et al. [Page 232]
Internet Draft IOTP/1.0 23 October 1998
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
15. References
This section contains references to related documents identified in
this specification.
[Base64] Base64 Content-Transfer-Encoding. A method of
transporting binary data defined by MIME. See: RFC 2045:
Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies. N. Freed & N.
Borenstein. November 1996.
[DNS] The Internet Domain Name System which allocates Internet
names to organisations for example "IOTP.org", the Domain
Name for IOTP. See RFC 1034: Domain names - concepts and
facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035:
Domain names - implementation and specification. P.V.
Mockapetris. Nov-01-1987.
[DSA] The Digital Signature Algorithm (DSA) published by the
National Institute of Standards and Technology (NIST) in
the Digital Signature Standard (DSS), which is a part of
the US government's Capstone project.
[ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm
(ECCDSA). Elliptic curve cryptosystems are analogs of
public-key cryptosystems such as RSA in which modular
multiplication is replaced by the elliptic curve addition
operation. See: V. S. Miller. Use of elliptic curves in
cryptography. In Advances in Cryptology - Crypto '85,
pages 417-426, Springer-Verlag, 1986.
[HTML] Hyper Text Mark Up Language. The Hypertext Mark-up
Language (HTML) is a simple mark-up language used to
create hypertext documents that are platform independent.
See RFC 1866 and the World Wide Web (W3C) consortium web
site at: http://www.w3.org/MarkUp/
[HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See
RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T.
David Burdett et al. [Page 233]
Internet Draft IOTP/1.0 23 October 1998
Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC
2068: Hypertext Transfer Protocol -- HTTP/1.1. R.
Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
Lee. January 1997.
[ISO4217] ISO 4217: Codes for the Representation of Currencies.
Available from ANSI or ISO.
[MIME] Multipurpose Internet Mail Extensions. See RFC822,
RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049.
[OPS] Open Profiling Standard. A proposed standard which
provides a framework with built-in privacy safeguards for
the trusted exchange of profile information between
individuals and web sites. Being developed by Netscape
and Microsoft amongst others.
[RFC822] IETF (Internet Engineering Task Force). RFC 822: The
Standard for the Format of ARPA Internet Messages
. 13 August 1982, David H Crocker. 13 August 1982.
[RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform
Resource Locators (URL), ed. T. Berners-Lee, L. Masinter,
M. McCahill. 1994.
[RSA] RSA is a public-key cryptosystem for both encryption and
authentication supported by RSA Data Security Inc. See:
R. L. Rivest, A. Shamir, and L.M. Adleman. A method for
obtaining digital signatures and public-key
cryptosystems. Communications of the ACM, 21(2): 120-126,
February 1978.
[SCCD] Secure Channel Credit Debit. A method of conducting a
credit or debit card payment where unauthorised access to
account information is prevented through use of secure
channel transport mechanisms such as SSL. An IOTP
supplement describing how SCCD works is under
development. Author. Jonathan Sowler JCP,
[SET] Secure Electronic Transaction Specification, Version 1.0,
May 31, 1997. Supports credit and debit card payments
using certificates at the Consumer and Merchant to help
ensure authenticity.
Download from:
<http://www.mastercard.com/set/specs.html>.
[SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of
Standards and Technology, US Department Of Commerce,
April 1995. Also known as: 59 Fed Reg. 35317 (1994).
[UTC] Universal Time Co-ordinated. A method of defining time
absolutely relative to Greenwich Mean Time (GMT).
David Burdett et al. [Page 234]
Internet Draft IOTP/1.0 23 October 1998
Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n"
where the "+n" defines the number of hours from GMT. See
ISO DIS8601.
[UTF16] The Unicode Standard, Version 2.0. The Unicode
Consortium, Reading, Massachusetts. See ISO/IEC 10646 1
Proposed Draft Amendment 1
[X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995,
Including Draft Amendment 1: Certificate Extensions
(Version 3 Certificate)
[XML See Design decisions reached at the XML Working Group
Namespace] meeting in Montreal, Canada, August 22, 1987
[XML] Extensible Mark Up Language. See http://www.w3.org/TR/PR-
xml-971208 for the 8 December 1997 version.
[XMLSIG] A proposal developed by the IOTP consortium describing an
approach to signing XML documents such as IOTP Messages.
It is intended that this document is submitted to W3C for
consideration. Author. Richard Brown. GlobeSet. (Under
preparation August 1998)
16. Author's Address
The author of this document is:
David Burdett
Development Director
Mondex International Ltd
Advanced Technology Division
111 Pine St, Suite 600
San Francisco, 94111
California
USA
Tel: +1 (415) 645 6973
Email: david.burdett@mondex.com
The author of this document appreciates the following contributors to
this protocol (in alphabetic order of company) without which it could
not have been developed.
o Phillip Mullarkey, British Telecom plc
o Andrew Marchewka, Canadian Imperial Bank of Commerce
o Brian Boesch, CyberCash Inc.
o Donald Eastlake 3rd, CyberCash Inc.
o Mark Linehan, International Business Machines
o Peter Chang, Hewlett Packard
David Burdett et al. [Page 235]
Internet Draft IOTP/1.0 23 October 1998
o Masaaki Hiroya, Hitachi Ltd
o Yoshiaki Kawatsura, Hitachi Ltd
o Jonathan Sowler, JCP Computer Services Ltd
o John Wankmueller, MasterCard International
o Steve Fabes, Mondex International Ltd
o Surendra Reddy, Oracle Corporation
o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
o Chris Smith, Royal Bank of Canada
o Hans Bernhard-Beykirch, SIZ (IT Development and Coordination
Centre of the German Savings Banks Organisation)
o W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services,
formally AT&T Universal Card Services)
o Efrem Lipkin, Sun Microsystems
o Terry Allen, Veo Systems
The author would also like to thank the following organisations for
their support:
o Amino Communications
o DigiCash
o Fujitsu
o General Information Systems
o Globe Id Software
o Hyperion
o InterTrader
o Nobil I T Corp
o Mercantec
o Netscape
o Nippon Telegraph and Telephone Corporation
o Oracle Corporation
o Smart Card Integrations Ltd.
o Spyrus
o Verifone
o Unisource nv
o Wells Fargo Bank
Note: This is file draft-ietf-trade-iotp-v1.0-protocol-02.txt
Expires: 23 May 1999
David Burdett et al. [Page 236]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:41 |