draft-ietf-trade-iotp-v1.0-protocol-07.txt   rfc2801.txt 
Internet Draft. David Burdett David Burdett
Commerce One
draft-ietf-trade-iotp-v1.0-protocol-07.txt October 1999
Expires: April 2000
Internet Open Trading Protocol - IOTP
Version 1.0
Status of this Memo Network Working Group D. Burdett
Request for Comments: 2801 Commerce One
Category: Informational April 2000
This document, filename [draft-ietf-trade-iotp-v1.0-protocol-07.txt], is Internet Open Trading Protocol - IOTP
the main specification of the Internet Open Trading Protocol version 1.0 Version 1.0
and is intended to become an Informational RFC. Distribution of this
document is unlimited. Comments should be sent to the TRADE working group
at <ietf-trade@lists.elistx.com>.
This document is an Internet-Draft and is in full conformance with all Status of this Memo
provisions of Section 10 of RFC2026. 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
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and This memo provides information for the Internet community. It does
may be updated, replaced, or obsoleted by other documents at any time. not specify an Internet standard of any kind. Distribution of this
It is inappropriate to use Internet-Drafts as reference material or to memo is unlimited.
cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see Copyright Notice
http://www.ietf.org/shadow.html.
Discussions of the TRADE working group are archived at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.elistx.com/archives/ietf-trade.
Abstract Abstract
The Internet Open Trading Protocol (IOTP) provides an interoperable The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Secure Channel Credit/Debit, encapsulates payment systems such as SET, Secure Channel
Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to
such merchant roles as the shopping site, the Payment Handler, the handle cases where such merchant roles as the shopping site, the
Delivery Handler of goods or services, and the provider of customer Payment Handler, the Delivery Handler of goods or services, and the
support are performed by different parties or by one party. provider of customer support are performed by different parties or by
one party.
Table of Contents Table of Contents
Status of this Memo ................................................1 1. Background .....................................................7
1.1 Commerce on the Internet, a Different Model .................7
Abstract ...........................................................1 1.2 Benefits of IOTP ............................................9
1.3 Baseline IOTP ..............................................10
1. Background .....................................................7 1.4 Objectives of Document .....................................10
1.1 Commerce on the Internet, a Different Model .................7 1.5 Scope of Document ..........................................11
1.2 Benefits of IOTP ............................................8 1.6 Document Structure .........................................11
1.3 Baseline IOTP ..............................................10 1.7 Intended Readership ........................................13
1.4 Objectives of Document .....................................10 1.7.1 Reading Guidelines ...................................13
1.5 Scope of Document ..........................................10 2. Introduction ..................................................14
1.6 Document Structure .........................................11 2.1 Trading Roles ..............................................16
1.7 Intended Readership ........................................12 2.2 Trading Exchanges ..........................................18
1.7.1 Reading Guidelines ...................................12 2.2.1 Offer Exchange .......................................19
2.2.2 Payment Exchange .....................................21
2. Introduction ..................................................14 2.2.3 Delivery Exchange ....................................24
2.1 Trading Roles ..............................................14 2.2.4 Authentication Exchange ..............................26
2.2 Trading Exchanges ..........................................16 2.3 Scope of Baseline IOTP .....................................28
2.2.1 Offer Exchange .......................................17
2.2.2 Payment Exchange .....................................19
2.2.3 Delivery Exchange ....................................21
2.2.4 Authentication Exchange ..............................23
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 ..................................32
3.3 Transaction Reference Block ................................33
3.3.1 Transaction Id Component .............................33
3.3.2 Message Id Component .................................35
3.3.3 Related To Component .................................36
3.4 ID Attributes ..............................................38
3.4.1 IOTP Message ID Attribute Definition .................38
3.4.2 Block and Component ID Attribute Definitions .........40
3.4.3 Example of use of ID Attributes ......................40
3.5 Element References .........................................41
3.6 Extending IOTP .............................................42
3.6.1 Extra XML Elements ...................................43
3.6.2 Opaque Embedded Data .................................44
3.7 Packaged Content Element ...................................44
3.7.1 Packaging HTML .......................................46
3.7.2 Packaging XML ........................................47
3.8 Identifying Languages ......................................47
3.9 Secure and Insecure Net Locations ..........................48
3.10 Cancelled Transactions .....................................48
3.10.1 Cancelling Transactions ..............................48
3.10.2 Handling Cancelled Transactions ......................49
4. IOTP Error Handling ...........................................50
4.1 Technical Errors ...........................................50
4.2 Business Errors ............................................51
4.3 Error Depth ................................................51
4.3.1 Transport Level ......................................51
4.3.2 Message Level ........................................52
4.3.3 Block Level ..........................................52
4.4 Idempotency, Processing Sequence, and Message Flow .........54
4.5 Server Role Processing Sequence ............................55
4.5.1 Initiating Transactions ..............................55
4.5.2 Processing Input Messages ............................55
4.5.3 Cancelling a Transaction .............................61
4.5.4 Retransmitting Messages ..............................61
4.6 Client Role Processing Sequence ............................62
4.6.1 Initiating Transactions ..............................62
4.6.2 Processing Input Messages ............................63
4.6.3 Cancelling a Transaction .............................64
4.6.4 Retransmitting Messages ..............................64
5. Security Considerations .......................................65
5.1 Determining whether to use digital signatures ..............65
5.2 Symmetric and Asymmetric Cryptography ......................66
5.3 Data Privacy ...............................................67
5.4 Payment Protocol Security ..................................67
6. Digital Signatures and IOTP ...................................68
6.1 How IOTP uses Digital Signatures ...........................68
6.1.1 IOTP Signature Example ...............................70
6.1.2 OriginatorInfo and RecipientInfo Elements ............71
6.1.3 Using signatures to Prove Actions Complete Successfully72
6.2 Checking a Signature is Correctly Calculated ...............72
6.3 Checking a Payment or Delivery can occur ...................73
6.3.1 Check Request Block sent Correct Organisation ........74
6.3.2 Check Correct Components present in Request Block ....77
6.3.3 Check an Action is Authorised ........................77
7. Trading Components ............................................79
7.1 Protocol Options Component .................................80
7.2 Authentication Request Component ...........................82
7.3 Authentication Response Component ..........................83
7.4 Trading Role Information Request Component .................84
7.5 Order Component ............................................84
7.5.1 Order Description Content ............................85
7.5.2 OkFrom and OkTo Timestamps ...........................86
7.6 Organisation Component .....................................87
7.6.1 Organisation IDs .....................................88
7.6.2 Trading Role Element .................................89
7.6.3 Contact Information Element ..........................92
7.6.4 Person Name Element ..................................92
7.6.5 Postal Address Element ...............................93
7.7 Brand List Component .......................................94
7.7.1 Brand Element ........................................96
7.7.2 Protocol Brand Element ...............................98
7.7.3 Protocol Amount Element ..............................99
7.7.4 Currency Amount Element .............................100
7.7.5 Pay Protocol Element ................................101
7.8 Brand Selection Component .................................102
7.8.1 Brand Selection Brand Info Element ..................104
7.11 Payment Receipt Component .................................107
7.12 Payment Note Component ....................................109
7.13 Delivery Component ........................................110
7.13.1 Delivery Data Element ...............................111
7.14 Consumer Delivery Data Component ..........................113
7.15 Delivery Note Component ...................................114
7.16 Status Component ..........................................115
7.16.1 Offer Completion Codes ..............................117
7.16.2 Payment Completion Codes ............................118
7.16.3 Delivery Completion Codes ...........................120
7.16.4 Authentication Completion Codes .....................122
7.16.5 Undefined Completion Codes ..........................123
7.16.6 Transaction Inquiry Completion Codes ................124
7.17 Trading Role Data Component ...............................124
7.17.1 Who Receives a Trading Role Data Component ..........125
7.18 Inquiry Type Component ....................................125
7.19 Signature Component .......................................126
7.19.1 IOTP usage of signature elements and attributes .....127
7.19.2 Offer Response Signature Component ..................129
7.19.3 Payment Receipt Signature Component .................130
7.19.4 Delivery Response Signature Component ...............131
7.19.5 Authentication Request Signature Component ..........131
7.19.6 Authentication Response Signature Component .........131
7.19.7 Inquiry Request Signature Component .................132
7.19.8 Inquiry Response Signature Component ................132
7.19.9 Ping Request Signature Component ....................132
7.19.10 Ping Response Signature Component...................132
7.20 Certificate Component .....................................132
7.20.1 IOTP usage of signature elements and attributes .....133
7.21 Error Component ...........................................133
7.21.1 Error Processing Guidelines .........................135
7.21.2 Error Codes .........................................136
7.21.3 Error Location Element ..............................140
8. Trading Blocks ...............................................142
8.1 Trading Protocol Options Block ............................144
8.2 TPO Selection Block .......................................145
8.3 Offer Response Block ......................................145
8.4 Authentication Request Block ..............................146
8.5 Authentication Response Block .............................148
8.6 Authentication Status Block ...............................148
8.7 Payment Request Block .....................................149
8.8 Payment Exchange Block ....................................150
8.9 Payment Response Block ....................................151
8.10 Delivery Request Block ....................................152
8.11 Delivery Response Block ...................................153
8.12 Inquiry Request Trading Block .............................154
8.13 Inquiry Response Trading Block ............................154
8.14 Ping Request Block ........................................155
8.15 Ping Response Block .......................................156
8.16 Signature Block ...........................................157
8.16.1 Signature Block with Offer Response .................158
8.16.2 Signature Block with Payment Request ................158
8.16.3 Signature Block with Payment Response ...............158
8.16.4 Signature Block with Delivery Request ...............158
8.16.5 Signature Block with Delivery Response ..............159
8.17 Error Block ...............................................159
8.18 Cancel Block ..............................................160
9. Internet Open Trading Protocol Transactions ..................161
9.1 Authentication and Payment Related IOTP Transactions ......161
9.1.1 Authentication Document Exchange ....................163
9.1.2 Offer Document Exchange .............................168
9.1.3 Payment Document Exchange ...........................175
9.1.4 Delivery Document Exchange ..........................180
9.1.5 Payment and Delivery Document Exchange ..............182
9.1.6 Baseline Authentication IOTP Transaction ............185
9.1.7 Baseline Deposit IOTP Transaction ...................186
9.1.8 Baseline Purchase IOTP Transaction ..................188
9.1.9 Baseline Refund IOTP Transaction ....................189
9.1.10 Baseline Withdrawal IOTP Transaction ................191
9.1.11 Baseline Value Exchange IOTP Transaction ............193
9.1.12 Valid Combinations of Document Exchanges ............195
9.1.13 Combining Authentication Transactions with other
Transactions ........................................198
9.2 Infrastructure Transactions ...............................199
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 200
9.2.2 Baseline Ping IOTP Transaction ......................204
10. Retrieving Logos .............................................208
10.1 Logo Size .................................................208
10.2 Logo Color Depth ..........................................209
10.3 Logo Net Location Examples ................................209
11. Brands .......................................................210
11.1 Brand Definitions and Brand Selection .....................210
11.1.1 Definition of Payment Instrument ....................210
11.1.2 Definition of Brand .................................211
11.1.3 Definition of Dual Brand ............................211
11.1.4 Definition of Promotional Brand .....................212
11.1.5 Identifying Promotional Brands ......................212
11.2 Brand List Examples .......................................214
11.2.1 Simple Credit Card Based Example ....................215
11.2.2 Credit Card Brand List Including Promotional Brands..216
11.2.3 Brand Selection Example .............................217
11.2.4 Complex Electronic Cash Based Brand List ............217
12. IANA Considerations ..........................................221
12.1 Codes Controlled by IANA ..................................221
12.2 Codes not controlled by IANA ..............................226
13. Internet Open Trading Protocol Data Type Definition ..........227
14. Glossary .....................................................240
15. Copyrights ...................................................247
16. References ...................................................248
17. Author's Address .............................................251 3. Protocol Structure ............................................31
3.1 Overview ...................................................32
3.1.1 IOTP Message Structure ...............................32
3.1.2 IOTP Transactions ....................................34
3.2 IOTP Message ...............................................35
3.2.1 XML Document Prolog ..................................37
3.3 Transaction Reference Block ................................37
3.3.1 Transaction Id Component .............................38
3.3.2 Message Id Component .................................39
3.3.3 Related To Component .................................41
3.4 ID Attributes ..............................................42
3.4.1 IOTP Message ID Attribute Definition .................43
3.4.2 Block and Component ID Attribute Definitions .........44
3.4.3 Example of use of ID Attributes ......................46
3.5 Element References .........................................46
3.6 Extending IOTP .............................................48
3.6.1 Extra XML Elements ...................................49
3.6.2 Opaque Embedded Data .................................50
3.7 Packaged Content Element ...................................50
3.7.1 Packaging HTML .......................................52
3.7.2 Packaging XML ........................................53
3.8 Identifying Languages ......................................54
3.9 Secure and Insecure Net Locations ..........................54
3.10 Cancelled Transactions .....................................55
3.10.1 Cancelling Transactions ..............................55
3.10.2 Handling Cancelled Transactions ......................56
4. IOTP Error Handling ...........................................56
4.1 Technical Errors ...........................................57
4.2 Business Errors ............................................57
4.3 Error Depth ................................................58
4.3.1 Transport Level ......................................58
4.3.2 Message Level ........................................58
4.3.3 Block Level ..........................................59
4.4 Idempotency, Processing Sequence, and Message Flow .........61
4.5 Server Role Processing Sequence ............................62
4.5.1 Initiating Transactions ..............................62
4.5.2 Processing Input Messages ............................63
4.5.3 Cancelling a Transaction .............................70
4.5.4 Retransmitting Messages ..............................70
4.6 Client Role Processing Sequence ............................71
4.6.1 Initiating Transactions ..............................71
4.6.2 Processing Input Messages ............................72
4.6.3 Cancelling a Transaction .............................74
4.6.4 Retransmitting Messages ..............................74
5. Security Considerations .......................................74
5.1 Determining whether to use digital signatures ..............74
5.2 Symmetric and Asymmetric Cryptography ......................76
5.3 Data Privacy ...............................................77
5.4 Payment Protocol Security ..................................77
6. Digital Signatures and IOTP ...................................77
6.1 How IOTP uses Digital Signatures ...........................77
6.1.1 IOTP Signature Example ...............................80
6.1.2 OriginatorInfo and RecipientInfo Elements ............82
6.1.3 Using signatures to Prove Actions Complete
Successfully .........................................83
6.2 Checking a Signature is Correctly Calculated ...............84
6.3 Checking a Payment or Delivery can occur ...................85
6.3.1 Check Request Block sent Correct Organisation ........86
6.3.2 Check Correct Components present in Request Block ....91
6.3.3 Check an Action is Authorised ........................91
7. Trading Components ............................................93
7.1 Protocol Options Component .................................96
7.2 Authentication Request Component ...........................97
7.3 Authentication Response Component ..........................98
7.4 Trading Role Information Request Component .................99
7.5 Order Component ...........................................100
7.5.1 Order Description Content ...........................101
7.5.2 OkFrom and OkTo Timestamps ..........................101
7.6 Organisation Component ....................................102
7.6.1 Organisation IDs ....................................104
7.6.2 Trading Role Element ................................105
7.6.3 Contact Information Element .........................108
7.6.4 Person Name Element .................................109
7.6.5 Postal Address Element ..............................110
7.7 Brand List Component ......................................111
7.7.1 Brand Element .......................................113
7.7.2 Protocol Brand Element ..............................115
7.7.3 Protocol Amount Element .............................116
7.7.4 Currency Amount Element .............................117
7.7.5 Pay Protocol Element ................................118
7.8 Brand Selection Component .................................120
7.8.1 Brand Selection Brand Info Element ..................122
7.8.2 Brand Selection Protocol Amount Info Element ........122
7.8.3 Brand Selection Currency Amount Info Element ........123
7.9 Payment Component .........................................123
7.10 Payment Scheme Component ..................................125
7.11 Payment Receipt Component .................................126
7.12 Payment Note Component ....................................128
7.13 Delivery Component ........................................129
7.13.1 Delivery Data Element ...............................130
7.14 Consumer Delivery Data Component ..........................132
7.15 Delivery Note Component ...................................133
7.16 Status Component ..........................................134
7.16.1 Offer Completion Codes ..............................137
7.16.2 Payment Completion Codes ............................138
7.16.3 Delivery Completion Codes ...........................140
7.16.4 Authentication Completion Codes .....................142
7.16.5 Undefined Completion Codes ..........................144
7.16.6 Transaction Inquiry Completion Codes ................144
7.17 Trading Role Data Component ...............................144
7.17.1 Who Receives a Trading Role Data Component ..........145
7.18 Inquiry Type Component ....................................146
7.19 Signature Component .......................................147
7.19.1 IOTP usage of signature elements and attributes .....148
7.19.2 Offer Response Signature Component ..................150
7.19.3 Payment Receipt Signature Component .................151
7.19.4 Delivery Response Signature Component ...............152
7.19.5 Authentication Request Signature Component ..........152
7.19.6 Authentication Response Signature Component .........153
7.19.7 Inquiry Request Signature Component .................153
7.19.8 Inquiry Response Signature Component ................153
7.19.9 Ping Request Signature Component ....................153
7.19.10 Ping Response Signature Component...................154
7.20 Certificate Component .....................................154
7.20.1 IOTP usage of signature elements and attributes .....154
7.21 Error Component ...........................................154
7.21.1 Error Processing Guidelines .........................157
7.21.2 Error Codes .........................................158
7.21.3 Error Location Element ..............................162
8. Trading Blocks ...............................................163
8.1 Trading Protocol Options Block ............................166
8.2 TPO Selection Block .......................................167
8.3 Offer Response Block ......................................168
8.4 Authentication Request Block ..............................169
8.5 Authentication Response Block .............................170
8.6 Authentication Status Block ...............................171
8.7 Payment Request Block .....................................171
8.8 Payment Exchange Block ....................................173
8.9 Payment Response Block ....................................173
8.10 Delivery Request Block ....................................175
8.11 Delivery Response Block ...................................176
8.12 Inquiry Request Trading Block .............................177
8.13 Inquiry Response Trading Block ............................177
8.14 Ping Request Block ........................................179
8.15 Ping Response Block .......................................179
8.16 Signature Block ...........................................181
8.16.1 Signature Block with Offer Response .................182
8.16.2 Signature Block with Payment Request ................182
8.16.3 Signature Block with Payment Response ...............182
8.16.4 Signature Block with Delivery Request ...............182
8.16.5 Signature Block with Delivery Response ..............182
8.17 Error Block ...............................................183
8.18 Cancel Block ..............................................184
9. Internet Open Trading Protocol Transactions ..................184
9.1 Authentication and Payment Related IOTP Transactions ......185
9.1.1 Authentication Document Exchange ....................188
9.1.2 Offer Document Exchange .............................194
9.1.3 Payment Document Exchange ...........................203
9.1.4 Delivery Document Exchange ..........................209
9.1.5 Payment and Delivery Document Exchange ..............212
9.1.6 Baseline Authentication IOTP Transaction ............216
9.1.7 Baseline Deposit IOTP Transaction ...................218
9.1.8 Baseline Purchase IOTP Transaction ..................220
9.1.9 Baseline Refund IOTP Transaction ....................222
9.1.10 Baseline Withdrawal IOTP Transaction ................224
9.1.11 Baseline Value Exchange IOTP Transaction ............226
9.1.12 Valid Combinations of Document Exchanges ............230
9.1.13 Combining Authentication Transactions with other
Transactions ........................................234
9.2 Infrastructure Transactions ...............................235
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 235
9.2.2 Baseline Ping IOTP Transaction ......................241
10. Retrieving Logos .............................................244
10.1 Logo Size .................................................245
10.2 Logo Color Depth ..........................................245
10.3 Logo Net Location Examples ................................246
11. Brands .......................................................246
11.1 Brand Definitions and Brand Selection .....................246
11.1.1 Definition of Payment Instrument ....................247
11.1.2 Definition of Brand .................................247
11.1.3 Definition of Dual Brand ............................248
11.1.4 Definition of Promotional Brand .....................248
11.1.5 Identifying Promotional Brands ......................249
11.2 Brand List Examples .......................................251
11.2.1 Simple Credit Card Based Example ....................252
11.2.2 Credit Card Brand List Including Promotional Brands..253
11.2.3 Brand Selection Example .............................254
11.2.4 Complex Electronic Cash Based Brand List ............255
12. IANA Considerations ..........................................257
12.1 Codes Controlled by IANA ..................................257
12.2 Codes not controlled by IANA ..............................263
13. Internet Open Trading Protocol Data Type Definition ..........263
14. Glossary .....................................................277
15. References ...................................................284
16. Author's Address .............................................287
17. Full Copyright Statement .....................................290
Table of Figures Table of Figures
Figure 1 IOTP Trading Roles 15 Figure 1 IOTP Trading Roles 16
Figure 2 Offer Exchange 17 Figure 2 Offer Exchange 19
Figure 3 Payment Exchange 20 Figure 3 Payment Exchange 22
Figure 4 Delivery Exchange 22 Figure 4 Delivery Exchange 25
Figure 5 Authentication Exchange 24 Figure 5 Authentication Exchange 27
Figure 6 IOTP Message Structure 29 Figure 6 IOTP Message Structure 33
Figure 7 An IOTP Transaction 30 Figure 7 An IOTP Transaction 34
Figure 8 Example use of ID attributes 41 Figure 8 Example use of ID attributes 46
Figure 9 Element References 42 Figure 9 Element References 48
Figure 10 Signature Digests 69 Figure 10 Signature Digests 79
Figure 11 Example use of Signatures for Baseline Purchase 71 Figure 11 Example use of Signatures for Baseline Purchase 81
Figure 12 Checking a Payment Handler can carry out a Payment 75 Figure 12 Checking a Payment Handler can carry out a Payment 87
Figure 13 Checking a Delivery Handler can carry out a Delivery 77 Figure 13 Checking a Delivery Handler can carry out a Delivery 90
Figure 14 Trading Components 80 Figure 14 Trading Components 94
Figure 15 Brand List Element Relationships 96 Figure 15 Brand List Element Relationships 113
Figure 16 Trading Blocks 143 Figure 16 Trading Blocks 164
Figure 17 Payment and Authentication Message Flow Combinations 163 Figure 17 Payment and Authentication Message Flow Combinations 187
Figure 18 Authentication Document Exchange 165 Figure 18 Authentication Document Exchange 190
Figure 19 Brand Dependent Offer Document Exchange 170 Figure 19 Brand Dependent Offer Document Exchange 196
Figure 20 Brand Independent Offer Exchange 171 Figure 20 Brand Independent Offer Exchange 198
Figure 21 Payment Document Exchange 176 Figure 21 Payment Document Exchange 204
Figure 22 Delivery Document Exchange 181 Figure 22 Delivery Document Exchange 210
Figure 23 Payment and Delivery Document Exchange 183 Figure 23 Payment and Delivery Document Exchange 214
Figure 24 Baseline Authentication IOTP Transaction 186 Figure 24 Baseline Authentication IOTP Transaction 217
Figure 25 Baseline Deposit IOTP Transaction 187 Figure 25 Baseline Deposit IOTP Transaction 219
Figure 26 Baseline Purchase IOTP Transaction 189 Figure 26 Baseline Purchase IOTP Transaction 221
Figure 27 Baseline Refund IOTP Transaction 191 Figure 27 Baseline Refund IOTP Transaction 223
Figure 28 Baseline Withdrawal IOTP Transaction 192 Figure 28 Baseline Withdrawal IOTP Transaction 225
Figure 29 Baseline Value Exchange IOTP Transaction 194 Figure 29 Baseline Value Exchange IOTP Transaction 228
Figure 30 Baseline Value Exchange Signatures 195 Figure 30 Baseline Value Exchange Signatures 230
Figure 31 Valid Combinations of Document Exchanges 196 Figure 31 Valid Combinations of Document Exchanges 231
Figure 32 Baseline Transaction Status Inquiry 202 Figure 32 Baseline Transaction Status Inquiry 238
Figure 33 Baseline Ping Messages 205 Figure 33 Baseline Ping Messages 242
1. Background 1. Background
The Internet Open Trading Protocol (IOTP) provides an interoperable The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, encapsulates payment systems such as SET, Mondex, CyberCash,
GeldKarte, etc. IOTP is able to handle cases where such merchant roles as DigiCash, GeldKarte, etc. IOTP is able to handle cases where such
the shopping site, the Payment Handler, the Delivery Handler of goods or merchant roles as the shopping site, the Payment Handler, the
services, and the provider of customer support are performed by different Delivery Handler of goods or services, and the provider of customer
parties or by one party. support are performed by different parties or by one party.
The developers of IOTP seek to provide a virtual capability that safely The developers of IOTP seek to provide a virtual capability that
replicates the real world, the paper based, traditional, understood, safely replicates the real world, the paper based, traditional,
accepted methods of trading, buying, selling, value exchanging that has understood, accepted methods of trading, buying, selling, value
existed for many hundreds of years. The negotiation of who will be the exchanging that has existed for many hundreds of years. The
parties to the trade, how it will be conducted, the presentment of an negotiation of who will be the parties to the trade, how it will be
offer, the method of payment, the provision of a payment receipt, the conducted, the presentment of an offer, the method of payment, the
delivery of goods and the receipt of goods. These are events that are provision of a payment receipt, the delivery of goods and the receipt
taken for granted in the course of real world trade. IOTP has been of goods. These are events that are taken for granted in the course
produced to provide the same for the virtual world, and to prepare and of real world trade. IOTP has been produced to provide the same for
provide for the introduction of new models of trading made possible by the virtual world, and to prepare and provide for the introduction of
the expanding presence of the virtual world. 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 The other fundamental ideal of the IOTP effort is to produce a
of these trading events in such a way that no matter where produced, two definition of these trading events in such a way that no matter where
unfamiliar parties using electronic commerce capabilities to buy and sell produced, two unfamiliar parties using electronic commerce
that conform to the IOTP specifications will be able to complete the capabilities to buy and sell that conform to the IOTP specifications
business safely and successfully. will be able to complete the business safely and successfully.
In summary, IOTP supports: In summary, IOTP supports:
o Familiar trading models o Familiar trading models
o New trading models o New trading models
o Global interoperability o Global interoperability
The remainder of this section provides background to why IOTP was The remainder of this section provides background to why IOTP was
developed. The specification itself starts in the next chapter. developed. The specification itself starts in the next chapter.
1.1 Commerce on the Internet, a Different Model 1.1 Commerce on the Internet, a Different Model
The growth of the Internet and the advent of electronic commerce are The growth of the Internet and the advent of electronic commerce are
bringing about enormous changes around the world in society, politics and bringing about enormous changes around the world in society, politics
government, and in business. The ways in which trading partners and government, and in business. The ways in which trading partners
communicate, conduct commerce, are governed have been enriched and communicate, conduct commerce, are governed have been enriched and
changed forever. changed forever.
One of the very fundamental changes about which IOTP is concerned is One of the very fundamental changes about which IOTP is concerned is
taking place in the way consumers and merchants trade. Characteristics of taking place in the way consumers and merchants trade.
trading that have changed markedly include: Characteristics of trading that have changed markedly include:
o Presence: Face-to-face transactions become the exception, not the rule. o Presence: Face-to-face transactions become the exception, not the
Already with the rise of mail order and telephone order placement this rule. Already with the rise of mail order and telephone order
change has been felt in western commerce. Electronic commerce over the placement this change has been felt in western commerce.
Internet will further expand the scope and volume of transactions Electronic commerce over the Internet will further expand the
conducted without ever seeing the people who are a part of the scope and volume of transactions conducted without ever seeing the
enterprise with whom one does business. people who are a part of the enterprise with whom one does
business.
o Authentication: An important part of personal presence is the ability o Authentication: An important part of personal presence is the
of the parties to use familiar objects and dialogue to confirm they are ability of the parties to use familiar objects and dialogue to
who they claim to be. The seller displays one or several well known confirm they are who they claim to be. The seller displays one or
financial logos that declaim his ability to accept widely used credit several well known financial logos that declaim his ability to
and debit instruments in the payment part of a purchase. The buyer accept widely used credit and debit instruments in the payment
brings government or financial institution identification that assures part of a purchase. The buyer brings government or financial
the seller she will be paid. People use intangibles such as personal institution identification that assures the seller she will be
appearance and conduct, location of the store, apparent quality and paid. People use intangibles such as personal appearance and
familiarity with brands of merchandise, and a good clear look in the conduct, location of the store, apparent quality and familiarity
eye to reinforce formal means of authentication. 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 o Payment Instruments: Despite the enormous size of bank card
payments associations and their members, most of the world's trade financial payments associations and their members, most of the
still takes place using the coin of the realm or barter. The present world's trade still takes place using the coin of the realm or
infrastructure of the payments business cannot economically support low barter. The present infrastructure of the payments business cannot
value transactions and could not survive under the consequent volumes economically support low value transactions and could not survive
of transactions if it did accept low value transactions. under the consequent volumes of transactions if it did accept low
value transactions.
o Transaction Values: New meaning for low value transactions arises in o Transaction Values: New meaning for low value transactions arises
the Internet where sellers may wish to offer for example, pages of in the Internet where sellers may wish to offer for example, pages
information for fractions of currency that do not exist in the real of information for fractions of currency that do not exist in the
world. real world.
o Delivery: New modes of delivery must be accommodated such as direct o Delivery: New modes of delivery must be accommodated such as
electronic delivery. The means by which receipt is confirmed and the direct electronic delivery. The means by which receipt is
execution of payment change dramatically where the goods or services confirmed and the execution of payment change dramatically where
have extremely low delivery cost but may in fact have very high value. the goods or services have extremely low delivery cost but may in
Or, maybe the value is not high, but once delivery occurs the value is fact have very high value. Or, maybe the value is not high, but
irretrievably delivered so payment must be final and non-refundable but once delivery occurs the value is irretrievably delivered so
delivery nonetheless must still be confirmed before payment. payment must be final and non-refundable but delivery nonetheless
Incremental delivery such as listening or viewing time or playing time must still be confirmed before payment. Incremental delivery such
are other models that operate somewhat differently in the virtual as listening or viewing time or playing time are other models that
world. operate somewhat differently in the virtual world.
1.2 Benefits of IOTP 1.2 Benefits of IOTP
ELECTRONIC COMMERCE SOFTWARE VENDORS ELECTRONIC COMMERCE SOFTWARE VENDORS
Electronic Commerce Software Vendors will be able to develop e-commerce Electronic Commerce Software Vendors will be able to develop e-
products which are more attractive as they will inter-operate with any commerce products which are more attractive as they will inter-
other vendors' software. However since IOTP focuses on how these operate with any other vendors' software. However, since IOTP focuses
solutions communicate, there is still plenty of opportunity for product on how these solutions communicate, there is still plenty of
differentiation. opportunity for product differentiation.
PAYMENT BRANDS PAYMENT BRANDS
IOTP provides a standard framework for encapsulating payment protocols. IOTP provides a standard framework for encapsulating payment
This means that it is easier for payment products to be incorporated into protocols. This means that it is easier for payment products to be
IOTP solutions. As a result the payment brands will be more widely incorporated into IOTP solutions. As a result the payment brands will
distributed and available on a wider variety of platforms. be more widely distributed and available on a wider variety of
platforms.
MERCHANTS MERCHANTS
There are several benefits for Merchants: There are several benefits for Merchants:
o they will be able to offer a wider variety of payment brands, 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 o they can be more certain that the customer will have the software
needed to complete the purchase needed to complete the purchase
o through receiving payment and delivery receipts from their customers, o through receiving payment and delivery receipts from their
they will be able to provide customer care knowing that they are customers, they will be able to provide customer care knowing that
dealing with the individual or organisation with which they originally they are dealing with the individual or organisation with which
traded they originally traded
o new merchants will be able to enter this new (Internet) market-place o new merchants will be able to enter this new (Internet) market-
with new products and services, using the new trading opportunities place with new products and services, using the new trading
which IOTP presents opportunities which IOTP presents
BANKS AND FINANCIAL INSTITUTIONS BANKS AND FINANCIAL INSTITUTIONS
There are also several benefits for 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 be able to provide IOTP support for merchants
o they will find new opportunities for IOTP related services: 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 - providing customer care for merchants
merchants - fees from processing new payments and deposits
CUSTOMERS o they have an opportunity to build relationships with new types of
merchants
For Customers there are several benefits: CUSTOMERS
o they will have a larger selection of merchants with whom they can trade For Customers there are several benefits:
o there is a more consistent interface when making the purchase o they will have a larger selection of merchants with whom they can
trade
o there are ways in which they can get their problems fixed through the o there is a more consistent interface when making the purchase
merchant (rather than the bank!)
o there is a record of their transaction which can be used, for example, o there are ways in which they can get their problems fixed through
to feed into accounting systems or, potentially, to present to the tax the merchant (rather than the bank!)
authorities
o there is a record of their transaction which can be used, for
example, to feed into accounting systems or, potentially, to
present to the tax authorities
1.3 Baseline IOTP 1.3 Baseline IOTP
This specification is Baseline IOTP. It is a Baseline in that it contains This specification is Baseline IOTP. It is a Baseline in that it
ways of doing trades on the Internet which are the most common, for contains ways of doing trades on the Internet which are the most
example purchases and refunds. common, for example purchases and refunds.
The group that has worked on the IOTP see an extended version being The group that has worked on the IOTP see an extended version being
developed over time but feel a need to focus on a limited function but developed over time but feel a need to focus on a limited function
completely usable specification in order that implementers can develop but completely usable specification in order that implementers can
solutions that work now. develop solutions that work now.
During this period it is anticipated that there will be no changes to the During this period it is anticipated that there will be no changes to
scope of this specification with the only changes made being limited to the scope of this specification with the only changes made being
corrections where problems are found. Software solutions have been limited to corrections where problems are found. Software solutions
developed based on earlier versions of this specification (for example have been developed based on earlier versions of this specification
version 0.9 published in early 1998 and earlier revisions of version 1.0 (for example version 0.9 published in early 1998 and earlier
published during 1999) which prove that the IOTP works. revisions of version 1.0 published during 1999) which prove that the
IOTP works.
1.4 Objectives of Document 1.4 Objectives of Document
The objectives of this document are to provide a specification of version The objectives of this document are to provide a specification of
1.0 of the Internet Open Trading Protocols which can be used to design version 1.0 of the Internet Open Trading Protocols which can be used
and implement systems which support electronic trading on the Internet to design and implement systems which support electronic trading on
using the Internet Open Trading Protocols. the Internet using the Internet Open Trading Protocols.
The purpose of the document is: The purpose of the document is:
o to allow potential developers of products based on the protocol to o to allow potential developers of products based on the protocol to
develop software/hardware solutions which use the protocol develop software/hardware solutions which use the protocol
o to allow the financial services industry to understand a developing o to allow the financial services industry to understand a
electronic commerce trading protocol that encapsulates (without developing electronic commerce trading protocol that encapsulates
modification) any of the current or developing payment schemes now (without modification) any of the current or developing payment
being used or considered by their merchant customer base schemes now being used or considered by their merchant customer
base
1.5 Scope of Document 1.5 Scope of Document
The protocol describes the content, format and sequences of messages that The protocol describes the content, format and sequences of messages
pass among the participants in an electronic trade - consumers, merchants that pass among the participants in an electronic trade - consumers,
and banks or other financial institutions, and customer care providers. merchants and banks or other financial institutions, and customer
These are required to support the electronic commerce transactions care providers. These are required to support the electronic
outlined in the objectives above. commerce transactions outlined in the objectives above.
The protocol is designed to be applicable to any electronic payment The protocol is designed to be applicable to any electronic payment
scheme since it targets the complete purchase process where the movement scheme since it targets the complete purchase process where the
of electronic value from the payer to the payee is only one, but movement of electronic value from the payer to the payee is only one,
important, step of many that may be involved to complete the trade. but important, step of many that may be involved to complete the
trade.
Payment Scheme which IOTP could support include MasterCard Credit, Visa Payment Scheme which IOTP could support include MasterCard Credit,
Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin,
Proton etc. Millicent, Proton, etc.
Each payment scheme contains some message flows which are specific to Each payment scheme contains some message flows which are specific to
that scheme. These scheme-specific parts of the protocol are contained in that scheme. These scheme-specific parts of the protocol are
a set of payment scheme supplements to this specification. contained in a set of payment scheme supplements to this
specification.
The document does not prescribe the software and processes that will need The document does not prescribe the software and processes that will
to be implemented by each participant. It does describe the framework need to be implemented by each participant. It does describe the
necessary for trading to take place. framework necessary for trading to take place.
This document also does not address any legal or regulatory issues This document also does not address any legal or regulatory issues
surrounding the implementation of the protocol or the information systems surrounding the implementation of the protocol or the information
which use them. systems which use them.
1.6 Document Structure 1.6 Document Structure
The document consists of the following sections: The document consists of the following sections:
o Section 1 - Background: This section gives a brief background on o Section 1 - Background: This section gives a brief background on
electronic commerce and the benefits IOTP offers. electronic commerce and the benefits IOTP offers.
o Section 2 - Introduction: This section describes the various Trading o Section 2 - Introduction: This section describes the various
Exchanges and shows how these trading exchanges are used to construct Trading Exchanges and shows how these trading exchanges are used
the IOTP Transactions. This section also explains various Trading Roles to construct the IOTP Transactions. This section also explains
that would participate in electronic trade. various Trading Roles that would participate in electronic trade.
o Section 3 - Protocol Structure: This section summarises how various o Section 3 - Protocol Structure: This section summarises how
IOTP transactions are constructed using the Trading Blocks and Trading various IOTP transactions are constructed using the Trading Blocks
Components that are the fundamental building blocks for IOTP and Trading Components that are the fundamental building blocks
transactions. All IOTP transaction messages are well formed XML for IOTP transactions. All IOTP transaction messages are well
documents. formed XML documents.
o Section 4 - IOTP Error Handling: This section describes how to process o Section 4 - IOTP Error Handling: This section describes how to
exceptions and errors during the protocol message exchange and trading process exceptions and errors during the protocol message exchange
exchange processing. This section provides a generic overview of the and trading exchange processing. This section provides a generic
exception handling. This section should be read carefully. overview of the exception handling. This section should be read
carefully.
o Section 5 - Security Considerations: This section considers from an o Section 5 - Security Considerations: This section considers from
IETF perspective, how IOTP addresses security. It includes: how to an IETF perspective, how IOTP addresses security. It includes: how
determine whether to use digital signatures with IOTP, how IOTP address to determine whether to use digital signatures with IOTP, how IOTP
data privacy, and how security built into payment protocols relate to address data privacy, and how security built into payment
IOTP security. protocols relate to IOTP security.
o Section 6 - Digital Signatures and IOTP: This section provides an o Section 6 - Digital Signatures and IOTP: This section provides an
overview of how IOTP uses digital signatures; how to check a signature overview of how IOTP uses digital signatures; how to check a
is correctly calculated and how the various Trading Roles that signature is correctly calculated and how the various Trading
participate in trade should check signatures when required. Roles that participate in trade should check signatures when
required.
o Section 7 - Trading Components: This section defines the XML elements o Section 7 - Trading Components: This section defines the XML
required by Trading Components. elements required by Trading Components.
o Section 8 - Trading Blocks: This section describes how Trading Blocks o Section 8 - Trading Blocks: This section describes how Trading
are constructed from Trading Components. Blocks are constructed from Trading Components.
o Section 9 - Internet Open Trading Protocol Transactions: This section o Section 9 - Internet Open Trading Protocol Transactions: This
describes all the IOTP Baseline transactions. It refers to Trading section describes all the IOTP Baseline transactions. It refers to
Blocks and Trading Components and Signatures. This section doesn't Trading Blocks and Trading Components and Signatures. This section
directly link error handling during the protocol exchanges, the reader doesn't directly link error handling during the protocol
is advised to understand Error Handling as defined in section before exchanges, the reader is advised to understand Error Handling as
reading this section. defined in section before reading this section.
o Section 10 - Retrieving Logos: This section describes how IOTP specific o Section 10 - Retrieving Logos: This section describes how IOTP
logos can be retrieved. specific logos can be retrieved.
o Section 11 - Brands: This section provides: an overview of Brand o Section 11 - Brands: This section provides: an overview of Brand
Definitions and Brand Selection which describe how a Consumer can Definitions and Brand Selection which describe how a Consumer can
select a Brand from a list provided by the Merchant; as well as some select a Brand from a list provided by the Merchant; as well as
examples of Brand Lists. some examples of Brand Lists.
o Section 12 - IANA Considerations: This section describes how new values o Section 12 - IANA Considerations: This section describes how new
for codes used by IOTP are co-ordinated. values for codes used by IOTP are co-ordinated.
o Section 13 - Internet Open Trading Protocol Data Type Definition: This o Section 13 - Internet Open Trading Protocol Data Type Definition:
section contains the XML Data Type Definitions for IOTP. This section contains the XML Data Type Definitions for IOTP.
o Section 14 - Glossary. This describes all the major terminology used by o Section 14 - Glossary. This describes all the major terminology
IOTP. used by IOTP.
o Section 15 - Copyright information. o Section 15 - A list of the other documents referenced by the IOTP
specification.
o Section 16 - A list of the other documents referenced by the IOTP o Section 16 - The Author's Address
specification.
o Section 17 - The Author's Address o Section 17 - Full Copyright Statement
1.7 Intended Readership 1.7 Intended Readership
Software and hardware developers; development analysts; business and Software and hardware developers; development analysts; business and
technical planners; industry analysts; merchants; bank and other payment technical planners; industry analysts; merchants; bank and other
handlers; owners, custodians, and users of payment protocols. payment handlers; owners, custodians, and users of payment protocols.
1.7.1 Reading Guidelines 1.7.1 Reading Guidelines
This IOTP specification is structured primarily in a sequence targeted at This IOTP specification is structured primarily in a sequence
people who want to understand the principles of IOTP. However from targeted at people who want to understand the principles of IOTP.
practical implementation experience by implementers of earlier of However from practical implementation experience by implementers of
versions of the protocol new readers who plan to implement IOTP may earlier of versions of the protocol new readers who plan to implement
prefer to read the document in a different sequence as described below. IOTP may prefer to read the document in a different sequence as
described below.
Review the transport independent parts of the specification: This covers Review the transport independent parts of the specification. This
covers:
o Section 14 - Glossary o Section 14 - Glossary
o Section 1 - Background
o Section 2 - Introduction o Section 1 - Background
o Section 3 - Protocol Structure o Section 2 - Introduction
o Section 4 - IOTP Error Handling o Section 3 - Protocol Structure
o Section 5 - Security Considerations o Section 4 - IOTP Error Handling
o Section 5 - Security Considerations
o Section 9 - Internet Open Trading Protocol Transactions o Section 9 - Internet Open Trading Protocol Transactions
o Section 11 - Brands o Section 11 - Brands
o Section 12 - IANA Considerations o Section 12 - IANA Considerations
o Section 10 - Retrieving Logos o Section 10 - Retrieving Logos
Review the detailed XML definitions: Review the detailed XML definitions:
o Section 8 - Trading Blocks o Section 8 - Trading Blocks
o Section 7 - Trading Components o Section 7 - Trading Components
o Section 6 - Digital Signatures and IOTP o Section 6 - Digital Signatures and IOTP
2. Introduction 2. Introduction
The Internet Open Trading Protocols (IOTP) define a number of different The Internet Open Trading Protocols (IOTP) define a number of
types of IOTP Transactions: different types of IOTP Transactions:
o Purchase. This supports a purchase involving an offer, a payment and o Purchase. This supports a purchase involving an offer, a payment
optionally a delivery and optionally a delivery
o Refund. This supports the refund of a payment as a result of, o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase typically, an earlier purchase
o Value Exchange. This involves two payments which result in the exchange o Value Exchange. This involves two payments which result in the
of value from one combination of currency and payment method to another exchange of value from one combination of currency and payment
method to another
o Authentication. This supports one organisation or individual to check o Authentication. This supports one organisation or individual to
that another organisation or individual are who they appear to be. check that another organisation or individual are who they appear
to be.
o Withdrawal. This supports the withdrawal of electronic cash from a o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution financial institution
o Deposit. This supports the deposit of electronic cash at a financial o Deposit. This supports the deposit of electronic cash at a
institution financial institution
o Inquiry This supports inquiries on the status of an IOTP transaction o Inquiry. This supports inquiries on the status of an IOTP
which is either in progress or is complete transaction which is either in progress or is complete
o Ping This supports a simple query which enables one IOTP aware o Ping. This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running application to determine whether another IOTP application running
elsewhere is working or not. elsewhere is working or not.
These IOTP Transactions are "Baseline" transactions since they have been These IOTP Transactions are "Baseline" transactions since they have
identified as a minimum useful set of transactions. Later versions of been identified as a minimum useful set of transactions. Later
IOTP may include additional types of transactions. versions of IOTP may include additional types of transactions.
Each of the IOTP Transactions above involve: Each of the IOTP Transactions above involve:
o a number of organisations playing a Trading Role, and o a number of organisations playing a Trading Role, and
o a set of Trading Exchanges. Each Trading Exchange involves the exchange o a set of Trading Exchanges. Each Trading Exchange involves the
of data, between Trading Roles, in the form of a set of Trading exchange of data, between Trading Roles, in the form of a set of
Components. Trading Components.
Trading Roles, Trading Exchanges and Trading Components are described Trading Roles, Trading Exchanges and Trading Components are described
below. below.
2.1 Trading Roles 2.1 Trading Roles
The Trading Roles identify the different parts which organisations can The Trading Roles identify the different parts which organisations
take in a trade. The five Trading Roles used within IOTP are illustrated can take in a trade. The five Trading Roles used within IOTP are
in the diagram below. illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Customer Care Provider resolves ---------- Merchant Customer Care Provider resolves ----------
---------------------------------------------->| Merchant | ---------------------------------------------->| Merchant |
| Consumer disputes and problems |Cust.Care.| | Consumer disputes and problems |Cust.Care.|
| | Provider | | | Provider |
| ---------- | ----------
| |
Payment Handler accepts or makes ---------- Payment Handler accepts or makes ----------
| ------------------------------------------>| Payment | | ------------------------------------------>| Payment |
| | Payment for Merchant | Handler | | | Payment for Merchant | Handler |
| | ---------- | | ----------
v v v v
---------- Consumer makes purchases or obtains ---------- ---------- Consumer makes purchases or obtains ----------
| Consumer |<--------------------------------------->| Merchant | | Consumer |<--------------------------------------->| Merchant |
---------- refund from Merchant ---------- ---------- refund from Merchant ----------
^ ^
| Delivery Handler supplies goods or ---------- | Delivery Handler supplies goods or ----------
|---------------------------------------------->|Deliverer | |---------------------------------------------->|Deliverer |
services for Merchant ---------- services for Merchant | Handler |
----------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 1 IOTP Trading Roles Figure 1 IOTP Trading Roles
The roles are: The roles are:
o Consumer. The person or organisation which is to receive and pay for o Consumer. The person or organisation which is to receive and pay
the goods or services for the goods or services
o Merchant. The person or organisation from whom the purchase is being o Merchant. The person or organisation from whom the purchase is
made and who is legally responsible for providing the goods or services being made and who is legally responsible for providing the goods
and receives the benefit of the payment made or services and receives the benefit of the payment made
o Payment Handler. The entity that physically receives the payment from o Payment Handler. The entity that physically receives the payment
the Consumer on behalf of the Merchant from the Consumer on behalf of the Merchant
o Delivery Handler. The entity that physically delivers the goods or o Delivery Handler. The entity that physically delivers the goods or
services to the Consumer on behalf of the Merchant. services to the Consumer on behalf of the Merchant.
o Merchant Customer Care Provider. The entity that is involved with o Merchant Customer Care Provider. The entity that is involved with
customer dispute negotiation and resolution on behalf of the Merchant customer dispute negotiation and resolution on behalf of the
Merchant
Roles may be carried out by the same organisation or different Roles may be carried out by the same organisation or different
organisations. For example: organisations. For example:
o in the simplest case one physical organisation (e.g. a merchant) could o in the simplest case one physical organisation (e.g., a merchant)
handle the purchase, accept the payment, deliver the goods and provide could handle the purchase, accept the payment, deliver the goods
merchant customer care and provide merchant customer care
o at the other extreme, a merchant could handle the purchase but instruct o at the other extreme, a merchant could handle the purchase but
the consumer to pay a bank or financial institution, request that instruct the consumer to pay a bank or financial institution,
delivery be made by an overnight courier firm and to contact an request that delivery be made by an overnight courier firm and to
organisation which provides 24x7 service if problems arise. contact an organisation which provides 24x7 service if problems
arise.
Note that in this specification, unless stated to the contrary, when the Note that in this specification, unless stated to the contrary, when
words Consumer, Merchant, Payment Handler, Delivery Handler or Customer the words Consumer, Merchant, Payment Handler, Delivery Handler or
Care Provider are used, they refer to the Trading Role rather than an Customer Care Provider are used, they refer to the Trading Role
actual organisation. rather than an actual organisation.
An individual organisation may take multiple roles. For example a company An individual organisation may take multiple roles. For example a
which is selling goods and services on the Internet could take the role company which is selling goods and services on the Internet could
of Merchant when selling goods or services and the role of Consumer when take the role of Merchant when selling goods or services and the role
the company is buying goods or services itself. of Consumer when the company is buying goods or services itself.
As roles occur in different places there is a need for the organisations As roles occur in different places there is a need for the
involved in the trade to exchange data, i.e. to carry out Trading organisations involved in the trade to exchange data, i.e. to carry
Exchanges, so that the trade can be completed. out Trading Exchanges, so that the trade can be completed.
2.2 Trading Exchanges 2.2 Trading Exchanges
The Internet Open Trading Protocols identify four Trading Exchanges which The Internet Open Trading Protocols identify four Trading Exchanges
involve the exchange of data between the Trading Roles. The Trading which involve the exchange of data between the Trading Roles. The
Exchanges are: Trading Exchanges are:
o Offer. The Offer Exchange results in the Merchant providing the 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 Consumer with the reason why the trade is taking place. It is
Offer since the Consumer must accept the Offer if a trade is to called an Offer since the Consumer must accept the Offer if a
continue trade is to continue
o Payment. The Payment Exchange results in a payment of some kind between o Payment. The Payment Exchange results in a payment of some kind
the Consumer and the Payment Handler. This may occur in either between the Consumer and the Payment Handler. This may occur in
direction either direction
o Delivery. The Delivery Exchange transmits either the on-line goods, or o Delivery. The Delivery Exchange transmits either the on-line
delivery information about physical goods from the Delivery Handler to goods, or delivery information about physical goods from the
the Consumer, and Delivery Handler to the Consumer, and
o Authentication. The Authentication Exchange can be used by any Trading o Authentication. The Authentication Exchange can be used by any
Role to authenticate another Trading Role to check that they are who Trading Role to authenticate another Trading Role to check that
they appear to be. they are who they appear to be.
IOTP Transactions are composed of various combinations of these Trading IOTP Transactions are composed of various combinations of these
Exchanges. For example, an IOTP Purchase transaction includes Offer, Trading Exchanges. For example, an IOTP Purchase transaction
Payment, and Delivery Trading Exchanges. As another example, an IOTP includes Offer, Payment, and Delivery Trading Exchanges. As another
Value Exchange transaction is composed of an Offer Trading Exchange and example, an IOTP Value Exchange transaction is composed of an Offer
two Payment Trading Exchanges. Trading Exchange and two Payment Trading Exchanges.
Trading Exchanges consist of Trading Components that are transmitted Trading Exchanges consist of Trading Components that are transmitted
between the various Trading Roles. Where possible, the number of round- between the various Trading Roles. Where possible, the number of
trip delays in an IOTP Transaction is minimised by packing the Components round-trip delays in an IOTP Transaction is minimised by packing the
from several Trading Exchanges into combination IOTP Messages. For Components from several Trading Exchanges into combination IOTP
example, the IOTP Purchase transaction combines a Delivery Organisation Messages. For example, the IOTP Purchase transaction combines a
Component with an Offer Response Component in order to avoid an extra Delivery Organisation Component with an Offer Response Component in
Consumer request and response. order to avoid an extra Consumer request and response.
Each of the IOTP Trading Exchanges is described in more detail below. For Each of the IOTP Trading Exchanges is described in more detail below.
clarity of description, these describe the Trading Exchanges as though For clarity of description, these describe the Trading Exchanges as
they were standalone operations. For performance reasons, the Trading though they were standalone operations. For performance reasons, the
Exchanges are intermingled in the actual IOTP Transaction definitions. Trading Exchanges are intermingled in the actual IOTP Transaction
definitions.
2.2.1 Offer Exchange 2.2.1 Offer Exchange
The goal of the Offer Exchange is for the Merchant to provide the 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 Consumer with information about the trade so that the Consumer can
whether to continue with the trade. This is illustrated in the figure decide whether to continue with the trade. This is illustrated in the
below. figure below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Consumer
| Merchant | Merchant
STEP | | STEP | |
1. Consumer decides to trade and sends information about the 1. Consumer decides to trade and sends information about the
transaction (requests an offer) to the Merchant e.g. using transaction (requests an offer) to the Merchant e.g.,
HTML. using HTML.
C --> M Data: Information on what is being purchased (Offer Request) C --> M Data: Information on what is being purchased (Offer Request)
- outside scope of IOTP - outside scope of IOTP
2. Merchant checks the information provided by the Consumer, 2. Merchant checks the information provided by the Consumer,
creates an Offer optionally signs it and sends it to the creates an Offer optionally signs it and sends it to the
Consumer. Consumer.
C <-- M OFFER RESPONSE. Components: Status; Organisation(s) C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
(Consumer, DelivTo, Merchant, Payment Handler, Customer (Consumer, DelivTo, Merchant, Payment Handler, Customer
Care); Order; Payment; Delivery; TradingRoleData (optional) Care); Order; Payment; Delivery; TradingRoleData (optional)
Offer Response Signature (optional) that signs other Offer Response Signature (optional) that signs other
components components
3. Consumer checks the information from the Merchant and decides 3. Consumer checks the information from the Merchant and
whether to continue. decides whether to continue.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 2 Offer Exchange Figure 2 Offer Exchange
An Offer Exchange uses the following Trading Components that are passed An Offer Exchange uses the following Trading Components that are
between the Consumer and the Merchant: passed between the Consumer and the Merchant:
o the Status component is used to indicate to other parties that a valid o the Status component is used to indicate to other parties that a
Offer Response has been generated valid Offer Response has been generated
o the Organisation Component contains information which describes the o the Organisation Component contains information which describes
Organisations which are taking a role in the trade: the Organisations which are taking a role in the trade:
- the consumer provides information, about who the consumer is and, if - the consumer provides information, about who the consumer is
goods or services are being delivered, where the goods or services and, if goods or services are being delivered, where the goods
are to be delivered to 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 - the merchant augments this information by providing information
which will result from the trade if the consumer agrees to the offer. about the merchant, the Payment Handler, the customer care
This information is sent by the Merchant to the consumer who should provider and, if goods or services are being delivered, the
verify it Delivery Handler
o the Payment Component generated by the Merchant, contains details of o the Order Component contains descriptions of the goods or services
how much to pay, the currency and the payment direction, for example which will result from the trade if the consumer agrees to the
the consumer could be asking for a refund. Note that there may be more offer. This information is sent by the Merchant to the consumer
than one payment in a trade who should verify it
o the Delivery Component, also generated by the Merchant, is used if o the Payment Component generated by the Merchant, contains details
goods or services are being delivered. This contains information about of how much to pay, the currency and the payment direction, for
how delivery will occur, for example by post or using e-mail example the consumer could be asking for a refund. Note that there
may be more than one payment in a trade
o the Trading Role Data component contains data the Merchant wants to o the Delivery Component, also generated by the Merchant, is used if
forward to another Trading Role such as a Payment Handler or Delivery goods or services are being delivered. This contains information
Handler about how delivery will occur, for example by post or using e-mail
o the "Offer Response" Signature Component, if present, digitally signs o the Trading Role Data component contains data the Merchant wants
all of the above components to ensure their integrity. to forward to another Trading Role such as a Payment Handler or
Delivery Handler
The exact content of the information provided by the Merchant to the o the "Offer Response" Signature Component, if present, digitally
Consumer will vary depending on the type of IOTP Transaction. For signs all of the above components to ensure their integrity.
example:
o low value purchases may not need a signature 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 the amount to be paid may vary depending on the payment brand and o low value purchases may not need a signature
payment protocol used
o some offers may not involve the delivery of any goods o the amount to be paid may vary depending on the payment brand and
payment protocol used
o a value exchange will involve two payments o some offers may not involve the delivery of any goods
o a merchant may not offer customer care. o a value exchange will involve two payments
Information provided by the consumer to the merchant is provided using a o a merchant may not offer customer care.
variety of methods, for example, it could be provided:
o using [HTML] pages as part of the "shopping experience" of the Information provided by the consumer to the merchant is provided
consumer. using a variety of methods, for example, it could be provided:
o Using the Open Profiling Standard [OPS] which has recently been o using [HTML] pages as part of the "shopping experience" of the
proposed, consumer.
o in the form of Organisation Components associated with an o Using the Open Profiling Standard [OPS] which has recently been
authentication of a Consumer by a Merchant proposed,
o as Order Components in a later version of IOTP. o in the form of Organisation Components associated with an
authentication of a Consumer by a Merchant
o as Order Components in a later version of IOTP.
2.2.2 Payment Exchange 2.2.2 Payment Exchange
The goal of the Payment Exchange is for a payment to be made from the 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 Consumer to a Payment Handler or vice versa using a payment brand and
payment protocol selected by the Consumer. A secondary goal is to payment protocol selected by the Consumer. A secondary goal is to
optionally provide the Consumer with a digitally signed Payment Receipt optionally provide the Consumer with a digitally signed Payment
which can be used to link the payment to the reason for the payment as Receipt which can be used to link the payment to the reason for the
described in the Offer Exchange. 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.
Payment Exchanges can work in a variety of ways. The most general case
where the trade is dependent on the payment brand and protocol used is
illustrated in the diagram below. Simpler payment exchanges are possible.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Pay Handler Consumer Pay Handler
| Merchant | | Merchant |
STEP | | | STEP | | |
1. Consumer decides to trade and sends information about 1. Consumer decides to trade and sends information
the transaction (requests an offer) to the Merchant about the transaction (requests an offer) to the
e.g. using HTML. Merchant e.g., using HTML.
C --> M Information on what is being paid for (outside scope C --> M Information on what is being paid for (outside
of IOTP scope of IOTP
2. Merchant decides which payment brand, payment 2. Merchant decides which payment brand, payment
protocols and currencies/amounts to offer, places then protocols and currencies/amounts to offer,
in a Brand List Component and sends them to the places then in a Brand List Component and sends
Consumer them to the Consumer
C <-- M Components: Brand List C <-- M Components: Brand List
3. Consumer selects the payment brand, protocol and 3. Consumer selects the payment brand, protocol and
currency/amount to use, creates a Brand Selection currency/amount to use, creates a Brand Selection
component and sends it to the Merchant component and sends it to the Merchant
C --> M Component: Brand List Selection C --> M Component: Brand List Selection
4. Merchant checks Brand Selection, creates a Payment 4. Merchant checks Brand Selection, creates a Payment
Amount information, optionally signs it to authorise Amount information, optionally signs it to
payment and sends it to the Consumer authorise payment and sends it to the Consumer
C <-- M Component: Payment; Organisation(s) (Merchant and C <-- M Component: Payment; Organisation(s) (Merchant and
Payment Handler); Optional Offer Response Signature Payment Handler); Optional Offer Response Signature
that signs other components that signs other components
5. Consumer checks the Payment Amount information and if 5. Consumer checks the Payment Amount information and
OK requests that the payment starts by sending if OK requests that the payment starts by sending
information to the Payment Handler information to the Payment Handler
C --------> P PAYMENT REQUEST. Components: Status, Payment; C --------> P PAYMENT REQUEST. Components: Status, Payment;
Organisations (Merchant and Payment Handler); Trading Organisations (Merchant and Payment Handler);
Role Data (optional); Optional Offer Response Trading Role Data (optional); Optional Offer
Signature that signs other components; Pay Scheme Data Response Signature that signs other components;
Pay Scheme Data
6. Payment Handler checks information including optional 6. Payment Handler checks information including
signature and if OK starts exchanging Pay Scheme Data optional signature and if OK starts exchanging Pay
components for selected payment brand and payment Scheme Data components for selected payment brand
protocol and payment protocol
C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data
7. Eventually payment protocol messages finish so Payment 7. Eventually payment protocol messages finish so
Handler sends Pay Receipt and optional signature to Payment Handler sends Pay Receipt and optional
the Consumer as proof of payment signature to the Consumer as proof of payment
C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt; C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt;
Payment Note; Trading Role Data (optional); Optional Payment Note; Trading Role Data (optional);
Offer Response Signature; Optional Payment Receipt Optional Offer Response Signature; Optional
Signature that binds the payment to the Offer Payment Receipt Signature that binds the payment
to the Offer
8. Consumer checks Payment Receipt is OK 8. Consumer checks Payment Receipt is OK
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 3 Payment Exchange Figure 3 Payment Exchange
A Payment Exchange uses the following Trading Components that are passed A Payment Exchange uses the following Trading Components that are
between the Consumer, the Merchant and the Payment Handler: passed between the Consumer, the Merchant and the Payment Handler:
o The Brand List Component contains a list of payment brands (for o The Brand List Component contains a list of payment brands (for
example, MasterCard, Visa, Mondex, GeldKarte), payment protocols (for example, MasterCard, Visa, Mondex, GeldKarte), payment protocols
example SET Version 1.0, Secure Channel Credit Debit (SCCD - the name (for example SET Version 1.0, Secure Channel Credit Debit (SCCD -
used for a credit or debit card payment where unauthorised access to the name used for a credit or debit card payment where
account information is prevented through use of secure channel unauthorised access to account information is prevented through
transport mechanisms such as SSL/TLS) as well as currencies/amounts use of secure channel transport mechanisms such as SSL/TLS) as
that apply. The Merchant sends the Brand List to the Consumer. The well as currencies/amounts that apply. The Merchant sends the
consumer compares the payment brands, protocols and currencies/amounts Brand List to the Consumer. The consumer compares the payment
on offer with those that the Consumer supports and makes a selection. brands, protocols and currencies/amounts on offer with those that
the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's selection. o The Brand Selection Component contains the Consumer's selection.
Payment brand, protocol, currency/amount and possibly protocol-specific Payment brand, protocol, currency/amount and possibly protocol-
information is sent back to the Merchant. This information may be used specific information is sent back to the Merchant. This
to change information in the Offer Exchange. For example, a merchant information may be used to change information in the Offer
could choose to offer a discount to encourage the use of a store card. Exchange. For example, a merchant could choose to offer a discount
to encourage the use of a store card.
o the Status component is used to indicate to the Payment Handler that an o the Status component is used to indicate to the Payment Handler
earlier exchange (e.g. an Offer Exchange) has successfully completed that an earlier exchange (e.g., an Offer Exchange) has
and by the Payment Handler to indicate the completion status of the successfully completed and by the Payment Handler to indicate the
Payment Exchange. completion status of the Payment Exchange.
o The Organisation Components are generated by the Merchant. They contain o The Organisation Components are generated by the Merchant. They
details of the Merchant and Payment Handler Roles: contain details of the Merchant and Payment Handler Roles:
- the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the result
of the Payment Handler accepting (or making) a payment on behalf of
the Merchant will be a credit or debit transaction to the Merchant's
account held by the Payment Handler. These transactions are outside
the scope of this version of IOTP
- the Payment Handler role is required so that the Payment Handler can
check that it is the correct Payment Handler to be used for the
payment
o The Payment Component contains details of how much to pay, the currency - the Merchant role is required so that the Payment Handler can
and the payment direction identify which Merchant initiated the payment. Typically, the
result of the Payment Handler accepting (or making) a payment
on behalf of the Merchant will be a credit or debit transaction
to the Merchant's account held by the Payment Handler. These
transactions are outside the scope of this version of IOTP
o The "Offer Response" Signature Component, if present, digitally signs - the Payment Handler role is required so that the Payment
all of the above components to ensure their integrity. Note that the Handler can check that it is the correct Payment Handler to be
Brand List and Brand Selection Components are not signed until the used for the payment
payment information is created (step 4 in the diagram)
o the Trading Role Data component contains from other roles (e.g. a o The Payment Component contains details of how much to pay, the
Merchant) that needs to be forwarded to the Payment Handler currency and the payment direction
o The Payment Scheme Component contains messages from the payment o The "Offer Response" Signature Component, if present, digitally
protocol used in the Trade. For example they could be SET messages, signs all of the above components to ensure their integrity. Note
Mondex messages, GeldKarte Messages or one of the other payment methods that the Brand List and Brand Selection Components are not signed
supported by IOTP. The content of the Payment Scheme Component is until the payment information is created (step 4 in the diagram)
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 o the Trading Role Data component contains from other roles (e.g., a
content depends upon the payment protocol used. Merchant) that needs to be forwarded to the Payment Handler
o The "Payment Receipt" Signature Component provides proof of payment by o The Payment Scheme Component contains messages from the payment
digitally signing both the Payment Receipt Component and the Offer protocol used in the Trade. For example they could be SET
Response Signature. The signature on the offer digitally signs the messages, Mondex messages, GeldKarte Messages or one of the other
Order, Organisation and Delivery Components contained in the Offer. payment methods supported by IOTP. The content of the Payment
This signature effectively binds the payment to the offer. Scheme Component is defined in the supplements that describe how
IOTP works with various payment protocols.
The example of a Payment Exchange above is the most general case. Simpler o The Payment Receipt Component contains a record of the payment.
cases are also possible. For example, if the amount paid is not dependent The content depends upon the payment protocol used.
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 o The "Payment Receipt" Signature Component provides proof of
Brand List Component generated by step 1. These and other variations are payment by digitally signing both the Payment Receipt Component
described in the Baseline Purchase IOTP Transaction (see section 9.1.8). and the Offer Response Signature. The signature on the offer
digitally signs the Order, Organisation and Delivery Components
contained in the Offer. This signature effectively binds the
payment to the offer.
The example of a Payment Exchange above is the most general case.
Simpler cases are also possible. For example, if the amount paid is
not dependent on the payment brand and protocol selected then the
payment information generated by step 3 can be sent to the Consumer
at the same time as the Brand List Component generated by step 1.
These and other variations are described in the Baseline Purchase
IOTP Transaction (see section 9.1.8).
2.2.3 Delivery Exchange 2.2.3 Delivery Exchange
The goal of the Delivery Exchange is to cause purchased goods to be The goal of the Delivery Exchange is to cause purchased goods to be
delivered to the consumer either online or via physical delivery. A delivered to the consumer either online or via physical delivery. A
second goal is to provide a "delivery note" to the consumer, providing second goal is to provide a "delivery note" to the consumer,
details about the delivery, such as shipping tracking number. The result providing details about the delivery, such as shipping tracking
of the delivery may also be signed so that it can be used for customer number. The result of the delivery may also be signed so that it can
care in the case of problems with physical delivery. The message flow is be used for customer care in the case of problems with physical
illustrated in the diagram below. delivery. The message flow is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER DELIVERY CONSUMER DELIVERY
| HANDLER | HANDLER
| Merchant | | Merchant |
STEP | | | STEP | | |
1. Consumer decides to trade and sends information about 1. Consumer decides to trade and sends information
what to deliver and who is to take delivery, to the about what to deliver and who is to take delivery,
Merchant e.g. using HTML. to the Merchant e.g., using HTML.
C --> M Information on what is being delivered (outside scope C --> M Information on what is being delivered (outside
of IOTP) scope of IOTP)
2. Merchant checks the information provided by the 2. Merchant checks the information provided by the
Consumer, adds information about how the delivery will Consumer, adds information about how the delivery
occur, information about the Organisations involved in will occur, information about the Organisations
the delivery and optionally sings it and sends it to involved in the delivery and optionally sings it
the Consumer and sends it to the Consumer
C <-- M Components: Delivery; Organisations (Delivery Handler, C <-- M Components: Delivery; Organisations (Delivery
Deliver To); Order, Optional Offer Response Signature Handler, Deliver To); Order, Optional Offer
Response Signature
3. Consumer checks delivery information is OK, obtains 3. Consumer checks delivery information is OK,
authorisation for the delivery, for example by making obtains authorisation for the delivery, for
a payment, and sends the delivery information to the example by making a payment, and sends the
Delivery Handler delivery information to the Delivery Handler
C --------> D DELIVERY REQUEST. Components: Status; Delivery, C --------> D DELIVERY REQUEST. Components: Status; Delivery,
Organisations: (Merchant, Delivery Handler, DelivTo); Organisations: (Merchant, Delivery Handler,
Order, Trading Role Data (optional); Optional Offer DelivTo); Order, Trading Role Data (optional);
Response Signature, Optional Payment Receipt Signature Optional Offer Response Signature, Optional
(from Payment Exchange) Payment Receipt Signature (from Payment Exchange)
4. Delivery Handler checks information and authorisation. 4. Delivery Handler checks information and
Starts or schedules delivery and creates and then authorisation. Starts or schedules delivery and
sends a delivery not tot the Consumer which can creates and then sends a delivery not tot the
optionally be signed. Consumer which can optionally be signed.
C <-------- D DELIVERY RESPONSE. Components: Status; Delivery Note, C <-------- D DELIVERY RESPONSE. Components: Status; Delivery
Trading Role Data (optional); Optional Delivery Note, Trading Role Data (optional); Optional
Response Signature Delivery Response Signature
5. Consumer checks delivery note is OK and accepts or 5. Consumer checks delivery note is OK and accepts or
waits for delivery as described in the the Delivery waits for delivery as described in the the Delivery
Note. Note.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 4 Delivery Exchange Figure 4 Delivery Exchange
A Delivery Exchange uses the following Trading Components that are passed A Delivery Exchange uses the following Trading Components that are
between the Consumer, the Merchant and the Delivery Handler: passed between the Consumer, the Merchant and the Delivery Handler:
o the Status component is used to indicate to the Delivery Handler that o the Status component is used to indicate to the Delivery Handler
an earlier exchange (e.g. an Offer Exchange or Payment Exchange) has that an earlier exchange (e.g., an Offer Exchange or Payment
successfully completed and by the Delivery Handler to indicate the Exchange) has successfully completed and by the Delivery Handler
completion status of the Delivery Exchange. to indicate the completion status of the Delivery Exchange.
o The Organisation Component(s) contain details of the Deliver To, o The Organisation Component(s) contain details of the Deliver To,
Delivery Handler and Merchant Roles: 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 - the Deliver To role indicates where the goods or services are
to be delivered to be delivered to
o The Delivery Component contains information about how delivery will - the Delivery Handler role is required so that the Delivery
occur, for example by post or using e-mail. Handler can check that she is the correct Delivery Handler to
do the delivery
o The "Offer Response" Signature Component, if present, digitally signs - the Merchant role is required so that the Delivery Handler can
all of the above components to ensure their integrity. identify which Merchant initiated the delivery
o The "Payment Receipt" Signature Component provides proof of payment by o The Order Component, contains information about the goods or
digitally signing the Payment Receipt Component and the Offer services to be delivered
Signature. This is used by the Delivery Handler to check that delivery
is authorised
o The Delivery Note Component contains customer care information related o The Delivery Component contains information about how delivery
to a physical delivery, or alternatively the actual "electronic goods". will occur, for example by post or using e-mail.
The Consumer's software does not interpret information about a physical
delivery but should have the ability to display the information, both
at the time of the delivery and later if the Consumer selects the Trade
to which this delivery relates from a transaction list
o The "Delivery Response" Signature Component, if present, provides proof o The "Offer Response" Signature Component, if present, digitally
of the results of the Delivery by digitally signing the Delivery Note signs all of the above components to ensure their integrity.
and any Offer Response or Payment Response signatures that the Delivery
Handler received. o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing the Payment Receipt Component and the
Offer Signature. This is used by the Delivery Handler to check
that delivery is authorised
o The Delivery Note Component contains customer care information
related to a physical delivery, or alternatively the actual
"electronic goods". The Consumer's software does not interpret
information about a physical delivery but should have the ability
to display the information, both at the time of the delivery and
later if the Consumer selects the Trade to which this delivery
relates from a transaction list
o The "Delivery Response" Signature Component, if present, provides
proof of the results of the Delivery by digitally signing the
Delivery Note and any Offer Response or Payment Response
signatures that the Delivery Handler received.
2.2.4 Authentication Exchange 2.2.4 Authentication Exchange
The goal of the Authentication Exchange is to allow one Organisation, for The goal of the Authentication Exchange is to allow one Organisation,
example a financial institution, to be able to check that another for example a financial institution, to be able to check that another
Organisation, for example a consumer, is who they appear to be. Organisation, for example a consumer, is who they appear to be.
An Authentication Exchange involves: An Authentication Exchange involves:
o an Authenticator - the Organisation which is requesting the o an Authenticator - the Organisation which is requesting the
authentication, and authentication, and
o an Authenticatee - the Organisation being authenticated. o an Authenticatee - the Organisation being authenticated.
This is illustrated in the diagram below. This is illustrated in the diagram below.
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1 Organisation 1
(Authenticatee) (Authenticatee)
| Organisation 2 | Organisation 2
| (Authenticator) | (Authenticator)
STEP | | STEP | |
1. First Organisation, e.g. a Consumer, takes an action (for 1. First Organisation, e.g., a Consumer, takes an action (for
example by pressing a button on an HTML page) which requires example by pressing a button on an HTML page) which
that the Organisation is authenticated requires that the Organisation is authenticated
1 --> 2 Need for Authentication (outside scope of IOTP) 1 --> 2 Need for Authentication (outside scope of IOTP)
2. The second Organisation generates an Authentication Request - 2. The second Organisation generates an Authentication
including challenge data, and a list of the algorithms that Request - including challenge data, and a list of the
may be used for the authentication - and/or a request for the algorithms that may be used for the authentication -
Organisation information then sends it to the first and/or a request for the Organisation information then
Organisation sends it to the first Organisation
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
Trading Role Information Request Request, Trading Role Information Request
3. The first Organisation optionally checks any signature 3. The first Organisation optionally checks any signature
associated with the Authentication Request then uses the associated with the Authentication Request then uses the
specified authentication algorithm to generate an specified authentication algorithm to generate an
Authentication Response which is sent back to the second Authentication Response which is sent back to the second
Organisation together with details of any Organisation Organisation together with details of any Organisation
information requested information requested
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Organisation(s) Response, Organisation(s)
4. The Authentication Response is checked against the challenge 4. The Authentication Response is checked against the
data to check that the first Organisation is who they appear challenge data to check that the first Organisation is
to be and the result recorded in a Status Component which is who they appear to be and the result recorded in a Status
then sent back to the first Organisation. Component which is then sent back to the first
Organisation.
1 <-- 2 AUTHENTICATION STATUS. Component: Status 1 <-- 2 AUTHENTICATION STATUS. Component: Status
5. The first Organisation then optionally checks the results 5. The first Organisation then optionally checks the results
indicated by the Status and any associated signature and indicated by the Status and any associated signature and
takes the appropriate action or stops. takes the appropriate action or stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 5 Authentication Exchange Figure 5 Authentication Exchange
An Authentication Exchange uses the following Trading Components that are An Authentication Exchange uses the following Trading Components that
passed between the two Organisations: are passed between the two Organisations:
o the Authentication Request Component that requests an Authentication o the Authentication Request Component that requests an
and indicates the authentication algorithm and optional challenge data Authentication and indicates the authentication algorithm and
to be used. optional challenge data to be used.
o A Trading Role Information Request Component that requests information o A Trading Role Information Request Component that requests
about an Organisation, for example a ship to address. information about an Organisation, for example a ship to address.
o The Authentication Response Component which contains the challenge o The Authentication Response Component which contains the challenge
response generated by the recipient of the Authentication Request response generated by the recipient of the Authentication Request
Component. Component.
o Organisation Components that contain the result of the Trading Role o Organisation Components that contain the result of the Trading
Information Request Role Information Request
o the Status Component which contains the results of the second party's o the Status Component which contains the results of the second
verification of the Authentication Response. party's verification of the Authentication Response.
2.3 Scope of Baseline IOTP 2.3 Scope of Baseline IOTP
This specification describes the IOTP Transactions which make up Baseline This specification describes the IOTP Transactions which make up
IOTP. As described in the preface, IOTP will evolve over time. This Baseline IOTP. As described in the preface, IOTP will evolve over
section defines the initial conformance criteria for implementations that time. This section defines the initial conformance criteria for
claim to "support IOTP." implementations that claim to "support IOTP."
The main determinant on the scope of an IOTP implementation is the roles The main determinant on the scope of an IOTP implementation is the
which the solution is designed to support. The roles within IOTP are roles which the solution is designed to support. The roles within
described in more detail in section 2.1 Trading Roles. To summarise the IOTP are described in more detail in section 2.1 Trading Roles. To
roles are: Merchant, Consumer, Payment Handler, Delivery Handler and summarise the roles are: Merchant, Consumer, Payment Handler,
Customer Care Provider. Delivery Handler and Customer Care Provider.
Payment Handlers who can be of three types: Payment Handlers who can be of three types:
o those who accept a payment as part of a purchase or make a payment as o those who accept a payment as part of a purchase or make a payment
part of a refund, as part of a refund,
o those who accept value as part of a deposit transaction, or o those who accept value as part of a deposit transaction, or
o those that issue value a withdrawal transaction o those that issue value a withdrawal transaction
The following table defines, for each role, the IOTP Transactions and The following table defines, for each role, the IOTP Transactions and
Trading Blocks which must be supported for that role. Trading Blocks which must be supported for that role.
Merchants Merchants
ECash ECash ECash ECash
Store Value Value Consumer Payment Delivery Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler Issuer Acquirer Handler Handler
TRANSACTIONS TRANSACTIONS
Purchase Must Must Purchase Must Must
Merchants
ECash ECash Merchants
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Refund Must b) ECash ECash
Depends Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Authentication May Must May b) Refund Must b)
Depends Depends
Value Exchange May Must Authentication May Must May b)
Depends
Withdrawal Must b) Value Exchange May Must
Depends
Deposit Must b) Withdrawal Must b)
Depends Depends
Inquiry Must Must Must May Must Must Deposit Must b)
Depends
Ping Must Must Must May Must Must Inquiry Must Must Must May Must Must
TRADING BLOCKS Ping Must Must Must May Must Must
TPO Must Must Must Must TRADING BLOCKS
TPO Selection Must Must Must Must TPO Must Must Must Must
Auth-Request a) a) a) TPO Selection Must Must Must Must
Depends Depends Depends
Auth-Reply a) a) a) Auth-Request a) a) a)
Depends Depends Depends Depends Depends Depends
Offer Response Must Must Must Must Auth-Reply a) a) a)
Depends Depends Depends
Payment Must Must Offer Response Must Must Must Must
Request Payment Must Must
Request
Payment Must Must Payment Must Must
Exchange Exchange
Payment Must Must Payment Must Must
Response Response
Delivery Must Must Delivery Must Must
Request Request
Delivery Must Must Delivery Must Must
Response Response
Merchants
ECash ECash Merchants
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Inquiry Must Must Must Must Must Must ECash ECash
Request Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Response Request
Ping Request Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Response
Ping Response Must Must Must Must Must Must Ping Request Must Must Must Must Must Must
Signature Must Must Must Limited Must Must Ping Response Must Must Must Must Must Must
Error Must Must Must Must Must Must Signature Must Must Must Limited Must Must
In the above table: Error Must Must Must Must Must Must
o "Must" means that a Trading Role must support the Transaction or In the above table:
Trading Block.
o "May" means that an implementation may support the Transaction or o "Must" means that a Trading Role must support the Transaction or
Trading Block at the option of the developer. Trading Block.
o "Depends" means implementation of the Transaction or Trading Block o "May" means that an implementation may support the Transaction or
depends on one of the following conditions: Trading Block at the option of the developer.
- 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 o "Depends" means implementation of the Transaction or Trading Block
manipulated but not in every respect. Specifically, on the Signature depends on one of the following conditions:
Block, Consumers do not have to be able to validate digital signatures.
An IOTP solution must support all the IOTP Transactions and Trading - if Baseline Authentication IOTP Transaction is supported;
Blocks required by at least one role (column) as described in the above - if required by a Payment Method as defined in its IOTP
table for that solution to be described as "supporting 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 3. Protocol Structure
The previous section provided an introduction which explained: The previous section provided an introduction which explained:
o Trading Roles which are the different roles which Organisations can o Trading Roles which are the different roles which Organisations
take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler can take in a trade: Consumer, Merchant, Payment Handler, Delivery
and Customer Care Provider, and Handler and Customer Care Provider, and
o Trading Exchanges where each Trading Exchange involves the exchange of o Trading Exchanges where each Trading Exchange involves the
data, between Trading Roles, in the form of a set of Trading exchange of data, between Trading Roles, in the form of a set of
Components. Trading Components.
This section describes: This section describes:
o how Trading Components are constructed into Trading Blocks and the IOTP o how Trading Components are constructed into Trading Blocks and the
Messages which are physically sent in the form of [XML] documents IOTP Messages which are physically sent in the form of [XML]
between the different Trading Roles, documents between the different Trading Roles,
o how IOTP Messages are exchanged between Trading Roles to create an IOTP o how IOTP Messages are exchanged between Trading Roles to create an
Transaction IOTP Transaction
o the XML definitions of an IOTP Message including a Transaction o the XML definitions of an IOTP Message including a Transaction
Reference Block - an XML element which identifies an IOTP Transaction Reference Block - an XML element which identifies an IOTP
and the IOTP Message within it Transaction and the IOTP Message within it
o the definitions of the XML ID Attributes which are used to identify o the definitions of the XML ID Attributes which are used to
IOTP Messages, Trading Blocks and Trading Components and how these are identify IOTP Messages, Trading Blocks and Trading Components and
referred to using Element References from other XML elements how these are referred to using Element References from other XML
elements
o how extra XML Elements and new user defined values for existing IOTP o how extra XML Elements and new user defined values for existing
codes can be used when Extending IOTP, IOTP codes can be used when Extending IOTP,
o how IOTP uses the Packaged Content Element to embed data such as o how IOTP uses the Packaged Content Element to embed data such as
payment protocol messages or detailed order definitions within an IOTP payment protocol messages or detailed order definitions within an
Message IOTP Message
o how IOTP Identifies Languages so that different languages can be used o how IOTP Identifies Languages so that different languages can be
within IOTP Messages used within IOTP Messages
o how IOTP handles both Secure and Insecure Net Locations when sending o how IOTP handles both Secure and Insecure Net Locations when
messages sending messages
o how an IOTP Transaction can be cancelled. o how an IOTP Transaction can be cancelled.
3.1 Overview 3.1 Overview
3.1.1 IOTP Message Structure 3.1.1 IOTP Message Structure
The structure of an IOTP Message and its relationship with Trading Blocks The structure of an IOTP Message and its relationship with Trading
and Trading Components is illustrated in the diagram below. Blocks and Trading Components is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <---------- IOTP Message - an XML Document which is IOTP MESSAGE <---------- IOTP Message - an XML Document which is
| transported between the Trading Roles | transported between the Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains information which |-Trans Ref Block <----- Trans Ref Block - contains information which
| | describes the IOTP Transaction and the IOTP | | describes the IOTP Transaction and the IOTP
| | Message. | | Message.
| |-Trans Id Comp. <--- Transaction Id Component - uniquely | |-Trans Id Comp. <--- Transaction Id Component - uniquely
| | identifies the IOTP Transaction. The Trans Id | | identifies the IOTP Transaction. The Trans Id
| | Components are the same across all IOTP | | Components are the same across all IOTP
| | messages that comprise a single IOTP | | messages that comprise a single IOTP
| | transaction. | | transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies and | |-Msg Id Comp. <----- Message Id Component - identifies and
| describes an IOTP Message within an IOTP | describes an IOTP Message within an IOTP
| Transaction | Transaction
|-Signature Block <----- Signature Block (optional) - contains one or |-Signature Block <----- Signature Block (optional) - contains one or
| | more Signature Components and their | | more Signature Components and their
| | associated Certificates | | associated Certificates
| |-Signature Comp. <-- Signature Component - contains digital | |-Signature Comp. <-- Signature Component - contains digital
| | signatures. Signatures may sign digests of | | signatures. Signatures may sign digests of
| | the Trans Ref Block and any Trading Component | | the Trans Ref Block and any Trading Component
| | in any IOTP Message in the same IOTP | | in any IOTP Message in the same IOTP
| | transaction. | | transaction.
| |-Certificate Comp. < Certificate Component (Optional) Used to check | |-Certificate Comp. < Certificate Component (Optional) Used to check
| the signature. | the signature.
|-Trading Block <------- Trading Block - an XML Element within an IOTP |-Trading Block <------- Trading Block - an XML Element within an IOTP
| |-Trading Comp. Message that contains a predefined set of | |-Trading Comp. Message that contains a predefined set of
| |-Trading Comp. Trading Components | |-Trading Comp. Trading Components
| |-Trading Comp. | |-Trading Comp.
| |-Trading Comp. <--- Trading Components - XML Elements within a | |-Trading Comp. <--- Trading Components - XML Elements within a
| Trading Block that contain a predefined set | Trading Block that contain a predefined set
|-Trading Block of XML elements and attributes containing |-Trading Block of XML elements and attributes containing
| |-Trading Comp. information required to support a Trading | |-Trading Comp. information required to support a Trading
| |-Trading Comp. Exchange | |-Trading Comp. Exchange
| |-Trading Comp. | |-Trading Comp.
| |-Trading Comp. | |-Trading Comp.
| |-Trading Comp. | |-Trading Comp.
*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 6 IOTP Message Structure Figure 6 IOTP Message Structure
The diagram also introduces the concept of a Transaction Reference Block. The diagram also introduces the concept of a Transaction Reference
This block contains, amongst other things, a globally unique identifier Block. This block contains, amongst other things, a globally unique
for the IOTP Transaction. Also each block and component is given an ID identifier for the IOTP Transaction. Also each block and component is
Attribute (see section 3.4) which is unique within an IOTP Transaction. given an ID Attribute (see section 3.4) which is unique within an
Therefore the combination of the ID attribute and the globally unique IOTP Transaction. Therefore the combination of the ID attribute and
identifier in the Transaction Reference Block is sufficient to uniquely the globally unique identifier in the Transaction Reference Block is
identify any Trading Block or Trading Component. sufficient to uniquely identify any Trading Block or Trading
Component.
3.1.2 IOTP Transactions 3.1.2 IOTP Transactions
A predefined set of IOTP Messages exchanged between the Trading Roles A predefined set of IOTP Messages exchanged between the Trading Roles
constitute an IOTP Transaction. This is illustrated in the diagram below. constitute an IOTP Transaction. This is illustrated in the diagram
below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER MERCHANT CONSUMER MERCHANT
Generate first Generate first
IOTP Message IOTP Message
--- | --- |
| | v | | v
Process incoming | I | ------------- Process incoming | I | -------------
IOTP Message & <------------- | | ------------ | IOTP Message | IOTP Message & <------------- | | ------------ | IOTP Message |
generate next IOTP | | ------------- generate next IOTP | | -------------
Message | N | Message | N |
| | | | | |
v | | v | |
------------- | T | Process incoming ------------- | T | Process incoming
| IOTP Message | -------------- | | -----------> IOTP Message & | IOTP Message | -------------- | | -----------> IOTP Message &
------------- | | generate next ------------- | | generate next
| E | IOTP Message | E | IOTP Message
| | | | | |
| | v | | v
Process incoming | R | ------------- Process incoming | R | -------------
IOTP Message <------------- | | ------------ | IOTP Message | IOTP Message <------------- | | ------------ | IOTP Message |
generate last IOTP | | ------------- generate last IOTP | | -------------
Message & stop | N | Message & stop | N |
| | | | | |
v | | v | |
------------- | E | Process last ------------- | E | Process last
| IOTP Message | -------------- | | -------------> incoming IOTP | IOTP Message | -------------- | | -------------> incoming IOTP
------------- | | Message & stop ------------- | | Message & stop
| | T | | | | T | |
v | | v v | | v
STOP --- STOP STOP --- STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 7 An IOTP Transaction Figure 7 An IOTP Transaction
In the above diagram the Internet is shown as the transport mechanism. In the above diagram the Internet is shown as the transport
This is not necessarily the case. IOTP Messages can be transported using mechanism. This is not necessarily the case. IOTP Messages can be
a variety of transport mechanisms. transported using a variety of transport mechanisms.
The IOTP Transactions (see section 9) in this version of IOTP are The IOTP Transactions (see section 9) in this version of IOTP are
specifically: specifically:
o Purchase. This supports a purchase involving an offer, a payment and o Purchase. This supports a purchase involving an offer, a payment
optionally a delivery and optionally a delivery
o Refund. This supports the refund of a payment as a result of, o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase typically, an earlier purchase
o Value Exchange. This involves two payments which result in the exchange o Value Exchange. This involves two payments which result in the
of value from one combination of currency and payment method to another exchange of value from one combination of currency and payment
method to another
o Authentication. This supports the remote authentication of one Trading o Authentication. This supports the remote authentication of one
Role by another Trading Role using a variety of authentication Trading Role by another Trading Role using a variety of
algorithms, and the provision of an Organisation Information about the authentication algorithms, and the provision of an Organisation
Trading Role that is being authenticated for use in, for example, the Information about the Trading Role that is being authenticated for
creation of an offer use in, for example, the creation of an offer
o Withdrawal. This supports the withdrawal of electronic cash from a o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution financial institution
o Deposit. This supports the deposit of electronic cash at a financial o Deposit. This supports the deposit of electronic cash at a
institution financial institution
o Inquiry This supports inquiries on the status of an IOTP transaction o Inquiry This supports inquiries on the status of an IOTP
which is either in progress or is complete transaction which is either in progress or is complete
o Ping This supports a simple query which enables one IOTP aware o Ping This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running application to determine whether another IOTP application running
elsewhere is working or not. elsewhere is working or not.
3.2 IOTP Message 3.2 IOTP Message
As described earlier, IOTP Messages are [XML] documents which are As described earlier, IOTP Messages are [XML] documents which are
physically sent between the different Trading Roles that are taking part physically sent between the different Trading Roles that are taking
in a trade. part in a trade.
The XML definition of an IOTP Message is as follows. The XML definition of an IOTP Message is as follows.
<!ELEMENT IotpMessage <!ELEMENT IotpMessage
( TransRefBlk, ( TransRefBlk,
SigBlk?, SigBlk?,
ErrorBlk?, ErrorBlk?,
( AuthReqBlk | ( AuthReqBlk |
AuthRespBlk | AuthRespBlk |
AuthStatusBlk | AuthStatusBlk |
CancelBlk | CancelBlk |
DeliveryReqBlk | DeliveryReqBlk |
DeliveryRespBlk | DeliveryRespBlk |
InquiryReqBlk | InquiryReqBlk |
InquiryRespBlk | InquiryRespBlk |
OfferRespBlk | OfferRespBlk |
PayExchBlk | PayExchBlk |
PayReqBlk | PayReqBlk |
PayRespBlk | PayRespBlk |
PingReqBlk | PingReqBlk |
PingRespBlk | PingRespBlk |
TpoBlk | TpoBlk |
TpoSelectionBlk TpoSelectionBlk
)* )*
) > ) >
<!ATTLIST IotpMessage <!ATTLIST IotpMessage
xmlns CDATA xmlns CDATA
'iotp:ietf.org/draft-ietf-trade-iotp-v1.0-protocol-07' > 'iotp:ietf.org/iotp-v1.0'
Content: Content:
TransRefBlk This contains information which describes an IOTP TransRefBlk This contains information which describes an IOTP
Message within an IOTP Transaction (see section Message within an IOTP Transaction (see section
3.3 immediately below) 3.3 immediately below)
AuthReqBlk, These are the Trading Blocks. AuthReqBlk, These are the Trading Blocks.
AuthRespBlk, AuthRespBlk,
DeliveryReqBlk, The Trading Blocks present within an IOTP Message, DeliveryReqBlk, The Trading Blocks present within an IOTP Message,
DeliveryRespBlk and the content of a Trading Block itself is DeliveryRespBlk and the content of a Trading Block itself is
ErrorBlk dependent on the type of IOTP Transaction being ErrorBlk dependent on the type of IOTP Transaction being
InquiryReqBlk, carried out - see the definition of each InquiryReqBlk, carried out - see the definition of each
InquiryRespBlk, transaction in section 9 Internet Open Trading InquiryRespBlk, transaction in section 9 Internet Open Trading
OfferRespBlk, Protocol Transactions. OfferRespBlk, Protocol Transactions.
PayExchBlk, PayExchBlk,
PayReqBlk, Full definitions of each Trading Block are PayReqBlk, Full definitions of each Trading Block are
PayRespBlk, described in section 8. PayRespBlk, described in section 8.
PingReqBlk, PingReqBlk,
PingRespBlk, PingRespBlk,
SigBlk, SigBlk,
TpoBlk, TpoBlk,
TpoSelectionBlk TpoSelectionBlk
Attributes: Attributes:
xmlns The [XML Namespace] definition for IOTP messages. xmlns The [XML Namespace] definition for IOTP messages.
3.2.1 XML Document Prolog 3.2.1 XML Document Prolog
The IOTP Message is the root element of the XML document. It therefore The IOTP Message is the root element of the XML document. It
needs to be preceded by an appropriate XML Document Prolog. For example: therefore needs to be preceded by an appropriate XML Document Prolog.
For example:
<?XML Version='1.0'?> <?XML Version='1.0'?>
<!DOCTYPE IotpMessage > <!DOCTYPE IotpMessage >
<IotpMessage> <IotpMessage>
... ...
</IotpMessage> </IotpMessage>
3.3 Transaction Reference Block 3.3 Transaction Reference Block
A Transaction Reference Block contains information which identifies the A Transaction Reference Block contains information which identifies
IOTP Transaction and IOTP Message. The Transaction Reference Block the IOTP Transaction and IOTP Message. The Transaction Reference
contains: Block contains:
o a Transaction Id Component which globally uniquely identifies the IOTP o a Transaction Id Component which globally uniquely identifies the
Transaction. The Transaction Id Components are the same across all IOTP IOTP Transaction. The Transaction Id Components are the same
messages that comprise a single IOTP transaction, across all IOTP messages that comprise a single IOTP transaction,
o a Message Id Component which provides control information about the o a Message Id Component which provides control information about
IOTP Message as well as uniquely identifying the IOTP Message within an the IOTP Message as well as uniquely identifying the IOTP Message
IOTP Transaction, and within an IOTP Transaction, and
o zero or more Related To Components which link this IOTP Transaction to o zero or more Related To Components which link this IOTP
either other IOTP Transactions or other events using the identifiers of Transaction to either other IOTP Transactions or other events
those events. using the identifiers of those events.
The definition of a Transaction Reference Block is as follows: The definition of a Transaction Reference Block is as follows:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk <!ATTLIST TransRefBlk
ID ID #REQUIRED > ID ID #REQUIRED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Transaction Reference Block within the IOTP Transaction Reference Block within the IOTP
Transaction (see section 3.4 ID Attributes). Transaction (see section 3.4 ID Attributes).
Content: Content:
TransId See 3.3.1 Transaction Id Component immediately TransId See 3.3.1 Transaction Id Component immediately
below. below.
MsgId See 3.3.2 Message Id Component immediately below. MsgId See 3.3.2 Message Id Component immediately below.
RelatedTo See 3.3.3 Related To Component immediately below. RelatedTo See 3.3.3 Related To Component immediately below.
3.3.1 Transaction Id Component 3.3.1 Transaction Id Component
This contains information which globally uniquely identifies the IOTP This contains information which globally uniquely identifies the IOTP
Transaction. Its definition is as follows: Transaction. Its definition is as follows:
<!ELEMENT TransId EMPTY > <!ELEMENT TransId EMPTY >
<!ATTLIST TransId <!ATTLIST TransId
ID ID #REQUIRED ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0' Version NMTOKEN #FIXED '1.0'
IotpTransId CDATA #REQUIRED IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED > TransTimeStamp CDATA #REQUIRED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP Transaction Id Component within the IOTP
Transaction. Transaction.
Version This identifies the version of IOTP, and therefore Version This identifies the version of IOTP, and therefore
the structure of the IOTP Messages, which the IOTP the structure of the IOTP Messages, which the IOTP
Transaction is using. Transaction is using.
IotpTransId Contains data which uniquely identifies the IOTP IotpTransId Contains data which uniquely identifies the IOTP
Transaction. It must conform to the rules for Transaction. It must conform to the rules for
Message Ids in [RFC 822]. Message Ids in [RFC 822].
IotpTransTyp This is the type of IOTP Transaction being carried IotpTransTyp This is the type of IOTP Transaction being carried
out. For Baseline IOTP it identifies a "standard" out. For Baseline IOTP it identifies a "standard"
IOTP Transaction and implies the sequence and IOTP Transaction and implies the sequence and
content of the IOTP Messages exchanged between the content of the IOTP Messages exchanged between the
Trading Roles. The valid values for Baseline IOTP Trading Roles. The valid values for Baseline IOTP
are: are:
o BaselineAuthentication o BaselineAuthentication
o BaselineDeposit o BaselineDeposit
o BaselinePurchase o BaselinePurchase
o BaselineRefund o BaselineRefund
o BaselineWithdrawal o BaselineWithdrawal
o BaselineValueExchange o BaselineValueExchange
o BaselineInquiry o BaselineInquiry
o BaselinePing o BaselinePing
Values of IotpTransType are managed under the Values of IotpTransType are managed under the
procedure described in section 12 IANA procedure described in section 12 IANA
Considerations which also allows user defined Considerations which also allows user defined
values of IotpTransType to be defined. values of IotpTransType to be defined.
In later versions of IOTP, this list will be In later versions of IOTP, this list will be
extended to support different types of standard extended to support different types of standard
IOTP Transaction. It is also likely to support the IOTP Transaction. It is also likely to support the
type Dynamic which indicates that the sequence of type Dynamic which indicates that the sequence of
steps within the transaction are non-standard. steps within the transaction are non-standard.
TransTimeStamp Where the system initiating the IOTP Transaction TransTimeStamp Where the system initiating the IOTP Transaction
has an internal clock, it is set to the time at has an internal clock, it is set to the time at
which the IOTP Transaction started in [UTC] which the IOTP Transaction started in [UTC]
format. format.
The main purpose of this attribute is to provide The main purpose of this attribute is to provide
an alternative way of identifying a transaction by an alternative way of identifying a transaction by
specifying the time at which it started. specifying the time at which it started.
Some systems, for example, hand held devices may Some systems, for example, hand held devices may
not be able to generate a time stamp. In this not be able to generate a time stamp. In this
case this attribute should contain the value "NA" case this attribute should contain the value "NA"
for Not Available. for Not Available.
3.3.2 Message Id Component 3.3.2 Message Id Component
The Message Id Component provides control information about the IOTP The Message Id Component provides control information about the IOTP
Message as well as uniquely identifying the IOTP Message within an IOTP Message as well as uniquely identifying the IOTP Message within an
Transaction. Its definition is as follows. IOTP Transaction. Its definition is as follows.
<!ELEMENT MsgId EMPTY > <!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId <!ATTLIST MsgId
ID ID #REQUIRED ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED > TimeStamp CDATA #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
IOTP Message within the IOTP Transaction (see IOTP Message within the IOTP Transaction (see
section 3.4 ID Attributes). Note that if an section 3.4 ID Attributes). Note that if an
IOTP Message is resent then the value of this IOTP Message is resent then the value of this
attribute remains the same. attribute remains the same.
RespIotpMsg This contains the ID attribute of the Message RespIotpMsg This contains the ID attribute of the Message
Id Component of the IOTP Message to which this Id Component of the IOTP Message to which this
IOTP Message is a response. In this way all IOTP Message is a response. In this way all
the IOTP Messages in an IOTP Transaction are the IOTP Messages in an IOTP Transaction are
unambiguously linked together. This field is unambiguously linked together. This field is
required on every IOTP Message except the required on every IOTP Message except the
first IOTP Message in an IOTP Transaction. first IOTP Message in an IOTP Transaction.
SenderTradingRoleRef The Element Reference (see section 3.5) of the SenderTradingRoleRef The Element Reference (see section 3.5) of the
Trading Role which has generated the IOTP Trading Role which has generated the IOTP
message. It is used to identify the Net message. It is used to identify the Net
Locations (see section 3.9) of the Trading Locations (see section 3.9) of the Trading
Role to which problems Technical Errors (see Role to which problems Technical Errors (see
section 4.1) with any of Trading Blocks should section 4.1) with any of Trading Blocks should
be reported. be reported.
Xml:lang Defines the language used by attributes or Xml:lang Defines the language used by attributes or
child elements within this component, unless child elements within this component, unless
overridden by an xml:lang attribute on a child overridden by an xml:lang attribute on a child
element. See section 3.8 Identifying element. See section 3.8 Identifying
Languages. Languages.
LangPrefList Optional list of Language codes that conform LangPrefList Optional list of Language codes that conform
to [XML] Language Identification. It is used to [XML] Language Identification. It is used
by the sender to indicate, in preference by the sender to indicate, in preference
sequence, the languages that the receiver of sequence, the languages that the receiver of
the message ideally should use when generating the message ideally should use when generating
a response. There is no obligation on the a response. There is no obligation on the
receiver to respond using one of the indicated receiver to respond using one of the indicated
languages, but using one of the languages is languages, but using one of the languages is
likely to provide an improved user experience. likely to provide an improved user experience.
CharSetPrefList Optional list of Character Set identifiers CharSetPrefList Optional list of Character Set identifiers
that conform to [XML] Characters. It is used that conform to [XML] Characters. It is used
by the sender to indicate, in preference by the sender to indicate, in preference
sequence, the character sets that the receiver sequence, the character sets that the receiver
of the message ideally should use when of the message ideally should use when
generating a response. There is no obligation generating a response. There is no obligation
on the receiver to respond using one of the on the receiver to respond using one of the
character sets indicated, but using one of the character sets indicated, but using one of the
character sets is likely to provide an character sets is likely to provide an
improved user experience. improved user experience.
SoftwareId This contains information which identifies the SoftwareId This contains information which identifies the
software which generated the IOTP Message. Its software which generated the IOTP Message. Its
purpose is to help resolve interoperability purpose is to help resolve interoperability
problems that might occur as a result of problems that might occur as a result of
incompatibilities between messages produced by incompatibilities between messages produced by
different software. It is a single text string different software. It is a single text string
in the language defined by xml:lang. It must in the language defined by xml:lang. It must
contain, as a minimum: 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 o the name of the software manufacturer
internal clock, it is set to the time at which o the name of the software
the IOTP Message was created in [UTC] format. 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 3.3.3 Related To Component
The Related To Component links IOTP Transactions to either other IOTP The Related To Component links IOTP Transactions to either other IOTP
Transactions or other events using the identifiers of those events. Its Transactions or other events using the identifiers of those events.
definition is as follows. Its definition is as follows.
<!ELEMENT RelatedTo (PackagedContent) > <!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo <!ATTLIST RelatedTo
ID ID #REQUIRED ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED > RelnKeyWords NMTOKENS #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Related To Component within the IOTP Transaction. Related To Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child xml:lang Defines the language used by attributes or child
elements within this component, unless overridden elements within this component, unless overridden
by an xml:lang attribute on a child element. See by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages. section 3.8 Identifying Languages.
RelationshipType Defines the type of the relationship. Valid values RelationshipType Defines the type of the relationship. Valid values
are: are:
o IotpTransaction. in which case the Packaged
Content Element contains an IotpTransId of
another IOTP Transaction
o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
Values of RelationshipType are controlled under o IotpTransaction. in which case the Packaged
the procedures defined in section 12 IANA Content Element contains an IotpTransId of
Considerations which also allows user defined another IOTP Transaction
values to be defined. o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
Relation The Relation attribute contains a phrase in the Values of RelationshipType are controlled under
language defined by xml:lang which describes the the procedures defined in section 12 IANA
nature of the relationship between the IOTP Considerations which also allows user defined
transaction that contains this component and values to be defined.
another IOTP Transaction or other event. The exact
words to be used are left to the implementers of
the IOTP software.
The purpose of the attribute is to provide the Relation The Relation attribute contains a phrase in the
Trading Roles involved in an IOTP Transaction with language defined by xml:lang which describes the
an explanation of the nature of the relationship nature of the relationship between the IOTP
between the transactions. transaction that contains this component and
another IOTP Transaction or other event. The exact
words to be used are left to the implementers of
the IOTP software.
Care should be taken that the words used to in the The purpose of the attribute is to provide the
Relation attribute indicate the "direction" of the Trading Roles involved in an IOTP Transaction with
relationship correctly. For example: one an explanation of the nature of the relationship
transaction might be a refund for another earlier between the transactions.
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 Care should be taken that the words used to in the
used to help identify similar relationships, for Relation attribute indicate the "direction" of the
example all refunds. It is anticipated that relationship correctly. For example: one
recommended keywords will be developed through transaction might be a refund for another earlier
examination of actual usage. In this version of transaction. In this case the transaction which is
the specification there are no specific a refund should contain in the Relation attribute
recommendations and the keywords used are at the words such as "refund for" rather than "refund to"
discretion of implementers. or just "refund".
Content: RelnKeyWords This attribute contains keywords which could be
used to help identify similar relationships, for
example all refunds. It is anticipated that
recommended keywords will be developed through
examination of actual usage. In this version of
the specification there are no specific
recommendations and the keywords used are at the
discretion of implementers.
PackagedContent The Packaged Content (see section 3.7) contains Content:
data which identifies the related transaction. Its
format varies depending on the value of the PackagedContent The Packaged Content (see section 3.7) contains
RelationshipType. data which identifies the related transaction. Its
format varies depending on the value of the
RelationshipType.
3.4 ID Attributes 3.4 ID Attributes
IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading
Blocks), Trading Components (including the Transaction Id Component and Blocks), Trading Components (including the Transaction Id Component
the Signature Component) and some of their child elements are each given and the Signature Component) and some of their child elements are
an XML "ID" attribute which is used to identify an instance of these XML each given an XML "ID" attribute which is used to identify an
elements. These identifiers are used so that one element can be instance of these XML elements. These identifiers are used so that
referenced by another. All these attributes are given the attribute name one element can be referenced by another. All these attributes are
ID. given the attribute name ID.
The values of each ID attribute are unique within an IOTP transaction 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 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 Transaction ID Component. Also, once the ID attribute of an element
been assigned a value it is never changed. This means that whenever an has been assigned a value it is never changed. This means that
element is copied, the value of the ID attribute remains the same. 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 As a result it is possible to use these IDs to refer to and locate
content of any IOTP Message, Block or Component from any other IOTP the content of any IOTP Message, Block or Component from any other
Message, Block or Component in the same IOTP Transaction using Element IOTP Message, Block or Component in the same IOTP Transaction using
References (see section 3.5). Element References (see section 3.5).
This section defines the rules for setting the values for the ID This section defines the rules for setting the values for the ID
attributes of IOTP Messages, Blocks and Components. attributes of IOTP Messages, Blocks and Components.
3.4.1 IOTP Message ID Attribute Definition 3.4.1 IOTP Message ID Attribute Definition
The ID attribute of the Message Id Component of an IOTP Message must be The ID attribute of the Message Id Component of an IOTP Message must
unique within an IOTP Transaction. It's definition is as follows: be unique within an IOTP Transaction. It's definition is as follows:
IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)* IotpMsgIdPrefix ::= NameChar (NameChar)*
IotpMsgIdSuffix ::= Digit (Digit)* IotpMsgIdSuffix ::= Digit (Digit)*
IotpMsgIdPrefix Apart from messages which contain: an Inquiry
Request Trading Block, an Inquiry Response Trading
Block, a Ping Request Trading Block or a Ping
Response Trading Block; then the same prefix is
used for all messages sent by the Merchant or
Consumer role as follows:
o "M" - Merchant
o "C" - Consumer
For messages which contain an Inquiry Request IotpMsgIdPrefix Apart from messages which contain: an Inquiry
Trading Block or a Ping Request Trading Block, the Request Trading Block, an Inquiry Response Trading
prefix is set to "I" for Inquiry. Block, a Ping Request Trading Block or a Ping
Response Trading Block; then the same prefix is
used for all messages sent by the Merchant or
Consumer role as follows:
For messages which contain an Inquiry Response o "M" - Merchant
Trading Block or a Ping Response Trading Block, o "C" - Consumer
the prefix is set to "Q".
The prefix for the other roles in a trade is For messages which contain an Inquiry Request
contained within the Organisation Component for Trading Block or a Ping Request Trading Block, the
the role and are typically set by the Merchant. prefix is set to "I" for Inquiry.
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
o "C" - Deliver To
As a guideline, prefixes should be limited to one For messages which contain an Inquiry Response
character. Trading Block or a Ping Response Trading Block,
the prefix is set to "Q".
NameChar has the same definition as the [XML] The prefix for the other roles in a trade is
definition of NameChar. 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:
IotpMsgIdSuffix The suffix consists of one or more digits. The o "P" - First (only) Payment Handler
suffix must be unique within a Trading Role within o "R" - Second Payment Handler
an IOTP Transaction. The following is recommended o "D" - Delivery Handler
as a guideline and must not be relied upon: o "C" - Deliver To
o the first IOTP Message sent by a trading role
is given the suffix "1"
o the second and subsequent IOTP Messages sent
by the same trading role are incremented by one
for each message
o no leading zeroes are included in the suffix
Put more simply the Message Id Component of the As a guideline, prefixes should be limited to one
first IOTP Message sent by a Consumer would have character.
an ID attribute of, "C1", the second "C2", the
third "C3" etc.
Digit has the same definition as the [XML] NameChar has the same definition as the [XML]
definition of Digit. definition of NameChar.
IotpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role within
an IOTP Transaction. The following is recommended
as a guideline and must not be relied upon:
o the first IOTP Message sent by a trading role
is given the suffix "1"
o the second and subsequent IOTP Messages sent
by the same trading role are incremented by one
for each message
o no leading zeroes are included in the suffix
Put more simply the Message Id Component of the
first IOTP Message sent by a Consumer would have
an ID attribute of, "C1", the second "C2", the
third "C3" etc.
Digit has the same definition as the [XML]
definition of Digit.
3.4.2 Block and Component ID Attribute Definitions 3.4.2 Block and Component ID Attribute Definitions
The ID Attribute of Blocks and Components must also be unique within an The ID Attribute of Blocks and Components must also be unique within
IOTP Transaction. Their definition is as follows: an IOTP Transaction. Their definition is as follows:
BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)* IdSuffix ::= Digit (Digit)*
IotpMsgId_value The ID attribute of the Message ID Component of IotpMsgId_value The ID attribute of the Message ID Component of
the IOTP Message where the Block or Component is the IOTP Message where the Block or Component is
first used. first used.
In IOTP, Trading Components and Trading Blocks are In IOTP, Trading Components and Trading Blocks are
copied from one IOTP Message to another. The ID copied from one IOTP Message to another. The ID
attribute does not change when an existing Trading attribute does not change when an existing Trading
Block or Component is copied to another IOTP Block or Component is copied to another IOTP
Message. Message.
IdSuffix The suffix consists of one or more digits. The IdSuffix The suffix consists of one or more digits. The
suffix must be unique within the ID attribute of suffix must be unique within the ID attribute of
the Message ID Component used to generate the ID the Message ID Component used to generate the ID
attribute. The following is recommended as a attribute. The following is recommended as a
guideline and must not be relied upon: 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 o the first Block or Component sent by a trading
added to the second IOTP Message sent, for role is given the suffix "1"
example, by a consumer would have a an ID o the ID attributes of the second and subsequent
attribute of "C2.1", the second "C2.2", the third Blocks or Components are incremented by one for
"C2.3" etc. each new Block or Component added to an IOTP
Message
o no leading zeroes are included in the suffix
Digit has the same definition as the [XML] Put more simply, the first new Block or Component
definition of Digit. 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.
3.4.3 Example of use of ID Attributes Digit has the same definition as the [XML]
definition of Digit.
The diagram below illustrates how ID attribute values are used. 3.4.3 Example of use of ID Attributes
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* The diagram below illustrates how ID attribute values are used.
1st IOTP MESSAGE 2nd IOTP MESSAGE *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
(e.g. from Merchant to (e.g. from Consumer to
Consumer Payment Handler)
IOTP MESSAGE IOTP MESSAGE * 1st IOTP MESSAGE 2nd IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* (e.g., from Merchant to (e.g., from Consumer to
| |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp. Consumer Payment Handler)
| | Copy Element | | ID=M1.2 IOTP MESSAGE IOTP MESSAGE *
| |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| | | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp.
|-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* | | Copy Element | | ID=M1.2
| |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 *
| Copy Element | | |
|-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 * |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5*
| |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4 | |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15
| | Copy Element | | Copy Element |
| |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5 |-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 *
| | Copy Element | | |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4
| |-Comp. ID=M1.6 |-Comp. ID=C1.3 * | | Copy Element |
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 * | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
| | | Copy Element |
|-Trading Block. ID=M1.9 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 *
|-Comp. ID=M1.10 * = new elements | |-Comp. ID=M1.7 |-Comp. ID=C1.4 *
|-Comp. ID=M1.11 |
|-Comp. ID=M1.12 |-Trading Block. ID=M1.9
|-Comp. ID=M1.13 |-Comp. ID=M1.10 * = new elements
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 8 Example use of ID attributes Figure 8 Example use of ID attributes
3.5 Element References 3.5 Element References
A Trading Component or one of its child XML elements, may contain an XML A Trading Component or one of its child XML elements, may contain an
attribute that refers to another Block (i.e. a Transaction Reference XML attribute that refers to another Block (i.e. a Transaction
Block or a Trading Block) or Trading Component (including a Transaction Reference Block or a Trading Block) or Trading Component (including a
Id and Signature Component). These Element References are used for many Transaction Id and Signature Component). These Element References are
purposes, a few examples include: used for many purposes, a few examples include:
o identifying an XML element whose Digest is included in a Signature o identifying an XML element whose Digest is included in a Signature
Component, Component,
o referring to the Payment Handler Organisation Component which is used o referring to the Payment Handler Organisation Component which is
when making a Payment used when making a Payment
An Element Reference always contains the value of an ID attribute of a An Element Reference always contains the value of an ID attribute of
Block or Component. a Block or Component.
Identifying the IOTP Message, Trading Block or Trading Component which is Identifying the IOTP Message, Trading Block or Trading Component
referred to by an Element Reference, involves finding the XML element which is referred to by an Element Reference, involves finding the
which: XML element which:
o belongs to the same IOTP Transaction (i.e. the Transaction Id o belongs to the same IOTP Transaction (i.e. the Transaction Id
Components of the IOTP Messages match), and Components of the IOTP Messages match), and
o where the value of the ID attribute of the element matches the value of o where the value of the ID attribute of the element matches the
the Element Reference. value of the Element Reference.
[Note] The term "match" in this specification has the same definition Note: The term "match" in this specification has the same definition
as the [XML] definition of match. as the [XML] definition of match.
[Note End]
An example of "matching" an Element Reference is illustrated in the An example of "matching" an Element Reference is illustrated in the
example below. example below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE 1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g. from Merchant to (e.g. from Consumer to (e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler) Consumer Payment Handler)
IOTP MESSAGE IOTP MESSAGE IOTP MESSAGE IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1
| |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2 | |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2
| | must be | | | | must be | |
| |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1
| ^ | | ^ |
|-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5 |-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5
| |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15
| AND | | AND |
|-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2
| |-Comp. ID=M1.4 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4
| | v | | | v |
| |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5
| | and El Ref | | | and El Ref |
| |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3
| | match--------|--> El Ref=M1.5 | | match--------|--> El Ref=M1.5
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 | |-Comp. ID=M1.7 |-Comp. ID=C1.4
| |
|-Trading Block. ID=M1.9 |-Trading Block. ID=M1.9
|-Comp. ID=M1.10 |-Comp. ID=M1.10
|-Comp. ID=M1.11 |-Comp. ID=M1.11
|-Comp. ID=M1.12 |-Comp. ID=M1.12
|-Comp. ID=M1.13 |-Comp. ID=M1.13
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 9 Element References Figure 9 Element References
[Note] Element Reference attributes are defined as "NMTOKEN" rather Note: Element Reference attributes are defined as "NMTOKEN" rather
than "IDREF" (see [XML]). This is because an IDREF requires than "IDREF" (see [XML]). This is because an IDREF requires that the
that the XML element referred to is in the same XML Document. XML element referred to is in the same XML Document. With IOTP this
With IOTP this is not necessarily the case. is not necessarily the case.
[Note End]
3.6 Extending IOTP 3.6 Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting IOTP Baseline IOTP defines a minimum protocol which systems supporting
must be able to accept. As new versions of IOTP are developed, additional IOTP must be able to accept. As new versions of IOTP are developed,
types of IOTP Transactions will be defined. In addition to this, Baseline additional types of IOTP Transactions will be defined. In addition to
and future versions of IOTP will support user extensions to IOTP through this, Baseline and future versions of IOTP will support user
two mechanisms: extensions to IOTP through two mechanisms:
o extra XML elements, and o extra XML elements, and
o new values for existing IOTP codes. o new values for existing IOTP codes.
3.6.1 Extra XML Elements 3.6.1 Extra XML Elements
The XML element and attribute names used within IOTP constitute an [XML The XML element and attribute names used within IOTP constitute an
Namespace] as identified by the xmlns attribute on the IotpMessage [XML Namespace] as identified by the xmlns attribute on the
element. This allows IOTP to support the inclusion of additional XML IotpMessage element. This allows IOTP to support the inclusion of
elements within IOTP messages through the use of [XML Namespaces]. additional XML elements within IOTP messages through the use of [XML
Namespaces].
Using XML Namespaces, extra XML elements may be included at any level Using XML Namespaces, extra XML elements may be included at any level
within an IOTP message including: within an IOTP message including:
o new Trading Blocks o new Trading Blocks
o new Trading Components o new Trading Components
o new XML elements within a Trading Component. o new XML elements within a Trading Component.
The following rules apply: The following rules apply:
o any new XML element must be declared according to the rules for [XML o any new XML element must be declared according to the rules for
Namespaces] [XML Namespaces]
o new XML elements which are either Trading Blocks or Trading Components o new XML elements which are either Trading Blocks or Trading
must contain an ID attributes with an attribute name of ID. 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, In order to make sure that extra XML elements can be processed
IOTP reserves the use of a special attribute, IOTP:Critical, which takes properly, IOTP reserves the use of a special attribute,
the values True or False and may appear in extra elements added to an IOTP:Critical, which takes the values True or False and may appear in
IOTP message. extra elements added to an IOTP message.
The purpose of this attribute is to allow an IOTP aware application to The purpose of this attribute is to allow an IOTP aware application
determine if the IOTP transaction can safely continue. Specifically: to determine if the IOTP transaction can safely continue.
Specifically:
o if an extra XML element has an "IOTP:Critical" attribute with a value o if an extra XML element has an "IOTP:Critical" attribute with a
of "True" and an IOTP aware application does not know how to process value of "True" and an IOTP aware application does not know how to
the element and its child elements, then the IOTP transaction has a process the element and its child elements, then the IOTP
Technical Error (see section 4.1) and must fail. transaction has a Technical Error (see section 4.1) and must fail.
o if an extra XML element has an "IOTP:Critical" attribute with a value o if an extra XML element has an "IOTP:Critical" attribute with a
of "False" then the IOTP transaction may continue if the IOTP aware value of "False" then the IOTP transaction may continue if the
application does not know how to process it. In this case: IOTP aware application does not know how to process it. In this
- any extra XML elements contained within an XML element defined within case:
the IOTP namespace, must be included with that element whenever the
IOTP XML element is used or copied by IOTP
- the content of the extra element must be ignored except that it must
be included when it is used in the creation of a digest as part of
the generation of a signature
o if an extra XML element has no "IOTP:Critical" attribute then it must - any extra XML elements contained within an XML element defined
be treated as if it had an "IOTP:Critical" attribute with a value of within the IOTP namespace, must be included with that element
"True" whenever the IOTP XML element is used or copied by IOTP
o if an XML element contains an "IOTP:Critical" attribute, then the value - the content of the extra element must be ignored except that it
of that attribute is assumed to apply to all the child elements within must be included when it is used in the creation of a digest as
that element part of the generation of a signature
In order to ensure that documents containing "IOTP:Critical" are valid, o if an extra XML element has no "IOTP:Critical" attribute then it
it is declared as part of the DTD for the extra element as: must be treated as if it had an "IOTP:Critical" attribute with a
value of "True"
IOTP:Critical (True | False ) 'True' o if an XML element contains an "IOTP:Critical" attribute, then the
value of that attribute is assumed to apply to all the child
elements within that element
In order to ensure that documents containing "IOTP:Critical" are
valid, it is declared as part of the DTD for the extra element as:
IOTP:Critical (True | False ) 'True'
3.6.2 Opaque Embedded Data 3.6.2 Opaque Embedded Data
If IOTP is to be extended using Opaque Embedded Data then a Packaged If IOTP is to be extended using Opaque Embedded Data then a Packaged
Content Element (see section 3.7) should be used to encapsulate the data. Content Element (see section 3.7) should be used to encapsulate the
data.
3.7 Packaged Content Element 3.7 Packaged Content Element
The Packaged Content element supports the concept of an embedded data The Packaged Content element supports the concept of an embedded data
stream, transformed to both protect it against misinterpretation by stream, transformed to both protect it against misinterpretation by
transporting systems and to ensure XML compatibility. Examples of its use transporting systems and to ensure XML compatibility. Examples of its
in IOTP include: use in IOTP include:
o to encapsulate payment scheme messages, such as SET messages, o to encapsulate payment scheme messages, such as SET messages,
o to encapsulate a description of an order, a payment note, or a delivery o to encapsulate a description of an order, a payment note, or a
note. delivery note.
In general it is used to encapsulate one or more data streams. In general it is used to encapsulate one or more data streams.
This data stream has three standardised attributes that allow for This data stream has three standardised attributes that allow for
identification, decoding and interpretation of the contents. Its identification, decoding and interpretation of the contents. Its
definition is as follows. definition is as follows.
<!ELEMENT PackagedContent (#PCDATA) > <!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent <!ATTLIST PackagedContent
Name CDATA #IMPLIED Name CDATA #IMPLIED
Content NMTOKEN "PCDATA" Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" > Transform (NONE|BASE64) "NONE" >
Attributes: Attributes:
Name Optional. Distinguishes between multiple Name Optional. Distinguishes between multiple
occurrences of Packaged Content Elements at the occurrences of Packaged Content Elements at the
same point in IOTP. For example: same point in IOTP. For example:
<ABCD> <ABCD>
<PackagedContent Name='FirstPiece'> <PackagedContent Name='FirstPiece'>
snroasdfnas934k snroasdfnas934k
</PackagedContent> </PackagedContent>
<PackagedContent Name='SecondPiece'> <PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45 dvdsjnl5poidsdsflkjnw45
</PackagedContent> </PackagedContent>
</ABCD> </ABCD>
The name attribute may be omitted, for example if The name attribute may be omitted, for example if
there is only one Packaged Content element. there is only one Packaged Content element.
Content This identifies what type of data is contained Content This identifies what type of data is contained
within the Content of the Packaged Content within the Content of the Packaged Content
Element. The valid values for the Content Element. The valid values for the Content
attribute are as follows: attribute are as follows:
o PCDATA. The content of the Packaged Content o PCDATA. The content of the Packaged Content
Element can be treated as PCDATA with no Element can be treated as PCDATA with no
further processing. further processing.
o MIME. The content of the Packaged Content o MIME. The content of the Packaged Content
Element is a complete MIME item. Processing Element is a complete MIME item. Processing
should include looking for MIME headers inside should include looking for MIME headers inside
the Packaged Content Element. the Packaged Content Element.
o MIME:mimetype. The content of the Packaged o MIME:mimetype. The content of the Packaged
Content Element is MIME content, with the Content Element is MIME content, with the
following header "Content-Type: mimetype". following header "Content-Type: mimetype".
Although it is possible to have MIME:mimetype Although it is possible to have MIME:mimetype
with the Transform attribute set to NONE, it is with the Transform attribute set to NONE, it is
far more likely to have Transform attribute set far more likely to have Transform attribute set
to BASE64. Note that if Transform is NONE is to BASE64. Note that if Transform is NONE is
used, then the entire content must still used, then the entire content must still
conform to PCDATA. Some characters will need to conform to PCDATA. Some characters will need to
be encoded either as the XML default entities, be encoded either as the XML default entities,
or as numeric character 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 BASE64, must be used to ensure that the
Packaged Content Element contents are
legitimate PCDATA.
Values of the Content attribute are controlled o XML. The content of the Packaged Content
under the procedures defined in section 12 IANA Element can be treated as an XML document.
Considerations which also allows user defined Entities and CDATA sections, or Transform set
values to be defined. to BASE64, must be used to ensure that the
Packaged Content Element contents are
legitimate PCDATA.
Transform This identifies the transformation that has been Values of the Content attribute are controlled
done to the data before it was placed in the under the procedures defined in section 12 IANA
content. Valid values are: Considerations which also allows user defined
values to be defined.
o NONE. The PCDATA content of the Packaged Transform This identifies the transformation that has been
Content Element is the correct representation done to the data before it was placed in the
of the data. Note that entity expansion must content. Valid values are:
occur first (i.e. replacement of &amp; and
&#9;) 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: 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 &amp; and
&#9;) 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.
PCDATA This is the actual data which has been embedded. Content:
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 PCDATA This is the actual data which has been embedded.
represented at a higher level. The format of the data and rules on how to decode
it are contained in the Content and the Transform
attributes
Note that any special details, especially custom attributes, must be
represented at a higher level.
3.7.1 Packaging HTML 3.7.1 Packaging HTML
The packaged content may contain HTML. In this case the following The packaged content may contain HTML. In this case the following
conventions are followed: conventions are followed:
o references to any documents, images or other things, such as sounds or o references to any documents, images or other things, such as
web pages, which can affect the recipient's understanding of the data sounds or web pages, which can affect the recipient's
which is being packaged must refer to other Packaged Elements contained understanding of the data which is being packaged must refer to
within the same parent element, e.g. an Order Description other Packaged Elements contained within the same parent element,
e.g., an Order Description
o if more than one Packaged Content element is included within a parent o if more than one Packaged Content element is included within a
element in order to meet the previous requirement, then the Name parent element in order to meet the previous requirement, then the
attribute of the top level Packaged Content from which references to Name attribute of the top level Packaged Content from which
all other Packaged Elements can be determined, should have a value of references to all other Packaged Elements can be determined,
Main should have a value of Main
o relative references to other documents, images, etc. from one Packaged o relative references to other documents, images, etc. from one
Content element to another are realised by setting the value of the Packaged Content element to another are realised by setting the
relative reference to the Name attribute of another Packaged Content value of the relative reference to the Name attribute of another
element at the same level and within the same parent element Packaged Content element at the same level and within the same
parent element
o no external references that require the reference to be resolved o no external references that require the reference to be resolved
immediately should be used. As this could make the HTML difficult or immediately should be used. As this could make the HTML difficult
impossible to display completely or impossible to display completely
o [MIME] is used to encapsulate the data inside each Packaged Element. o [MIME] is used to encapsulate the data inside each Packaged
This means that the information in the MIME header used to identify the Element. This means that the information in the MIME header used
type of data which has been encapsulated and therefore how it should be to identify the type of data which has been encapsulated and
displayed. therefore how it should be displayed.
If the above conventions are not followed by, for example, including If the above conventions are not followed by, for example, including
external references which must be resolved, then the recipient of the external references which must be resolved, then the recipient of the
HTML should be informed. HTML should be informed.
[Note] As an implementation guideline the values of the Name Note: As an implementation guideline the values of the Name
Attributes allocated to Packaged Content elements should make Attributes allocated to Packaged Content elements should make it
it possible to extract each Packaged Content into a directory possible to extract each Packaged Content into a directory and then
and then display the HTML directly display the HTML directly
[Note End]
3.7.2 Packaging XML 3.7.2 Packaging XML
Support for XML is recommended. When XML needs to be displayed, for Support for XML is recommended. When XML needs to be displayed, for
example to display the content of an Order Description to a Consumer, example to display the content of an Order Description to a Consumer,
then implementers should follow the latest recommendations of the World then implementers should follow the latest recommendations of the
Wide Web Consortium. World Wide Web Consortium.
[Note] At the time of writing this specification, standards are under Note: At the time of writing this specification, standards are under
development that specify XML style sheets that show how XML development that specify XML style sheets that show how XML documents
documents should be displayed. See: should be displayed. See:
o "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl, and
o "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet.
Once these standards become W3C "Recommendations", then it is o "Extensible Stylesheet Language (XSL) Specification" at
anticipated that this specification will be amended if http://www.w3.org/TR/WD-xsl, and
practical.
[Note End] o "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet.
Once these standards become W3C "Recommendations", then it is
anticipated that this specification will be amended if practical.
3.8 Identifying Languages 3.8 Identifying Languages
IOTP uses [XML] Language Identification to specify which languages are IOTP uses [XML] Language Identification to specify which languages
used within the content and attributes of IOTP Messages. are used within the content and attributes of IOTP Messages.
The following principles have been used in order to determine which XML The following principles have been used in order to determine which
elements contain an xml:lang Attributes: XML elements contain an xml:lang Attributes:
o a mandatory xml:lang attribute is contained on every Trading Component o a mandatory xml:lang attribute is contained on every Trading
which contains attributes or content which may need to be displayed or Component which contains attributes or content which may need to
printed in a particular language be displayed or printed in a particular language
o an optional xml:lang attribute is included on child elements of these o an optional xml:lang attribute is included on child elements of
Trading Components. In this case the value of xml:lang, if present, these Trading Components. In this case the value of xml:lang, if
overrides the value for the Trading Component. present, overrides the value for the Trading Component.
xml:lang attributes which follow these principles are included in the xml:lang attributes which follow these principles are included in the
Trading Components and their child XML elements defined in section 7. Trading Components and their child XML elements defined in section 7.
A sender of a message, typically a Consumer can indicate a preference for A sender of a message, typically a Consumer can indicate a preference
a language, and a character set by specifying a list of preferred for a language, and a character set by specifying a list of preferred
languages/character sets in a Message Id Component (see section 3.3.2). languages/character sets in a Message Id Component (see section
Note that there is no obligation on the receiver of such a message to 3.3.2). Note that there is no obligation on the receiver of such a
respond using one of the listed languages/character sets as they may not message to respond using one of the listed languages/character sets
have the technology to be able to do it. It also means that the ability as they may not have the technology to be able to do it. It also
to handle these lists is not a requirement for conformance to this means that the ability to handle these lists is not a requirement for
specification. However the ability to respond, for example using one of conformance to this specification. However the ability to respond,
the stated languages/character sets is likely to provide a better user for example using one of the stated languages/character sets is
experience. likely to provide a better user experience.
3.9 Secure and Insecure Net Locations 3.9 Secure and Insecure Net Locations
IOTP contains several "Net Locations" which identify places where, IOTP contains several "Net Locations" which identify places where,
typically, IOTP Messages may be sent. Net Locations come in two types: 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 o "Secure" Net Locations which are net locations where privacy of
secured using, for example, encryption methods such as [SSL/TLS], and data is secured using, for example, encryption methods such as
[SSL/TLS], and
o "Insecure" Net Locations where privacy of data is not assured. o "Insecure" Net Locations where privacy of data is not assured.
Note that either a Secure Net Location or an Insecure Net Location or Note that either a Secure Net Location or an Insecure Net Location or
both must be present. both must be present.
If only one of the two Net Locations is present, then the one present If only one of the two Net Locations is present, then the one present
must be used. must be used.
Where both types of net location are present then either may be used Where both types of net location are present then either may be used
depending on the preference of the sender of the message. depending on the preference of the sender of the message.
3.10 Cancelled Transactions 3.10 Cancelled Transactions
Any Trading Role involved in an IOTP transaction may cancel that Any Trading Role involved in an IOTP transaction may cancel that
transaction at any time. transaction at any time.
3.10.1 Cancelling Transactions 3.10.1 Cancelling Transactions
IOTP Transactions are cancelled by sending an IOTP message containing IOTP Transactions are cancelled by sending an IOTP message containing
just a Cancel Block with an appropriate Status Component to the other just a Cancel Block with an appropriate Status Component to the other
Trading Role involved in the Trading Exchange. Trading Role involved in the Trading Exchange.
[Note] The Cancel Block can be sent asynchronously of any other IOTP
Message. Specifically it can be sent either before sending or
after receiving an IOTP Message from the other Trading Role
[Note End]
If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the Note: The Cancel Block can be sent asynchronously of any other IOTP
interval between sending a "request" block and receiving the matching Message. Specifically it can be sent either before sending or after
"response" block) then the Cancel Block is sent to the same location as receiving an IOTP Message from the other Trading Role
the next IOTP Message in the Trading Exchange would have been sent.
If a Consumer cancels a transaction after a Trading Exchange has If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
completed (i.e. the "response" block for the Trading Exchange has been the interval between sending a "request" block and receiving the
received), but before the IOTP Transaction has finished then the Consumer matching "response" block) then the Cancel Block is sent to the same
sends a Cancel Block with an appropriate Status Component to the net location as the next IOTP Message in the Trading Exchange would have
location identified by the SenderNetLocn or SecureSenderNetLocn contained been sent.
in the Protocol Options Component (see section 7.1) contained in the TPO
Block (see section 8.1) for the transaction. This is normally the
Merchant Trading Role.
A Consumer should not send a Cancel Block after the IOTP Transaction has If a Consumer cancels a transaction after a Trading Exchange has
completed. Cancelling a complete transaction should be treated as a completed (i.e. the "response" block for the Trading Exchange has
technical error. been received), but before the IOTP Transaction has finished then the
Consumer sends a Cancel Block with an appropriate Status Component to
the net location identified by the SenderNetLocn or
SecureSenderNetLocn contained in the Protocol Options Component (see
section 7.1) contained in the TPO Block (see section 8.1) for the
transaction. This is normally the Merchant Trading Role.
After cancelling the IOTP Transaction, the Consumer should go to the net A Consumer should not send a Cancel Block after the IOTP Transaction
location specified by the CancelNetLocn attribute contained in the has completed. Cancelling a complete transaction should be treated as
Trading Role Element for the Organisation that was sent the Cancel Block. a technical error.
A non-Consumer Trading Role should only cancel a transaction: After cancelling the IOTP Transaction, the Consumer should go to the
net location specified by the CancelNetLocn attribute contained in
the Trading Role Element for the Organisation that was sent the
Cancel Block.
o after a request block has been received and A non-Consumer Trading Role should only cancel a transaction:
o before the response block has been sent o after a request block has been received and
o before the response block has been sent
If a non-Consumer Trading Role cancels a transaction at any other time it If a non-Consumer Trading Role cancels a transaction at any other
should be treated by the recipient as an error. time it should be treated by the recipient as an error.
3.10.2 Handling Cancelled Transactions 3.10.2 Handling Cancelled Transactions
If a Cancel Block is received by a Consumer at a point in the IOTP If a Cancel Block is received by a Consumer at a point in the IOTP
Transaction when cancellation is allowed, then the Consumer should stop Transaction when cancellation is allowed, then the Consumer should
the transaction. stop the transaction.
If a Cancel Block is received by a non-Consumer role, then the Trading If a Cancel Block is received by a non-Consumer role, then the
Role should anticipate that the Consumer may go to the location specified Trading Role should anticipate that the Consumer may go to the
by the CancelNetLocn attribute contained in the Trading Role Element for location specified by the CancelNetLocn attribute contained in the
the Trading Role. Trading Role Element for the Trading Role.
4. IOTP Error Handling 4. IOTP Error Handling
IOTP is designed as a request/response protocol where each message is 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 composed of a number of Trading Blocks which contain a number of
Components. There are several interrelated considerations in handling Trading Components. There are several interrelated considerations in
errors, re-transmissions, duplicates, and the like. These factors mean handling errors, re-transmissions, duplicates, and the like. These
IOTP aware applications must manage message flows more complex than the factors mean IOTP aware applications must manage message flows more
simple request/response model. Also a wide variety of errors can occur in complex than the simple request/response model. Also a wide variety
messages as well as at the transport level or in Trading Blocks or of errors can occur in messages as well as at the transport level or
Components. in Trading Blocks or Components.
This section describes at a high level how IOTP handles errors, retries This section describes at a high level how IOTP handles errors,
and idempotency. It covers: retries and idempotency. It covers:
o the different types of errors which can occur. This is divided into: o the different types of errors which can occur. This is divided
- "technical errors" which are independent of the purpose of the IOTP into:
Message,
- "business errors" which indicate that there is a problem specific to
the process (e.g. payment or delivery) which is being carried out,
and
o the depth of the error which indicates whether the error is at the - "technical errors" which are independent of the purpose of the
transport, message or block/component level IOTP Message,
o how the different trading roles should handle the different types of - "business errors" which indicate that there is a problem
messages which they may receive. specific to the process (e.g., payment or delivery) which is
being carried out, and
o the depth of the error which indicates whether the error is at the
transport, message or block/component level
o how the different trading roles should handle the different types
of messages which they may receive.
4.1 Technical Errors 4.1 Technical Errors
Technical Errors are those which are independent of the meaning of the Technical Errors are those which are independent of the meaning of
message. This means, they can affect any attempt at IOTP communication. the message. This means, they can affect any attempt at IOTP
Typically they are handled in a standard fashion with a limited number of communication. Typically they are handled in a standard fashion with
standard options for the user. Specifically these are: a limited number of standard options for the user. Specifically these
are:
o retrying the transmission, or o retrying the transmission, or
o cancelling the transaction. o cancelling the transaction.
When communications are operating sufficiently well, a technical error is When communications are operating sufficiently well, a technical
indicated by an Error Component (see section 7.21) in an Error Block (see error is indicated by an Error Component (see section 7.21) in an
section 8.17) sent by the party which detected the error in an IOTP Error Block (see section 8.17) sent by the party which detected the
message to the party which sent the erroneous message. error in an IOTP message to the party which sent the erroneous
message.
If communications are too poor, a message which was sent may not reach If communications are too poor, a message which was sent may not
its destination. In this case a time-out might occur. reach its destination. In this case a time-out might occur.
The Error Codes associated with Technical Errors are recorded in the The Error Codes associated with Technical Errors are recorded in the
Error Component which lists all the different technical errors which can Error Component which lists all the different technical errors which
be set. can be set.
4.2 Business Errors 4.2 Business Errors
Business Errors may occur when the IOTP messages are "technically" Business Errors may occur when the IOTP messages are "technically"
correct. They are connected with a particular process, for example, an correct. They are connected with a particular process, for example,
offer, payment, delivery or authentication, where each process has a an offer, payment, delivery or authentication, where each process has
different set of possible business errors. a different set of possible business errors.
For example, "Insufficient funds" is a reasonable payment error but makes For example, "Insufficient funds" is a reasonable payment error but
no sense for a delivery while "Back ordered" is a reasonable delivery makes no sense for a delivery while "Back ordered" is a reasonable
error but not meaningful for a payment. Business errors are indicated in delivery error but not meaningful for a payment. Business errors are
the Status Component (see section 7.16) of a "response block" of the indicated in the Status Component (see section 7.16) of a "response
appropriate type, for example a Payment Response Block or a Delivery block" of the appropriate type, for example a Payment Response Block
Response Block. This allows whatever additional response related or a Delivery Response Block. This allows whatever additional
information is needed to accompany the error indication. response related information is needed to accompany the error
indication.
Business errors must usually be presented to the user so that they can Business errors must usually be presented to the user so that they
decide what to do next. For example, if the error is insufficient funds can decide what to do next. For example, if the error is insufficient
in a Brand Independent Offer (see section 9.1.2.2), the user might wish funds in a Brand Independent Offer (see section 9.1.2.2), the user
to choose a different payment instrument/account of the same brand or a might wish to choose a different payment instrument/account of the
different brand or payment system. Alternatively, if the IOTP based same brand or a different brand or payment system. Alternatively, if
implementation allows it and it makes sense for that instrument, the user the IOTP based implementation allows it and it makes sense for that
might want to put more funds into the instrument/account and try again. instrument, the user might want to put more funds into the
instrument/account and try again.
4.3 Error Depth 4.3 Error Depth
The three levels at which IOTP errors can occur are the transport level, The three levels at which IOTP errors can occur are the transport
the message level, and the block level. Each is described below. level, the message level, and the block level. Each is described
below.
4.3.1 Transport Level 4.3.1 Transport Level
This level of error indicates a fundamental problem in the transport This level of error indicates a fundamental problem in the transport
mechanism over which the IOTP communication is taking place. mechanism over which the IOTP communication is taking place.
All transport level errors are technical errors and are indicated by All transport level errors are technical errors and are indicated by
either an explicit transport level error indication, such as a "No route either an explicit transport level error indication, such as a "No
to destination" error from TCP/IP, or by a time out where no response has route to destination" error from TCP/IP, or by a time out where no
been received to a request. response has been received to a request.
The only reasonable automatic action when faced with transport level The only reasonable automatic action when faced with transport level
errors is to retry and, after some number of automatic retries, to inform errors is to retry and, after some number of automatic retries, to
the user. inform the user.
The explicit error indications that can be received are transport The explicit error indications that can be received are transport
dependent and the documentation for the appropriate IOTP Transport dependent and the documentation for the appropriate IOTP Transport
supplement should be consulted for errors and appropriate actions. supplement should be consulted for errors and appropriate actions.
Appropriate time outs to use are a function of both the transport being Appropriate time outs to use are a function of both the transport
used and of the payment system if the request encapsulates payment being used and of the payment system if the request encapsulates
information. The transport and payment system specific documentation payment information. The transport and payment system specific
should be consulted for time out and automatic retry parameters. documentation should be consulted for time out and automatic retry
Frequently there is no way to directly inform the other party of parameters. Frequently there is no way to directly inform the other
transport level errors but they should generally be logged and if party of transport level errors but they should generally be logged
automatic recovery is unsuccessful and there is a human user, the user and if automatic recovery is unsuccessful and there is a human user,
should be informed. the user should be informed.
4.3.2 Message Level 4.3.2 Message Level
This level of error indicates a fundamental technical problem with an This level of error indicates a fundamental technical problem with an
entire IOTP message. For example, the XML is not "Well Formed", or the entire IOTP message. For example, the XML is not "Well Formed", or
message is too large for the receiver to handle or there are errors in the message is too large for the receiver to handle or there are
the Transaction Reference Block (see section 3.3) so it is not possible errors in the Transaction Reference Block (see section 3.3) so it is
to figure out what transaction the message relates to. not possible to figure out what transaction the message relates to.
All message level errors are technical errors and are indicated by Error All message level errors are technical errors and are indicated by
Components (see section 7.21) sent to the other party. The Error Error Components (see section 7.21) sent to the other party. The
Component includes a Severity attribute which indicates whether the error Error Component includes a Severity attribute which indicates whether
is a Warning and may be ignored, a TransientError which indicates that a the error is a Warning and may be ignored, a TransientError which
retry may resolve the problem or a HardError in which case the indicates that a retry may resolve the problem or a HardError in
transaction must fail. which case the transaction must fail.
The Technical Errors (see section 7.21.2 Error Codes) that are Message The Technical Errors (see section 7.21.2 Error Codes) that are
Level errors are: Message Level errors are:
o XML not well formed. The document is not well formed XML (see [XML]) 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 XML not valid. The document is not valid XML (see [XML])
o block level technical errors (see section 4.3.3) on the Transaction o block level technical errors (see section 4.3.3) on the
Reference Block (see section 3.3) and the Signature Block only. Checks Transaction Reference Block (see section 3.3) and the Signature
on these blocks should only be carried out if the XML is valid Block only. Checks on these blocks should only be carried out if
the XML is valid
Note that checks on the Signature Block include checking, where possible, Note that checks on the Signature Block include checking, where
that each Signature Component is correctly calculated. If the Signature possible, that each Signature Component is correctly calculated. If
is incorrectly calculated then the data that should have been covered by the Signature is incorrectly calculated then the data that should
the signature can not be trusted and must be treated as erroneous. A have been covered by the signature can not be trusted and must be
description of how to check a signature is correctly calculated is treated as erroneous. A description of how to check a signature is
contained in section 6.2. correctly calculated is contained in section 6.2.
4.3.3 Block Level 4.3.3 Block Level
A Block level error indicates a problem with a block or one of its A Block level error indicates a problem with a block or one of its
components in an IOTP message (apart from Transaction Reference or components in an IOTP message (apart from Transaction Reference or
Signature Blocks). The message has been transported properly, the overall Signature Blocks). The message has been transported properly, the
message structure and the block/component(s) including the Transaction overall message structure and the block/component(s) including the
Reference and Signature Blocks are meaningful but there is some error Transaction Reference and Signature Blocks are meaningful but there
related to one of the other blocks. is some error related to one of the other blocks.
Block level errors can be either: Block level errors can be either:
o technical errors, or o technical errors, or
o business errors o business errors
Technical Errors are further divided into:
o Block Level Attribute and Element Checks, and Technical Errors are further divided into:
o Block and Component Consistency Checks o Block Level Attribute and Element Checks, and
o Transient Technical Errors o Block and Component Consistency Checks
If a technical error occurs related to a block or component, then an o Transient Technical Errors
Error Component is generated for return. If a technical error occurs related to a block or component, then an
Error Component is generated for return.
4.3.3.1 Block Level Attribute and Element Checks 4.3.3.1 Block Level Attribute and Element Checks
Block Level Attribute and Element Checks occur only within the same Block Level Attribute and Element Checks occur only within the same
block. Checks which involve cross-checking against other blocks are block. Checks which involve cross-checking against other blocks are
covered by Block and Component Consistency Checks. covered by Block and Component Consistency Checks.
The Block Level Attribute & Element checks are: The Block Level Attribute & Element checks are:
o checking that each attribute value within each element in a block o checking that each attribute value within each element in a block
conforms to any rules contained within this IOTP specification conforms to any rules contained within this IOTP specification
o checking that the content of each element conforms to any rules o checking that the content of each element conforms to any rules
contained within this IOTP specification contained within this IOTP specification
o if the previous checks are OK, then checking the consistency of o if the previous checks are OK, then checking the consistency of
attribute values and element content against other attribute values or attribute values and element content against other attribute
element content within any other components in the same block. values or element content within any other components in the same
block.
4.3.3.2 Block and Component Consistency Checks 4.3.3.2 Block and Component Consistency Checks
Block and Component Consistency Checks consist of: Block and Component Consistency Checks consist of:
o checking that the combination of blocks and/or components present in o checking that the combination of blocks and/or components present
the IOTP Message are consistent with the rules contained within this in the IOTP Message are consistent with the rules contained within
IOTP specification this IOTP specification
o checking for consistency between attributes and element content within o checking for consistency between attributes and element content
the blocks within the same IOTP message. within the blocks within the same IOTP message.
o checking for consistency between attributes and elements in blocks in o checking for consistency between attributes and elements in blocks
this IOTP message and blocks received in earlier IOTP messages for the in this IOTP message and blocks received in earlier IOTP messages
same IOTP transaction for the same IOTP transaction
If the block passes the "Block Level Attribute and Element Checks" and If the block passes the "Block Level Attribute and Element Checks"
the "Block and Component Consistency Checks" then it is processed either and the "Block and Component Consistency Checks" then it is processed
by the IOTP Aware application or perhaps by some "back-end" system such either by the IOTP Aware application or perhaps by some "back-end"
as a payment server. system such as a payment server.
4.3.3.3 Transient Technical Errors 4.3.3.3 Transient Technical Errors
During the processing of the Block some temporary failure may occur that During the processing of the Block some temporary failure may occur
can potentially be recovered by the other trading role re-transmitting, that can potentially be recovered by the other trading role re-
at some slightly later time, the original message that they sent. transmitting, at some slightly later time, the original message that
they sent. In this case the other role is informed of the Transient
In this case the other role is informed of the Transient Error by sending Error by sending them an Error Component (see section 7.21) with the
them an Error Component (see section 7.21) with the Severity Attribute Severity Attribute set to TransientError and the MinRetrySecs
set to TransientError and the MinRetrySecs attribute set to some value attribute set to some value suitable for the Transport Mechanism
suitable for the Transport Mechanism and/or payment protocol being used and/or payment protocol being used (see appropriate Transport and
(see appropriate Transport and payment protocol Supplements). payment protocol Supplements).
Note that transient technical errors can be generated by any of the Note that transient technical errors can be generated by any of the
Trading Roles involved in transaction. Trading Roles involved in transaction.
4.3.3.4 Block Level Business Errors 4.3.3.4 Block Level Business Errors
If a business error occurs in a process such as a Payment or a Delivery, If a business error occurs in a process such as a Payment or a
then the appropriate type of response block is returned containing a Delivery, then the appropriate type of response block is returned
Status Component (see section 7.16) with the ProcessState attribute set containing a Status Component (see section 7.16) with the
to Failed and the CompletionCode indicating the nature of the problem. ProcessState attribute set to Failed and the CompletionCode
indicating the nature of the problem.
Some business errors may be "transient" in that the Consumer role may be Some business errors may be "transient" in that the Consumer role may
able to recover and complete the transaction in some other way. For be able to recover and complete the transaction in some other way.
example if the Credit Card that a consumer provided had insufficient For example if the Credit Card that a consumer provided had
funds for a purchase, then the Consumer may recover by using a different insufficient funds for a purchase, then the Consumer may recover by
credit card. using a different credit card.
Recovery from "transient" business errors is dependent on the Recovery from "transient" business errors is dependent on the
CompletionCode. See the definition of the Status Component for what is CompletionCode. See the definition of the Status Component for what
possible. is possible.
Note that no Error Component or Error Block is generated for business Note that no Error Component or Error Block is generated for business
errors. errors.
4.4 Idempotency, Processing Sequence, and Message Flow 4.4 Idempotency, Processing Sequence, and Message Flow
IOTP messages are actually a combination of blocks and components as IOTP messages are actually a combination of blocks and components as
described in 3.1.1 IOTP Message Structure. Especially in future described in 3.1.1 IOTP Message Structure. Especially in future
extensions of IOTP, a rich variety of combinations of such blocks and extensions of IOTP, a rich variety of combinations of such blocks and
components can occur. It is important that the multiple components can occur. It is important that the multiple
transmission/receipt of the "same" request for an action that will change transmission/receipt of the "same" request for an action that will
state does not result in that action occurring more than once. This is change state does not result in that action occurring more than once.
called idempotency. For example, a customer paying for an order would This is called idempotency. For example, a customer paying for an
want to pay the full amount only once. Most network transport mechanisms order would want to pay the full amount only once. Most network
have some probability of delivering a message more than once or not at transport mechanisms have some probability of delivering a message
all, perhaps requiring retransmission. On the other hand, a request for more than once or not at all, perhaps requiring retransmission. On
status can reasonably be repeated and should be processed fresh each time the other hand, a request for status can reasonably be repeated and
it is received. should be processed fresh each time it is received.
Correct implementation of IOTP can be modelled by a particular processing Correct implementation of IOTP can be modelled by a particular
order as detailed below. Any other method that is indistinguishable in processing order as detailed below. Any other method that is
the messages sent between the parties is equally acceptable. indistinguishable in the messages sent between the parties is equally
acceptable.
4.5 Server Role Processing Sequence 4.5 Server Role Processing Sequence
"Server roles" are any Trading Role which is not the Consumer role. They "Server roles" are any Trading Role which is not the Consumer role.
are "Server roles" since they typically receive a request which they must They are "Server roles" since they typically receive a request which
service and then produce a response. However server roles can also they must service and then produce a response. However server roles
initiate transactions. More specifically Server Roles must be able to: can also initiate transactions. More specifically Server Roles must
be able to:
o Initiate a transaction (see section 4.5.1). These are divided into: o Initiate a transaction (see section 4.5.1). These are divided
- payment related transactions and into:
- infrastructure transactions
o Accept and process a message received from another role (see section - payment related transactions and
4.5.2). This includes:
- identifying if the message belongs to a transaction that has been
received before
- handling duplicate messages
- generating Transient errors if the servers that process the input
message are too busy to handle it
- processing the message if it is error free, authorised and, if
appropriate, producing a response to send back to the other role
o Cancel a current transaction if requested (see section 4.5.3) - infrastructure transactions
o Re-transmit messages if a response was expected but has not been o Accept and process a message received from another role (see
received in a reasonable time (see section 4.5.4). section 4.5.2). This includes:
- identifying if the message belongs to a transaction that has
been received before
- handling duplicate messages
- generating Transient errors if the servers that process the
input message are too busy to handle it
- processing the message if it is error free, authorised and, if
appropriate, producing a response to send back to the other
role
o Cancel a current transaction if requested (see section 4.5.3)
o Re-transmit messages if a response was expected but has not been
received in a reasonable time (see section 4.5.4).
4.5.1 Initiating Transactions 4.5.1 Initiating Transactions
Server Roles may initiate a variety of different types of transaction. Server Roles may initiate a variety of different types of
Specifically: transaction. Specifically:
o an Inquiry Transaction (see section 9.2.1) o an Inquiry Transaction (see section 9.2.1)
o a Ping Transaction (see section 9.2.2) o a Ping Transaction (see section 9.2.2)
o an Authentication Transaction (see section 9.1.6)
o an Authentication Transaction (see section 9.1.6) o a Payment Related Transaction such as:
o a Payment Related Transaction such as: - a Deposit (see section 9.1.7)
- a Deposit (see section 9.1.7)
- a Purchase (see section 9.1.8) - a Purchase (see section 9.1.8)
- a Refund (see section 9.1.9)
- a Withdrawal (see section 9.1.10) - a Refund (see section 9.1.9)
- a Value Exchange (see section 9.1.11)
- a Withdrawal (see section 9.1.10)
- a Value Exchange (see section 9.1.11)
4.5.2 Processing Input Messages 4.5.2 Processing Input Messages
Processing input messages involves the following: Processing input messages involves the following:
o checking the structure and identity of the message o checking the structure and identity of the message
o checking for and handling duplicate messages o checking for and handling duplicate messages
o processing non-duplicate original messages which includes:
- checking for errors, then if no errors are found
- processing the message to produce an output message if appropriate
Each of these is discussed in more detail below. o processing non-duplicate original messages which includes:
4.5.2.1 Checking Structure and Message Identity - checking for errors, then if no errors are found
It is critical to check that the message is "well formed" XML and that - processing the message to produce an output message if
the transaction identifier (IotpTransId attribute on the TransId appropriate
Component) within the IOTP message can be successfully identified since
an IotpTransId will be needed to generate a response.
If the input message is not well formed then generate an Error Component Each of these is discussed in more detail below.
with a Severity of HardError and ErrorCode of XmlNotWellFrmd.
If the message is well formed but the IotpTransId cannot be identified 4.5.2.1 Checking Structure and Message Identity
then generate an ErrorComponent with:
o a Severity of HardError and an ErrorCode of AttMissing, It is critical to check that the message is "well formed" XML and
that the transaction identifier (IotpTransId attribute on the TransId
Component) within the IOTP message can be successfully identified
since an IotpTransId will be needed to generate a response.
o a PackagedContent containing "IotpTransId" - the missing attribute. If the input message is not well formed then generate an Error
Component with a Severity of HardError and ErrorCode of
XmlNotWellFrmd.
Insert the Error Component inside an Error Block with a new TransactionId If the message is well formed but the IotpTransId cannot be
component with a new IotpTransId and return it to the sender of the identified then generate an ErrorComponent with:
original message.
o a Severity of HardError and an ErrorCode of AttMissing,
o a PackagedContent containing "IotpTransId" - the missing
attribute.
Insert the Error Component inside an Error Block with a new
TransactionId component with a new IotpTransId and return it to the
sender of the original message.
4.5.2.2 Checking/Handling Duplicate Messages 4.5.2.2 Checking/Handling Duplicate Messages
If the input message can be identified as potentially a valid input If the input message can be identified as potentially a valid input
message then check to see if an "identical" input message has been message then check to see if an "identical" input message has been
received before. Identical means that all blocks, components, elements, received before. Identical means that all blocks, components,
attribute values and element content in the input message are the same. elements, attribute values and element content in the input message
are the same.
[Note] The recommended way of checking for identical messages is to Note: The recommended way of checking for identical messages is to
check for equal values of their [DOM-HASH] check for equal values of their [DOM-HASH]
[Note End]
If an identical message has been received before then check to see if the If an identical message has been received before then check to see if
processing of the previous message has completed. the processing of the previous message has completed.
If processing has not completed then generate an Error Component with a If processing has not completed then generate an Error Component with
Severity of Transient Error and an Error Code of MsgBeingProc to indicate a Severity of Transient Error and an Error Code of MsgBeingProc to
the message is being processed and send it back to the sender of the indicate the message is being processed and send it back to the
Input Message requesting that the original message be resent after an sender of the Input Message requesting that the original message be
appropriate period of time. resent after an appropriate period of time.
Otherwise, if processing has completed and resulted in an output message Otherwise, if processing has completed and resulted in an output
then retrieve the last message that was sent and send it again. message then retrieve the last message that was sent and send it
again.
If the message is not a duplicate then it should be processed. If the message is not a duplicate then it should be processed.
4.5.2.3 Processing Non-Duplicate Message 4.5.2.3 Processing Non-Duplicate Message
Once it's been established that the message is not a duplicate, then it Once it's been established that the message is not a duplicate, then
can be processed. This involves: it can be processed. This involves:
o checking that a server is available to handle the message, generating a o checking that a server is available to handle the message,
Transient Error if it is not generating a Transient Error if it is not
o checking the Transaction is Not Already in error or cancelled o checking the Transaction is Not Already in error or cancelled
o validating the input message. This includes: o validating the input message. This includes:
- checking for message level errors
- checking for block level errors
- checking any encapsulated data
o checking for errors in the sequence that blocks have been received - checking for message level errors
o generating error components for any errors that result - checking for block level errors
- checking any encapsulated data
o if neither hard errors nor transient errors result, then processing the o checking for errors in the sequence that blocks have been received
message and generating an output message, if required, for return to
the sender of the Input Message
[Note] This approach to handling of duplicate input messages means, o generating error components for any errors that result
if absolutely "identical" messages are received then
absolutely "identical" messages are returned. This also
applies to Inquiry and Ping transactions when in reality the
state of a transaction or the processing ability of the
servers may have changed. If up-to-date status of transactions
or servers is required, then an IOTP transaction with a new
value for the ID attribute of the MsgId component must be
used.
[Note End]
Each of the above steps is discussed below. o if neither hard errors nor transient errors result, then
processing the message and generating an output message, if
required, for return to the sender of the Input Message
CHECKING A SERVER IS AVAILABLE Note: This approach to handling of duplicate input messages means, if
absolutely "identical" messages are received then absolutely
"identical" messages are returned. This also applies to Inquiry and
Ping transactions when in reality the state of a transaction or the
processing ability of the servers may have changed. If up-to-date
status of transactions or servers is required, then an IOTP
transaction with a new value for the ID attribute of the MsgId
component must be used.
The process that is handling the input message should check that the rest Each of the above steps is discussed below.
of the system is not so busy that a response in a reasonable time cannot
be produced.
If the server is too busy, then it should generate an Error Component CHECKING A SERVER IS AVAILABLE
with a Severity of Transient Error and an Error Code of SystemBusy and
send it back to the sender of the Input Message requesting that the
original message be resent after an appropriate period of time.
[Note] Some servers may occasionally become very busy due to The process that is handling the input message should check that the
unexpected increases in workload. This approach allows short rest of the system is not so busy that a response in a reasonable
peaks in workloads to be handled by delaying the input of time cannot be produced.
messages by asking the sender of the message to resubmit
later.
[Note End]
CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
Check that: If the server is too busy, then it should generate an Error Component
with a Severity of Transient Error and an Error Code of SystemBusy
and send it back to the sender of the Input Message requesting that
the original message be resent after an appropriate period of time.
o previous messages received or sent did not contain or result in Hard Note: Some servers may occasionally become very busy due to
Errors, and unexpected increases in workload. This approach allows short peaks in
workloads to be handled by delaying the input of messages by asking
the sender of the message to resubmit later.
o the Transaction has not been cancelled by either the Consumer or the CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
Server Trading Role
If it has then, ignore the message. A transaction with hard errors or Check that:
that has been cancelled, cannot be restarted.
CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS o previous messages received or sent did not contain or result in
Hard Errors, and
If the transaction is still OK then check for message level errors. This o the Transaction has not been cancelled by either the Consumer or
involves: the Server Trading Role
o checking the XML is valid If it has then, ignore the message. A transaction with hard errors or
that has been cancelled, cannot be restarted.
o checking that the elements, attributes and content of the Transaction CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS
Reference Block are without error and conform to this specification
o checking the digital signature which involves: If the transaction is still OK then check for message level errors.
- checking that the Signature value is correctly calculated, and This involves:
- the hash values in the digests are correctly calculated where the
source of the hash value is available.
Checking for block level errors involves: o checking the XML is valid
o checking within each block (apart from the Transaction Reference Block) o checking that the elements, attributes and content of the
that: Transaction Reference Block are without error and conform to this
- the attributes, elements and element contents are valid specification
- the values of the attributes, elements and element contents are
consistent within the block
o checking that the combination of blocks are valid o checking the digital signature which involves:
o checking that the values of the attribute, elements and element - checking that the Signature value is correctly calculated, and
contents are consistent between the blocks in the input message and
blocks in earlier messages either sent or received. This includes
checking that the presence of a block is valid for a particular
transaction type
If the message contains any encapsulated data, then if possible check the - the hash values in the digests are correctly calculated where
encapsulated data for errors using additional software to check the data the source of the hash value is available.
where appropriate.
Checking for block level errors involves:
o checking within each block (apart from the Transaction Reference
Block) that:
- the attributes, elements and element contents are valid
- the values of the attributes, elements and element contents are
consistent within the block
o checking that the combination of blocks are valid
o checking that the values of the attribute, elements and element
contents are consistent between the blocks in the input message
and blocks in earlier messages either sent or received. This
includes checking that the presence of a block is valid for a
particular transaction type
If the message contains any encapsulated data, then if possible check
the encapsulated data for errors using additional software to check
the data where appropriate.
4.5.2.4 Check for Errors in Block Sequence 4.5.2.4 Check for Errors in Block Sequence
[Note] For reasons of brevity, the following explanations of how to Note: For reasons of brevity, the following explanations of how to
check for errors in Block sequence, the phrase "refers to an check for errors in Block sequence, the phrase "refers to an IOTP
IOTP transaction" is interpreted as "is contained in an IOTP transaction" is interpreted as "is contained in an IOTP Message where
Message where the Trans Ref Block contains an IotpTransId that the Trans Ref Block contains an IotpTransId that refers to". So, for
refers to". So, for example, " If an Error or Cancel Block example, " If an Error or Cancel Block refers to an IOTP transaction
refers to an IOTP transaction that is not recognised then ..." that is not recognised then ..." should be interpreted as " If an
should be interpreted as " If an Error or Cancel Block is Error or Cancel Block is contained in an IOTP Message where the Trans
contained in an IOTP Message where the Trans Ref Block Ref Block contains an IotpTransId that refers to an IOTP transaction
contains an IotpTransId that refers to an IOTP transaction that is not recognised then ...
that is not recognised then ...
[Note End]
Errors in the sequence that blocks arrive depends on the block. Blocks Errors in the sequence that blocks arrive depends on the block.
where checking for sequence is required are: Blocks where checking for sequence is required are:
o Error and Cancel Blocks. If an Error or Cancel Block refers to an IOTP o Error and Cancel Blocks. If an Error or Cancel Block refers to an
transaction that is not recognised then it is a Hard Error. Do not IOTP transaction that is not recognised then it is a Hard Error.
return an error if Error or Cancel Blocks have been received for the Do not return an error if Error or Cancel Blocks have been
IOTP Transaction before to avoid looping. received for the IOTP Transaction before to avoid looping.
o Inquiry Request and Response Blocks. If an Inquiry Request or an o Inquiry Request and Response Blocks. If an Inquiry Request or an
Inquiry Response Block refers to an IOTP transaction that is not Inquiry Response Block refers to an IOTP transaction that is not
recognised then it is a Hard Error recognised then it is a Hard Error
o Authentication Request Block. If an Authentication Request Block refers o Authentication Request Block. If an Authentication Request Block
to an IOTP transaction that is recognised it is a Hard Error refers to an IOTP transaction that is recognised it is a Hard
Error
o Authentication Response Block. Check as follows: o Authentication Response Block. Check as follows:
- if an Authentication Response Block does not refer to an IOTP
transaction that is recognised it is a Hard Error, otherwise
- if the Authentication Response Block doesn't refer to an
Authentication Request that had been previously sent then it is a
Hard Error, otherwise
- if an Authentication Response for the same IOTP transaction has been
received before and the Authentication was successful then it is a
Hard Error.
o Authentication Status Block. Check as follows: - if an Authentication Response Block does not refer to an IOTP
- if an Authentication Status Block does not refer to an IOTP transaction that is recognised it is a Hard Error, otherwise
transaction that is recognised it is a Hard Error, otherwise
- if the Authentication Status Block doesn't refer to an Authentication
Response that had been previously sent then it is a Hard Error,
otherwise
- if an Authentication Status for the same IOTP transaction has been
received before then it is a Warning Error
o TPO Selection Block (Merchant only). Check as follows: - if the Authentication Response Block doesn't refer to an
- if the TPO Selection Block doesn't refer to an IOTP Transaction that Authentication Request that had been previously sent then it is
is recognised then it is a Hard Error, otherwise a Hard Error, otherwise
- if the TPO Selection Block refers to an IOTP Transaction where a TPO
Block and Offer Response (in one message) had previously been sent
then it is a Hard Error, otherwise
- if the TPO Selection Block does not refer to an IOTP Transaction
where a TPO Block only (i.e. without an Offer Response) had
previously been sent then it is a Hard Error, otherwise
- if a TPO Selection Block for the same TPO Block has been received
before then it is a Hard Error
o Payment Request Block (Payment Handler only). Check as follows: - if an Authentication Response for the same IOTP transaction has
- if the Payment Request Block refers to an IOTP Transaction that is been received before and the Authentication was successful then
not recognised then its OK, otherwise it is a Hard Error.
- if the Payment Request Block refers to IOTP Transaction that was not
for a Payment then it is a Hard Error, otherwise
- if there was a previous payment that failed with a non-recoverable
Completion Code then it is a Hard Error, otherwise
- if a previous payment is still in progress then it is a Hard Error
o Payment Exchange Block (Payment Handler only). Check as follows: o Authentication Status Block. Check as follows:
- if the Payment Exchange Block doesn't refer to an IOTP Transaction
that is recognised then it is a Hard Error, otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction where a
Payment Exchange had previously been sent then it a Hard Error
o Delivery Request (Delivery Handler Only). If the Delivery Request Block - if an Authentication Status Block does not refer to an IOTP
refers to an IOTP Transaction that is recognised by the Server then it transaction that is recognised it is a Hard Error, otherwise
is a Hard Error
If any Error Components have been generated then collect them into an - if the Authentication Status Block doesn't refer to an
Error Block for sending to the sender of the Input message. Note that Authentication Response that had been previously sent then it
Error Blocks should be sent back to the sender of the message and to the is a Hard Error, otherwise
ErrorLogNetLocn for the Trading Role of the sender if one is specified.
[Note] The above checking on the sequence of Authentication Responses - if an Authentication Status for the same IOTP transaction has
and Payment Requests supports the Consumer re-submitting a been received before then it is a Warning Error
repeat action request since the previous one failed, for
example:
o because they did not know the correct response (e.g. a
password) on an authentication or,
o they were unable to pay as there were insufficient funds on
a credit card
[Note End]
PROCESS THE ERROR FREE INPUT MESSAGE o TPO Selection Block (Merchant only). Check as follows:
If the input message passes the previous checks then it can be processed - if the TPO Selection Block doesn't refer to an IOTP Transaction
to produce an output message if required. Note that: that is recognised then it is a Hard Error, otherwise
o Inquiry Requests on Ping Transactions should be ignored - if the TPO Selection Block refers to an IOTP Transaction where
a TPO Block and Offer Response (in one message) had previously
been sent then it is a Hard Error, otherwise
o if the Input message contains an Error Block with a Transient Error - if the TPO Selection Block does not refer to an IOTP
then wait for the required time then resend the previous message, if a Transaction where a TPO Block only (i.e. without an Offer
response to the earlier message has not been received Response) had previously been sent then it is a Hard Error,
otherwise
o if the input message contains a Error Component with a HardError or a - if a TPO Selection Block for the same TPO Block has been
Cancel Block then stop all further processing of the transaction. This received before then it is a Hard Error
includes suppressing the sending of any messages currently being
generated or responding to any new non-duplicate messages that are
received
o processing of encapsulated messages (e.g. Payment Protocol Messages) o Payment Request Block (Payment Handler only). Check as follows:
may result in additional transient errors
o a digital signature can only safely be generated once all the blocks - if the Payment Request Block refers to an IOTP Transaction that
and components have been generated and it is known which elements in is not recognised then its OK, otherwise
the message need to be signed.
If an output message is generated then it should be saved so that it can - if the Payment Request Block refers to IOTP Transaction that
be resent as required if an identical input message is received again. was not for a Payment then it is a Hard Error, otherwise
Note that output messages that contain transient errors are not saved so
that they can be processed afresh when the input message is received - if there was a previous payment that failed with a non-
again. recoverable Completion Code then it is a Hard Error, otherwise
- if a previous payment is still in progress then it is a Hard
Error
o Payment Exchange Block (Payment Handler only). Check as follows:
- if the Payment Exchange Block doesn't refer to an IOTP
Transaction that is recognised then it is a Hard Error,
otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction
where a Payment Exchange had previously been sent then it a
Hard Error
o Delivery Request (Delivery Handler Only). If the Delivery Request
Block refers to an IOTP Transaction that is recognised by the
Server then it is a Hard Error
If any Error Components have been generated then collect them into an
Error Block for sending to the sender of the Input message. Note that
Error Blocks should be sent back to the sender of the message and to
the ErrorLogNetLocn for the Trading Role of the sender if one is
specified.
Note: The above checking on the sequence of Authentication Responses
and Payment Requests supports the Consumer re-submitting a repeat
action request since the previous one failed, for example:
o because they did not know the correct response (e.g., a password)
on an authentication or,
o they were unable to pay as there were insufficient funds on a
credit card
PROCESS THE ERROR FREE INPUT MESSAGE
If the input message passes the previous checks then it can be
processed to produce an output message if required. Note that:
o Inquiry Requests on Ping Transactions should be ignored
o if the Input message contains an Error Block with a Transient
Error then wait for the required time then resend the previous
message, if a response to the earlier message has not been
received
o if the input message contains a Error Component with a HardError
or a Cancel Block then stop all further processing of the
transaction. This includes suppressing the sending of any messages
currently being generated or responding to any new non-duplicate
messages that are received
o processing of encapsulated messages (e.g., Payment Protocol
Messages) may result in additional transient errors
o a digital signature can only safely be generated once all the
blocks and components have been generated and it is known which
elements in the message need to be signed.
If an output message is generated then it should be saved so that it
can be resent as required if an identical input message is received
again. Note that output messages that contain transient errors are
not saved so that they can be processed afresh when the input message
is received again.
4.5.3 Cancelling a Transaction 4.5.3 Cancelling a Transaction
This process is used to cancel a transaction running on an IOTP server. This process is used to cancel a transaction running on an IOTP
It is initiated by some other process as a result of an external request server. It is initiated by some other process as a result of an
from another system or server that is being run by the same Trading Role. external request from another system or server that is being run by
The processing required is as follows: the same Trading Role. The processing required is as follows:
o if the IotpTransId of the transaction to be cancelled is not o if the IotpTransId of the transaction to be cancelled is not
recognised, or complete then fail the request, otherwise recognised, or complete then fail the request, otherwise
o if the IotpTransId refers to a Ping Transaction then fail the request, o if the IotpTransId refers to a Ping Transaction then fail the
otherwise request, otherwise
o determine which Document Exchange to cancel and generate a Cancel Block o determine which Document Exchange to cancel and generate a Cancel
and send it to the other party Block and send it to the other party
[Note] Cancelling a transaction on an IOTP server typically arises Note: Cancelling a transaction on an IOTP server typically arises for
for a business reason. For example a merchant may have a business reason. For example a merchant may have attempted
attempted authentication several times without success and as authentication several times without success and as a result decides
a result decides to cancel the transaction. Therefore the to cancel the transaction. Therefore the process that decides to take
process that decides to take this action needs to send a this action needs to send a message from the process/server that made
message from the process/server that made the business the business decision to the IOTP server with the instruction that
decision to the IOTP server with the instruction that the IOTP the IOTP transaction should be cancelled.
transaction should be cancelled.
[Note End]
4.5.4 Retransmitting Messages 4.5.4 Retransmitting Messages
The server should periodically check for transactions where a message is The server should periodically check for transactions where a message
expected in return but none has been received after a time that is is expected in return but none has been received after a time that is
dependent on factors such as: dependent on factors such as:
o the Transport Mechanism being used; o the Transport Mechanism being used;
o the time required to process encapsulated messages (e.g. Payment o the time required to process encapsulated messages (e.g., Payment
messages) and messages) and
o whether or not human input is required. o whether or not human input is required.
If no message has been received the original message should be resent. If no message has been received the original message should be
This should occur up to a maximum number of times dependent on the resent. This should occur up to a maximum number of times dependent
reliability of the Transport Mechanism being used. on the reliability of the Transport Mechanism being used.
If no response is received after the required time then the Transaction If no response is received after the required time then the
should be "timed out". In this case, set the process state of the Transaction should be "timed out". In this case, set the process
transaction to Failed, and a completion code of either: state of the transaction to Failed, and a completion code of either:
o TimedOutRcvr if the transaction can potentially recovered later, or o TimedOutRcvr if the transaction can potentially recovered later,
or
o TimedOutNoRcvr if the transaction is non-recoverable o TimedOutNoRcvr if the transaction is non-recoverable
4.6 Client Role Processing Sequence 4.6 Client Role Processing Sequence
The "Client role" in IOTP is the Consumer Trading Role. The "Client role" in IOTP is the Consumer Trading Role.
[Note] A company or Organisation that is a Merchant, for example, may Note: A company or Organisation that is a Merchant, for example, may
take on the Trading Role of a Consumer when making purchases take on the Trading Role of a Consumer when making purchases or
or downloading or withdrawing electronic cash. downloading or withdrawing electronic cash.
[Note End]
More specifically the Consumer Role must be able to: More specifically the Consumer Role must be able to:
o Initiate a transaction (see section 4.6.1). These are divided into: o Initiate a transaction (see section 4.6.1). These are divided
- payment related transactions and into:
- infrastructure transactions
o Accept and process a message received from another role (see section - payment related transactions and
4.6.2). This includes:
- identifying if the message belongs to a transaction that has been
received before
- handling duplicate messages
- generating Transient errors if the servers that process the input
message are too busy to handle it
- processing the message if it is error free and, if appropriate,
producing a response to send back to the other role
o Cancel a current transaction if requested, for example by the User (see - infrastructure transactions
section 4.6.3)
o Re-transmit messages if a response was expected but has not been o Accept and process a message received from another role (see
received in a reasonable time (see section 4.6.4). section 4.6.2). This includes:
4.6.1 Initiating Transactions - identifying if the message belongs to a transaction that has
been received before
The Consumer Role may initiate a number of different types of - handling duplicate messages
transaction. Specifically:
o an Inquiry Transaction (see section 9.2.1) - generating Transient errors if the servers that process the
input message are too busy to handle it
o a Ping Transaction (see section 9.2.2) - processing the message if it is error free and, if appropriate,
producing a response to send back to the other role
o an Authentication Transaction (see section 9.1.6) o Cancel a current transaction if requested, for example by the User
(see section 4.6.3)
o Re-transmit messages if a response was expected but has not been
received in a reasonable time (see section 4.6.4).
4.6.1 Initiating Transactions
The Consumer Role may initiate a number of different types of
transaction. Specifically:
o an Inquiry Transaction (see section 9.2.1)
o a Ping Transaction (see section 9.2.2)
o an Authentication Transaction (see section 9.1.6)
4.6.2 Processing Input Messages 4.6.2 Processing Input Messages
Processing of Input Messages for a Consumer Role is the same as for an Processing of Input Messages for a Consumer Role is the same as for
IOTP Server (see section 4.5.2) except in the area of checking for Errors an IOTP Server (see section 4.5.2) except in the area of checking for
in Block Sequence (for an IOTP Server see section 4.5.2.4). This is Errors in Block Sequence (for an IOTP Server see section 4.5.2.4).
described below This is described below
[Note] The description of the processing for an IOTP Server includes Note: The description of the processing for an IOTP Server includes
consideration of multi-threading of input messages and multi- consideration of multi-threading of input messages and multi-tasking
tasking of requests. For the Consumer Role - particularly if of requests. For the Consumer Role - particularly if running on a
running on a stand-alone system such as a PC - use of multi- stand-alone system such as a PC - use of multi-threading is a
threading is a decision of the implementer of the consumer decision of the implementer of the consumer role IOTP solution.
role IOTP solution.
[Note End]
4.6.2.1 Check for Errors in Block Sequence 4.6.2.1 Check for Errors in Block Sequence
The handling of the following blocks is the same as for an IOTP Server The handling of the following blocks is the same as for an IOTP
(see section 4.5.2.4) except that the Consumer Role is substituted for Server (see section 4.5.2.4) except that the Consumer Role is
IOTP Server Role: substituted for IOTP Server Role:
o Error and Cancel Blocks, o Error and Cancel Blocks,
o Inquiry Request and Response Blocks, o Inquiry Request and Response Blocks,
o Authentication Request, Response and Status Blocks. o Authentication Request, Response and Status Blocks.
For the other blocks a Consumer role might receive, the potential errors For the other blocks a Consumer role might receive, the potential
in the sequence that blocks arrive depends on the block. Blocks where errors in the sequence that blocks arrive depends on the block.
checking for sequence is required are: Blocks where checking for sequence is required are:
o TPO Block. Check as follows: o TPO Block. Check as follows:
- if the input message also contains an Authentication Request block
and an Offer Response Block then there is a Hard Error, otherwise
- if the input message also contains an Authentication Request block
and Authentication Status block then there is Hard Error otherwise,
- if the input message also contains an Authentication Request block
and the IOTP Transaction is recognised by the Consumer role's system,
then there is a Hard Error, otherwise
- if the input message also contains an Authentication Status block and
the IOTP Transaction is not recognised by the Consumer role's system
then there is a Hard Error, otherwise
- if input message also contains an Authentication Status Block and the
Authentication Status Block has not been sent after an earlier
Authentication Response message then there is a hard error
- if input message also contains an Offer Response Block and the IOTP
Transaction is recognised by the Consumer role's system then there is
a Hard Error, otherwise
- if the TPO Block occurs on its own and the IOTP Transaction is
recognised by the Consumer role's system then there is a Hard Error
o Offer Response Block. Check as follows: - if the input message also contains an Authentication Request
- if the Offer Response Block is part of a Brand Independent Offer block and an Offer Response Block then there is a Hard Error,
Exchange (see section 9.1.2.2) then there is no sequence checking as otherwise
it is part of the first message received, otherwise
- if the Offer Response Block is not part of an IOTP Transaction that
is recognised by the Consumer role then there is a Hard Error,
otherwise
- if the Offer Response Block does not refer to an IOTP transaction
where a TPO Selection Block was the last message sent then there is a
Hard Error
o Payment Exchange Block. Check as follows: - if the input message also contains an Authentication Request
- if the Payment Exchange Block doesn't refer to an IOTP Transaction block and Authentication Status block then there is Hard Error
that is recognised by the Consumer role's system then there is a Hard otherwise,
Error, otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction where
either a Payment Request or a Payment Exchange block was most
recently sent then there is a Hard Error
o Payment Response Block. Check as follows: - if the input message also contains an Authentication Request
- if the Payment Response Block doesn't refer to an IOTP Transaction block and the IOTP Transaction is recognised by the Consumer
that is recognised by the Consumer role's system then there is a Hard role's system, then there is a Hard Error, otherwise
Error, otherwise
- if the Payment Response doesn't refer to an IOTOP Transaction where
either a Payment Request or a Payment Exchange block was most
recently sent then there is a Hard Error
o Delivery Response Block. Check as follows: - if the input message also contains an Authentication Status
- if the Delivery Response Block doesn't refer to an IOTP Transaction block and the IOTP Transaction is not recognised by the
that is recognised by the Consumer role's system then there is a Hard Consumer role's system then there is a Hard Error, otherwise
Error, otherwise
- If the Delivery Response doesn't refer to an IOTP Transaction where - if input message also contains an Authentication Status Block
either a Payment Request or a Payment Exchange block was most and the Authentication Status Block has not been sent after an
recently sent then there is a Hard Error earlier Authentication Response message then there is a hard
error
- if input message also contains an Offer Response Block and the
IOTP Transaction is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- if the TPO Block occurs on its own and the IOTP Transaction is
recognised by the Consumer role's system then there is a Hard
Error
o Offer Response Block. Check as follows:
- if the Offer Response Block is part of a Brand Independent
Offer Exchange (see section 9.1.2.2) then there is no sequence
checking as it is part of the first message received, otherwise
- if the Offer Response Block is not part of an IOTP Transaction
that is recognised by the Consumer role then there is a Hard
Error, otherwise
- if the Offer Response Block does not refer to an IOTP
transaction where a TPO Selection Block was the last message
sent then there is a Hard Error
o Payment Exchange Block. Check as follows:
- if the Payment Exchange Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
o Payment Response Block. Check as follows:
- if the Payment Response Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- if the Payment Response doesn't refer to an IOTOP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
o Delivery Response Block. Check as follows:
- if the Delivery Response Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- If the Delivery Response doesn't refer to an IOTP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
4.6.3 Cancelling a Transaction 4.6.3 Cancelling a Transaction
This process cancels a current transaction on an Consumer role's system This process cancels a current transaction on an Consumer role's
as a result of an external request from the user, or another system or system as a result of an external request from the user, or another
server in the Consumer's role. The processing is the same as for an IOTP system or server in the Consumer's role. The processing is the same
Server (see section 4.5.3). as for an IOTP Server (see section 4.5.3).
4.6.4 Retransmitting Messages 4.6.4 Retransmitting Messages
The process of retransmitting messages is the same as for an IOTP Server The process of retransmitting messages is the same as for an IOTP
(see section 4.5.4). Server (see section 4.5.4).
5. Security Considerations 5. Security Considerations
This section considers, from an IETF perspective how IOTP addresses This section considers, from an IETF perspective how IOTP addresses
security. The next section (see section 6. Digital Signatures and IOTP) security. The next section (see section 6. Digital Signatures and
describes how IOTP uses Digital Signatures when these are needed. IOTP) describes how IOTP uses Digital Signatures when these are
needed.
This section covers: This section covers:
o determining whether to use digital signatures o determining whether to use digital signatures
o data privacy, and o data privacy, and
o payment protocol security. o payment protocol security.
5.1 Determining whether to use digital signatures 5.1 Determining whether to use digital signatures
The use of digital signatures within IOTP are entirely optional. IOTP can The use of digital signatures within IOTP are entirely optional. IOTP
work successfully entirely without the use of digital signatures. can work successfully entirely without the use of digital signatures.
Ultimately it is up to the Merchant, or other trading role, to decide Ultimately it is up to the Merchant, or other trading role, to decide
whether IOTP Messages will include signatures, and for the Consumer to whether IOTP Messages will include signatures, and for the Consumer
decide whether carrying out a transaction without signatures is an to decide whether carrying out a transaction without signatures is an
acceptable risk. If Merchants discover that transactions without acceptable risk. If Merchants discover that transactions without
signatures are not being accepted, then they will either: signatures are not being accepted, then they will either:
o start using signatures, o start using signatures,
o find a method of working which does not need signatures, or o find a method of working which does not need signatures, or
o accept a lower volume and value of business. o accept a lower volume and value of business.
A non-exhaustive list of the reasons why digital signatures might be used A non-exhaustive list of the reasons why digital signatures might be
follows: used follows:
o the Merchant (or other trading role) wants to demonstrate that they can o the Merchant (or other trading role) wants to demonstrate that
be trusted. If, for example, a merchant generates an Offer Response they can be trusted. If, for example, a merchant generates an
Signature (see section 7.19.2) using a certificate from a trusted third Offer Response Signature (see section 7.19.2) using a certificate
party, known to the Consumer, then the Consumer can check the signature from a trusted third party, known to the Consumer, then the
and certificate and so more reasonably rely on the offer being from the Consumer can check the signature and certificate and so more
actual Organisation the Merchant claims to be. In this case signatures reasonably rely on the offer being from the actual Organisation
using asymmetric cryptography are likely to be required the Merchant claims to be. In this case signatures using
asymmetric cryptography are likely to be required
o the Merchant, or other Trading Role, want to generate a record of the o the Merchant, or other Trading Role, want to generate a record of
transaction that is fit for a particular purpose. For example, with the transaction that is fit for a particular purpose. For example,
appropriate trust hierarchies, digital signatures could be checked by with appropriate trust hierarchies, digital signatures could be
the Consumer to determine: checked by the Consumer to determine:
- if it would be accepted by tax authorities as a valid record of a
transaction, or
- if some warranty, for example from a "Better Business Bureau" or
similar was being provided
o the Payment Handler, or Delivery Handler, needs to know that the - if it would be accepted by tax authorities as a valid record of
request is unaltered and authorised. For example, in IOTP, details of a transaction, or
how much to pay is sent to the Consumer in the Offer Response and then
forwarded to the Payment Handler in a Payment Request. If the request
is not signed, the Consumer could change the amount due by, for
example, removing a digit. If the Payment Handler has no access to the
original payment information in the Offer Response, then, without
signatures, the Payment Handler cannot be sure that the data has not
been altered. Similarly, if the payment information is not digitally
signed, the Payment Handler cannot be sure who is the Merchant that is
requesting the payment
o a Payment Handler or Delivery Handler wants to provide a non-refutable - if some warranty, for example from a "Better Business Bureau"
record of the completion status of a Payment or Delivery. If a Payment orsimilar was being provided
Response or Delivery Response is signed, then the Consumer can later
use the record of the Payment or Delivery to prove that it occurred.
This could be used, for example, for customer care purposes.
A non-exhaustive list of the reasons why digital signatures might not be o the Payment Handler, or Delivery Handler, needs to know that the
used follows: request is unaltered and authorised. For example, in IOTP, details
of how much to pay is sent to the Consumer in the Offer Response
and then forwarded to the Payment Handler in a Payment Request. If
the request is not signed, the Consumer could change the amount
due by, for example, removing a digit. If the Payment Handler has
no access to the original payment information in the Offer
Response, then, without signatures, the Payment Handler cannot be
sure that the data has not been altered. Similarly, if the payment
information is not digitally signed, the Payment Handler cannot be
sure who is the Merchant that is requesting the payment
o trading roles are combined therefore changes to data made by the o a Payment Handler or Delivery Handler wants to provide a non-
consumer can be detected. One of the reasons for using signatures is so refutable record of the completion status of a Payment or
that one trading role can determine if data has been changed by the Delivery. If a Payment Response or Delivery Response is signed,
Consumer or some other party. However if the trading roles have access then the Consumer can later use the record of the Payment or
to the necessary data, then it might be possible to compare, for Delivery to prove that it occurred. This could be used, for
example, the payment information in the Payment Request with the example, for customer care purposes.
payment information in the Offer Response. Access to the data necessary
could be realised by, for example, the Merchant and Payment Handler
roles being carried out by the same Organisation on the same system, or
the Merchant and Payment Handler roles being carried out on different
systems but the systems can communicate in some way. (Note this type of
communication is outside the current scope of IOTP)
o the processing cost of the cryptography is too high. For example, if a A non-exhaustive list of the reasons why digital signatures might not
payment is being made of only a few cents, the cost of carrying out all be used follows:
the cryptography associated with generating and checking digital
signatures might make the whole transaction uneconomic. Co-locating o trading roles are combined therefore changes to data made by the
trading roles, could help avoid this problem. consumer can be detected. One of the reasons for using signatures
is so that one trading role can determine if data has been changed
by the Consumer or some other party. However if the trading roles
have access to the necessary data, then it might be possible to
compare, for example, the payment information in the Payment
Request with the payment information in the Offer Response. Access
to the data necessary could be realised by, for example, the
Merchant and Payment Handler roles being carried out by the same
Organisation on the same system, or the Merchant and Payment
Handler roles being carried out on different systems but the
systems can communicate in some way. (Note this type of
communication is outside the current scope of IOTP)
o the processing cost of the cryptography is too high. For example,
if a payment is being made of only a few cents, the cost of
carrying out all the cryptography associated with generating and
checking digital signatures might make the whole transaction
uneconomic. Co-locating trading roles, could help avoid this
problem.
5.2 Symmetric and Asymmetric Cryptography 5.2 Symmetric and Asymmetric Cryptography
The advantage of using symmetric keys with IOTP is that no Public Key The advantage of using symmetric keys with IOTP is that no Public Key
Infrastructure need be set up and just the Merchant, Payment Handler and Infrastructure need be set up and just the Merchant, Payment Handler
Delivery Handler need to agree the shared secrets to use. and Delivery Handler need to agree on the shared secrets to use.
However the disadvantage of symmetric cryptography is that the Consumer However the disadvantage of symmetric cryptography is that the
cannot easily check the credentials of the Merchant, Payment Handler, Consumer cannot easily check the credentials of the Merchant, Payment
etc. that they are dealing with. This is likely to reduce, somewhat, the Handler, etc. that they are dealing with. This is likely to reduce,
trust that the Consumer will have carrying out the transaction. somewhat, the trust that the Consumer will have carrying out the
transaction.
However it should be noted that even if asymmetric cryptography is being However it should be noted that even if asymmetric cryptography is
used, the Consumer does not NEED to be provided with any digital being used, the Consumer does not NEED to be provided with any
certificates as the integrity of the transaction is determined by, for digital certificates as the integrity of the transaction is
example, the Payment Handler checking the Offer Response Signature copied determined by, for example, the Payment Handler checking the Offer
to the Payment Request. Response Signature copied to the Payment Request.
Note that symmetric, asymmetric or both types of cryptography may be used Note that symmetric, asymmetric or both types of cryptography may be
in a single transaction. used in a single transaction.
5.3 Data Privacy 5.3 Data Privacy
Privacy of information is provided by sending IOTP Messages between the Privacy of information is provided by sending IOTP Messages between
various Trading Roles using a secure channel such as [SSL/TLS]. Use of a the various Trading Roles using a secure channel such as [SSL/TLS].
secure channel within IOTP is optional. Use of a secure channel within IOTP is optional.
5.4 Payment Protocol Security 5.4 Payment Protocol Security
IOTP is designed to be completely blind to the payment protocol being IOTP is designed to be completely blind to the payment protocol being
used to effect a payment. From the security perspective, this means that used to effect a payment. From the security perspective, this means
IOTP neither helps, nor hinders, the achievement of payment security. that IOTP neither helps, nor hinders, the achievement of payment
security.
If it is necessary to consider payment security from an IOTP perspective, If it is necessary to consider payment security from an IOTP
then this should be included in the payment protocol supplement which perspective, then this should be included in the payment protocol
describes how IOTP supports that payment protocol. supplement which describes how IOTP supports that payment protocol.
However what IOTP is designed to do is to use digital signatures to bind However what IOTP is designed to do is to use digital signatures to
together the record, contained in a "response" message, of each trading bind together the record, contained in a "response" message, of each
exchange in a transaction. For example IOTP can bind together: an Offer, trading exchange in a transaction. For example IOTP can bind
a Payment and a Delivery. together: an Offer, a Payment and a Delivery.
6. Digital Signatures and IOTP 6. Digital Signatures and IOTP
IOTP can work successfully without using any digital signatures although IOTP can work successfully without using any digital signatures
in an open networking environment it will be less secure - see 5. although in an open networking environment it will be less secure -
Security Considerations for a description of the factors that need to be see 5. Security Considerations for a description of the factors that
considered. need to be considered.
However, this section describes how to use digital signatures in the many However, this section describes how to use digital signatures in the
situations when they will be needed. Topics covered are: many situations when they will be needed. Topics covered are:
o an overview of how IOTP uses digital signatures o an overview of how IOTP uses digital signatures
o how to check a signature is correctly calculated o how to check a signature is correctly calculated
o how Payment Handlers and Delivery Handlers check they can carry out o how Payment Handlers and Delivery Handlers check they can carry
payments or deliveries on behalf of a Merchant. out payments or deliveries on behalf of a Merchant.
6.1 How IOTP uses Digital Signatures 6.1 How IOTP uses Digital Signatures
In general, signatures when used with IOTP: In general, signatures when used with IOTP:
o are always treated as IOTP Components (see section 7) o are always treated as IOTP Components (see section 7)
o contain digests of one or more IOTP Components or Trading Blocks, o contain digests of one or more IOTP Components or Trading Blocks,
possibly including other Signature Components, in any IOTP message possibly including other Signature Components, in any IOTP message
within the same IOTP Transaction within the same IOTP Transaction
o identify: o identify:
- which Organisation signed (originated) the signature, and
- which Organisation(s) should process the signature in order to check
that the Action the Organisation should take can occur.
Digital certificates may be associated with digital signatures if - which Organisation signed (originated) the signature, and
asymmetric cryptography is being used. However if symmetric cryptography
is being used, then the digital certificate will be replaced by some
identifier of the secret key to use.
The way in which Signatures Components digest one or more elements is - which Organisation(s) should process the signature in order to
illustrated in the figure below. check that the Action the Organisation should take can occur.
Digital certificates may be associated with digital signatures if
asymmetric cryptography is being used. However if symmetric
cryptography is being used, then the digital certificate will be
replaced by some identifier of the secret key to use.
The way in which Signatures Components digest one or more elements is
illustrated in the figure below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE SIGNATURE COMPONENT IOTP MESSAGE SIGNATURE COMPONENT
IOTP Message Signature Id = P1.3 IOTP Message Signature Id = P1.3
|-Trans Ref Block digest TransRefBlk |-Manifest |-Trans Ref Block digest TransRefBlk |-Manifest
| | ID=P1.1-----------------------------|->|-Digest of P1.1-- | | ID=P1.1-----------------------------|->|-Digest of P1.1--
| |-Trans Id Comp digest TransIdComp | | | | |-Trans Id Comp digest TransIdComp | | |
| | ID = M1.2----------------------------|->|-Digest of M1.2--| | | ID = M1.2----------------------------|->|-Digest of M1.2--|
skipping to change at page 69, line 31 skipping to change at page 80, line 5
| |-Comp. ID=C1.5 | |-Comp. ID=C1.5
Digital signature of Manifest element Digital signature of Manifest element
using certificate identified by CertRef using certificate identified by CertRef
Elements that are digested can be in any IOTP Message Elements that are digested can be in any IOTP Message
within the same IOTP Transaction within the same IOTP Transaction
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 10 Signature Digests Figure 10 Signature Digests
[Note] The classic example of one signature signing another in IOTP, Note: The classic example of one signature signing another in IOTP,
is when an Offer is first signed by a Merchant creating an is when an Offer is first signed by a Merchant creating an "Offer
"Offer Response" signature, which is then later signed by a Response" signature, which is then later signed by a Payment Handler
Payment Handler together with a record of the payment creating together with a record of the payment creating a "Payment Receipt"
a "Payment Receipt" signature. In this way, the payment in an signature. In this way, the payment in an IOTP Transaction is bound
IOTP Transaction is bound to the Merchant's offer. to the Merchant's offer.
[Note End]
Note that one Manifest may be associated with multiple signature "Value" Note that one Manifest may be associated with multiple signature
elements where each Value element contains a digital signature over the "Value" elements where each Value element contains a digital
same Manifest, perhaps using the same (or different) signature algorithm signature over the same Manifest, perhaps using the same (or
but using a different certificate or shared secret key. Specifically it different) signature algorithm but using a different certificate or
will allow the Merchant to agree different shared secrets keys with their shared secret key. Specifically it will allow the Merchant to agree
Payment Handler and Delivery Handler. on different shared secrets keys with their Payment Handler and
Delivery Handler.
The detailed definitions of a Signature component are contained in The detailed definitions of a Signature component are contained in
section 7.19. section 7.19.
The remainder of this section contains: The remainder of this section contains:
o an example of how IOTP uses signatures o an example of how IOTP uses signatures
o how the OriginatorInfo and RecipientInfo elements within a Signature o how the OriginatorInfo and RecipientInfo elements within a
Component are used to identify the Organisations associated with the Signature Component are used to identify the Organisations
signature associated with the signature
o how IOTP uses signatures to prove actions complete successfully o how IOTP uses signatures to prove actions complete successfully
6.1.1 IOTP Signature Example 6.1.1 IOTP Signature Example
An example of how signatures are used is illustrated in the figure below An example of how signatures are used is illustrated in the figure
which shows how the various components and elements in a Baseline below which shows how the various components and elements in a
Purchase relate to one another. Refer to this example in the later Baseline Purchase relate to one another. Refer to this example in the
description of how signatures are used to check a payment or delivery can later description of how signatures are used to check a payment or
occur (see section 6.3). delivery can occur (see section 6.3).
[Note] A Baseline Purchase transaction has been used for illustration Note: A Baseline Purchase transaction has been used for illustration
purposes. The usage of the elements and attributes is the same purposes. The usage of the elements and attributes is the same for
for all types of IOTP Transactions. all types of IOTP Transactions.
[Note End]
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK
| (Offer Response) | (Offer Response)
Brand Selection Organisation<--- |------Signature Brand Selection Organisation<--- |------Signature
Component Component | | Component Component Component | | Component
| | | -Manifest | | | -Manifest
|BrandList -Trading Role | | |BrandList -Trading Role | |
| Ref Element | Originator |-Orig. | Ref Element | Originator |-Orig.
v (Merchant) ------------|--Info v (Merchant) ------------|--Info
Brand List Ref | Brand List Ref |
>Component | >Component |
| |-Protocol ------> Organisation Recipient |-Recipient | |-Protocol ------> Organisation Recipient |-Recipient
| | Amount Elem | Component <------------------|--Info | | Amount Elem | Component <------------------|--Info
| | | | | Refs | | | | | | Refs |
| |Pay|Protocol |Action -Trading Role | | |Pay|Protocol |Action -Trading Role |
| | | Ref |OrgRef Element | | | | Ref |OrgRef Element |
| | v | (Payment Handler) | | | v | (Payment Handler) |
| -PayProtocol-- | | -PayProtocol-- |
| Elem ->Organisation Recipient |-Recipient | Elem ->Organisation Recipient |-Recipient
| | Component <--------------------Info | | Component <--------------------Info
| | | Refs | | | Refs
| | -Trading Role | | -Trading Role
| | Element | | Element
| | (Delivery Handler | | (Delivery Handler
| |
| OFFER RESPONSE BLOCK | OFFER RESPONSE BLOCK
| | | |
|BrandListRef |ActionOrgRef |BrandListRef |ActionOrgRef
| | | |
--Payment ---Delivery --Payment ---Delivery
Component Component Component Component
The Manifest element in the Signature Component contains digests of: The Manifest element in the Signature Component contains digests of:
the Trans Ref Block (not shown); the Transaction ID Component (not the Trans Ref Block (not shown); the Transaction ID Component (not
shown); Organisation Components (Merchant, Payment Handler, Delivery shown); Organisation Components (Merchant, Payment Handler, Delivery
Handler); the Brand List Component; the Order Component, the Payment Handler); the Brand List Component; the Order Component, the Payment
Component the Delivery Component and the Brand Selection Component (if a Component the Delivery Component and the Brand Selection Component (if a
Brand Dependent Purchase). Brand Dependent Purchase).
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 11 Example use of Signatures for Baseline Purchase Figure 11 Example use of Signatures for Baseline Purchase
6.1.2 OriginatorInfo and RecipientInfo Elements 6.1.2 OriginatorInfo and RecipientInfo Elements
The OriginatorRef attribute of the OriginatorInfo element in the The OriginatorRef attribute of the OriginatorInfo element in the
Signature Component contains an Element Reference (see section 3.5) that Signature Component contains an Element Reference (see section 3.5)
points to the Organisation Component of the Organisation which generated that points to the Organisation Component of the Organisation which
the Signature. In this example its the Merchant. generated the Signature. In this example its the Merchant.
Note that the value of the content of the Attribute element with a Type Note that the value of the content of the Attribute element with a
attribute set to IOTP Signature Type must match the Trading Role of the Type attribute set to IOTP Signature Type must match the Trading Role
Organisation which signed it. If it does not, then it is an error. Valid of the Organisation which signed it. If it does not, then it is an
combinations are given in the table below. error. Valid combinations are given in the table below.
IOTP Signature Type Valid Trading Role IOTP Signature Type Valid Trading Role
OfferResponse Merchant OfferResponse Merchant
PaymentResponse PaymentHandler PaymentResponse PaymentHandler
DeliveryResponse DeliveryHandler DeliveryResponse DeliveryHandler
AuthenticationRequest any role AuthenticationRequest any role
AuthenticationResponse any role AuthenticationResponse any role
PingRequest any role PingRequest any role
PingResponse any role PingResponse any role
The RecipientRefs attribute of the RecipientInfo element in the Signature The RecipientRefs attribute of the RecipientInfo element in the
Component contains Element References to the Organisation Components of Signature Component contains Element References to the Organisation
the Organisations that should use the signature to verify that: Components of the Organisations that should use the signature to
verify that:
o they have a pre-existing relationship with the Organisation that o they have a pre-existing relationship with the Organisation that
generated the signature, generated the signature,
o the data which is secured by the signature has not been changed, o the data which is secured by the signature has not been changed,
o the data has been signed correctly, and o the data has been signed correctly, and
o the action they are required to undertake on behalf of the Merchant is o the action they are required to undertake on behalf of the
therefore authorised. Merchant is therefore authorised.
Note that if symmetric cryptography is being used then a separate Note that if symmetric cryptography is being used then a separate
RecipientInfo and Value elements for each different set of shared secret RecipientInfo and Value elements for each different set of shared
keys are likely within the Signature Component. secret keys are likely within the Signature Component.
Alternatively if asymmetric cryptography is being used then the Alternatively if asymmetric cryptography is being used then the
RecpientRefs attribute of one RecipientInfo element may refer to multiple RecpientRefs attribute of one RecipientInfo element may refer to
Organisation Components if they are all using the same certificates. multiple Organisation Components if they are all using the same
certificates.
6.1.3 Using signatures to Prove Actions Complete Successfully 6.1.3 Using signatures to Prove Actions Complete Successfully
Proving an action completed successfully, is achieved by signing data on Proving an action completed successfully, is achieved by signing data
Response messages. Specifically: on Response messages. Specifically:
o on the Offer Response, when a Merchant is making an Offer to the o on the Offer Response, when a Merchant is making an Offer to the
Consumer which can then be sent to either: Consumer which can then be sent to either:
- a Payment Handler to prove that the Merchant authorises Payment, or
- a Delivery Handler to prove that Merchant authorises Delivery,
provided other necessary authorisations are complete (see below)
o on the Payment Response, when a Payment Handler is generating a Payment - a Payment Handler to prove that the Merchant authorises
Receipt which can be sent to either: Payment, or
- a Delivery Handler, in a Delivery Request Block to authorise Delivery
together with the Offer Response signature, or
- another Payment Handler, in a second Payment Request, to authorise
the second payment in a Value Exchange IOTP Transaction
o Delivery Response, when a Delivery Handler is generating a Delivery - a Delivery Handler to prove that Merchant authorises Delivery,
Note. This can be used to prove after the event what the Delivery provided other necessary authorisations are complete (see