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