draft-ietf-trade-iotp-v1.0-protocol-02.txt   draft-ietf-trade-iotp-v1.0-protocol-03.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-02.txt 23 October 1998 draft-ietf-trade-iotp-v1.0-protocol-03.txt
Expires: 23 March 1998 Expires: 28 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. Internet drafts are working This document is an Internet-Draft and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas and provisions of Section 10 of RFC2026.
its working groups. Note that other groups may also distribute working
information as Internet drafts.
Internet Drafts are draft documents valid for a maximum of six months Internet-Drafts are working documents of the Internet Engineering Task
and can be updated, replaced or obsoleted by other documents at any Force (IETF), its areas, and its working groups. Note that other
time. It is inappropriate to use Internet drafts as reference material groups may also distribute working documents as Internet-Drafts.
or to cite them as other than as "work in progress".
To learn the current status of any Internet draft please check the Internet-Drafts are draft documents valid for a maximum of six months
"lid-abstracts.txt" listing contained in the Internet drafts shadow and may be updated, replaced, or obsoleted by other documents at any
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), time. It is inappropriate to use Internet-Drafts as reference
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East coast) or material or to cite them other than as "work in progress."
ftp.isi.edu (US West coast). Further information about the IETF can be
found at URL: http://www.ietf.org/ To view the list Internet-Draft Shadow Directories, see
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.
Abstract Abstract
skipping to change at page 2, line 7 skipping to change at page 4, line 7
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.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo..................................................2
Abstract...........................................................1 Abstract.............................................................3
1. Background......................................................9 1. Background.......................................................10
1.1 Commerce on the Internet _ a Different Model................9 1.1 Commerce on the Internet _ a Different Model.................11
1.2 Benefits of IOTP...........................................10 1.2 Benefits of IOTP.............................................12
1.3 Baseline IOTP..............................................12 1.3 Baseline IOTP................................................13
1.4 Objectives of Document.....................................12 1.4 Objectives of Document.......................................14
1.5 Purpose....................................................12 1.5 Purpose......................................................14
1.6 Scope of Document..........................................13 1.6 Scope of Document............................................14
1.7 Document Structure.........................................13 1.7 Document Structure...........................................15
1.8 Intended Readership........................................14 1.8 Intended Readership..........................................16
1.8.1 Reading Guidelines ....................................14 1.8.1 Reading Guidelines ......................................17
1.9 History....................................................15 1.9 History......................................................17
2. Introduction...................................................16 2. Introduction.....................................................19
2.1 Trading Roles..............................................16 2.1 Trading Roles................................................20
2.2 Trading Exchanges..........................................18 2.2 Trading Exchanges............................................21
2.2.1 Offer Exchange ........................................19 2.2.1 Offer Exchange ..........................................23
2.2.2 Payment Exchange ......................................20 2.2.2 Payment Exchange ........................................25
2.2.3 Delivery Exchange .....................................23 2.2.3 Delivery Exchange .......................................29
2.2.4 Authentication Exchange ...............................24 2.2.4 Authentication Exchange .................................31
2.3 Scope of Baseline IOTP.....................................25 2.3 Scope of Baseline IOTP.......................................33
3. Protocol Structure.............................................28 3. Protocol Structure...............................................38
3.1 Overview...................................................29 3.1 Overview.....................................................40
3.1.1 IOTP Message Structure ................................29 3.1.1 IOTP Message Structure ..................................40
3.1.2 IOTP Transactions .....................................30 3.1.2 IOTP Transactions .......................................42
3.2 IOTP Message...............................................31 3.2 IOTP Message.................................................43
3.2.1 XML Document Prolog ...................................33 3.2.1 XML Document Prolog .....................................45
3.3 Transaction Reference Block................................33 3.3 Transaction Reference Block..................................45
3.3.1 Transaction Id Component ..............................34 3.3.1 Transaction Id Component ................................46
3.3.2 Message Id Component ..................................35 3.3.2 Message Id Component ....................................48
3.3.3 Related To Component ..................................36 3.3.3 Related To Component ....................................49
3.4 ID Attributes..............................................37 3.4 ID Attributes................................................51
3.4.1 IOTP Message ID Attribute Definition ..................38 3.4.1 IOTP Message ID Attribute Definition ....................52
3.4.2 Block and Component ID Attribute Definitions ..........39 3.4.2 Block and Component ID Attribute Definitions ............53
3.4.3 Example of use of ID Attributes .......................40 3.4.3 Example of use of ID Attributes .........................54
3.5 Element References.........................................40 3.5 Element References...........................................55
3.6 Brands and Brand Selection.................................42 3.6 Brands and Brand Selection...................................56
3.6.1 Definition of Payment Instrument ......................42 3.6.1 Definition of Payment Instrument ........................57
3.6.2 Definition of Brand ...................................42 3.6.2 Definition of Brand .....................................58
3.6.3 Definition of Dual Brand ..............................43 3.6.3 Definition of Dual Brand ................................58
3.6.4 Definition of Promotional Brand .......................43 3.6.4 Definition of Promotional Brand .........................59
3.6.5 Identifying Promotional Brands ........................44 3.6.5 Identifying Promotional Brands ..........................59
3.7 Extending IOTP.............................................46 3.7 Extending IOTP...............................................62
3.7.1 Extra XML Elements ....................................46 3.7.1 Extra XML Elements ......................................62
3.7.2 Opaque Embedded Data ..................................47 3.7.2 Opaque Embedded Data ....................................63
3.7.3 User Defined Codes ....................................47 3.7.3 Values for IOTP Codes ...................................63
3.8 Packaged Content Element...................................48 3.8 Packaged Content Element.....................................66
3.9 Identifying Languages......................................49 3.8.1 Packaging HTML ..........................................68
3.10 Secure and Insecure Net Locations.........................50 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............................................50 4. IOTP Error Handling..............................................73
4.1 Technical Errors...........................................51 4.1 Technical Errors.............................................73
4.2 Business Errors............................................51 4.2 Business Errors..............................................74
4.3 Error Depth................................................52 4.3 Error Depth..................................................74
4.3.1 Transport Level .......................................52 4.3.1 Transport Level .........................................75
4.3.2 Message Level .........................................52 4.3.2 Message Level ...........................................75
4.3.3 4Block Level ..........................................53 4.3.3 Block Level .............................................76
4.4 Idempotency, Processing Sequence, and Message Flow.........54 4.4 Idempotency, Processing Sequence, and Message Flow...........78
4.4.1 Server Role Processing Sequence .......................55 4.4.1 Server Role Processing Sequence .........................78
4.4.2 Client Role Processing Sequence .......................59 4.4.2 Client Role Processing Sequence .........................84
5. Security Considerations........................................64 5. Security Considerations..........................................90
5.1 Digital Signatures and IOTP................................64 5.1 Digital Signatures and IOTP..................................90
5.1.1 IOTP Signature Example ................................65 5.1.1 IOTP Signature Example ..................................92
5.1.2 SignerOrgRef and VerifierOrgRef Attributes ............66 5.1.2 OriginatorInfo and RecipientInfo Elements ...............94
5.1.3 Symmetric and Asymmetric Cryptography .................67 5.1.3 Symmetric and Asymmetric Cryptography ...................95
5.1.4 Mandatory and Optional Signatures .....................67 5.1.4 Mandatory and Optional Signatures .......................95
5.1.5 Using signatures to Prove Actions Complete Successfully68 5.1.5 Using signatures to Prove Actions Complete Successfully .95
5.2 Checking a Signature is Correctly Calculated...............68 5.2 Checking a Signature is Correctly Calculated.................96
5.3 Checking a Payment or Delivery can occur...................69 5.3 Checking a Payment or Delivery can occur.....................97
5.3.1 Check the Action Request was sent to the Correct 5.3.1 Check the Action Request was sent to the Correct
Organisation ................................................69 Organisation ..................................................99
5.3.2 Check the Correct Components are present in the Request 5.3.2 Check the Correct Components are present in the Request
Block .......................................................73 Block ........................................................103
5.3.3 Check an Action is Authorised .........................73 5.3.3 Check an Action is Authorised ..........................103
5.4 Data Integrity and Privacy.................................74 5.4 Data Integrity and Privacy..................................105
6. Trading Components.............................................75
6.1 Protocol Options Component.................................76
6.2 Authentication Data Component..............................77
6.3 Authentication Response Component..........................79
6.4 Order Component............................................80
6.4.1 Order Description Content .............................81
6.4.2 OkFrom and OkTo Timestamps ............................82
6.5 Organisation Component.....................................82
6.5.2 Trading Role Element ..................................85
6.5.3 Contact Information Element ...........................87
6.5.4 Person Name Element ...................................87
6.5.5 Postal Address Element ................................88
6.6 Brand List Component.......................................89
6.6.1 Brand Element .........................................91
6.6.2 Protocol Amount Element ...............................94
6.6.3 Currency Amount Element ...............................95
6.6.4 Pay Protocol Element ..................................96
6.7 Brand Selection Component..................................98
6.7.1 Brand Selection Brand Info Element ....................99
6.7.2 Brand Selection Protocol Amount Info Element .........100
6.7.3 Brand Selection Currency Amount Info Element .........100
6.8 Payment Component.........................................101
6.9 Payment Scheme Component..................................102
6.10 Payment Receipt Component................................104
6.11 Payment Note Component...................................105
6.12 Delivery Component.......................................106
6.12.1 Delivery Data Element ...............................108
6.13 Delivery Note Component..................................110
6.14 Payment Method Information Component.....................111
6.15 Status Component.........................................112
6.16 Trading Role Data Component..............................117
6.16.1 Who Receives a Trading Role Data Component ..........118
6.17 Inquiry Type Component...................................118
6.18 Signature Component......................................119
6.18.1 Offer Response Signature Component ..................119
6.18.2 Payment Receipt Signature Component .................120
6.18.3 Ping Signature Components ...........................120
6.19 Error Component..........................................121
6.19.1 Error Processing Guidelines .........................123
6.19.2 Error Codes .........................................124
6.19.3 Error Location Element ..............................127
7. Trading Blocks................................................128 6. Trading Components..............................................106
7.1 Trading Protocol Options Block............................130 6.1 Protocol Options Component..................................108
7.2 TPO Selection Block.......................................131 6.2 Authentication Data Component...............................110
7.3 Offer Response Block......................................132 6.3 Authentication Response Component...........................112
7.4 Authentication Request Block..............................133 6.4 Order Component.............................................113
7.5 Authentication Response Block.............................134 6.4.1 Order Description Content ..............................115
7.6 Payment Request Block.....................................134 6.4.2 OkFrom and OkTo Timestamps .............................115
7.7 Payment Exchange Block....................................136 6.5 Organisation Component......................................116
7.8 Payment Response Block....................................136 6.5.2 Trading Role Element ...................................119
7.9 Delivery Request Block....................................137 6.5.3 Contact Information Element ............................122
7.10 Delivery Response Block..................................138 6.5.4 Person Name Element ....................................123
7.11 Payment Instrument Customer Care Request Block...........139 6.5.5 Postal Address Element .................................124
7.12 Payment Instrument Customer Care Exchange Block..........140 6.6 Brand List Component........................................125
7.13 Payment Instrument Customer Care Response Block..........140 6.6.1 Brand Element ..........................................127
7.14 Inquiry Request Trading Block............................141 6.6.2 Protocol Amount Element ................................130
7.15 Inquiry Response Trading Block...........................141 6.6.3 Currency Amount Element ................................132
7.16 Ping Request Block.......................................142 6.6.4 Pay Protocol Element ...................................133
7.17 Ping Response Block......................................143 6.7 Brand Selection Component...................................135
7.18 Signature Block..........................................144 6.7.1 Brand Selection Brand Info Element .....................137
7.18.1 Offer Response ......................................145 6.7.2 Brand Selection Protocol Amount Info Element ...........138
7.18.2 Payment Request .....................................145 6.7.3 Brand Selection Currency Amount Info Element ...........138
7.18.3 Payment Response ....................................145 6.8 Payment Component...........................................139
7.18.4 Delivery Request ....................................145 6.9 Payment Scheme Component....................................141
7.19 Error Block..............................................146 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
8. Open Trading Protocol Transactions............................147 7. Trading Blocks..................................................180
8.1 Baseline Authentication IOTP Transaction..................147 7.1 Trading Protocol Options Block..............................183
8.1.1 Trading Protocol Options Block .......................150 7.2 TPO Selection Block.........................................184
8.1.2 Authentication Request Block .........................150 7.3 Offer Response Block........................................185
8.1.3 Signature Block (Authentication Request) .............150 7.4 Authentication Request Block................................186
8.1.4 Authentication Response Block ........................150 7.5 Authentication Response Block...............................187
8.1.5 Signature Block (Authentication Response) ............150 7.6 Authentication Status Block.................................187
8.2 Baseline Deposit IOTP Transaction.........................151 7.7 Payment Request Block.......................................188
8.2.1 Baseline Deposit Variations ..........................152 7.8 Payment Exchange Block......................................190
8.2.2 Baseline Deposit Authentication ......................152 7.9 Payment Response Block......................................190
8.2.3 Baseline Deposit Payment Messages ....................154 7.10 Delivery Request Block.....................................191
8.2.4 TPO (Trading Protocol Options) Block .................155 7.11 Delivery Response Block....................................193
8.2.5 TPO Selection Block ..................................156 7.12 Inquiry Request Trading Block..............................194
8.2.6 Authentication Request Block .........................156 7.13 Inquiry Response Trading Block.............................194
8.2.7 Authentication Response Block ........................156 7.14 Ping Request Block.........................................195
8.2.8 Offer Response Block .................................156 7.15 Ping Response Block........................................196
8.2.9 Signature Block (Offer Response) .....................157 7.16 Signature Block............................................198
8.2.10 Payment Request Block ...............................157 7.16.1 Offer Response ........................................199
8.2.11 Signature Block (Payment Request) ...................158 7.16.2 Payment Request .......................................199
8.2.12 Payment Exchange Block ..............................158 7.16.3 Payment Response ......................................199
8.2.13 Payment Response Block ..............................158 7.16.4 Delivery Request ......................................199
8.2.14 Signature Block (Payment Response) ..................158 7.17 Error Block................................................199
8.3 Baseline Purchase IOTP Transaction........................159 7.18 Cancel Block...............................................201
8.3.1 Baseline Purchase Variations .........................159
8.3.2 TPO (Trading Protocol Options) Block .................167
8.3.3 TPO Selection Block ..................................167
8.3.4 Offer Response Block .................................167
8.3.5 Signature Block (Offer Response) .....................168
8.3.6 Payment Request Block ................................169
8.3.7 Signature Block (Payment Request) ....................169
8.3.8 Payment Exchange Block ...............................169
8.3.9 Payment Response Block ...............................169
8.3.10 Signature Block (Payment Response) ..................170
8.3.11 Delivery Request Block ..............................170
8.3.12 Signature Block (Delivery Request) ..................171
8.3.13 Delivery Response Block .............................171
8.4 Baseline Refund IOTP Transaction..........................171
8.4.1 Baseline Refund Variations ...........................172
8.4.2 Baseline Refund Authentication .......................172
8.4.3 Baseline Refund Payment Messages .....................174
8.4.4 TPO (Trading Protocol Options) Block .................175
8.4.5 TPO Selection Block ..................................175
8.4.6 Authentication Request Block .........................176
8.4.7 Authentication Response Block ........................176
8.4.8 Offer Response Block .................................176
8.4.9 Signature Block (Offer Response) .....................176
8.4.10 Payment Request Block ...............................177
8.4.11 Signature Block (Payment Request) ...................177
8.4.12 Payment Exchange Block ..............................177
8.4.13 Payment Response Block ..............................178
8.4.14 Signature Block (Payment Response) ..................178
8.5 Baseline Withdrawal IOTP Transaction......................178
8.5.1 Baseline Withdrawal Variations .......................179
8.5.2 Baseline Withdrawal Authentication ...................179
8.5.3 Baseline Withdrawal Payment Messages .................182
8.5.4 TPO (Trading Protocol Options) Block .................183
8.5.5 TPO Selection Block ..................................183
8.5.6 Authentication Request Block .........................183
8.5.7 Authentication Response Block ........................184
8.5.8 Offer Response Block .................................184
8.5.9 Signature Block (Offer Response) .....................184
8.5.10 Payment Request Block ...............................185
8.5.11 Signature Block (Payment Request) ...................185
8.5.12 Payment Exchange Block ..............................185
8.5.13 Payment Response Block ..............................186
8.5.14 Signature Block (Payment Response) ..................186
8.6 Baseline Value Exchange IOTP Transaction..................186
8.6.1 Baseline Value Exchange Variations ...................187
8.6.2 PO (Trading Protocol Options) Block ..................191
8.6.3 TPO Selection Block ..................................192
8.6.4 Offer Response Block .................................192
8.6.5 Signature Block (Offer Response) .....................192
8.6.6 Payment Request Block (first payment) ................193
8.6.7 Signature Block (Payment Request - first payment) ....194
8.6.8 Payment Exchange Block (first payment) ...............194
8.6.9 Payment Response Block (first payment) ...............194
8.6.10 Signature Block (Payment Response - first payment) ..195
8.6.11 Payment Request Block (second payment) ..............195
8.6.12 Signature Block (Payment Request - second payment) ..196
8.6.13 Payment Exchange Block (second payment) .............196
8.6.14 Payment Response Block (second payment) .............196
8.6.15 Signature Block (Payment Response - second payment) .197
8.6.16 Baseline Value Exchange Signatures ..................197
8.7 Payment Instrument Customer Care IOTP Transaction.........198
8.7.1 Payment Instrument Customer Care Request Block .......200
8.7.2 Payment Instrument Customer Care Exchange Block ......200
8.7.3 Payment Instrument Customer Care Response Block ......200
8.7.4 Signature Block ......................................200
8.8 Baseline Transaction Status Inquiry IOTP Transaction......201
8.8.1 Which Trading Roles can receive Inquiry Requests .....201
8.8.2 Transaction Status Inquiry Transport Session .........201
8.8.3 Transaction Status Inquiry Error Handling ............202
8.8.4 Inquiry Transaction Messages .........................202
8.8.5 Transaction Reference Block ..........................203
8.8.6 Inquiry Request Block ................................203
8.8.7 Inquiry Response Block ...............................203
8.9 Baseline Ping IOTP Transaction............................204
8.9.1 Ping Messages ........................................204
8.9.2 Transaction Reference Block ..........................205
8.9.3 Ping Request Block ...................................205
8.9.4 Signature Block (Ping Request) .......................206
8.9.5 Ping Response Block ..................................206
8.9.6 Signature Block (Ping Response) ......................206
9. Retrieving Logos..............................................206 8. Internet Open Trading Protocol Transactions.....................202
9.1 Logo Size.................................................207 8.1 Authentication and Payment Related IOTP Transactions........202
9.2 Logo Color Depth..........................................207 8.1.1 Authentication Document Exchange .......................205
9.3 Logo Net Location Examples................................208 8.1.2 Offer Document Exchange ................................212
8.1.3 Payment Document Exchange ..............................222
8.1.4 Delivery Document Exchange .............................228
8.1.5 Payment and Delivery Document Exchange .................231
8.1.6 Baseline Authentication IOTP Transaction ...............234
8.1.7 Baseline Deposit IOTP Transaction ......................236
8.1.8 Baseline Purchase IOTP Transaction .....................238
8.1.9 Baseline Refund IOTP Transaction .......................240
8.1.10 Baseline Withdrawal IOTP Transaction ..................242
8.1.11 Baseline Value Exchange IOTP Transaction ..............244
8.1.12 Valid Combinations of Document Exchanges ..............248
8.1.13 Combining Authentication Transactions with other
Transactions .................................................252
8.2 Infrastructure Transactions.................................253
8.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...254
8.2.2 Baseline Ping IOTP Transaction .........................258
10. Brand List Examples..........................................208 9. Retrieving Logos................................................262
10.1 Simple Credit Card Based Example.........................208 9.1 Logo Size...................................................262
10.2 Credit Card Brand List Including Promotional Brands......209 9.2 Logo Color Depth............................................263
10.3 Brand Selection Example..................................211 9.3 Logo Net Location Examples..................................263
10.4 Complex Electronic Cash Based Brand List.................211 10. Brand List Examples............................................265
11. XML Overview.................................................213 10.1 Simple Credit Card Based Example...........................265
11.1 Document Definition......................................214 10.2 Credit Card Brand List Including Promotional Brands........266
11.2 Element Declaration......................................214 10.3 Brand Selection Example....................................269
11.2.1 Example 1 ...........................................215 10.4 Complex Electronic Cash Based Brand List...................269
11.2.2 Example 2 ...........................................215
11.2.3 Example 3 ...........................................215
11.2.4 Data Types used in element declarations .............216
11.3 Attribute declarations...................................216
11.3.1 Declared value ......................................216
11.3.2 Default value .......................................217
12. Open Trading Protocol Data Type Definition...................218 11. Open Trading Protocol Data Type Definition.....................274
13. Glossary.....................................................229 12. Glossary.......................................................289
14. Copyrights...................................................232 13. Copyrights.....................................................298
15. References...................................................233 14. References.....................................................299
16. Author's Address.............................................235 15. Author's Address...............................................303
Table of Figures Table of Figures
Figure 1 IOTP Trading Roles ......................................17 Figure 1 IOTP Trading Roles ........................................20
Figure 2 Offer Exchange ..........................................19 Figure 2 Offer Exchange ............................................23
Figure 3 Payment Exchange ........................................21 Figure 3 Payment Exchange ..........................................26
Figure 4 Delivery Exchange .......................................24 Figure 4 Delivery Exchange .........................................30
Figure 5 Authentication Exchange .................................25 Figure 5 Authentication Exchange ...................................33
Figure 6 IOTP Message Structure ..................................29 Figure 6 IOTP Message Structure ....................................41
Figure 7 An IOTP Transaction .....................................30 Figure 7 An IOTP Transaction .......................................42
Figure 8 Example use of ID attributes ............................40 Figure 8 Example use of ID attributes ..............................54
Figure 9 Element References ......................................41 Figure 9 Element References ........................................56
Figure 10 Server Role Processing Sequence ........................56 Figure 10 Server Role Processing Sequence ..........................80
Figure 11 Client Role Processing Sequence ........................61 Figure 11 Client Role Processing Sequence ..........................86
Figure 12 Signature Hashing ......................................65 Figure 12 Signature Digests ........................................91
Figure 13 Example use of Signatures for Baseline Purchase ........66 Figure 13 Example use of Signatures for Baseline Purchase ..........93
Figure 14 Checking a Payment Handler can carry out a Payment .....70 Figure 14 Checking a Payment Handler can carry out a Payment ......100
Figure 15 Checking a Delivery Handler can carry out a Delivery ...72 Figure 15 Checking a Delivery Handler can carry out a Delivery ....102
Figure 16 Trading Components .....................................75 Figure 16 Trading Components ......................................107
Figure 17 Brand List Element Relationships .......................91 Figure 17 Brand List Element Relationships ........................127
Figure 18 Trading Blocks ........................................129 Figure 18 Trading Blocks ..........................................181
Figure 19 Baseline Authentication ...............................149 Figure 19 Payment and Authentication Message Flow Combinations ....204
Figure 20 Baseline Deposit with Authentication ..................153 Figure 20 Authentication Document Exchange ........................208
Figure 21 Baseline Deposit without Authentication ...............154 Figure 21 Brand Dependent Offer Document Exchange .................214
Figure 22 Baseline Deposit Payment Messages .....................155 Figure 22 Brand Independent Offer Exchange ........................217
Figure 23 Brand Dependent Baseline Purchase .....................161 Figure 23 Payment Document Exchange ...............................224
Figure 24 Brand Independent Baseline Purchase ...................162 Figure 24 Delivery Document Exchange ..............................229
Figure 25 Baseline Purchase, Delivery Response Block and Payment Figure 25 Payment and Delivery Document Exchange ..................232
Response Blocks Not Combined .................................163 Figure 26 Baseline Authentication IOTP Transaction ................235
Figure 26 Baseline Purchase, Delivery Response Block and Payment Figure 27 Baseline Deposit IOTP Transaction .......................237
Response Block Combined ......................................164 Figure 28 Baseline Purchase IOTP Transaction ......................239
Figure 27 Baseline Purchase, Purchase without Delivery Exchange .166 Figure 29 Baseline Refund IOTP Transaction ........................241
Figure 28 Baseline Purchase Variations ..........................167 Figure 30 Baseline Withdrawal IOTP Transaction ....................243
Figure 29 Baseline Refund with Authentication ...................173 Figure 31 Baseline Value Exchange IOTP Transaction ................246
Figure 30 Baseline Refund without Authentication ................174 Figure 32 Baseline Value Exchange Signatures ......................247
Figure 31 Baseline Refund Payment Messages ......................175 Figure 33 Valid Combinations of Document Exchanges ................250
Figure 32 Baseline Withdrawal with Authentication ...............180 Figure 34 Baseline Transaction Status Inquiry .....................257
Figure 33 Baseline Withdrawal without Authentication ............181 Figure 35 Baseline Ping Messages ..................................259
Figure 34 Baseline Withdrawal Payment Messages ..................183
Figure 35 Brand Dependent Value Exchange ........................189
Figure 36 Brand Independent Value Exchange ......................189
Figure 37 Baseline Value Exchange Payment Messages ..............191
Figure 38 Baseline Value Exchange Signatures ....................198
Figure 39 IOTP Payment Instrument Customer Care Transaction Message
Flows ........................................................200
Figure 40 Baseline Transaction Status Inquiry ...................203
Figure 41 Baseline Ping Messages ................................204
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.
skipping to change at page 10, line 8 skipping to change at page 11, line 16
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, not
the rule. Already with the rise of mail order and telephone the rule. Already with the rise of mail order and telephone
order placement this change has been felt in western commerce. order placement this change has been felt in western commerce.
Electronic commerce over the Internet will further expand the Electronic commerce over the Internet will further expand the
scope and volume of transactions conducted without ever seeing scope and volume of transactions conducted without ever seeing
the people who are a part of the enterprise with whom one does the people who are a part of the enterprise with whom one does
business. business.
o Authentication: An important part of personal presence is the o Authentication: An important part of personal presence is the
ability of the parties to use familiar objects and dialogue to ability of the parties to use familiar objects and dialogue to
confirm they are who they claim to be. The seller displays one confirm they are who they claim to be. The seller displays one
or several well known financial logos that declaim his ability or several well known financial logos that declaim his ability
to accept widely used credit and debit instruments in the to accept widely used credit and debit instruments in the
payment part of a purchase. The buyer brings government or payment part of a purchase. The buyer brings government or
financial institution identification that assures the seller financial institution identification that assures the seller
she will be paid. People use intangibles such as personal she will be paid. People use intangibles such as personal
appearance and conduct, location of the store, apparent appearance and conduct, location of the store, apparent quality
quality and familiarity with brands of merchandise, and a good and familiarity with brands of merchandise, and a good clear
clear look in the eye to reinforce formal means of look in the eye to reinforce formal means of authentication.
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 the
world's trade still takes place using the coin of the realm or world's trade still takes place using the coin of the realm or
barter. The present infrastructure of the payments business barter. The present infrastructure of the payments business
cannot economically support low value transactions and could cannot economically support low value transactions and could
not survive under the consequent volumes of transactions if it not survive under the consequent volumes of transactions if it
did accept low value transactions. 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 example, pages of information for fractions of currency that do
do not exist in the real world. 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 as
direct electronic delivery. The means by which receipt is direct electronic delivery. The means by which receipt is
confirmed and the execution of payment change dramatically confirmed and the execution of payment change dramatically
where the goods or services have extremely low delivery cost where the goods or services have extremely low delivery cost
but may in fact have very high value. Or, maybe the value is but may in fact have very high value. Or, maybe the value is
not high, but once delivery occurs the value is irretrievably not high, but once delivery occurs the value is irretrievably
delivered so payment must be final and non-refundable but delivered so payment must be final and non-refundable but
delivery nonetheless must still be confirmed before payment. delivery nonetheless must still be confirmed before payment.
Incremental delivery such as listening or viewing time or Incremental delivery such as listening or viewing time or
playing time are other models that operate somewhat playing time are other models that operate somewhat differently
differently in the virtual world. 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.
Payment Brands PAYMENT BRANDS
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 knowing
that they are dealing with the individual or organisation with that they are dealing with the individual or organisation with
which they originally traded which they originally traded
o new merchants will be able to enter this new (Internet)
market-place with new products and services, using the new
trading opportunities which IOTP presents
Banks and Financial Institutions o new merchants will be able to enter this new (Internet) market-
place with new products and services, using the new trading
opportunities which IOTP presents
BANKS AND FINANCIAL INSTITUTIONS
There are also several benefits for Banks and Financial Institutions: 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 types
of merchants 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 they
can trade 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, for
example, to feed into accounting systems or, potentially, to example, to feed into accounting systems or, potentially, to
present to the tax authorities 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 versions 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
skipping to change at page 12, line 13 skipping to change at page 13, line 41
present to the tax authorities 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 versions 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 be placed in the market in order to understand the real _market place_
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. To proceed otherwise would be presumptuous, time consuming,
expensive and foolish. 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 specification
by end '98. by end '98.
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
skipping to change at page 12, line 42 skipping to change at page 14, line 26
specification of version 1.0 of the Open Trading Protocols which can specification of version 1.0 of the Open Trading Protocols which can
be used to design and implement systems which support electronic be used to design and implement systems which support electronic
trading on the Internet using the Open Trading Protocols. trading on the Internet using the Open Trading Protocols.
An overview of IOTP is provided the IOTP Business Description which An overview of IOTP is provided the IOTP Business Description which
explains the Business Requirements for IOTP. explains the Business Requirements for IOTP.
1.5 Purpose 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 to start development of software/hardware solutions o to allow potential developers of products based on the protocol
which use the protocol to start development of software/hardware 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.6 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,
skipping to change at page 13, line 38 skipping to change at page 15, line 30
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.7 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 background
on electronic commerce and the benefits IOTP offers. 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 various
Trading Exchanges and shows how these trading exchanges are Trading Exchanges and shows how these trading exchanges are
used to construct the IOTP Transactions. This section also used to construct the IOTP Transactions. This section also
explains various Trading Roles that would participate in explains various Trading Roles that would participate in
electronic trade. 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 Blocks and Trading Components that are the fundamental building
building blocks for IOTP transactions. All IOTP transaction blocks for IOTP transactions. All IOTP transaction messages are
messages are well formed XML documents. 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 to
process exceptions and errors during the protocol message process exceptions and errors during the protocol message
exchange and trading exchange processing. This section exchange and trading exchange processing. This section provides
provides a generic overview of the exception handling. This a generic overview of the exception handling. This section
section should be read carefully. should be read carefully.
o Section 5 - Security Considerations: This section describes o Section 5 - Security Considerations: This section describes
security considerations and digital signatures for the XML security considerations and digital signatures for the XML
elements exchanged between the Trading Roles. elements exchanged between the Trading Roles.
o Section 6 - Trading Components: This section defines the XML o Section 6 - Trading Components: This section defines the XML
elements required by Trading Components. elements required by Trading Components.
o Section 7 - Trading Blocks: This section describes how Trading o Section 7 - Trading Blocks: This section describes how Trading
Blocks are constructed from Trading Components. Blocks are constructed from Trading Components.
o Section 8 - Open Trading Protocol Transactions: This section o Section 8 - Open Trading Protocol Transactions: This section
describes all the IOTP Baseline transactions. It refers to describes all the IOTP Baseline transactions. It refers to
Trading Blocks and Trading Components and Signatures. This Trading Blocks and Trading Components and Signatures. This
section doesn't directly link error handling during the section doesn't directly link error handling during the
protocol exchanges, the reader is advised to understand Error protocol exchanges, the reader is advised to understand Error
Handling as defined in section before reading this section. Handling as defined in section before reading this section.
o Section 9 - Retrieving Logos: This section describes how IOTP o Section 9 - Retrieving Logos: This section describes how IOTP
specific logos can be retrieved. specific logos can be retrieved.
o Section 10 - Brand List Examples: This section gives some o Section 10 - Brand List Examples: This section gives some
examples for Brand List. examples for Brand List.
o Section 11 - XML Overview: This section gives brief o Section 11 - XML Overview: This section gives brief
introduction to XML. introduction to XML.
o Section 12 - Open Trading Protocol Data Type Definition: This o Section 12 - Open Trading Protocol Data Type Definition: This
section contains the XML Data Type Definitions for IOTP. section contains the XML Data Type Definitions for IOTP.
o Section 12 - Glossary. This describes all the major
terminology used by IOTP. o Section 12 - Glossary. This describes all the major terminology
used by IOTP.
1.8 Intended Readership 1.8 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.8.1 Reading Guidelines
This IOTP specification is structured primarily in a sequence targeted This IOTP specification is structured primarily in a sequence targeted
skipping to change at page 14, line 46 skipping to change at page 17, line 16
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 12 - 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 8 - Open Trading Protocol Transactions
o Section 10 - Brand List Examples o Section 10 - Brand List Examples
o Section 4 - IOTP Error Handling o Section 4 - IOTP Error Handling
o Section 9 - Retrieving Logos o Section 9 - Retrieving Logos
Review the detailed XML definitions: Review the detailed XML definitions:
o Section 11 - XML Overview (if the reader does not know XML) o Section 11 - XML Overview (if the reader does not know XML)
o Section 7 - Trading Blocks o Section 7 - Trading Blocks
o Section 6 - Trading Components o Section 6 - Trading Components
1.9 History 1.9 History
Version 0.1 20 February Initial draft for comment Version 0.1 20 February 1997 Initial draft for comment
1997
Version 0.2 14 April 1997 Revised draft including changes Version 0.2 14 April 1997 Revised draft including changes
arising from comments arising from comments
Version 0.2a 24 April 1997 Same as version 0-2 with Version 0.2a 24 April 1997 Same as version 0-2 with
typographic corrections typographic corrections
Version 0.3 9 October 1997 Revised draft for comment Version 0.3 9 October 1997 Revised draft for comment
including revised encoding including revised encoding
approach using [XML] approach using [XML]
Version 0.4 31 October 1997 Published draft for limited public Version 0.4 31 October 1997 Published draft for limited public
review by groups working within review by groups working within
IOTP dev the OTP consortium
Version 0.9 12 January 1998 Revisions following limited public Version 0.9 12 January 1998 Revisions following limited public
review _ draft for public comment review _ draft for public comment
only. only.
Version 0.9.1 20 May 1998 Revisions following public review Version 0.9.1 20 May 1998 Revisions following public review
- internal IOTP Consortium review. - internal IOTP Consortium review.
Version 0.9.9 17 August 1998 Draft published for submission to Version 0.9.9 17 August 1998 Draft published for submission to
IETF for information. IETF for information.
Version 1.0 23 October 1998 Draft published incorporating Version 1.0 23 October 1998 Draft published incorporating
comments received on version comments received on version
0.9.9. 0.9.9.
Version 1.0 28 February 1998 Revised draft published incorporating
comments received on version 1.0
2. Introduction 2. Introduction
The Open Trading Protocols (IOTP) define a number of different types The Internet Open Trading Protocols (IOTP) define a number of
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 of,
typically, an earlier purchase 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 the
exchange of value from one combination of currency and payment exchange of value from one combination of currency and payment
method to another method to another
o Authentication. This supports the remote authentication of a
Consumer by another Trading Role using a variety of o Authentication. This supports one organisation or individual to
authentication methods, and the provision of an Organisation check that another organisation or individual are who they
Component about a Consumer to another Trading Role for use in, appear to be.
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 Payment Instrument Customer Care. This supports the provision
of Payment Brand or Payment Method specific customer care of a
Payment Instrument
o Inquiry This supports inquiries on the status of an IOTP 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 aware
application to determine whether another IOTP application application to determine whether another IOTP application
running elsewhere is working or not. 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 the
exchange of data, between Trading Roles, in the form of a set exchange of data, between Trading Roles, in the form of a set
of Trading Components. 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 can
skipping to change at page 16, line 50 skipping to change at page 20, line 11
o a set of Trading Exchanges. Each Trading Exchange involves the o a set of Trading Exchanges. 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 set
of Trading Components. 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 can
take in a trade. The five 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 |
| | ---------- | | ----------
v v v v
---------- Consumer makes purchases or obtains ---------- ---------- Consumer makes purchases or obtains ----------
| Consumer |<--------------------------------------->| Merchant | | Consumer |<--------------------------------------->| Merchant |
---------- refund from Merchant ---------- ---------- refund from Merchant ----------
^ ^ ^
| | Delivery Handler supplies goods or ---------- | Delivery Handler supplies goods or ----------
| ------------------------------------------>|Deliverer | |---------------------------------------------->|Deliverer |
| services for Merchant ---------- services for Merchant ----------
|
| ---------- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Payment Instrument Customer Care Provider | Payment |
---------------------------------------------->|Instrument|
resolves problems with Payment Instruments |Cust.Care.|
| Provider |
----------
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 and
pay for the goods or services 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 is
being made and who is legally responsible for providing the being made and who is legally responsible for providing the
goods or services and receives the benefit of the payment made 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 o Delivery Handler. The entity that physically delivers the goods
goods or services to the Consumer on behalf of the Merchant. or services to the Consumer on behalf of the Merchant.
o Merchant Customer Care Provider. The entity that is involved o Merchant Customer Care Provider. The entity that is involved
with customer dispute negotiation and resolution on behalf of with customer dispute negotiation and resolution on behalf of
the Merchant the Merchant
o Payment Instrument Customer Care Provider. The entity that
resolves problems with a particular Payment Instrument
Roles may be carried out by the same organisation or different 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 but
instruct the consumer to pay a bank or financial institution, instruct the consumer to pay a bank or financial institution,
request that delivery be made by an overnight courier firm and request that delivery be made by an overnight courier firm and
to contact an organisation which provides 24x7 service if to contact an organisation which provides 24x7 service if
problems arise. 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 rather
than an actual organisation. than an actual organisation.
skipping to change at page 18, line 27 skipping to change at page 21, line 43
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 Open Trading Protocols identify four Trading Exchanges which
involve the exchange of data between the Trading Roles. The Trading involve the exchange of data between the Trading Roles. The Trading
Exchanges are: Exchanges are:
o Offer. The Offer Exchange results in the Merchant providing
the Consumer with the reason why the trade is taking place. It o Offer. The Offer Exchange results in the Merchant providing the
is called an Offer since the Consumer must accept the Offer if Consumer with the reason why the trade is taking place. It is
a trade is to continue called an Offer since the Consumer must accept the Offer if a
o Payment. The Payment Exchange results in a payment of some trade is to continue
kind between the Consumer and the Payment Handler. This may o Payment. The Payment Exchange results in a payment of some kind
occur in either direction between the Consumer and the Payment Handler. This may occur in
either direction
o Delivery. The Delivery Exchange transmits either the on-line o Delivery. The Delivery Exchange transmits either the on-line
goods, or delivery information about physical goods from the goods, or delivery information about physical goods from the
Delivery Handler to the Consumer, and 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 any
Trading Role to authenticate another Trading Role to check Trading Role to authenticate another Trading Role to check that
that they are who they appear to be. 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 includes
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
skipping to change at page 19, line 18 skipping to change at page 23, line 12
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 OTP MESSAGE MERCHANT *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
CONSUMER IOTP MESSAGE MERCHANT
1. Consumer decides to ----------------------> 2. Merchant checks 1. Consumer decides to ----------------------> 2. Merchant checks
pay (request an offer) Information on what is the information trade and sends Information on what is the information
and sends information being purchased (Offer provided by the information about the being purchased (Offer provided by the
on what to purchase to Request) (outside scope Consumer, creates transaction (requests Request) (outside scope Consumer, creates an
the Merchant using e.g. of OTP) and Offer and sends an offer) to the of IOTP) Offer and sends it
HTML it to the Consumer. Merchant, e.g using to the Consumer|
| HTML
v v
Components: Organisation(s) 3. Consumer checks the Components: Organisation(s)
3. Consumer checks the (Consumer, DeliverTo, Merchant, information from the (Consumer, DeliverTo, Merchant,
information from the <---------- Payment Handler, Delivery Merchant and decides <---------- Payment Handler, Delivery
Merchant and decides Offer Handler, Cust Care); Order; Pay whether to continue Offer Handler, Cust Care); Order; Pay
whether to continue Response Amount; Delivery; Signature Response Amount; Delivery; Signature
(Offer Response)(which signs (Offer Response)(which signs
other components) 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 the organisations which are taking a role in the o the Organisation Component contains information which describes
trade: the organisations which are taking a role in the trade:
- the consumer provides information, about who the consumer is - the consumer provides information, about who the consumer is and,
and, if goods or services are being delivered, where the goods if goods or services are being delivered, where the goods or
or services are to be delivered to services are to be delivered to
- the merchant augments this information by providing information - the merchant augments this information by providing information
about the merchant, the Payment Handler, the customer care about the merchant, the Payment Handler, the customer care
provider and, if goods or services are being delivered, the provider and, if goods or services are being delivered, the
Delivery Handler 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 Merchant
to the consumer who should verify it 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 refund. Note that there may be more than one payment in a trade
trade
o the Delivery Component, also generated by the Merchant, is o the Delivery Component, also generated by the Merchant, is used
used if goods or services are being delivered. This contains if goods or services are being delivered. This contains
information about how delivery will occur, for example by post information about how delivery will occur, for example by post
or using e-mail or using e-mail
o the "Offer Response" Signature Component, if present,
digitally signs all of the above components to ensure their o the "Offer Response" Signature Component, if present, digitally
integrity. 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 brand
and payment protocol used 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 could be provided Information provided by the consumer to the merchant is provided using
using 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 the
consumer. consumer.
o using the Open Profiling Standard [OPS] which has recently
been proposed, o Using the Open Profiling Standard [OPS] which has recently been
o in the form of Organisation and Order Components in a later proposed,
version of IOTP.
o in the form of Organisation Components associated with an
authentication of a Consumer by a Merchant
o as Order Components in a later version of IOTP.
2.2.2 Payment Exchange 2.2.2 Payment Exchange
The goal of the Payment Exchange is for a payment to be made from the The goal of the Payment Exchange is for a payment to be made from the
Consumer to a Payment Handler or vice versa using a payment brand and Consumer to a Payment Handler or vice versa using a payment brand and
payment protocol selected by the Consumer. A secondary goal is to payment protocol selected by the Consumer. A secondary goal is to
optionally provide the Consumer with a digitally signed Payment 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 case
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 is
illustrated in the diagram below. Simpler payment exchanges are illustrated in the diagram below. Simpler payment exchanges are
possible. possible.
CONSUMER OTP MESSAGE MERCHANT *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
1. Consumer decides to 2. Merchant decides
trade and sends Information on what is which payment brand
information on what to being paid for and protocols to
purchase to the ----------------------> offer, places then
Merchant, e.g. using (outside scope of OTP) in a Brand List
HTML Component and sends
them to the
Consumer.
CONSUMER IOTP MESSAGE MERCHANT
1. Consumer decides to 2. Merchant decides
trade and sends Information on what is which payment
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
| |
v v
3. Consumer selects the payment <----------------- Brand List 3. Consumer selects the payment <----------------- Brand List
brand and protocol to use, creates a Brand List Component brand, protocol and currency/amount Brand List Component
Brand Selection Component and sends to use, creates a Brand Selection
it to the Merchant Component and sends it to the
Merchant
| |
v v
Brand Selection ----------------> 4. Merchant checks Brand Brand Selection ----------------> 4. Merchant checks Brand
Brand Selection Selection, creates Payment Amount Brand Selection Selection, creates Payment Amount
Information, optionally signs it information, optionally signs it
to authorise payment and send it to authorise payment and sends it
to the consumer to the Consumer
| |
v v
5. Consumer checks the Components: 5. Consumer checks the Components:
Payment Amount information <-------- Pay Amount; Auth data; Payment Amount information <-------- Pay Amount; Auth data;
and if OK requests that the Payment Organisation(s) (Merchant & and if OK requests that the Payment Organisation(s) (Merchant &
payment starts by sending Information Payment Handler); Signature payment starts by sending Information Payment Handler); Signature
information to the Payment (Offer) (signs other information to the Payment (Offer) (signs other
Handler components) Handler components)
| |
| ======================================== | ========================================
v PAYMENT HANDLER v PAYMENT HANDLER
Components: Pay Scheme; Auth 6. Payment Handler checks Components: Pay Scheme; Auth 6. Payment Handler checks
Data; Brand List; Pay Amount; information including Data; Brand List; Pay Amount; information including
Brand Selection; ----------> optional signature and if Brand Selection; ----------> optional signature and if
Organisation(s) (Merchant & Payment OK starts exchanging Pay Organisation(s) (Merchant & Payment OK starts exchanging Pay
Payment Handler); Signature Request Scheme Components using Payment Handler); Signature Request Scheme Components using
(Offer) (signs all other messages for selected (Offer) (signs all other messages for selected
components except payment brand and payment ----- components except payment brand and payment
------ Pay Scheme) protocol | Pay Scheme) protocol
| | | | | |
| v v | v v
| Component: Pay Scheme <------------------> Component: Pay Scheme | Component: Pay Scheme <------------------> Component: Pay Scheme
| Payment Exchange | Payment Exchange
| | | |
| v | v
| 7. Eventually payment protocol messages | 7. Eventually payment protocol messages
---------- finish so Payment Handler sends Pay ----------- finish so Payment Handler sends Pay
| Receipt and optional signature to | Receipt and optional signature to
| Consumer as proof of payment | Consumer as proof of payment
| | | |
| v | v
v Components: Pay Receipt; Pay 8. Consumer checks Pay Components: Pay Receipt; Pay
8 Consumer checks Pay scheme; Signature (Offer); Receipt is OK <------- scheme; Signature (Offer);
Receipt is OK <------- Signature (Pay Receipt) Payment Signature (Pay Receipt) (signs Pay
Payment (signs Pay Receipt and Response Receipt and Signature (Offer)
Response Signature (Offer) components) 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 example, MasterCard, Visa, Mondex, GeldKarte) and payment o The Brand List Component contains a list of payment brands (for
example, MasterCard, Visa, Mondex, GeldKarte), payment
protocols (for example SET Version 1.0, Secure Channel Credit protocols (for example SET Version 1.0, Secure Channel Credit
Debit (SCCD - the name used for a credit or debit card payment Debit (SCCD - the name used for a credit or debit card payment
where unauthorised access to account information is prevented where unauthorised access to account information is prevented
through use of secure channel transport mechanisms such as through use of secure channel transport mechanisms such as SSL)
SSL). The Merchant sends the Brand List to the Consumer. The as well as currencies/amounts that apply. The Merchant sends
consumer compares the payment brands and protocols on offer the Brand List to the Consumer. The consumer compares the
with those that the Consumer supports and makes a selection. payment brands, protocols and currencies/amounts on offer with
those that the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's o The Brand Selection Component contains the Consumer's
selection. Payment brand, protocol and possibly protocol- selection. Payment brand, protocol, currency/amount and
specific information is sent back to the Merchant. This possibly protocol-specific information is sent back to the
information may be used to change information in the Offer Merchant. This information may be used to change information in
Exchange. For example, a merchant could choose to offer a the Offer Exchange. For example, a merchant could choose to
discount to encourage the use of a store card. offer a discount to encourage the use of a store card.
o The Organisation Components are generated by the Merchant.
They contain details of the Merchant and Payment Handler o The Organisation Components are generated by the Merchant. They
Roles: 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 on
behalf of the Merchant will be a credit or debit transaction to behalf of the Merchant will be a credit or debit transaction to
the Merchant's account held by the Payment Handler. These the Merchant's account held by the Payment Handler. These
transactions are outside the scope of IOTP transactions are outside the scope of this version of IOTP
- the Payment Handler role is required so that the Payment Handler - the Payment Handler role is required so that the Payment Handler
can check that it is the correct Payment Handler to be used for can check that it is the correct Payment Handler to be used for
the payment the payment
o The optional Authentication Data Component contains challenge
data which is used by the payment protocol to authenticate the
consumer. Authentication may not always occur
o The Payment Component contains details of how much to pay, the o The Payment Component contains details of how much to pay, the
currency and the payment direction, and identifies the currency and the payment direction
Authentication Data Component to use.
o The "Offer Response" Signature Component, if present, o The "Offer Response" Signature Component, if present, digitally
digitally signs all of the above components to ensure their signs all of the above components to ensure their integrity.
integrity. Note that the Brand List and Brand Selection Note that the Brand List and Brand Selection Components are not
Components are not signed until the payment information is signed until the payment information is created (step 4 in the
created (step 3 in the diagram) diagram)
o The Payment Scheme Component contains messages from the
payment protocol used in the Trade. For example they could be o The Payment Scheme Component contains messages from the payment
SET messages, Mondex messages, GeldKarte Messages or one of protocol used in the Trade. For example they could be SET
the other payment methods supported by IOTP. The content of messages, Mondex messages, GeldKarte Messages or one of the
the Payment Scheme Component is defined in the supplements other payment methods supported by IOTP. The content of the
that describe how IOTP works with various payment protocols. Payment Scheme Component is defined in the supplements that
o The Payment Receipt Component contains a record of the describe how IOTP works with various payment protocols.
payment. The content depends upon the payment protocol used.
o The Payment Receipt Component contains a record of the payment.
The content depends upon the payment protocol used.
o The "Payment Receipt" Signature Component provides proof of o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing both the Payment Receipt payment by digitally signing both the Payment Receipt Component
Component and the Offer Signature. The signature on the offer and the Offer Response Signature. The signature on the offer
digitally signs the Order, Organisation and Delivery digitally signs the Order, Organisation and Delivery Components
Components contained in the Offer. This signature effectively contained in the Offer. This signature effectively binds the
binds the payment to the offer. 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 at
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 8.3). 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, providing
details about the delivery, such as shipping tracking number. A future details about the delivery, such as shipping tracking number. The
goal is to have a signed delivery that can be used for customer care result of the delivery may also be signed so that it can be used for
in the case of problems with physical delivery. This is illustrated in customer care in the case of problems with physical delivery. The
the diagram below. message flow is illustrated in the diagram below.
CONSUMER OTP MESSAGE MERCHANT *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
CONSUMER IOTP MESSAGE MERCHANT
1. Consumer decides to ------------> 2. Merchant checks the 1. Consumer decides to ------------> 2. Merchant checks the
trade and sends Information information provided by the trade and sends Information information provided by the
information about what on what is Consumer, adds information information about what on what is Consumer, adds information
to deliver and who is being about how the delivery will to deliver and who is being about how the delivery will
to take delivery, to delivered occur, information about the to take delivery, to delivered occur, information about the
the Merchant, using for (outside organisations involved in the the Merchant, using for (outside organisations involved in the
example, HTML scope of OTP) delivery and optionally signs example, HTML scope of delivery and optionally signs
it IOTP) it
| |
v v
3. Consumer checks the Components: 3. Consumer checks the Components:
delivery information is OK, Delivery; delivery information is OK, Delivery;
obtains authorisation for <----------------- Organisation(s) obtains authorisation for <----------------- Organisation(s)
the delivery, for example by Delivery Delivery Handler, the delivery, for example by Delivery Delivery Handler,
making a payment, and sends Information Deliver To; Order; making a payment, and sends Information Deliver To; Order;
the delivery information to Signature (Offer) the delivery information to Signature (Offer)
the Delivery Handler. the Delivery Handler.
| |
v v
Components: Delivery; 4. Delivery Handler checks Components: Delivery; 4. Delivery Handler checks
Organisation(s), Merchant, information and Organisation(s), Merchant, information and
Delivery Handler, DelivTo; --------> authorisation. Starts or Delivery Handler, DelivTo; --------> authorisation. Starts or
Order; Signature (Offer); Delivery schedules delivery and Order; Signature (Offer); Delivery schedules delivery and
Signature (Pay Receipt) Request creates and then sends a Signature (Pay Receipt) Request creates and then sends a
(from Payment Exchange) delivery note to the Consumer (from Payment Exchange) delivery note to the Consumer
which can optionally be signed
| |
v v
5. Consumer checks delivery <--------- Component: Delivery 5. Consumer checks delivery <--------- Component: Delivery
note is OK and accepts or waits Delivery Note note is OK and accepts or waits Delivery Note; Signature
for delivery as described in Response for delivery as described in Response (Delivery Response)
the Delivery Note 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 Deliver
To, Delivery Handler and Merchant Roles: 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 to
be delivered to be delivered to
- the Delivery Handler role is required so that the Delivery - the Delivery Handler role is required so that the Delivery Handler
Handler can check that she is the correct Delivery Handler to do can check that she is the correct Delivery Handler to do the
the delivery 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 or
services to be delivered services to be delivered
o The Delivery Component contains information about how delivery o The Delivery Component contains information about how delivery
will occur, for example by post or using e-mail. will occur, for example by post or using e-mail.
o The "Offer Response" Signature Component, if present,
digitally signs all of the above components to ensure their o The "Offer Response" Signature Component, if present, digitally
integrity. 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 and
the Offer Signature. This is used by the Delivery Handler to the Offer Signature. This is used by the Delivery Handler to
check that delivery is authorised check that delivery is authorised
o The Delivery Note Component contains customer care information o The Delivery Note Component contains customer care information
related to a physical delivery, or alternatively the actual related to a physical delivery, or alternatively the actual
"electronic goods". The Consumer's software does not interpret "electronic goods". The Consumer's software does not interpret
information about a physical delivery but should have the information about a physical delivery but should have the
ability to display the information, both at the time of the ability to display the information, both at the time of the
delivery and later if the Consumer selects the Trade to which delivery and later if the Consumer selects the Trade to which
this delivery relates from a transaction list. this delivery relates from a transaction list
o The "Delivery Response" Signature Component, if present,
provides proof of the results of the Delivery by digitally
signing the Delivery Note and any Offer Response or Payment
Response signatures that the Delivery Handler received.
2.2.4 Authentication Exchange 2.2.4 Authentication Exchange
The goal of the Authentication Exchange is to allow one organisation, 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. It
uses a "challenge-response" mechanism. This is illustrated in the uses a "challenge-response" mechanism.
diagram below.
ORGANISATION 1 OTP MESSAGE ORGANISATION 2 An Authentication Exchange involves:
o an Authenticator - the organisation which is requesting the
authentication, and
o an Authenticatee - the organisation being authenticated.
This is illustrated in the diagram below.
+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
ORGANISATION 1 IOTP MESSAGE ORGANISATION 2
(AUTHENTICATEE) (AUTHENTICATOR)
1. First organisation, 2. The second 1. First organisation, 2. The second
e.g a consumer, takes an organisation generates e.g a consumer, takes an organisation generates
action (for example by ----------------> Authentication Data action (for example by ----------------> Authentication Data
pressing a button on an Need for containing challenge data pressing a button on an Need for containing challenge
HTML page) which Authentication and the method of HTML page) which Authentication data, the method of
requires that the (outside scope of authentication to be used requires that the (outside scope of authentication to be used
organisation is OTP) then sends it to the organisation is IOTP) and optionally a request
authenticated first organisation authenticated for Organisation
information then sends it
to the first organisation
| |
v v
3. The first organisation uses Component: 3. The first organisation Component:
the challenge data with the <------------ Authentication Data optionally checks any signature <------------ Authentication Data
specified authentication method Authentication associated with the Authentication
to generate an Authentication Request Authentication request then Request
Response which is sent back to uses the challenge data with
the second organisation 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
| |
v v
Component: Component: 4. The Authentication Response is
Authentication -------------> 4. The Authentication Response is Authentication -------------> checked against the challenge data to
Response Authentication checked against the challenge data to Response Authentication check that the first organisation is
Response check that the first organisation is Response who they appear to be and the result
who they appear to be recorded in a Status Component which
is then sent back to the first
organisation
|
v
5. The first organisation then Component: Status
optionally checks the results <------------
of the Status and any Authentication
associated signature and takes Status
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 Data Component which contains the challenge
data to be used in the "challenge-response" mechanism and data to be used in the "challenge-response" mechanism,
indicates the authentication method to be used. It is sent by indicates the authentication method to be used and optionally
one organisation to the other. request Organisation data about the first organisation, for
o the Authentication Response Component which contains the example a ship to or billing address. It is sent by one
organisation to the other.
o The Authentication Response Component which contains the
challenge response generated by the recipient of the challenge response generated by the recipient of the
Authentication Data Component. It is sent back to the first Authentication Data Component. It is sent back to the first
organisation for verification. organisation for verification together with Organisation
Components requested
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 IOTP
skipping to change at page 25, line 47 skipping to change at page 33, line 39
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 IOTP
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, Delivery
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
The following table defines, for each role, the IOTP Transactions and The following table defines, for each role, the IOTP Transactions and
Trading Blocks which must be supported for that role. Trading Blocks which must be supported for that role.
Merchants Merchants
ECash ECash ECash ECash
Store Value Value Consumer Payment Delivery Pay Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler Inst. Issuer Acquirer Handler Handler
Cuts
Care
TRANSACTIONS TRANSACTIONS
Purchase Must Must Purchase Must Must
Refund Must b) Refund Must b)
Depends Depends
Authent- May Must May b) Authentication May Must May b)
ication Depends Depends
Value May Must Value Exchange May Must
Exchange
Withdrawal Must b) Withdrawal Must b)
Depends Depends
Deposit Must b) Deposit Must b)
Depends Depends
Inquiry Must Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Ping Must Must Must Must Must Must Must Ping Must Must Must Must Must Must
Merchants
Pay Inst. b) Must ECash ECash
Cust. Care Depends Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
TRADING TRADING BLOCKS
BLOCKS
TPO Must Must Must Must TPO Must Must Must Must
TPO Must Must Must Must TPO Selection Must Must Must Must
Selection
Auth-Requesta) a) a) Auth-Requesta) 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 Must Must Must Must Offer Response Must Must Must Must
Response
Payment Must Must Payment Must Must
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery Pay
Issuer Acquirer Handler Handler Inst.
Cuts
Care
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
Pay Inst. b) Must Inquiry Must Must Must Must Must Must
Cust Care Depends
Req.
Pay Inst. b) Must
Cust Care Depends
Resp
Inquiry Must Must Must Must Must Must Must
Request Request
Inquiry Must Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Response Response
Ping RequestMust Must Must Must Must Must Must Ping Request Must Must Must Must Must Must
Ping Must Must Must Must Must Must Must Ping Response Must Must Must Must Must Must
Response
Signature Must Must Must Limited Must Must b) Signature Must Must Must Limited Must Must
Depends
Error Must 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 or Trading Block. o _Must_ means that a Trading Role must support the Transaction
o _May_ means that an implementation may support the or Trading Block.
Transaction or Trading Block at the option of the developer.
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 _Depends_ means implementation of the Transaction or Trading
Block depends on one of the following conditions: Block depends on one of the following conditions:
- if Baseline Authentication IOTP Transaction is a) if Baseline Authentication IOTP Transaction is supported;
supported; b) if required by a Payment Method as defined in its IOTP
- 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 its
content manipulated but not in every respect. Specifically, on content manipulated but not in every respect. Specifically, on
the Signature Block, Consumers do not have to be able to the Signature Block, Consumers do not have to be able to
validate digital signatures. 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 can take in a trade: Consumer, Merchant, Payment o Trading Roles which are the different roles which organisations
Handler, Delivery Handler and Merchant and Payment Instrument can take in a trade: Consumer, Merchant, Payment Handler,
Customer Care Provider, and 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 set
of Trading Components. 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 and
the IOTP Messages which are physically sent in the form of the IOTP Messages which are physically sent in the form of
[XML] documents between the different Trading Roles, [XML] documents between the different Trading Roles,
o how IOTP Messages are exchanged between Trading Roles to
create an IOTP Transaction o how IOTP Messages are exchanged between Trading Roles to create
an IOTP Transaction
o the XML definitions of an IOTP Message including a Transaction o the XML definitions of an IOTP Message including a Transaction
Reference Block - an XML element which identifies an IOTP Reference Block - an XML element which identifies an IOTP
Transaction and the IOTP Message within it Transaction and the IOTP Message within it
o the definitions of the XML ID Attributes which are used to 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 Components
and how these are referred to using Element References from and how these are referred to using Element References from
other XML elements such as other XML elements
o IOTP Signature Components which use digital signature
techniques to preserve the integrity of IOTP Messages and o an overview of Brands and Brand Selection which describes how a
provide the trust relationships required by IOTP Consumer can select a Brand from a list provided by the
o how extra XML Elements and new user defined values for Merchant
existing IOTP codes can be used when Extending IOTP, and
finally o how extra XML Elements and new user defined values for existing
IOTP codes can be used when Extending IOTP,
o how IOTP uses the Packaged Content Element to embed data such
as payment protocol messages or detailed order definitions
within an IOTP Message
o how IOTP Identifies Languages so that different languages can
be used within IOTP Messages
o how IOTP handles both Secure and Insecure Net Locations when
sending messages
o how an IOTP Transaction can be cancelled.
3.1 Overview 3.1 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.
OTP MESSAGE <----------- OTP 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 OTP Transaction and the OTP | | 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 OTP Transaction. The Trans Id | | identifies the IOTP Transaction. The Trans Id
| | Components are the same across all OTP | | Components are the same across all IOTP
| | messages that comprise a single OTP | | messages that comprise a single IOTP
| | transaction. | | transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies and | |-Msg Id Comp. <----- Message Id Component - identifies and
| describes an OTP Message within an OTP | 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 hashes of the | | signatures. Signatures may sign digests of
| | Trans Ref Block and any Trading Component in | | the Trans Ref Block and any Trading Component
| | any OTP Message in the same OTP Transaction. | | in any IOTP Message in the same IOTP
| | transaction.
| |-Certificate Comp. < Certificate Component. Used to check the | |-Certificate Comp. < Certificate Component. Used to check the
| signature. | signature.
|-Trading Block <------- Trading Block - an XML Element within an OTP |-Trading Block <------- Trading Block - an XML Element within an IOTP
| |-Component Message that contains a predefined set of | |-Component Message that contains a predefined set of
| |-Component Trading Components | |-Component Trading Components
| |-Component | |-Component
| |-Component <-------- Trading Components - XML Elements within a | |-Component <-------- 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 | |-Component information required to support a Trading
| |-Component Exchange | |-Component Exchange
| |-Component | |-Component
| |-Component | |-Component
| |-Component | |-Component
|
|
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 IOTP
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
OTP Message IOTP Message
--- | --- |
| | v | | v
Process incoming | I | ------------- Process incoming | I | -------------
OTP Message & <------------- | | -------------- | OTP Message | IOTP Message & <------------- | | -------------- | IOTP Message |
generate next OTP | | ------------- generate next IOTP | | -------------
Message | N | Message | N |
| | | | | |
v | | v | |
------------- | T | Process incoming ------------- | T | Process incoming
| OTP Message | -------------- | | -------------> OTP Message & | IOTP Message | -------------- | | -------------> IOTP Message &
------------- | | generate next OTP ------------- | | generate next
| E | Message | E | IOTP Message
| | | | | |
| | v | | v
Process incoming | R | ------------- Process incoming | R | -------------
OTP Message <------------- | | -------------- | OTP Message | IOTP Message <------------- | | -------------- | IOTP Message |
generate last OTP | | ------------- generate last IOTP | | -------------
Message & stop | N | Message & stop | N |
| | | | | |
v | | v | |
------------- | E | Process last ------------- | E | Process last
| OTP Message | -------------- | | -------------> incoming OTP | 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 8) 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 of,
typically, an earlier purchase 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 the
exchange of value from one combination of currency and payment exchange of value from one combination of currency and payment
method to another method to another
o Authentication. This supports the remote authentication of a o Authentication. This supports the remote authentication of a
Consumer by another Trading Role using a variety of Consumer by another Trading Role using a variety of
authentication methods, and the provision of an Organisation authentication methods, and the provision of an Organisation
Component about a Consumer to another Trading Role for use in, Component about a Consumer to another Trading Role for use in,
for example the creation of an offer 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 Payment Instrument Customer Care. This supports the provision
of Payment Brand or Payment Method specific customer care of a
Payment Instrument
o Inquiry This supports inquiries on the status of an IOTP 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 aware
application to determine whether another IOTP application application to determine whether another IOTP application
running elsewhere is working or not. 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 organisations 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 (TransRefBlk, SigBlk?, ErrorBlk?, <!ELEMENT OtpMessage
( TransRefBlk,
SigBlk?,
ErrorBlk?,
( AuthReqBlk | ( AuthReqBlk |
AuthRespBlk | AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk | DeliveryReqBlk |
DeliveryRespBlk | DeliveryRespBlk |
InquiryReqBlk | InquiryReqBlk |
InquiryRespBlk | InquiryRespBlk |
OfferRespBlk | OfferRespBlk |
PayExchBlk | PayExchBlk |
PayReqBlk | PayReqBlk |
PayInstCCExchBlk |
PayInstCCReqBlk |
PayInstCCRespBlk
PayRespBlk | PayRespBlk |
PingReqBlk | PingReqBlk |
PingRespBlk | PingRespBlk |
TpoBlk | TpoBlk |
TpoSelectionBlk | TpoSelectionBlk
)* )*
) > ) >
<!ATTLIST OtpMessage
xmlns:iotp CDATA
'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-03' >
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 Open InquiryRespBlk, definition of each transaction in section 8
OfferRespBlk, 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
PayInstCCExchBlk, described in section 7. PayRespBlk, described in section 7.
PayInstCCReqBlk,
PayInstCCRespBlk
PayRespBlk,
PingReqBlk, PingReqBlk,
PingRespBlk, PingRespBlk,
SigBlk, SigBlk,
TpoBlk, TpoBlk,
TpoSelectionBlk TpoSelectionBlk
Attributes
xmlns:iotp The [XML Namespace] definition for IOTP
messages.
3.2.1 XML Document Prolog 3.2.1 XML Document Prolog
The IOTP Message is the root element of the XML document. It therefore The IOTP Message is the root element of the XML document. It therefore
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 OtpMessage >
<OtpMessage> <OtpMessage>
... ...
skipping to change at page 33, line 22 skipping to change at page 45, line 30
<!DOCTYPE OtpMessage > <!DOCTYPE OtpMessage >
<OtpMessage> <OtpMessage>
... ...
</OtpMessage> </OtpMessage>
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 Block
contains: contains:
o a Transaction Id Component which globally uniquely identifies o a Transaction Id Component which globally uniquely identifies
the IOTP Transaction. The Transaction Id Components are the the IOTP Transaction. The Transaction Id Components are the
same across all IOTP messages that comprise a single IOTP same across all IOTP messages that comprise a single IOTP
transaction, transaction,
o a Message Id Component which provides control information
about the IOTP Message as well as uniquely identifying the o a Message Id Component which provides control information about
IOTP Message within an IOTP Transaction, and the IOTP Message as well as uniquely identifying the IOTP
Message within an IOTP Transaction, and
o zero or more Related To Components which link this IOTP 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 events
using the identifiers of those events. using the identifiers of those events.
The definition of a Transaction Reference Block is as follows: The definition of a Transaction Reference Block is as follows:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk <!ATTLIST TransRefBlk
ID ID #REQUIRED > ID ID #REQUIRED >
skipping to change at page 33, line 50 skipping to change at page 46, line 20
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Transaction Reference Block within the IOTP Transaction Reference Block within the IOTP
Transaction (see section 3.4 ID Attributes). Transaction (see section 3.4 ID Attributes).
Content: Content:
TransId See 3.3.1 Transaction Id Component immediately TransId See 3.3.1 Transaction Id Component immediately
below. below.
MsgId See 3.3.2 Message Id Component immediately below. MsgId See 3.3.2 Message Id Component immediately
below.
RelatedTo See 3.3.3 Related To Component immediately below. RelatedTo See 3.3.3 Related To Component immediately
below.
3.3.1 Transaction Id Component 3.3.1 Transaction Id Component
This contains information which globally uniquely identifies the IOTP This contains information which globally uniquely identifies the IOTP
Transaction. Its definition is as follows: Transaction. Its definition is as follows:
<!ELEMENT TransId EMPTY> <!ELEMENT TransId EMPTY>
<!ATTLIST TransId <!ATTLIST TransId
ID ID #REQUIRED ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0' Version NMTOKEN #FIXED '1.0'
OtpTransId NMTOKEN #REQUIRED OtpTransId NMTOKEN #REQUIRED
OtpTransType CDATA #REQUIRED > OtpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED > TransTimeStamp CDATA #REQUIRED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP Transaction Id Component within the IOTP
Transaction. Transaction.
Version This identifies the version of IOTP, and therefore Version This identifies the version of IOTP, and
the structure of the IOTP Messages, which the IOTP therefore the structure of the IOTP Messages,
Transaction is using. which the IOTP Transaction is using.
OtpTransId Contains data which uniquely identifies the IOTP OtpTransId 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 carried OtpTransType This is the type of IOTP Transaction being
out. For Baseline IOTP it identifies a "standard" carried out. For Baseline IOTP it identifies a
IOTP Transaction and implies the sequence and "standard" IOTP Transaction and implies the
content of the IOTP Messages exchanged between the sequence and content of the IOTP Messages
Trading Roles. The valid values for Baseline IOTP exchanged between the Trading Roles. The valid
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
o BaselinePayInstrumentCustomerCare
o x-ddd:nnn
A value for OtpTransType of x-ddd:nnn indicates a Values of OtpTransType are managed under the
user defined transaction type. See section 3.7.3 procedure described in section 3.7.3 Values for
User Defined Codes. IOTP Codes which also allows user defined values
of OtpTransType 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 based on market demand. It is
also likely to support the type Dynamic which also likely to support the type Dynamic which
indicates that the sequence of steps within the indicates that the sequence of steps within the
transaction are non-standard. transaction are non-standard.
TransTimeStamp Where the system initiating the IOTP Transaction TransTimeStamp Where the system initiating the IOTP Transaction
has an internal clock, it is set to the time at has an internal clock, it is set to the time at
which the IOTP Transaction started in [UTC] which the IOTP Transaction started in [UTC]
format. format.
The main purpose of this attribute is to provide The main purpose of this attribute is to provide
an alternative way of identifying a transaction by an alternative way of identifying a transaction
specifying the time at which it started. by specifying the time at which it started.
Some systems, for example, hand held devices may Some systems, for example, hand held devices may
not be able to generate a time stamp. In this not be able to generate a time stamp. In this
case this attribute should contain the value "NA" case this attribute should contain the value
for Not Available. "NA" for Not Available.
3.3.2 Message Id Component 3.3.2 Message Id Component
The Message Id Component provides control information about the IOTP The Message Id Component provides control information about the IOTP
Message as well as uniquely identifying the IOTP Message within an 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 RespOtpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
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 IOTP
Message within the IOTP Transaction (see section Message within the IOTP Transaction (see section
3.4 ID Attributes). Note that if an IOTP Message 3.4 ID Attributes). Note that if an IOTP Message
is resent then the value of this attribute remains is resent then the value of this attribute
the same. remains the same.
RespOtpMsg This contains the ID attribute of the Message Id RespOtpMsg This contains the ID attribute of the Message Id
Component of the IOTP Message to which this IOTP Component of the IOTP Message to which this IOTP
Message is a response. In this way all the IOTP Message is a response. In this way all the IOTP
Messages in an IOTP Transaction are unambiguously Messages in an IOTP Transaction are
linked together. This field is required on every unambiguously linked together. This field is
IOTP Message except the first IOTP Message in an required on every IOTP Message except the first
IOTP Transaction. IOTP Message in an IOTP Transaction.
SenderTradingRoleR The Element Reference (see section 3.5) of the
ef Trading Role which has generated the IOTP
message. It is used to identify the Net
Locations (see section 3.10) of the Trading Role
to which problems Technical Errors (see section
4.1) with any of Trading Blocks should be
reported.
xml:lang Defines the language used by attributes or child xml:lang Defines the language used by attributes or child
elements within this component, unless overridden elements within this component, unless
by an xml:lang attribute on a child element. See overridden by an xml:lang attribute on a child
section 3.9 Identifying Languages. element. See section 3.9 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 in different software. It is a single text string
the language defined by xml:lang. It must contain, in the language defined by xml:lang. It must
as a minimum: contain, as a minimum:
o the name of the software manufacturer o the name of the software manufacturer
o the name of the software o the name of the software
o the version of the software, and o the version of the software, and
o the build of the software o the build of the software
TimeStamp Where the device sending the message has an TimeStamp Where the device sending the message has an
internal clock, it is set to the time at which the internal clock, it is set to the time at which
IOTP Message was created in [UTC] format. the IOTP Message was created in [UTC] format.
3.3.3 Related To Component 3.3.3 Related To Component
The Related To Component links IOTP Transactions to either other IOTP The Related To Component links IOTP Transactions to either other IOTP
Transactions or other events using the identifiers of those events. Transactions or other events using the identifiers of those events.
Its definition is as follows. Its definition is as follows.
<!ELEMENT RelatedTo (PackagedContent) > <!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo <!ATTLIST RelatedTo
ID ID #REQUIRED ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED > RelnKeyWords NMTOKENS #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Related To Component within the IOTP Transaction. Related To Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or child xml:lang Defines the language used by attributes or child
elements within this component, unless overridden elements within this component, unless
by an xml:lang attribute on a child element. See overridden by an xml:lang attribute on a child
section 3.9 Identifying Languages. element. See section 3.9 Identifying Languages.
RelationshipType Defines the type of the relationship. Valid values RelationshipType Defines the type of the relationship. Valid
are: values are:
o OtpTransaction. in which case the Packaged o OtpTransaction. in which case the Packaged
Content Element contains an OtpTransId of Content Element contains an OtpTransId 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.
o x-ddd:nnn a user defined code (see section
3.7.3) Values of RelationshipType are controlled under
the procedures defined in section 3.7.3 Values
for IOTP Codes which also allows user 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 exact another IOTP Transaction or other event. The
words to be used are left to the implementer of exact words to be used are left to the
the IOTP software. implementers of the IOTP software.
The purpose of the attribute is to provide the The purpose of the attribute is to provide the
Trading Roles involved in an IOTP Transaction with Trading Roles involved in an IOTP Transaction
an explanation of the nature of the relationship with an explanation of the nature of the
between the transactions. relationship between the transactions.
Care should be taken that the words used to in the Care should be taken that the words used to in
Relation attribute indicate the "direction" of the the Relation attribute indicate the "direction"
relationship correctly. For example: one of the relationship correctly. For example: one
transaction might be a refund for another earlier transaction might be a refund for another
transaction. In this case the transaction which is earlier transaction. In this case the
a refund should contain in the Relation attribute transaction which is a refund should contain in
words such as "refund for" rather than "refund to" the Relation attribute words such as "refund
or just "refund". for" rather than "refund to" or just "refund".
RelnKeyWords This attribute contains keywords which could be RelnKeyWords This attribute contains keywords which could be
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 the implementer. discretion of implementers.
Content: Content:
PackagedContent The Packaged Content (see section 3.8) contains PackagedContent The Packaged Content (see section 3.8) contains
data which identifies the related transaction. Its data which identifies the related transaction.
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 each
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 attribute
skipping to change at page 38, line 13 skipping to change at page 51, line 28
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 the
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 Element
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 OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix
OtpMsgIdPrefix ::= NameChar (NameChar)* OtpMsgIdPrefix ::= NameChar (NameChar)*
OtpMsgIdSuffix ::= Digit (Digit)* OtpMsgIdSuffix ::= Digit (Digit)*
OtpMsgIdPrefix Apart from messages which contain an Inquiry OtpMsgIdPrefix Apart from messages which contain an Inquiry
Request Trading Block (see section 7.14), the same Request Trading Block (see section 7.12), the
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
contained within the Organisation Component for contained within the Organisation Component for
the role and are typically set by the Merchant. the role and are typically set by the Merchant.
The following is recommended as a guideline and The following is recommended as a guideline and
must not be relied upon: must not be relied upon:
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 one As a guideline, prefixes should be limited to
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 OtpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role within suffix must be unique within a Trading Role
an IOTP Transaction. The following is recommended within an IOTP Transaction. The following is
as a guideline and must not be relied upon: recommended as a guideline and must not be
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 by o the second and subsequent IOTP Messages sent
the same trading role are incremented by one for by the same trading role are incremented by
each message one for each message
o no leading zeroes are included in the suffix o no leading zeroes are included in the suffix
Put more simply the Message Id Component of the Put more simply the Message Id Component of the
first IOTP Message sent by a Consumer would have first IOTP Message sent by a Consumer would have
an ID attribute of, "C1", the second "C2", the an ID attribute of, "C1", the second "C2", the
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
skipping to change at page 39, line 23 skipping to change at page 53, line 17
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 "." IdSuffix BlkOrCompId_value ::= OtpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)* IdSuffix ::= Digit (Digit)*
OtpMsgId The ID attribute of the Message ID Component of OtpMsgId_value The ID attribute of the Message ID Component of
the IOTP Message where the Block or Component is the IOTP Message where the Block or Component is
first used. first used.
In IOTP, Trading Components and Trading Blocks are In IOTP, Trading Components and Trading Blocks
copied from one IOTP Message to another. The ID are copied from one IOTP Message to another. The
attribute does not change when an existing Trading ID attribute does not change when an existing
Block or Component is copied to another IOTP Trading Block or Component is copied to another
Message. IOTP Message.
IdSuffix The suffix consists of one or more digits. The IdSuffix The suffix consists of one or more digits. The
suffix must be unique within the ID attribute of suffix must be unique within the ID attribute of
the Message ID Component used to generate the ID the Message ID Component used to generate the ID
attribute. The following is recommended as a attribute. The following is recommended as a
guideline and must not be relied upon: guideline and must not be relied upon:
o the first Block or Component sent by a trading o the first Block or Component sent by a trading
role is given the suffix "1" role is given the suffix "1"
o the ID attributes of the second and subsequent o the ID attributes of the second and subsequent
Blocks or Components are incremented by one for Blocks or Components are incremented by one
each new Block or Component added to an IOTP for each new Block or Component added to an
Message IOTP Message
o no leading zeroes are included in the suffix o no leading zeroes are included in the suffix
Put more simply, the first new Block or Component Put more simply, the first new Block or
added to the second IOTP Message sent, for Component added to the second IOTP Message sent,
example, by a consumer would have a an ID for example, by a consumer would have a an ID
attribute of "C2.1", the second "C2.2", the third attribute of "C2.1", the second "C2.2", the
"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 OTP MESSAGE 2nd OTP 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)
OTP MESSAGE OTP 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. ------------->| |-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
skipping to change at page 40, line 37 skipping to change at page 54, line 41
| | 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.3
|-Comp. ID=M1.4 * = new elements |-Comp. ID=M1.4 * = new elements
|-Comp. ID=M1.5 |-Comp. ID=M1.5
|-Comp. ID=M1.6 |-Comp. ID=M1.6
|-Comp. ID=M1.7 |-Comp. ID=M1.7
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 hash value 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 o referring to the Payment Handler Organisation Component which
is used when making a Payment is used when making a Payment
An Element Reference always contains the value of an ID attribute of a An Element Reference always contains the value of an ID attribute of 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 which
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 Id
Components of the IOTP Messages match), and Components of the IOTP Messages match), and
o where the value of the ID attribute of the element matches the o where the value of the ID attribute of the element matches the
value of the Element Reference. 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.
skipping to change at page 41, line 20 skipping to change at page 56, line 5
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 the
value of the Element Reference. 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 OTP MESSAGE 2nd OTP 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)
OTP MESSAGE OTP 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. <-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
skipping to change at page 41, line 48 skipping to change at page 56, line 35
| |-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.6
| |-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.3
|-Comp. ID=M1.4 |-Comp. ID=M1.4
|-Comp. ID=M1.5 |-Comp. ID=M1.5
|-Comp. ID=M1.6 |-Comp. ID=M1.6
|-Comp. ID=M1.7 |-Comp. ID=M1.7
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 Brands and Brand Selection
skipping to change at page 42, line 12 skipping to change at page 57, line 7
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 Brands and Brand Selection
One of the key features of IOTP is the ability for a merchant to offer 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 a list of Brands from which a consumer may make a selection. This
section provides an overview of what is involved and provides guidance section provides an overview of what is involved and provides guidance
on how selection of a brand and associated payment instrument can be on how selection of a brand and associated payment instrument can be
carried out by a Consumer. It covers: carried out by a Consumer. It covers:
o definitions of Payment Instruments and Brands - what are o definitions of Payment Instruments and Brands - what are
Payment Instruments and Brands in an IOTP context. Further Payment Instruments and Brands in an IOTP context. Further
categorises Brands as optionally a "Dual Brand" or a categorises Brands as optionally a "Dual Brand" or a
"Promotional Brand", "Promotional Brand",
o identification and selection of Promotional Brands - o identification and selection of Promotional Brands -
Promotional Brands offer a Consumer some additional benefit, Promotional Brands offer a Consumer some additional benefit,
for example loyalty points or a discount. This means that both for example loyalty points or a discount. This means that both
Consumers and Merchant must be able to correctly identify that Consumers and Merchant must be able to correctly identify that
a valid Promotional Brand is being used. a valid Promotional Brand is being used.
Also see the following sections: Also see the following sections:
o Brand List Component (section 6.6) which contains definitions o Brand List Component (section 6.6) which contains definitions
of the XML elements which contain the list of Brands offered of the XML elements which contain the list of Brands offered by
by a Merchant to a Consumer, and a Merchant to a Consumer, and
o Brand Selection Component (section 6.7) for details of how a o Brand Selection Component (section 6.7) for details of how a
Consumer records the Brand that was selected. Consumer records the Brand that was selected.
3.6.1 Definition of Payment Instrument 3.6.1 Definition of Payment Instrument
A Payment Instrument is the means by which Consumer pays for goods or A Payment Instrument is the means by which a Consumer pays for goods
services offered by a Merchant. It can be, for example: or services offered by a Merchant. It can be, for example:
o a credit card such as MasterCard or Visa; o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro; 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 smart card based electronic cash payment instrument such as a
o a software based electronic payment account such as a Mondex Card, a GeldKarte card or a Visa Cash card
CyberCash or DigiCash account.
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 All Payment Instruments have a number, typically an account number, by
which the Payment Instrument can be identified. which the Payment Instrument can be identified.
3.6.2 Definition of Brand 3.6.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are Instrument. A list of Brands are the payment options which are
presented by the Merchant to the Consumer and from which the Consumer presented by the Merchant to the Consumer and from which the Consumer
makes a selection. Each Brand may have a different Payment Handler. makes a selection. Each Brand may have a different Payment Handler.
skipping to change at page 42, line 50 skipping to change at page 58, line 12
All Payment Instruments have a number, typically an account number, by All Payment Instruments have a number, typically an account number, by
which the Payment Instrument can be identified. which the Payment Instrument can be identified.
3.6.2 Definition of Brand 3.6.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are Instrument. A list of Brands are the payment options which are
presented by the Merchant to the Consumer and from which the Consumer presented by the Merchant to the Consumer and from which the Consumer
makes a selection. Each Brand may have a different Payment Handler. makes a selection. Each Brand may have a different Payment Handler.
Examples of Brands include: Examples of Brands include:
o payment association and proprietary Brands, for example o payment association and proprietary Brands, for example
MasterCard, Visa, American Express, Diners Club, American MasterCard, Visa, American Express, Diners Club, Mondex,
Express, Mondex, GeldKarte, CyberCash, etc. GeldKarte, CyberCash, etc.
o promotional brands (see below). These include:
- store brands, where the Payment Instrument is issued to a o promotional brands (see below). These include:
Consumer by a particular Merchant, for example Walmart, Sears, - store brands, where the Payment Instrument is issued to a Consumer
or Marks and Spencer (UK) by a particular Merchant, for example Walmart, Sears, or Marks and
Spencer (UK)
- cobrands, for example American Advantage Visa, where an - cobrands, for example American Advantage Visa, where an
organisation uses their own brand in conjunction with, organisation uses their own brand in conjunction with, typically,
typically, a payment association Brand. a payment association Brand.
3.6.3 Definition of Dual Brand 3.6.3 Definition of Dual Brand
A Dual Brand means that a single payment instrument may be used as if 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 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 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 regular MasterCard. The UC card Brand and the MasterCard Brand could
each have their own separate Payment Handlers. This means that: each have their own separate Payment Handlers. This means that:
o the merchant treats, for example "UC" and "MasterCard" as two o the merchant treats, for example "UC" and "MasterCard" as two
separate Brands when offering a list of Brands to the separate Brands when offering a list of Brands to the Consumer,
Consumer,
o the consumer chooses a Brand, for example either "UC" or o the consumer chooses a Brand, for example either "UC" or
"MasterCard, "MasterCard,
o the consumer IOTP aware application determines which Payment o the consumer IOTP aware application determines which Payment
Instrument(s) match the chosen Brand, and selects, perhaps Instrument(s) match the chosen Brand, and selects, perhaps with
with user assistance, the correct Payment Instrument to use. user assistance, the correct Payment Instrument to use.
[Note] Dual Brands need no special treatment by the Merchant and [Note] Dual Brands need no special treatment by the Merchant and
therefore no explicit reference is made to Dual Brands in therefore no explicit reference is made to Dual Brands in
the DTD. This is because, as far as the Merchant is the DTD. This is because, as far as the Merchant is
concerned, each Brand in a Dual Brand is treated as a concerned, each Brand in a Dual Brand is treated as a
separate Brand. It is at the Consumer, that the matching of separate Brand. It is at the Consumer, that the matching of
a Brand to a Dual Brand Payment Instrument needs to be done. a Brand to a Dual Brand Payment Instrument needs to be done.
[Note End] [Note End]
3.6.4 Definition of Promotional Brand 3.6.4 Definition of Promotional Brand
A Promotional Brand means that, if the Consumer pays with that Brand, A Promotional Brand means that, if the Consumer pays with that Brand,
then the Consumer will receive some additional benefit which can be then the Consumer will receive some additional benefit which can be
received in two ways: received in two ways:
o at the time of purchase. For example if a Consumer pays with a 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 "Walmart MasterCard" at a Walmart web site, then a 5% discount
might apply, which means the consumer actually pays less, might apply, which means the consumer actually pays less,
o from their Payment Instrument (card) issuer when the payment o from their Payment Instrument (card) issuer when the payment
appears on their statement. For example loyalty points in a appears on their statement. For example loyalty points in a
frequent flyer scheme could be awarded based on the total frequent flyer scheme could be awarded based on the total
payments made with the Payment Instrument since the last payments made with the Payment Instrument since the last
statement was issued. statement was issued.
Note that: Note that:
o the first example (obtaining the benefit at the time of o the first example (obtaining the benefit at the time of
purchase), requires that: purchase), requires that:
- the Consumer is informed of the benefits which arise if that - the Consumer is informed of the benefits which arise if that Brand
Brand is selected is selected
- if the Brand is selected, the Merchant changes the relevant IOTP - if the Brand is selected, the Merchant changes the relevant IOTP
Components in the Offer Response to reflect the correct amount Components in the Offer Response to reflect the correct amount to
to be paid be paid
o the second (obtaining a benefit through the Payment Instrument o the second (obtaining a benefit through the Payment Instrument
issuer) does not require that the Offer Response is changed 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 o each Promotional Brand should be identified as a separate Brand
example: "Walmart", "Sears", "Marks and Spencer" and "American in the list of Brands offered by the Merchant. For example:
Advantage Visa", would each be a separate Brand. "Walmart", "Sears", "Marks and Spencer" and "American Advantage
Visa", would each be a separate Brand.
3.6.5 Identifying Promotional Brands 3.6.5 Identifying Promotional Brands
There are two problems which need to handled in identifying There are two problems which need to handled in identifying
Promotional Brands: Promotional Brands:
o how does the Merchant or their Payment Handler positively o how does the Merchant or their Payment Handler positively
identify the promotional brand being used at the time of identify the promotional brand being used at the time of
purchase purchase
o how does the Consumer reliably identify the correct
promotional brand from the Brand List presented by the
Merchant
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. The following is a description of how this could be achieved.
[Note] Please note that the approach described here is a model [Note] Please note that the approach described here is a model
approach that solves the problem. Other equivalent methods approach that solves the problem. Other equivalent methods
may be used. may be used.
[Note End] [Note End]
3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands 3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a Promotional Correct identification that the Consumer is paying using a Promotional
skipping to change at page 44, line 40 skipping to change at page 60, line 19
[Note End] [Note End]
3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands 3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a Promotional Correct identification that the Consumer is paying using a Promotional
Brand is important since a Consumer might fraudulently claim to have a Brand is important since a Consumer might fraudulently claim to have a
Promotional Brand that offers a reduced payment amount when in reality Promotional Brand that offers a reduced payment amount when in reality
they do not. they do not.
Two approaches seem possible: Two approaches seem possible:
o use some feature of the Payment Instrument or the payment o use some feature of the Payment Instrument or the payment
method to positively identify the Brand being used. For method to positively identify the Brand being used. For
example, the SET certificate for the Brand could be used, if example, the SET certificate for the Brand could be used, if
one is available, or one is available, or
o use the Payment Instrument (card) number to look up
information about the Payment Instrument on a Payment o use the Payment Instrument (card) number to look up information
Instrument issuer database to determine if the Payment about the Payment Instrument on a Payment Instrument issuer
Instrument is a promotional brand database to determine if the Payment Instrument is a
promotional brand
Note that: Note that:
o the first assumes that SET is available. o the first assumes that SET is available.
o the second is only possible if the Merchant, or alternatively o the second is only possible if the Merchant, or alternatively
the Payment Handler, has access to card issuer information. the Payment Handler, has access to card issuer information.
IOTP does not provide the Merchant with Payment Instrument 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 (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: encapsulated payment protocol to a Payment Handler. This means that:
o the Merchant would have to assume that the Payment Instrument o the Merchant would have to assume that the Payment Instrument
selected was a valid Promotional Brand, or selected was a valid Promotional Brand, or
o the Payment Handler would have to check that the Payment o the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the Instrument was for the valid Promotional Brand and fail the
payment if it was not. payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer. is most likely if the Payment Handler is also the Card Issuer.
3.6.5.2 Consumer Selection of Promotional Brands 3.6.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand Two ways by which a Consumer can correctly select a Promotional Brand
skipping to change at page 45, line 21 skipping to change at page 61, line 9
Instrument was for the valid Promotional Brand and fail the Instrument was for the valid Promotional Brand and fail the
payment if it was not. payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer. is most likely if the Payment Handler is also the Card Issuer.
3.6.5.2 Consumer Selection of Promotional Brands 3.6.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand Two ways by which a Consumer can correctly select a Promotional Brand
are: 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 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 o the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered against Promotional Brand which the application has registered against
a similar code contained in the list of Brands offered by the a similar code contained in the list of Brands offered by the
Merchant. Merchant.
In the latter case, the code contained in the Consumer wallet must In the latter case, the code contained in the Consumer wallet must
match exactly the code in the list offered by the Merchant otherwise 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 no match will be found. Ways in which the Consumer's IOTP Aware
Application could obtain such a code include: Application could obtain such a code include:
o the Consumer types the code in directly. This is error prone o the Consumer types the code in directly. This is error prone
and not user friendly, also the consumer needs to be provided and not user friendly, also the consumer needs to be provided
with the code. This approach is not recommended, with the code. This approach is not recommended,
o using some information contained in the software or other data o using some information contained in the software or other data
associated with the Payment Instrument. This could be: associated with the Payment Instrument. This could be:
- a SET certificate for Brands which use this payment method - a SET certificate for Brands which use this payment method
- a code provided by the payment software which handles the - a code provided by the payment software which handles the
particular payment method, this could apply to, for example, particular payment method, this could apply to, for example,
GeldKarte, Mondex, CyberCash and DigiCash GeldKarte, Mondex, CyberCash and DigiCash
o the consumer making a initial "manual" link between a o the consumer making a initial "manual" link between a
Promotional Brand in the list of Brands offered by the Promotional Brand in the list of Brands offered by the Merchant
Merchant and an individual Payment Instrument, the first time and an individual Payment Instrument, the first time the
the promotional brand is used. The IOTP Aware application promotional brand is used. The IOTP Aware application would
would then "remember" the code for the Promotional Brand for then "remember" the code for the Promotional Brand for use in
use in future purchases future purchases
[Note] It is not the intention of the developers of this [Note] It is not the intention of the developers of this
specification to develop a prescriptive list of payment specification to develop a prescriptive list of payment
brands. It is anticipated that owners of brands will develop brands. It is anticipated that owners of brands will develop
distinctive names for Brands which should mean that name distinctive names for Brands which should mean that name
clashes are unlikely. clashes are unlikely.
[Note End] [Note End]
3.7 Extending IOTP 3.7 Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting IOTP Baseline IOTP defines a minimum protocol which systems supporting IOTP
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 user-defined values for existing IOTP codes.
o new values for existing IOTP codes.
3.7.1 Extra XML Elements 3.7.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]. This allows IOTP to support the inclusion of [XML Namespace] as identified by the xmlns attribute on the OtpMessage
additional XML elements within IOTP messages through the use of [XML element. This allows IOTP to support the inclusion of additional XML
Namespaces]. elements within IOTP messages through the use of [XML Namespaces].
[Note] In drafts of the [XML] specification, the concept of Using XML Namespaces, extra XML elements may be included at any level
"Namespaces" have been discussed. However they are not within an IOTP message including:
present in the XML documentation submitted for approval (see
XML draft dated 8 December 1997) although it appears as if
they may be included in version 1.1 of XML. It is considered
by the authors of this document that IOTP would be an ideal
example of a Namespace so that other XML elements with
potentially the same name can be included unambiguously in
XML documents which conform to this specification. If
Namespaces, or an equivalent, is not developed for XML as a
whole then IOTP is likely to propose its own equivalent. The
Views of other organisations on this topic are sought.
[Note End]
Extra XML elements may be included at any level within an IOTP message
including:
o new Trading Blocks o new Trading Blocks
o new Trading Components o new Trading Components
o new XML elements within a Trading Component. o new XML elements within a Trading Component.
The following rules apply: The following rules apply:
o any new XML element must be declared according to the rules
for [XML Namespaces]. This means that: o any new XML element must be declared according to the rules for
- the namespace must be declared to the XML parser [XML Namespaces]
- each element must have a start and end tags which conform to the
rules for XML Namespaces
o new XML elements which are either Trading Blocks or Trading o new XML elements which are either Trading Blocks or Trading
Components must contain an ID attributes with an attribute Components must contain an ID attributes with an attribute name
name of ID. 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 to
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 value of "True" and an IOTP aware application does not know o if an extra XML element has an "IOTP:Critical" attribute with a
how to process the element and its child elements, then the value of "True" and an IOTP aware application does not know how
IOTP transaction must fail. See section 6.19 Error Component. to process the element and its child elements, then the IOTP
o if an extra XML element has an "IOTP:Critical" attribute with transaction has a Technical Error (see section 4.1) and must
a value of "False" then the IOTP transaction may continue if fail.
the IOTP aware application does not know how to process it. In
this case: o if an extra XML element has an "IOTP:Critical" attribute with a
value of "False" then the IOTP transaction may continue if the
IOTP aware application does not know how to process it. In this
case:
- any extra XML elements contained within an XML element defined - 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 it
must be included when it is hashed as part of the generation of must be included when it is used in the creation of a digest as
a signature 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 then
it must be treated as if it had an "IOTP:Critical" attribute it must be treated as if it had an "IOTP:Critical" attribute
with a value of "True" 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, then
the value of that attribute is assumed to apply to all the the value of that attribute is assumed to apply to all the
child elements within that element 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.7.2 Opaque Embedded Data
skipping to change at page 47, line 39 skipping to change at page 63, line 41
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.7.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.8) should be used to encapsulate the
data. data.
3.7.3 User Defined Codes 3.7.3 Values for IOTP Codes
User defined codes provide a simple way to identify additional values Codes used by IOTP are registered by [IANA] so that new values can be
for the codes contained within this specification. co-ordinated based on an IETF consensus as defined in RFC 2434.
The definition of a user defined code is as follows: 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.
user_defined_code ::= ( "x-" | "X-" ) domain_name ":" name Element Type Attribute Attribute Values
Name
domain_name A name which identifies the organisation which is AuthData AuthMethod sha1
creating the user defined code (see [DNS]). The
purpose of this field is to reduce the probability of
two organisations creating the same user-defined name
name A name specified by the organisation which owns the signature
domain_name which identifies the user defined code
within the domain_name.
User defined codes are identified in this specification as "x- pay:ppp where ppp may be set to any
ddd:nnn". The values of User Defined Codes must conform to the rules valid value for iotpbrand (see below)
for the specific code (see explanations of the individual codes).
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 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.
In general it is used to encapsulate any data stream. o to encapsulate a description of an order, a payment note, or a
delivery note.
This data stream has two standardised attributes that allow for In general it is used to encapsulate one or more data streams.
decoding and interpretation of the contents. Its definition is as
follows. This data stream has three standardised attributes that allow for
identification, decoding and interpretation of the contents. Its
definition is as follows.
<!ELEMENT PackagedContent (#PCDATA)> <!ELEMENT PackagedContent (#PCDATA)>
<!ATTLIST PackagedContent <!ATTLIST PackagedContent
Content CDATA "PCDATA" Name NMTOKEN #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" > Transform (NONE|BASE64) "NONE" >
Attributes: Attributes:
Name Optional. Distinguishes between multiple
occurrences of Packaged Content Elements at the
same point in IOTP. For example:
<ABCD>
<PackagedContent Name='FirstMsg'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondMsg'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
The name attribute may be omitted, for example
if there is only one Packaged Content element.
Content This identifies what type of data is contained Content This identifies what type of data is contained
within the Content of the Packaged Content within the Content of the Packaged Content
Element. The valid values for the Content Element. The valid values for the Content
attribute are as follows: attribute are as follows:
o PCDATA.The content of the Packaged Content o PCDATA.The content of the Packaged Content
Element can be treated as PCDATA with no further Element can be treated as PCDATA with no
processing. further processing.
o MIME. The content of the Packaged Content o MIME. The content of the Packaged Content
Element is a complete MIME item. Processing Element is a complete MIME item. Processing
should include looking for MIME headers inside should include looking for MIME headers inside
the Packaged Content Element. the Packaged Content Element.
o MIME:mimetype. The content of the Packaged o MIME:mimetype. The content of the Packaged
Content Element is MIME content, with the Content Element is MIME content, with the
following header "Content-Type: mimetype". following header "Content-Type: mimetype".
Although it is possible to have MIME:mimetype Although it is possible to have MIME:mimetype
with the Transform attribute set to NONE, it is with the Transform attribute set to NONE, it
far more likely to have Transform attribute set is far more likely to have Transform attribute
to BASE64. Note that if Transform is NONE is set to BASE64. Note that if Transform is NONE
used, then the entire content must still conform is used, then the entire content must still
to PCDATA. Some characters will need to be conform to PCDATA. Some characters will need
encoded either as the XML default entities, or to be encoded either as the XML default
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 to Entities and CDATA sections, or Transform set
BASE64, must be used to ensure that the Packaged to BASE64, must be used to ensure that the
Content Element contents are legitimate PCDATA. Packaged Content Element contents are
o x-ddd:usercode. The content is private, where legitimate PCDATA.
ddd represents a domain name of a user, and
usercode represents a particular content format Values of the Content attribute are controlled
defined by that user. The guidelines around a x- under the procedures defined in section 3.7.3
ddd are very loose. Given company FFGGHH Inc., Values for IOTP Codes which also allows user
all of x-www.ffgghh.com, x-ffgghh.comand and defined values to be defined.
x-ffgghh are legitimate examples. However, only
one should be the correct format, as defined by
FFGGHH Inc.
Transform This identifies the transformation that has been 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 of Content Element is the correct representation
the data. Note that entity expansion must occur of the data. Note that entity expansion must
first (i.e. replacement of &amp; and &#9;) occur first (i.e. replacement of &amp; and
before the data is examined. CDATA sections may &#9;) before the data is examined. CDATA
legitimately occur in a Packaged Content Element sections may legitimately occur in a Packaged
where the Transform attribute is set to NONE. Content Element where the Transform attribute
is set to NONE.
o BASE64. The PCDATA content of the Packaged o BASE64. The PCDATA content of the Packaged
Content Element represents a BASE64 encoding of Content Element represents a BASE64 encoding
the actual content. of the actual content.
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 decode The format of the data and rules on how to
it are contained in the Content and the Transform decode it are contained in the Content and the
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
The packaged content may contain HTML. In this case the following
conventions are followed:
o references to any documents, images or other things, such as
sounds or web pages, which can affect the recipient's
understanding of the data which is being packaged must refer to
other Packaged Elements contained within the same parent
element, e.g. an Order Description
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
Packaged Content element to another are realised by setting the
value of the relative reference to the Name attribute of
another Packaged Content element at the same level and within
the same parent element
o no external references that require the reference to be
resolved immediately should be used. As this could make the
HTML difficult or impossible to display completely
o [MIME] is used to encapsulate the data inside each Packaged
Element. This means that the information in the MIME header
used to identify the type of data which has been encapsulated
and therefore how it should be displayed.
If the above conventions are not followed by, for example, including
external references which must be resolved, then the recipient of the
HTML should be informed.
[Note] As an implementation guideline the values of the Name
Attributes allocated to Packaged Content elements should
make it possible to extract each Packaged Content into a
directory and then display the HTML directly
[Note End]
3.9 Identifying Languages 3.9 Identifying Languages
IOTP uses [XML] Language Identification to specify which languages are IOTP uses [XML] Language Identification to specify which languages are
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 Trading
Component which contains attributes or content which may need Component which contains attributes or content which may need
to be displayed or printed in a particular language to be displayed or printed in a particular language
o an optional xml:lang attribute is included on child elements o an optional xml:lang attribute is included on child elements of
of these Trading Components. In this case the value of these Trading Components. In this case the value of xml:lang,
xml:lang, if present, overrides the value for the Trading if present, overrides the value for the Trading Component.
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 6.
3.10 Secure and Insecure Net Locations 3.10 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 o "Secure" Net Locations which are net locations where privacy of
as [SSL], and data is secured using, for example, encryption methods such as
[SSL], and
o "Insecure" Net Locations where privacy of data is not assured. o "Insecure" Net Locations where privacy of data is not assured.
Where both types of net location are present, the following rules Where both types of net location are present, the following rules
apply: apply:
o either a Secure Net Location or an Insecure Net Location or o 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 o if only one of the two Net Locations is present, then the one
present must be used present must be used
o if both are present, then the either may be used depending on o if both are present, then the either may be used depending on
preference the preference of the sender of the message. the preference of the sender of the message.
3.11 Cancelled Transactions
Any Trading Role involved in an IOTP transaction may cancel that
transaction at any time.
3.11.1 Cancelling Transactions
IOTP Transactions are cancelled by sending an IOTP message containing
just a Cancel Block with an appropriate Status Component to the other
Trading Role involved in the Trading Exchange.
[Note] The Cancel Block can be sent asynchronously of any other
IOTP Message. Specifically it can be sent either before
sending or after receiving an IOTP Message from the other
Trading Role
[Note End]
If an IOTP Transaction is cancelled during a Trading Exchange (i.e.
the interval between sending a _request_ block and receiving the
matching _response_ block) then the Cancel Block is sent to the same
location as the next IOTP Message in the Trading Exchange would have
been sent.
If a Consumer cancels a transaction after a Trading Exchange has
completed (i.e. the "response" block for the Trading Exchange has been
received), but before the IOTP Transaction has finished then the
Consumer sends a Cancel Block with an appropriate Status Component to
the net location identified by the SenderNetLocn or
SecureSenderNetLocn contained in the Protocol Options Component
contained in the TPO Block for the transaction. This is normally the
Merchant Trading Role.
A Consumer should not send a Cancel Block after the IOTP Transaction.
Cancelling a complete should be treated as a technical error.
After cancelling the IOTP Transaction, the Consumer should go to the
net location specified by the CancelNetLocn attribute contained in the
Trading Role Element for the organisation that was sent the Cancel
Block.
A non-Consumer Trading Role should only cancel a transaction:
o after a request block has been received and
o before the response block has been sent
If a non-Consumer Trading Role cancels a transaction at any other time
it should be treated by the recipient is an error.
3.11.2 Handling Cancelled Transactions
If a Cancel Block is received by a Consumer at a point in the IOTP
Transaction when cancellation is allowed, then the Consumer should
stop the transaction.
If a Cancel Block is received by a non-Consumer role, then the Trading
Role should anticipate that the Consumer may go to the location
specified by the CancelNetLocn attribute contained in the Trading Role
Element for the Trading Role.
4. IOTP Error Handling 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 a 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 of
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
skipping to change at page 50, line 39 skipping to change at page 73, line 18
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 a 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 of
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 divided
into: into:
- "technical errors" which are independent of the meaning of the - "technical errors" which are independent of the meaning of the
IOTP Message, IOTP Message,
- "business errors" which indicate that there is a problem - "business errors" which indicate that there is a problem specific
specific to the process (payment or delivery) which is being to the process (e.g. payment or delivery) which is being carried
carried out, and 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 at
the transport, message or block/component level 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 the
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 a
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 error
is indicated by an Error Component (see section 6.19) in an Error is indicated by an Error Component (see section 0) in an Error Block
Block (see section 7.19) sent by the party which detected the error in (see section 7.17) sent by the party which detected the error in an
an IOTP message to the party which sent the erroneous message. IOTP message to the party which sent the erroneous message.
If communications too poor, a message which was sent may not reach its If communications are too poor, a message which was sent may not reach
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 Error
Components (see section 6.19) which lists all the different technical Components 6.19) which lists all the different technical errors which
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, an
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.15) of a "response indicated in the Status Component (see section 6.14) of a "response
block" of the normal type, for example a Payment Response Block or a block" of the appropriate type, for example a Payment Response Block
Delivery Response Block. This allows whatever additional response or a Delivery Response Block. This allows whatever additional response
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 can
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 Purchase (see section 8.3.1), the user funds in a Brand Independent Offer (see section 8.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 52, line 41 skipping to change at page 75, line 35
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 the
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 in
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 an
Error Component (see section 6.19) sent to the other party. The Error Error Components (see section 6.19) sent to the other party. The Error
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 which
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 6.19.2 Error Codes) that are Message
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 (see
[XML]) [XML])
skipping to change at page 53, line 7 skipping to change at page 76, line 7
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 which
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 6.19.2 Error Codes) that are Message
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 (see
[XML]) [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 Transaction Reference Block (see section 3.3) and the Signature
Signature Block only. This should only be carried out if the Block only. Checks on these blocks should only be carried out
XML is valid if the XML is valid
Note that checks on the Signature Block includes 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 Digital Signature Element is incorrectly calculated then the data
that should have been covered by the signature can not be trusted and that should have been covered by the signature can not be trusted and
must be treated as erroneous. A description of how to check a must be treated as erroneous. A description of how to check a
signature is correctly calculate is contained in section 5.2 Checking signature is correctly calculated is contained in section 5.2 Checking
a Signature is Correctly Calculated. a Signature is Correctly Calculated.
4.3.3 4Block 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 is
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
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 returned and, unless it is merely a warning, the
usual response block is suppressed. 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
skipping to change at page 53, line 49 skipping to change at page 77, line 12
Error Component is returned and, unless it is merely a warning, the Error Component is returned and, unless it is merely a warning, the
usual response block is suppressed. 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 contained within this IOTP specification o checking that the content of each element conforms to any rules
o if the previous checks are OK, then cross-checking attribute contained within this IOTP specification
values and element content against other attribute values or
element content within any other components in the same block. o if the previous checks are OK, then checking the consistency of
attribute values and element content against other attribute
values or element content within any other components in the
same block.
4.3.3.2 Block and Component Consistency Checks 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 within the blocks within the same IOTP message. o checking for consistency between attributes and element content
within the blocks within the same IOTP message.
o checking for consistency between attributes and elements in o checking for consistency between attributes and elements in
blocks in this IOTP message and blocks received in earlier blocks in this IOTP message and blocks received in earlier IOTP
IOTP messages for the same IOTP transaction messages for the same IOTP transaction
4.3.3.3 Block Business Errors 4.3.3.3 Block 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 usual type of response block is returned. The Delivery, then the appropriate type of response block is returned. The
Status Component (see section 6.15) within that response block Status Component (see section 6.14) within that response block
indicates the error and its severity. No Error Component or Error indicates the error and its severity. No Error Component or Error
Block is generated for business errors. 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 state changing action
skipping to change at page 55, line 14 skipping to change at page 79, line 8
4.4.1 Server Role Processing Sequence 4.4.1 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.
The model processing sequence for a Server role is indicated in the The model processing sequence for a Server role is indicated in the
diagram below. diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
------------- -------------
| Input | | Input |
| OTP Message | | IOTP Message|
------------- -------------
| |
v v
1. Check for transport --------------> 1. Check for transport -------------->
or message level errors Errors | or message level errors Errors |
|OK | |OK |
v | v |
11. Generate output <-------2. More Blocks <------------------ +- 11. Generate output <-------2. More Blocks <----------------- + -
message No to process? | | message No to process? | |
| |Yes | | | |Yes | |
v v | | v v | |
------------- 3. Check Block OK ---------------> | | ------------- 3. Check Block OK ---------------> | |
| Output | | Errors | | | Output | | Errors | |
| OTP Message | |Checks OK | | | IOTP Message| |Checks OK | |
------------- v | | ------------- v | |
----- ---4. Type of Block ? ------- | | ---------4. Type of Block ? ------- | |
| | | | | | | | | | | |
----- ---Status Action Encapsulating Error | | ---------Status Action Encapsulating Error | |
| Request Request Block Block | | | Request Request Block Block | |
| | | | | | | | | | | |
| v v v | | | v v v | |
| 6a. Action 7. Process 8.Error | | | 6a. Action 7. Process 8.Error | |
| Request - encapsulated Block ? | | | Request - encapsulated Block ? | |
| received message and | | | | received message and | | |
| before?-- generate -- v | | | before?-- generate -- v | |
| | | response | STOP ---- | | | | response | STOP --- |
| |Yes |No OK| | | | | |Yes |No OK| | | |
| v v | |Errors v | | v v | |Errors v |
| 6b. Processing 6e. Process Action | ------> 9. Gen | | 6b. Processing 6e. Process Action | ------> 9. Gen |
| of Block Request & generate-+--------->Error | | of Block Request & generate-+--------->Error |
| Complete ?- response block- | Errors Block & | | Complete ?- response block- | Errors Block & |
| | | ^ | | store | | | | ^ | | store |
| | | | | | | | | | | | | | | |
| |Yes |No | Ok or | | | | | |Yes |No | Ok or | | | |
| | --- | Warning | -------- | | | | --- | Warning | -------- | |
v v v | v | | | v v v | v | | |
5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | | 5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | |
Status and resend process request & | | | Status and resend process request & | | |
Response previous completion response | | | Response previous completion response | | |
Block Block block | | | Block Block block | | |
| | | v v | | | | v v |
---------------------------------------------- 10. Add block-- ---------------------------------------------- 10. Add block--
to output to output
message message
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 10 Server Role Processing Sequence Figure 10 Server Role Processing Sequence
Each of the processes in the sequence is described in more detail Each of the processes in the sequence is described in more detail
below. below.
4.4.1.1 Check for Transport or Message Level Error 4.4.1.1 Check for Transport or Message Level Error
On receipt of an IOTP request message (step 1), first check for On receipt of an IOTP request message (step 1), first check for
transport or message level errors (see sections 4.3.1 and 4.3.2). 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 These are errors which indicate that the entire message is corrupt and
skipping to change at page 57, line 9 skipping to change at page 81, line 14
It may be desirable to log the complete response message at the It may be desirable to log the complete response message at the
server. Failure of the requester to receive a response may lead to a server. Failure of the requester to receive a response may lead to a
time-out and a retransmission of the request. Following the procedures time-out and a retransmission of the request. Following the procedures
above, a duplicate request message should produce a duplicate of the above, a duplicate request message should produce a duplicate of the
previous response except for changes in status and transient error previous response except for changes in status and transient error
conditions that have changed. conditions that have changed.
4.4.1.3 Check the Block is OK 4.4.1.3 Check the Block is OK
Check the block is OK (see section 4.3.3). For each block level error Check the block is OK (see section 4.3.3). For each block level
found, an appropriate Error Component should be created to be included technical error found, an appropriate Error Component should be
in the IOTP Message sent back to the Consumer. Note that some checking created to be included in the IOTP Message sent back to the Consumer.
of the Transaction Reference Block and the Signature Block has Note that some checking of the Transaction Reference Block and the
occurred as part of Message Level error checking. Signature Block has occurred as part of Message Level error checking.
If one or more of the Error Components contain a Severity attribute If one or more of the Error Components contain a Severity attribute
with a value of TransientError or HardError, then no response block with a value of TransientError or HardError, then no response block
need be generated and no further processing of the block, including need be generated and no further processing of the block, including
idempotency related actions are necessary. idempotency related actions are necessary.
4.4.1.4 Determine the Type of the Block 4.4.1.4 Determine the Type of the Block
Trading Blocks that survive the above steps and thus have no errors, Trading Blocks that survive the above steps and thus have no errors,
or at worst have added a warning error component to the response, can or at worst have added a warning error component to the response, can
receive further processing. The nature of the processing depends (step receive further processing. The nature of the processing depends (step
4) on whether the block is a Status Request, Action Request, an Error 4) on whether the block is a Status Request, Action Request, an Error
Block or contains an Encapsulated Message. Block or contains an Encapsulated Message.
4.4.1.5 Status Request Blocks 4.4.1.5 Status Request Blocks
Status Request Blocks (step 5) are either: Status Request Blocks (step 5) are either:
o Inquiry Request Trading Block (see section 7.14), or
o Ping Request Block (see section 7.16). o Inquiry Request Trading Block (see section 7.12), or
o Ping Request Block (see section 7.14).
These status requests do not change state and are processed fresh to These status requests do not change state and are processed fresh to
get the current status. The appropriate response block should be added get the current status. The appropriate response block should be added
to the IOTP message being composed. to the IOTP message being composed.
No idempotency actions are required. No idempotency actions are required.
4.4.1.6 Action Request Blocks 4.4.1.6 Action Request Blocks
Blocks which request an action and change state need to be subject to Blocks which request an action and change state need to be subject to
skipping to change at page 59, line 7 skipping to change at page 83, line 14
No IOTP level idempotency actions are required for encapsulating No IOTP level idempotency actions are required for encapsulating
blocks. The payment system must return material to be encapsulated in blocks. The payment system must return material to be encapsulated in
the IOTP response message along with indications as to whether the the IOTP response message along with indications as to whether the
exchange will continue or this is the final response and an indication exchange will continue or this is the final response and an indication
whether an error occurred. If a payment protocol error has occurred, whether an error occurred. If a payment protocol error has occurred,
an Error Component is added to the response block. an Error Component is added to the response block.
4.4.1.8 Error Block Received 4.4.1.8 Error Block Received
An error block (step 8) should not occur in a request and should be An error block (step 8) should not occur in a request block and should
treated as an unexpected element with a Severity of HardError. No be treated as an unexpected element with a Severity of HardError.
response to the block should be made in order to avoid the risk of
loops.
[Note] Consumers should send Error Blocks to a server specified in Error Blocks are sent by Consumers to potentially two locations:
the ErrorNetLocn attribute of the appropriate Trading Role
element as a response to the detection of an error in an o the _request_ location, i.e. the location from which they
IOTP Message that has been received (see section 4.4.1.9 received the IOTP message that contained the error, and
Generate Error Block). This may be the same server as is
used to accept IOTP Messages which contain no error. In this o optionally, the ErrorLogNetLocn which may be a separate
case, the error block must not considered as a fatal error. location maintained for the purpose of logging errors
[Note End]
The ErrorLogNetLocn block may be the same location as the _request_
location. In this case, the error block must not considered as a fatal
error.
In order to avoid loops, no Error Block should be sent to the Consumer
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 4.4.1.9 Generate Error Block
If any of the previous steps resulted in an error being detected and If any of the previous steps resulted in an error being detected and
an Error Component being created then generate an Error Block (step 9) an Error Component being created then generate an Error Block (step 9)
containing the Error Components that describe the error(s). containing the Error Components that describe the error(s).
Unless the error is a "Transient Error", the Error Component(s) and Unless the error is a "Transient Error", the Error Component(s) and
the request block which caused the Error Components to be generated the request block which caused the Error Components to be generated
should be stored so that it can be reused if the action request is should be stored so that it can be reused if the action request is
skipping to change at page 59, line 49 skipping to change at page 85, line 4
received are added to the output message. received are added to the output message.
4.4.2 Client Role Processing Sequence 4.4.2 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 a
purchase or downloading or withdrawing electronic cash. purchase or downloading or withdrawing electronic cash.
[Note End] [Note End]
The model processing sequence for a Client role is indicted in the The model processing sequence for a Client role is indicted in the
diagram below. diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
------------- -------------
| Input | | Input |
| OTP Message | | IOTP Message|
------------- -------------
| |
v v
1. Check for transport --> 1. Check for transport -->
or message level errors |Errors or message level errors |Errors
|OK | |OK |
v | v |
11.Blocks to be sent?<---------2. More Blocks <-- -------------------- 11.Blocks to be sent?<---------2. More Blocks <-- ------------------
| |No No to process? | ^ | |No No to process? | ^
Yes| v |Yes | | Yes| v |Yes | |
v STOP v | | v STOP v | |
12. Generate 3. Check Block OK - -->| | 12. Generate 3. Check Block OK - -->| |
output message | |Errors | output message | |Errors |
| |Checks OK | | | |Checks OK | |
v v | | v v | |
------------- ------ 4. Type of Block ? -----| | ------------- ------ 4. Type of Block ? -----| |
| Output | | | | | | | | Output | | | | | | |
| OTP Message | | ---- | | | | | IOTP Message| | ---- | | | |
------------- | | | | | | ------------- | | | | | |
------------ | | | | | ------------ | | | | |
| -- | | | | | -- | | | |
v v v v | | v v v v | |
Status Action Encapsulating Error | | Status Action Encapsulating Error | |
Request Response Block Block | | Request Response Block Block | |
| | | | | | | | | | | |
| v v v | | | v v v | |
| 6a. Action 7. Process 8a.Error Block---- > Transient | | 6a. Action 7. Process 8a.Error Block---- > Transient |
| Response encapsulated severity ? | Error | | Response encapsulated severity ? | Error |
| received message |Hard Error | (retry) | | received message |Hard Error | (retry) |
| before ? | | | | | | | before ? | | | | | |
| Yes| |No Ok| | v | WAIT | | Yes| |No Ok| | v | WAIT |
| (Ig-| | | | STOP | | | | (Ig-| | | | STOP | | |
| nore|) v | | v v | | nore|) v | | v v |
| | 6b. Process | ----- -> 9. Generate 8b. | | | 6b. Process | -------> 9. Generate 8b. |
| | Action | Errors Error Block Retrieve | | | Action | Errors Error Block Retrieve |
| | Response---+-------- --> & store and resend | | | Response --+----------> & store and resend |
| | Block | Errors | previous | | | Block | Errors | previous |
| | |Ok | | Block(s) | | | |Ok | | Block(s) |
| | v v | | | | | v v | | |
| | 6c. New | | | | | 6c. New | | |
| | request | | | | | request | | |
| | required ? | | | | | required ? | | |
| | No| |Yes 6d. Generate | | | | | No| |Yes 6d. Generate | | |
| | | ---- > Request | | | | | | ---- > Request | | |
| | | Block & Store v v | | | | Block & Store v v |
v | | | 10. Add Block to | v | | | 10. Add Block to |
----------+-------+-------------------------> output message | ----------+-------+------------------------> output message |
v v | v v |
--------------------------------------------------> --------------------------------------------------->
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 11 Client Role Processing Sequence Figure 11 Client Role Processing Sequence
Each of the processes in the sequence is described in more detail Each of the processes in the sequence is described in more detail below.
below.
4.4.2.1 Check for Transport or Message Level Error 4.4.2.1 Check for Transport or Message Level Error
On receipt of an IOTP response message (step 1), first check for On receipt of an IOTP response message (step 1), first check for
transport or message level errors (see sections 4.3.1 and 4.3.2). 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 These are errors which indicate that the entire message is corrupt and
can not reliably be associated with any particular transaction or, if can not reliably be associated with any particular transaction or, if
it can be associated with a transaction, the interior information in it can be associated with a transaction, the interior information in
the message can not be reliably accessed. Set up an error indication the message can not be reliably accessed. Set up an error indication
message with an Error Component indicating the error. message with an Error Component indicating the error.
If the value of the OtpTransId attribute is not recognised as If the value of the OtpTransId attribute is not recognised as
belonging to an IOTP transaction when other Blocks in the IOTP Message belonging to an IOTP transaction when other Blocks in the IOTP Message
indicate that it should be recognised, then report the error using an indicate that it should be recognised, then report the error using an
Error Component with a Severity of HardError, an ErrorCode set to Error Component with a Severity of HardError, an ErrorCode set to
AttValNotRecog (attribute value not recognised), and an Error Location AttValNotRecog (attribute value not recognised), and an Error Location
element (see section 6.19.3) that points to the OtpTransId attribute. element (see section 6.19.3) that points to the OtpTransId attribute.
On failure to receive an expected response message, the time out On failure to receive an expected response message, the time out
strategy indicated in the documentation for the transport method being strategy indicated in the documentation for the transport method being
used should be followed. This may include some number of automatic used should be followed. This may include some number of automatic re-
retransmissions of the request. If a user is present, they may be transmissions of the request. If a user is present, they may be
offered options of continuing to retransmit the request or of offered options of continuing to retransmit the request or of
cancelling the transaction. cancelling the transaction.
4.4.2.2 Process all the blocks 4.4.2.2 Process all the blocks
If there are no message level errors, process each of the blocks If there are no transport or message level errors, process each of the
within the message which has not been processed (step 2). 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 Once all the blocks have been processed, check to see if there are any
blocks to be sent (step 11). There may be no blocks to send if the blocks to be sent (step 11). There may be no blocks to send if the
last response message received was the last message of the last response message received was the last message of the
transaction. transaction.
If blocks are to be sent then generate a request message (step 12) and If blocks are to be sent then generate a request message (step 12) and
send it to the server. It may be desirable to log the complete request send it to the server. It may be desirable to log the complete request
message at the client. Failure of the server to receive a response may message at the client. Failure of the server to receive a response may
lead to a time-out and a retransmission of the request. lead to a time-out and a retransmission of the request.
skipping to change at page 62, line 30 skipping to change at page 87, line 40
Trading Blocks that survive the above steps and thus have no errors, Trading Blocks that survive the above steps and thus have no errors,
or at worst have added a warning error component to the error or at worst have added a warning error component to the error
indication message, can receive further processing. The nature of the indication message, can receive further processing. The nature of the
processing depends (step 4) on whether the block is a Status Response, processing depends (step 4) on whether the block is a Status Response,
Action Response, an Error Block or contains an Encapsulated Message. Action Response, an Error Block or contains an Encapsulated Message.
4.4.2.5 Status Response Blocks 4.4.2.5 Status Response Blocks
Status Response Blocks (step 4) are either: Status Response Blocks (step 4) are either:
o Inquiry Response Trading Blocks (see section 7.15), or
o Ping Response Blocks (see section 7.17) o Inquiry Response Trading Blocks (see section 7.13), or
o Ping Response Blocks (see section 7.15)
In general, such blocks should be considered a status update. The best In general, such blocks should be considered a status update. The best
action to take at the requester may depend on whether this is in action to take at the requester may depend on whether this is in
response to a user originated or automatic status request, whether a response to a user originated or automatic status request, whether a
status display that could be updated is being presented to the user, 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 and whether the status response block shows a change in status from a
previous response block for the same type of status. Thus client previous response block for the same type of status. Thus client
detection of duplication in successive status response blocks may be detection of duplication in successive status response blocks may be
useful. useful.
skipping to change at page 63, line 5 skipping to change at page 88, line 18
Check to determine if the Block has been received previously (step Check to determine if the Block has been received previously (step
6a). If it has then it should be ignored. 6a). If it has then it should be ignored.
These indicate an action taken at the server in response to an action These indicate an action taken at the server in response to an action
request block or a business error. If the response indicates success request block or a business error. If the response indicates success
the block should be processed (step 6b) and, if required by the the block should be processed (step 6b) and, if required by the
transaction (step 6c) , another Action Request Block generated and transaction (step 6c) , another Action Request Block generated and
stored (step 6d). stored (step 6d).
The Response Block should always be stored with the transaction id and The Response Block should always be stored with the transaction id
until the transaction is terminated. If the Response Block indicates a until the transaction is terminated. If the Response Block indicates a
transient business error, appropriate manually chosen or automatic transient business error, appropriate manually chosen or automatic
steps to fix the problem or cancel the transaction should be provided. steps to fix the problem or cancel the transaction should be provided.
4.4.2.7 Encapsulating Blocks 4.4.2.7 Encapsulating Blocks
Blocks which encapsulate a payment protocol (step 7) pass along the Blocks which encapsulate a payment protocol (step 7) pass along the
enclosed information to the payment system involved. enclosed information to the payment system involved.
IOTP does not know the meaning of the enclosed information. It is up IOTP does not know the meaning of the enclosed information. It is up
skipping to change at page 63, line 45 skipping to change at page 89, line 11
Transient errors may be used to provide a manual or automatic Transient errors may be used to provide a manual or automatic
resending (step 8b) of a block previously stored or alternatively may resending (step 8b) of a block previously stored or alternatively may
result in transaction cancellation. Hard errors will always terminate result in transaction cancellation. Hard errors will always terminate
the transaction, unless they are in optional blocks, with appropriate the transaction, unless they are in optional blocks, with appropriate
indication to he user. indication to he user.
4.4.2.9 Generate Error Block 4.4.2.9 Generate Error Block
If an error indication message was created above, try to send it to If an error indication message was created above, try to send it to
the server unless all of the error components are of the warning the unless all of the error components are of the warning severity in
severity in which case attempted transmission to the server is which case attempted transmission to the server is optional.
optional.
[Note] To avoid error message loops, such an error indication from The net locations consumers send Error Blocks to are:
a requester must be sent to the Error Net Location specified
in the Trading Role Element (see section 6.5.2) for the o the net location which sent them the IOTP Message which was in
Organisation that is the server. Any errors encountered in error, this is either:
sending such an error indication should be, at most, logged - the location specified by the SenderNetLocn or SecureSenderNetLocn
and must not result in any further attempts to transmit any attribute of the Protocol Options Component if the problem was
error indication. contained in the TPO Block or the Offer Response Block
[Note End] - 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
attribute of the Trading Role element identified by the
SenderTradingRoleRef the Message Id Component.
4.4.2.10 Add Block to Output Message 4.4.2.10 Add Block to Output Message
Any Blocks which have been created as a result of processing the block Any Blocks which have been created as a result of processing the block
received are added to the output message. received are added to the output message.
5. Security Considerations 5. Security Considerations
This section considers the security associated with IOTP. It covers: This section considers the security associated with IOTP. It covers:
o an overview of how IOTP uses digital signatures o an overview of how IOTP uses digital signatures
o how to check a signature is correctly calculated o how to check a signature is correctly calculated
o how Payment Handlers and Delivery Handlers check they can
carry out payments or deliveries on behalf of a Merchant. o how Payment Handlers and Delivery Handlers check they can carry
out payments or deliveries on behalf of a Merchant.
o how IOTP handles data integrity and privacy o how IOTP handles data integrity and privacy
5.1 Digital Signatures and IOTP 5.1 Digital Signatures and IOTP
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 a IOTP Components (see section 6)
o hash one or more IOTP Components or Trading Blocks, possibly
including other Signature Components, in any IOTP message o contain digests of one or more IOTP Components or Trading
within the same IOTP Transaction Blocks, possibly including other Signature Components, in any
IOTP message within the same IOTP Transaction
o identify: o identify:
- which Organisation signed (generated) the signature, and - which Organisation signed (originated) the signature, and
- which Organisation(s) should verify the signature in order to - which Organisation(s) should be the receive the signature in order
check that the Action the Organisation should take can occur. to check that the Action the Organisation should take can occur.
The way in which Signatures Components hash 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.
OTP MESSAGE SIGNATURE COMPONENT *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
OTP MESSAGE OtpSignature Id = P1.3 IOTP MESSAGE SIGNATURE COMPONENT
|-Trans Ref Block hash TransRefBlk |-SignedData
| | ID=P1.1-------- ---------------------|->|-Hash of P1.1--- IOTP MESSAGE Signature Id = P1.3
| |-Trans Id Comp hash TransIdComp | | | |-Trans Ref Block digest TransRefBlk |-Manifest
| | ID = M1.2------- ---------------------|->|-Hash of M1.2---| | | ID=P1.1-----------------------------|->|-Digest of P1.1--
| |-Msg Id Comp. hash element | | | | |-Trans Id Comp digest TransIdComp | | |
| | ID = P1 -------------------|->|-Hash of M1.5---| | | ID = M1.2----------------------------|->|-Digest of M1.2--|
| | hash element | | | | |-Msg Id Comp. digest Signature | | |
|-Signature Block | -----------------|->|-Hash of M1.7---| | | ID = P1 -------------------|->|-Digest of M1.5--|
| | ID=P1.2 | | hash element | | | | | digest element | | |
| |-Sig Comp. ID=P1.3 | | ---------------|->|-Hash of C1.4---| |-IOTPSignatures Block | -----------------|->|-Digest of M1.7--|
| |-Sig Comp. ID=M1.5--- - | | | | | | ID=P1.2 | | digest element | | |
| |-Cert Comp. ID=P1.4 | | CertRef Iden- -DigSig | | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--|
| |-Cert Comp. ID=M1.6<- ---|-|---------------------CertRef=M1.6 | | |-Signature ID=M1.5---- | | | |
| | | | tifies Certs Content: | | |-Signature ID=P1.4 | | Points to |-RecipientInfo* |
|-Trading Block. ID=P1.5 | | to use JtvwpMdmSfMbhK<- | |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6 |
| |-Comp. ID=M1.7------- --- | r1Ln3vovbMQttbBI | | | | Certs to use | SignatureValueRef|
| | | J8pxLjoSRfe1o6k | | | | | Points|to Value El|
| |-Comp. ID=P1.6 | OGG7nTFzTi+/0<-- | | | | | v |
| | | | |-Trading Block. ID=P1.5 | | -Value* ID=P1.4: |
| |-Comp. ID=C1.4------- ----- Digital signature of- | |-Comp. ID=M1.7---------- | JtvwpMdmSfMbhK<--|
| |-Comp. ID=C1.5 SignedData element | | | r1Ln3vovbMQttbBI |
| |-Comp. ID=P1.6 | J8pxLjoSRfe1o6k|
| | | OGG7nTFzTi+/0<-
| |-Comp. ID=C1.4------------
| |-Comp. ID=C1.5 Digital signature of-
SignedData element
using certificate using certificate
identified by CertRef identified by CertRef
Elements signed can be in any OTP Message
within the same OTP Transaction
Figure 12 Signature Hashing Elements that are digested can be in any IOTP Message
within the same IOTP Transaction
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 12 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]
The detailed definitions of how signatures are created is contained in Note that one Manifest may be associated with multiple signature
the paper "Digital Signature for XML - Proposal", see [XMLSIG]. That "Value" elements where each Value element contains a digital signature
document should be read in conjunction with this section. over the same manifest, perhaps using the same (or different)
signature algorithm but using a different certificate
This may be used to allow each potential recipient of a signature to
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
section 6.17.
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 SignerOrgRef and VerifierOrgRef attributes 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 signatures may use either Symmetric or Asymmetric
Cryptography Cryptography
o Mandatory and Optional use of Signatures by IOTP, and o Mandatory and Optional use of Signatures by IOTP, and
o how IOTP uses signatures to prove actions complete
successfully o how IOTP uses signatures to prove actions complete successfully
5.1.1 IOTP Signature Example 5.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 5.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<--- Signer Signature Brand Selection Organisation<--- Signature
Component Component | OrgRef Component Component Component | Component
| | ----------(Offer | | | |
|BrandList -Trading Role Response) |BrandList -Trading Role | |
| Ref Element | | Ref Element | Originator |-Originator
v (Merchant) | v (Merchant) ------------|--Info
Brand List | Brand List Ref |
>Component | >Component |
| |-Protocol ------> Organisation<-------------- |-Dig Sig | |-Protocol ------> Organisation Recipient |-Recipient
| | Amount Elem | Component Verifier | | Element | | Amount Elem | Component <------------------|--Info
| | | | | OrgRef -|-(Payment | | | | | Refs |
| | Pa|Protocol |Action -Trading Role | Handler) | | Pa|Protocol |Action -Trading Role |
| | | Ref |OrgRef Element | | | | Ref |OrgRef Element |
| | v | (Payment Handler) | | | v | (Payment Handler) |
| -PayProtocol-- | | -PayProtocol-- |
| Elem ->Organisation<------------- |-Dig Sig | Elem ->Organisation Recipient |-Recipient
| | Component Verifier | | Element | | Component <-----------------|--Info
| | | OrgRef -|-(Delivery | | | Refs |
| | -Trading Role | Handler) | | -Trading Role |
| | Element | | | Element |
| | (Delivery Handler) -SignedData | | (Delivery Handler) -Manifest
| | Element ^ | | ^
| OFFER RESPONSE BLOCK | | OFFER RESPONSE BLOCK |
| | Contains hashes of:----- | | Contains digests of:--
|BrandListRef |ActionOrgRef -Trans Ref Block (not |BrandListRef |ActionOrgRef -Trans Ref Block (not
| | shown) | | shown)
--Payment ---Delivery -Transaction Id Component --Payment ---Delivery -Transaction Id Component
Component Component (not shown) Component Component (not shown)
-Org Components (Merchant, -Org Components (Merchant,
Payment Handler, Payment Handler,
Delivery Handler Delivery Handler
-Brand List Component -Brand List Component
-Order Component -Order Component
-Payment Component -Payment Component
-Delivery Component -Delivery Component
-Brand Selection Component -Brand Selection Component
(if Brand Dependent) (if Brand Dependent)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 13 Example use of Signatures for Baseline Purchase Figure 13 Example use of Signatures for Baseline Purchase
5.1.2 OriginatorInfo and RecipientInfo Elements
5.1.2 SignerOrgRef and VerifierOrgRef Attributes The OriginatorRef attribute of the OriginatorInfo element in the
Signature Component contains an Element Reference (see section 3.5)
The SignerOrgRef attribute on the Signature Component contains an that points to the Organisation Component of the Organisation which
Element Reference (see section 3.5) that points to the Organisation generated the Signature. In this example its the Merchant.
Component of the Organisation which generated the Signature. In this
example its the Merchant.
Note that the type of the Signature Component must match the Trading Note that the value of the content of the Attribute element with a
Role of the Organisation which signed it. If it does not, then it is type attribute set to IOTPSignatureType must match the Trading Role of
an error. Valid combinations are given in the table below. the Organisation which signed it. If it does not, then it is an error.
Valid combinations are given in the table below.
Signature Valid IOTP Signature Type Valid Trading Role
Component Trading
Type Role
OfferResponse Merchant OfferResponse Merchant
PaymentResponse PaymentHandler PaymentResponse PaymentHandler
The VerifierOrgRef attribute on the DigSig elements, contains Element DeliveryResponse DeliveryHandler
References to the Organisation Components of the Organisations that
should use the signature to verify that: AuthenticationRequest any role
AuthenticationResponse any role
PingRequest any role
PingResponse any role
The RecipientRef attribute of the RecipientInfo element in the
Signature Component contains Element References to the Organisation
Components of the Organisations that should use the signature to
verify that:
o they have a pre-existing relationship with the Organisation 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 5.1.3 Symmetric and Asymmetric Cryptography
The Signer of an Action and a Verifier of an Action may have agreed to The Originator and Recipient of a signature may have agreed to use
use cryptography which is understood only by the two organisations cryptography which is understood only by the two organisations
involved. This requires that a separate Digital Signature Element for involved. This requires that a separate RecipientInfo and Value
use by the verifier is contained within the Signature Component. This elements are contained within the Signature Component. This approach
approach is more likely if symmetric cryptography is being used is more likely if symmetric cryptography is being used between the
between the Trading Roles. Trading Roles.
Equally the same cryptography may be understood by several or all of Equally the same cryptography may be understood by several or all of
the Trading Roles. In this case one Digital Signature Element may the Trading Roles. In this case the RecpientRefs attribute of one
refer to multiple Verifiers of an Action. This is more likely if RecipientInfo element may refer to multiple Organisation Components.
public key/asymmetric cryptography is being used. This is more likely if public key/asymmetric cryptography is being
used.
Note that one transaction may involve use of both symmetric and Note that one transaction may involve use of both symmetric and
asymmetric cryptography. asymmetric cryptography.
5.1.4 Mandatory and Optional Signatures 5.1.4 Mandatory and Optional Signatures
IOTP does not mandate the use of signatures. For example, if a micro 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 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 required to generate the signature may be greater than the income
generated from the payment. Therefore it is up to the Merchant to generated from the payment. Therefore it is up to the Merchant to
skipping to change at page 68, line 19 skipping to change at page 95, line 46
the Trading Roles may be included, for example, to identify a Customer the Trading Roles may be included, for example, to identify a Customer
Care Provider or so that a Merchant can sign an Offer using a Care Provider or so that a Merchant can sign an Offer using a
certificate issued by a Certificate Authority which offers Merchant certificate issued by a Certificate Authority which offers Merchant
"Credentials" or some other warranty on the goods or services being "Credentials" or some other warranty on the goods or services being
offered. offered.
5.1.5 Using signatures to Prove Actions Complete Successfully 5.1.5 Using signatures to Prove Actions Complete Successfully
Proving an action completed successfully, is achieved by signing data Proving an action completed successfully, is achieved by signing data
on Response messages. Specifically: on Response messages. Specifically:
o on the Offer Response, when a Merchant is making an Offer to o on the Offer Response, when a Merchant is making an Offer to
the Consumer which can then be sent to either: the Consumer which can then be sent to either:
- a Payment Handler to prove that payment is authorised, or
- a Delivery Handler to prove that Delivery is authorised - a Payment Handler to prove that the Merchant authorises Payment,
o on the Payment Response, when a Payment Handler is generating or
a Payment Receipt which can be sent to either: - a Delivery Handler to prove that Merchant authorises Delivery,
- a Delivery Handler, in a Delivery Request Block to prove that provided other necessary authorisations are complete (see below)
delivery is authorised, or
- another Payment Handler, in a second Payment Request, to prove o on the Payment Response, when a Payment Handler is generating a
that the second payment in a Value Exchange IOTP Transaction is Payment Receipt which can be sent to either:
authorised. - a Delivery Handler, in a Delivery Request Block to authorise
Delivery together with the Offer Response signature, or
- another Payment Handler, in a second Payment Request, to authorise
the second payment in a Value Exchange IOTP Transaction.
This proof of an action may, in future versions of IOTP, also be used This proof of an action may, in future versions of IOTP, also be used
to prove after the event that the IOTP transaction occurred. For to prove after the event that the IOTP transaction occurred. For
example to a Customer Care Provider. example to a Customer Care Provider.
5.2 Checking a Signature is Correctly Calculated 5.2 Checking a Signature is Correctly Calculated
Checking a signature is correctly calculated is part of checking for Checking a signature is correctly calculated is part of checking for
Message Level Errors (see section 4.3.2). It is included here so that Message Level Errors (see section 4.3.2). It is included here so that
all signature and security related considerations are kept together. all signature and security related considerations are kept together.
Before a Trading Role can check a signature it must identify which of Before a Trading Role can check a signature it must identify which of
the potentially multiple digital signature elements should be checked. the potentially multiple Signature elements should be checked. The
The steps involved are as follows: steps involved are as follows:
o check that a Signature Block is present and it contains one or o check that a Signature Block is present and it contains one or
more Signature Components more Signature Components
o identify the Organisation Component which contains an OrgId o identify the Organisation Component which contains an OrgId
attribute for the Organisation which is carrying out the attribute for the Organisation which is carrying out the
signature check. If no or more than one Organisation Component signature check. If no or more than one Organisation Component
is found then it is an error is found then it is an error
o use the ID attribute of the Organisation Component to identify
the Digital Signatures Elements which the Trading Role should
verify. Note there may be no signatures for a Trading Role to
verify.
o verify the Signature Components that contain the Digital o use the ID attribute of the Organisation Component to find the
Signature Elements as follows: RecipientInfo element that contains a RecipientRefs attribute
- check that the Digital Signature Element correctly signs the that refers to that Organisation Component. Note there may be
Signed Data Element no signatures to verify
- check that the Hash Elements in the Signed Data Element are
correctly calculated where Components or Blocks that are hashed o check the Signature Component that contains the identified
have been received by the organisation checking the signature RecipientInfo element as follows as follows:
- use the SignatureValueRef, the SignatureAlgoritmRef and the
SignatureCertRef attributes to identify: respectively, the Value
element that contains the signature to be checked, the Algorithm
element that describes the signature algorithm to be used to
verify the Signature and the Certificate to be used by the
signature algorithm, then
- check that the Value Element correctly signs the Manifest Element
- check that the Digest Elements in the Manifest Element are
correctly calculated where Components or Blocks referenced by the
Digest have been received by the organisation checking the
signature
5.3 Checking a Payment or Delivery can occur 5.3 Checking a Payment or Delivery can occur
This section describes the processes required for a Payment Handler or This section describes the processes required for a Payment Handler or
Delivery Handler to check that a payment or delivery can occur. This Delivery Handler to check that a payment or delivery can occur. This
may include checking signatures if this is specified by the Merchant. may include checking signatures if this is specified by the Merchant.
In outline the steps are: In outline the steps are:
o check that the Payment Request or Delivery Request has been o check that the Payment Request or Delivery Request has been
sent to the correct organisation sent to the correct organisation
o check that correct IOTP components are present in the request, o check that correct IOTP components are present in the request,
and and
o check that the payment or delivery is authorised o check that the payment or delivery is authorised
For clarity and brevity the following terms or phrases are used in For clarity and brevity the following terms or phrases are used in
this section: this section:
o a "Request Block" is used to refer to either a Payment Request o a "Request Block" is used to refer to either a Payment Request
Block (see section 7.6) or a Delivery Request Block (see Block (see section 7.7) or a Delivery Request Block (see
section 7.9) unless specified to the contrary section 7.10) unless specified to the contrary
o a "Response Block" is used to refer to either a Payment o a "Response Block" is used to refer to either a Payment
Response Block (see section 7.8) or a Delivery Response Block Response Block (see section 7.9) or a Delivery Response Block
(see section 7.10) (see section 7.11)
o an "Action" is used to refer to an action which occurs on o an "Action" is used to refer to an action which occurs on
receipt of a Request Block. Actions can be either a Payment or receipt of a Request Block. Actions can be either a Payment or
a Delivery a Delivery
o an "Action Organisation", is used to refer to the Payment o an "Action Organisation", is used to refer to the Payment
Handler or Delivery Handler that carries out an Action Handler or Delivery Handler that carries out an Action
o a "Signer of an Action", is used to refer to the Organisations o a "Signer of an Action", is used to refer to the Organisations
that sign data about an Action to authorise the Action, either that sign data about an Action to authorise the Action, either
in whole or in part in whole or in part
o a "Verifier of an Action", is used to refer to the o a "Verifier of an Action", is used to refer to the
Organisations that verify data to determine if they are Organisations that verify data to determine if they are
authorised to carry out the Action authorised to carry out the Action
o an ActionOrgRef attribute contains Element References which
can be used to identify the "Action Organisation" that should
carry out an Action
o an ActionOrgRef attribute contains Element References which can
be used to identify the "Action Organisation" that should carry
out an Action
5.3.1 Check the Action Request was sent to the Correct Organisation 5.3.1 Check the Action Request was sent to the Correct Organisation
Checking the Action Request was sent to the correct Organisation Checking the Action Request was sent to the correct Organisation
varies depending on whether the Action is a Payment or a Delivery. varies depending on whether the Action is a Payment or a Delivery.
5.3.1.1 Payment 5.3.1.1 Payment
In outline a Payment Handler checks if it can accept or make a payment In outline a Payment Handler checks if it can accept or make a payment
by identifying the Payment Component in the Payment Request Block it by identifying the Payment Component in the Payment Request Block it
has received, then using the ID of the Payment Component to track has received, then using the ID of the Payment Component to track
through the Brand List and Brand Selection Components to identify the through the Brand List and Brand Selection Components to identify the
Organisation selected by the Consumer and then checking that this Organisation selected by the Consumer and then checking that this
organisation is itself. organisation is itself.
The way data is accessed to do this is illustrated in the figure The way data is accessed to do this is illustrated in the figure
below. below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
Start Start
| |
v v
Brand List<--------------------------+-----------Payment Brand List<--------------------------+-----------Payment
Component BrandListRef | Component Component BrandListRef | Component
| | | |
|-Brand<-------------------------- | |-Brand<-------------------------- |
| Element BrandRef | | | Element BrandRef | |
| | Brand Selection | | Brand Selection
| |Protocol Component | |Protocol Component
skipping to change at page 70, line 46 skipping to change at page 100, line 5
| Element<---------|---------------- | Element<---------|----------------
| | | |
-PayProtocol<----- -PayProtocol<-----
Element---------------------->Organisation Element---------------------->Organisation
Action Component Action Component
OrgRef | OrgRef |
-Trading Role -Trading Role
Element Element
(Payment Handler) (Payment Handler)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 14 Checking a Payment Handler can carry out a Payment
Figure 14 Checking a Payment Handler can carry out a Payment Figure 14 Checking a Payment Handler can carry out a Payment
The following describes the steps involved and the checks which need The following describes the steps involved and the checks which need
to be made: to be made:
1)
Identify the Payment Component (see section 6.8) in the 1) Identify the Payment Component (see section 6.8) in the Payment
Payment Request Block that was received. Request Block that was received.
2)
Identify the Brand List and Brand Selection Components for the 2) Identify the Brand List and Brand Selection Components for the
Payment Component. This involves: Payment Component. This involves:
a)
identifying the Brand List Component (see section 6.6) a) identifying the Brand List Component (see section 6.6) where
where the value of its ID attribute matches the the value of its ID attribute matches the BrandListRef
BrandListRef attribute of the Payment Component. If no or attribute of the Payment Component. If no or more than one
more than one Brand List Component is found there is an Brand List Component is found there is an error.
error.
b) b) identifying the Brand Selection Component (see section 6.7)
identifying the Brand Selection Component (see section 6.7)
where the value of its BrandListRef attribute matches the where the value of its BrandListRef attribute matches the
BrandListRef of the Payment Component. If no or more than BrandListRef of the Payment Component. If no or more than one
one matching Brand Selection Component is found there is an matching Brand Selection Component is found there is an
error. error.
3)
Identify the Brand, Protocol Amount, Pay Protocol and Currency 3) Identify the Brand, Protocol Amount, Pay Protocol and Currency
Amount elements within the Brand List that have been selected Amount elements within the Brand List that have been selected by
by the Consumer as follows: the Consumer as follows:
a)
the Brand Element (see section 6.6.1) selected is the a) the Brand Element (see section 6.6.1) selected is the element
element where the value of its Id attribute matches the where the value of its Id attribute matches the value of the
value of the BrandRef attribute in the Brand Selection. If BrandRef attribute in the Brand Selection. If no or more than
no or more than one matching Brand Element is found then one matching Brand Element is found then there is an error.
there is an error.
b) b) the Protocol Amount Element (see section 6.6.2) selected is
the Protocol Amount Element (see section 6.6.2) selected is
the element where the value of its Id attribute matches the the element where the value of its Id attribute matches the
value of the ProtocolAmountRef attribute in the Brand value of the ProtocolAmountRef attribute in the Brand
Selection Component. If no or more than one matching Selection Component. If no or more than one matching Protocol
Protocol Amount Element is found there is an error Amount Element is found there is an error
c)
the Pay Protocol Element (see section 6.6.4) selected is c) the Pay Protocol Element (see section 6.6.4) selected is the
the element where the value of its Id attribute matches the element where the value of its Id attribute matches the value
value of the PayProtocolRef attribute in the identified of the PayProtocolRef attribute in the identified Protocol
Protocol Amount Element. If no or more than one matching Amount Element. If no or more than one matching Pay Protocol
Pay Protocol Element is found there is an error Element is found there is an error
d) d) the Currency Amount Element (see section 6.6.3) selected is
the Currency Amount Element (see section 6.6.3) selected is
the element where the value of its Id attribute matches the the element where the value of its Id attribute matches the
value of the CurrencyAmountRef attribute in the Brand value of the CurrencyAmountRef attribute in the Brand
Selection Component. If no or more than one matching Selection Component. If no or more than one matching Currency
Currency Amount element is found there is an error Amount element is found there is an error
4)
Check the consistency of the references in the Brand List and 4) Check the consistency of the references in the Brand List and
Brand Selection Components: Brand Selection Components:
a)
check that an Element Reference exists in the a) check that an Element Reference exists in the
ProtocolAmountRefs attribute of the identified Brand ProtocolAmountRefs attribute of the identified Brand Element
Element that matches the Id attribute of the identified that matches the Id attribute of the identified Protocol
Protocol Amount Element. If no or more than one matching Amount Element. If no or more than one matching Element
Element Reference can be found there is an error Reference can be found there is an error
b)
check that the CurrencyAmountRefs attribute of the b) check that the CurrencyAmountRefs attribute of the identified
identified Protocol Amount element contains an element Protocol Amount element contains an element reference that
reference that matches the Id attribute of the identified matches the Id attribute of the identified Currency Amount
Currency Amount element. If no or more than one matching element. If no or more than one matching Element Reference is
Element Reference is found there is an error. found there is an error.
c)
check the consistency of the elements in the Brand List. c) check the consistency of the elements in the Brand List.
Specifically, the selected Brand, Protocol Amount, Pay Specifically, the selected Brand, Protocol Amount, Pay
Protocol and Currency Amount Elements are all child Protocol and Currency Amount Elements are all child elements
elements of the identified Brand List Component. If they of the identified Brand List Component. If they are not there
are not there is an error. is an error.
5)
Check that the Payment Handler that received the Payment 5) Check that the Payment Handler that received the Payment Request
Request Block is the Payment Handler selected by the Consumer. Block is the Payment Handler selected by the Consumer. This
This involves: involves:
a)
identifying the Organisation Component for the Payment a) identifying the Organisation Component for the Payment
Handler. This is the Organisation Component where its ID Handler. This is the Organisation Component where its ID
attribute matches the ActionOrgRef attribute in the attribute matches the ActionOrgRef attribute in the
identified Pay Protocol Element. If no or more than one identified Pay Protocol Element. If no or more than one
matching Organisation Component is found there is an error matching Organisation Component is found there is an error
b)
checking the Organisation Component has a Trading Role b) checking the Organisation Component has a Trading Role
Element with a Role attribute of PaymentHandler. If not Element with a Role attribute of PaymentHandler. If not there
there is an error is an error
c)
finally, if the identified Organisation Component is not c) finally, if the identified Organisation Component is not the
the same as the organisation that received the Payment same as the organisation that received the Payment Request
Request Block, then there is an error. Block, then there is an error.
5.3.1.2 Delivery 5.3.1.2 Delivery
The way data is accessed by a Delivery Handler in order to check that The way data is accessed by a Delivery Handler in order to check that
it may carry out a delivery is illustrated in the figure below. it may carry out a delivery is illustrated in the figure below.
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*
Start Start
| |
v v
Delivery Delivery
Component Component
| |
|ActionOrgRef |ActionOrgRef
| |
v v
Organisation Organisation
Component Component
| |
-Trading Role -Trading Role
Element Element
(Delivery Handler) (Delivery Handler)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 15 Checking a Delivery Handler can carry out a Delivery Figure 15 Checking a Delivery Handler can carry out a Delivery
The steps involved are as follows: The steps involved are as follows:
1.
Identify the Delivery Component in the Delivery Request Block. 1) Identify the Delivery Component in the Delivery Request Block.
If there is no or more than one matching Delivery Component If there is no or more than one matching Delivery Component
there is an error there is an error
2.
Use the ActionOrgRef attribute of the Delivery Component to 2) Use the ActionOrgRef attribute of the Delivery Component to
identify the Organisation Component of the Delivery Handler. identify the Organisation Component of the Delivery Handler. If
If there is no or more than one matching Organisation there is no or more than one matching Organisation Component
Component there is an error there is an error
3.
If the Organisation Component for the Delivery Handler does 3) If the Organisation Component for the Delivery Handler does not
not have a Trading Role Element with a Role attribute of have a Trading Role Element with a Role attribute of
DeliveryHandler there is an error DeliveryHandler there is an error
4.
Finally, if the organisation that received the Delivery 4) Finally, if the organisation that received the Delivery Request
Request Block does not identify the Organisation Component for Block does not identify the Organisation Component for the
the Delivery Handler as itself, then there is an error. Delivery Handler as itself, then there is an error.
5.3.2 Check the Correct Components are present in the Request Block 5.3.2 Check the Correct Components are present in the Request Block
Check that the correct components are present in the Payment Request Check that the correct components are present in the Payment Request
Block (see section 7.6) or in the Delivery Request Block (see section Block (see section 7.7) or in the Delivery Request Block (see section
7.9). 7.10).
If components are missing, there is an error.