draft-ietf-trade-iotp-v1.0-protocol-03.txt   draft-ietf-trade-iotp-v1.0-protocol-04.txt 
TRADE Working Group David Burdett TRADE Working Group David Burdett
Internet Draft Mondex International Internet Draft Mondex International
draft-ietf-trade-iotp-v1.0-protocol-03.txt draft-ietf-trade-iotp-v1.0-protocol-04.txt
Expires: 28 August 1999 Expires: 13 February 2000 12 August 1999
Internet Open Trading Protocol - IOTP Internet Open Trading Protocol - IOTP
Version 1.0 Version 1.0
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 5 skipping to change at page 2, line ?
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com >, which may the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf- be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>. trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at Discussions of the TRADE working group are archived at
http://www.elistx.com/archives/ietf-trade. http://www.elistx.com/archives/ietf-trade.
David Burdett et al.
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, Mondex, CyberCash, DigiCash, encapsulates payment systems such as SET, Secure Channel Credit/Debit,
GeldKarte, etc. IOTP is able to handle cases where such merchant roles Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where
as the shopping site, the payment handler, the Delivery Handler of such merchant roles as the shopping site, the Payment Handler, the
goods or services, and the provider of customer support are performed Delivery Handler of goods or services, and the provider of customer
by different parties or by one party. support are performed by different parties or by one party.
This document obsoletes the previous version of the IOTP specification
(draft-ietf-trade-iotp-v1.0-protocol-03.txt.)
Table of Contents Table of Contents
Status of this Memo..................................................2 Status of this Memo..................................................1
Abstract.............................................................3 Abstract.............................................................2
1. Background.......................................................10 1. Background........................................................9
1.1 Commerce on the Internet _ a Different Model.................11 1.1 Commerce on the Internet, a Different Model..................10
1.2 Benefits of IOTP.............................................12 1.2 Benefits of IOTP.............................................11
1.3 Baseline IOTP................................................13 1.3 Baseline IOTP................................................12
1.4 Objectives of Document.......................................14 1.4 Objectives of Document.......................................13
1.5 Purpose......................................................14 1.5 Scope of Document............................................13
1.6 Scope of Document............................................14 1.6 Document Structure...........................................14
1.7 Document Structure...........................................15 1.7 Intended Readership..........................................16
1.8 Intended Readership..........................................16 1.7.1 Reading Guidelines ......................................16
1.8.1 Reading Guidelines ......................................17
1.9 History......................................................17
2. Introduction.....................................................19 2. Introduction.....................................................18
2.1 Trading Roles................................................20 2.1 Trading Roles................................................19
2.2 Trading Exchanges............................................21 2.2 Trading Exchanges............................................20
2.2.1 Offer Exchange ..........................................23 2.2.1 Offer Exchange ..........................................21
2.2.2 Payment Exchange ........................................25 2.2.2 Payment Exchange ........................................23
2.2.3 Delivery Exchange .......................................29 2.2.3 Delivery Exchange .......................................26
2.2.4 Authentication Exchange .................................31 2.2.4 Authentication Exchange .................................28
2.3 Scope of Baseline IOTP.......................................33 2.3 Scope of Baseline IOTP.......................................30
3. Protocol Structure...............................................38 3. Protocol Structure...............................................34
3.1 Overview.....................................................40 3.1 Overview.....................................................35
3.1.1 IOTP Message Structure ..................................40 3.1.1 IOTP Message Structure ..................................35
3.1.2 IOTP Transactions .......................................42 3.1.2 IOTP Transactions .......................................36
3.2 IOTP Message.................................................43 3.2 IOTP Message.................................................37
3.2.1 XML Document Prolog .....................................45 3.2.1 XML Document Prolog .....................................39
3.3 Transaction Reference Block..................................45 3.3 Transaction Reference Block..................................39
3.3.1 Transaction Id Component ................................46 3.3.1 Transaction Id Component ................................40
3.3.2 Message Id Component ....................................48 3.3.2 Message Id Component ....................................42
3.3.3 Related To Component ....................................49 3.3.3 Related To Component ....................................43
3.4 ID Attributes................................................51 3.4 ID Attributes................................................44
3.4.1 IOTP Message ID Attribute Definition ....................52 3.4.1 IOTP Message ID Attribute Definition ....................46
3.4.2 Block and Component ID Attribute Definitions ............53 3.4.2 Block and Component ID Attribute Definitions ............47
3.4.3 Example of use of ID Attributes .........................54 3.4.3 Example of use of ID Attributes .........................48
3.5 Element References...........................................55 3.5 Element References...........................................48
3.6 Brands and Brand Selection...................................56 3.6 Extending IOTP...............................................50
3.6.1 Definition of Payment Instrument ........................57 3.6.1 Extra XML Elements ......................................50
3.6.2 Definition of Brand .....................................58 3.6.2 Opaque Embedded Data ....................................51
3.6.3 Definition of Dual Brand ................................58 3.7 Packaged Content Element.....................................52
3.6.4 Definition of Promotional Brand .........................59 3.7.1 Packaging HTML ..........................................54
3.6.5 Identifying Promotional Brands ..........................59 3.7.2 Packaging XML ...........................................54
3.7 Extending IOTP...............................................62 3.8 Identifying Languages........................................55
3.7.1 Extra XML Elements ......................................62 3.9 Secure and Insecure Net Locations............................55
3.7.2 Opaque Embedded Data ....................................63 3.10 Cancelled Transactions......................................56
3.7.3 Values for IOTP Codes ...................................63 3.10.1 Cancelling Transactions ................................56
3.8 Packaged Content Element.....................................66 3.10.2 Handling Cancelled Transactions ........................57
3.8.1 Packaging HTML ..........................................68
3.9 Identifying Languages........................................69
3.10 Secure and Insecure Net Locations...........................70
3.11 Cancelled Transactions......................................70
3.11.1 Cancelling Transactions ................................70
3.11.2 Handling Cancelled Transactions ........................71
4. IOTP Error Handling..............................................73 4. IOTP Error Handling..............................................58
4.1 Technical Errors.............................................73 4.1 Technical Errors.............................................58
4.2 Business Errors..............................................74 4.2 Business Errors..............................................59
4.3 Error Depth..................................................74 4.3 Error Depth..................................................59
4.3.1 Transport Level .........................................75 4.3.1 Transport Level .........................................59
4.3.2 Message Level ...........................................75 4.3.2 Message Level ...........................................60
4.3.3 Block Level .............................................76 4.3.3 Block Level .............................................61
4.4 Idempotency, Processing Sequence, and Message Flow...........78 4.4 Idempotency, Processing Sequence, and Message Flow...........63
4.4.1 Server Role Processing Sequence .........................78 4.5 Server Role Processing Sequence..............................63
4.4.2 Client Role Processing Sequence .........................84 4.5.1 Initiating Transactions .................................64
4.5.2 Processing Input Messages ...............................64
4.5.3 Cancelling a Transaction ................................70
4.5.4 Retransmitting Messages .................................71
4.6 Client Role Processing Sequence..............................71
4.6.1 Initiating Transactions .................................72
4.6.2 Processing Input Messages ...............................72
4.6.3 Cancelling a Transaction ................................74
4.6.4 Retransmitting Messages .................................74
5. Security Considerations..........................................90 5. Security Considerations..........................................75
5.1 Digital Signatures and IOTP..................................90 5.1 Determining whether to use digital signatures................75
5.1.1 IOTP Signature Example ..................................92 5.2 Symmetric and Asymmetric Cryptography........................77
5.1.2 OriginatorInfo and RecipientInfo Elements ...............94 5.3 Data Privacy.................................................77
5.1.3 Symmetric and Asymmetric Cryptography ...................95 5.4 Payment Protocol Security....................................77
5.1.4 Mandatory and Optional Signatures .......................95
5.1.5 Using signatures to Prove Actions Complete Successfully .95
5.2 Checking a Signature is Correctly Calculated.................96
5.3 Checking a Payment or Delivery can occur.....................97
5.3.1 Check the Action Request was sent to the Correct
Organisation ..................................................99
5.3.2 Check the Correct Components are present in the Request
Block ........................................................103
5.3.3 Check an Action is Authorised ..........................103
5.4 Data Integrity and Privacy..................................105
6. Trading Components..............................................106 6. Digital Signatures and IOTP......................................79
6.1 Protocol Options Component..................................108 6.1 How IOTP uses Digital Signatures.............................79
6.2 Authentication Data Component...............................110 6.1.1 IOTP Signature Example ..................................81
6.3 Authentication Response Component...........................112 6.1.2 OriginatorInfo and RecipientInfo Elements ...............82
6.4 Order Component.............................................113 6.1.3 Using signatures to Prove Actions Complete Successfully .83
6.4.1 Order Description Content ..............................115 6.2 Checking a Signature is Correctly Calculated.................84
6.4.2 OkFrom and OkTo Timestamps .............................115 6.3 Checking a Payment or Delivery can occur.....................85
6.5 Organisation Component......................................116 6.3.1 Check the Request Block was sent to the Correct
6.5.2 Trading Role Element ...................................119 Organisation ..................................................86
6.5.3 Contact Information Element ............................122 6.3.2 Check the Correct Components are present in the Request
6.5.4 Person Name Element ....................................123 Block .........................................................89
6.5.5 Postal Address Element .................................124 6.3.3 Check an Action is Authorised ...........................89
6.6 Brand List Component........................................125
6.6.1 Brand Element ..........................................127
6.6.2 Protocol Amount Element ................................130
6.6.3 Currency Amount Element ................................132
6.6.4 Pay Protocol Element ...................................133
6.7 Brand Selection Component...................................135
6.7.1 Brand Selection Brand Info Element .....................137
6.7.2 Brand Selection Protocol Amount Info Element ...........138
6.7.3 Brand Selection Currency Amount Info Element ...........138
6.8 Payment Component...........................................139
6.9 Payment Scheme Component....................................141
6.10 Payment Receipt Component..................................142
6.11 Payment Note Component.....................................144
6.12 Delivery Component.........................................145
6.12.1 Delivery Data Element .................................147
6.13 Delivery Note Component....................................149
6.14 Status Component...........................................151
6.14.1 Offer Completion Codes ................................154
6.14.2 Payment Completion Codes ..............................154
6.14.3 Delivery Completion Codes .............................155
6.14.4 Authentication Completion Codes .......................157
6.15 Trading Role Data Component................................158
6.15.1 Who Receives a Trading Role Data Component ............159
6.16 Inquiry Type Component.....................................159
6.17 Signature Component........................................160
6.17.1 IOTP usage of signature elements and attributes .......164
6.17.2 Offer Response Signature Component ....................166
6.17.3 Payment Receipt Signature Component ...................167
6.17.4 Delivery Response Signature Component .................168
6.17.5 Authentication Request Signature Component ............168
6.17.6 Authentication Response Signature Component ...........168
6.17.7 Ping Request Signature Component ......................169
6.17.8 Ping Response Signature Component .....................169
6.18 Certificate Component......................................169
6.18.1 IOTP usage of signature elements and attributes .......170
6.19 Error Component............................................170
6.19.1 Error Processing Guidelines ...........................173
6.19.2 Error Codes ...........................................174
6.19.3 Error Location Element ................................178
7. Trading Blocks..................................................180 7. Trading Components...............................................92
7.1 Trading Protocol Options Block..............................183 7.1 Protocol Options Component...................................94
7.2 TPO Selection Block.........................................184 7.2 Authentication Request Component.............................95
7.3 Offer Response Block........................................185 7.3 Authentication Response Component............................96
7.4 Authentication Request Block................................186 7.4 Trading Role Information Request Component...................97
7.5 Authentication Response Block...............................187 7.5 Order Component..............................................98
7.6 Authentication Status Block.................................187 7.5.1 Order Description Content ...............................99
7.7 Payment Request Block.......................................188 7.5.2 OkFrom and OkTo Timestamps ..............................99
7.8 Payment Exchange Block......................................190 7.6 Organisation Component......................................100
7.9 Payment Response Block......................................190 7.6.2 Trading Role Element ...................................103
7.10 Delivery Request Block.....................................191 7.6.3 Contact Information Element ............................106
7.11 Delivery Response Block....................................193 7.6.4 Person Name Element ....................................107
7.12 Inquiry Request Trading Block..............................194 7.6.5 Postal Address Element .................................108
7.13 Inquiry Response Trading Block.............................194 7.7 Brand List Component........................................109
7.14 Ping Request Block.........................................195 7.7.1 Brand Element ..........................................111
7.15 Ping Response Block........................................196 7.7.2 Protocol Brand Element .................................113
7.16 Signature Block............................................198 7.7.3 Protocol Amount Element ................................114
7.16.1 Offer Response ........................................199 7.7.4 Currency Amount Element ................................115
7.16.2 Payment Request .......................................199 7.7.5 Pay Protocol Element ...................................116
7.16.3 Payment Response ......................................199 7.8 Brand Selection Component...................................118
7.16.4 Delivery Request ......................................199 7.8.1 Brand Selection Brand Info Element .....................119
7.17 Error Block................................................199 7.8.2 Brand Selection Protocol Amount Info Element ...........120
7.18 Cancel Block...............................................201 7.8.3 Brand Selection Currency Amount Info Element ...........120
7.9 Payment Component...........................................121
7.10 Payment Scheme Component...................................122
7.11 Payment Receipt Component..................................123
7.12 Payment Note Component.....................................125
7.13 Delivery Component.........................................126
7.13.1 Delivery Data Element .................................128
7.14 Delivery Note Component....................................130
7.15 Status Component...........................................131
7.15.1 Offer Completion Codes ................................133
7.15.2 Payment Completion Codes ..............................135
7.15.3 Delivery Completion Codes .............................137
7.15.4 Authentication Completion Codes .......................139
7.15.5 Undefined Completion Codes ............................140
7.15.6 Transaction Inquiry Completion Codes ..................141
7.16 Trading Role Data Component................................141
7.16.1 Who Receives a Trading Role Data Component ............142
7.17 Inquiry Type Component.....................................143
7.18 Signature Component........................................143
7.18.1 IOTP usage of signature elements and attributes .......145
7.18.2 Offer Response Signature Component ....................148
7.18.3 Payment Receipt Signature Component ...................149
7.18.4 Delivery Response Signature Component .................149
7.18.5 Authentication Request Signature Component ............150
7.18.6 Authentication Response Signature Component ...........150
7.18.7 Ping Request Signature Component ......................151
7.18.8 Ping Response Signature Component .....................151
7.19 Certificate Component......................................151
7.19.1 IOTP usage of signature elements and attributes .......152
7.20 Error Component............................................152
7.20.1 Error Processing Guidelines ...........................154
7.20.2 Error Codes ...........................................156
7.20.3 Error Location Element ................................159
8. Internet Open Trading Protocol Transactions.....................202 8. Trading Blocks..................................................161
8.1 Authentication and Payment Related IOTP Transactions........202 8.1 Trading Protocol Options Block..............................163
8.1.1 Authentication Document Exchange .......................205 8.2 TPO Selection Block.........................................164
8.1.2 Offer Document Exchange ................................212 8.3 Offer Response Block........................................165
8.1.3 Payment Document Exchange ..............................222 8.4 Authentication Request Block................................166
8.1.4 Delivery Document Exchange .............................228 8.5 Authentication Response Block...............................167
8.1.5 Payment and Delivery Document Exchange .................231 8.6 Authentication Status Block.................................168
8.1.6 Baseline Authentication IOTP Transaction ...............234 8.7 Payment Request Block.......................................169
8.1.7 Baseline Deposit IOTP Transaction ......................236 8.8 Payment Exchange Block......................................170
8.1.8 Baseline Purchase IOTP Transaction .....................238 8.9 Payment Response Block......................................171
8.1.9 Baseline Refund IOTP Transaction .......................240 8.10 Delivery Request Block.....................................172
8.1.10 Baseline Withdrawal IOTP Transaction ..................242 8.11 Delivery Response Block....................................173
8.1.11 Baseline Value Exchange IOTP Transaction ..............244 8.12 Inquiry Request Trading Block..............................174
8.1.12 Valid Combinations of Document Exchanges ..............248 8.13 Inquiry Response Trading Block.............................175
8.1.13 Combining Authentication Transactions with other 8.14 Ping Request Block.........................................176
Transactions .................................................252 8.15 Ping Response Block........................................177
8.2 Infrastructure Transactions.................................253 8.16 Signature Block............................................179
8.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...254 8.16.1 Signature Block with Offer Response ...................179
8.2.2 Baseline Ping IOTP Transaction .........................258 8.16.2 Signature Block with Payment Request ..................179
8.16.3 Signature Block with Payment Response .................180
8.16.4 Signature Block with Delivery Request .................180
8.16.5 Signature Block with Delivery Response ................180
8.17 Error Block................................................180
8.18 Cancel Block...............................................181
9. Retrieving Logos................................................262 9. Internet Open Trading Protocol Transactions.....................183
9.1 Logo Size...................................................262 9.1 Authentication and Payment Related IOTP Transactions........183
9.2 Logo Color Depth............................................263 9.1.1 Authentication Document Exchange .......................185
9.3 Logo Net Location Examples..................................263 9.1.2 Offer Document Exchange ................................191
10. Brand List Examples............................................265 9.1.3 Payment Document Exchange ..............................199
10.1 Simple Credit Card Based Example...........................265 9.1.4 Delivery Document Exchange .............................205
10.2 Credit Card Brand List Including Promotional Brands........266 9.1.5 Payment and Delivery Document Exchange .................207
10.3 Brand Selection Example....................................269 9.1.6 Baseline Authentication IOTP Transaction ...............211
10.4 Complex Electronic Cash Based Brand List...................269 9.1.7 Baseline Deposit IOTP Transaction ......................212
9.1.8 Baseline Purchase IOTP Transaction .....................214
9.1.9 Baseline Refund IOTP Transaction .......................215
9.1.10 Baseline Withdrawal IOTP Transaction ..................217
9.1.11 Baseline Value Exchange IOTP Transaction ..............219
9.1.12 Valid Combinations of Document Exchanges ..............222
9.1.13 Combining Authentication Transactions with other
Transactions .................................................225
9.2 Infrastructure Transactions.................................227
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...227
9.2.2 Baseline Ping IOTP Transaction .........................231
11. Open Trading Protocol Data Type Definition.....................274 10. Retrieving Logos...............................................235
10.1 Logo Size..................................................235
10.2 Logo Color Depth...........................................236
10.3 Logo Net Location Examples.................................236
12. Glossary.......................................................289 11. Brands.........................................................237
11.1 Brand Definitions and Brand Selection......................237
11.1.1 Definition of Payment Instrument ......................237
11.1.2 Definition of Brand ...................................238
11.1.3 Definition of Dual Brand ..............................238
11.1.4 Definition of Promotional Brand .......................239
11.1.5 Identifying Promotional Brands ........................239
11.2 Brand List Examples........................................242
11.2.1 Simple Credit Card Based Example ......................242
11.2.2 Credit Card Brand List Including Promotional Brands ...243
11.2.3 Brand Selection Example ...............................246
11.2.4 Complex Electronic Cash Based Brand List ..............246
13. Copyrights.....................................................298 12. IANA Considerations............................................251
12.1 Codes Controlled by IANA...................................251
12.2 Codes not controlled by IANA...............................256
14. References.....................................................299 13. Internet Open Trading Protocol Data Type Definition............257
15. Author's Address...............................................303 14. Glossary.......................................................272
15. Copyrights.....................................................282
16. References.....................................................283
17. Author's Address...............................................286
Table of Figures Table of Figures
Figure 1 IOTP Trading Roles ........................................20 Figure 1 IOTP Trading Roles ........................................19
Figure 2 Offer Exchange ............................................23 Figure 2 Offer Exchange ............................................22
Figure 3 Payment Exchange ..........................................26 Figure 3 Payment Exchange ..........................................25
Figure 4 Delivery Exchange .........................................30 Figure 4 Delivery Exchange .........................................27
Figure 5 Authentication Exchange ...................................33 Figure 5 Authentication Exchange ...................................29
Figure 6 IOTP Message Structure ....................................41 Figure 6 IOTP Message Structure ....................................35
Figure 7 An IOTP Transaction .......................................42 Figure 7 An IOTP Transaction .......................................37
Figure 8 Example use of ID attributes ..............................54 Figure 8 Example use of ID attributes ..............................48
Figure 9 Element References ........................................56 Figure 9 Element References ........................................50
Figure 10 Server Role Processing Sequence ..........................80 Figure 10 Signature Digests ........................................80
Figure 11 Client Role Processing Sequence ..........................86 Figure 11 Example use of Signatures for Baseline Purchase ..........82
Figure 12 Signature Digests ........................................91 Figure 12 Checking a Payment Handler can carry out a Payment .......87
Figure 13 Example use of Signatures for Baseline Purchase ..........93 Figure 13 Checking a Delivery Handler can carry out a Delivery .....89
Figure 14 Checking a Payment Handler can carry out a Payment ......100 Figure 14 Trading Components .......................................93
Figure 15 Checking a Delivery Handler can carry out a Delivery ....102 Figure 15 Brand List Element Relationships ........................111
Figure 16 Trading Components ......................................107 Figure 16 Trading Blocks ..........................................162
Figure 17 Brand List Element Relationships ........................127 Figure 17 Payment and Authentication Message Flow Combinations ....185
Figure 18 Trading Blocks ..........................................181 Figure 18 Authentication Document Exchange ........................187
Figure 19 Payment and Authentication Message Flow Combinations ....204 Figure 19 Brand Dependent Offer Document Exchange .................193
Figure 20 Authentication Document Exchange ........................208 Figure 20 Brand Independent Offer Exchange ........................195
Figure 21 Brand Dependent Offer Document Exchange .................214 Figure 21 Payment Document Exchange ...............................200
Figure 22 Brand Independent Offer Exchange ........................217 Figure 22 Delivery Document Exchange ..............................206
Figure 23 Payment Document Exchange ...............................224 Figure 23 Payment and Delivery Document Exchange ..................209
Figure 24 Delivery Document Exchange ..............................229 Figure 24 Baseline Authentication IOTP Transaction ................212
Figure 25 Payment and Delivery Document Exchange ..................232 Figure 25 Baseline Deposit IOTP Transaction .......................213
Figure 26 Baseline Authentication IOTP Transaction ................235 Figure 26 Baseline Purchase IOTP Transaction ......................215
Figure 27 Baseline Deposit IOTP Transaction .......................237 Figure 27 Baseline Refund IOTP Transaction ........................217
Figure 28 Baseline Purchase IOTP Transaction ......................239 Figure 28 Baseline Withdrawal IOTP Transaction ....................219
Figure 29 Baseline Refund IOTP Transaction ........................241 Figure 29 Baseline Value Exchange IOTP Transaction ................221
Figure 30 Baseline Withdrawal IOTP Transaction ....................243 Figure 30 Baseline Value Exchange Signatures ......................222
Figure 31 Baseline Value Exchange IOTP Transaction ................246 Figure 31 Valid Combinations of Document Exchanges ................223
Figure 32 Baseline Value Exchange Signatures ......................247 Figure 32 Baseline Transaction Status Inquiry .....................230
Figure 33 Valid Combinations of Document Exchanges ................250 Figure 33 Baseline Ping Messages ..................................232
Figure 34 Baseline Transaction Status Inquiry .....................257
Figure 35 Baseline Ping Messages ..................................259
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, DigiCash,
GeldKarte, etc. IOTP is able to handle cases where such merchant roles GeldKarte, etc. IOTP is able to handle cases where such merchant roles
as the shopping site, the payment handler, the Delivery Handler of as the shopping site, the Payment Handler, the Delivery Handler of
goods or services, and the provider of customer support are performed goods or services, and the provider of customer support are performed
by different parties or by one party. by different parties or by one party.
The developers of IOTP seek to provide a virtual capability that The developers of IOTP seek to provide a virtual capability that
safely replicates the real world, the paper based, traditional, safely replicates the real world, the paper based, traditional,
understood, accepted methods of trading, buying, selling, value understood, accepted methods of trading, buying, selling, value
exchanging that has existed for many hundreds of years. The exchanging that has existed for many hundreds of years. The
negotiation of who will be the parties to the trade, how it will be negotiation of who will be the parties to the trade, how it will be
conducted, the presentment of an offer, the method of payment, the conducted, the presentment of an offer, the method of payment, the
provision of a payment receipt, the delivery of goods and the receipt provision of a payment receipt, the delivery of goods and the receipt
skipping to change at page 11, line 5 skipping to change at page 10, line 5
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 bringing about enormous changes around the world in society, politics
and 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 taking place in the way consumers and merchants trade. Characteristics
of trading that have changed markedly include: of trading that have changed markedly include:
o Presence: Face-to-face transactions become the exception, not o Presence: Face-to-face transactions become the exception,
the rule. Already with the rise of mail order and telephone not the rule. Already with the rise of mail order and
order placement this change has been felt in western commerce. telephone order placement this change has been felt in
Electronic commerce over the Internet will further expand the western commerce. Electronic commerce over the Internet
scope and volume of transactions conducted without ever seeing will further expand the scope and volume of transactions
the people who are a part of the enterprise with whom one does conducted without ever seeing the people who are a part of
business. the enterprise with whom one does business.
o Authentication: An important part of personal presence is the o Authentication: An important part of personal presence is
ability of the parties to use familiar objects and dialogue to the ability of the parties to use familiar objects and
confirm they are who they claim to be. The seller displays one dialogue to confirm they are who they claim to be. The
or several well known financial logos that declaim his ability seller displays one or several well known financial logos
to accept widely used credit and debit instruments in the that declaim his ability to accept widely used credit and
payment part of a purchase. The buyer brings government or debit instruments in the payment part of a purchase. The
financial institution identification that assures the seller buyer brings government or financial institution
she will be paid. People use intangibles such as personal identification that assures the seller she will be paid.
appearance and conduct, location of the store, apparent quality People use intangibles such as personal appearance and
and familiarity with brands of merchandise, and a good clear conduct, location of the store, apparent quality and
look in the eye to reinforce formal means of authentication. familiarity with brands of merchandise, and a good clear
look in the eye to reinforce formal means of
authentication.
o Payment Instruments: Despite the enormous size of bank card o Payment Instruments: Despite the enormous size of bank card
financial payments associations and their members, most of the financial payments associations and their members, most of
world's trade still takes place using the coin of the realm or the world's trade still takes place using the coin of the
barter. The present infrastructure of the payments business realm or barter. The present infrastructure of the payments
cannot economically support low value transactions and could business cannot economically support low value transactions
not survive under the consequent volumes of transactions if it and could not survive under the consequent volumes of
did accept low value transactions. transactions if it did accept low value transactions.
o Transaction Values: New meaning for low value transactions o Transaction Values: New meaning for low value transactions
arises in the Internet where sellers may wish to offer for arises in the Internet where sellers may wish to offer for
example, pages of information for fractions of currency that do example, pages of information for fractions of currency
not exist in the real world. that do not exist in the real world.
o Delivery: New modes of delivery must be accommodated such as o Delivery: New modes of delivery must be accommodated such
direct electronic delivery. The means by which receipt is as direct electronic delivery. The means by which receipt
confirmed and the execution of payment change dramatically is confirmed and the execution of payment change
where the goods or services have extremely low delivery cost dramatically where the goods or services have extremely low
but may in fact have very high value. Or, maybe the value is delivery cost but may in fact have very high value. Or,
not high, but once delivery occurs the value is irretrievably maybe the value is not high, but once delivery occurs the
delivered so payment must be final and non-refundable but value is irretrievably delivered so payment must be final
delivery nonetheless must still be confirmed before payment. and non-refundable but delivery nonetheless must still be
Incremental delivery such as listening or viewing time or confirmed before payment. Incremental delivery such as
playing time are other models that operate somewhat differently listening or viewing time or playing time are other models
in the virtual world. that 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- Electronic Commerce Software Vendors will be able to develop e-
commerce products which are more attractive as they will inter-operate commerce products which are more attractive as they will inter-operate
with any other vendors' software. However since IOTP focuses on how with any other vendors' software. However since IOTP focuses on how
these solutions communicate, there is still plenty of opportunity for these solutions communicate, there is still plenty of opportunity for
product differentiation. product differentiation.
skipping to change at page 12, line 36 skipping to change at page 11, line 39
IOTP provides a standard framework for encapsulating payment IOTP provides a standard framework for encapsulating payment
protocols. This means that it is easier for payment products to be protocols. This means that it is easier for payment products to be
incorporated into IOTP solutions. As a result the payment brands will incorporated into IOTP solutions. As a result the payment brands will
be more widely distributed and available on a wider variety of be more widely distributed and available on a wider variety of
platforms. 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 o they can be more certain that the customer will have the
software needed to complete the purchase software needed to complete the purchase
o through receiving payment and delivery receipts from their o through receiving payment and delivery receipts from their
customers, they will be able to provide customer care knowing customers, they will be able to provide customer care
that they are dealing with the individual or organisation with knowing that they are dealing with the individual or
which they originally traded organisation with which they originally traded
o new merchants will be able to enter this new (Internet)
market-place with new products and services, using the new
trading opportunities which IOTP presents
o new merchants will be able to enter this new (Internet) market-
place with new products and services, using the new trading
opportunities which IOTP presents
BANKS AND FINANCIAL INSTITUTIONS 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 - providing customer care for merchants
- fees from processing new payments and deposits - fees from processing new payments and deposits
o they have an opportunity to build relationships with new types o they have an opportunity to build relationships with new
of merchants types of merchants
CUSTOMERS CUSTOMERS
For Customers there are several benefits: For Customers there are several benefits:
o they will have a larger selection of merchants with whom they o they will have a larger selection of merchants with whom
can trade they can trade
o there is a more consistent interface when making the purchase o there is a more consistent interface when making the
purchase
o there are ways in which they can get their problems fixed o there are ways in which they can get their problems fixed
through the merchant (rather than the bank!) through the merchant (rather than the bank!)
o there is a record of their transaction which can be used, for o there is a record of their transaction which can be used,
example, to feed into accounting systems or, potentially, to for example, to feed into accounting systems or,
present to the tax authorities 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 This specification is Baseline IOTP. It is a Baseline in that it
contains ways of doing trades on the Internet which are the most contains ways of doing trades on the Internet which are the most
common. The team working on the IOTP see an extended versions of this common. The team working on the IOTP see an extended version of this
specification being developed as needs demand but at this stage feel a specification being developed as needs demand but at this stage feel a
need to develop a limited function but usable specification in order need to develop a limited function but usable specification in order
that technology providers can develop pathway-pilot products that will that technology providers can develop pathway-pilot products that will
be placed in the market in order to understand the real _market place_ be placed in the market in order to understand the real "market place"
demands and requirements for electronic trading or electronic demands and requirements for electronic trading or electronic
commerce. To proceed otherwise would be presumptuous, time consuming, commerce.
expensive and foolish.
Accordingly the IOTP Baseline specification has been produced for Accordingly the IOTP Baseline specification has been produced for
pathway-pilot product development, expecting to transact live trades pathway-pilot product development, expecting to transact live trades
to prove the interoperability of solutions based on this specification to prove the interoperability of solutions based on this
by end '98. specification.
During this period it is anticipated that there will be no changes to During this period it is anticipated that there will be no changes to
the scope of this specification with the only changes made being the scope of this specification with the only changes made being
limited to corrections where problems are found. Software solutions limited to corrections where problems are found. Software solutions
have been developed based on earlier versions of this specification have been developed based on earlier versions of this specification
which prove that the basic concepts work. (for example version 0.9 published in early 1998) which prove that the
basic concepts work.
1.4 Objectives of Document 1.4 Objectives of Document
The objectives of this document are to provide a functional The objectives of this document are to provide a functional
specification of version 1.0 of the Open Trading Protocols which can specification of version 1.0 of the Internet Open Trading Protocols
be used to design and implement systems which support electronic which can be used to design and implement systems which support
trading on the Internet using the Open Trading Protocols. electronic trading on the Internet using the Internet Open Trading
Protocols.
An overview of IOTP is provided the IOTP Business Description which
explains the Business Requirements for IOTP.
1.5 Purpose
The purpose of the document is: The purpose of the document is:
o to allow potential developers of products based on the protocol o to allow potential developers of products based on the
to start development of software/hardware solutions which use protocol to start development of software/hardware
the protocol solutions which use the protocol
o to allow the financial services industry to understand a o to allow the financial services industry to understand a
developing electronic commerce trading protocol that developing electronic commerce trading protocol that
encapsulates (without modification) any of the current or encapsulates (without modification) any of the current or
developing payment schemes now being used or considered by developing payment schemes now being used or considered by
their merchant customer base their merchant customer base
1.6 Scope of Document 1.5 Scope of Document
The protocol describes the content, format and sequences of messages The protocol describes the content, format and sequences of messages
that pass among the participants in an electronic trade - consumers, that pass among the participants in an electronic trade - consumers,
merchants and banks or other financial institutions, and customer care merchants and banks or other financial institutions, and customer care
providers. These are required to support the electronic commerce providers. These are required to support the electronic commerce
transactions outlined in the objectives above. 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 scheme since it targets the complete purchase process where the
movement of electronic value from the payer to the payee is only one, movement of electronic value from the payer to the payee is only one,
skipping to change at page 15, line 27 skipping to change at page 14, line 23
in a set of payment scheme supplements to this specification. in a set of payment scheme supplements to this specification.
The document does not prescribe the software and processes that will The document does not prescribe the software and processes that will
need to be implemented by each participant. It does describe the need to be implemented by each participant. It does describe the
framework 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 surrounding the implementation of the protocol or the information
systems which use them. systems which use them.
1.7 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 o Section 1 - Background: This section gives a brief
on electronic commerce and the benefits IOTP offers. background on electronic commerce and the benefits IOTP
offers.
o Section 2 - Introduction: This section describes the various o Section 2 - Introduction: This section describes the
Trading Exchanges and shows how these trading exchanges are various Trading Exchanges and shows how these trading
used to construct the IOTP Transactions. This section also exchanges are used to construct the IOTP Transactions. This
explains various Trading Roles that would participate in section also explains various Trading Roles that would
electronic trade. participate in electronic trade.
o Section 3 - Protocol Structure: This section summarises how o Section 3 - Protocol Structure: This section summarises how
various IOTP transactions are constructed using the Trading various IOTP transactions are constructed using the Trading
Blocks and Trading Components that are the fundamental building Blocks and Trading Components that are the fundamental
blocks for IOTP transactions. All IOTP transaction messages are building blocks for IOTP transactions. All IOTP transaction
well formed XML documents. messages are well formed XML documents.
o Section 4 - IOTP Error Handling: This section describes how to o Section 4 - IOTP Error Handling: This section describes how
process exceptions and errors during the protocol message to process exceptions and errors during the protocol
exchange and trading exchange processing. This section provides message exchange and trading exchange processing. This
a generic overview of the exception handling. This section section provides a generic overview of the exception
should be read carefully. handling. This section should be read carefully.
o Section 5 - Security Considerations: This section describes o Section 5 - Security Considerations: This section considers
security considerations and digital signatures for the XML from an IETF perspective, how IOTP addresses security. It
elements exchanged between the Trading Roles. includes: how to determine whether to use digital
signatures with IOTP, how IOTP address data privacy, and
how security built into payment protocols relate to IOTP
security.
o Section 6 - Trading Components: This section defines the XML o Section 6 - Digital Signatures and IOTP: This section
elements required by Trading Components. provides an overview of how IOTP uses digital signatures;
how to check a signature is correctly calculated and how
the various Trading Roles that participate in trade should
check signatures when required.
o Section 7 - Trading Blocks: This section describes how Trading o Section 7 - Trading Components: This section defines the
Blocks are constructed from Trading Components. XML elements required by Trading Components.
o Section 8 - Open Trading Protocol Transactions: This section o Section 8 - Trading Blocks: This section describes how
describes all the IOTP Baseline transactions. It refers to Trading Blocks are constructed from Trading Components.
Trading Blocks and Trading Components and Signatures. This
section doesn't directly link error handling during the
protocol exchanges, the reader is advised to understand Error
Handling as defined in section before reading this section.
o Section 9 - Retrieving Logos: This section describes how IOTP o Section 9 - Internet Open Trading Protocol Transactions:
specific logos can be retrieved. This section describes all the IOTP Baseline transactions.
It refers to Trading Blocks and Trading Components and
Signatures. This section doesn't directly link error
handling during the protocol exchanges, the reader is
advised to understand Error Handling as defined in section
before reading this section.
o Section 10 - Brand List Examples: This section gives some o Section 10 - Retrieving Logos: This section describes how
examples for Brand List. IOTP specific logos can be retrieved.
o Section 11 - XML Overview: This section gives brief o Section 11 - Brands: This section provides: an overview of
introduction to XML. Brand Definitions and Brand Selection which describe how a
Consumer can select a Brand from a list provided by the
Merchant; as well as some examples of Brand Lists.
o Section 12 - Open Trading Protocol Data Type Definition: This o Section 12 - IANA Considerations: This section describes
section contains the XML Data Type Definitions for IOTP. how new values for codes used by IOTP are co-ordinated.
o Section 12 - Glossary. This describes all the major terminology o Section 13 - Internet Open Trading Protocol Data Type
used by IOTP. Definition: This section contains the XML Data Type
Definitions for IOTP.
1.8 Intended Readership o Section 14 - Glossary. This describes all the major
terminology used by IOTP.
o Section 15 - Copyright information.
o Section 16 - A list of the other documents referenced by
the IOTP specification.
o Section 17 - The Author's Address
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 technical planners; industry analysts; merchants; bank and other
payment handlers; owners, custodians, and users of payment protocols. payment handlers; owners, custodians, and users of payment protocols.
1.8.1 Reading Guidelines 1.7.1 Reading Guidelines
This IOTP specification is structured primarily in a sequence targeted This IOTP specification is structured primarily in a sequence targeted
at people who want to understand the principles of IOTP. However from at people who want to understand the principles of IOTP. However from
practical implementation experience by implementers of earlier of practical implementation experience by implementers of earlier of
versions of the protocol new readers who plan to implement IOTP may versions of the protocol new readers who plan to implement IOTP may
prefer to read the document in a different sequence as described prefer to read the document in a different sequence as described
below. below.
Review the transport independent parts of the specification: This Review the transport independent parts of the specification: This
covers covers
o Section 12 - Glossary o Section 14 - Glossary
o Section 1 - Background o Section 1 - Background
o Section 2 - Introduction o Section 2 - Introduction
o Section 3 - Protocol Structure o Section 3 - Protocol Structure
o Section 4 - IOTP Error Handling o Section 4 - IOTP Error Handling
o Section 8 - Open Trading Protocol Transactions o Section 5 - Security Considerations
o Section 10 - Brand List Examples
o Section 4 - IOTP Error Handling
o Section 9 - Retrieving Logos
Review the detailed XML definitions:
o Section 11 - XML Overview (if the reader does not know XML)
o Section 7 - Trading Blocks
o Section 6 - Trading Components
1.9 History
Version 0.1 20 February 1997 Initial draft for comment
Version 0.2 14 April 1997 Revised draft including changes o Section 9 - Internet Open Trading Protocol Transactions
arising from comments
Version 0.2a 24 April 1997 Same as version 0-2 with
typographic corrections
Version 0.3 9 October 1997 Revised draft for comment o Section 11 - Brands
including revised encoding
approach using [XML]
Version 0.4 31 October 1997 Published draft for limited public o Section 12 - IANA Considerations
review by groups working within
the OTP consortium
Version 0.9 12 January 1998 Revisions following limited public o Section 10 - Retrieving Logos
review _ draft for public comment
only.
Version 0.9.1 20 May 1998 Revisions following public review Review the detailed XML definitions:
- internal IOTP Consortium review.
Version 0.9.9 17 August 1998 Draft published for submission to o Section 8 - Trading Blocks
IETF for information.
Version 1.0 23 October 1998 Draft published incorporating o Section 7 - Trading Components
comments received on version
0.9.9.
Version 1.0 28 February 1998 Revised draft published incorporating o Section 6 - Digital Signatures and IOTP
comments received on version 1.0
2. Introduction 2. Introduction
The Internet Open Trading Protocols (IOTP) define a number of The Internet Open Trading Protocols (IOTP) define a number of
different types of IOTP Transactions: different types of IOTP Transactions:
o Purchase. This supports a purchase involving an offer, a o Purchase. This supports a purchase involving an offer, a
payment and optionally a delivery payment 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
typically, an earlier purchase of, typically, an earlier purchase
o Value Exchange. This involves two payments which result in the o Value Exchange. This involves two payments which result in
exchange of value from one combination of currency and payment the exchange of value from one combination of currency and
method to another payment method to another
o Authentication. This supports one organisation or individual to o Authentication. This supports one organisation or
check that another organisation or individual are who they individual to check that another organisation or individual
appear to be. are who they appear to be.
o Withdrawal. This supports the withdrawal of electronic cash o Withdrawal. This supports the withdrawal of electronic cash
from a financial institution from a financial institution
o Deposit. This supports the deposit of electronic cash at a o Deposit. This supports the deposit of electronic cash at a
financial institution financial institution
o Inquiry This supports inquiries on the status of an IOTP o Inquiry This supports inquiries on the status of an IOTP
transaction 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
application to determine whether another IOTP application aware application to determine whether another IOTP
running elsewhere is working or not. application running elsewhere is working or not.
These IOTP Transactions are "Baseline" transactions since they have These IOTP Transactions are "Baseline" transactions since they have
been identified as a minimum useful set of transactions. Later been identified as a minimum useful set of transactions. Later
versions of 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 organisations playing a Trading Role, and o a number organisations playing a Trading Role, and
o a set of Trading Exchanges. Each Trading Exchange involves the o a set of Trading Exchanges. Each Trading Exchange involves
exchange of data, between Trading Roles, in the form of a set the exchange of data, between Trading Roles, in the form of
of Trading Components. a set of 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 ca
take in a trade. The six Trading Roles used within IOTP are take in a trade. The six Trading Roles used within IOTP are
illustrated 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 |
skipping to change at page 20, line 40 skipping to change at page 19, line 37
| Delivery Handler supplies goods or ---------- | Delivery Handler supplies goods or ----------
|---------------------------------------------->|Deliverer | |---------------------------------------------->|Deliverer |
services for Merchant ---------- services for Merchant ----------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 o Consumer. The person or organisation which is to receive
pay for the goods or services and pay for the goods or services
o Merchant. The person or organisation from whom the purchase is o Merchant. The person or organisation from whom the purchase
being made and who is legally responsible for providing the is being made and who is legally responsible for providing
goods or services and receives the benefit of the payment made the goods or services and receives the benefit of the
payment made
o Payment Handler. The entity that physically receives the o Payment Handler. The entity that physically receives the
payment from the Consumer on behalf of the Merchant payment from the Consumer on behalf of the Merchant
o Delivery Handler. The entity that physically delivers the goods
or services to the Consumer on behalf of the Merchant.
o Merchant Customer Care Provider. The entity that is involved o Delivery Handler. The entity that physically delivers the
with customer dispute negotiation and resolution on behalf of goods or services to the Consumer on behalf of the
the Merchant Merchant.
o Merchant Customer Care Provider. The entity that is
involved with customer dispute negotiation and resolution
on behalf of the Merchant
Roles may be carried out by the same organisation or different 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 o in the simplest case one physical organisation (e.g. a
merchant) could handle the purchase, accept the payment, merchant) could handle the purchase, accept the payment,
deliver the goods and provide merchant customer care deliver the goods and provide merchant customer care
o at the other extreme, a merchant could handle the purchase but o at the other extreme, a merchant could handle the purchase
instruct the consumer to pay a bank or financial institution, but instruct the consumer to pay a bank or financial
request that delivery be made by an overnight courier firm and institution, request that delivery be made by an overnight
to contact an organisation which provides 24x7 service if courier firm and to contact an organisation which provides
problems arise. 24x7 service if problems arise.
Note that in this specification, unless stated to the contrary, when Note that in this specification, unless stated to the contrary, when
the words Consumer, Merchant, Payment Handler, Delivery Handler or the words Consumer, Merchant, Payment Handler, Delivery Handler or
Customer Care Provider are used, they refer to the Trading Role rather Customer Care Provider are used, they refer to the Trading Role rathe
than an actual organisation. than an actual organisation.
An individual organisation may take multiple roles. For example a An individual organisation may take multiple roles. For example a
company which is selling goods and services on the Internet could take company which is selling goods and services on the Internet could tak
the role of Merchant when selling goods or services and the role of the role of Merchant when selling goods or services and the role of
Consumer when the company is buying goods or services itself. Consumer when the company is buying goods or services itself.
As roles occur in different places there is a need for the As roles occur in different places there is a need for the
organisations involved in the trade to exchange data, i.e. to carry organisations involved in the trade to exchange data, i.e. to carry
out Trading 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 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
Consumer with the reason why the trade is taking place. It is the Consumer with the reason why the trade is taking place.
called an Offer since the Consumer must accept the Offer if a It is called an Offer since the Consumer must accept the
trade is to continue Offer if a trade is to continue
o Payment. The Payment Exchange results in a payment of some kind
between the Consumer and the Payment Handler. This may occur in
either direction
o Delivery. The Delivery Exchange transmits either the on-line o Payment. The Payment Exchange results in a payment of some
goods, or delivery information about physical goods from the kind between the Consumer and the Payment Handler. This may
Delivery Handler to the Consumer, and occur in either direction
o Delivery. The Delivery Exchange transmits either the on-
line goods, or delivery information about physical goods
from the Delivery Handler to the Consumer, and
o Authentication. The Authentication Exchange can be used by any o Authentication. The Authentication Exchange can be used by
Trading Role to authenticate another Trading Role to check that any Trading Role to authenticate another Trading Role to
they are who they appear to be. check that they are who they appear to be.
IOTP Transactions are composed of various combinations of these IOTP Transactions are composed of various combinations of these
Trading Exchanges. For example, an IOTP Purchase transaction includes Trading Exchanges. For example, an IOTP Purchase transaction include
Offer, Payment, and Delivery Trading Exchanges. As another example, Offer, Payment, and Delivery Trading Exchanges. As another example,
an IOTP Value Exchange transaction is composed of an Offer Trading an IOTP Value Exchange transaction is composed of an Offer Trading
Exchange and two Payment Trading Exchanges. 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 between the various Trading Roles. Where possible, the number of
round-trip delays in an IOTP Transaction is minimised by packing the round-trip delays in an IOTP Transaction is minimised by packing the
Components from several Trading Exchanges into combination IOTP Components from several Trading Exchanges into combination IOTP
Messages. For example, the IOTP Purchase transaction combines a Messages. For example, the IOTP Purchase transaction combines a
Delivery Organisation Component with an Offer Response Component in Delivery Organisation Component with an Offer Response Component in
skipping to change at page 23, line 12 skipping to change at page 21, line 39
Trading Exchanges are intermingled in the actual IOTP Transaction Trading Exchanges are intermingled in the actual IOTP Transaction
definitions. 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 Consumer with information about the trade so that the Consumer can
decide whether to continue with the trade. This is illustrated in the decide whether to continue with the trade. This is illustrated in the
figure below. figure below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends information about the
transaction (requests an offer) to the Merchant e.g. using
HTML.
CONSUMER IOTP MESSAGE MERCHANT C --> M Data: Information on what is being purchased (Offer
1. Consumer decides to ----------------------> 2. Merchant checks Request) - outside scope of IOTP
trade and sends Information on what is the information
information about the being purchased (Offer provided by the 2. Merchant checks the information provided by the Consumer,
transaction (requests Request) (outside scope Consumer, creates an creates an Offer optionally signs it and sends it to the
an offer) to the of IOTP) Offer and sends it Consumer.
Merchant, e.g using to the Consumer|
HTML C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer,
v DeliverTo, Merchant, Payment Handler, Customer Care);
3. Consumer checks the Components: Organisation(s) Order; Pay Amount; Delivery; Optional Offer Response
information from the (Consumer, DeliverTo, Merchant, Signature that signs other components
Merchant and decides <---------- Payment Handler, Delivery
whether to continue Offer Handler, Cust Care); Order; Pay 3. Consumer checks the information from the Merchant and
Response Amount; Delivery; Signature decides whether to continue.
(Offer Response)(which signs
other components)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 2 Offer Exchange Figure 2 Offer Exchange
An Offer Exchange uses the following Trading Components that are An Offer Exchange uses the following Trading Components that are
passed between the Consumer and the Merchant: passed between the Consumer and the Merchant:
o the Organisation Component contains information which describes o the Organisation Component contains information which
the organisations which are taking a role in the trade: describes the organisations which are taking a role in the
- the consumer provides information, about who the consumer is and, trade:
if goods or services are being delivered, where the goods or - the consumer provides information, about who the consumer is
services are to be delivered to and, if goods or services are being delivered, where the goods
- the merchant augments this information by providing information or services are to be delivered to
about the merchant, the Payment Handler, the customer care - the merchant augments this information by providing
provider and, if goods or services are being delivered, the information about the merchant, the Payment Handler, the
Delivery Handler customer care provider and, if goods or services are being
delivered, the Delivery Handler
o the Order Component contains descriptions of the goods or o the Order Component contains descriptions of the goods or
services which will result from the trade if the consumer services which will result from the trade if the consumer
agrees to the offer. This information is sent by the Merchant agrees to the offer. This information is sent by the
to the consumer who should verify it Merchant to the consumer who should verify it
o the Payment Component generated by the Merchant, contains o the Payment Component generated by the Merchant, contains
details of how much to pay, the currency and the payment details of how much to pay, the currency and the payment
direction, for example the consumer could be asking for a direction, for example the consumer could be asking for a
refund. Note that there may be more than one payment in a trade refund. Note that there may be more than one payment in a
trade
o the Delivery Component, also generated by the Merchant, is used o the Delivery Component, also generated by the Merchant, is
if goods or services are being delivered. This contains used if goods or services are being delivered. This
information about how delivery will occur, for example by post contains information about how delivery will occur, for
or using e-mail example by post or using e-mail
o the "Offer Response" Signature Component, if present, digitally o the "Offer Response" Signature Component, if present,
signs all of the above components to ensure their integrity. digitally signs all of the above components to ensure their
integrity.
The exact content of the information provided by the Merchant to the The exact content of the information provided by the Merchant to the
Consumer will vary depending on the type of IOTP Transaction. For Consumer will vary depending on the type of IOTP Transaction. For
example: example:
o low value purchases may not need a signature o low value purchases may not need a signature
o the amount to be paid may vary depending on the payment brand o the amount to be paid may vary depending on the payment
and payment protocol used brand and payment protocol used
o some offers may not involve the delivery of any goods o some offers may not involve the delivery of any goods
o a value exchange will involve two payments o a value exchange will involve two payments
o a merchant may not offer customer care. o a merchant may not offer customer care.
Information provided by the consumer to the merchant is provided using Information provided by the consumer to the merchant is provided usin
a variety of methods, for example, it could be provided: a variety of methods, for example, it could be provided:
o using [HTML] pages as part of the "shopping experience" of the o using [HTML] pages as part of the "shopping experience" of
consumer. the consumer.
o Using the Open Profiling Standard [OPS] which has recently been o Using the Open Profiling Standard [OPS] which has recently
proposed, been proposed,
o in the form of Organisation Components associated with an o in the form of Organisation Components associated with an
authentication of a Consumer by a Merchant authentication of a Consumer by a Merchant
o as Order Components in a later version of IOTP. 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 optionally provide the Consumer with a digitally signed Payment
Receipt which can be used to link the payment to the reason for the Receipt which can be used to link the payment to the reason for the
payment as 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 Payment Exchanges can work in a variety of ways. The most general cas
where the trade is dependent on the payment brand and protocol used is where the trade is dependent on the payment brand and protocol used i
illustrated in the diagram below. Simpler payment exchanges are illustrated in the diagram below. Simpler payment exchanges are
possible. possible.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Pay Handler
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about the transaction (requests an offer) to the
Merchant e.g. using HTML.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* C --> M Information on what is being paid for (outside scop
of IOTP
CONSUMER IOTP MESSAGE MERCHANT 2. Merchant decides which payment brand, payment
1. Consumer decides to 2. Merchant decides protocols and currencies/amounts to offer, places
trade and sends Information on what is which payment then in a Brand List Component and sends them to th
information about the being paid for brand, payment
transaction (requests an ----------------------> protocols and
offer) to the Merchant, (outside scope of IOTP) currencies/amounts
e.g using HTML to offer, places
them in a Brand
List Component and
sends them to the
Consumer Consumer
|
v C <-- M Components: Brand List
3. Consumer selects the payment <----------------- Brand List
brand, protocol and currency/amount Brand List Component 3. Consumer selects the payment brand, protocol and
to use, creates a Brand Selection currency/amount to use, creates a Brand Selection
Component and sends it to the component and sends it to the Merchant
Merchant
| C --> M Component: Brand List Selection
v
Brand Selection ----------------> 4. Merchant checks Brand 4. Merchant checks Brand Selection, creates a Payment
Brand Selection Selection, creates Payment Amount Amount information, optionally signs it to authoris
information, optionally signs it payment and sends it to the Consumer
to authorise payment and sends it
to the Consumer C <-- M Component: Pay Amount; Organisation(s) (Merchant an
| Payment Handler); Optional Offer Response Signature
v that signs other components
5. Consumer checks the Components:
Payment Amount information <-------- Pay Amount; Auth data; 5. Consumer checks the Payment Amount information and
and if OK requests that the Payment Organisation(s) (Merchant & if OK requests that the payment starts by sending
payment starts by sending Information Payment Handler); Signature information to the Payment Handler
information to the Payment (Offer) (signs other
Handler components) C --------> P PAYMENT REQUEST. Components: Pay Amount;
| Organisations (Merchant and Payment Handler);
| ======================================== Optional Offer Response Signature that signs other
v PAYMENT HANDLER components; Pay Scheme
Components: Pay Scheme; Auth 6. Payment Handler checks
Data; Brand List; Pay Amount; information including 6. Payment Handler checks information including
Brand Selection; ----------> optional signature and if optional signature and if OK starts exchanging Pay
Organisation(s) (Merchant & Payment OK starts exchanging Pay Scheme components for selected payment brand and
Payment Handler); Signature Request Scheme Components using payment protocol
(Offer) (signs all other messages for selected
----- components except payment brand and payment C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme
| Pay Scheme) protocol
| | | 7. Eventually payment protocol messages finish so
| v v Payment Handler sends Pay Receipt and optional
| Component: Pay Scheme <------------------> Component: Pay Scheme signature to the Consumer as proof of payment
| Payment Exchange
| | C <-------> P PAYMENT RESPONSE. Components: Pay Receipt; Payment
| v Note; Optional Offer Response Signature; Optional
| 7. Eventually payment protocol messages Payment Receipt Signature that binds the payment to
----------- finish so Payment Handler sends Pay the Offer
| Receipt and optional signature to 8. Consumer checks Payment Receipt is OK
| Consumer as proof of payment
| |
| v
8. Consumer checks Pay Components: Pay Receipt; Pay
Receipt is OK <------- scheme; Signature (Offer);
Payment Signature (Pay Receipt) (signs Pay
Response Receipt and Signature (Offer)
components)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 3 Payment Exchange Figure 3 Payment Exchange
A Payment Exchange uses the following Trading Components that are A Payment Exchange uses the following Trading Components that are
passed 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
example, MasterCard, Visa, Mondex, GeldKarte), payment (for example, MasterCard, Visa, Mondex, GeldKarte), payment
protocols (for example SET Version 1.0, Secure Channel Credit protocols (for example SET Version 1.0, Secure Channel
Debit (SCCD - the name used for a credit or debit card payment Credit Debit (SCCD - the name used for a credit or debit
where unauthorised access to account information is prevented card payment where unauthorised access to account
through use of secure channel transport mechanisms such as SSL) information is prevented through use of secure channel
as well as currencies/amounts that apply. The Merchant sends transport mechanisms such as SSL/TLS) as well as
the Brand List to the Consumer. The consumer compares the currencies/amounts that apply. The Merchant sends the Brand
payment brands, protocols and currencies/amounts on offer with List to the Consumer. The consumer compares the payment
brands, protocols and currencies/amounts on offer with
those that the Consumer supports and makes a selection. those that the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's o The Brand Selection Component contains the Consumer's
selection. Payment brand, protocol, currency/amount and selection. Payment brand, protocol, currency/amount and
possibly protocol-specific information is sent back to the possibly protocol-specific information is sent back to the
Merchant. This information may be used to change information in Merchant. This information may be used to change
the Offer Exchange. For example, a merchant could choose to information in the Offer Exchange. For example, a merchant
offer a discount to encourage the use of a store card. could choose to offer a discount to encourage the use of a
store card.
o The Organisation Components are generated by the Merchant. They o The Organisation Components are generated by the Merchant.
contain details of the Merchant and Payment Handler Roles: They contain details of the Merchant and Payment Handler
Roles:
- the Merchant role is required so that the Payment Handler can - the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the identify which Merchant initiated the payment. Typically, the
result of the Payment Handler accepting (or making) a payment on result of the Payment Handler accepting (or making) a payment
behalf of the Merchant will be a credit or debit transaction to on behalf of the Merchant will be a credit or debit
the Merchant's account held by the Payment Handler. These transaction to the Merchant's account held by the Payment
transactions are outside the scope of this version of IOTP Handler. These transactions are outside the scope of this
- the Payment Handler role is required so that the Payment Handler version of IOTP
can check that it is the correct Payment Handler to be used for - the Payment Handler role is required so that the Payment
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 o The Payment Component contains details of how much to pay,
currency and the payment direction the currency and the payment direction
o The "Offer Response" Signature Component, if present, digitally o The "Offer Response" Signature Component, if present,
signs all of the above components to ensure their integrity. digitally signs all of the above components to ensure their
Note that the Brand List and Brand Selection Components are not integrity. Note that the Brand List and Brand Selection
signed until the payment information is created (step 4 in the Components are not signed until the payment information is
diagram) created (step 4 in the diagram)
o The Payment Scheme Component contains messages from the payment o The Payment Scheme Component contains messages from the
protocol used in the Trade. For example they could be SET payment protocol used in the Trade. For example they could
messages, Mondex messages, GeldKarte Messages or one of the be SET messages, Mondex messages, GeldKarte Messages or one
other payment methods supported by IOTP. The content of the of the other payment methods supported by IOTP. The content
Payment Scheme Component is defined in the supplements that of the Payment Scheme Component is defined in the
describe how IOTP works with various payment protocols. supplements that describe how IOTP works with various
payment protocols.
o The Payment Receipt Component contains a record of the payment. o The Payment Receipt Component contains a record of the
The content depends upon the payment protocol used. payment. The content depends upon the payment protocol
used.
o The "Payment Receipt" Signature Component provides proof of o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing both the Payment Receipt Component payment by digitally signing both the Payment Receipt
and the Offer Response Signature. The signature on the offer Component and the Offer Response Signature. The signature
digitally signs the Order, Organisation and Delivery Components on the offer digitally signs the Order, Organisation and
contained in the Offer. This signature effectively binds the Delivery Components contained in the Offer. This signature
payment to the offer. effectively binds the payment to the offer.
The example of a Payment Exchange above is the most general case. The example of a Payment Exchange above is the most general case.
Simpler cases are also possible. For example, if the amount paid is Simpler cases are also possible. For example, if the amount paid is
not dependent on the payment brand and protocol selected then the not dependent on the payment brand and protocol selected then the
payment information generated by step 3 can be sent to the Consumer at payment information generated by step 3 can be sent to the Consumer a
the same time as the Brand List Component generated by step 1. These the same time as the Brand List Component generated by step 1. These
and other variations are described in the Baseline Purchase IOTP and other variations are described in the Baseline Purchase IOTP
Transaction (see section Baseline Purchase IOTP Transaction). Transaction (see section Baseline Purchase IOTP Transaction).
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, providin
details about the delivery, such as shipping tracking number. The details about the delivery, such as shipping tracking number. The
result of the delivery may also be signed so that it can be used for result of the delivery may also be signed so that it can be used for
customer care in the case of problems with physical delivery. The customer care in the case of problems with physical delivery. The
message flow is illustrated in the diagram below. message flow is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Delivery
| Handler
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about what to deliver and who is to take delivery,
to the Merchant e.g. using HTML.
CONSUMER IOTP MESSAGE MERCHANT C --> M Information on what is being delivered (outside
1. Consumer decides to ------------> 2. Merchant checks the scope of IOTP)
trade and sends Information information provided by the
information about what on what is Consumer, adds information 2. Merchant checks the information provided by the
to deliver and who is being about how the delivery will Consumer, adds information about how the delivery
to take delivery, to delivered occur, information about the will occur, information about the organisations
the Merchant, using for (outside organisations involved in the involved in the delivery and optionally sings it an
example, HTML scope of delivery and optionally signs sends it to the Consumer
IOTP) it
| C <-- M Components: Delivery; Organisations (Delivery
v Handler, Deliver To); Order, Optional Offer Respons
3. Consumer checks the Components: Signature
delivery information is OK, Delivery;
obtains authorisation for <----------------- Organisation(s) 3. Consumer checks delivery information is OK, obtains
the delivery, for example by Delivery Delivery Handler, authorisation for the delivery, for example by
making a payment, and sends Information Deliver To; Order; making a payment, and sends the delivery informatio
the delivery information to Signature (Offer) to the Delivery Handler
the Delivery Handler.
| C --------> D DELIVERY REQUEST. Components: Delivery,
v Organisations: (Merchant, Delivery Handler,
Components: Delivery; 4. Delivery Handler checks DelivTo); Order, Optional Offer Response Signature,
Organisation(s), Merchant, information and Optional Payment Receipt Signature (from Payment
Delivery Handler, DelivTo; --------> authorisation. Starts or Exchange)
Order; Signature (Offer); Delivery schedules delivery and
Signature (Pay Receipt) Request creates and then sends a 4. Delivery Handler checks information and
(from Payment Exchange) delivery note to the Consumer authorisation. Starts or schedules delivery and
which can optionally be signed creates and then sends a delivery not tot the
| Consumer which can optionally be signed.
v
5. Consumer checks delivery <--------- Component: Delivery C <-------- D DELIVERY RESPONSE. Components: Delivery Note,
note is OK and accepts or waits Delivery Note; Signature Optional Delivery Response Signature
for delivery as described in Response (Delivery Response)
the Delivery Note 5. Consumer checks delivery note is OK and accepts or
waits for delivery as described in the the Delivery
Note.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 4 Delivery Exchange Figure 4 Delivery Exchange
A Delivery Exchange uses the following Trading Components that are A Delivery Exchange uses the following Trading Components that are
passed between the Consumer, the Merchant and the Delivery Handler: passed between the Consumer, the Merchant and the Delivery Handler:
o The Organisation Component(s) contain details of the Deliver o The Organisation Component(s) contain details of the
To, Delivery Handler and Merchant Roles: Deliver To, Delivery Handler and Merchant Roles:
- the Deliver To role indicates where the goods or services are to - the Deliver To role indicates where the goods or services are
be delivered to to be delivered to
- the Delivery Handler role is required so that the Delivery Handler - the Delivery Handler role is required so that the Delivery
can check that she is the correct Delivery Handler to do the Handler can check that she is the correct Delivery Handler to
delivery do the delivery
- the Merchant role is required so that the Delivery Handler can - the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery identify which Merchant initiated the delivery
o The Order Component, contains information about the goods or o The Order Component, contains information about the goods
services to be delivered or services to be delivered
o The Delivery Component contains information about how delivery o The Delivery Component contains information about how
will occur, for example by post or using e-mail. delivery will occur, for example by post or using e-mail.
o The "Offer Response" Signature Component, if present, digitally o The "Offer Response" Signature Component, if present,
signs all of the above components to ensure their integrity. digitally signs all of the above components to ensure their
integrity.
o The "Payment Receipt" Signature Component provides proof of o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing the Payment Receipt Component and payment by digitally signing the Payment Receipt Component
the Offer Signature. This is used by the Delivery Handler to and the Offer Signature. This is used by the Delivery
check that delivery is authorised Handler to check that delivery is authorised
o The Delivery Note Component contains customer care information o The Delivery Note Component contains customer care
related to a physical delivery, or alternatively the actual information related to a physical delivery, or
"electronic goods". The Consumer's software does not interpret alternatively the actual "electronic goods". The Consumer's
information about a physical delivery but should have the software does not interpret information about a physical
ability to display the information, both at the time of the delivery but should have the ability to display the
delivery and later if the Consumer selects the Trade to which information, both at the time of the delivery and later if
this delivery relates from a transaction list the Consumer selects the Trade to which this delivery
relates from a transaction list
o The "Delivery Response" Signature Component, if present, o The "Delivery Response" Signature Component, if present,
provides proof of the results of the Delivery by digitally provides proof of the results of the Delivery by digitally
signing the Delivery Note and any Offer Response or Payment signing the Delivery Note and any Offer Response or Payment
Response signatures that the Delivery Handler received. 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, The goal of the Authentication Exchange is to allow one organisation,
for 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. It organisation, for example a consumer, is who they appear to be.
uses a "challenge-response" mechanism.
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
(Authenticatee)
| Organisation 2
| (Authenticator)
STEP | |
1. First organisation, e.g. a Consumer, takes an action (for
example by pressing a button on an HTML page) which
requires that the organisation is authenticated
ORGANISATION 1 IOTP MESSAGE ORGANISATION 2 1 --> 2 Need for Authentication (outside scope of IOTP)
(AUTHENTICATEE) (AUTHENTICATOR)
1. First organisation, 2. The second 2. The second organisation generates an Authentication
e.g a consumer, takes an organisation generates Request - including challenge data, and a list of the
action (for example by ----------------> Authentication Data algorithms that may be used for the authentication -
pressing a button on an Need for containing challenge and/or a request for the Organisation information then
HTML page) which Authentication data, the method of sends it to the first organisation
requires that the (outside scope of authentication to be used
organisation is IOTP) and optionally a request 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
authenticated for Organisation Request, Trading Role Information Request
information then sends it
to the first organisation 3. The first organisation optionally checks any signature
| associated with the Authentication Request then uses the
v specified authentication algorithm to generate an
3. The first organisation Component: Authentication Response which is sent back to the second
optionally checks any signature <------------ Authentication Data organisation together with details of any Organisation
associated with the Authentication
Authentication request then Request
uses the challenge data with
the specified authentication
method to generate an
Authentication Response which
is sent back to the second
organisation together with
details of any Organisation
information requested information requested
|
v 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Component: 4. The Authentication Response is Response, Organisation(s)
Authentication -------------> checked against the challenge data to
Response Authentication check that the first organisation is 4. The Authentication Response is checked against the
Response who they appear to be and the result challenge data to check that the first organisation is who
recorded in a Status Component which they appear to be and the result recorded in a Status
is then sent back to the first Component which is then sent back to the first
organisation organisation.
|
v 1 <-- 2 AUTHENTICATION STATUS. Component: Status
5. The first organisation then Component: Status
optionally checks the results <------------ 5. The first organisation then optionally checks the results
of the Status and any Authentication indicated by the Status and any associated signature and
associated signature and takes Status takes the appropriate action or stops.
the appropriate action or
stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 5 Authentication Exchange
Figure 5 Authentication Exchange
An Authentication Exchange uses the following Trading Components that An Authentication Exchange uses the following Trading Components that
are passed between the two organisations: are passed between the two organisations:
o the Authentication Data Component which contains the challenge o the Authentication Request Component that requests an
data to be used in the "challenge-response" mechanism, Authentication and indicates the authentication algorithm
indicates the authentication method to be used and optionally and optional challenge data to be used.
request Organisation data about the first organisation, for
example a ship to or billing address. It is sent by one o A Trading Role Information Request Component that requests
organisation to the other. information about an Organisation, for example a ship to or
billing address.
o The Authentication Response Component which contains the o The Authentication Response Component which contains the
challenge response generated by the recipient of the challenge response generated by the recipient of the
Authentication Data Component. It is sent back to the first Authentication Request Component.
organisation for verification together with Organisation
Components requested
o the Status Component which contains the results of the second o Organisation Components that contain the result of the
party's verification of the Authentication Response. Trading Role Information Request
o the Status Component which contains the results of the
second party's verification of the Authentication Response.
2.3 Scope of Baseline IOTP 2.3 Scope of Baseline IOTP
This specification describes the IOTP Transactions which make up This specification describes the IOTP Transactions which make up
Baseline IOTP. As described in the preface, IOTP will evolve over Baseline IOTP. As described in the preface, IOTP will evolve over
time. This section defines the initial conformance criteria for time. This section defines the initial conformance criteria for
implementations that claim to _support IOTP._ implementations that claim to "support IOTP."
The main determinant on the scope of an IOTP implementation is the The main determinant on the scope of an IOTP implementation is the
roles which the solution is designed to support. The roles within IOTP roles which the solution is designed to support. The roles within IOT
are described in more detail in section 2.1 Trading Roles. To are described in more detail in section 2.1 Trading Roles. To
summarise the roles are: Merchant, Consumer, Payment Handler, Delivery summarise the roles are: Merchant, Consumer, Payment Handler, Deliver
Handler and Customer Care Provider. 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 o those who accept a payment as part of a purchase or make a
payment as part of a refund, payment 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
skipping to change at page 35, line 4 skipping to change at page 31, line 32
Withdrawal Must b) Withdrawal Must b)
Depends Depends
Deposit Must b) Deposit Must b)
Depends Depends
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Ping Must Must Must Must Must Must Ping Must Must Must Must Must Must
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
TRADING BLOCKS TRADING BLOCKS
TPO Must Must Must Must TPO Must Must Must Must
TPO Selection Must Must Must Must TPO Selection Must Must Must Must
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Auth-Request a) a) a) Auth-Request a) a) a)
Depends Depends Depends Depends Depends Depends
Auth-Reply a) a) a) Auth-Reply a) a) a)
Depends Depends Depends Depends Depends Depends
Offer Response Must Must Must Must Offer Response Must Must Must Must
Payment Must Must Payment Must Must
Request 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
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Delivery Must Must Delivery Must Must
Response Response
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Request Request
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Response Response
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Ping Request Must Must Must Must Must Must Ping Request Must Must Must Must Must Must
Ping Response Must Must Must Must Must Must Ping Response Must Must Must Must Must Must
Signature Must Must Must Limited Must Must Signature Must Must Must Limited Must Must
Error Must Must Must Must Must Must Error Must Must Must Must Must Must
In the above table: In the above table:
o _Must_ means that a Trading Role must support the Transaction o "Must" means that a Trading Role must support the
or Trading Block. Transaction or Trading Block.
o _May_ means that an implementation may support the Transaction
or Trading Block at the option of the developer.
o _Depends_ means implementation of the Transaction or Trading o "May" means that an implementation may support the
Block depends on one of the following conditions: Transaction or Trading Block at the option of the
developer.
a) if Baseline Authentication IOTP Transaction is supported; o "Depends" means implementation of the Transaction or
b) if required by a Payment Method as defined in its IOTP Trading Block depends on one of the following conditions:
- if Baseline Authentication IOTP Transaction is supported;
- if required by a Payment Method as defined in its IOTP
Supplement document. Supplement document.
o "Limited" means the Trading Block must be understood and its o "Limited" means the Trading Block must be understood and
content manipulated but not in every respect. Specifically, on its content manipulated but not in every respect.
the Signature Block, Consumers do not have to be able to Specifically, on the Signature Block, Consumers do not have
validate digital signatures. to be able to validate digital signatures.
An IOTP solution must support all the IOTP Transactions and Trading An IOTP solution must support all the IOTP Transactions and Trading
Blocks required by at least one role (column) as described in the Blocks required by at least one role (column) as described in the
above table for that solution to be described as "supporting IOTP". 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 o Trading Roles which are the different roles which
can take in a trade: Consumer, Merchant, Payment Handler, organisations can take in a trade: Consumer, Merchant,
Delivery Handler and Customer Care Provider, and Payment Handler, Delivery Handler and Customer Care
Provider, and
o Trading Exchanges where each Trading Exchange involves the o Trading Exchanges where each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set exchange of data, between Trading Roles, in the form of a
of Trading Components. set of Trading Components.
This section describes: This section describes:
o how Trading Components are constructed into Trading Blocks and o how Trading Components are constructed into Trading Blocks
the IOTP Messages which are physically sent in the form of and the IOTP Messages which are physically sent in the form
[XML] documents between the different Trading Roles, of [XML] documents between the different Trading Roles,
o how IOTP Messages are exchanged between Trading Roles to create o how IOTP Messages are exchanged between Trading Roles to
an IOTP Transaction create an IOTP Transaction
o the XML definitions of an IOTP Message including a Transaction o the XML definitions of an IOTP Message including a
Reference Block - an XML element which identifies an IOTP Transaction Reference Block - an XML element which
Transaction and the IOTP Message within it identifies an IOTP Transaction and the IOTP Message within
it
o the definitions of the XML ID Attributes which are used to o the definitions of the XML ID Attributes which are used to
identify IOTP Messages, Trading Blocks and Trading Components identify IOTP Messages, Trading Blocks and Trading
and how these are referred to using Element References from Components and how these are referred to using Element
other XML elements References from other XML elements
o an overview of Brands and Brand Selection which describes how a o how extra XML Elements and new user defined values for
Consumer can select a Brand from a list provided by the existing IOTP codes can be used when Extending IOTP,
Merchant
o how extra XML Elements and new user defined values for existing o how IOTP uses the Packaged Content Element to embed data
IOTP codes can be used when Extending IOTP, such as payment protocol messages or detailed order
definitions within an IOTP Message
o how IOTP uses the Packaged Content Element to embed data such o how IOTP Identifies Languages so that different languages
as payment protocol messages or detailed order definitions can be used within IOTP Messages
within an IOTP Message
o how IOTP Identifies Languages so that different languages can o how IOTP handles both Secure and Insecure Net Locations
be used within IOTP Messages when sending messages
o how IOTP handles both Secure and Insecure Net Locations when
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 The structure of an IOTP Message and its relationship with Trading
Blocks 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
skipping to change at page 40, line 35 skipping to change at page 35, line 35
| 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. Used to check the | |-Certificate Comp. < Certificate Component (0ptional) Used to chec
| signature. | the signature.
|-Trading Block <------- Trading Block - an XML Element within an IOTP |-Trading Block <------- Trading Block - an XML Element within an IOTP
| |-Component Message that contains a predefined set of | |-Trading Comp. Message that contains a predefined set of
| |-Component Trading Components | |-Trading Comp. Trading Components
| |-Component | |-Trading Comp.
| |-Component <-------- 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
| |-Component information required to support a Trading | |-Trading Comp. information required to support a Trading
| |-Component Exchange | |-Trading Comp. Exchange
| |-Component | |-Trading Comp.
| |-Component | |-Trading Comp.
| |-Component | |-Trading Comp.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 6 IOTP Message Structure
Figure 6 IOTP Message Structure
The diagram also introduces the concept of a Transaction Reference The diagram also introduces the concept of a Transaction Reference
Block. This block contains, amongst other things, a globally unique Block. This block contains, amongst other things, a globally unique
identifier for the IOTP Transaction. Also each block and component is identifier for the IOTP Transaction. Also each block and component is
given an ID Attribute (see section 3.4) which is unique within an IOTP given an ID Attribute (see section 3.4) which is unique within an IOT
Transaction. Therefore the combination of the ID attribute and the Transaction. Therefore the combination of the ID attribute and the
globally unique identifier in the Transaction Reference Block is globally unique identifier in the Transaction Reference Block is
sufficient to uniquely identify any Trading Block or Trading sufficient to uniquely identify any Trading Block or Trading
Component. 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 constitute an IOTP Transaction. This is illustrated in the diagram
below. 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 |
skipping to change at page 42, line 44 skipping to change at page 37, line 4
| | | | | |
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 mechanism
This is not necessarily the case. IOTP Messages can be transported This is not necessarily the case. IOTP Messages can be transported
using a variety of transport mechanisms. using a variety of transport mechanisms.
The IOTP Transactions (see section 8) 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 o Purchase. This supports a purchase involving an offer, a
payment and optionally a delivery payment 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
typically, an earlier purchase of, typically, an earlier purchase
o Value Exchange. This involves two payments which result in the o Value Exchange. This involves two payments which result in
exchange of value from one combination of currency and payment the exchange of value from one combination of currency and
method to another payment method to another
o Authentication. This supports the remote authentication of a o Authentication. This supports the remote authentication of
Consumer by another Trading Role using a variety of one Trading Role by another Trading Role using a variety of
authentication methods, and the provision of an Organisation authentication algorithms, and the provision of an
Component about a Consumer to another Trading Role for use in, Organisation Information about the Trading Role that is
for example the creation of an offer being authenticated for use in, for example, the creation
of an offer
o Withdrawal. This supports the withdrawal of electronic cash o Withdrawal. This supports the withdrawal of electronic cash
from a financial institution from a financial institution
o Deposit. This supports the deposit of electronic cash at a o Deposit. This supports the deposit of electronic cash at a
financial institution financial institution
o Inquiry This supports inquiries on the status of an IOTP o Inquiry This supports inquiries on the status of an IOTP
transaction 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
application to determine whether another IOTP application aware application to determine whether another IOTP
running elsewhere is working or not. application running 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 physically sent between the different Trading Roles that are taking
part 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 OtpMessage <!ELEMENT IotpMessage
( TransRefBlk, ( TransRefBlk,
SigBlk?, SigBlk?,
ErrorBlk?, ErrorBlk?,
( AuthReqBlk | ( AuthReqBlk |
AuthRespBlk | AuthRespBlk |
AuthStatusBlk | AuthStatusBlk |
CancelBlk | CancelBlk |
DeliveryReqBlk | DeliveryReqBlk |
DeliveryRespBlk | DeliveryRespBlk |
InquiryReqBlk | InquiryReqBlk |
skipping to change at page 44, line 27 skipping to change at page 38, line 27
OfferRespBlk | OfferRespBlk |
PayExchBlk | PayExchBlk |
PayReqBlk | PayReqBlk |
PayRespBlk | PayRespBlk |
PingReqBlk | PingReqBlk |
PingRespBlk | PingRespBlk |
TpoBlk | TpoBlk |
TpoSelectionBlk TpoSelectionBlk
)* )*
) > ) >
<!ATTLIST OtpMessage <!ATTLIST IotpMessage
xmlns:iotp CDATA xmlns:iotp CDATA
'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-03' > 'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-04' >
Content: Content:
TransRefBlk This contains information which describes an TransRefBlk This contains information which describes an
IOTP Message within an IOTP Transaction (see IOTP Message within an IOTP Transaction (see
section 3.3 immediately below) section 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 DeliveryReqBlk, The Trading Blocks present within an IOTP
DeliveryRespBlk Message, and the content of a Trading Block DeliveryRespBlk Message, and the content of a Trading Block
ErrorBlk itself is dependent on the type of IOTP ErrorBlk itself is dependent on the type of IOTP
InquiryReqBlk, Transaction being carried out - see the InquiryReqBlk, Transaction being carried out - see the
InquiryRespBlk, definition of each transaction in section 8 InquiryRespBlk, definition of each transaction in section 9
OfferRespBlk, Internet Open Trading Protocol Transactions. OfferRespBlk, Internet Open Trading Protocol Transactions.
PayExchBlk, PayExchBlk,
PayReqBlk, Full definitions of each Trading Block are PayReqBlk, Full definitions of each Trading Block are
PayRespBlk, described in section 7. PayRespBlk, described in section 8.
PingReqBlk, PingReqBlk,
PingRespBlk, PingRespBlk,
SigBlk, SigBlk,
TpoBlk, TpoBlk,
TpoSelectionBlk TpoSelectionBlk
Attributes Attributes
xmlns:iotp The [XML Namespace] definition for IOTP xmlns:iotp The [XML Namespace] definition for IOTP
messages. 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 therefor
needs to be preceded by an appropriate XML Document Prolog. For needs to be preceded by an appropriate XML Document Prolog. For
example: example:
<?XML Version='1.0'?> <?XML Version='1.0'?>
<!DOCTYPE OtpMessage > <!DOCTYPE IotpMessage >
<OtpMessage> <IotpMessage>
... ...
</OtpMessage> </IotpMessage>
3.3 Transaction Reference Block 3.3 Transaction Reference Block
A Transaction Reference Block contains information which identifies A Transaction Reference Block contains information which identifies
the IOTP Transaction and IOTP Message. The Transaction Reference Block the IOTP Transaction and IOTP Message. The Transaction Reference Bloc
contains: contains:
o a Transaction Id Component which globally uniquely identifies o a Transaction Id Component which globally uniquely
the IOTP Transaction. The Transaction Id Components are the identifies the IOTP Transaction. The Transaction Id
same across all IOTP messages that comprise a single IOTP Components are the same across all IOTP messages that
transaction, comprise a single IOTP transaction,
o a Message Id Component which provides control information about o a Message Id Component which provides control information
the IOTP Message as well as uniquely identifying the IOTP about the IOTP Message as well as uniquely identifying the
Message within an IOTP Transaction, and IOTP Message within an IOTP Transaction, and
o zero or more Related To Components which link this IOTP o zero or more Related To Components which link this IOTP
Transaction to either other IOTP Transactions or other events Transaction to either other IOTP Transactions or other
using the identifiers of those events. 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
skipping to change at page 46, line 35 skipping to change at page 40, line 25
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'
OtpTransId NMTOKEN #REQUIRED IotpTransId NMTOKEN #REQUIRED
OtpTransType 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 Version This identifies the version of IOTP, and
therefore the structure of the IOTP Messages, therefore the structure of the IOTP Messages,
which the IOTP Transaction is using. which the IOTP Transaction is using.
OtpTransId 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].
OtpTransType This is the type of IOTP Transaction being IotpTransType This is the type of IOTP Transaction being
carried out. For Baseline IOTP it identifies a carried out. For Baseline IOTP it identifies a
"standard" IOTP Transaction and implies the "standard" IOTP Transaction and implies the
sequence and content of the IOTP Messages sequence and content of the IOTP Messages
exchanged between the Trading Roles. The valid exchanged between the Trading Roles. The valid
values for Baseline IOTP are: values for Baseline IOTP 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 OtpTransType are managed under the Values of IotpTransType are managed under the
procedure described in section 3.7.3 Values for procedure described in section 12 IANA
IOTP Codes which also allows user defined values Considerations which also allows user defined
of OtpTransType 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 based on market demand. It is IOTP Transaction. It is also likely to support
also likely to support the type Dynamic which the type Dynamic which indicates that the
indicates that the sequence of steps within the sequence of steps within the transaction are
transaction are non-standard. 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 an alternative way of identifying a transaction
by specifying the time at which it started. by specifying the time at which it started.
skipping to change at page 48, line 14 skipping to change at page 42, line 14
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 Message as well as uniquely identifying the IOTP Message within an
IOTP 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
RespOtpMsg NMTOKEN #IMPLIED RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
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 IOTP ID An identifier which uniquely identifies the
Message within the IOTP Transaction (see section IOTP Message within the IOTP Transaction (see
3.4 ID Attributes). Note that if an IOTP Message section 3.4 ID Attributes). Note that if an
is resent then the value of this attribute IOTP Message is resent then the value of this
remains the same. attribute remains the same.
RespOtpMsg This contains the ID attribute of the Message Id RespIotpMsg This contains the ID attribute of the Message
Component of the IOTP Message to which this IOTP Id Component of the IOTP Message to which this
Message is a response. In this way all the IOTP IOTP Message is a response. In this way all
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 first required on every IOTP Message except the
IOTP Message in an IOTP Transaction. first IOTP Message in an IOTP Transaction.
SenderTradingRoleR The Element Reference (see section 3.5) of the SenderTradingRoleRef The Element Reference (see section 3.5) of the
ef 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.10) of the Trading Role Locations (see section 3.9) of the Trading
to which problems Technical Errors (see section Role to which problems Technical Errors (see
4.1) with any of Trading Blocks should be section 4.1) with any of Trading Blocks should
reported. be reported.
xml:lang Defines the language used by attributes or child xml:lang Defines the language used by attributes or
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.9 Identifying Languages. element. See section 3.8 Identifying
Languages.
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 manufacturer
skipping to change at page 49, line 41 skipping to change at page 43, line 39
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Related To Component within the IOTP Related To Component within the IOTP
Transaction. 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 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.9 Identifying Languages. element. See section 3.8 Identifying Languages.
RelationshipType Defines the type of the relationship. Valid RelationshipType Defines the type of the relationship. Valid
values are: values are:
o OtpTransaction. in which case the Packaged o IotpTransaction. in which case the Packaged
Content Element contains an OtpTransId of Content Element contains an IotpTransId of
another IOTP Transaction another IOTP Transaction
o Reference in which case the Packaged Content o Reference in which case the Packaged Content
Element contains the reference of some other, Element contains the reference of some other,
non-IOTP document. non-IOTP document.
Values of RelationshipType are controlled under Values of RelationshipType are controlled under
the procedures defined in section 3.7.3 Values the procedures defined in section 12 IANA
for IOTP Codes which also allows user defined Considerations which also allows user defined
values to be defined. values to be defined.
Relation The Relation attribute contains a phrase in the Relation The Relation attribute contains a phrase in the
language defined by xml:lang which describes the language defined by xml:lang which describes the
nature of the relationship between the IOTP nature of the relationship between the IOTP
transaction that contains this component and transaction that contains this component and
another IOTP Transaction or other event. The another IOTP Transaction or other event. The
exact words to be used are left to the exact words to be used are left to the
implementers of the IOTP software. implementers of the IOTP software.
skipping to change at page 50, line 44 skipping to change at page 44, line 39
used to help identify similar relationships, for used to help identify similar relationships, for
example all refunds. It is anticipated that example all refunds. It is anticipated that
recommended keywords will be developed through recommended keywords will be developed through
examination of actual usage. In this version of examination of actual usage. In this version of
the specification there are no specific the specification there are no specific
recommendations and the keywords used are at the recommendations and the keywords used are at the
discretion of implementers. discretion of implementers.
Content: Content:
PackagedContent The Packaged Content (see section 3.8) contains PackagedContent The Packaged Content (see section 3.7) contains
data which identifies the related transaction. data which identifies the related transaction.
Its format varies depending on the value of the Its format varies depending on the value of the
RelationshipType. 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 Blocks), Trading Components (including the Transaction Id Component
and the Signature Component) and some of their child elements are each and the Signature Component) and some of their child elements are eac
given an XML "ID" attribute which is used to identify an instance of given an XML "ID" attribute which is used to identify an instance of
these XML elements. These identifiers are used so that one element can these XML elements. These identifiers are used so that one element can
be referenced by another. All these attributes are given the attribute be referenced by another. All these attributes are given the attribut
name ID. 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 Transaction ID Component. Also, once the ID attribute of an element
has been assigned a value it is never changed. This means that has been assigned a value it is never changed. This means that
whenever an element is copied, the value of the ID attribute remains whenever an element is copied, the value of the ID attribute remains
the same. 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 th
content of any IOTP Message, Block or Component from any other IOTP content of any IOTP Message, Block or Component from any other IOTP
Message, Block or Component in the same IOTP Transaction using Element Message, Block or Component in the same IOTP Transaction using Elemen
References (see section 3.5). 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 The ID attribute of the Message Id Component of an IOTP Message must
be unique within an IOTP Transaction. It's definition is as follows: be unique within an IOTP Transaction. It's definition is as follows:
OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
OtpMsgIdPrefix ::= NameChar (NameChar)* IotpMsgIdPrefix ::= NameChar (NameChar)*
OtpMsgIdSuffix ::= Digit (Digit)* IotpMsgIdSuffix ::= Digit (Digit)*
OtpMsgIdPrefix Apart from messages which contain an Inquiry IotpMsgIdPrefix Apart from messages which contain an Inquiry
Request Trading Block (see section 7.12), the Request Trading Block (see section 8.12), the
same prefix is used for all messages sent by the same prefix is used for all messages sent by the
Merchant or Consumer role as follows: Merchant or Consumer role as follows:
o "M" - Merchant o "M" - Merchant
o "C" - Consumer o "C" - Consumer
For messages which contain an Inquiry Request For messages which contain an Inquiry Request
Trading Block, the prefix is set to "I" for Trading Block, the prefix is set to "I" for
Inquiry. Inquiry.
The prefix for the other roles in a trade is The prefix for the other roles in a trade is
skipping to change at page 52, line 40 skipping to change at page 46, line 40
o "P" - First (only) Payment Handler o "P" - First (only) Payment Handler
o "R" - Second Payment Handler o "R" - Second Payment Handler
o "D" - Delivery Handler o "D" - Delivery Handler
As a guideline, prefixes should be limited to As a guideline, prefixes should be limited to
one character. one character.
NameChar has the same definition as the [XML] NameChar has the same definition as the [XML]
definition of NameChar. definition of NameChar.
OtpMsgIdSuffix The suffix consists of one or more digits. The IotpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role suffix must be unique within a Trading Role
within an IOTP Transaction. The following is within an IOTP Transaction. The following is
recommended as a guideline and must not be recommended as a guideline and must not be
relied upon: relied upon:
o the first IOTP Message sent by a trading role o the first IOTP Message sent by a trading role
is given the suffix "1" is given the suffix "1"
o the second and subsequent IOTP Messages sent o the second and subsequent IOTP Messages sent
by the same trading role are incremented by by the same trading role are incremented by
one for each message one for each message
o no leading zeroes are included in the suffix o no leading zeroes are included in the suffix
skipping to change at page 53, line 17 skipping to change at page 47, line 15
third "C3" etc. third "C3" etc.
Digit has the same definition as the [XML] Digit has the same definition as the [XML]
definition of Digit. 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 The ID Attribute of Blocks and Components must also be unique within
an IOTP Transaction. Their definition is as follows: an IOTP Transaction. Their definition is as follows:
BlkOrCompId_value ::= OtpMsgId_value "." IdSuffix BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)* IdSuffix ::= Digit (Digit)*
OtpMsgId_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 In IOTP, Trading Components and Trading Blocks
are copied from one IOTP Message to another. The are copied from one IOTP Message to another. The
ID attribute does not change when an existing ID attribute does not change when an existing
Trading Block or Component is copied to another Trading Block or Component is copied to another
IOTP Message. IOTP Message.
IdSuffix The suffix consists of one or more digits. The IdSuffix The suffix consists of one or more digits. The
skipping to change at page 54, line 12 skipping to change at page 48, line 9
attribute of "C2.1", the second "C2.2", the attribute of "C2.1", the second "C2.2", the
third "C2.3" etc. third "C2.3" etc.
Digit has the same definition as the [XML] Digit has the same definition as the [XML]
definition of Digit. definition of Digit.
3.4.3 Example of use of ID Attributes 3.4.3 Example of use of ID Attributes
The diagram below illustrates how ID attribute values are used. The diagram below illustrates how ID attribute values are used.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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 Ref Block.ID=C1.1* |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| |-Trans Id Comp. ID = M1. ------------->| |-Trans Id Comp. | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp.
| | Copy Element | | ID=M1.2 | | Copy Element | | ID=M1.2
| |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * | |-Msg Id Comp. ID = M1 | |-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
| Copy Element | | Copy Element |
|-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
| | Copy Element | | | Copy Element |
| |-Comp. ID=M1.5 --------- ---------------->|-Comp. ID=M1.5 | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
| | Copy Element | | | Copy Element |
| |-Comp. ID=M1.6 |-Comp. ID=C1.3 * | |-Comp. ID=M1.6 |-Comp. ID=C1.3 *
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 * | |-Comp. ID=M1.7 |-Comp. ID=C1.4 *
| |
|-Trading Block. ID=M1.3 |-Trading Block. ID=M1.9
|-Comp. ID=M1.4 * = new elements |-Comp. ID=M1.10 * = new elements
|-Comp. ID=M1.5 |-Comp. ID=M1.11
|-Comp. ID=M1.6 |-Comp. ID=M1.12
|-Comp. ID=M1.7 |-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 A Trading Component or one of its child XML elements, may contain an
XML attribute that refers to another Block (i.e. a Transaction XML attribute that refers to another Block (i.e. a Transaction
Reference Block or a Trading Block) or Trading Component (including a Reference Block or a Trading Block) or Trading Component (including a
Transaction Id and Signature Component). These Element References are Transaction Id and Signature Component). These Element References are
used for many purposes, a few examples include: used for many purposes, a few examples include:
o identifying an XML element whose Digest is included in a o identifying an XML element whose Digest is included in a
Signature Component, Signature Component,
skipping to change at page 55, line 14 skipping to change at page 49, line 4
3.5 Element References 3.5 Element References
A Trading Component or one of its child XML elements, may contain an A Trading Component or one of its child XML elements, may contain an
XML attribute that refers to another Block (i.e. a Transaction XML attribute that refers to another Block (i.e. a Transaction
Reference Block or a Trading Block) or Trading Component (including a Reference Block or a Trading Block) or Trading Component (including a
Transaction Id and Signature Component). These Element References are Transaction Id and Signature Component). These Element References are
used for many purposes, a few examples include: used for many purposes, a few examples include:
o identifying an XML element whose Digest is included in a o identifying an XML element whose Digest is included in a
Signature Component, Signature Component,
o referring to the Payment Handler Organisation Component
which is used when making a Payment
o referring to the Payment Handler Organisation Component which An Element Reference always contains the value of an ID attribute of
is used when making a Payment
An Element Reference always contains the value of an ID attribute of a
Block or Component. Block or Component.
Identifying the IOTP Message, Trading Block or Trading Component which Identifying the IOTP Message, Trading Block or Trading Component whic
is referred to by an Element Reference, involves finding the XML is referred to by an Element Reference, involves finding the XML
element which: 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
Components of the IOTP Messages match), and Id Components of the IOTP Messages match), and
o where the value of the ID attribute of the element matches the o where the value of the ID attribute of the element matches
value of the Element Reference. the value of the Element Reference.
[Note] The term "match" in this specification has the same [Note] The term "match" in this specification has the same
definition as the [XML] definition of match. definition as the [XML] definition of match.
[Note End] [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 Ref Block. ID=C1.1 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans Ref Block. ID=C1.1
| |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id Comp.ID=M1.2 | |-Trans Id Comp. ID = M1.2 <-Components-|->|-Trans Id 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.6 | | 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.3 |-Trading Block. ID=M1.9
|-Comp. ID=M1.4 |-Comp. ID=M1.10
|-Comp. ID=M1.5 |-Comp. ID=M1.11
|-Comp. ID=M1.6 |-Comp. ID=M1.12
|-Comp. ID=M1.7 |-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 XML element referred to is in the same XML that the XML element referred to is in the same XML
Document. With IOTP this is not necessarily the case. Document. With IOTP this is not necessarily the case.
[Note End] [Note End]
3.6 Brands and Brand Selection 3.6 Extending IOTP
One of the key features of IOTP is the ability for a merchant to offer
a list of Brands from which a consumer may make a selection. This
section provides an overview of what is involved and provides guidance
on how selection of a brand and associated payment instrument can be
carried out by a Consumer. It covers:
o definitions of Payment Instruments and Brands - what are
Payment Instruments and Brands in an IOTP context. Further
categorises Brands as optionally a "Dual Brand" or a
"Promotional Brand",
o identification and selection of Promotional Brands -
Promotional Brands offer a Consumer some additional benefit,
for example loyalty points or a discount. This means that both
Consumers and Merchant must be able to correctly identify that
a valid Promotional Brand is being used.
Also see the following sections:
o Brand List Component (section 6.6) which contains definitions
of the XML elements which contain the list of Brands offered by
a Merchant to a Consumer, and
o Brand Selection Component (section 6.7) for details of how a
Consumer records the Brand that was selected.
3.6.1 Definition of Payment Instrument
A Payment Instrument is the means by which a Consumer pays for goods
or services offered by a Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash payment instrument such as a
Mondex Card, a GeldKarte card or a Visa Cash card
o a software based electronic payment account such as a CyberCash
or DigiCash account.
All Payment Instruments have a number, typically an account number, by
which the Payment Instrument can be identified.
3.6.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are
presented by the Merchant to the Consumer and from which the Consumer
makes a selection. Each Brand may have a different Payment Handler.
Examples of Brands include:
o payment association and proprietary Brands, for example
MasterCard, Visa, American Express, Diners Club, Mondex,
GeldKarte, CyberCash, etc.
o promotional brands (see below). These include:
- store brands, where the Payment Instrument is issued to a Consumer
by a particular Merchant, for example Walmart, Sears, or Marks and
Spencer (UK)
- cobrands, for example American Advantage Visa, where an
organisation uses their own brand in conjunction with, typically,
a payment association Brand.
3.6.3 Definition of Dual Brand
A Dual Brand means that a single payment instrument may be used as if
it were two separate Brands. For example there could be a single
Japanese "UC" MasterCard which can be used as either a UC card or a
regular MasterCard. The UC card Brand and the MasterCard Brand could
each have their own separate Payment Handlers. This means that:
o the merchant treats, for example "UC" and "MasterCard" as two
separate Brands when offering a list of Brands to the Consumer,
o the consumer chooses a Brand, for example either "UC" or
"MasterCard,
o the consumer IOTP aware application determines which Payment
Instrument(s) match the chosen Brand, and selects, perhaps with
user assistance, the correct Payment Instrument to use.
[Note] Dual Brands need no special treatment by the Merchant and
therefore no explicit reference is made to Dual Brands in
the DTD. This is because, as far as the Merchant is
concerned, each Brand in a Dual Brand is treated as a
separate Brand. It is at the Consumer, that the matching of
a Brand to a Dual Brand Payment Instrument needs to be done.
[Note End]
3.6.4 Definition of Promotional Brand
A Promotional Brand means that, if the Consumer pays with that Brand,
then the Consumer will receive some additional benefit which can be
received in two ways:
o at the time of purchase. For example if a Consumer pays with a
"Walmart MasterCard" at a Walmart web site, then a 5% discount
might apply, which means the consumer actually pays less,
o from their Payment Instrument (card) issuer when the payment
appears on their statement. For example loyalty points in a
frequent flyer scheme could be awarded based on the total
payments made with the Payment Instrument since the last
statement was issued.
Note that:
o the first example (obtaining the benefit at the time of
purchase), requires that:
- the Consumer is informed of the benefits which arise if that Brand
is selected
- if the Brand is selected, the Merchant changes the relevant IOTP
Components in the Offer Response to reflect the correct amount to
be paid
o the second (obtaining a benefit through the Payment Instrument
issuer) does not require that the Offer Response is changed
o each Promotional Brand should be identified as a separate Brand
in the list of Brands offered by the Merchant. For example:
"Walmart", "Sears", "Marks and Spencer" and "American Advantage
Visa", would each be a separate Brand.
3.6.5 Identifying Promotional Brands
There are two problems which need to handled in identifying
Promotional Brands:
o how does the Merchant or their Payment Handler positively
identify the promotional brand being used at the time of
purchase
o how does the Consumer reliably identify the correct promotional
brand from the Brand List presented by the Merchant
The following is a description of how this could be achieved.
[Note] Please note that the approach described here is a model
approach that solves the problem. Other equivalent methods
may be used.
[Note End]
3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a Promotional
Brand is important since a Consumer might fraudulently claim to have a
Promotional Brand that offers a reduced payment amount when in reality
they do not.
Two approaches seem possible:
o use some feature of the Payment Instrument or the payment
method to positively identify the Brand being used. For
example, the SET certificate for the Brand could be used, if
one is available, or
o use the Payment Instrument (card) number to look up information
about the Payment Instrument on a Payment Instrument issuer
database to determine if the Payment Instrument is a
promotional brand
Note that:
o the first assumes that SET is available.
o the second is only possible if the Merchant, or alternatively
the Payment Handler, has access to card issuer information.
IOTP does not provide the Merchant with Payment Instrument information
(e.g. a card or account number). This is only sent as part of the
encapsulated payment protocol to a Payment Handler. This means that:
o the Merchant would have to assume that the Payment Instrument
selected was a valid Promotional Brand, or
o the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the
payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer.
3.6.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand
are:
o the Consumer visually matching a logo for the Promotional Brand
which has been provided to the Consumer by the Merchant,
o the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered against
a similar code contained in the list of Brands offered by the
Merchant.
In the latter case, the code contained in the Consumer wallet must
match exactly the code in the list offered by the Merchant otherwise
no match will be found. Ways in which the Consumer's IOTP Aware
Application could obtain such a code include:
o the Consumer types the code in directly. This is error prone
and not user friendly, also the consumer needs to be provided
with the code. This approach is not recommended,
o using some information contained in the software or other data
associated with the Payment Instrument. This could be:
- a SET certificate for Brands which use this payment method
- a code provided by the payment software which handles the
particular payment method, this could apply to, for example,
GeldKarte, Mondex, CyberCash and DigiCash
o the consumer making a initial "manual" link between a
Promotional Brand in the list of Brands offered by the Merchant
and an individual Payment Instrument, the first time the
promotional brand is used. The IOTP Aware application would
then "remember" the code for the Promotional Brand for use in
future purchases
[Note] It is not the intention of the developers of this
specification to develop a prescriptive list of payment
brands. It is anticipated that owners of brands will develop
distinctive names for Brands which should mean that name
clashes are unlikely.
[Note End]
3.7 Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting IOTP Baseline IOTP defines a minimum protocol which systems supporting IOT
must be able to accept. As new versions of IOTP are developed, must be able to accept. As new versions of IOTP are developed,
additional types of IOTP Transactions will be defined. In addition to additional types of IOTP Transactions will be defined. In addition to
this, Baseline and future versions of IOTP will support user this, Baseline and future versions of IOTP will support user
extensions to IOTP through 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.7.1 Extra XML Elements 3.6.1 Extra XML Elements
The XML element and attribute names used within IOTP constitute an The XML element and attribute names used within IOTP constitute an
[XML Namespace] as identified by the xmlns attribute on the OtpMessage [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 o any new XML element must be declared according to the rules
[XML Namespaces] for [XML Namespaces]
o new XML elements which are either Trading Blocks or Trading o new XML elements which are either Trading Blocks or Trading
Components must contain an ID attributes with an attribute name Components must contain an ID attributes with an attribute
of ID. name of ID.
In order to make sure that extra XML elements can be processed In order to make sure that extra XML elements can be processed
properly, IOTP reserves the use of a special attribute, IOTP:Critical, properly, IOTP reserves the use of a special attribute, IOTP:Critical
which takes the values True or False and may appear in extra elements which takes the values True or False and may appear in extra elements
added to an IOTP message. 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 t
determine if the IOTP transaction can safely continue. Specifically: determine if the IOTP transaction can safely continue. Specifically:
o if an extra XML element has an "IOTP:Critical" attribute with a o if an extra XML element has an "IOTP:Critical" attribute
value of "True" and an IOTP aware application does not know how with a value of "True" and an IOTP aware application does
to process the element and its child elements, then the IOTP not know how to process the element and its child elements,
transaction has a Technical Error (see section 4.1) and must then the IOTP transaction has a Technical Error (see
fail. section 4.1) and must fail.
o if an extra XML element has an "IOTP:Critical" attribute with a o if an extra XML element has an "IOTP:Critical" attribute
value of "False" then the IOTP transaction may continue if the with a value of "False" then the IOTP transaction may
IOTP aware application does not know how to process it. In this continue if the IOTP aware application does not know how to
case: process it. In this case:
- any extra XML elements contained within an XML element defined - any extra XML elements contained within an XML element defined
within the IOTP namespace, must be included with that element within the IOTP namespace, must be included with that element
whenever the IOTP XML element is used or copied by IOTP whenever the IOTP XML element is used or copied by IOTP
- the content of the extra element must be ignored except that it - the content of the extra element must be ignored except that
must be included when it is used in the creation of a digest as it must be included when it is used in the creation of a
part of the generation of a signature digest as part of the generation of a signature
o if an extra XML element has no "IOTP:Critical" attribute then o if an extra XML element has no "IOTP:Critical" attribute
it must be treated as if it had an "IOTP:Critical" attribute then it must be treated as if it had an "IOTP:Critical"
with a value of "True" attribute with a value of "True"
o if an XML element contains an "IOTP:Critical" attribute, then o if an XML element contains an "IOTP:Critical" attribute,
the value of that attribute is assumed to apply to all the then the value of that attribute is assumed to apply to all
child elements within that element the child elements within that element
In order to ensure that documents containing "IOTP:Critical" are In order to ensure that documents containing "IOTP:Critical" are
valid, it is declared as part of the DTD for the extra element as: valid, it is declared as part of the DTD for the extra element as:
IOTP:Critical (True | False ) #TRUE IOTP:Critical (True | False ) #TRUE
3.7.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.8) should be used to encapsulate the Content Element (see section 3.7) should be used to encapsulate the
data. data.
3.7.3 Values for IOTP Codes 3.7 Packaged Content Element
Codes used by IOTP are registered by [IANA] so that new values can be
co-ordinated based on an IETF consensus as defined in RFC 2434.
The element types, attributes names to which this procedure applies is
shown in the table below together with the original values for
attributes which apply. For more up-to-date information on valid
values and how these relate to versions of the IOTP specification
contact IANA.
Element Type Attribute Attribute Values
Name
AuthData AuthMethod sha1
signature
pay:ppp where ppp may be set to any
valid value for iotpbrand (see below)
Brand BrandId SET:setbrand where setbrand is a brand
which is accepted by the [SET] payment
protocol
IOTP:iotpbrand where iotpbrand may be:
o GeldKarte
o Mondex
CurrencyAmount CurrCode TBD. Codes which apply when the
CurrCodeType attribute is set to IOTP
are to be defined
CurrencyAmount CurrCodeType ISO4217
IOTP
DeliveryData DelivMethod Post
Web
Email
PackagedContent Content PCDATA
MIME
MIME:mimetype (where mimetype must be
the same as content-type as defined by
[MIME] )
XML
PayProtocol ProtocolId The values of ProtocolId are to be
defined by the payment scheme/method
owners.
RelatedTo Relationship OtpTransaction
Type
Reference
Status StatusType Offer
Payment
Delivery
Authentication
TradingRole TradingRole Consumer
Merchant
PaymentHandler
DeliveryHandler
DelivTo
CustCare
TransId OtpTransType BaselineAuthentication
BaselineDeposit
BaselinePurchase
BaselineRefund
BaselineWithdrawal
BaselineValueExchange
BaselineInquiry
BaselinePing
Attibute Content OfferResponse
(within
Signature PaymentResponse
Component)
DeliveryResponse
AuthenticationRequest
AuthenticationResponse
PingRequest
PingResponse
However there is still a need for developers to experiment using new
IOTP codes. For this reason, "user defined codes" may be used to
identify additional values for the codes contained within this
specification with the need for them to be registered with IANA.
The definition of a user defined code is as follows:
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
NameChar NameChar has the same definition as the [XML]
definition of NameChar
Use of domain names (see [DNS]) to make user defined codes unique is
recommended although this method cannot be relied upon.
3.8 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 transporting systems and to ensure XML compatibility. Examples of its
use 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 o to encapsulate a description of an order, a payment note,
delivery note. or a 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 NMTOKEN #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='FirstMsg'> <PackagedContent Name='FirstPiece'>
snroasdfnas934k snroasdfnas934k
</PackagedContent> </PackagedContent>
<PackagedContent Name='SecondMsg'> <PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45 dvdsjnl5poidsdsflkjnw45
</PackagedContent> </PackagedContent>
</ABCD> </ABCD>
The name attribute may be omitted, for example The name attribute may be omitted, for example
if there is only one Packaged Content element. if 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
skipping to change at page 68, line 11 skipping to change at page 53, line 26
to be encoded either as the XML default to be encoded either as the XML default
entities, or as numeric character entities. entities, or as numeric character entities.
o XML. The content of the Packaged Content o XML. The content of the Packaged Content
Element can be treated as an XML document. Element can be treated as an XML document.
Entities and CDATA sections, or Transform set Entities and CDATA sections, or Transform set
to BASE64, must be used to ensure that the to BASE64, must be used to ensure that the
Packaged Content Element contents are Packaged Content Element contents are
legitimate PCDATA. legitimate PCDATA.
Values of the Content attribute are controlled Values of the Content attribute are controlled
under the procedures defined in section 3.7.3 under the procedures defined in section 12 IANA
Values for IOTP Codes which also allows user Considerations which also allows user defined
defined values to be defined. values to be defined.
Transform This identifies the transformation that has been Transform This identifies the transformation that has been
done to the data before it was placed in the done to the data before it was placed in the
content. Valid values are: content. Valid values are:
o NONE. The PCDATA content of the Packaged o NONE. The PCDATA content of the Packaged
Content Element is the correct representation Content Element is the correct representation
of the data. Note that entity expansion must of the data. Note that entity expansion must
occur first (i.e. replacement of &amp; and occur first (i.e. replacement of &amp; and
&#9;) before the data is examined. CDATA &#9;) before the data is examined. CDATA
sections may legitimately occur in a Packaged sections may legitimately occur in a Packaged
skipping to change at page 68, line 40 skipping to change at page 54, line 5
Content: Content:
PCDATA This is the actual data which has been embedded. PCDATA This is the actual data which has been embedded.
The format of the data and rules on how to The format of the data and rules on how to
decode it are contained in the Content and the decode it are contained in the Content and the
Transform attributes Transform attributes
Note that any special details, especially custom attributes, must be Note that any special details, especially custom attributes, must be
represented at a higher level. represented at a higher level.
3.8.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 o references to any documents, images or other things, such
sounds or web pages, which can affect the recipient's as sounds or web pages, which can affect the recipient's
understanding of the data which is being packaged must refer to understanding of the data which is being packaged must
other Packaged Elements contained within the same parent refer to other Packaged Elements contained within the same
element, e.g. an Order Description parent element, e.g. an Order Description
o if more than one Packaged Content element is included within a
parent element in order to meet the previous requirement, then
the Name attribute of the top level Packaged Content from which
references to all other Packaged Elements can be determined,
should have a value of Main. This means that the "Main"
Packaged Content element must not be referred to from the HTML
in any other Packaged Content
o relative references to other documents, images, etc. from one o if more than one Packaged Content element is included
Packaged Content element to another are realised by setting the within a parent element in order to meet the previous
value of the relative reference to the Name attribute of requirement, then the Name attribute of the top level
another Packaged Content element at the same level and within Packaged Content from which references to all other
the same parent element Packaged Elements can be determined, should have a value of
Main
o relative references to other documents, images, etc. from
one Packaged Content element to another are realised by
setting the value of the relative reference to the Name
attribute of another Packaged Content element at the same
level and within the same parent element
o no external references that require the reference to be o no external references that require the reference to be
resolved immediately should be used. As this could make the resolved immediately should be used. As this could make the
HTML difficult or impossible to display completely HTML difficult or impossible to display completely
o [MIME] is used to encapsulate the data inside each Packaged o [MIME] is used to encapsulate the data inside each Packaged
Element. This means that the information in the MIME header Element. This means that the information in the MIME header
used to identify the type of data which has been encapsulated used to identify the type of data which has been
and therefore how it should be displayed. encapsulated and 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 Attributes allocated to Packaged Content elements should
make it possible to extract each Packaged Content into a make it possible to extract each Packaged Content into a
directory and then display the HTML directly directory and then display the HTML directly
[Note End] [Note End]
3.9 Identifying Languages 3.7.2 Packaging XML
IOTP uses [XML] Language Identification to specify which languages are Support for XML is recommended. When XML needs to be displayed, for
example to display the content of an Order Description to a Consumer,
then implementers should follow the latest recommendations of the
World Wide Web Consortium.
[Note] At the time of writing this specification, standards are
under development that specify XML style sheets that show
how XML documents should be displayed. See:
o "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl, and
o "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet.
Once these standards become W3C "Recommendations", then it
is anticipated that this specification will be amended if
practical.
[Note End]
3.8 Identifying Languages
IOTP uses [XML] Language Identification to specify which languages ar
used within the content and attributes of IOTP Messages. used within the content and attributes of IOTP Messages.
The following principles have been used in order to determine which The following principles have been used in order to determine which
XML elements contain an xml:lang Attributes: XML elements contain an xml:lang Attributes:
o a mandatory xml:lang attribute is contained on every Trading o a mandatory xml:lang attribute is contained on every
Component which contains attributes or content which may need Trading Component which contains attributes or content
to be displayed or printed in a particular language which may need to be displayed or printed in a particular
o an optional xml:lang attribute is included on child elements of language
these Trading Components. In this case the value of xml:lang,
if present, overrides the value for the Trading Component. o an optional xml:lang attribute is included on child
elements of these Trading Components. In this case the
value of xml:lang, if present, overrides the value for the
Trading Component.
xml:lang attributes which follow these principles are included in the xml:lang attributes which follow these principles are included in the
Trading Components and their child XML elements defined in section 6. Trading Components and their child XML elements defined in section 7.
3.10 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 secured using, for example, encryption methods such as
[SSL], and
o "Insecure" Net Locations where privacy of data is not assured.
Where both types of net location are present, the following rules o "Secure" Net Locations which are net locations where
apply: privacy of data is secured using, for example, encryption
methods such as [SSL/TLS], and
o "Insecure" Net Locations where privacy of data is not
assured.
o 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.
o if only one of the two Net Locations is present, then the one If only one of the two Net Locations is present, then the one present
present must be used must be used.
o if both are present, then the either may be used depending on Where both types of net location are present then either may be used
the preference of the sender of the message. depending on the preference of the sender of the message.
3.11 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.11.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 [Note] The Cancel Block can be sent asynchronously of any other
IOTP Message. Specifically it can be sent either before IOTP Message. Specifically it can be sent either before
sending or after receiving an IOTP Message from the other sending or after receiving an IOTP Message from the other
Trading Role Trading Role
[Note End] [Note End]
If an IOTP Transaction is cancelled during a Trading Exchange (i.e. If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
the interval between sending a _request_ block and receiving the the interval between sending a "request" block and receiving the
matching _response_ block) then the Cancel Block is sent to the same matching "response" block) then the Cancel Block is sent to the same
location as the next IOTP Message in the Trading Exchange would have location as the next IOTP Message in the Trading Exchange would have
been sent. been sent.
If a Consumer cancels a transaction after a Trading Exchange has If a Consumer cancels a transaction after a Trading Exchange has
completed (i.e. the "response" block for the Trading Exchange has been completed (i.e. the "response" block for the Trading Exchange has bee
received), but before the IOTP Transaction has finished then the received), but before the IOTP Transaction has finished then the
Consumer sends a Cancel Block with an appropriate Status Component to Consumer sends a Cancel Block with an appropriate Status Component to
the net location identified by the SenderNetLocn or the net location identified by the SenderNetLocn or
SecureSenderNetLocn contained in the Protocol Options Component SecureSenderNetLocn contained in the Protocol Options Component (see
contained in the TPO Block for the transaction. This is normally the section 7.1) contained in the TPO Block (see section 8.1) for the
Merchant Trading Role. transaction. This is normally the Merchant Trading Role.
A Consumer should not send a Cancel Block after the IOTP Transaction. A Consumer should not send a Cancel Block after the IOTP Transaction
Cancelling a complete should be treated as a technical error. has completed. Cancelling a complete transaction should be treated as
a technical error.
After cancelling the IOTP Transaction, the Consumer should go to the After cancelling the IOTP Transaction, the Consumer should go to the
net location specified by the CancelNetLocn attribute contained in the net location specified by the CancelNetLocn attribute contained in th
Trading Role Element for the organisation that was sent the Cancel Trading Role Element for the organisation that was sent the Cancel
Block. Block.
A non-Consumer Trading Role should only cancel a transaction: A non-Consumer Trading Role should only cancel a transaction:
o after a request block has been received and o after a request block has been received and
o before the response block has been sent o before the response block has been sent
If a non-Consumer Trading Role cancels a transaction at any other time If a non-Consumer Trading Role cancels a transaction at any other tim
it should be treated by the recipient is an error. it should be treated by the recipient as an error.
3.11.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 Transaction when cancellation is allowed, then the Consumer should
stop 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 Tradin
Role should anticipate that the Consumer may go to the location Role should anticipate that the Consumer may go to the location
specified by the CancelNetLocn attribute contained in the Trading Role specified by the CancelNetLocn attribute contained in the Trading Rol
Element for the 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 composed of a number of Trading Blocks which contain a number of
Trading Components. There are a several interrelated considerations in Trading Components. There are several interrelated considerations in
handling errors, re-transmissions, duplicates, and the like. These handling errors, re-transmissions, duplicates, and the like. These
factors mean IOTP aware applications must manage message flows more factors mean IOTP aware applications must manage message flows more
complex than the simple request/response model. Also a wide variety of complex than the simple request/response model. Also a wide variety o
errors can occur in messages as well as at the transport level or in errors can occur in messages as well as at the transport level or in
Trading Blocks or Components. Trading Blocks or Components.
This section describes at a high level how IOTP handles errors, This section describes at a high level how IOTP handles errors,
retries and idempotency. It covers: retries and idempotency. It covers:
o the different types of errors which can occur. This is divided o the different types of errors which can occur. This is
into: divided into:
- "technical errors" which are independent of the meaning of the - "technical errors" which are independent of the purpose of the
IOTP Message, IOTP Message,
- "business errors" which indicate that there is a problem specific - "business errors" which indicate that there is a problem
to the process (e.g. payment or delivery) which is being carried specific to the process (e.g. payment or delivery) which is
out, and being carried out, and
o the depth of the error which indicates whether the error is at o the depth of the error which indicates whether the error is
the transport, message or block/component level at the transport, message or block/component level
o how the different trading roles should handle the different o how the different trading roles should handle the different
types of messages which they may receive. 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 th
message. This means, they can affect any attempt at IOTP message. This means, they can affect any attempt at IOTP
communication. Typically they are handled in a standard fashion with a communication. Typically they are handled in a standard fashion with
limited number of standard options for the user. Specifically these limited number of standard options for the user. Specifically these
are: 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 When communications are operating sufficiently well, a technical erro
is indicated by an Error Component (see section 0) in an Error Block is indicated by an Error Component (see section 7.20) in an Error
(see section 7.17) sent by the party which detected the error in an Block (see section 8.17) sent by the party which detected the error i
IOTP message to the party which sent the erroneous message. 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 reac
its destination. In this case a time-out might occur. its destination. In this case a time-out might occur.
The Error Codes associated with Technical Errors are recorded in Error The Error Codes associated with Technical Errors are recorded in the
Components 6.19) which lists all the different technical errors which Error Component which lists all the different technical errors which
can 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, a
offer, payment, delivery or authentication, where each process has a offer, payment, delivery or authentication, where each process has a
different set of possible business errors. different set of possible business errors.
For example, "Insufficient funds" is a reasonable payment error but For example, "Insufficient funds" is a reasonable payment error but
makes no sense for a delivery while "Back ordered" is a reasonable makes no sense for a delivery while "Back ordered" is a reasonable
delivery error but not meaningful for a payment. Business errors are delivery error but not meaningful for a payment. Business errors are
indicated in the Status Component (see section 6.14) of a "response indicated in the Status Component (see section 7.15) of a "response
block" of the appropriate type, for example a Payment Response Block block" of the appropriate type, for example a Payment Response Block
or a Delivery Response Block. This allows whatever additional response or a Delivery Response Block. This allows whatever additional respons
related information is needed to accompany the error indication. 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 ca
decide what to do next. For example, if the error is insufficient decide what to do next. For example, if the error is insufficient
funds in a Brand Independent Offer (see section 8.1.2.2), the user funds in a Brand Independent Offer (see section 9.1.2.2), the user
might wish to choose a different payment instrument/account of the might wish to choose a different payment instrument/account of the
same brand or a different brand or payment system. Alternatively, if same brand or a different brand or payment system. Alternatively, if
the IOTP based implementation allows it and it makes sense for that the IOTP based implementation allows it and it makes sense for that
instrument, the user might want to put more funds into the instrument, the user might want to put more funds into the
instrument/account and try again. 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 The three levels at which IOTP errors can occur are the transport
level, the message level, and the block level. Each is described level, the message level, and the block level. Each is described
skipping to change at page 75, line 20 skipping to change at page 60, line 12
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 either an explicit transport level error indication, such as a "No
route to destination" error from TCP/IP, or by a time out where no route to destination" error from TCP/IP, or by a time out where no
response has 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 errors is to retry and, after some number of automatic retries, to
inform 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 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 Appropriate time outs to use are a function of both the transport
being used and of the payment system if the request encapsulates being used and of the payment system if the request encapsulates
payment information. The transport and payment system specific payment information. The transport and payment system specific
documentation should be consulted for time out and automatic retry documentation should be consulted for time out and automatic retry
parameters. Frequently there is no way to directly inform the other parameters. Frequently there is no way to directly inform the other
party of transport level errors but they should generally be logged party of transport level errors but they should generally be logged
and if automatic recovery is unsuccessful and there is a human user, and if automatic recovery is unsuccessful and there is a human user,
the 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 th
message is too large for the receiver to handle or there are errors in message is too large for the receiver to handle or there are errors i
the Transaction Reference Block (see section 3.3) so it is not the Transaction Reference Block (see section 3.3) so it is not
possible to figure out what transaction the message relates to. possible to figure out what transaction the message relates to.
All message level errors are technical errors and are indicated by an All message level errors are technical errors and are indicated by
Error Components (see section 6.19) sent to the other party. The Error Error Components (see section 7.20) sent to the other party. The Erro
Component includes a Severity attribute which indicates whether the Component includes a Severity attribute which indicates whether the
error is a Warning and may be ignored, a TransientError which error is a Warning and may be ignored, a TransientError which
indicates that a retry may resolve the problem or a HardError in which indicates that a retry may resolve the problem or a HardError in whic
case the transaction must fail. case the transaction must fail.
The Technical Errors (see section 6.19.2 Error Codes) that are Message The Technical Errors (see section 7.20.2 Error Codes) that are Messag
Level errors are: Level errors are:
o XML not well formed. The document is not well formed XML (see o XML not well formed. The document is not well formed XML
[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 o block level technical errors (see section 4.3.3) on the
Transaction Reference Block (see section 3.3) and the Signature Transaction Reference Block (see section 3.3) and the
Block only. Checks on these blocks should only be carried out Signature Block only. Checks on these blocks should only be
if the XML is valid carried out if the XML is valid
Note that checks on the Signature Block include checking, where
Note that checks on the Signature Block includes checking, where
possible, that each Signature Component is correctly calculated. If possible, that each Signature Component is correctly calculated. If
the Digital Signature Element is incorrectly calculated then the data the Signature is incorrectly calculated then the data that should hav
that should have been covered by the signature can not be trusted and been covered by the signature can not be trusted and must be treated
must be treated as erroneous. A description of how to check a as erroneous. A description of how to check a signature is correctly
signature is correctly calculated is contained in section 5.2 Checking calculated is contained in section 6.2.
a Signature is Correctly Calculated.
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 Signature Blocks). The message has been transported properly, the
overall message structure and the block/component(s) including the overall message structure and the block/component(s) including the
Transaction Reference and Signature Blocks are meaningful but there is Transaction Reference and Signature Blocks are meaningful but there i
some error related to one of the other blocks. 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: Technical Errors are further divided into:
o Block Level Attribute and Element Checks, and o Block Level Attribute and Element Checks, and
o Block and Component Consistency Checks o Block and Component Consistency Checks
o Transient Technical Errors
If a technical error occurs related to a block or component, then an If a technical error occurs related to a block or component, then an
Error Component is returned and, unless it is merely a warning, the Error Component is generated for return.
usual response block is suppressed.
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 o checking that each attribute value within each element in a
block conforms to any rules contained within this IOTP block conforms to any rules contained within this IOTP
specification specification
o checking that the content of each element conforms to any rules o checking that the content of each element conforms to any
contained within this IOTP specification rules contained within this IOTP specification
o if the previous checks are OK, then checking the
o if the previous checks are OK, then checking the consistency of consistency of attribute values and element content against
attribute values and element content against other attribute other attribute values or element content within any other
values or element content within any other components in the components in the same block.
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 o checking that the combination of blocks and/or components
present in the IOTP Message are consistent with the rules present in the IOTP Message are consistent with the rules
contained within this IOTP specification contained within this IOTP specification
o checking for consistency between attributes and element content o checking for consistency between attributes and element
within the blocks within the same IOTP message. content within the blocks within the same IOTP message.
o checking for consistency between attributes and elements in o checking for consistency between attributes and elements in
blocks in this IOTP message and blocks received in earlier IOTP blocks in this IOTP message and blocks received in earlier
messages for the same IOTP transaction IOTP messages for the same IOTP transaction
4.3.3.3 Block Business Errors If the block passes the "Block Level Attribute and Element Checks" an
the "Block and Component Consistency Checks" then it is processed
either by the IOTP Aware application or perhaps by some "back-end"
system such as a payment server.
4.3.3.3 Transient Technical Errors
During the processing of the Block some temporary failure may occur
that can potentially be recovered by the other trading role re-
transmitting, at some slightly later time, the original message that
they sent.
In this case the other role is informed of the Transient Error by
sending them an Error Component (see section 7.20) with the Severity
Attribute set to TransientError and the MinRetrySecs attribute set to
some value suitable for the Transport Mechanism and/or payment
protocol being used (see appropriate Transport and payment protocol
Supplements).
Note that transient technical errors can be generated by any of the
Trading Roles involved in transaction.
4.3.3.4 Block Level Business Errors
If a business error occurs in a process such as a Payment or a If a business error occurs in a process such as a Payment or a
Delivery, then the appropriate type of response block is returned. The Delivery, then the appropriate type of response block is returned
Status Component (see section 6.14) within that response block containing a Status Component (see section 7.15) with the ProcessStat
indicates the error and its severity. No Error Component or Error attribute set to Failed and the CompletionCode indicating the nature
Block is generated for business errors. of the problem.
Some business errors may be "transient" in that the Consumer role may
be able to recover and complete the transaction in some other way. Fo
example if the Credit Card that a consumer provided had insufficient
funds for a purchase, then the Consumer may recover by using a
different credit card.
Recovery from "transient" business errors is dependent on the
CompletionCode. See the definition of the Status Component for what i
possible.
Note that no Error Component or Error Block is generated for business
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 state changing action transmission/receipt of the "same" request for an action that will
not result in that action occurring more than once. This is called change state does not result in that action occurring more than once.
idempotency. For example, a customer paying for an order would want to This is called idempotency. For example, a customer paying for an
pay the full amount only once. Most network transport mechanisms have order would want to pay the full amount only once. Most network
some probability of delivering a message more than once or not at all, transport mechanisms have some probability of delivering a message
perhaps requiring retransmission. On the other hand, a request for more than once or not at all, perhaps requiring retransmission. On th
status can reasonably be repeated and should be processed fresh each other hand, a request for status can reasonably be repeated and shoul
time it is received. be processed fresh each time it is received.
Correct implementation of IOTP can be modelled by a particular Correct implementation of IOTP can be modelled by a particular
processing order as detailed below. Any other method that is processing order as detailed below. Any other method that is
indistinguishable in the messages sent between the parties is equally indistinguishable in the messages sent between the parties is equally
acceptable. acceptable.
4.4.1 Server Role Processing Sequence 4.5 Server Role Processing Sequence
"Server roles" are any Trading Role which is not the Consumer role. "Server roles" are any Trading Role which is not the Consumer role.
They are "Server roles" since they typically receive a request which They are "Server roles" since they typically receive a request which
they must service and then produce a response. they must service and then produce a response. However server roles
can also initiate transactions. More specifically Server Roles must b
able to:
The model processing sequence for a Server role is indicated in the o Initiate a transaction (see section 4.5.1). These are
diagram below. divided into:
- payment related transactions and
- infrastructure transactions
o Accept and process a message received from another role
(see 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
| Input | been received in a reasonable time (see section 4.5.4).
| IOTP Message|
-------------
|
v
1. Check for transport -------------->
or message level errors Errors |
|OK |
v |
11. Generate output <-------2. More Blocks <----------------- + -
message No to process? | |
| |Yes | |
v v | |
------------- 3. Check Block OK ---------------> | |
| Output | | Errors | |
| IOTP Message| |Checks OK | |
------------- v | |
---------4. Type of Block ? ------- | |
| | | | | |
---------Status Action Encapsulating Error | |
| Request Request Block Block | |
| | | | | |
| v v v | |
| 6a. Action 7. Process 8.Error | |
| Request - encapsulated Block ? | |
| received message and | | |
| before?-- generate -- v | |
| | | response | STOP --- |
| |Yes |No OK| | | |
| v v | |Errors v |
| 6b. Processing 6e. Process Action | ------> 9. Gen |
| of Block Request & generate-+--------->Error |
| Complete ?- response block- | Errors Block & |
| | | ^ | | store |
| | | | | | | |
| |Yes |No | Ok or | | | |
| | --- | Warning | -------- | |
v v v | v | | |
5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | |
Status and resend process request & | | |
Response previous completion response | | |
Block Block block | | |
| | | v v |
---------------------------------------------- 10. Add block--
to output
message
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 4.5.1 Initiating Transactions
Figure 10 Server Role Processing Sequence Server Roles may initiate a variety of different types of transaction
Specifically:
Each of the processes in the sequence is described in more detail o an Inquiry Transaction (see section 9.2.1)
below.
4.4.1.1 Check for Transport or Message Level Error o a Ping Transaction (see section 9.2.2)
On receipt of an IOTP request message (step 1), first check for o an Authentication Transaction (see section 9.1.6)
transport or message level errors (see sections 4.3.1 and 4.3.2).
These are errors which indicate that the entire message is corrupt and
can not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information in
the message can not be reliably accessed.
If the OtpTransId attribute in the Transaction Id Component (see o a Payment Related Transaction such as:
section 3.3.1) can be determined, set up a response message with an - a Deposit (see section 9.1.7)
appropriate Error Component. Perform local actions such as making log - a Purchase (see section 9.1.8)
entries. - a Refund (see section 9.1.9)
- a Withdrawal (see section 9.1.10)
- a Value Exchange (see section 9.1.11)
If the value of the OtpTransId attribute is not recognised as 4.5.2 Processing Input Messages
belonging to an IOTP transaction when other Blocks in the IOTP Message
indicate that it should be recognised, then report the error using an
Error Component with a Severity of HardError, an ErrorCode set to
AttValNotRecog (attribute value not recognised), and an Error Location
element (see section 6.19.3) that points to the OtpTransId attribute.
No idempotency related actions are necessary. Processing input messages involves the following:
4.4.1.2 Process all the blocks o checking the structure and identity of the message
If there are no message level errors, process each of the blocks o checking for and handling duplicate messages
within the message which has not been processed (step 2).
Once all the blocks have been processed, generate a response message o processing non-duplicate original messages which includes:
(step 11) and send it to the requester unless there are fatal - checking for errors, then if no errors are found
transport level problems. As recommended for the particular transport - processing the message to produce an output message if
used, a limited number of automatic response retransmission attempts appropriate
may be appropriate. Each of these is discussed in more detail below.
It may be desirable to log the complete response message at the 4.5.2.1 Checking Structure and Message Identity
server. Failure of the requester to receive a response may lead to a
time-out and a retransmission of the request. Following the procedures
above, a duplicate request message should produce a duplicate of the
previous response except for changes in status and transient error
conditions that have changed.
4.4.1.3 Check the Block is OK It is critical to check that the message is "well formed" XML and tha
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.
Check the block is OK (see section 4.3.3). For each block level If the input message is not well formed then generate an Error
technical error found, an appropriate Error Component should be Component with a Severity of HardError and ErrorCode of
created to be included in the IOTP Message sent back to the Consumer. XmlNotWellFrmd.
Note that some checking of the Transaction Reference Block and the
Signature Block has occurred as part of Message Level error checking.
If one or more of the Error Components contain a Severity attribute If the message is well formed but the IotpTransId cannot be identifie
with a value of TransientError or HardError, then no response block then generate an ErrorComponent with:
need be generated and no further processing of the block, including
idempotency related actions are necessary.
4.4.1.4 Determine the Type of the Block o a Severity of HardError and an ErrorCode of AttMissing,
Trading Blocks that survive the above steps and thus have no errors, o one PackagedContent containing the original Input Message,
or at worst have added a warning error component to the response, can and
receive further processing. The nature of the processing depends (step
4) on whether the block is a Status Request, Action Request, an Error
Block or contains an Encapsulated Message.
4.4.1.5 Status Request Blocks o the second PackagedContent containing "IotpTransId" - the
missing attribute.
Status Request Blocks (step 5) are either: 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.
o Inquiry Request Trading Block (see section 7.12), or 4.5.2.2 Checking/Handling Duplicate Messages
o Ping Request Block (see section 7.14). If the input message can be identified as potentially a valid input
message then check to see if an "identical" input message has been
received before. Identical means that all blocks, components,
elements, attribute values and element content in the input message
are the same.
These status requests do not change state and are processed fresh to If an identical message has been received before then check to see if
get the current status. The appropriate response block should be added the processing of the previous message has completed.
to the IOTP message being composed.
No idempotency actions are required. If processing has not completed then do nothing as the processing of
the previous message will result in a response if required.
4.4.1.6 Action Request Blocks Otherwise, if processing has completed and resulted in an output
message then retrieve the last message that was sent and send it
again.
Blocks which request an action and change state need to be subject to If the message is not a duplicate then it should be processed.
idempotency duplicate filtering by checking to see if the same block
for the same transaction has been previously stored (step 6a) at the
server as described later.
If the Block has been received previously then: 4.5.2.3 Processing Non-Duplicate Message
o if processing of the previously stored block is complete (step Once it's been established that the message is not a duplicate, then
6b) then the same IOTP Block as previously produced must be it can be processed. This involves:
included for resending to the Consumer (step 6c).
o if processing is not complete, wait until the processing is o checking that a server is available to handle the message,
complete (step 6d) before sending the response. generating a Transient Error if it is not
If the block has not been received before, the action request is o checking the Transaction is Not Already in error or
processed normally (step 6e) producing a response block that is added cancelled
to the response message. This might or might not indicate a business
error.
If there is a transient error indicated by an Error Component that o validating the input message. This includes:
contains a Severity attribute set to TransientError, then apart from - checking for message level errors
sending the Error Block, no further actions should be taken so the - checking for block level errors
action can be retried. - checking any encapsulated data
If there is no Transient Error, then the transaction id, the request o checking for errors in the sequence that blocks have been
block, and the response block must be stored (step 6f) so they can be received
found as described above (step 6a) should a duplicate IOTP action
request block be received for this transaction in the future.
[Note] Most business errors should be labelled as a TransientError o generating error components for any errors that result
as there is usually some possibility they will be corrected
over time or some user action exists that can fix them. o if no hard errors result, then processing the message and
Requesters are expected to understand business errors and generating an output message, if required, for return to
the appropriate time scale for user actions for retrying. the sender of the Input Message
[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 IotpTransId must be used.
[Note End] [Note End]
4.4.1.7 Encapsulating Blocks Each of the above steps is discussed below.
Blocks which encapsulate a payment protocol (step 7) pass along the CHECKING A SERVER IS AVAILABLE
enclosed information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is thus The process that is handling the input message should check that the
up to the payment system involved to handle error detection and rest of the system is not so busy that a response in a reasonable tim
idempotency. Payment systems adapted for the Internet include cannot be produced.
idempotency handling because duplicates are always possible. Should a
payment system have no idempotency handling, a layer between IOTP and
the payment system must be added to take care of this.
No IOTP level idempotency actions are required for encapsulating If the server is too busy, then it should generate an Error Component
blocks. The payment system must return material to be encapsulated in with a transient error and send it back to the sender of the Input
the IOTP response message along with indications as to whether the Message requesting that the original message be resent after an
exchange will continue or this is the final response and an indication appropriate period of time.
whether an error occurred. If a payment protocol error has occurred,
an Error Component is added to the response block.
4.4.1.8 Error Block Received [Note] Some servers may occasionally become very busy due to
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.
[Note End]
An error block (step 8) should not occur in a request block and should CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
be treated as an unexpected element with a Severity of HardError.
Error Blocks are sent by Consumers to potentially two locations: Check that:
o the _request_ location, i.e. the location from which they o previous messages received or sent did not contain or
received the IOTP message that contained the error, and result in Hard Errors, and
o optionally, the ErrorLogNetLocn which may be a separate o the Transaction has not been cancelled by either the
location maintained for the purpose of logging errors Consumer or the Server Trading Role
The ErrorLogNetLocn block may be the same location as the _request_ If it has then, ignore the message. A transaction with hard errors or
location. In this case, the error block must not considered as a fatal that has been cancelled, cannot be restarted.
error.
In order to avoid loops, no Error Block should be sent to the Consumer CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS
in response to an IOTP Message received from a Consumer where the IOTP
message contains an Error Block with a severity of HardError.
4.4.1.9 Generate Error Block If the transaction is still OK then check for message level errors.
This involves:
If any of the previous steps resulted in an error being detected and o checking the XML is valid
an Error Component being created then generate an Error Block (step 9)
containing the Error Components that describe the error(s).
Unless the error is a "Transient Error", the Error Component(s) and o checking that the elements, attributes and content of the
the request block which caused the Error Components to be generated Transaction Reference Block are without error and conform
should be stored so that it can be reused if the action request is to this specification
received again (step 6a).
"Transient Errors" are not stored so that if the original Response o checking the digital signature which involves:
Block is received again, then it can be processed as if it had never - checking that the Signature value is correctly calculated, and
been received before. - the hash values in the digests are correctly calculated where
the source of the hash value is available.
4.4.1.10 Add Block to Output Message Checking for block level errors involves:
Any Blocks which have been created as a result of processing the block o checking within each block (apart from the Transaction
received are added to the output message. 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
4.4.2 Client Role Processing Sequence 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
Errors in the sequence that blocks arrive depends on the block. Block
where checking for sequence is required are:
o Error and Cancel Blocks. If an Error or Cancel Block refers
to an IOTP transaction that is not recognised then it is a
Hard Error. Do not return an error if Error or Cancel
Blocks have been received for the IOTP Transaction before
to avoid looping.
o Inquiry Request and Response Blocks. If an Inquiry Request
or an Inquiry Response Block refers to an IOTP transaction
that is not recognised then it is a Hard Error
o Authentication Request Block. If an Authentication Request
Block refers to an IOTP transaction that is recognised it
is a Hard Error
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 Status Block does not refer to an IOTP
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 TPO Selection Block doesn't refer to an IOTP
Transaction that is recognised then it is 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 the Payment Request Block refers to an IOTP Transaction
that is not recognised then its OK, otherwise
- if the Payment Request Block refers to IOTP Transaction that
was not for a Payment then it is a Hard Error, otherwise
- if the previous payment CompletedOk OR failed with a non-
recoverable Completion Code then it is a Hard Error, otherwise
- if the 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
[Note End]
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
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 no
saved so that they can be processed afresh when the input message is
received again.
4.5.3 Cancelling a Transaction
This process cancels a current transaction on an IOTP server as a
result of an external request from another system or server. The
processing required is as follows:
o if the IotpTransId of the transaction to be cancelled not
recognised, or complete then fail the request, otherwise
o if the IotpTransId refers to Inquiry Transaction or a Ping
Transaction then fail the request, otherwise
o determine which Document Exchange to cancel and generate a
Cancel Block and send it to the other party
4.5.4 Retransmitting Messages
The server should periodically check for transactions where a message
is expected in return but none has been received after a time that is
dependent on factors such as:
o the Transport Mechanism being used;
o the time required to process encapsulated messages (e.g.
Payment messages) and
o whether or not human input is required.
If no message has been received the original message should be resent
This should occur up to a maximum number of times dependent on the
reliability of the Transport Mechanism being used.
If no response is received after the required time then the
Transaction should be "timed out". In this case, set the process stat
of the transaction to Failed, and a completion code of either:
o TimedOutRcvr if the transaction can potentially recovered
later, or
o TimedOutNoRcvr if the transaction is non-recoverable
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, [Note] A company or organisation that is a Merchant, for example,
may take on the Trading Role of a Consumer when making a may take on the Trading Role of a Consumer when making
purchase or downloading or withdrawing electronic cash. purchases or downloading or withdrawing electronic cash.
[Note End] [Note End]
The model processing sequence for a Client role is indicted in the
diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* More specifically the Consumer Role must be able to:
------------- o Initiate a transaction (see section 4.6.1). These are
| Input | divided into:
| IOTP Message| - payment related transactions and
------------- - infrastructure transactions
|
v
1. Check for transport -->
or message level errors |Errors
|OK |
v |
11.Blocks to be sent?<---------2. More Blocks <-- ------------------
| |No No to process? | ^
Yes| v |Yes | |
v STOP v | |
12. Generate 3. Check Block OK - -->| |
output message | |Errors |
| |Checks OK | |
v v | |
------------- ------ 4. Type of Block ? -----| |
| Output | | | | | | |
| IOTP Message| | ---- | | | |
------------- | | | | | |
------------ | | | | |
| -- | | | |
v v v v | |
Status Action Encapsulating Error | |
Request Response Block Block | |
| | | | | |
| v v v | |
| 6a. Action 7. Process 8a.Error Block---- > Transient |
| Response encapsulated severity ? | Error |
| received message |Hard Error | (retry) |
| before ? | | | | | |
| Yes| |No Ok| | v | WAIT |
| (Ig-| | | | STOP | | |
| nore|) v | | v v |
| | 6b. Process | -------> 9. Generate 8b. |
| | Action | Errors Error Block Retrieve |
| | Response --+----------> & store and resend |
| | Block | Errors | previous |
| | |Ok | | Block(s) |
| | v v | | |
| | 6c. New | | |
| | request | | |
| | required ? | | |
| | No| |Yes 6d. Generate | | |
| | | ---- > Request | | |
| | | Block & Store v v |
v | | | 10. Add Block to |
----------+-------+------------------------> output message |
v v |
--------------------------------------------------->
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* o Accept and process a message received from another role
(see section 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
Figure 11 Client Role Processing Sequence o Cancel a current transaction if requested, for example by
the User (see section 4.6.3)
Each of the processes in the sequence is described in more detail below. o Re-transmit messages if a response was expected but has not
been received in a reasonable time (see section 4.6.4).
4.4.2.1 Check for Transport or Message Level Error 4.6.1 Initiating Transactions
On receipt of an IOTP response message (step 1), first check for The Consumer Role may initiate a number of different types of
transport or message level errors (see sections 4.3.1 and 4.3.2). transaction. Specifically:
These are errors which indicate that the entire message is corrupt and
can not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information in
the message can not be reliably accessed. Set up an error indication
message with an Error Component indicating the error.
If the value of the OtpTransId attribute is not recognised as o an Inquiry Transaction (see section 9.2.1)
belonging to an IOTP transaction when other Blocks in the IOTP Message
indicate that it should be recognised, then report the error using an
Error Component with a Severity of HardError, an ErrorCode set to
AttValNotRecog (attribute value not recognised), and an Error Location
element (see section 6.19.3) that points to the OtpTransId attribute.
On failure to receive an expected response message, the time out o a Ping Transaction (see section 9.2.2)
strategy indicated in the documentation for the transport method being
used should be followed. This may include some number of automatic re-
transmissions of the request. If a user is present, they may be
offered options of continuing to retransmit the request or of
cancelling the transaction.
4.4.2.2 Process all the blocks o an Authentication Transaction (see section 9.1.6)
If there are no transport or message level errors, process each of the 4.6.2 Processing Input Messages
blocks within the message which has not been processed (step 2).
Once all the blocks have been processed, check to see if there are any Processing of Input Messages for a Consumer Role is the same as for a
blocks to be sent (step 11). There may be no blocks to send if the IOTP Server (see section 4.5.2) except in the area of checking for
last response message received was the last message of the Errors in Block Sequence (for an IOTP Server see section 4.5.2.4).
transaction. This is described below
If blocks are to be sent then generate a request message (step 12) and [Note] The description of the processing for an IOTP Server
send it to the server. It may be desirable to log the complete request includes consideration of multi-threading of input messages
message at the client. Failure of the server to receive a response may and multi-tasking of requests. For the Consumer Role -
lead to a time-out and a retransmission of the request. particularly if running on a stand-alone system such as a PC
- use of multi-threading is a decision of the implementer of
the consumer role IOTP solution.
[Note End]
4.4.2.3 Check the Block is OK 4.6.2.1 Check for Errors in Block Sequence
If there are no message level errors process each of the blocks within The handling of the following blocks is the same as for an IOTP Serve
the message (step 2). (see section 4.5.2.4) except that the Consumer Role is substituted fo
IOTP Server Role:
Check the block is OK (see section 4.3.3). For each block level error o Error and Cancel Blocks,
found, an appropriate Error Component should be created to be included
in an Error Component sent back to the Server.
If one or more of the Error Components contain a Severity attribute o Inquiry Request and Response Blocks,
with a value of TransientError or HardError, no further processing of o Authentication Request, Response and Status Blocks.
the block should occur and it is likely that this will result in
termination of the transaction.
4.4.2.4 Determine the Type of the Block For the other blocks a Consumer role might receive, the potential
errors in the sequence that blocks arrive depends on the block. Block
where checking for sequence is required are:
Trading Blocks that survive the above steps and thus have no errors, o TPO Block. Check as follows:
or at worst have added a warning error component to the error - if the input message also contains an Authentication Request
indication message, can receive further processing. The nature of the block and an Offer Response Block then there is a Hard Error,
processing depends (step 4) on whether the block is a Status Response, otherwise
Action Response, an Error Block or contains an Encapsulated Message. - 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
4.4.2.5 Status Response Blocks o Offer Response Block. Check as follows:
- 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
Status Response Blocks (step 4) are either: 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 Inquiry Response Trading Blocks (see section 7.13), or 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 Ping Response Blocks (see section 7.15) 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
In general, such blocks should be considered a status update. The best 4.6.3 Cancelling a Transaction
action to take at the requester may depend on whether this is in
response to a user originated or automatic status request, whether a
status display that could be updated is being presented to the user,
and whether the status response block shows a change in status from a
previous response block for the same type of status. Thus client
detection of duplication in successive status response blocks may be
useful.
4.4.2.6 Action Response Blocks This process cancels a current transaction on an Consumer role's
system as a result of an external request from the user, or another
system or server in the Consumer's role. The processing is the same a
for an IOTP Server (see section 4.5.3).
Check to determine if the Block has been received previously (step 4.6.4 Retransmitting Messages
6a). If it has then it should be ignored.
These indicate an action taken at the server in response to an action The process of retransmitting messages is the same as for an IOTP
request block or a business error. If the response indicates success Server (see section 4.5.4).
the block should be processed (step 6b) and, if required by the
transaction (step 6c), another Action Request Block generated and
stored (step 6d).
The Response Block should always be stored with the transaction id 5. Security Considerations
until the transaction is terminated. If the Response Block indicates a
transient business error, appropriate manually chosen or automatic
steps to fix the problem or cancel the transaction should be provided.
4.4.2.7 Encapsulating Blocks This section considers, from an IETF perspective how IOTP addresses
security. The next section (see section 6. Digital Signatures and
IOTP) describes how IOTP uses Digital Signatures when these are
needed.
Blocks which encapsulate a payment protocol (step 7) pass along the This section covers:
enclosed information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is up o determining whether to use digital signatures
to the payment system involved to handle error detection and
idempotency. Payment systems adapted for the Internet include
idempotency handling because duplicates are always possible. Should a
payment system have no idempotency handling, a layer between IOTP and
the payment system must be added to take care of this.
No IOTP level idempotency actions are required for encapsulating o data privacy, and
blocks. The payment system must return an indication of whether an
error occurred. In addition, for a continuing exchange, it must return
material to be encapsulated in the next IOTP request/exchange (step
6d). If the response was a final response for that payment exchange
and there was an error, the payment system may optionally return
material to be encapsulated in the error indication.
4.4.2.8 Error Block o payment protocol security.
An error block in a response (step 8a) indicates some problem was 5.1 Determining whether to use digital signatures
detected by the server. If all of the error components are warnings,
they may be optionally logged and/or presented to the user.
Transient errors may be used to provide a manual or automatic The use of digital signatures within IOTP are entirely optional. IOTP
resending (step 8b) of a block previously stored or alternatively may can work successfully entirely without the use of digital signatures.
result in transaction cancellation. Hard errors will always terminate
the transaction, unless they are in optional blocks, with appropriate
indication to he user.
4.4.2.9 Generate Error Block Ultimately it is up to the Merchant, or other trading role, to decide
whether IOTP Messages will include signatures, and for the Consumer t
decide whether carrying out a transaction without signatures is an
acceptable risk. If Merchants discover that transactions without
signatures are not being accepted, then they will either:
If an error indication message was created above, try to send it to o start using signatures,
the unless all of the error components are of the warning severity in
which case attempted transmission to the server is optional.
The net locations consumers send Error Blocks to are: o find a method of working which does not need signatures, or
o the net location which sent them the IOTP Message which was in o accept a lower volume and value of business.
error, this is either:
- the location specified by the SenderNetLocn or SecureSenderNetLocn
attribute of the Protocol Options Component if the problem was
contained in the TPO Block or the Offer Response Block
- the location to which the Payment Request Block was sent if the
problem is in either a Payment Exchange or a Payment Response
Block, or
- the location to which the Delivery request Block if the problems
in a Delivery Response Block, and
o if present, the server identified by the ErrorLogNetLocn A non-exhaustive list of the reasons why digital signatures might be
attribute of the Trading Role element identified by the used follows:
SenderTradingRoleRef the Message Id Component.
4.4.2.10 Add Block to Output Message o the Merchant (or other trading role) wants to demonstrate
that they can be trusted. If, for example, a merchant
generates an Offer Response Signature (see section 7.18.2)
using a certificate from a trusted third party, known to
the Consumer, then the Consumer can check the signature and
certificate and so more reasonably rely on the offer being
from the actual organisation 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 transaction that is fit for a particular
purpose. For example, with appropriate trust hierarchies,
digital signatures could be 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
Any Blocks which have been created as a result of processing the block o the Payment Handler, or Delivery Handler, needs to know
received are added to the output message. that the 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
5. Security Considerations o a Payment Handler or Delivery Handler wants to provide a
non-refutable record of the completion status of a Payment
or Delivery. If a Payment 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.
This section considers the security associated with IOTP. It covers: A non-exhaustive list of the reasons why digital signatures might not
be used follows:
o trading roles are combined therefore changes to data made
by the 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
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 Delivery Handler need to agree the shared secrets to use.
However the disadvantage of symmetric cryptography is that the
Consumer cannot easily check the credentials of the Merchant, Payment
Handler, etc. that they are dealing with. This is likely to reduce,
somewhat, the trust that the Consumer will have carrying out the
transaction.
However it should be noted that even if asymmetric cryptography is
being used, the Consumer does not NEED to be provided with any digita
certificates as the integrity of the transaction is determined by, fo
example, the Payment Handler checking the Offer Response Signature
copied to the Payment Request.
Note that symmetric, asymmetric or both types of cryptography may be
used in a single transaction.
5.3 Data Privacy
Privacy of information is provided by sending IOTP Messages between
the various Trading Roles using a secure channel such as [SSL/TLS].
Use of a secure channel within IOTP is optional.
5.4 Payment Protocol Security
IOTP is designed to be completely blind to the payment protocol being
used to effect a payment. From the security perspective, this means
that IOTP neither helps, nor hinders, the achievement of payment
security.
If it is necessary to consider payment security from an IOTP
perspective, then this should be included in the 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 together the record, contained in a "response" message, of each
trading exchange in a transaction. For example IOTP can bind together
an Offer, a Payment and a Delivery.
6. Digital Signatures and IOTP
IOTP can work successfully without using any digital signatures
although in an open networking environment it will be less secure -
see 5. Security Considerations for a description of the factors that
need to be considered.
However, this section describes how to use digital signatures in the
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 o how Payment Handlers and Delivery Handlers check they can
out payments or deliveries on behalf of a Merchant. carry out payments or deliveries on behalf of a Merchant.
o how IOTP handles data integrity and privacy
5.1 Digital Signatures and IOTP 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 a IOTP Components (see section 6) o are always treated as IOTP Components (see section 7)
o contain digests of one or more IOTP Components or Trading o contain digests of one or more IOTP Components or Trading
Blocks, possibly including other Signature Components, in any Blocks, possibly including other Signature Components, in
IOTP message within the same IOTP Transaction any IOTP message within the same IOTP Transaction
o identify: o identify:
- which Organisation signed (originated) the signature, and - which Organisation signed (originated) the signature, and
- which Organisation(s) should be the receive the signature in order - which Organisation(s) should process the signature in order to
to check that the Action the Organisation should take can occur. 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 The way in which Signatures Components digest one or more elements is
illustrated in the figure below. 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--|
| |-Msg Id Comp. digest Signature | | | | |-Msg Id Comp. digest Signature | | |
| | ID = P1 -------------------|->|-Digest of M1.5--| | | ID = P1 -------------------|->|-Digest of M1.5--|
| | digest element | | | | | digest element | | |
|-IOTPSignatures Block | -----------------|->|-Digest of M1.7--| |-Signatures Block | -----------------|->|-Digest of M1.7--|
| | ID=P1.2 | | digest element | | | | | ID=P1.2 | | digest element | | |
| |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--|
| |-Signature ID=M1.5---- | | | | | |-Signature ID=M1.5---- | | | | |
| |-Signature ID=P1.4 | | Points to |-RecipientInfo* | | |-Signature ID=P1.4 | | Points to |-RecipientInfo* |
| |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6 | | |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 |
| | | | Certs to use | SignatureValueRef| | | | | Certs to use | Sig.ValueRef=P1.4 |
| | | | | Points|to Value El| | | | | | | |
| | | | | v | | | | | | | |
|-Trading Block. ID=P1.5 | | -Value* ID=P1.4: | |-Trading Block. ID=P1.5 | | | v |
| |-Comp. ID=M1.7---------- | JtvwpMdmSfMbhK<--| | |-Comp. ID=M1.7---------- | -Value* ID=P1.4: |
| | | r1Ln3vovbMQttbBI | | | | JtvwpMdmSfMbhK<--
| |-Comp. ID=P1.6 | J8pxLjoSRfe1o6k| | |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI
| | | OGG7nTFzTi+/0<- | | | J8pxLjoSRfe1o6k
| |-Comp. ID=C1.4------------ | |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<-
| |-Comp. ID=C1.5 Digital signature of- | |-Comp. ID=C1.5
SignedData element Digital signature of Manifest element
using certificate using certificate identified by CertRef
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 12 Signature Digests Figure 10 Signature Digests
[Note] The classic example of one signature signing another in [Note] The classic example of one signature signing another in
IOTP, is when an Offer is first signed by a Merchant IOTP, is when an Offer is first signed by a Merchant
creating an "Offer Response" signature, which is then later creating an "Offer Response" signature, which is then later
signed by a Payment Handler together with a record of the signed by a Payment Handler together with a record of the
payment creating a "Payment Receipt" signature. In this way, payment creating a "Payment Receipt" signature. In this way,
the payment in an IOTP Transaction is bound to the the payment in an IOTP Transaction is bound to the
Merchant's offer. Merchant's offer.
[Note End] [Note End]
Note that one Manifest may be associated with multiple signature Note that one Manifest may be associated with multiple signature
"Value" elements where each Value element contains a digital signature "Value" elements where each Value element contains a digital signatur
over the same manifest, perhaps using the same (or different) over the same Manifest, perhaps using the same (or different)
signature algorithm but using a different certificate signature algorithm but using a different certificate or shared secre
key. Specifically it will allow the Merchant to agree different share
This may be used to allow each potential recipient of a signature to secrets keys with their Payment Handler and Delivery Handler.
use different certificates. Specifically it will allow the Merchant to
agreed different shared secrets with their Payment Handler and
Delivery Handler.
The detailed definitions of a Signature component is contained in The detailed definitions of a Signature component are contained in
section 6.17. section 7.18.
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 o how the OriginatorInfo and RecipientInfo elements within a
Signature Component are used to identify the organisations Signature Component are used to identify the organisations
associated with the signature associated with the signature
o how signatures may use either Symmetric or Asymmetric o how IOTP uses signatures to prove actions complete
Cryptography successfully
o Mandatory and Optional use of Signatures by IOTP, and
o how IOTP uses signatures to prove actions complete successfully
5.1.1 IOTP Signature Example 6.1.1 IOTP Signature Example
An example of how signatures are used is illustrated in the figure An example of how signatures are used is illustrated in the figure
below which shows how the various components and elements in a below which shows how the various components and elements in a
Baseline Purchase relate to one another. Refer to this example in the Baseline Purchase relate to one another. Refer to this example in the
later description of how signatures are used to check a payment or later description of how signatures are used to check a payment or
delivery can occur (see section 5.3). delivery can occur (see section 6.3).
[Note] A Baseline Purchase transaction has been used for [Note] A Baseline Purchase transaction has been used for
illustration purposes. The usage of the elements and illustration purposes. The usage of the elements and
attributes is the same for all types of IOTP Transactions. attributes is the same for all types of IOTP Transactions.
[Note End] [Note End]
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK
(Offer Response) | (Offer Response)
Brand Selection Organisation<--- Signature Brand Selection Organisation<--- |------Signature
Component Component | Component Component Component | | Component
| | | | | | | -Manifest
|BrandList -Trading Role | | |BrandList -Trading Role | |
| Ref Element | Originator |-Originator | Ref Element | Originator |-Originator
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 |
| | Pa|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) -Manifest | | (Delivery Handler
| | ^ |
| OFFER RESPONSE BLOCK | | OFFER RESPONSE BLOCK
| | Contains digests of:-- | |
|BrandListRef |ActionOrgRef -Trans Ref Block (not |BrandListRef |ActionOrgRef
| | shown) | |
--Payment ---Delivery -Transaction Id Component --Payment ---Delivery
Component Component (not shown) Component Component
-Org Components (Merchant,
Payment Handler, The Manifest element in the Signature Component contains digests of:
Delivery Handler the Trans Ref Block (not shown); the Transaction ID Component (not
-Brand List Component shown); Organisation Components (Merchant, Payment Handler, Delivery
-Order Component Handler); the Brand List Component; the Order Component, the Payment
-Payment Component Component the Delivery Component and the Brand Selection Component (if
-Delivery Component a Brand Dependent Purchase).
-Brand Selection Component
(if Brand Dependent)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 13 Example use of Signatures for Baseline Purchase Figure 11 Example use of Signatures for Baseline Purchase
5.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) Signature Component contains an Element Reference (see section 3.5)
that points to the Organisation Component of the Organisation which that points to the Organisation Component of the Organisation which
generated 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 Note that the value of the content of the Attribute element with a
type attribute set to IOTPSignatureType must match the Trading Role of Type attribute set to IOTPSignatureType must match the Trading Role o
the Organisation which signed it. If it does not, then it is an error. the Organisation which signed it. If it does not, then it is an error
Valid combinations are given in the table below. 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 RecipientRef attribute of the RecipientInfo element in the The RecipientRefs attribute of the RecipientInfo element in the
Signature Component contains Element References to the Organisation Signature Component contains Element References to the Organisation
Components of the Organisations that should use the signature to Components of the Organisations that should use the signature to
verify that: verify that:
o they have a pre-existing relationship with the Organisation o they have a pre-existing relationship with the Organisation
that generated the signature, that generated the signature,
o the data which is secured by the signature has not been o the data which is secured by the signature has not been
changed, 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 o the action they are required to undertake on behalf of the
Merchant is therefore authorised. Merchant is therefore authorised.
5.1.3 Symmetric and Asymmetric Cryptography Note that if symmetric cryptography is being used then a separate
RecipientInfo and Value elements for each different set of shared
The Originator and Recipient of a signature may have agreed to use secret keys are likely within the Signature Component.
cryptography which is understood only by the two organisations
involved. This requires that a separate RecipientInfo and Value
elements are contained within the Signature Component. This approach
is more likely if symmetric cryptography is being used between the
Trading Roles.
Equally the same cryptography may be understood by several or all of
the Trading Roles. In this case the RecpientRefs attribute of one
RecipientInfo element may refer to multiple Organisation Components.
This is more likely if public key/asymmetric cryptography is being
used.
Note that one transaction may involve use of both symmetric and
asymmetric cryptography.
5.1.4 Mandatory and Optional Signatures
IOTP does not mandate the use of signatures. For example, if a micro
payment is being made for 0.1 cents, then the cost of the cryptography
required to generate the signature may be greater than the income
generated from the payment. Therefore it is up to the Merchant to
decide whether IOTP Messages will include signatures, and for the
Consumer to decide whether carrying out a transaction without
signatures is an acceptable risk. If Merchants discover that
transactions without signatures are not being accepted, then they will
start using signatures or accept a lower volume and value of business.
Additional optional signatures, over and above the ones required by Alternatively if asymmetric cryptography is being used then the
the Trading Roles may be included, for example, to identify a Custome