idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-trade-iotp-v1.0-protocol-02', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 71) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 875 has weird spacing: '...rmation bein...' == Line 955 has weird spacing: '...what is which...' == Line 1089 has weird spacing: '...rmation inf...' == Line 1090 has weird spacing: '...ut what on ...' == Line 1166 has weird spacing: '...cope of authe...' == (41 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (23 October 1998) is 9310 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 822' is mentioned on line 1624, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'Note' is mentioned on line 10375, but not defined == Missing Reference: 'SSL' is mentioned on line 5424, but not defined == Missing Reference: 'ISO 4217' is mentioned on line 4724, but not defined == Missing Reference: 'DocumentStructureDefinition' is mentioned on line 10683, but not defined == Unused Reference: 'Base64' is defined on line 11569, but no explicit reference was found in the text == Unused Reference: 'DSA' is defined on line 11582, but no explicit reference was found in the text == Unused Reference: 'ECCDSA' is defined on line 11587, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 11601, but no explicit reference was found in the text == Unused Reference: 'ISO4217' is defined on line 11609, but no explicit reference was found in the text == Unused Reference: 'MIME' is defined on line 11612, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 11630, but no explicit reference was found in the text == Unused Reference: 'SHA1' is defined on line 11651, but no explicit reference was found in the text == Unused Reference: 'UTF16' is defined on line 11662, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECCDSA' ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTC' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTF16' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSIG' Summary: 14 errors (**), 0 flaws (~~), 26 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRADE Working Group David Burdett 3 Internet Draft Mondex International 4 draft-ietf-trade-iotp-v1.0-protocol-02.txt 23 October 1998 5 Expires: 23 March 1998 7 Internet Open Trading Protocol - IOTP 8 Version 1.0 10 Status of this Memo 12 This document is an Internet draft. Internet drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas and 14 its working groups. Note that other groups may also distribute working 15 information as Internet drafts. 17 Internet Drafts are draft documents valid for a maximum of six months 18 and can be updated, replaced or obsoleted by other documents at any 19 time. It is inappropriate to use Internet drafts as reference material 20 or to cite them as other than as "work in progress". 22 To learn the current status of any Internet draft please check the 23 "lid-abstracts.txt" listing contained in the Internet drafts shadow 24 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East coast) or 26 ftp.isi.edu (US West coast). Further information about the IETF can be 27 found at URL: http://www.ietf.org/ 29 Distribution of this document is unlimited. Please send comments to 30 the TRADE working group at , which may 31 be joined by sending a message with subject "subscribe" to . 34 Discussions of the TRADE working group are archived at 35 http://www.elistx.com/archives/ietf-trade. 37 Abstract 39 The Internet Open Trading Protocol (IOTP) provides an interoperable 40 framework for Internet commerce. It is payment system independent and 41 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 42 GeldKarte, etc. IOTP is able to handle cases where such merchant roles 43 as the shopping site, the payment handler, the Delivery Handler of 44 goods or services, and the provider of customer support are performed 45 by different parties or by one party. 47 Table of Contents 49 Status of this Memo................................................1 51 Abstract...........................................................1 53 1. Background......................................................9 54 1.1 Commerce on the Internet _ a Different Model................9 55 1.2 Benefits of IOTP...........................................10 56 1.3 Baseline IOTP..............................................12 57 1.4 Objectives of Document.....................................12 58 1.5 Purpose....................................................12 59 1.6 Scope of Document..........................................13 60 1.7 Document Structure.........................................13 61 1.8 Intended Readership........................................14 62 1.8.1 Reading Guidelines ....................................14 63 1.9 History....................................................15 65 2. Introduction...................................................16 66 2.1 Trading Roles..............................................16 67 2.2 Trading Exchanges..........................................18 68 2.2.1 Offer Exchange ........................................19 69 2.2.2 Payment Exchange ......................................20 70 2.2.3 Delivery Exchange .....................................23 71 2.2.4 Authentication Exchange ...............................24 72 2.3 Scope of Baseline IOTP.....................................25 74 3. Protocol Structure.............................................28 75 3.1 Overview...................................................29 76 3.1.1 IOTP Message Structure ................................29 77 3.1.2 IOTP Transactions .....................................30 78 3.2 IOTP Message...............................................31 79 3.2.1 XML Document Prolog ...................................33 80 3.3 Transaction Reference Block................................33 81 3.3.1 Transaction Id Component ..............................34 82 3.3.2 Message Id Component ..................................35 83 3.3.3 Related To Component ..................................36 84 3.4 ID Attributes..............................................37 85 3.4.1 IOTP Message ID Attribute Definition ..................38 86 3.4.2 Block and Component ID Attribute Definitions ..........39 87 3.4.3 Example of use of ID Attributes .......................40 88 3.5 Element References.........................................40 89 3.6 Brands and Brand Selection.................................42 90 3.6.1 Definition of Payment Instrument ......................42 91 3.6.2 Definition of Brand ...................................42 92 3.6.3 Definition of Dual Brand ..............................43 93 3.6.4 Definition of Promotional Brand .......................43 94 3.6.5 Identifying Promotional Brands ........................44 95 3.7 Extending IOTP.............................................46 96 3.7.1 Extra XML Elements ....................................46 97 3.7.2 Opaque Embedded Data ..................................47 98 3.7.3 User Defined Codes ....................................47 100 3.8 Packaged Content Element...................................48 101 3.9 Identifying Languages......................................49 102 3.10 Secure and Insecure Net Locations.........................50 104 4. IOTP Error Handling............................................50 105 4.1 Technical Errors...........................................51 106 4.2 Business Errors............................................51 107 4.3 Error Depth................................................52 108 4.3.1 Transport Level .......................................52 109 4.3.2 Message Level .........................................52 110 4.3.3 4Block Level ..........................................53 111 4.4 Idempotency, Processing Sequence, and Message Flow.........54 112 4.4.1 Server Role Processing Sequence .......................55 113 4.4.2 Client Role Processing Sequence .......................59 115 5. Security Considerations........................................64 116 5.1 Digital Signatures and IOTP................................64 117 5.1.1 IOTP Signature Example ................................65 118 5.1.2 SignerOrgRef and VerifierOrgRef Attributes ............66 119 5.1.3 Symmetric and Asymmetric Cryptography .................67 120 5.1.4 Mandatory and Optional Signatures .....................67 121 5.1.5 Using signatures to Prove Actions Complete Successfully68 122 5.2 Checking a Signature is Correctly Calculated...............68 123 5.3 Checking a Payment or Delivery can occur...................69 124 5.3.1 Check the Action Request was sent to the Correct 125 Organisation ................................................69 126 5.3.2 Check the Correct Components are present in the Request 127 Block .......................................................73 128 5.3.3 Check an Action is Authorised .........................73 129 5.4 Data Integrity and Privacy.................................74 131 6. Trading Components.............................................75 132 6.1 Protocol Options Component.................................76 133 6.2 Authentication Data Component..............................77 134 6.3 Authentication Response Component..........................79 135 6.4 Order Component............................................80 136 6.4.1 Order Description Content .............................81 137 6.4.2 OkFrom and OkTo Timestamps ............................82 138 6.5 Organisation Component.....................................82 139 6.5.2 Trading Role Element ..................................85 140 6.5.3 Contact Information Element ...........................87 141 6.5.4 Person Name Element ...................................87 142 6.5.5 Postal Address Element ................................88 143 6.6 Brand List Component.......................................89 144 6.6.1 Brand Element .........................................91 145 6.6.2 Protocol Amount Element ...............................94 146 6.6.3 Currency Amount Element ...............................95 147 6.6.4 Pay Protocol Element ..................................96 148 6.7 Brand Selection Component..................................98 149 6.7.1 Brand Selection Brand Info Element ....................99 150 6.7.2 Brand Selection Protocol Amount Info Element .........100 151 6.7.3 Brand Selection Currency Amount Info Element .........100 152 6.8 Payment Component.........................................101 153 6.9 Payment Scheme Component..................................102 154 6.10 Payment Receipt Component................................104 155 6.11 Payment Note Component...................................105 156 6.12 Delivery Component.......................................106 157 6.12.1 Delivery Data Element ...............................108 158 6.13 Delivery Note Component..................................110 159 6.14 Payment Method Information Component.....................111 160 6.15 Status Component.........................................112 161 6.16 Trading Role Data Component..............................117 162 6.16.1 Who Receives a Trading Role Data Component ..........118 163 6.17 Inquiry Type Component...................................118 164 6.18 Signature Component......................................119 165 6.18.1 Offer Response Signature Component ..................119 166 6.18.2 Payment Receipt Signature Component .................120 167 6.18.3 Ping Signature Components ...........................120 168 6.19 Error Component..........................................121 169 6.19.1 Error Processing Guidelines .........................123 170 6.19.2 Error Codes .........................................124 171 6.19.3 Error Location Element ..............................127 173 7. Trading Blocks................................................128 174 7.1 Trading Protocol Options Block............................130 175 7.2 TPO Selection Block.......................................131 176 7.3 Offer Response Block......................................132 177 7.4 Authentication Request Block..............................133 178 7.5 Authentication Response Block.............................134 179 7.6 Payment Request Block.....................................134 180 7.7 Payment Exchange Block....................................136 181 7.8 Payment Response Block....................................136 182 7.9 Delivery Request Block....................................137 183 7.10 Delivery Response Block..................................138 184 7.11 Payment Instrument Customer Care Request Block...........139 185 7.12 Payment Instrument Customer Care Exchange Block..........140 186 7.13 Payment Instrument Customer Care Response Block..........140 187 7.14 Inquiry Request Trading Block............................141 188 7.15 Inquiry Response Trading Block...........................141 189 7.16 Ping Request Block.......................................142 190 7.17 Ping Response Block......................................143 191 7.18 Signature Block..........................................144 192 7.18.1 Offer Response ......................................145 193 7.18.2 Payment Request .....................................145 194 7.18.3 Payment Response ....................................145 195 7.18.4 Delivery Request ....................................145 196 7.19 Error Block..............................................146 198 8. Open Trading Protocol Transactions............................147 199 8.1 Baseline Authentication IOTP Transaction..................147 200 8.1.1 Trading Protocol Options Block .......................150 201 8.1.2 Authentication Request Block .........................150 202 8.1.3 Signature Block (Authentication Request) .............150 203 8.1.4 Authentication Response Block ........................150 204 8.1.5 Signature Block (Authentication Response) ............150 205 8.2 Baseline Deposit IOTP Transaction.........................151 206 8.2.1 Baseline Deposit Variations ..........................152 207 8.2.2 Baseline Deposit Authentication ......................152 208 8.2.3 Baseline Deposit Payment Messages ....................154 209 8.2.4 TPO (Trading Protocol Options) Block .................155 210 8.2.5 TPO Selection Block ..................................156 211 8.2.6 Authentication Request Block .........................156 212 8.2.7 Authentication Response Block ........................156 213 8.2.8 Offer Response Block .................................156 214 8.2.9 Signature Block (Offer Response) .....................157 215 8.2.10 Payment Request Block ...............................157 216 8.2.11 Signature Block (Payment Request) ...................158 217 8.2.12 Payment Exchange Block ..............................158 218 8.2.13 Payment Response Block ..............................158 219 8.2.14 Signature Block (Payment Response) ..................158 220 8.3 Baseline Purchase IOTP Transaction........................159 221 8.3.1 Baseline Purchase Variations .........................159 222 8.3.2 TPO (Trading Protocol Options) Block .................167 223 8.3.3 TPO Selection Block ..................................167 224 8.3.4 Offer Response Block .................................167 225 8.3.5 Signature Block (Offer Response) .....................168 226 8.3.6 Payment Request Block ................................169 227 8.3.7 Signature Block (Payment Request) ....................169 228 8.3.8 Payment Exchange Block ...............................169 229 8.3.9 Payment Response Block ...............................169 230 8.3.10 Signature Block (Payment Response) ..................170 231 8.3.11 Delivery Request Block ..............................170 232 8.3.12 Signature Block (Delivery Request) ..................171 233 8.3.13 Delivery Response Block .............................171 234 8.4 Baseline Refund IOTP Transaction..........................171 235 8.4.1 Baseline Refund Variations ...........................172 236 8.4.2 Baseline Refund Authentication .......................172 237 8.4.3 Baseline Refund Payment Messages .....................174 238 8.4.4 TPO (Trading Protocol Options) Block .................175 239 8.4.5 TPO Selection Block ..................................175 240 8.4.6 Authentication Request Block .........................176 241 8.4.7 Authentication Response Block ........................176 242 8.4.8 Offer Response Block .................................176 243 8.4.9 Signature Block (Offer Response) .....................176 244 8.4.10 Payment Request Block ...............................177 245 8.4.11 Signature Block (Payment Request) ...................177 246 8.4.12 Payment Exchange Block ..............................177 247 8.4.13 Payment Response Block ..............................178 248 8.4.14 Signature Block (Payment Response) ..................178 249 8.5 Baseline Withdrawal IOTP Transaction......................178 250 8.5.1 Baseline Withdrawal Variations .......................179 251 8.5.2 Baseline Withdrawal Authentication ...................179 252 8.5.3 Baseline Withdrawal Payment Messages .................182 253 8.5.4 TPO (Trading Protocol Options) Block .................183 254 8.5.5 TPO Selection Block ..................................183 255 8.5.6 Authentication Request Block .........................183 256 8.5.7 Authentication Response Block ........................184 257 8.5.8 Offer Response Block .................................184 258 8.5.9 Signature Block (Offer Response) .....................184 259 8.5.10 Payment Request Block ...............................185 260 8.5.11 Signature Block (Payment Request) ...................185 261 8.5.12 Payment Exchange Block ..............................185 262 8.5.13 Payment Response Block ..............................186 263 8.5.14 Signature Block (Payment Response) ..................186 264 8.6 Baseline Value Exchange IOTP Transaction..................186 265 8.6.1 Baseline Value Exchange Variations ...................187 266 8.6.2 PO (Trading Protocol Options) Block ..................191 267 8.6.3 TPO Selection Block ..................................192 268 8.6.4 Offer Response Block .................................192 269 8.6.5 Signature Block (Offer Response) .....................192 270 8.6.6 Payment Request Block (first payment) ................193 271 8.6.7 Signature Block (Payment Request - first payment) ....194 272 8.6.8 Payment Exchange Block (first payment) ...............194 273 8.6.9 Payment Response Block (first payment) ...............194 274 8.6.10 Signature Block (Payment Response - first payment) ..195 275 8.6.11 Payment Request Block (second payment) ..............195 276 8.6.12 Signature Block (Payment Request - second payment) ..196 277 8.6.13 Payment Exchange Block (second payment) .............196 278 8.6.14 Payment Response Block (second payment) .............196 279 8.6.15 Signature Block (Payment Response - second payment) .197 280 8.6.16 Baseline Value Exchange Signatures ..................197 281 8.7 Payment Instrument Customer Care IOTP Transaction.........198 282 8.7.1 Payment Instrument Customer Care Request Block .......200 283 8.7.2 Payment Instrument Customer Care Exchange Block ......200 284 8.7.3 Payment Instrument Customer Care Response Block ......200 285 8.7.4 Signature Block ......................................200 286 8.8 Baseline Transaction Status Inquiry IOTP Transaction......201 287 8.8.1 Which Trading Roles can receive Inquiry Requests .....201 288 8.8.2 Transaction Status Inquiry Transport Session .........201 289 8.8.3 Transaction Status Inquiry Error Handling ............202 290 8.8.4 Inquiry Transaction Messages .........................202 291 8.8.5 Transaction Reference Block ..........................203 292 8.8.6 Inquiry Request Block ................................203 293 8.8.7 Inquiry Response Block ...............................203 294 8.9 Baseline Ping IOTP Transaction............................204 295 8.9.1 Ping Messages ........................................204 296 8.9.2 Transaction Reference Block ..........................205 297 8.9.3 Ping Request Block ...................................205 298 8.9.4 Signature Block (Ping Request) .......................206 299 8.9.5 Ping Response Block ..................................206 300 8.9.6 Signature Block (Ping Response) ......................206 302 9. Retrieving Logos..............................................206 303 9.1 Logo Size.................................................207 304 9.2 Logo Color Depth..........................................207 305 9.3 Logo Net Location Examples................................208 307 10. Brand List Examples..........................................208 308 10.1 Simple Credit Card Based Example.........................208 309 10.2 Credit Card Brand List Including Promotional Brands......209 310 10.3 Brand Selection Example..................................211 311 10.4 Complex Electronic Cash Based Brand List.................211 313 11. XML Overview.................................................213 314 11.1 Document Definition......................................214 315 11.2 Element Declaration......................................214 316 11.2.1 Example 1 ...........................................215 317 11.2.2 Example 2 ...........................................215 318 11.2.3 Example 3 ...........................................215 319 11.2.4 Data Types used in element declarations .............216 320 11.3 Attribute declarations...................................216 321 11.3.1 Declared value ......................................216 322 11.3.2 Default value .......................................217 324 12. Open Trading Protocol Data Type Definition...................218 326 13. Glossary.....................................................229 328 14. Copyrights...................................................232 330 15. References...................................................233 332 16. Author's Address.............................................235 333 Table of Figures 335 Figure 1 IOTP Trading Roles ......................................17 336 Figure 2 Offer Exchange ..........................................19 337 Figure 3 Payment Exchange ........................................21 338 Figure 4 Delivery Exchange .......................................24 339 Figure 5 Authentication Exchange .................................25 340 Figure 6 IOTP Message Structure ..................................29 341 Figure 7 An IOTP Transaction .....................................30 342 Figure 8 Example use of ID attributes ............................40 343 Figure 9 Element References ......................................41 344 Figure 10 Server Role Processing Sequence ........................56 345 Figure 11 Client Role Processing Sequence ........................61 346 Figure 12 Signature Hashing ......................................65 347 Figure 13 Example use of Signatures for Baseline Purchase ........66 348 Figure 14 Checking a Payment Handler can carry out a Payment .....70 349 Figure 15 Checking a Delivery Handler can carry out a Delivery ...72 350 Figure 16 Trading Components .....................................75 351 Figure 17 Brand List Element Relationships .......................91 352 Figure 18 Trading Blocks ........................................129 353 Figure 19 Baseline Authentication ...............................149 354 Figure 20 Baseline Deposit with Authentication ..................153 355 Figure 21 Baseline Deposit without Authentication ...............154 356 Figure 22 Baseline Deposit Payment Messages .....................155 357 Figure 23 Brand Dependent Baseline Purchase .....................161 358 Figure 24 Brand Independent Baseline Purchase ...................162 359 Figure 25 Baseline Purchase, Delivery Response Block and Payment 360 Response Blocks Not Combined .................................163 361 Figure 26 Baseline Purchase, Delivery Response Block and Payment 362 Response Block Combined ......................................164 363 Figure 27 Baseline Purchase, Purchase without Delivery Exchange .166 364 Figure 28 Baseline Purchase Variations ..........................167 365 Figure 29 Baseline Refund with Authentication ...................173 366 Figure 30 Baseline Refund without Authentication ................174 367 Figure 31 Baseline Refund Payment Messages ......................175 368 Figure 32 Baseline Withdrawal with Authentication ...............180 369 Figure 33 Baseline Withdrawal without Authentication ............181 370 Figure 34 Baseline Withdrawal Payment Messages ..................183 371 Figure 35 Brand Dependent Value Exchange ........................189 372 Figure 36 Brand Independent Value Exchange ......................189 373 Figure 37 Baseline Value Exchange Payment Messages ..............191 374 Figure 38 Baseline Value Exchange Signatures ....................198 375 Figure 39 IOTP Payment Instrument Customer Care Transaction Message 376 Flows ........................................................200 377 Figure 40 Baseline Transaction Status Inquiry ...................203 378 Figure 41 Baseline Ping Messages ................................204 380 1. Background 382 The Internet Open Trading Protocol (IOTP) provides an interoperable 383 framework for Internet commerce. It is payment system independent and 384 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 385 GeldKarte, etc. IOTP is able to handle cases where such merchant roles 386 as the shopping site, the payment handler, the Delivery Handler of 387 goods or services, and the provider of customer support are performed 388 by different parties or by one party. 390 The developers of IOTP seek to provide a virtual capability that 391 safely replicates the real world, the paper based, traditional, 392 understood, accepted methods of trading, buying, selling, value 393 exchanging that has existed for many hundreds of years. The 394 negotiation of who will be the parties to the trade, how it will be 395 conducted, the presentment of an offer, the method of payment, the 396 provision of a payment receipt, the delivery of goods and the receipt 397 of goods. These are events that are taken for granted in the course of 398 real world trade. IOTP has been produced to provide the same for the 399 virtual world, and to prepare and provide for the introduction of new 400 models of trading made possible by the expanding presence of the 401 virtual world. 403 The other fundamental ideal of the IOTP effort is to produce a 404 definition of these trading events in such a way that no matter where 405 produced, two unfamiliar parties using electronic commerce 406 capabilities to buy and sell that conform to the IOTP specifications 407 will be able to complete the business safely and successfully. 409 In summary, IOTP supports: 410 o Familiar trading models 411 o New trading models 412 o Global interoperability 414 The remainder of this section provides background to why IOTP was 415 developed. The specification itself starts in the next chapter. 417 1.1 Commerce on the Internet _ a Different Model 419 The growth of the Internet and the advent of electronic commerce are 420 bringing about enormous changes around the world in society, politics 421 and government, and in business. The ways in which trading partners 422 communicate, conduct commerce, are governed have been enriched and 423 changed forever. 425 One of the very fundamental changes about which IOTP is concerned is 426 taking place in the way consumers and merchants trade. Characteristics 427 of trading that have changed markedly include: 428 o Presence: Face-to-face transactions become the exception, not 429 the rule. Already with the rise of mail order and telephone 430 order placement this change has been felt in western commerce. 431 Electronic commerce over the Internet will further expand the 432 scope and volume of transactions conducted without ever seeing 433 the people who are a part of the enterprise with whom one does 434 business. 435 o Authentication: An important part of personal presence is the 436 ability of the parties to use familiar objects and dialogue to 437 confirm they are who they claim to be. The seller displays one 438 or several well known financial logos that declaim his ability 439 to accept widely used credit and debit instruments in the 440 payment part of a purchase. The buyer brings government or 441 financial institution identification that assures the seller 442 she will be paid. People use intangibles such as personal 443 appearance and conduct, location of the store, apparent 444 quality and familiarity with brands of merchandise, and a good 445 clear look in the eye to reinforce formal means of 446 authentication. 447 o Payment Instruments: Despite the enormous size of bank card 448 financial payments associations and their members, most of the 449 world's trade still takes place using the coin of the realm or 450 barter. The present infrastructure of the payments business 451 cannot economically support low value transactions and could 452 not survive under the consequent volumes of transactions if it 453 did accept low value transactions. 454 o Transaction Values: New meaning for low value transactions 455 arises in the Internet where sellers may wish to offer for 456 example, pages of information for fractions of currency that 457 do not exist in the real world. 458 o Delivery: New modes of delivery must be accommodated such as 459 direct electronic delivery. The means by which receipt is 460 confirmed and the execution of payment change dramatically 461 where the goods or services have extremely low delivery cost 462 but may in fact have very high value. Or, maybe the value is 463 not high, but once delivery occurs the value is irretrievably 464 delivered so payment must be final and non-refundable but 465 delivery nonetheless must still be confirmed before payment. 466 Incremental delivery such as listening or viewing time or 467 playing time are other models that operate somewhat 468 differently in the virtual world. 470 1.2 Benefits of IOTP 472 Electronic Commerce Software Vendors 474 Electronic Commerce Software Vendors will be able to develop e- 475 commerce products which are more attractive as they will inter-operate 476 with any other vendors' software. However since IOTP focuses on how 477 these solutions communicate, there is still plenty of opportunity for 478 product differentiation. 480 Payment Brands 482 IOTP provides a standard framework for encapsulating payment 483 protocols. This means that it is easier for payment products to be 484 incorporated into IOTP solutions. As a result the payment brands will 485 be more widely distributed and available on a wider variety of 486 platforms. 488 Merchants 490 There are several benefits for Merchants: 491 o they will be able to offer a wider variety of payment brands, 492 o they can be more certain that the customer will have the 493 software needed to complete the purchase 494 o through receiving payment and delivery receipts from their 495 customers, they will be able to provide customer care knowing 496 that they are dealing with the individual or organisation with 497 which they originally traded 498 o new merchants will be able to enter this new (Internet) 499 market-place with new products and services, using the new 500 trading opportunities which IOTP presents 502 Banks and Financial Institutions 504 There are also several benefits for Banks and Financial Institutions: 505 o they will be able to provide IOTP support for merchants 506 o they will find new opportunities for IOTP related services: 507 - providing customer care for merchants 508 - fees from processing new payments and deposits 509 o they have an opportunity to build relationships with new types 510 of merchants 512 Customers 514 For Customers there are several benefits: 515 o they will have a larger selection of merchants with whom they 516 can trade 517 o there is a more consistent interface when making the purchase 518 o there are ways in which they can get their problems fixed 519 through the merchant (rather than the bank!) 520 o there is a record of their transaction which can be used, for 521 example, to feed into accounting systems or, potentially, to 522 present to the tax authorities 524 1.3 Baseline IOTP 526 This specification is Baseline IOTP. It is a Baseline in that it 527 contains ways of doing trades on the Internet which are the most 528 common. The team working on the IOTP see an extended versions of this 529 specification being developed as needs demand but at this stage feel a 530 need to develop a limited function but usable specification in order 531 that technology providers can develop pathway-pilot products that will 532 be placed in the market in order to understand the real _market 533 place_ demands and requirements for electronic trading or electronic 534 commerce. To proceed otherwise would be presumptuous, time consuming, 535 expensive and foolish. 537 Accordingly the IOTP Baseline specification has been produced for 538 pathway-pilot product development, expecting to transact live trades 539 to prove the interoperability of solutions based on this specification 540 by end '98. 542 During this period it is anticipated that there will be no changes to 543 the scope of this specification with the only changes made being 544 limited to corrections where problems are found. Software solutions 545 have been developed based on earlier versions of this specification 546 which prove that the basic concepts work. 548 1.4 Objectives of Document 550 The objectives of this document are to provide a functional 551 specification of version 1.0 of the Open Trading Protocols which can 552 be used to design and implement systems which support electronic 553 trading on the Internet using the Open Trading Protocols. 555 An overview of IOTP is provided the IOTP Business Description which 556 explains the Business Requirements for IOTP. 558 1.5 Purpose 560 The purpose of the document is: 561 o to allow potential developers of products based on the 562 protocol to start development of software/hardware solutions 563 which use the protocol 564 o to allow the financial services industry to understand a 565 developing electronic commerce trading protocol that 566 encapsulates (without modification) any of the current or 567 developing payment schemes now being used or considered by 568 their merchant customer base 570 1.6 Scope of Document 572 The protocol describes the content, format and sequences of messages 573 that pass among the participants in an electronic trade - consumers, 574 merchants and banks or other financial institutions, and customer care 575 providers. These are required to support the electronic commerce 576 transactions outlined in the objectives above. 578 The protocol is designed to be applicable to any electronic payment 579 scheme since it targets the complete purchase process where the 580 movement of electronic value from the payer to the payee is only one, 581 but important, step of many that may be involved to complete the 582 trade. 584 Payment Scheme which IOTP could support include MasterCard Credit, 585 Visa Credit, Mondex Cash, Visa Cash, GeldKarte, DigiCash, CyberCoin, 586 Millicent, Proton etc. 588 Each payment scheme contains some message flows which are specific to 589 that scheme. These scheme-specific parts of the protocol are contained 590 in a set of payment scheme supplements to this specification. 592 The document does not prescribe the software and processes that will 593 need to be implemented by each participant. It does describe the 594 framework necessary for trading to take place. 596 This document also does not address any legal or regulatory issues 597 surrounding the implementation of the protocol or the information 598 systems which use them. 600 1.7 Document Structure 602 The document consists of the following sections: 603 o Section 1 - Background: This section gives a brief background 604 on electronic commerce and the benefits IOTP offers. 605 o Section 2 - Introduction: This section describes the various 606 Trading Exchanges and shows how these trading exchanges are 607 used to construct the IOTP Transactions. This section also 608 explains various Trading Roles that would participate in 609 electronic trade. 610 o Section 3 - Protocol Structure: This section summarises how 611 various IOTP transactions are constructed using the Trading 612 Blocks and Trading Components that are the fundamental 613 building blocks for IOTP transactions. All IOTP transaction 614 messages are well formed XML documents. 615 o Section 4 - IOTP Error Handling: This section describes how to 616 process exceptions and errors during the protocol message 617 exchange and trading exchange processing. This section 618 provides a generic overview of the exception handling. This 619 section should be read carefully. 621 o Section 5 - Security Considerations: This section describes 622 security considerations and digital signatures for the XML 623 elements exchanged between the Trading Roles. 624 o Section 6 - Trading Components: This section defines the XML 625 elements required by Trading Components. 626 o Section 7 - Trading Blocks: This section describes how Trading 627 Blocks are constructed from Trading Components. 628 o Section 8 - Open Trading Protocol Transactions: This section 629 describes all the IOTP Baseline transactions. It refers to 630 Trading Blocks and Trading Components and Signatures. This 631 section doesn't directly link error handling during the 632 protocol exchanges, the reader is advised to understand Error 633 Handling as defined in section before reading this section. 634 o Section 9 - Retrieving Logos: This section describes how IOTP 635 specific logos can be retrieved. 636 o Section 10 - Brand List Examples: This section gives some 637 examples for Brand List. 638 o Section 11 - XML Overview: This section gives brief 639 introduction to XML. 640 o Section 12 - Open Trading Protocol Data Type Definition: This 641 section contains the XML Data Type Definitions for IOTP. 642 o Section 12 - Glossary. This describes all the major 643 terminology used by IOTP. 645 1.8 Intended Readership 647 Software and hardware developers; development analysts; business and 648 technical planners; industry analysts; merchants; bank and other 649 payment handlers; owners, custodians, and users of payment protocols. 651 1.8.1 Reading Guidelines 653 This IOTP specification is structured primarily in a sequence targeted 654 at people who want to understand the principles of IOTP. However from 655 practical implementation experience by implementers of earlier of 656 versions of the protocol new readers who plan to implement IOTP may 657 prefer to read the document in a different sequence as described 658 below. 660 Review the transport independent parts of the specification: This 661 covers 662 o Section 12 - Glossary 663 o Section 1 - Background 664 o Section 2 - Introduction 665 o Section 3 - Protocol Structure 666 o Section 4 - IOTP Error Handling 667 o Section 8 - Open Trading Protocol Transactions 668 o Section 10 - Brand List Examples 669 o Section 4 - IOTP Error Handling 670 o Section 9 - Retrieving Logos 671 Review the detailed XML definitions: 672 o Section 11 - XML Overview (if the reader does not know XML) 673 o Section 7 - Trading Blocks 674 o Section 6 - Trading Components 676 1.9 History 678 Version 0.1 20 February Initial draft for comment 679 1997 681 Version 0.2 14 April 1997 Revised draft including changes 682 arising from comments 684 Version 0.2a 24 April 1997 Same as version 0-2 with 685 typographic corrections 687 Version 0.3 9 October 1997 Revised draft for comment 688 including revised encoding 689 approach using [XML] 691 Version 0.4 31 October 1997 Published draft for limited public 692 review by groups working within 693 IOTP dev 695 Version 0.9 12 January 1998 Revisions following limited public 696 review _ draft for public comment 697 only. 699 Version 0.9.1 20 May 1998 Revisions following public review 700 - internal IOTP Consortium review. 702 Version 0.9.9 17 August 1998 Draft published for submission to 703 IETF for information. 705 Version 1.0 23 October 1998 Draft published incorporating 706 comments received on version 707 0.9.9. 709 2. Introduction 711 The Open Trading Protocols (IOTP) define a number of different types 712 of IOTP Transactions: 713 o Purchase. This supports a purchase involving an offer, a 714 payment and optionally a delivery 715 o Refund. This supports the refund of a payment as a result of, 716 typically, an earlier purchase 717 o Value Exchange. This involves two payments which result in the 718 exchange of value from one combination of currency and payment 719 method to another 720 o Authentication. This supports the remote authentication of a 721 Consumer by another Trading Role using a variety of 722 authentication methods, and the provision of an Organisation 723 Component about a Consumer to another Trading Role for use in, 724 for example the creation of an offer 725 o Withdrawal. This supports the withdrawal of electronic cash 726 from a financial institution 727 o Deposit. This supports the deposit of electronic cash at a 728 financial institution 729 o Payment Instrument Customer Care. This supports the provision 730 of Payment Brand or Payment Method specific customer care of a 731 Payment Instrument 732 o Inquiry This supports inquiries on the status of an IOTP 733 transaction which is either in progress or is complete 734 o Ping This supports a simple query which enables one IOTP aware 735 application to determine whether another IOTP application 736 running elsewhere is working or not. 738 These IOTP Transactions are "Baseline" transactions since they have 739 been identified as a minimum useful set of transactions. Later 740 versions of IOTP may include additional types of transactions. 742 Each of the IOTP Transactions above involve: 743 o a number organisations playing a Trading Role, and 744 o a set of Trading Exchanges. Each Trading Exchange involves the 745 exchange of data, between Trading Roles, in the form of a set 746 of Trading Components. 748 Trading Roles, Trading Exchanges and Trading Components are described 749 below. 751 2.1 Trading Roles 753 The Trading Roles identify the different parts which organisations can 754 take in a trade. The five Trading Roles used within IOTP are 755 illustrated in the diagram below. 757 Merchant Customer Care Provider resolves ---------- 758 ---------------------------------------------->| Merchant | 759 | Consumer disputes and problems |Cust.Care.| 760 | | Provider | 761 | ---------- 762 | 763 | Payment Handler accepts or makes ---------- 764 | ------------------------------------------>| Payment | 765 | | Payment for Merchant | Handler | 766 | | ---------- 767 v v 768 ---------- Consumer makes purchases or obtains ---------- 769 | Consumer |<--------------------------------------->| Merchant | 770 ---------- refund from Merchant ---------- 771 ^ ^ 772 | | Delivery Handler supplies goods or ---------- 773 | ------------------------------------------>|Deliverer | 774 | services for Merchant ---------- 775 | 776 | ---------- 777 | Payment Instrument Customer Care Provider | Payment | 778 ---------------------------------------------->|Instrument| 779 resolves problems with Payment Instruments |Cust.Care.| 780 | Provider | 781 ---------- 783 Figure 1 IOTP Trading Roles 785 The roles are: 786 o Consumer. The person or organisation which is to receive and 787 pay for the goods or services 788 o Merchant. The person or organisation from whom the purchase is 789 being made and who is legally responsible for providing the 790 goods or services and receives the benefit of the payment made 791 o Payment Handler. The entity that physically receives the 792 payment from the Consumer on behalf of the Merchant 793 o Delivery Handler. The entity that physically delivers the 794 goods or services to the Consumer on behalf of the Merchant. 795 o Merchant Customer Care Provider. The entity that is involved 796 with customer dispute negotiation and resolution on behalf of 797 the Merchant 798 o Payment Instrument Customer Care Provider. The entity that 799 resolves problems with a particular Payment Instrument 801 Roles may be carried out by the same organisation or different 802 organisations. For example: 803 o in the simplest case one physical organisation (e.g. a 804 merchant) could handle the purchase, accept the payment, 805 deliver the goods and provide merchant customer care 806 o at the other extreme, a merchant could handle the purchase but 807 instruct the consumer to pay a bank or financial institution, 808 request that delivery be made by an overnight courier firm and 809 to contact an organisation which provides 24x7 service if 810 problems arise. 812 Note that in this specification, unless stated to the contrary, when 813 the words Consumer, Merchant, Payment Handler, Delivery Handler or 814 Customer Care Provider are used, they refer to the Trading Role rather 815 than an actual organisation. 817 An individual organisation may take multiple roles. For example a 818 company which is selling goods and services on the Internet could take 819 the role of Merchant when selling goods or services and the role of 820 Consumer when the company is buying goods or services itself. 822 As roles occur in different places there is a need for the 823 organisations involved in the trade to exchange data, i.e. to carry 824 out Trading Exchanges, so that the trade can be completed. 826 2.2 Trading Exchanges 828 The Open Trading Protocols identify four Trading Exchanges which 829 involve the exchange of data between the Trading Roles. The Trading 830 Exchanges are: 831 o Offer. The Offer Exchange results in the Merchant providing 832 the Consumer with the reason why the trade is taking place. It 833 is called an Offer since the Consumer must accept the Offer if 834 a trade is to continue 835 o Payment. The Payment Exchange results in a payment of some 836 kind between the Consumer and the Payment Handler. This may 837 occur in either direction 838 o Delivery. The Delivery Exchange transmits either the on-line 839 goods, or delivery information about physical goods from the 840 Delivery Handler to the Consumer, and 841 o Authentication. The Authentication Exchange can be used by any 842 Trading Role to authenticate another Trading Role to check 843 that they are who they appear to be. 845 IOTP Transactions are composed of various combinations of these 846 Trading Exchanges. For example, an IOTP Purchase transaction includes 847 Offer, Payment, and Delivery Trading Exchanges. As another example, 848 an IOTP Value Exchange transaction is composed of an Offer Trading 849 Exchange and two Payment Trading Exchanges. 851 Trading Exchanges consist of Trading Components that are transmitted 852 between the various Trading Roles. Where possible, the number of 853 round-trip delays in an IOTP Transaction is minimised by packing the 854 Components from several Trading Exchanges into combination IOTP 855 Messages. For example, the IOTP Purchase transaction combines a 856 Delivery Organisation Component with an Offer Response Component in 857 order to avoid an extra Consumer request and response. 859 Each of the IOTP Trading Exchanges is described in more detail below. 860 For clarity of description, these describe the Trading Exchanges as 861 though they were standalone operations. For performance reasons, the 862 Trading Exchanges are intermingled in the actual IOTP Transaction 863 definitions. 865 2.2.1 Offer Exchange 867 The goal of the Offer Exchange is for the Merchant to provide the 868 Consumer with information about the trade so that the Consumer can 869 decide whether to continue with the trade. This is illustrated in the 870 figure below. 872 CONSUMER OTP MESSAGE MERCHANT 873 1. Consumer decides to ----------------------> 2. Merchant checks 874 pay (request an offer) Information on what is the information 875 and sends information being purchased (Offer provided by the 876 on what to purchase to Request) (outside scope Consumer, creates 877 the Merchant using e.g. of OTP) and Offer and sends 878 HTML it to the Consumer. 879 | 880 v 881 Components: Organisation(s) 882 3. Consumer checks the (Consumer, DeliverTo, Merchant, 883 information from the <---------- Payment Handler, Delivery 884 Merchant and decides Offer Handler, Cust Care); Order; Pay 885 whether to continue Response Amount; Delivery; Signature 886 (Offer Response)(which signs 887 other components) 889 Figure 2 Offer Exchange 891 An Offer Exchange uses the following Trading Components that are 892 passed between the Consumer and the Merchant: 893 o the Organisation Component contains information which 894 describes the organisations which are taking a role in the 895 trade: 896 - the consumer provides information, about who the consumer is 897 and, if goods or services are being delivered, where the goods 898 or services are to be delivered to 899 - the merchant augments this information by providing information 900 about the merchant, the Payment Handler, the customer care 901 provider and, if goods or services are being delivered, the 902 Delivery Handler 903 o the Order Component contains descriptions of the goods or 904 services which will result from the trade if the consumer 905 agrees to the offer. This information is sent by the Merchant 906 to the consumer who should verify it 907 o the Payment Component generated by the Merchant, contains 908 details of how much to pay, the currency and the payment 909 direction, for example the consumer could be asking for a 910 refund. Note that there may be more than one payment in a 911 trade 912 o the Delivery Component, also generated by the Merchant, is 913 used if goods or services are being delivered. This contains 914 information about how delivery will occur, for example by post 915 or using e-mail 916 o the "Offer Response" Signature Component, if present, 917 digitally signs all of the above components to ensure their 918 integrity. 920 The exact content of the information provided by the Merchant to the 921 Consumer will vary depending on the type of IOTP Transaction. For 922 example: 923 o low value purchases may not need a signature 924 o the amount to be paid may vary depending on the payment brand 925 and payment protocol used 926 o some offers may not involve the delivery of any goods 927 o a value exchange will involve two payments 928 o a merchant may not offer customer care. 930 Information provided by the consumer to the merchant could be provided 931 using a variety of methods, for example, it could be provided: 932 o using [HTML] pages as part of the "shopping experience" of the 933 consumer. 934 o using the Open Profiling Standard [OPS] which has recently 935 been proposed, 936 o in the form of Organisation and Order Components in a later 937 version of IOTP. 939 2.2.2 Payment Exchange 941 The goal of the Payment Exchange is for a payment to be made from the 942 Consumer to a Payment Handler or vice versa using a payment brand and 943 payment protocol selected by the Consumer. A secondary goal is to 944 optionally provide the Consumer with a digitally signed Payment 945 Receipt which can be used to link the payment to the reason for the 946 payment as described in the Offer Exchange. 948 Payment Exchanges can work in a variety of ways. The most general case 949 where the trade is dependent on the payment brand and protocol used is 950 illustrated in the diagram below. Simpler payment exchanges are 951 possible. 953 CONSUMER OTP MESSAGE MERCHANT 954 1. Consumer decides to 2. Merchant decides 955 trade and sends Information on what is which payment brand 956 information on what to being paid for and protocols to 957 purchase to the ----------------------> offer, places then 958 Merchant, e.g. using (outside scope of OTP) in a Brand List 959 HTML Component and sends 960 them to the 961 Consumer. 963 | 964 v 965 3. Consumer selects the payment <----------------- Brand List 966 brand and protocol to use, creates a Brand List Component 967 Brand Selection Component and sends 968 it to the Merchant 969 | 970 v 971 Brand Selection ----------------> 4. Merchant checks Brand 972 Brand Selection Selection, creates Payment Amount 973 Information, optionally signs it 974 to authorise payment and send it 975 to the consumer 976 | 977 v 978 5. Consumer checks the Components: 979 Payment Amount information <-------- Pay Amount; Auth data; 980 and if OK requests that the Payment Organisation(s) (Merchant & 981 payment starts by sending Information Payment Handler); Signature 982 information to the Payment (Offer) (signs other 983 Handler components) 984 | 985 | ======================================== 986 v PAYMENT HANDLER 987 Components: Pay Scheme; Auth 6. Payment Handler checks 988 Data; Brand List; Pay Amount; information including 989 Brand Selection; ----------> optional signature and if 990 Organisation(s) (Merchant & Payment OK starts exchanging Pay 991 Payment Handler); Signature Request Scheme Components using 992 (Offer) (signs all other messages for selected 993 components except payment brand and payment 994 ------ Pay Scheme) protocol 995 | | | 996 | v v 997 | Component: Pay Scheme <------------------> Component: Pay Scheme 998 | Payment Exchange 999 | | 1000 | v 1001 | 7. Eventually payment protocol messages 1002 ---------- finish so Payment Handler sends Pay 1003 | Receipt and optional signature to 1004 | Consumer as proof of payment 1005 | | 1006 | v 1007 v Components: Pay Receipt; Pay 1008 8 Consumer checks Pay scheme; Signature (Offer); 1009 Receipt is OK <------- Signature (Pay Receipt) 1010 Payment (signs Pay Receipt and 1011 Response Signature (Offer) components) 1013 Figure 3 Payment Exchange 1014 A Payment Exchange uses the following Trading Components that are 1015 passed between the Consumer, the Merchant and the Payment Handler: 1016 o The Brand List Component contains a list of payment brands 1017 (for example, MasterCard, Visa, Mondex, GeldKarte) and payment 1018 protocols (for example SET Version 1.0, Secure Channel Credit 1019 Debit (SCCD - the name used for a credit or debit card payment 1020 where unauthorised access to account information is prevented 1021 through use of secure channel transport mechanisms such as 1022 SSL). The Merchant sends the Brand List to the Consumer. The 1023 consumer compares the payment brands and protocols on offer 1024 with those that the Consumer supports and makes a selection. 1025 o The Brand Selection Component contains the Consumer's 1026 selection. Payment brand, protocol and possibly protocol- 1027 specific information is sent back to the Merchant. This 1028 information may be used to change information in the Offer 1029 Exchange. For example, a merchant could choose to offer a 1030 discount to encourage the use of a store card. 1031 o The Organisation Components are generated by the Merchant. 1032 They contain details of the Merchant and Payment Handler 1033 Roles: 1034 - the Merchant role is required so that the Payment Handler can 1035 identify which Merchant initiated the payment. Typically, the 1036 result of the Payment Handler accepting (or making) a payment on 1037 behalf of the Merchant will be a credit or debit transaction to 1038 the Merchant's account held by the Payment Handler. These 1039 transactions are outside the scope of IOTP 1040 - the Payment Handler role is required so that the Payment Handler 1041 can check that it is the correct Payment Handler to be used for 1042 the payment 1043 o The optional Authentication Data Component contains challenge 1044 data which is used by the payment protocol to authenticate the 1045 consumer. Authentication may not always occur 1046 o The Payment Component contains details of how much to pay, the 1047 currency and the payment direction, and identifies the 1048 Authentication Data Component to use. 1049 o The "Offer Response" Signature Component, if present, 1050 digitally signs all of the above components to ensure their 1051 integrity. Note that the Brand List and Brand Selection 1052 Components are not signed until the payment information is 1053 created (step 3 in the diagram) 1054 o The Payment Scheme Component contains messages from the 1055 payment protocol used in the Trade. For example they could be 1056 SET messages, Mondex messages, GeldKarte Messages or one of 1057 the other payment methods supported by IOTP. The content of 1058 the Payment Scheme Component is defined in the supplements 1059 that describe how IOTP works with various payment protocols. 1060 o The Payment Receipt Component contains a record of the 1061 payment. The content depends upon the payment protocol used. 1062 o The "Payment Receipt" Signature Component provides proof of 1063 payment by digitally signing both the Payment Receipt 1064 Component and the Offer Signature. The signature on the offer 1065 digitally signs the Order, Organisation and Delivery 1066 Components contained in the Offer. This signature effectively 1067 binds the payment to the offer. 1069 The example of a Payment Exchange above is the most general case. 1070 Simpler cases are also possible. For example, if the amount paid is 1071 not dependent on the payment brand and protocol selected then the 1072 payment information generated by step 3 can be sent to the Consumer at 1073 the same time as the Brand List Component generated by step 1. These 1074 and other variations are described in the Baseline Purchase IOTP 1075 Transaction (see section 8.3). 1077 2.2.3 Delivery Exchange 1079 The goal of the Delivery Exchange is to cause purchased goods to be 1080 delivered to the consumer either online or via physical delivery. A 1081 second goal is to provide a "delivery note" to the consumer, providing 1082 details about the delivery, such as shipping tracking number. A future 1083 goal is to have a signed delivery that can be used for customer care 1084 in the case of problems with physical delivery. This is illustrated in 1085 the diagram below. 1087 CONSUMER OTP MESSAGE MERCHANT 1088 1. Consumer decides to ------------> 2. Merchant checks the 1089 trade and sends Information information provided by the 1090 information about what on what is Consumer, adds information 1091 to deliver and who is being about how the delivery will 1092 to take delivery, to delivered occur, information about the 1093 the Merchant, using for (outside organisations involved in the 1094 example, HTML scope of OTP) delivery and optionally signs 1095 it 1096 | 1097 v 1098 3. Consumer checks the Components: 1099 delivery information is OK, Delivery; 1100 obtains authorisation for <----------------- Organisation(s) 1101 the delivery, for example by Delivery Delivery Handler, 1102 making a payment, and sends Information Deliver To; Order; 1103 the delivery information to Signature (Offer) 1104 the Delivery Handler. 1105 | 1106 v 1107 Components: Delivery; 4. Delivery Handler checks 1108 Organisation(s), Merchant, information and 1109 Delivery Handler, DelivTo; --------> authorisation. Starts or 1110 Order; Signature (Offer); Delivery schedules delivery and 1111 Signature (Pay Receipt) Request creates and then sends a 1112 (from Payment Exchange) delivery note to the Consumer 1113 | 1114 v 1115 5. Consumer checks delivery <--------- Component: Delivery 1116 note is OK and accepts or waits Delivery Note 1117 for delivery as described in Response 1118 the Delivery Note 1120 Figure 4 Delivery Exchange 1122 A Delivery Exchange uses the following Trading Components that are 1123 passed between the Consumer, the Merchant and the Delivery Handler: 1124 o The Organisation Component(s) contain details of the Deliver 1125 To, Delivery Handler and Merchant Roles: 1126 - the Deliver To role indicates where the goods or services are to 1127 be delivered to 1128 - the Delivery Handler role is required so that the Delivery 1129 Handler can check that she is the correct Delivery Handler to do 1130 the delivery 1131 - the Merchant role is required so that the Delivery Handler can 1132 identify which Merchant initiated the delivery 1133 o The Order Component, contains information about the goods or 1134 services to be delivered 1135 o The Delivery Component contains information about how delivery 1136 will occur, for example by post or using e-mail. 1137 o The "Offer Response" Signature Component, if present, 1138 digitally signs all of the above components to ensure their 1139 integrity. 1140 o The " Payment Receipt" Signature Component provides proof of 1141 payment by digitally signing the Payment Receipt Component and 1142 the Offer Signature. This is used by the Delivery Handler to 1143 check that delivery is authorised 1144 o The Delivery Note Component contains customer care information 1145 related to a physical delivery, or alternatively the actual 1146 "electronic goods". The Consumer's software does not interpret 1147 information about a physical delivery but should have the 1148 ability to display the information, both at the time of the 1149 delivery and later if the Consumer selects the Trade to which 1150 this delivery relates from a transaction list. 1152 2.2.4 Authentication Exchange 1154 The goal of the Authentication Exchange is to allow one organisation, 1155 for example a financial institution, to be able to check that another 1156 organisation, for example a consumer, is who they appear to be. It 1157 uses a "challenge-response" mechanism. This is illustrated in the 1158 diagram below. 1160 ORGANISATION 1 OTP MESSAGE ORGANISATION 2 1161 1. First organisation, 2. The second 1162 e.g a consumer, takes an organisation generates 1163 action (for example by ----------------> Authentication Data 1164 pressing a button on an Need for containing challenge data 1165 HTML page) which Authentication and the method of 1166 requires that the (outside scope of authentication to be used 1167 organisation is OTP) then sends it to the 1168 authenticated first organisation 1169 | 1170 v 1171 3. The first organisation uses Component: 1172 the challenge data with the <------------ Authentication Data 1173 specified authentication method Authentication 1174 to generate an Authentication Request 1175 Response which is sent back to 1176 the second organisation 1177 | 1178 v 1179 Component: 1180 Authentication -------------> 4. The Authentication Response is 1181 Response Authentication checked against the challenge data to 1182 Response check that the first organisation is 1183 who they appear to be 1185 Figure 5 Authentication Exchange 1187 An Authentication Exchange uses the following Trading Components that 1188 are passed between the two organisations: 1189 o the Authentication Data Component which contains the challenge 1190 data to be used in the "challenge-response" mechanism and 1191 indicates the authentication method to be used. It is sent by 1192 one organisation to the other. 1193 o the Authentication Response Component which contains the 1194 challenge response generated by the recipient of the 1195 Authentication Data Component. It is sent back to the first 1196 organisation for verification. 1198 2.3 Scope of Baseline IOTP 1200 This specification describes the IOTP Transactions which make up 1201 Baseline IOTP. As described in the preface, IOTP will evolve over 1202 time. This section defines the initial conformance criteria for 1203 implementations that claim to _support IOTP._ 1205 The main determinant on the scope of an IOTP implementation is the 1206 roles which the solution is designed to support. The roles within IOTP 1207 are described in more detail in section 2.1 Trading Roles. To 1208 summarise the roles are: Merchant, Consumer, Payment Handler, Delivery 1209 Handler and Customer Care Provider. 1211 Payment Handlers who can be of three types: 1212 o those who accept a payment as part of a purchase or make a 1213 payment as part of a refund, 1214 o those who accept value as part of a deposit transaction, or 1215 o those that issue value a withdrawal transaction 1217 The following table defines, for each role, the IOTP Transactions and 1218 Trading Blocks which must be supported for that role. 1220 Merchants 1222 ECash ECash 1223 Store Value Value Consumer Payment Delivery Pay 1224 Issuer Acquirer Handler Handler Inst. 1225 Cuts 1226 Care 1228 TRANSACTIONS 1230 Purchase Must Must 1232 Refund Must b) 1233 Depends 1235 Authent- May Must May b) 1236 ication Depends 1238 Value May Must 1239 Exchange 1241 Withdrawal Must b) 1242 Depends 1244 Deposit Must b) 1245 Depends 1247 Inquiry Must Must Must Must Must Must Must 1249 Ping Must Must Must Must Must Must Must 1251 Pay Inst. b) Must 1252 Cust. Care Depends 1254 TRADING 1255 BLOCKS 1257 TPO Must Must Must Must 1259 TPO Must Must Must Must 1260 Selection 1262 Auth-Requesta) a) a) 1263 Depends Depends Depends 1265 Auth-Reply a) a) a) 1266 Depends Depends Depends 1268 Offer Must Must Must Must 1269 Response 1271 Payment Must Must 1272 Merchants 1274 ECash ECash 1275 Store Value Value Consumer Payment Delivery Pay 1276 Issuer Acquirer Handler Handler Inst. 1277 Cuts 1278 Care 1279 Request 1281 Payment Must Must 1282 Exchange 1284 Payment Must Must 1285 Response 1287 Delivery Must Must 1288 Request 1290 Delivery Must Must 1291 Response 1293 Pay Inst. b) Must 1294 Cust Care Depends 1295 Req. 1297 Pay Inst. b) Must 1298 Cust Care Depends 1299 Resp 1301 Inquiry Must Must Must Must Must Must Must 1302 Request 1304 Inquiry Must Must Must Must Must Must Must 1305 Response 1307 Ping RequestMust Must Must Must Must Must Must 1309 Ping Must Must Must Must Must Must Must 1310 Response 1312 Signature Must Must Must Limited Must Must b) 1313 Depends 1315 Error Must Must Must Must Must Must Must 1317 In the above table: 1318 o _Must_ means that a Trading Role must support the 1319 Transaction or Trading Block. 1320 o _May_ means that an implementation may support the 1321 Transaction or Trading Block at the option of the developer. 1322 o _Depends_ means implementation of the Transaction or Trading 1323 Block depends on one of the following conditions: 1325 - if Baseline Authentication IOTP Transaction is 1326 supported; 1328 - if required by a Payment Method as defined in its IOTP 1329 Supplement document. 1331 o "Limited" means the Trading Block must be understood and its 1332 content manipulated but not in every respect. Specifically, on 1333 the Signature Block, Consumers do not have to be able to 1334 validate digital signatures. 1336 An IOTP solution must support all the IOTP Transactions and Trading 1337 Blocks required by at least one role (column) as described in the 1338 above table for that solution to be described as "supporting IOTP". 1340 3. Protocol Structure 1342 The previous section provided an introduction which explained: 1343 o Trading Roles which are the different roles which 1344 organisations can take in a trade: Consumer, Merchant, Payment 1345 Handler, Delivery Handler and Merchant and Payment Instrument 1346 Customer Care Provider, and 1347 o Trading Exchanges where each Trading Exchange involves the 1348 exchange of data, between Trading Roles, in the form of a set 1349 of Trading Components. 1351 This section describes: 1352 o how Trading Components are constructed into Trading Blocks and 1353 the IOTP Messages which are physically sent in the form of 1354 [XML] documents between the different Trading Roles, 1355 o how IOTP Messages are exchanged between Trading Roles to 1356 create an IOTP Transaction 1357 o the XML definitions of an IOTP Message including a Transaction 1358 Reference Block - an XML element which identifies an IOTP 1359 Transaction and the IOTP Message within it 1360 o the definitions of the XML ID Attributes which are used to 1361 identify IOTP Messages, Trading Blocks and Trading Components 1362 and how these are referred to using Element References from 1363 other XML elements such as 1364 o IOTP Signature Components which use digital signature 1365 techniques to preserve the integrity of IOTP Messages and 1366 provide the trust relationships required by IOTP 1367 o how extra XML Elements and new user defined values for 1368 existing IOTP codes can be used when Extending IOTP, and 1369 finally 1371 3.1 Overview 1373 3.1.1 IOTP Message Structure 1375 The structure of an IOTP Message and its relationship with Trading 1376 Blocks and Trading Components is illustrated in the diagram below. 1378 OTP MESSAGE <----------- OTP Message - an XML Document which is 1379 | transported between the Trading Roles 1380 |-Trans Ref Block <----- Trans Ref Block - contains information which 1381 | | describes the OTP Transaction and the OTP 1382 | | Message. 1383 | |-Trans Id Comp. <--- Transaction Id Component - uniquely 1384 | | identifies the OTP Transaction. The Trans Id 1385 | | Components are the same across all OTP 1386 | | messages that comprise a single OTP 1387 | | transaction. 1388 | |-Msg Id Comp. <----- Message Id Component - identifies and 1389 | describes an OTP Message within an OTP 1390 | Transaction 1391 |-Signature Block <----- Signature Block (optional) - contains one or 1392 | | more Signature Components and their 1393 | | associated Certificates 1394 | |-Signature Comp. <-- Signature Component - contains digital 1395 | | signatures. Signatures may sign hashes of the 1396 | | Trans Ref Block and any Trading Component in 1397 | | any OTP Message in the same OTP Transaction. 1398 | |-Certificate Comp. < Certificate Component. Used to check the 1399 | signature. 1400 |-Trading Block <------- Trading Block - an XML Element within an OTP 1401 | |-Component Message that contains a predefined set of 1402 | |-Component Trading Components 1403 | |-Component 1404 | |-Component <-------- Trading Components - XML Elements within a 1405 | Trading Block that contain a predefined set 1406 |-Trading Block of XML elements and attributes containing 1407 | |-Component information required to support a Trading 1408 | |-Component Exchange 1409 | |-Component 1410 | |-Component 1411 | |-Component 1412 | 1413 | 1415 Figure 6 IOTP Message Structure 1417 The diagram also introduces the concept of a Transaction Reference 1418 Block. This block contains, amongst other things, a globally unique 1419 identifier for the IOTP Transaction. Also each block and component is 1420 given an ID Attribute (see section 3.4) which is unique within an IOTP 1421 Transaction. Therefore the combination of the ID attribute and the 1422 globally unique identifier in the Transaction Reference Block is 1423 sufficient to uniquely identify any Trading Block or Trading 1424 Component. 1426 3.1.2 IOTP Transactions 1428 A predefined set of IOTP Messages exchanged between the Trading Roles 1429 constitute an IOTP Transaction. This is illustrated in the diagram 1430 below. 1432 CONSUMER MERCHANT 1433 Generate first 1434 OTP Message 1435 --- | 1436 | | v 1437 Process incoming | I | ------------- 1438 OTP Message & <------------- | | -------------- | OTP Message | 1439 generate next OTP | | ------------- 1440 Message | N | 1441 | | | 1442 v | | 1443 ------------- | T | Process incoming 1444 | OTP Message | -------------- | | -------------> OTP Message & 1445 ------------- | | generate next OTP 1446 | E | Message 1447 | | | 1448 | | v 1449 Process incoming | R | ------------- 1450 OTP Message <------------- | | -------------- | OTP Message | 1451 generate last OTP | | ------------- 1452 Message & stop | N | 1453 | | | 1454 v | | 1455 ------------- | E | Process last 1456 | OTP Message | -------------- | | -------------> incoming OTP 1457 ------------- | | Message & stop 1458 | | T | | 1459 v | | v 1460 STOP --- STOP 1462 Figure 7 An IOTP Transaction 1464 In the above diagram the Internet is shown as the transport mechanism. 1465 This is not necessarily the case. IOTP Messages can be transported 1466 using a variety of transport mechanisms. 1468 The IOTP Transactions (see section 8) in this version of IOTP are 1469 specifically: 1470 o Purchase. This supports a purchase involving an offer, a 1471 payment and optionally a delivery 1473 o Refund. This supports the refund of a payment as a result of, 1474 typically, an earlier purchase 1475 o Value Exchange. This involves two payments which result in the 1476 exchange of value from one combination of currency and payment 1477 method to another 1478 o Authentication. This supports the remote authentication of a 1479 Consumer by another Trading Role using a variety of 1480 authentication methods, and the provision of an Organisation 1481 Component about a Consumer to another Trading Role for use in, 1482 for example the creation of an offer 1483 o Withdrawal. This supports the withdrawal of electronic cash 1484 from a financial institution 1485 o Deposit. This supports the deposit of electronic cash at a 1486 financial institution 1487 o Payment Instrument Customer Care. This supports the provision 1488 of Payment Brand or Payment Method specific customer care of a 1489 Payment Instrument 1490 o Inquiry This supports inquiries on the status of an IOTP 1491 transaction which is either in progress or is complete 1492 o Ping This supports a simple query which enables one IOTP aware 1493 application to determine whether another IOTP application 1494 running elsewhere is working or not. 1496 3.2 IOTP Message 1498 As described earlier, IOTP Messages are [XML] documents which are 1499 physically sent between the different organisations that are taking 1500 part in a trade. 1502 The XML definition of an IOTP Message is as follows. 1504 1525 Content: 1527 TransRefBlk This contains information which describes an 1528 IOTP Message within an IOTP Transaction (see 1529 section 3.3 immediately below) 1531 AuthReqBlk, These are the Trading Blocks. 1532 AuthRespBlk, 1533 DeliveryReqBlk, The Trading Blocks present within an IOTP 1534 DeliveryRespBlk Message, and the content of a Trading Block 1535 ErrorBlk itself is dependent on the type of IOTP 1536 InquiryReqBlk, Transaction being carried out - see the 1537 InquiryRespBlk, definition of each transaction in section 8 Open 1538 OfferRespBlk, Trading Protocol Transactions. 1539 PayExchBlk, 1540 PayReqBlk, Full definitions of each Trading Block are 1541 PayInstCCExchBlk, described in section 7. 1542 PayInstCCReqBlk, 1543 PayInstCCRespBlk 1544 PayRespBlk, 1545 PingReqBlk, 1546 PingRespBlk, 1547 SigBlk, 1548 TpoBlk, 1549 TpoSelectionBlk 1550 3.2.1 XML Document Prolog 1552 The IOTP Message is the root element of the XML document. It therefore 1553 needs to be preceded by an appropriate XML Document Prolog. For 1554 example: 1556 1557 1558 1559 ... 1560 1562 3.3 Transaction Reference Block 1564 A Transaction Reference Block contains information which identifies 1565 the IOTP Transaction and IOTP Message. The Transaction Reference Block 1566 contains: 1567 o a Transaction Id Component which globally uniquely identifies 1568 the IOTP Transaction. The Transaction Id Components are the 1569 same across all IOTP messages that comprise a single IOTP 1570 transaction, 1571 o a Message Id Component which provides control information 1572 about the IOTP Message as well as uniquely identifying the 1573 IOTP Message within an IOTP Transaction, and 1574 o zero or more Related To Components which link this IOTP 1575 Transaction to either other IOTP Transactions or other events 1576 using the identifiers of those events. 1578 The definition of a Transaction Reference Block is as follows: 1580 1581 1584 Attributes: 1586 ID An identifier which uniquely identifies the 1587 Transaction Reference Block within the IOTP 1588 Transaction (see section 3.4 ID Attributes). 1590 Content: 1592 TransId See 3.3.1 Transaction Id Component immediately 1593 below. 1595 MsgId See 3.3.2 Message Id Component immediately below. 1597 RelatedTo See 3.3.3 Related To Component immediately below. 1599 3.3.1 Transaction Id Component 1601 This contains information which globally uniquely identifies the IOTP 1602 Transaction. Its definition is as follows: 1604 1605 1610 TransTimeStamp CDATA #REQUIRED > 1612 Attributes: 1614 ID An identifier which uniquely identifies the 1615 Transaction Id Component within the IOTP 1616 Transaction. 1618 Version This identifies the version of IOTP, and therefore 1619 the structure of the IOTP Messages, which the IOTP 1620 Transaction is using. 1622 OtpTransId Contains data which uniquely identifies the IOTP 1623 Transaction. It must conform to the rules for 1624 Message Ids in [RFC 822]. 1626 OtpTransType This is the type of IOTP Transaction being carried 1627 out. For Baseline IOTP it identifies a "standard" 1628 IOTP Transaction and implies the sequence and 1629 content of the IOTP Messages exchanged between the 1630 Trading Roles. The valid values for Baseline IOTP 1631 are: 1632 o BaselineAuthentication 1633 o BaselineDeposit 1634 o BaselinePurchase 1635 o BaselineRefund 1636 o BaselineWithdrawal 1637 o BaselineValueExchange 1638 o BaselineInquiry 1639 o BaselinePing 1640 o BaselinePayInstrumentCustomerCare 1641 o x-ddd:nnn 1643 A value for OtpTransType of x-ddd:nnn indicates a 1644 user defined transaction type. See section 3.7.3 1645 User Defined Codes. 1647 In later versions of IOTP, this list will be 1648 extended to support different types of standard 1649 IOTP Transaction based on market demand. It is 1650 also likely to support the type Dynamic which 1651 indicates that the sequence of steps within the 1652 transaction are non-standard. 1654 TransTimeStamp Where the system initiating the IOTP Transaction 1655 has an internal clock, it is set to the time at 1656 which the IOTP Transaction started in [UTC] 1657 format. 1659 The main purpose of this attribute is to provide 1660 an alternative way of identifying a transaction by 1661 specifying the time at which it started. 1663 Some systems, for example, hand held devices may 1664 not be able to generate a time stamp. In this 1665 case this attribute should contain the value "NA" 1666 for Not Available. 1668 3.3.2 Message Id Component 1670 The Message Id Component provides control information about the IOTP 1671 Message as well as uniquely identifying the IOTP Message within an 1672 IOTP Transaction. Its definition is as follows. 1674 1675 1682 Attributes: 1684 ID An identifier which uniquely identifies the IOTP 1685 Message within the IOTP Transaction (see section 1686 3.4 ID Attributes). Note that if an IOTP Message 1687 is resent then the value of this attribute remains 1688 the same. 1690 RespOtpMsg This contains the ID attribute of the Message Id 1691 Component of the IOTP Message to which this IOTP 1692 Message is a response. In this way all the IOTP 1693 Messages in an IOTP Transaction are unambiguously 1694 linked together. This field is required on every 1695 IOTP Message except the first IOTP Message in an 1696 IOTP Transaction. 1698 xml:lang Defines the language used by attributes or child 1699 elements within this component, unless overridden 1700 by an xml:lang attribute on a child element. See 1701 section 3.9 Identifying Languages. 1703 SoftwareId This contains information which identifies the 1704 software which generated the IOTP Message. Its 1705 purpose is to help resolve interoperability 1706 problems that might occur as a result of 1707 incompatibilities between messages produced by 1708 different software. It is a single text string in 1709 the language defined by xml:lang. It must contain, 1710 as a minimum: 1711 o the name of the software manufacturer 1712 o the name of the software 1713 o the version of the software, and 1714 o the build of the software 1716 TimeStamp Where the device sending the message has an 1717 internal clock, it is set to the time at which the 1718 IOTP Message was created in [UTC] format. 1720 3.3.3 Related To Component 1722 The Related To Component links IOTP Transactions to either other IOTP 1723 Transactions or other events using the identifiers of those events. 1724 Its definition is as follows. 1726 1727 1734 Attributes: 1736 ID An identifier which uniquely identifies the 1737 Related To Component within the IOTP Transaction. 1739 xml:lang Defines the language used by attributes or child 1740 elements within this component, unless overridden 1741 by an xml:lang attribute on a child element. See 1742 section 3.9 Identifying Languages. 1744 RelationshipType Defines the type of the relationship. Valid values 1745 are: 1746 o OtpTransaction. in which case the Packaged 1747 Content Element contains an OtpTransId of 1748 another IOTP Transaction 1749 o Reference in which case the Packaged Content 1750 Element contains the reference of some other, 1751 non-IOTP document. 1752 o x-ddd:nnn a user defined code (see section 1753 3.7.3) 1755 Relation The Relation attribute contains a phrase in the 1756 language defined by xml:lang which describes the 1757 nature of the relationship between the IOTP 1758 transaction that contains this component and 1759 another IOTP Transaction or other event. The exact 1760 words to be used are left to the implementer of 1761 the IOTP software. 1763 The purpose of the attribute is to provide the 1764 Trading Roles involved in an IOTP Transaction with 1765 an explanation of the nature of the relationship 1766 between the transactions. 1768 Care should be taken that the words used to in the 1769 Relation attribute indicate the "direction" of the 1770 relationship correctly. For example: one 1771 transaction might be a refund for another earlier 1772 transaction. In this case the transaction which is 1773 a refund should contain in the Relation attribute 1774 words such as "refund for" rather than "refund to" 1775 or just "refund". 1777 RelnKeyWords This attribute contains keywords which could be 1778 used to help identify similar relationships, for 1779 example all refunds. It is anticipated that 1780 recommended keywords will be developed through 1781 examination of actual usage. In this version of 1782 the specification there are no specific 1783 recommendations and the keywords used are at the 1784 discretion of the implementer. 1786 Content: 1788 PackagedContent The Packaged Content (see section 3.8) contains 1789 data which identifies the related transaction. Its 1790 format varies depending on the value of the 1791 RelationshipType. 1793 3.4 ID Attributes 1795 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading 1796 Blocks), Trading Components (including the Transaction Id Component 1797 and the Signature Component) and some of their child elements are each 1798 given an XML "ID" attribute which is used to identify an instance of 1799 these XML elements. These identifiers are used so that one element can 1800 be referenced by another. All these attributes are given the attribute 1801 name ID. 1803 The values of each ID attribute are unique within an IOTP transaction 1804 i.e. the set of IOTP Messages which have the same globally unique 1805 Transaction ID Component. Also, once the ID attribute of an element 1806 has been assigned a value it is never changed. This means that 1807 whenever an element is copied, the value of the ID attribute remains 1808 the same. 1810 As a result it is possible to use these IDs to refer to and locate the 1811 content of any IOTP Message, Block or Component from any other IOTP 1812 Message, Block or Component in the same IOTP Transaction using Element 1813 References (see section 3.5). 1815 This section defines the rules for setting the values for the ID 1816 attributes of IOTP Messages Blocks and Components. 1818 3.4.1 IOTP Message ID Attribute Definition 1820 The ID attribute of the Message Id Component of an IOTP Message must 1821 be unique within an IOTP Transaction. It's definition is as follows: 1823 OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix 1824 OtpMsgIdPrefix ::= NameChar (NameChar)* 1825 OtpMsgIdSuffix ::= Digit (Digit)* 1827 OtpMsgIdPrefix Apart from messages which contain an Inquiry 1828 Request Trading Block (see section 7.14), the same 1829 prefix is used for all messages sent by the 1830 Merchant or Consumer role as follows: 1831 o "M" - Merchant 1832 o "C" - Consumer 1834 For messages which contain an Inquiry Request 1835 Trading Block, the prefix is set to "I" for 1836 Inquiry. 1838 The prefix for the other roles in a trade is 1839 contained within the Organisation Component for 1840 the role and are typically set by the Merchant. 1841 The following is recommended as a guideline and 1842 must not be relied upon: 1843 o "P" - First (only) Payment Handler 1844 o "R" - Second Payment Handler 1845 o "D" - Delivery Handler 1847 As a guideline, prefixes should be limited to one 1848 character. 1850 NameChar has the same definition as the [XML] 1851 definition of NameChar. 1853 OtpMsgIdSuffix The suffix consists of one or more digits. The 1854 suffix must be unique within a Trading Role within 1855 an IOTP Transaction. The following is recommended 1856 as a guideline and must not be relied upon: 1857 o the first IOTP Message sent by a trading role 1858 is given the suffix "1" 1859 o the second and subsequent IOTP Messages sent by 1860 the same trading role are incremented by one for 1861 each message 1862 o no leading zeroes are included in the suffix 1864 Put more simply the Message Id Component of the 1865 first IOTP Message sent by a Consumer would have 1866 an ID attribute of, "C1", the second "C2", the 1867 third "C3" etc. 1869 Digit has the same definition as the [XML] 1870 definition of Digit. 1872 3.4.2 Block and Component ID Attribute Definitions 1874 The ID Attribute of Blocks and Components must also be unique within 1875 an IOTP Transaction. Their definition is as follows: 1877 BlkOrCompId_value ::= OtpMsgId "." IdSuffix 1878 IdSuffix ::= Digit (Digit)* 1880 OtpMsgId The ID attribute of the Message ID Component of 1881 the IOTP Message where the Block or Component is 1882 first used. 1884 In IOTP, Trading Components and Trading Blocks are 1885 copied from one IOTP Message to another. The ID 1886 attribute does not change when an existing Trading 1887 Block or Component is copied to another IOTP 1888 Message. 1890 IdSuffix The suffix consists of one or more digits. The 1891 suffix must be unique within the ID attribute of 1892 the Message ID Component used to generate the ID 1893 attribute. The following is recommended as a 1894 guideline and must not be relied upon: 1895 o the first Block or Component sent by a trading 1896 role is given the suffix "1" 1897 o the ID attributes of the second and subsequent 1898 Blocks or Components are incremented by one for 1899 each new Block or Component added to an IOTP 1900 Message 1901 o no leading zeroes are included in the suffix 1903 Put more simply, the first new Block or Component 1904 added to the second IOTP Message sent, for 1905 example, by a consumer would have a an ID 1906 attribute of "C2.1", the second "C2.2", the third 1907 "C2.3" etc. 1909 Digit has the same definition as the [XML] 1910 definition of Digit. 1912 3.4.3 Example of use of ID Attributes 1914 The diagram below illustrates how ID attribute values are used. 1916 1st OTP MESSAGE 2nd OTP MESSAGE 1917 (e.g. from Merchant to (e.g. from Consumer to 1918 Consumer Payment Handler) 1920 OTP MESSAGE OTP MESSAGE * 1921 |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* 1922 | |-Trans Id Comp. ID = M1. ------------->| |-Trans Id Comp. 1923 | | Copy Element | | ID=M1.2 1924 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * 1925 | | 1926 |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* 1927 | |-Sig Comp. ID=M1.15 ---- ------------->| |-Comp. ID=M1.15 1928 | Copy Element | 1929 |-Trading Block. ID=M1.3 |-Trading Block. ID=C1.2 * 1930 | |-Comp. ID=M1.4 --------- ---------------->|-Comp. ID=M1.4 1931 | | Copy Element | 1932 | |-Comp. ID=M1.5 --------- ---------------->|-Comp. ID=M1.5 1933 | | Copy Element | 1934 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * 1935 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * 1936 | 1937 |-Trading Block. ID=M1.3 1938 |-Comp. ID=M1.4 * = new elements 1939 |-Comp. ID=M1.5 1940 |-Comp. ID=M1.6 1941 |-Comp. ID=M1.7 1943 Figure 8 Example use of ID attributes 1945 3.5 Element References 1947 A Trading Component or one of its child XML elements, may contain an 1948 XML attribute that refers to another Block (i.e. a Transaction 1949 Reference Block or a Trading Block) or Trading Component (including a 1950 Transaction Id and Signature Component). These Element References are 1951 used for many purposes, a few examples include: 1952 o identifying an XML element whose hash value is included in a 1953 Signature Component, 1954 o referring to the Payment Handler Organisation Component which 1955 is used when making a Payment 1957 An Element Reference always contains the value of an ID attribute of a 1958 Block or Component. 1960 Identifying the IOTP Message, Trading Block or Trading Component which 1961 is referred to by an Element Reference, involves finding the XML 1962 element which: 1963 o belongs to the same IOTP Transaction (i.e. the Transaction Id 1964 Components of the IOTP Messages match), and 1965 o where the value of the ID attribute of the element matches the 1966 value of the Element Reference. 1968 [Note] The term "match" in this specification has the same 1969 definition as the [XML] definition of match. 1970 [Note End] 1972 An example of "matching" an Element Reference is illustrated in the 1973 example below. 1975 1st OTP MESSAGE 2nd OTP MESSAGE 1976 (e.g. from Merchant to (e.g. from Consumer to 1977 Consumer Payment Handler) 1979 OTP MESSAGE OTP MESSAGE 1980 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans Ref Block. ID=C1.1 1981 | |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id Comp.ID=M1.2 1982 | | must be | | 1983 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 1984 | ^ | 1985 |-Signature Block. ID=M1.8 | |-Signature Block. ID=C1.5 1986 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 1987 | AND | 1988 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 1989 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 1990 | | v | 1991 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 1992 | | and El Ref | 1993 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 1994 | | match--------|--> El Ref=M1.6 1995 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 1996 | 1997 |-Trading Block. ID=M1.3 1998 |-Comp. ID=M1.4 1999 |-Comp. ID=M1.5 2000 |-Comp. ID=M1.6 2001 |-Comp. ID=M1.7 2003 Figure 9 Element References 2005 [Note] Element Reference attributes are defined as "NMTOKEN" rather 2006 than "IDREF" (see [XML]). This is because an IDREF requires 2007 that the XML element referred to is in the same XML 2008 Document. With IOTP this is not necessarily the case. 2009 [Note End] 2011 3.6 Brands and Brand Selection 2013 One of the key features of IOTP is the ability for a merchant to offer 2014 a list of Brands from which a consumer may make a selection. This 2015 section provides an overview of what is involved and provides guidance 2016 on how selection of a brand and associated payment instrument can be 2017 carried out by a Consumer. It covers: 2018 o definitions of Payment Instruments and Brands - what are 2019 Payment Instruments and Brands in an IOTP context. Further 2020 categorises Brands as optionally a "Dual Brand" or a 2021 "Promotional Brand", 2022 o identification and selection of Promotional Brands - 2023 Promotional Brands offer a Consumer some additional benefit, 2024 for example loyalty points or a discount. This means that both 2025 Consumers and Merchant must be able to correctly identify that 2026 a valid Promotional Brand is being used. 2028 Also see the following sections: 2029 o Brand List Component (section 6.6) which contains definitions 2030 of the XML elements which contain the list of Brands offered 2031 by a Merchant to a Consumer, and 2032 o Brand Selection Component (section 6.7) for details of how a 2033 Consumer records the Brand that was selected. 2035 3.6.1 Definition of Payment Instrument 2037 A Payment Instrument is the means by which Consumer pays for goods or 2038 services offered by a Merchant. It can be, for example: 2039 o a credit card such as MasterCard or Visa; 2040 o a debit card such as MasterCard's Maestro; 2041 o a smart card based electronic cash payment instrument such as 2042 a Mondex Card, a GeldKarte card or a Visa Cash card 2043 o a software based electronic payment account such as a 2044 CyberCash or DigiCash account. 2046 All Payment Instruments have a number, typically an account number, by 2047 which the Payment Instrument can be identified. 2049 3.6.2 Definition of Brand 2051 A Brand is the mark which identifies a particular type of Payment 2052 Instrument. A list of Brands are the payment options which are 2053 presented by the Merchant to the Consumer and from which the Consumer 2054 makes a selection. Each Brand may have a different Payment Handler. 2055 Examples of Brands include: 2056 o payment association and proprietary Brands, for example 2057 MasterCard, Visa, American Express, Diners Club, American 2058 Express, Mondex, GeldKarte, CyberCash, etc. 2059 o promotional brands (see below). These include: 2061 - store brands, where the Payment Instrument is issued to a 2062 Consumer by a particular Merchant, for example Walmart, Sears, 2063 or Marks and Spencer (UK) 2064 - cobrands, for example American Advantage Visa, where an 2065 organisation uses their own brand in conjunction with, 2066 typically, a payment association Brand. 2068 3.6.3 Definition of Dual Brand 2070 A Dual Brand means that a single payment instrument may be used as if 2071 it were two separate Brands. For example there could be a single 2072 Japanese "UC" MasterCard which can be used as either a UC card or a 2073 regular MasterCard. The UC card Brand and the MasterCard Brand could 2074 each have their own separate Payment Handlers. This means that: 2075 o the merchant treats, for example "UC" and "MasterCard" as two 2076 separate Brands when offering a list of Brands to the 2077 Consumer, 2078 o the consumer chooses a Brand, for example either "UC" or 2079 "MasterCard, 2080 o the consumer IOTP aware application determines which Payment 2081 Instrument(s) match the chosen Brand, and selects, perhaps 2082 with user assistance, the correct Payment Instrument to use. 2084 [Note] Dual Brands need no special treatment by the Merchant and 2085 therefore no explicit reference is made to Dual Brands in 2086 the DTD. This is because, as far as the Merchant is 2087 concerned, each Brand in a Dual Brand is treated as a 2088 separate Brand. It is at the Consumer, that the matching of 2089 a Brand to a Dual Brand Payment Instrument needs to be done. 2090 [Note End] 2092 3.6.4 Definition of Promotional Brand 2094 A Promotional Brand means that, if the Consumer pays with that Brand, 2095 then the Consumer will receive some additional benefit which can be 2096 received in two ways: 2097 o at the time of purchase. For example if a Consumer pays with a 2098 "Walmart MasterCard" at a Walmart web site, then a 5% discount 2099 might apply, which means the consumer actually pays less, 2100 o from their Payment Instrument (card) issuer when the payment 2101 appears on their statement. For example loyalty points in a 2102 frequent flyer scheme could be awarded based on the total 2103 payments made with the Payment Instrument since the last 2104 statement was issued. 2106 Note that: 2107 o the first example (obtaining the benefit at the time of 2108 purchase), requires that: 2109 - the Consumer is informed of the benefits which arise if that 2110 Brand is selected 2112 - if the Brand is selected, the Merchant changes the relevant IOTP 2113 Components in the Offer Response to reflect the correct amount 2114 to be paid 2115 o the second (obtaining a benefit through the Payment Instrument 2116 issuer) does not require that the Offer Response is changed 2117 o each Promotional Brand should be identified as a separate 2118 Brand in the list of Brands offered by the Merchant. For 2119 example: "Walmart", "Sears", "Marks and Spencer" and "American 2120 Advantage Visa", would each be a separate Brand. 2122 3.6.5 Identifying Promotional Brands 2124 There are two problems which need to handled in identifying 2125 Promotional Brands: 2126 o how does the Merchant or their Payment Handler positively 2127 identify the promotional brand being used at the time of 2128 purchase 2129 o how does the Consumer reliably identify the correct 2130 promotional brand from the Brand List presented by the 2131 Merchant 2133 The following is a description of how this could be achieved. 2135 [Note] Please note that the approach described here is a model 2136 approach that solves the problem. Other equivalent methods 2137 may be used. 2138 [Note End] 2140 3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands 2142 Correct identification that the Consumer is paying using a Promotional 2143 Brand is important since a Consumer might fraudulently claim to have a 2144 Promotional Brand that offers a reduced payment amount when in reality 2145 they do not. 2147 Two approaches seem possible: 2148 o use some feature of the Payment Instrument or the payment 2149 method to positively identify the Brand being used. For 2150 example, the SET certificate for the Brand could be used, if 2151 one is available, or 2152 o use the Payment Instrument (card) number to look up 2153 information about the Payment Instrument on a Payment 2154 Instrument issuer database to determine if the Payment 2155 Instrument is a promotional brand 2157 Note that: 2158 o the first assumes that SET is available. 2159 o the second is only possible if the Merchant, or alternatively 2160 the Payment Handler, has access to card issuer information. 2162 IOTP does not provide the Merchant with Payment Instrument information 2163 (e.g. a card or account number). This is only sent as part of the 2164 encapsulated payment protocol to a Payment Handler. This means that: 2165 o the Merchant would have to assume that the Payment Instrument 2166 selected was a valid Promotional Brand, or 2167 o the Payment Handler would have to check that the Payment 2168 Instrument was for the valid Promotional Brand and fail the 2169 payment if it was not. 2171 A Payment Handler checking that a brand is a valid Promotional Brand 2172 is most likely if the Payment Handler is also the Card Issuer. 2174 3.6.5.2 Consumer Selection of Promotional Brands 2176 Two ways by which a Consumer can correctly select a Promotional Brand 2177 are: 2178 o the Consumer visually matching a logo for the Promotional 2179 Brand which has been provided to the Consumer by the Merchant, 2180 o the Consumer's IOTP aware application matching a code for the 2181 Promotional Brand which the application has registered against 2182 a similar code contained in the list of Brands offered by the 2183 Merchant. 2185 In the latter case, the code contained in the Consumer wallet must 2186 match exactly the code in the list offered by the Merchant otherwise 2187 no match will be found. Ways in which the Consumer's IOTP Aware 2188 Application could obtain such a code include: 2189 o the Consumer types the code in directly. This is error prone 2190 and not user friendly, also the consumer needs to be provided 2191 with the code. This approach is not recommended, 2192 o using some information contained in the software or other data 2193 associated with the Payment Instrument. This could be: 2194 - a SET certificate for Brands which use this payment method 2195 - a code provided by the payment software which handles the 2196 particular payment method, this could apply to, for example, 2197 GeldKarte, Mondex, CyberCash and DigiCash 2198 o the consumer making a initial "manual" link between a 2199 Promotional Brand in the list of Brands offered by the 2200 Merchant and an individual Payment Instrument, the first time 2201 the promotional brand is used. The IOTP Aware application 2202 would then "remember" the code for the Promotional Brand for 2203 use in future purchases 2205 [Note] It is not the intention of the developers of this 2206 specification to develop a prescriptive list of payment 2207 brands. It is anticipated that owners of brands will develop 2208 distinctive names for Brands which should mean that name 2209 clashes are unlikely. 2210 [Note End] 2212 3.7 Extending IOTP 2214 Baseline IOTP defines a minimum protocol which systems supporting IOTP 2215 must be able to accept. As new versions of IOTP are developed, 2216 additional types of IOTP Transactions will be defined. In addition to 2217 this, Baseline and future versions of IOTP will support user 2218 extensions to IOTP through two mechanisms: 2219 o extra XML elements, and 2220 o new user-defined values for existing IOTP codes. 2222 3.7.1 Extra XML Elements 2224 The XML element and attribute names used within IOTP constitute an 2225 [XML Namespace]. This allows IOTP to support the inclusion of 2226 additional XML elements within IOTP messages through the use of [XML 2227 Namespaces]. 2229 [Note] In drafts of the [XML] specification, the concept of 2230 "Namespaces" have been discussed. However they are not 2231 present in the XML documentation submitted for approval (see 2232 XML draft dated 8 December 1997) although it appears as if 2233 they may be included in version 1.1 of XML. It is considered 2234 by the authors of this document that IOTP would be an ideal 2235 example of a Namespace so that other XML elements with 2236 potentially the same name can be included unambiguously in 2237 XML documents which conform to this specification. If 2238 Namespaces, or an equivalent, is not developed for XML as a 2239 whole then IOTP is likely to propose its own equivalent. The 2240 Views of other organisations on this topic are sought. 2241 [Note End] 2243 Extra XML elements may be included at any level within an IOTP message 2244 including: 2245 o new Trading Blocks 2246 o new Trading Components 2247 o new XML elements within a Trading Component. 2249 The following rules apply: 2250 o any new XML element must be declared according to the rules 2251 for [XML Namespaces]. This means that: 2252 - the namespace must be declared to the XML parser 2253 - each element must have a start and end tags which conform to the 2254 rules for XML Namespaces 2255 o new XML elements which are either Trading Blocks or Trading 2256 Components must contain an ID attributes with an attribute 2257 name of ID. 2259 In order to make sure that extra XML elements can be processed 2260 properly, IOTP reserves the use of a special attribute, IOTP:Critical, 2261 which takes the values True or False and may appear in extra elements 2262 added to an IOTP message. 2264 The purpose of this attribute is to allow an IOTP aware application to 2265 determine if the IOTP transaction can safely continue. Specifically: 2266 o if an extra XML element has an "IOTP:Critical" attribute with 2267 a value of "True" and an IOTP aware application does not know 2268 how to process the element and its child elements, then the 2269 IOTP transaction must fail. See section 6.19 Error Component. 2270 o if an extra XML element has an "IOTP:Critical" attribute with 2271 a value of "False" then the IOTP transaction may continue if 2272 the IOTP aware application does not know how to process it. In 2273 this case: 2274 - any extra XML elements contained within an XML element defined 2275 within the IOTP namespace, must be included with that element 2276 whenever the IOTP XML element is used or copied by IOTP 2277 - the content of the extra element must be ignored except that it 2278 must be included when it is hashed as part of the generation of 2279 a signature 2280 o if an extra XML element has no "IOTP:Critical" attribute then 2281 it must be treated as if it had an "IOTP:Critical" attribute 2282 with a value of "True" 2283 o if an XML element contains an "IOTP:Critical" attribute, then 2284 the value of that attribute is assumed to apply to all the 2285 child elements within that element 2287 In order to ensure that documents containing "IOTP:Critical" are 2288 valid, it is declared as part of the DTD for the extra element as: 2290 IOTP:Critical (True | False ) #TRUE 2292 3.7.2 Opaque Embedded Data 2294 If IOTP is to be extended using Opaque Embedded Data then a Packaged 2295 Content Element (see section 3.8) should be used to encapsulate the 2296 data. 2298 3.7.3 User Defined Codes 2300 User defined codes provide a simple way to identify additional values 2301 for the codes contained within this specification. 2303 The definition of a user defined code is as follows: 2305 user_defined_code ::= ( "x-" | "X-" ) domain_name ":" name 2307 domain_name A name which identifies the organisation which is 2308 creating the user defined code (see [DNS]). The 2309 purpose of this field is to reduce the probability of 2310 two organisations creating the same user-defined name 2312 name A name specified by the organisation which owns the 2313 domain_name which identifies the user defined code 2314 within the domain_name. 2316 User defined codes are identified in this specification as "x- 2317 ddd:nnn". The values of User Defined Codes must conform to the rules 2318 for the specific code (see explanations of the individual codes). 2320 3.8 Packaged Content Element 2322 The Packaged Content element supports the concept of an embedded data 2323 stream, transformed to both protect it against misinterpretation by 2324 transporting systems and to ensure XML compatibility. Examples of its 2325 use in IOTP include: 2326 o to encapsulate payment scheme messages, such as SET messages, 2327 o to encapsulate a description of an order. 2329 In general it is used to encapsulate any data stream. 2331 This data stream has two standardised attributes that allow for 2332 decoding and interpretation of the contents. Its definition is as 2333 follows. 2335 2336 2340 Attributes: 2342 Content This identifies what type of data is contained 2343 within the Content of the Packaged Content 2344 Element. The valid values for the Content 2345 attribute are as follows: 2346 o PCDATA.The content of the Packaged Content 2347 Element can be treated as PCDATA with no further 2348 processing. 2349 o MIME. The content of the Packaged Content 2350 Element is a complete MIME item. Processing 2351 should include looking for MIME headers inside 2352 the Packaged Content Element. 2353 o MIME:mimetype. The content of the Packaged 2354 Content Element is MIME content, with the 2355 following header "Content-Type: mimetype". 2356 Although it is possible to have MIME:mimetype 2357 with the Transform attribute set to NONE, it is 2358 far more likely to have Transform attribute set 2359 to BASE64. Note that if Transform is NONE is 2360 used, then the entire content must still conform 2361 to PCDATA. Some characters will need to be 2362 encoded either as the XML default entities, or 2363 as numeric character entities. 2364 o XML. The content of the Packaged Content 2365 Element can be treated as an XML document. 2366 Entities and CDATA sections, or Transform set to 2367 BASE64, must be used to ensure that the Packaged 2368 Content Element contents are legitimate PCDATA. 2369 o x-ddd:usercode. The content is private, where 2370 ddd represents a domain name of a user, and 2371 usercode represents a particular content format 2372 defined by that user. The guidelines around a x- 2373 ddd are very loose. Given company FFGGHH Inc., 2374 all of x-www.ffgghh.com, x-ffgghh.comand and 2375 x-ffgghh are legitimate examples. However, only 2376 one should be the correct format, as defined by 2377 FFGGHH Inc. 2379 Transform This identifies the transformation that has been 2380 done to the data before it was placed in the 2381 content. Valid values are: 2382 o NONE. The PCDATA content of the Packaged 2383 Content Element is the correct representation of 2384 the data. Note that entity expansion must occur 2385 first (i.e. replacement of & and ) 2386 before the data is examined. CDATA sections may 2387 legitimately occur in a Packaged Content Element 2388 where the Transform attribute is set to NONE. 2389 o BASE64. The PCDATA content of the Packaged 2390 Content Element represents a BASE64 encoding of 2391 the actual content. 2393 Content: 2395 PCDATA This is the actual data which has been embedded. 2396 The format of the data and rules on how to decode 2397 it are contained in the Content and the Transform 2398 attributes 2400 Note that any special details, especially custom attributes, must be 2401 represented at a higher level. 2403 3.9 Identifying Languages 2405 IOTP uses [XML] Language Identification to specify which languages are 2406 used within the content and attributes of IOTP Messages. 2408 The following principles have been used in order to determine which 2409 XML elements contain an xml:lang Attributes: 2410 o a mandatory xml:lang attribute is contained on every Trading 2411 Component which contains attributes or content which may need 2412 to be displayed or printed in a particular language 2413 o an optional xml:lang attribute is included on child elements 2414 of these Trading Components. In this case the value of 2415 xml:lang, if present, overrides the value for the Trading 2416 Component. 2418 xml:lang attributes which follow these principles are included in the 2419 Trading Components and their child XML elements defined in section 6. 2421 3.10 Secure and Insecure Net Locations 2423 IOTP contains several "Net Locations" which identify places where, 2424 typically, IOTP Messages may be sent. Net Locations come in two types: 2425 o "Secure" Net Locations which are net locations where privacy 2426 of data is secured using, for example, encryption methods such 2427 as [SSL], and 2428 o "Insecure" Net Locations where privacy of data is not assured. 2430 Where both types of net location are present, the following rules 2431 apply: 2432 o either a Secure Net Location or an Insecure Net Location or 2433 both must be present 2434 o if only one of the two Net Locations is present, then the one 2435 present must be used 2436 o if both are present, then the either may be used depending on 2437 preference the preference of the sender of the message. 2439 4. IOTP Error Handling 2441 IOTP is designed as a request/response protocol where each message is 2442 composed of a number of Trading Blocks which contain a number of 2443 Trading Components. There are a several interrelated considerations in 2444 handling errors, re-transmissions, duplicates, and the like. These 2445 factors mean IOTP aware applications must manage message flows more 2446 complex than the simple request/response model. Also a wide variety of 2447 errors can occur in messages as well as at the transport level or in 2448 Trading Blocks or Components. 2450 This section describes at a high level how IOTP handles errors, 2451 retries and idempotency. It covers: 2452 o the different types of errors which can occur. This is divided 2453 into: 2454 - "technical errors" which are independent of the meaning of the 2455 IOTP Message, 2456 - "business errors" which indicate that there is a problem 2457 specific to the process (payment or delivery) which is being 2458 carried out, and 2459 o the depth of the error which indicates whether the error is at 2460 the transport, message or block/component level 2461 o how the different trading roles should handle the different 2462 types of messages which they may receive. 2464 4.1 Technical Errors 2466 Technical errors are those which are independent of the meaning of the 2467 message. This means, they can affect any attempt at IOTP 2468 communication. Typically they are handled in a standard fashion with a 2469 limited number of standard options for the user. Specifically these 2470 are: 2471 o retrying the transmission, or 2472 o cancelling the transaction. 2474 When communications are operating sufficiently well, a technical error 2475 is indicated by an Error Component (see section 6.19) in an Error 2476 Block (see section 7.19) sent by the party which detected the error in 2477 an IOTP message to the party which sent the erroneous message. 2479 If communications too poor, a message which was sent may not reach its 2480 destination. In this case a time-out might occur. 2482 The Error codes associated with Technical Errors are recorded in Error 2483 Components (see section 6.19) which lists all the different technical 2484 errors which can be set. 2486 4.2 Business Errors 2488 Business errors may occur when the IOTP messages are "technically" 2489 correct. They are connected with a particular process, for example, an 2490 offer, payment, delivery or authentication where each process has a 2491 different set of possible business errors. 2493 For example, "Insufficient funds" is a reasonable payment error but 2494 makes no sense for a delivery while "Back ordered" is a reasonable 2495 delivery error but not meaningful for a payment. Business errors are 2496 indicated in the Status Component (see section 6.15) of a "response 2497 block" of the normal type, for example a Payment Response Block or a 2498 Delivery Response Block. This allows whatever additional response 2499 related information is needed to accompany the error indication. 2501 Business errors must usually be presented to the user so that they can 2502 decide what to do next. For example, if the error is insufficient 2503 funds in a Brand Independent Purchase (see section 8.3.1), the user 2504 might wish to choose a different payment instrument/account of the 2505 same brand or a different brand or payment system. Alternatively, if 2506 the IOTP based implementation allows it and it makes sense for that 2507 instrument, the user might want to put more funds into the 2508 instrument/account and try again. 2510 4.3 Error Depth 2512 The three levels at which IOTP errors can occur are the transport 2513 level, the message level, and the block level. Each is described 2514 below. 2516 4.3.1 Transport Level 2518 This level of error indicates a fundamental problem in the transport 2519 mechanism over which the IOTP communication is taking place. 2521 All transport level errors are technical errors and are indicated by 2522 either an explicit transport level error indication, such as a "No 2523 route to destination" error from TCP/IP, or by a time out where no 2524 response has been received to a request. 2526 The only reasonable automatic action when faced with transport level 2527 errors is to retry and, after some number of automatic retries, to 2528 inform the user. 2530 The explicit error indications that can be received are transport 2531 dependent and the documentation for appropriate IOTP Transport 2532 supplement should be consulted for errors and appropriate actions. 2534 Appropriate time outs to use are a function of both the transport 2535 being used and of the payment system if the request encapsulates 2536 payment information. The transport and payment system specific 2537 documentation should be consulted for time out and automatic retry 2538 parameters. Frequently there is no way to directly inform the other 2539 party of transport level errors but they should generally be logged 2540 and if automatic recovery is unsuccessful and there is a human user, 2541 the user should be informed. 2543 4.3.2 Message Level 2545 This level of error indicates a fundamental technical problem with an 2546 entire IOTP message. For example, the XML is not Well formed, or the 2547 message is too large for the receiver to handle or there are errors in 2548 the Transaction Reference Block (see section 3.3) so it is not 2549 possible to figure out what transaction the message relates to. 2551 All message level errors are technical errors and are indicated by an 2552 Error Component (see section 6.19) sent to the other party. The Error 2553 Component includes a Severity attribute which indicates whether the 2554 error is a Warning and may be ignored, a TransientError which 2555 indicates that a retry may resolve the problem or a HardError in which 2556 case the transaction must fail. 2558 The Technical Errors (see section 6.19.2 Error Codes) that are Message 2559 Level errors are: 2561 o XML not well formed. The document is not well formed XML (see 2562 [XML]) 2563 o XML not valid. The document is not valid XML (see [XML]) 2564 o block level technical errors (see section 4.3.3) on the 2565 Transaction Reference Block (see section 3.3) and the 2566 Signature Block only. This should only be carried out if the 2567 XML is valid 2569 Note that checks on the Signature Block includes checking, where 2570 possible, that each Signature Component is correctly calculated. If 2571 the Digital Signature Element is incorrectly calculated then the data 2572 that should have been covered by the signature can not be trusted and 2573 must be treated as erroneous. A description of how to check a 2574 signature is correctly calculate is contained in section 5.2 Checking 2575 a Signature is Correctly Calculated. 2577 4.3.3 4Block Level 2579 A Block level error indicates a problem with a block or one of its 2580 components in an IOTP message (apart from Transaction Reference or 2581 Signature Blocks). The message has been transported properly, the 2582 overall message structure and the block/component(s) including the 2583 Transaction Reference and Signature Blocks are meaningful but there is 2584 some error related to one of the other blocks. 2586 Block level errors can be either: 2587 o technical errors, or 2588 o business errors 2590 Technical Errors are further divided into: 2591 o Block Level Attribute and Element Checks, and 2592 o Block and Component Consistency Checks 2594 If a technical error occurs related to a block or component, then an 2595 Error Component is returned and, unless it is merely a warning, the 2596 usual response block is suppressed. 2598 4.3.3.1 Block Level Attribute and Element Checks 2600 Block Level Attribute and Element Checks occur only within the same 2601 block. Checks which involve cross-checking against other blocks are 2602 covered by Block and Component Consistency Checks. 2604 The Block Level Attribute & Element checks are: 2605 o checking that each attribute value within each element in a 2606 block conforms to any rules contained within this IOTP 2607 specification 2608 o checking that the content of each element conforms to any 2609 rules contained within this IOTP specification 2611 o if the previous checks are OK, then cross-checking attribute 2612 values and element content against other attribute values or 2613 element content within any other components in the same block. 2615 4.3.3.2 Block and Component Consistency Checks 2617 Block and Component Consistency Checks consist of: 2618 o checking that the combination of blocks and/or components 2619 present in the IOTP Message are consistent with the rules 2620 contained within this IOTP specification 2621 o checking for consistency between attributes and element 2622 content within the blocks within the same IOTP message. 2623 o checking for consistency between attributes and elements in 2624 blocks in this IOTP message and blocks received in earlier 2625 IOTP messages for the same IOTP transaction 2627 4.3.3.3 Block Business Errors 2629 If a business error occurs in a process such as a Payment or a 2630 Delivery, then the usual type of response block is returned. The 2631 Status Component (see section 6.15) within that response block 2632 indicates the error and its severity. No Error Component or Error 2633 Block is generated for business errors. 2635 4.4 Idempotency, Processing Sequence, and Message Flow 2637 IOTP messages are actually a combination of blocks and components as 2638 described in 3.1.1 IOTP Message Structure. Especially in future 2639 extensions of IOTP, a rich variety of combinations of such blocks and 2640 components can occur. It is important that the multiple 2641 transmission/receipt of the "same" request for state changing action 2642 not result in that action occurring more than once. This is called 2643 idempotency. For example, a customer paying for an order would want to 2644 pay the full amount only once. Most network transport mechanisms have 2645 some probability of delivering a message more than once or not at all, 2646 perhaps requiring retransmission. On the other hand, a request for 2647 status can reasonably be repeated and should be processed fresh each 2648 time it is received. 2650 Correct implementation of IOTP can be modelled by a particular 2651 processing order as detailed below. Any other method that is 2652 indistinguishable in the messages sent between the parties is equally 2653 acceptable. 2655 4.4.1 Server Role Processing Sequence 2657 "Server roles" are any Trading Role which is not the Consumer role. 2658 They are "Server roles" since they typically receive a request which 2659 they must service and then produce a response. 2661 The model processing sequence for a Server role is indicated in the 2662 diagram below. 2664 ------------- 2665 | Input | 2666 | OTP Message | 2667 ------------- 2668 | 2669 v 2670 1. Check for transport --------------> 2671 or message level errors Errors | 2672 |OK | 2673 v | 2674 11. Generate output <-------2. More Blocks <------------------ +- 2675 message No to process? | | 2676 | |Yes | | 2677 v v | | 2678 ------------- 3. Check Block OK ---------------> | | 2679 | Output | | Errors | | 2680 | OTP Message | |Checks OK | | 2681 ------------- v | | 2682 ----- ---4. Type of Block ? ------- | | 2683 | | | | | | 2684 ----- ---Status Action Encapsulating Error | | 2685 | Request Request Block Block | | 2686 | | | | | | 2687 | v v v | | 2688 | 6a. Action 7. Process 8.Error | | 2689 | Request - encapsulated Block ? | | 2690 | received message and | | | 2691 | before?-- generate -- v | | 2692 | | | response | STOP ---- | 2693 | |Yes |No OK| | | | 2694 | v v | |Errors v | 2695 | 6b. Processing 6e. Process Action | ------> 9. Gen | 2696 | of Block Request & generate-+--------->Error | 2697 | Complete ?- response block- | Errors Block & | 2698 | | | ^ | | store | 2699 | | | | | | | | 2700 | |Yes |No | Ok or | | | | 2701 | | --- | Warning | -------- | | 2702 v v v | v | | | 2703 5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | | 2704 Status and resend process request & | | | 2705 Response previous completion response | | | 2706 Block Block block | | | 2707 | | | v v | 2708 ---------------------------------------------- 10. Add block-- 2709 to output 2710 message 2712 Figure 10 Server Role Processing Sequence 2714 Each of the processes in the sequence is described in more detail 2715 below. 2717 4.4.1.1 Check for Transport or Message Level Error 2719 On receipt of an IOTP request message (step 1), first check for 2720 transport or message level errors (see sections 4.3.1 and 4.3.2). 2721 These are errors which indicate that the entire message is corrupt and 2722 can not reliably be associated with any particular transaction or, if 2723 it can be associated with a transaction, the interior information in 2724 the message can not be reliably accessed. 2726 If the OtpTransId attribute in the Transaction Id Component (see 2727 section 3.3.1) can be determined, set up a response message with an 2728 appropriate Error Component. Perform local actions such as making log 2729 entries. 2731 If the value of the OtpTransId attribute is not recognised as 2732 belonging to an IOTP transaction when other Blocks in the IOTP Message 2733 indicate that it should be recognised, then report the error using an 2734 Error Component with a Severity of HardError, an ErrorCode set to 2735 AttValNotRecog (attribute value not recognised), and an Error Location 2736 element (see section 6.19.3) that points to the OtpTransId attribute. 2738 No idempotency related actions are necessary. 2740 4.4.1.2 Process all the blocks 2742 If there are no message level errors, process each of the blocks 2743 within the message which has not been processed (step 2). 2745 Once all the blocks have been processed, generate a response message 2746 (step 11) and send it to the requester unless there are fatal 2747 transport level problems. As recommended for the particular transport 2748 used, a limited number of automatic response retransmission attempts 2749 may be appropriate. 2751 It may be desirable to log the complete response message at the 2752 server. Failure of the requester to receive a response may lead to a 2753 time-out and a retransmission of the request. Following the procedures 2754 above, a duplicate request message should produce a duplicate of the 2755 previous response except for changes in status and transient error 2756 conditions that have changed. 2758 4.4.1.3 Check the Block is OK 2760 Check the block is OK (see section 4.3.3). For each block level error 2761 found, an appropriate Error Component should be created to be included 2762 in the IOTP Message sent back to the Consumer. Note that some checking 2763 of the Transaction Reference Block and the Signature Block has 2764 occurred as part of Message Level error checking. 2766 If one or more of the Error Components contain a Severity attribute 2767 with a value of TransientError or HardError, then no response block 2768 need be generated and no further processing of the block, including 2769 idempotency related actions are necessary. 2771 4.4.1.4 Determine the Type of the Block 2773 Trading Blocks that survive the above steps and thus have no errors, 2774 or at worst have added a warning error component to the response, can 2775 receive further processing. The nature of the processing depends (step 2776 4) on whether the block is a Status Request, Action Request, an Error 2777 Block or contains an Encapsulated Message. 2779 4.4.1.5 Status Request Blocks 2781 Status Request Blocks (step 5) are either: 2782 o Inquiry Request Trading Block (see section 7.14), or 2783 o Ping Request Block (see section 7.16). 2785 These status requests do not change state and are processed fresh to 2786 get the current status. The appropriate response block should be added 2787 to the IOTP message being composed. 2789 No idempotency actions are required. 2791 4.4.1.6 Action Request Blocks 2793 Blocks which request an action and change state need to be subject to 2794 idempotency duplicate filtering by checking to see if the same block 2795 for the same transaction has been previously stored (step 6a) at the 2796 server as described later. 2798 If the Block has been received previously then: 2800 o if processing of the previously stored block is complete (step 2801 6b) then the same IOTP Block as previously produced must be 2802 included for resending to the Consumer (step 6c). 2803 o if processing is not complete, wait until the processing is 2804 complete (step 6d) before sending the response. 2806 If the block has not been received before, the action request is 2807 processed normally (step 6e) producing a response block that is added 2808 to the response message. This might or might not indicate a business 2809 error. 2811 If there is a transient error indicated by an Error Component that 2812 contains a Severity attribute set to TransientError, then apart from 2813 sending the Error Block, no further actions should be taken so the 2814 action can be retried. 2816 If there is no Transient Error, then the transaction id, the request 2817 block, and the response block must be stored (step 6f) so they can be 2818 found as described above (step 6a) should a duplicate IOTP action 2819 request block be received for this transaction in the future. 2821 [Note] Most business errors should be labelled as a TransientError 2822 as there is usually some possibility they will be corrected 2823 over time or some user action exists that can fix them. 2824 Requesters are expected to understand business errors and 2825 the appropriate time scale for user actions for retrying. 2826 [Note End] 2828 4.4.1.7 Encapsulating Blocks 2830 Blocks which encapsulate a payment protocol (step 7) pass along the 2831 enclosed information to the payment system involved. 2833 IOTP does not know the meaning of the enclosed information. It is thus 2834 up to the payment system involved to handle error detection and 2835 idempotency. Payment systems adapted for the Internet include 2836 idempotency handling because duplicates are always possible. Should a 2837 payment system have no idempotency handling, a layer between IOTP and 2838 the payment system must be added to take care of this. 2840 No IOTP level idempotency actions are required for encapsulating 2841 blocks. The payment system must return material to be encapsulated in 2842 the IOTP response message along with indications as to whether the 2843 exchange will continue or this is the final response and an indication 2844 whether an error occurred. If a payment protocol error has occurred, 2845 an Error Component is added to the response block. 2847 4.4.1.8 Error Block Received 2849 An error block (step 8) should not occur in a request and should be 2850 treated as an unexpected element with a Severity of HardError. No 2851 response to the block should be made in order to avoid the risk of 2852 loops. 2854 [Note] Consumers should send Error Blocks to a server specified in 2855 the ErrorNetLocn attribute of the appropriate Trading Role 2856 element as a response to the detection of an error in an 2857 IOTP Message that has been received (see section 4.4.1.9 2858 Generate Error Block). This may be the same server as is 2859 used to accept IOTP Messages which contain no error. In this 2860 case, the error block must not considered as a fatal error. 2861 [Note End] 2863 4.4.1.9 Generate Error Block 2865 If any of the previous steps resulted in an error being detected and 2866 an Error Component being created then generate an Error Block (step 9) 2867 containing the Error Components that describe the error(s). 2869 Unless the error is a "Transient Error", the Error Component(s) and 2870 the request block which caused the Error Components to be generated 2871 should be stored so that it can be reused if the action request is 2872 received again (step 6a). 2874 "Transient Errors" are not stored so that if the original Response 2875 Block is received again, then it can be processed as if it had never 2876 been received before. 2878 4.4.1.10 Add Block to Output Message 2880 Any Blocks which have been created as a result of processing the block 2881 received are added to the output message. 2883 4.4.2 Client Role Processing Sequence 2885 The "Client role" in IOTP is the Consumer Trading Role. 2887 [Note] A company or organisation that is a Merchant, for example, 2888 may take on the Trading Role of a Consumer when making a 2889 purchase or downloading or withdrawing electronic cash. 2890 [Note End] 2892 The model processing sequence for a Client role is indicted in the 2893 diagram below. 2895 ------------- 2896 | Input | 2897 | OTP Message | 2898 ------------- 2899 | 2900 v 2901 1. Check for transport --> 2902 or message level errors |Errors 2903 |OK | 2904 v | 2905 11.Blocks to be sent?<---------2. More Blocks <-- -------------------- 2906 | |No No to process? | ^ 2907 Yes| v |Yes | | 2908 v STOP v | | 2909 12. Generate 3. Check Block OK - -->| | 2910 output message | |Errors | 2911 | |Checks OK | | 2912 v v | | 2913 ------------- ------ 4. Type of Block ? -----| | 2914 | Output | | | | | | | 2915 | OTP Message | | ---- | | | | 2916 ------------- | | | | | | 2917 ------------ | | | | | 2918 | -- | | | | 2919 v v v v | | 2920 Status Action Encapsulating Error | | 2921 Request Response Block Block | | 2922 | | | | | | 2923 | v v v | | 2924 | 6a. Action 7. Process 8a.Error Block---- > Transient | 2925 | Response encapsulated severity ? | Error | 2926 | received message |Hard Error | (retry) | 2927 | before ? | | | | | | 2928 | Yes| |No Ok| | v | WAIT | 2929 | (Ig-| | | | STOP | | | 2930 | nore|) v | | v v | 2931 | | 6b. Process | ----- -> 9. Generate 8b. | 2932 | | Action | Errors Error Block Retrieve | 2933 | | Response---+-------- --> & store and resend | 2934 | | Block | Errors | previous | 2935 | | |Ok | | Block(s) | 2936 | | v v | | | 2937 | | 6c. New | | | 2938 | | request | | | 2939 | | required ? | | | 2940 | | No| |Yes 6d. Generate | | | 2941 | | | ---- > Request | | | 2942 | | | Block & Store v v | 2943 v | | | 10. Add Block to | 2944 ----------+-------+-------------------------> output message | 2945 v v | 2946 --------------------------------------------------> 2948 Figure 11 Client Role Processing Sequence 2950 Each of the processes in the sequence is described in more detail 2951 below. 2953 4.4.2.1 Check for Transport or Message Level Error 2955 On receipt of an IOTP response message (step 1), first check for 2956 transport or message level errors (see sections 4.3.1 and 4.3.2). 2957 These are errors which indicate that the entire message is corrupt and 2958 can not reliably be associated with any particular transaction or, if 2959 it can be associated with a transaction, the interior information in 2960 the message can not be reliably accessed. Set up an error indication 2961 message with an Error Component indicating the error. 2963 If the value of the OtpTransId attribute is not recognised as 2964 belonging to an IOTP transaction when other Blocks in the IOTP Message 2965 indicate that it should be recognised, then report the error using an 2966 Error Component with a Severity of HardError, an ErrorCode set to 2967 AttValNotRecog (attribute value not recognised), and an Error Location 2968 element (see section 6.19.3) that points to the OtpTransId attribute. 2970 On failure to receive an expected response message, the time out 2971 strategy indicated in the documentation for the transport method being 2972 used should be followed. This may include some number of automatic 2973 retransmissions of the request. If a user is present, they may be 2974 offered options of continuing to retransmit the request or of 2975 cancelling the transaction. 2977 4.4.2.2 Process all the blocks 2979 If there are no message level errors, process each of the blocks 2980 within the message which has not been processed (step 2). 2982 Once all the blocks have been processed, check to see if there are any 2983 blocks to be sent (step 11). There may be no blocks to send if the 2984 last response message received was the last message of the 2985 transaction. 2987 If blocks are to be sent then generate a request message (step 12) and 2988 send it to the server. It may be desirable to log the complete request 2989 message at the client. Failure of the server to receive a response may 2990 lead to a time-out and a retransmission of the request. 2992 4.4.2.3 Check the Block is OK 2994 If there are no message level errors process each of the blocks within 2995 the message (step 2). 2997 Check the block is OK (see section 4.3.3). For each block level error 2998 found, an appropriate Error Component should be created to be included 2999 in an Error Component sent back to the Server. 3001 If one or more of the Error Components contain a Severity attribute 3002 with a value of TransientError or HardError, no further processing of 3003 the block should occur and it is likely that this will result in 3004 termination of the transaction. 3006 4.4.2.4 Determine the Type of the Block 3008 Trading Blocks that survive the above steps and thus have no errors, 3009 or at worst have added a warning error component to the error 3010 indication message, can receive further processing. The nature of the 3011 processing depends (step 4) on whether the block is a Status Response, 3012 Action Response, an Error Block or contains an Encapsulated Message. 3014 4.4.2.5 Status Response Blocks 3016 Status Response Blocks (step 4) are either: 3017 o Inquiry Response Trading Blocks (see section 7.15), or 3018 o Ping Response Blocks (see section 7.17) 3020 In general, such blocks should be considered a status update. The best 3021 action to take at the requester may depend on whether this is in 3022 response to a user originated or automatic status request, whether a 3023 status display that could be updated is being presented to the user, 3024 and whether the status response block shows a change in status from a 3025 previous response block for the same type of status. Thus client 3026 detection of duplication in successive status response blocks may be 3027 useful. 3029 4.4.2.6 Action Response Blocks 3031 Check to determine if the Block has been received previously (step 3032 6a). If it has then it should be ignored. 3034 These indicate an action taken at the server in response to an action 3035 request block or a business error. If the response indicates success 3036 the block should be processed (step 6b) and, if required by the 3037 transaction (step 6c) , another Action Request Block generated and 3038 stored (step 6d). 3040 The Response Block should always be stored with the transaction id and 3041 until the transaction is terminated. If the Response Block indicates a 3042 transient business error, appropriate manually chosen or automatic 3043 steps to fix the problem or cancel the transaction should be provided. 3045 4.4.2.7 Encapsulating Blocks 3047 Blocks which encapsulate a payment protocol (step 7) pass along the 3048 enclosed information to the payment system involved. 3050 IOTP does not know the meaning of the enclosed information. It is up 3051 to the payment system involved to handle error detection and 3052 idempotency. Payment systems adapted for the Internet include 3053 idempotency handling because duplicates are always possible. Should a 3054 payment system have no idempotency handling, a layer between IOTP and 3055 the payment system must be added to take care of this. 3057 No IOTP level idempotency actions are required for encapsulating 3058 blocks. The payment system must return an indication of whether an 3059 error occurred. In addition, for a continuing exchange, it must return 3060 material to be encapsulated in the next IOTP request/exchange (step 3061 6d). If the response was a final response for that payment exchange 3062 and there was an error, the payment system may optionally return 3063 material to be encapsulated in the error indication. 3065 4.4.2.8 Error Block 3067 An error block in a response (step 8a) indicates some problem was 3068 detected by the server. If all of the error components are warnings, 3069 they may be optionally logged and/or presented to the user. 3071 Transient errors may be used to provide a manual or automatic 3072 resending (step 8b) of a block previously stored or alternatively may 3073 result in transaction cancellation. Hard errors will always terminate 3074 the transaction, unless they are in optional blocks, with appropriate 3075 indication to he user. 3077 4.4.2.9 Generate Error Block 3079 If an error indication message was created above, try to send it to 3080 the server unless all of the error components are of the warning 3081 severity in which case attempted transmission to the server is 3082 optional. 3084 [Note] To avoid error message loops, such an error indication from 3085 a requester must be sent to the Error Net Location specified 3086 in the Trading Role Element (see section 6.5.2) for the 3087 Organisation that is the server. Any errors encountered in 3088 sending such an error indication should be, at most, logged 3089 and must not result in any further attempts to transmit any 3090 error indication. 3091 [Note End] 3093 4.4.2.10 Add Block to Output Message 3095 Any Blocks which have been created as a result of processing the block 3096 received are added to the output message. 3098 5. Security Considerations 3100 This section considers the security associated with IOTP. It covers: 3101 o an overview of how IOTP uses digital signatures 3102 o how to check a signature is correctly calculated 3103 o how Payment Handlers and Delivery Handlers check they can 3104 carry out payments or deliveries on behalf of a Merchant. 3105 o how IOTP handles data integrity and privacy 3107 5.1 Digital Signatures and IOTP 3109 In general, signatures when used with IOTP: 3110 o are always treated as a IOTP Components (see section 6) 3111 o hash one or more IOTP Components or Trading Blocks, possibly 3112 including other Signature Components, in any IOTP message 3113 within the same IOTP Transaction 3114 o identify: 3115 - which Organisation signed (generated) the signature, and 3116 - which Organisation(s) should verify the signature in order to 3117 check that the Action the Organisation should take can occur. 3119 The way in which Signatures Components hash one or more elements is 3120 illustrated in the figure below. 3122 OTP MESSAGE SIGNATURE COMPONENT 3124 OTP MESSAGE OtpSignature Id = P1.3 3125 |-Trans Ref Block hash TransRefBlk |-SignedData 3126 | | ID=P1.1-------- ---------------------|->|-Hash of P1.1--- 3127 | |-Trans Id Comp hash TransIdComp | | | 3128 | | ID = M1.2------- ---------------------|->|-Hash of M1.2---| 3129 | |-Msg Id Comp. hash element | | | 3130 | | ID = P1 -------------------|->|-Hash of M1.5---| 3131 | | hash element | | | 3132 |-Signature Block | -----------------|->|-Hash of M1.7---| 3133 | | ID=P1.2 | | hash element | | | 3134 | |-Sig Comp. ID=P1.3 | | ---------------|->|-Hash of C1.4---| 3135 | |-Sig Comp. ID=M1.5--- - | | | | 3136 | |-Cert Comp. ID=P1.4 | | CertRef Iden- -DigSig | 3137 | |-Cert Comp. ID=M1.6<- ---|-|---------------------CertRef=M1.6 | 3138 | | | | tifies Certs Content: | 3139 |-Trading Block. ID=P1.5 | | to use JtvwpMdmSfMbhK<- 3140 | |-Comp. ID=M1.7------- --- | r1Ln3vovbMQttbBI 3141 | | | J8pxLjoSRfe1o6k 3142 | |-Comp. ID=P1.6 | OGG7nTFzTi+/0<-- 3143 | | | | 3144 | |-Comp. ID=C1.4------- ----- Digital signature of- 3145 | |-Comp. ID=C1.5 SignedData element 3146 using certificate 3147 identified by CertRef 3148 Elements signed can be in any OTP Message 3149 within the same OTP Transaction 3151 Figure 12 Signature Hashing 3153 [Note] The classic example of one signature signing another in 3154 IOTP, is when an Offer is first signed by a Merchant 3155 creating an "Offer Response" signature, which is then later 3156 signed by a Payment Handler together with a record of the 3157 payment creating a "Payment Receipt" signature. In this way, 3158 the payment in an IOTP Transaction is bound to the 3159 Merchant's offer. 3160 [Note End] 3162 The detailed definitions of how signatures are created is contained in 3163 the paper "Digital Signature for XML - Proposal", see [XMLSIG]. That 3164 document should be read in conjunction with this section. 3166 The remainder of this section contains: 3167 o an example of how IOTP uses signatures 3168 o how the SignerOrgRef and VerifierOrgRef attributes within a 3169 Signature Component are used to identify the organisations 3170 associated with the signature 3171 o how signatures may use either Symmetric or Asymmetric 3172 Cryptography 3173 o Mandatory and Optional use of Signatures by IOTP, and 3174 o how IOTP uses signatures to prove actions complete 3175 successfully 3177 5.1.1 IOTP Signature Example 3179 An example of how signatures are used is illustrated in the figure 3180 below which shows how the various components and elements in a 3181 Baseline Purchase relate to one another. Refer to this example in the 3182 later description of how signatures are used to check a payment or 3183 delivery can occur (see section 5.3). 3185 [Note] A Baseline Purchase transaction has been used for 3186 illustration purposes. The usage of the elements and 3187 attributes is the same for all types of IOTP Transactions. 3188 [Note End] 3190 TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK 3191 (Offer Response) 3192 Brand Selection Organisation<--- Signer Signature 3193 Component Component | OrgRef Component 3194 | | ----------(Offer 3195 |BrandList -Trading Role Response) 3196 | Ref Element | 3197 v (Merchant) | 3198 Brand List | 3199 >Component | 3200 | |-Protocol ------> Organisation<-------------- |-Dig Sig 3201 | | Amount Elem | Component Verifier | | Element 3202 | | | | | OrgRef -|-(Payment 3203 | | Pa|Protocol |Action -Trading Role | Handler) 3204 | | | Ref |OrgRef Element | 3205 | | v | (Payment Handler) | 3206 | -PayProtocol-- | 3207 | Elem ->Organisation<------------- |-Dig Sig 3208 | | Component Verifier | | Element 3209 | | | OrgRef -|-(Delivery 3210 | | -Trading Role | Handler) 3211 | | Element | 3212 | | (Delivery Handler) -SignedData 3213 | | Element ^ 3214 | OFFER RESPONSE BLOCK | 3215 | | Contains hashes of:----- 3216 |BrandListRef |ActionOrgRef -Trans Ref Block (not 3217 | | shown) 3218 --Payment ---Delivery -Transaction Id Component 3219 Component Component (not shown) 3220 -Org Components (Merchant, 3221 Payment Handler, 3222 Delivery Handler 3223 -Brand List Component 3224 -Order Component 3225 -Payment Component 3226 -Delivery Component 3227 -Brand Selection Component 3228 (if Brand Dependent) 3230 Figure 13 Example use of Signatures for Baseline Purchase 3232 5.1.2 SignerOrgRef and VerifierOrgRef Attributes 3234 The SignerOrgRef attribute on the Signature Component contains an 3235 Element Reference (see section 3.5) that points to the Organisation 3236 Component of the Organisation which generated the Signature. In this 3237 example its the Merchant. 3239 Note that the type of the Signature Component must match the Trading 3240 Role of the Organisation which signed it. If it does not, then it is 3241 an error. Valid combinations are given in the table below. 3243 Signature Valid 3244 Component Trading 3245 Type Role 3247 OfferResponse Merchant 3249 PaymentResponse PaymentHandler 3251 The VerifierOrgRef attribute on the DigSig elements, contains Element 3252 References to the Organisation Components of the Organisations that 3253 should use the signature to verify that: 3254 o they have a pre-existing relationship with the Organisation 3255 that generated the signature, 3256 o the data which is secured by the signature has not been 3257 changed, 3258 o the data has been signed correctly, and 3259 o the action they are required to undertake on behalf of the 3260 Merchant is therefore authorised. 3262 5.1.3 Symmetric and Asymmetric Cryptography 3264 The Signer of an Action and a Verifier of an Action may have agreed to 3265 use cryptography which is understood only by the two organisations 3266 involved. This requires that a separate Digital Signature Element for 3267 use by the verifier is contained within the Signature Component. This 3268 approach is more likely if symmetric cryptography is being used 3269 between the Trading Roles. 3271 Equally the same cryptography may be understood by several or all of 3272 the Trading Roles. In this case one Digital Signature Element may 3273 refer to multiple Verifiers of an Action. This is more likely if 3274 public key/asymmetric cryptography is being used. 3276 Note that one transaction may involve use of both symmetric and 3277 asymmetric cryptography. 3279 5.1.4 Mandatory and Optional Signatures 3281 IOTP does not mandate the use of signatures. For example, if a micro 3282 payment is being made for 0.1 cents, then the cost of the cryptography 3283 required to generate the signature may be greater than the income 3284 generated from the payment. Therefore it is up to the Merchant to 3285 decide whether IOTP Messages will include signatures, and for the 3286 Consumer to decide whether carrying out a transaction without 3287 signatures is an acceptable risk. If Merchants discover that 3288 transactions without signatures are not being accepted, then they will 3289 start using signatures or accept a lower volume and value of business. 3291 Additional optional signatures, over and above the ones required by 3292 the Trading Roles may be included, for example, to identify a Customer 3293 Care Provider or so that a Merchant can sign an Offer using a 3294 certificate issued by a Certificate Authority which offers Merchant 3295 "Credentials" or some other warranty on the goods or services being 3296 offered. 3298 5.1.5 Using signatures to Prove Actions Complete Successfully 3300 Proving an action completed successfully, is achieved by signing data 3301 on Response messages. Specifically: 3302 o on the Offer Response, when a Merchant is making an Offer to 3303 the Consumer which can then be sent to either: 3304 - a Payment Handler to prove that payment is authorised, or 3305 - a Delivery Handler to prove that Delivery is authorised 3306 o on the Payment Response, when a Payment Handler is generating 3307 a Payment Receipt which can be sent to either: 3308 - a Delivery Handler, in a Delivery Request Block to prove that 3309 delivery is authorised, or 3310 - another Payment Handler, in a second Payment Request, to prove 3311 that the second payment in a Value Exchange IOTP Transaction is 3312 authorised. 3314 This proof of an action may, in future versions of IOTP, also be used 3315 to prove after the event that the IOTP transaction occurred. For 3316 example to a Customer Care Provider. 3318 5.2 Checking a Signature is Correctly Calculated 3320 Checking a signature is correctly calculated is part of checking for 3321 Message Level Errors (see section 4.3.2). It is included here so that 3322 all signature and security related considerations are kept together. 3324 Before a Trading Role can check a signature it must identify which of 3325 the potentially multiple digital signature elements should be checked. 3326 The steps involved are as follows: 3327 o check that a Signature Block is present and it contains one or 3328 more Signature Components 3329 o identify the Organisation Component which contains an OrgId 3330 attribute for the Organisation which is carrying out the 3331 signature check. If no or more than one Organisation Component 3332 is found then it is an error 3333 o use the ID attribute of the Organisation Component to identify 3334 the Digital Signatures Elements which the Trading Role should 3335 verify. Note there may be no signatures for a Trading Role to 3336 verify. 3338 o verify the Signature Components that contain the Digital 3339 Signature Elements as follows: 3340 - check that the Digital Signature Element correctly signs the 3341 Signed Data Element 3342 - check that the Hash Elements in the Signed Data Element are 3343 correctly calculated where Components or Blocks that are hashed 3344 have been received by the organisation checking the signature 3346 5.3 Checking a Payment or Delivery can occur 3348 This section describes the processes required for a Payment Handler or 3349 Delivery Handler to check that a payment or delivery can occur. This 3350 may include checking signatures if this is specified by the Merchant. 3352 In outline the steps are: 3353 o check that the Payment Request or Delivery Request has been 3354 sent to the correct organisation 3355 o check that correct IOTP components are present in the request, 3356 and 3357 o check that the payment or delivery is authorised 3359 For clarity and brevity the following terms or phrases are used in 3360 this section: 3361 o a "Request Block" is used to refer to either a Payment Request 3362 Block (see section 7.6) or a Delivery Request Block (see 3363 section 7.9) unless specified to the contrary 3364 o a "Response Block" is used to refer to either a Payment 3365 Response Block (see section 7.8) or a Delivery Response Block 3366 (see section 7.10) 3367 o an "Action" is used to refer to an action which occurs on 3368 receipt of a Request Block. Actions can be either a Payment or 3369 a Delivery 3370 o an "Action Organisation", is used to refer to the Payment 3371 Handler or Delivery Handler that carries out an Action 3372 o a "Signer of an Action", is used to refer to the Organisations 3373 that sign data about an Action to authorise the Action, either 3374 in whole or in part 3375 o a "Verifier of an Action", is used to refer to the 3376 Organisations that verify data to determine if they are 3377 authorised to carry out the Action 3378 o an ActionOrgRef attribute contains Element References which 3379 can be used to identify the "Action Organisation" that should 3380 carry out an Action 3382 5.3.1 Check the Action Request was sent to the Correct Organisation 3384 Checking the Action Request was sent to the correct Organisation 3385 varies depending on whether the Action is a Payment or a Delivery. 3387 5.3.1.1 Payment 3389 In outline a Payment Handler checks if it can accept or make a payment 3390 by identifying the Payment Component in the Payment Request Block it 3391 has received, then using the ID of the Payment Component to track 3392 through the Brand List and Brand Selection Components to identify the 3393 Organisation selected by the Consumer and then checking that this 3394 organisation is itself. 3396 The way data is accessed to do this is illustrated in the figure 3397 below. 3399 Start 3400 | 3401 v 3402 Brand List<--------------------------+-----------Payment 3403 Component BrandListRef | Component 3404 | | 3405 |-Brand<-------------------------- | 3406 | Element BrandRef | | 3407 | | Brand Selection 3408 | |Protocol Component 3409 | | AmountRefs | | 3410 | v Protocol | | 3411 |-Protocol Amount<---------------- | 3412 | Element---------- AmountRef | 3413 | | | | 3414 | |Currency |Pay | 3415 | | AmountRefs |Protocol | 3416 | v |Ref | 3417 |-Currency Amount | | 3418 | Element<---------|---------------- 3419 | | 3420 -PayProtocol<----- 3421 Element---------------------->Organisation 3422 Action Component 3423 OrgRef | 3424 -Trading Role 3425 Element 3426 (Payment Handler) 3428 Figure 14 Checking a Payment Handler can carry out a Payment 3430 The following describes the steps involved and the checks which need 3431 to be made: 3432 1) 3433 Identify the Payment Component (see section 6.8) in the 3434 Payment Request Block that was received. 3435 2) 3436 Identify the Brand List and Brand Selection Components for the 3437 Payment Component. This involves: 3438 a) 3439 identifying the Brand List Component (see section 6.6) 3440 where the value of its ID attribute matches the 3441 BrandListRef attribute of the Payment Component. If no or 3442 more than one Brand List Component is found there is an 3443 error. 3444 b) 3445 identifying the Brand Selection Component (see section 6.7) 3446 where the value of its BrandListRef attribute matches the 3447 BrandListRef of the Payment Component. If no or more than 3448 one matching Brand Selection Component is found there is an 3449 error. 3450 3) 3451 Identify the Brand, Protocol Amount, Pay Protocol and Currency 3452 Amount elements within the Brand List that have been selected 3453 by the Consumer as follows: 3454 a) 3455 the Brand Element (see section 6.6.1) selected is the 3456 element where the value of its Id attribute matches the 3457 value of the BrandRef attribute in the Brand Selection. If 3458 no or more than one matching Brand Element is found then 3459 there is an error. 3460 b) 3461 the Protocol Amount Element (see section 6.6.2) selected is 3462 the element where the value of its Id attribute matches the 3463 value of the ProtocolAmountRef attribute in the Brand 3464 Selection Component. If no or more than one matching 3465 Protocol Amount Element is found there is an error 3466 c) 3467 the Pay Protocol Element (see section 6.6.4) selected is 3468 the element where the value of its Id attribute matches the 3469 value of the PayProtocolRef attribute in the identified 3470 Protocol Amount Element. If no or more than one matching 3471 Pay Protocol Element is found there is an error 3472 d) 3473 the Currency Amount Element (see section 6.6.3) selected is 3474 the element where the value of its Id attribute matches the 3475 value of the CurrencyAmountRef attribute in the Brand 3476 Selection Component. If no or more than one matching 3477 Currency Amount element is found there is an error 3478 4) 3479 Check the consistency of the references in the Brand List and 3480 Brand Selection Components: 3481 a) 3482 check that an Element Reference exists in the 3483 ProtocolAmountRefs attribute of the identified Brand 3484 Element that matches the Id attribute of the identified 3485 Protocol Amount Element. If no or more than one matching 3486 Element Reference can be found there is an error 3487 b) 3488 check that the CurrencyAmountRefs attribute of the 3489 identified Protocol Amount element contains an element 3490 reference that matches the Id attribute of the identified 3491 Currency Amount element. If no or more than one matching 3492 Element Reference is found there is an error. 3493 c) 3494 check the consistency of the elements in the Brand List. 3495 Specifically, the selected Brand, Protocol Amount, Pay 3496 Protocol and Currency Amount Elements are all child 3497 elements of the identified Brand List Component. If they 3498 are not there is an error. 3499 5) 3500 Check that the Payment Handler that received the Payment 3501 Request Block is the Payment Handler selected by the Consumer. 3502 This involves: 3503 a) 3504 identifying the Organisation Component for the Payment 3505 Handler. This is the Organisation Component where its ID 3506 attribute matches the ActionOrgRef attribute in the 3507 identified Pay Protocol Element. If no or more than one 3508 matching Organisation Component is found there is an error 3509 b) 3510 checking the Organisation Component has a Trading Role 3511 Element with a Role attribute of PaymentHandler. If not 3512 there is an error 3513 c) 3514 finally, if the identified Organisation Component is not 3515 the same as the organisation that received the Payment 3516 Request Block, then there is an error. 3518 5.3.1.2 Delivery 3520 The way data is accessed by a Delivery Handler in order to check that 3521 it may carry out a delivery is illustrated in the figure below. 3523 Start 3524 | 3525 v 3526 Delivery 3527 Component 3528 | 3529 |ActionOrgRef 3530 | 3531 v 3532 Organisation 3533 Component 3534 | 3535 -Trading Role 3536 Element 3537 (Delivery Handler) 3539 Figure 15 Checking a Delivery Handler can carry out a Delivery 3541 The steps involved are as follows: 3542 1. 3543 Identify the Delivery Component in the Delivery Request Block. 3544 If there is no or more than one matching Delivery Component 3545 there is an error 3546 2. 3547 Use the ActionOrgRef attribute of the Delivery Component to 3548 identify the Organisation Component of the Delivery Handler. 3549 If there is no or more than one matching Organisation 3550 Component there is an error 3551 3. 3552 If the Organisation Component for the Delivery Handler does 3553 not have a Trading Role Element with a Role attribute of 3554 DeliveryHandler there is an error 3555 4. 3556 Finally, if the organisation that received the Delivery 3557 Request Block does not identify the Organisation Component for 3558 the Delivery Handler as itself, then there is an error. 3560 5.3.2 Check the Correct Components are present in the Request Block 3562 Check that the correct components are present in the Payment Request 3563 Block (see section 7.6) or in the Delivery Request Block (see section 3564 7.9). 3566 If components are missing, there is an error. 3568 5.3.3 Check an Action is Authorised 3570 The previous steps identified the Action Organisation and that all the 3571 necessary components are present. This step checks that the Action 3572 Organisation is authorised to carry out the Action. 3574 In outline the Action Organisation identifies the Merchant, checks 3575 that it has a pre-existing agreement which allows it carry out the 3576 Action and that any constraints implied by that agreement are being 3577 followed, then, if signatures are required, it checks that they sign 3578 the correct data. 3580 The steps involved are as follows: 3581 1. 3582 Identify the Merchant. This is the Organisation Component with 3583 a Trading Role Element which has a Role attribute with a value 3584 of Merchant. If no or more than one Trading Role Element is 3585 found, there is an error 3586 2. 3587 Check the Action Organisation's agreements with the Merchant 3588 allows the Action to be carried out. To do this the Action 3589 Organisation must check that: 3590 a) the Merchant is known and a pre-existing agreement exists 3591 for the Action Organisation to be their agent for the 3592 payment or delivery 3593 b) they are allowed to take part in the type of IOTP 3594 transaction that is occurring. For example a Payment 3595 Handler may have agreed to accept payments as part of a 3596 Baseline Purchase, but not make payments as part of a 3597 Baseline Refund 3598 c) any constraints in their agreement with the Merchant are 3599 being followed, for example, whether or not an Offer 3600 Response signature is required 3601 3. 3602 Check the signatures are correct. If signatures are required 3603 then they need to be checked. This involves: 3604 a) Identifying the correct signatures to check. This involves 3605 the Action Organisation identifying the Signature 3606 Components where the VerifierOrgRef attribute of the 3607 Digital Signature element points to the Action 3608 Organisation's Organisation Component. Depending on the 3609 IOTP Transaction being carried out (see section 8) either 3610 one or two signatures may be identified 3611 b) checking that the Signature Components are correct. This 3612 involves checking that the necessary Trading Components 3613 have been hashed (see section 5.3.3.1). 3615 [Note] Validation that the signature is correct and that the Hash 3616 elements within the signature are correctly calculated is 3617 described in section 4 IOTP Error Handling. This is because 3618 errors in the signature or calculation of hashes is 3619 considered a Message Level Error and is carried out before 3620 the Request Block is processed. 3621 [Note End] 3623 5.3.3.1 Check the Signatures Sign Correct Data 3625 All Signature Components contained within IOTP Messages must always 3626 hash: 3627 o the Transaction Id Component (see section 3.3.1) of the IOTP 3628 message that contains the Signature Component. This binds the 3629 globally unique OtpTransId to other components which make up 3630 the IOTP Transaction 3631 o the Transaction Reference Block (see section 3.3) of the first 3632 IOTP Message that contained the signature. This binds the 3633 OtpTransId with information about the IOTP Message contained 3634 inside the Message Id Component (see section 3.3.2). 3636 Checking that each signature signs the correct data, involves checking 3637 that hashes of the necessary components are present in the SignedData 3638 element of the Signature Component. 3640 The hashes that need to be present depend on the Trading Role of the 3641 Organisation which generated (signed) the signature: 3642 o if the signer of the signature is a Merchant then: 3643 - hashes must be present for all the components in the Request 3644 Block apart from the Brand Selection Component which is optional 3645 o if the signer of the signature is a Payment Handler then 3646 hashes should be present for: 3647 - the Signature Component signed by the Merchant, and optionally 3648 - one or more Signature Components signed by the Payment 3649 Handler(s) identified by the appropriate ActionSignerRefs 3650 attribute. 3652 5.4 Data Integrity and Privacy 3654 The overall integrity of data in IOTP Messages is ensured by the 3655 signing of hashes of Components and Trading Blocks contained in a 3656 Signature Component (see section 6.18) in a Signature Block (see 3657 section 7.18). 3659 Privacy of information is provided by sending IOTP Messages between 3660 the various Trading Roles using a secure channel such as [SSL]. Use of 3661 a secure channel within IOTP is optional. 3663 6. Trading Components 3665 This section describes the Trading Components used within IOTP. 3666 Trading Components are the child XML elements which occur immediately 3667 below a Trading Block as illustrated in the diagram below. 3669 OTP MESSAGE <----------- OTP Message - an XML Document 3670 | which is transported between the 3671 | Trading Roles 3672 |-Trans Ref Block <----- Trans Ref Block - contains 3673 | | information which describes the 3674 | | OTP Transaction and the OTP 3675 Message. 3676 --------> | |-Trans Id Comp. <--- Transaction Id Component - 3677 | | | uniquely identifies the OTP 3678 | | | Transaction. The Trans Id 3679 | | | Components are the same across 3680 | | | all OTP messages that comprise a 3681 | | | single OTP transaction. 3682 | | |-Msg Id Comp. <----- Message Id Component - 3683 | | identifies and describes an OTP 3684 | | Message within an OTP 3685 | | Transaction 3686 | |-Signature Block <----- Signature Block (optional) - 3687 | | | contains one or more Signature 3688 | | | Components and their associated 3689 | | | Certificates 3690 | ---> | |-Signature Comp. <-- Signature Component - contains 3691 | | | | digital signatures. Signatures 3692 | | | | may sign hashes of the Trans Ref 3693 | | | | Block and any Trading Component 3694 | | | | in any OTP Message in the same 3695 | | | | OTP Transaction. 3696 | | | |-Certificate Comp. <- Certificate Component. Used to 3697 | | | check the signature. 3698 Trading |-Trading Block <-------- Trading Block - an XML Element 3699 Components | |-Component within an OTP Message that 3700 | | | |-Component contains a predefined set of 3701 | ---> | |-Component Trading Components 3702 | | |-Component 3703 | | |-Component <--------- Trading Components - XML 3704 | | Elements within a Trading Block 3705 | |-Trading Block that contain a predefined set of 3706 --------> | |-Component XML elements and attributes 3707 | |-Component containing information required 3708 | |-Component to support a Trading Exchange 3709 | |-Component 3710 | |-Component 3711 | 3712 | 3714 Figure 16 Trading Components 3715 The Trading Components described in this section are listed below in 3716 approximately the sequence they are likely to be used: 3717 o Protocol Options Component 3718 o Authentication Data Component 3719 o Authentication Response Component 3720 o Order Component 3721 o Organisation Component 3722 o Brand List Component 3723 o Brand Selection Component 3724 o Payment Component 3725 o Payment Scheme Component 3726 o Payment Receipt Component 3727 o Delivery Component 3728 o Delivery Note Component 3729 o Signature Component 3730 o Certificate Component 3731 o Error Component 3733 Note that the following components are listed in other sections of 3734 this specification: 3735 o Transaction Id Component (see section 3.3.1) 3736 o Message Id Component (see section 3.3.2) 3738 6.1 Protocol Options Component 3740 Protocol options are options which apply to the IOTP Transaction as a 3741 whole. Essentially it provides a short description of the entire 3742 transaction and the net location which the Consumer role should branch 3743 to if the IOTP Transaction is successful. 3745 The definition of a Protocol Options Component is as follows. 3747 3748 3756 Attributes: 3758 ID An identifier which uniquely identifies the 3759 Protocol Options Component within the IOTP 3760 Transaction. 3762 xml:lang Defines the language used by attributes or child 3763 elements within this component, unless overridden 3764 by an xml:lang attribute on a child element. See 3765 section 3.9 Identifying Languages. 3767 ShortDesc This contains a short description of the IOTP 3768 Transaction in the language defined by xml:lang. 3769 Its purpose is to provide an explanation of what 3770 type of IOTP Transaction is being conducted by the 3771 parties involved. 3773 It is used to facilitate selecting an individual 3774 transaction from a list of similar transactions , 3775 for example from a database of IOTP transactions 3776 which has been stored by a Consumer, Merchant, 3777 etc. 3779 SenderNetLocn This contains the non secured net location of the 3780 sender of the TPO Block in which the Protocol 3781 Options Component is contained. 3783 It is the net location to which the recipient of 3784 the TPO block should send a TPO Selection Block if 3785 required. 3787 The content of this attribute is dependent on the 3788 Transport Mechanism see the Transport Mechanism 3789 Supplement. 3791 SecureSenderNetLo This contains the secured net location of the 3792 cn sender of the TPO Block in which the Protocol 3793 Options Component is contained. 3795 The content of this attribute is dependent on the 3796 Transport Mechanism see the Transport Mechanism 3797 Supplement. 3799 SuccessNetLocn This contains the net location that the should be 3800 displayed after the IOTP Transaction has 3801 successfully completed. 3803 The content of this attribute is dependent on the 3804 Transport Mechanism see the Transport Mechanism 3805 Supplement. 3807 6.2 Authentication Data Component 3809 This Trading Component contains data about how an Authentication 3810 within the IOTP Transaction will occur. Its definition is as follows. 3812 3813 3820 Attributes: 3822 ID An identifier which uniquely identifies the 3823 Authentication Data Component within the IOTP 3824 Transaction. 3826 AuthenticationId An identifier specified by the Authenticator 3827 which, if returned by the Organisation that 3828 receives the Authentication Request, will enable 3829 the Authenticator to identify which Authentication 3830 is being referred to. 3832 AuthMethod This identifies the content of the Authentication 3833 Data Component. Valid values are: 3834 o sha1 This indicates that the recipient of the 3835 Authentication Data Component should generate a 3836 hash. See 6.3 Authentication Response Component. 3837 o signature This indicates the recipient of the 3838 Authentication Data Component should generate a 3839 digital signature to include in the 3840 Authentication Response 3841 o pay:ppp A payment protocol specific 3842 authentication method. The "ppp" identifies a 3843 payment protocol associated with a payment 3844 exchange which is part of the IOTP Transaction. 3845 In this case the content and format of the 3846 AuthData element is defined in the appropriate 3847 Payment Scheme supplement. For example if a 3848 payment method "xzpay" provided an 3849 authentication method, then this attribute would 3850 have the value "pay:xzpay" 3851 o x-ddd:nnn a user defined authentication scheme 3852 type see section (3.7.3 User Defined Codes). 3854 TradingRoleList If present, contains a list of the Trading Roles 3855 (see the TradingRole attribute of the Trading Role 3856 Element - section 6.5.2) for which the 3857 Authenticator is requesting the Authenticatee 3858 provides Organisation Components in the 3859 Authentication Response. 3861 For example a Merchant could request that a 3862 Consumer provides Organisation Components for the 3863 Consumer and DelivTo Trading Roles. 3865 ContentSoftwareId This contains information which identifies the 3866 software which generated the content of the 3867 element. Its purpose is to help resolve 3868 interoperability problems that might occur as a 3869 result of incompatibilities between messages 3870 produced by different software. It is a single 3871 text string in the language defined by xml:lang. 3872 It must contain, as a minimum: 3873 o the name of the software manufacturer 3874 o the name of the software 3875 o the version of the software, and 3876 o the build of the software 3878 It is recommended that this attribute is included 3879 if the software which generated the content cannot 3880 be identified from the SoftwareId attribute on the 3881 Message Id Component (see section 3.3.2) 3883 Content: 3885 PackagedContent This contains the challenge data as Packaged 3886 Content (see section 3.8) that is to be responded 3887 to using the method indicated by AuthMethod. 3889 6.3 Authentication Response Component 3891 This Authentication Response Component contains the results of an 3892 authentication. Its definition is as follows. 3894 3895 3899 Attributes: 3901 ID An identifier which uniquely identifies the 3902 Authentication Response Component within the IOTP 3903 Transaction. 3905 ContentSoftwareId This contains information which identifies the 3906 software which generated the content of the 3907 element. Its purpose is to help resolve 3908 interoperability problems that might occur as a 3909 result of incompatibilities between messages 3910 produced by different software. It is a single 3911 text string in the language defined by xml:lang. 3912 It must contain, as a minimum: 3913 o the name of the software manufacturer 3914 o the name of the software 3915 o the version of the software, and 3916 o the build of the software 3918 It is recommended that this attribute is included 3919 if the software which generated the content cannot 3920 be identified from the SoftwareId attribute on the 3921 Message Id Component (see section 3.3.2) 3923 Content: 3925 PackagedContent This contains the response to the content of the 3926 Authentication Data Component see section 6.2 as 3927 Packaged Content (see section 3.8). 3929 For a payment specific scheme, it may contain 3930 scheme-specific data. Refer to the scheme-specific 3931 supplemental documentation. 3933 6.4 Order Component 3935 An Order Component contains information about an order. Its definition 3936 is as follows. 3938 3939 3949 Attributes: 3951 ID An identifier which uniquely identifies the Order 3952 Component within the IOTP Transaction. 3954 xml:lang Defines the language used by attributes or child 3955 elements within this component, unless overridden 3956 by an xml:lang attribute on a child element. See 3957 section 3.9 Identifying Languages. 3959 OrderIdentifier This is a code, reference number or other 3960 identifier which the creator of the Order may use 3961 to identify the order. It must be unique within an 3962 IOTP Transaction. If it is used in this way, then 3963 it may remove the need to specify any content for 3964 the Order element as the reference can be used to 3965 look up the necessary information in a database. 3967 ShortDesc A short description of the order in the language 3968 defined by xml:lang. It is used to facilitate 3969 selecting an individual order from a list of 3970 orders, for example from a database of orders 3971 which has been stored by a Consumer, Merchant, 3972 etc. 3974 OkFrom The date and time in [UTC] format after which the 3975 offer made by the Merchant lapses. 3977 OkTo The date and time in [UTC] format before which a 3978 Value Acquirer may accept the offer made by the 3979 Merchant is not valid. 3981 ApplicableLaw A phrase in the language defined by xml:lang which 3982 describes the state or country of jurisdiction 3983 which will apply in resolving problems or 3984 disputes. 3986 ContentSoftwareId This contains information which identifies the 3987 software which generated the content of the 3988 element. Its purpose is to help resolve 3989 interoperability problems that might occur as a 3990 result of incompatibilities between messages 3991 produced by different software. It is a single 3992 text string in the language defined by xml:lang. 3993 It must contain, as a minimum: 3994 o the name of the software manufacturer 3995 o the name of the software 3996 o the version of the software, and 3997 o the build of the software 3999 It is recommended that this attribute is included 4000 if the software which generated the content cannot 4001 be identified from the SoftwareId attribute on the 4002 Message Id Component (see section 3.3.2) 4004 Content: 4006 PackagedContent An optional description of the order information 4007 as Packaged Content (see section 3.8). 4009 6.4.1 Order Description Content 4011 The Packaged Content element will normally be required, however it may 4012 be omitted where sufficient information about the purchase can be 4013 provided in the ShortDesc attribute 4015 Although the amount and currency are likely to appear in the Packaged 4016 Content of the Order Description it is the amount and currency 4017 contained in the payment related trading components (Brand List, Brand 4018 Selection and Payment) that is authoritative. This means it is 4019 important that the amount actually being paid (as contained in the 4020 payment related trading components) is prominently displayed to the 4021 Consumer. 4023 For interoperability, implementations must support Plain Text as a 4024 minimum so that it can be easily displayed. 4026 6.4.2 OkFrom and OkTo Timestamps 4028 Note that: 4029 o the OkFrom date may be later than the OkFrom date on the 4030 Payment Component (see section 6.8) associated with this 4031 order, and 4032 o similarly, the OkTo date may be earlier that the OkTo date on 4033 the Payment Component (see section 6.8). 4035 [Note] Disclaimer. The following information provided in this note 4036 does not represent formal advice of the Open Trading 4037 Protocol Consortium, any of its members or the authors of 4038 this specification. Readers of this specification must form 4039 their own views and seek their own legal counsel on the 4040 usefulness and applicability of this information. 4042 The merchant in the context of Internet commerce with 4043 anonymous consumers initially frames the terms of the offer 4044 on the web page, and in order to obtain the good or service, 4045 the consumer must accept them. 4047 If there is to be a time-limited offer, it recommended that 4048 merchants communicate this to the consumer and state in the 4049 order description in a manner which is clear to the consumer 4050 that: 4052 - the offer is time limited 4054 - the OkFrom and OkTo timestamps specify the validity of 4055 the offer 4057 - the clock, e.g. the merchant's clock, that will be used 4058 to determine the validity of the offer 4059 [Note End] 4061 6.5 Organisation Component 4063 The Organisation Component provides information about an individual or 4064 an organisation. This can be used for a variety of purposes. For 4065 example: 4066 o to describe the merchant who is selling the goods, 4067 o to identify who made a purchase, 4068 o to identify who will take delivery of goods, 4069 o to provide a customer care contact, 4070 o to describe who will be the Payment Handler. 4072 Note that the Organisation Components which must be present in an OTP 4073 Message are dependent on the particular transaction being carried out. 4074 Refer to section 8. Open Trading Protocol Transactions, for more 4075 details. 4077 Its definition is as follows. 4079 4081 4090 Attributes: 4092 ID An identifier which uniquely identifies the 4093 Organisation Component within the IOTP 4094 Transaction. 4096 xml:lang Defines the language used by attributes or child 4097 elements within this component, unless overridden 4098 by an xml:lang attribute on a child element. See 4099 section 3.9 Identifying Languages. 4101 OrgId A code which identifies the organisation described 4102 by the Organisation Component. See 6.5.1.1 4103 Organisation IDs, below. 4105 OtpMsgIdPrefix Contains the prefix which must be used for all 4106 IOTP Messages sent by the Organisation in this 4107 IOTP Transaction. The values to be used are 4108 defined in 3.4.1 IOTP Message ID Attribute 4109 Definition. 4111 LegalName For organisations which are companies this is 4112 their legal name in the language defined by 4113 xml:lang. It is required for Organisations who 4114 have a Trading Role other than Consumer or 4115 DeliverTo. 4117 ShortDesc A short description of the organisation in the 4118 language defined by xml:lang. It is typically the 4119 name by which the organisation is commonly known. 4120 For example, if the legal name was "Blue Meadows 4121 Financial Services Inc.". Then its short name 4122 would likely be "Blue Meadows". 4124 It is used to facilitate selecting an individual 4125 organisation from a list of organisations, for 4126 example from a database of organisations involved 4127 in IOTP Transactions which has been stored by a 4128 consumer. 4130 LogoNetLocn The net location which can be used to download the 4131 logo for the organisation. 4133 See section 9 Retrieving Logos. 4135 The content of this attribute must conform to 4136 [RFC1738]. 4138 Content: 4140 TradingRole See 6.5.2 Trading Role Element below. 4142 ContactInfo See 6.5.3 Contact Information Element below. 4144 PersonName See 6.5.4 Person Name below. 4146 PostalAddress See 6.5.5 Postal Address below. 4148 6.5.1.1 Organisation IDs 4150 Organisation IDs are used by one IOTP Trading Role to identify 4151 another. In order to avoid confusion, this means that these IDs must 4152 be globally unique. 4154 In principle this is achieved in the following way: 4155 o the Organisation Id for all trading roles, apart from the 4156 Consumer Trading Role, uses a domain name as their globally 4157 unique identifier, 4158 o the Organisation Id for a Consumer Trading Role is allocated 4159 by one of the other Trading Roles in an IOTP Transaction and 4160 is made unique by concatenating it with that other roles' 4161 Organisation Id, 4162 o once a Consumer is allocated an Organisation Id within an IOTP 4163 Transaction the same Organisation Id is used by all the other 4164 trading roles in that IOTP transaction to identify that 4165 Consumer. 4167 Specifically, the content of the Organisation ID is defined as 4168 follows: 4170 OrgId ::= NonConsumerOrgId | ConsumerOrgId 4171 NonConsumerOrgId ::= DomainName 4172 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" 4173 NonConsumerOrgId 4174 ConsumerOrgIdPrefix ::= "Consumer:" 4176 ConsumerOrgId If the Organisation ID for a Consumer consists 4177 of: 4178 o a standard prefix is to identify that the 4179 Organisation Id is for a consumer, followed by 4180 o one or more characters which conform to the 4181 definition of an XML "namechar". See [XML] 4182 specifications, followed by 4183 o the NonConsumerOrgId for the Organisation which 4184 allocated the ConsumerOrgId. It is normally the 4185 Merchant role. 4187 Use of upper and lower case is significant. 4189 NonConsumerOrgId If the Role is not Consumer then this contains the 4190 Canonical Name for the non-consumer organisation 4191 being described by the Organisation Component. See 4192 [DNS]. 4194 Note that a NonConsumerOrgId may not start with 4195 the ConsumerOrgIdPrefix. 4197 Use of upper and lower case is not significant. 4199 Examples of Organisation Ids follow: 4200 o newjerseybooks.com - a merchant organisation id 4201 o westernbank.co.uk - a payment handler organisation id 4202 o consumer:1000247ABH/newjerseybooks.com - a consumer 4203 organisation id allocated by a merchant 4205 6.5.2 Trading Role Element 4207 This identifies the Trading Role of an individual or organisation in 4208 the IOTP Transaction. Note, an organisation may have more than one 4209 Trading Role and several roles may be present in one organisation 4210 element. Its definition is as follows: 4212 4213 4217 Attributes: 4219 TradingRole The trading role of the organisation. Valid values 4220 are: 4221 o Consumer. The person or organisation that is 4222 acting in the role of a consumer in the IOTP 4223 Transaction. 4224 o Merchant. The person or organisation that is 4225 acting in the role of merchant in the IOTP 4226 Transaction. 4227 o PaymentHandler. The financial institution or 4228 other organisation which is a Payment Handler 4229 for the IOTP Transaction 4230 o DeliveryHandler. The person or organisation 4231 that is the delivering the goods or services for 4232 the IOTP Transaction 4233 o DelivTo. The person or organisation that is 4234 receiving the delivery of goods or services in 4235 the IOTP Transaction 4236 o CustCare. The organisation and/or individual 4237 who will provide customer care for an IOTP 4238 Transaction. 4239 o x-ddd:nnn a user defined role (see section 4240 3.7.3 User Defined Codes). 4242 ErrorNetLocn The net location to which IOTP messages containing 4243 Error Components with a Severity of either 4244 HardError or TransientError are sent. See section 4245 6.19.1 Error Processing Guidelines for more 4246 details. 4248 This attribute must be set when TradingRole is set 4249 to Merchant, PaymentHandler or DeliveryHandler. 4251 The content of this attribute is dependent on the 4252 Transport Mechanism see the Transport Mechanism 4253 Supplement. 4255 CancelNetLocn This contains the net location that should be 4256 displayed by the Consumer after the Consumer has 4257 received an Error Block containing an Error 4258 Component with the Severity attribute set to 4259 either: 4260 o HardError, 4261 o Warning but the Consumer decides to not 4262 continue with the transaction 4263 o TransientError and the transaction has 4264 subsequently timed out. 4266 See section 6.19.1 Error Processing Guidelines for 4267 more details. 4269 This attribute must be set when TradingRole is set 4270 to Merchant, PaymentHandler or DeliveryHandler. 4272 The content of this attribute is dependent on the 4273 Transport Mechanism see the Transport Mechanism 4274 Supplement. 4276 6.5.3 Contact Information Element 4278 This contains information which can be used to contact an organisation 4279 or an individual. All attributes are optional however at least one 4280 item of contact information should be present. Its definition is as 4281 follows. 4283 4284 4291 Attributes: 4293 xml:lang Defines the language used by attributes within 4294 this element. See section 3.9 Identifying 4295 Languages. 4297 Tel A telephone number by which the organisation may 4298 be contacted. Note that this is a text field and 4299 no validation is carried out on it. 4301 Fax A fax number by which the organisation may be 4302 contacted. Note that this is a text field and no 4303 validation is carried out on it. 4305 Email An email address by which the organisation may be 4306 contacted. Note that this field should conform to 4307 the conventions for address specifications 4308 contained in [RFC822]. 4310 NetLocn A location on the Internet by which information 4311 about the organisation may be obtained that can be 4312 displayed using a web browser. 4314 The content of this attribute must conform to 4315 [RFC1738]. 4317 6.5.4 Person Name Element 4319 This contains the name of an individual person. All fields are 4320 optional however as a minimum either the GivenName or the FamilyName 4321 should be present. Its definition is as follows. 4323 4324 4331 Attributes: 4333 xml:lang Defines the language used by attributes within 4334 this element. See section 3.9 Identifying 4335 Languages. 4337 Title A distinctive name; personal appellation, 4338 hereditary or not, denoting or implying office 4339 (e.g. judge, mayor) or nobility (e.g. duke, 4340 duchess, earl), or used in addressing or referring 4341 to a person (e.g. Mr, Mrs, Miss) 4343 GivenName The primary or main name by which a person is 4344 known amongst and identified by their family, 4345 friends and acquaintances. Otherwise known as 4346 first name or Christian Name. 4348 Initials The first letter of the secondary names (other 4349 than the Given Name) by which a person is known 4350 amongst or identified by their family, friends and 4351 acquaintances. 4353 FamilyName The name by which family of related individuals 4354 are known. It is typically the part of an 4355 individual's name which is passed on by parents to 4356 their children. 4358 6.5.5 Postal Address Element 4360 This contains an address which can be used, for example, for the 4361 physical delivery of goods, services or letters. Its definition is as 4362 follows. 4364 4365 4375 Attributes: 4377 xml:lang Defines the language used by attributes within 4378 this element. See section 3.9 Identifying 4379 Languages. 4381 AddressLine1 The first line of a postal address. e.g. "The 4382 Meadows" 4384 AddressLine2 The second line of a postal address. e.g. "Sandy 4385 Lane" 4387 CityOrTown The city of town of the address. e.g. "Carpham" 4389 StateOrRegion The state or region within a country where the 4390 city or town is placed. e.g. "Surrey" 4392 Country The country for the address. e.g. "UK" 4394 LegalLocation This identifies whether the address is the 4395 Registered Address for the Organisation. At least 4396 one address for the Organisation must have a value 4397 set to True unless the Trading Role is either 4398 Consumer or DeliverTo. 4400 6.6 Brand List Component 4402 Brand List Components are contained within the Trading Protocol 4403 Options Block (see section 7.1) of the IOTP Transaction. They contains 4404 lists of: 4405 o payment Brands (see also section 3.6 Brands and Brand 4406 Selection), 4407 o amounts to be paid in the currencies that are accepted or 4408 offered by the Merchant, 4409 o the payment protocols which can be used to make payments with 4410 a Brand, and 4411 o the net locations of the Payment Handlers which accept payment 4412 for a payment protocol 4414 The definition of a Brand List Component is as follows. 4416 4418 4424 Attributes: 4426 ID An identifier which uniquely identifies the Brand 4427 List Component within the IOTP Transaction. 4429 xml:lang Defines the language used by attributes or child 4430 elements within this component, unless overridden 4431 by an xml:lang attribute on a child element. See 4432 section 3.9 Identifying Languages. 4434 ShortDesc A text description in the language defined by 4435 xml:Lang giving details of the purpose of the 4436 Brand List. This information must be displayed to 4437 the receiver of the Brand List in order to assist 4438 with making the selection. It is of particular 4439 benefit in allowing a Consumer to distinguish the 4440 purpose of a Brand List when an IOTP Transaction 4441 involves more than one payment. 4443 PayDirection Indicates the direction in which the payment for 4444 which a Brand is being selected is to be made. Its 4445 values may be: 4446 o Debit The sender of the Payment Request Block 4447 (e.g. the Consumer) to which this Brand List 4448 relates will make the payment to the Payment 4449 Handler, or 4450 o Credit The sender of the Payment Request Block 4451 to which this Brand List relates will receive a 4452 payment from the Payment Handler. 4454 Content: 4456 Brand This describes a Brand. The sequence of the Brand 4457 elements (see section 6.6.1) within the Brand List 4458 does not indicate any preference. It is 4459 recommended that software which processes this 4460 Brand List presents Brands in a sequence which the 4461 receiver of the Brand List prefers. 4463 ProtocolAmount This links a particular Brand to: 4464 o the currencies and amounts in CurrencyAmount 4465 elements that can be used with the Brand, and 4466 o the Payment Protocols and Payment Handlers, 4467 which can be used with those currencies and 4468 amounts, and a particular Brand 4470 CurrencyAmount This contains a currency code and an amount. 4472 PayProtocol This contains information about a Payment Protocol 4473 and the Payment Handler which may be used with a 4474 particular Brand. 4476 The relationships between the elements which make up the content of 4477 the Brand List is illustrated in the diagram below. 4479 Brand List 4480 Component 4481 | 4482 |-Brand 4483 | Element 4484 | | 4485 | |Protocol 4486 | | AmountRefs 4487 | v 4488 |-Protocol Amount 4489 | Element---------- 4490 | | | 4491 | |Currency |Pay 4492 | | AmountRefs |Protocol 4493 | v |Ref 4494 |-Currency Amount | 4495 | Element | 4496 | | 4497 -PayProtocol<----- 4498 Element 4500 Figure 17 Brand List Element Relationships 4502 Examples of complete Brand Lists are contained in section 10 Brand 4503 List Examples. 4505 6.6.1 Brand Element 4507 A Brand Element describes a brand that can be used for making a 4508 payment. One or more of these elements is carried in each Brand List 4509 Component that has the PayDirection attribute set to Debit. Exactly 4510 one Brand Element may be carried in a Brand List Component that has 4511 the PayDirection attribute set to Credit. 4513 4514 4524 Attributes: 4526 Id Element identifier, potentially referenced in a 4527 Brand Selection Component contained in a later 4528 Payment Request message and uniquely identifies 4529 the Brand element within the IOTP Transaction. 4531 xml:lang Defines the language used by attributes and 4532 content of this element. See section 3.9 4533 Identifying Languages. 4535 BrandId This contains a unique identifier for the brand or 4536 promotional brand. It is used to match against a 4537 list of Payment Instruments which the Consumer 4538 holds to determine whether or not the Consumer can 4539 pay with the Brand. 4541 The syntax for a BrandId is as follows: 4543 BrandId ::= UserDefinedCode | 4544 BrandIdDomain ":" BrandValue 4546 Currently the only valid value for the 4547 BrandIdDomain is IOTP which indicates that the 4548 BrandValue is registered with IOTP. 4550 The valid values for BrandValue for brands defined 4551 within the IOTP Brand domain are obtainable from 4552 the IOTP web site http:www.IOTP.org. 4554 A user defined code follows the conventions 4555 defined in section 3.7.3. Uniqueness of a user 4556 defined BrandId is not guaranteed. 4558 BrandName This contains the name of the brand, for example 4559 MasterCard Credit. This is the description of the 4560 Brand which is displayed to the consumer in the 4561 Consumers language defined by xml:lang. For 4562 example it might be "American Airlines Advantage 4563 Visa". Note that this attribute is not used for 4564 matching against the payment instruments held by 4565 the Consumer. 4567 BrandLogoNetLocn The net location which can be used to download the 4568 logo for the organisation. See section Retrieving 4569 Logos (see section 9). 4571 The content of this attribute must conform to 4572 [RFC1738]. 4574 BrandNarrative This optional attribute is designed to be used by 4575 the Merchant to indicate some special conditions 4576 or benefit which would apply if the Consumer 4577 selected that brand. For example "5% discount", 4578 "free shipping and handling", "free breakage 4579 insurance for 1 year", "double air miles apply", 4580 etc. 4582 ProtocolAmountRefs Identifies the protocols and related currencies 4583 and amounts which can be used with this Brand. 4584 Specified as a list of ID's of Protocol Amount 4585 Elements (see section 6.6.2) contained within the 4586 Brand List. 4588 ContentSoftwareId This optional attribute contains information which 4589 identifies the software which generated the 4590 content of the element. Its purpose is to help 4591 resolve interoperability problems that might occur 4592 as a result of incompatibilities between messages 4593 produced by different software. It is a single 4594 text string in the language defined by xml:lang. 4595 It must contain, as a minimum: 4596 o the name of the software manufacturer 4597 o the name of the software 4598 o the version of the software, and 4599 o the build of the software 4601 It is recommended that this attribute is included 4602 if the software which generated the content cannot 4603 be identified from the SoftwareId attribute on the 4604 Message Id Component (see section 3.3.2) 4606 Content: 4608 PackagedContent Optional Packaged Content (see section 3.8) 4609 containing information about the brand which may 4610 be used by the payment protocol. The content of 4611 this information is defined in the supplement for 4612 a payment protocol which describes how the payment 4613 protocol works with IOTP. 4615 Examples Brand Elements are contained in section 10 Brand List 4616 Examples. 4618 6.6.2 Protocol Amount Element 4620 The Protocol Amount element links a Brand to: 4621 o the currencies and amounts in Currency Amount Elements (see 4622 section 6.6.3) that can be used with the Brand, and 4623 o the Payment Protocols and Payment Handlers defined in a Pay 4624 Protocol Element (see section 6.6.4), which can be used with 4625 those currencies and amounts. 4627 Its definition is as follows: 4629 4630 4636 Attributes: 4638 Id Element identifier, potentially referenced in a 4639 Brand element; or in a Brand Selection Component 4640 contained in a later Payment Request message which 4641 uniquely identifies the Protocol Amount element 4642 within the IOTP Transaction. 4644 PayProtocolRef Contains an Element Reference (see section 3.5) 4645 that refers to the Pay Protocol Element (see 4646 section 6.6.4) that contains the Payment Protocol 4647 and Payment Handlers that can be used with the 4648 Brand. 4650 CurrencyamountRefs Contains a list of Element References (see 4651 section 3.5) that refer to the Currency Amount 4652 Element (see section 6.6.3) that describes the 4653 currencies and amounts that can be used with the 4654 Brand. 4656 ContentSoftwareId This contains information which identifies the 4657 software which generated the content of the 4658 element. Its purpose is to help resolve 4659 interoperability problems that might occur as a 4660 result of incompatibilities between messages 4661 produced by different software. It is a single 4662 text string in the language defined by xml:lang. 4663 It must contain, as a minimum: 4664 o the name of the software manufacturer 4665 o the name of the software 4666 o the version of the software, and 4667 o the build of the software 4669 It is recommended that this attribute is included 4670 if the software which generated the content cannot 4671 be identified from the SoftwareId attribute on the 4672 Message Id Component (see section 3.3.2) 4674 Content: 4676 PackagedContent Optional Packaged Content (see section 3.8) 4677 containing information about the protocol amount 4678 which may be used by the payment protocol. The 4679 content of this information is defined in the 4680 supplement for a payment protocol which describes 4681 how the payment protocol works with IOTP. 4683 Examples Protocol Amount Elements are contained in10 Brand List 4684 Examples. 4686 6.6.3 Currency Amount Element 4688 A Currency Amount element contains: 4689 o a currency code (and its type), and 4690 o an amount. 4692 One or more of these elements is carried in each Brand List Component. 4693 Its definition is as follows: 4695 4696 4702 Attributes: 4704 Id Element identifier, potentially referenced in a 4705 Brand element; or in a Brand Selection Component 4706 contained in a later Payment Request message which 4707 uniquely identifies the Currency Amount Element 4708 within the IOTP Transaction. 4710 Amount Indicates the amount to be paid in whole and 4711 fractional units of the currency. For example 4712 $245.35 would be expressed "245.35". Note that 4713 values smaller than the smallest denomination are 4714 allowed. For example one tenth of a cent would be 4715 "0.001". 4717 CurrCodeType Indicates the domain of the CurrCode. This 4718 attribute is included so that the currency code 4719 may support non-standard "currencies" such as 4720 frequent flyer points, trading stamps, etc. Its 4721 values may be: 4723 o ISO4217 indicates the currency code conforms to 4724 [ISO 4217] 4725 o x-ddd:nnn a user defined currency code type 4726 (see section 3.7.3 User Defined Codes). 4728 CurrCode A code which identifies the currency to be used in 4729 the payment. The domain of valid currency codes is 4730 defined by CurrCodeType 4732 Note that Amount, CurrCodeType and CurrCode have identical meanings to 4733 the attributes of the same name on the Payment Component (see section 4734 6.8). 4736 Examples Currency Amount Elements are contained in 10 Brand List 4737 Examples. 4739 6.6.4 Pay Protocol Element 4741 A Pay Protocol element specifies details of a Payment Protocol and the 4742 Payment Handler that can be used with a Brand. One or more of these 4743 elements is carried in each Brand List. 4745 4746 4756 Attributes: 4758 Id Element identifier, potentially referenced in a 4759 Brand element; or in a Brand Selection Component 4760 contained in a later Payment Request message which 4761 uniquely identifies the Pay Protocol element 4762 within the IOTP Transaction. 4764 xml:lang Defines the language used by attributes and 4765 content of this element. See section 3.9 4766 Identifying Languages. 4768 ProtocolId Consists of a protocol name and version. For 4769 example "SETv1.0". 4771 The value used for the ProtocolId is defined in 4772 the payment supplement for the payment method. 4774 ProtocolName A narrative description of the payment protocol 4775 and its version in the language identified by 4776 xml:lang. For example "Secure Electronic 4777 Transaction Version 1.0". Its purpose is to help 4778 provide information on the payment protocol being 4779 used if problems arise. 4781 ActionOrgRef An Element Reference (see section 3.5) to the 4782 Organisation Component for the Payment Handler for 4783 the Payment Protocol. 4785 PayReqNetLocn The Net Location indicating where an unsecured 4786 Payment Request message should be sent if this 4787 protocol choice is used. 4789 The content of this attribute is dependent on the 4790 Transport Mechanism (such must conform to 4791 [RFC1738]. 4793 SecPayReqNetLocn The Net Location indicating where a secured 4794 Payment Request message should be sent if this 4795 protocol choice is used. 4797 A secured payment involves the use of a secure 4798 channel such as [SSL] in order to communicate with 4799 the Payment Handler. 4801 The content of this attribute must conform to 4802 [RFC1738]. See also See section 3.10 Secure and 4803 Insecure Net Locations. 4805 ContentSoftwareId This contains information which identifies the 4806 software which generated the content of the 4807 element. Its purpose is to help resolve 4808 interoperability problems that might occur as a 4809 result of incompatibilities between messages 4810 produced by different software. It is a single 4811 text string in the language defined by xml:lang. 4812 It must contain, as a minimum: 4813 o the name of the software manufacturer 4814 o the name of the software 4815 o the version of the software, and 4816 o the build of the software 4818 It is recommended that this attribute is included 4819 if the software which generated the content cannot 4820 be identified from the SoftwareId attribute on the 4821 Message Id Component (see section 3.3.2) 4823 Content: 4825 PackagedContent Optional Packaged Content information (see section 4826 3.8) about the protocol which is used by the 4827 payment protocol. The content of this information 4828 is defined in the supplement for a payment 4829 protocol which describes how the payment protocol 4830 works with IOTP. An example of its use could be to 4831 include a payment protocol message. 4833 Examples Pay Protocol Elements are contained in section 6.6 Brand List 4834 Component. 4836 6.7 Brand Selection Component 4838 A Brand Selection Component identifies the choice of payment brand, 4839 payment protocol and the Payment Handler. This element is used: 4840 o in Payment Request messages within Baseline Purchase and 4841 Baseline Value IOTP Transactions to identify the brand, 4842 protocol and payment handler for a payment, or 4843 o to, optionally, inform a merchant in a purchase of the payment 4844 brand being used so that the offer and order details can be 4845 amended accordingly. 4847 In Baseline IOTP, the integrity of Brand Selection Components is not 4848 guaranteed. However, modification of Brand Selection Components can 4849 only cause denial of service if the payment protocol itself is secure 4850 against message modification, duplication, and swapping attacks. 4852 The definition of a Brand Selection Component is as follows. 4854 4857 4864 Attributes: 4866 ID An identifier which uniquely identifies the Brand 4867 Selection Component within the IOTP Transaction. 4869 BrandListRef The Element Reference (see section 3.5) of the 4870 Brand List Component from which a Brand is being 4871 selected 4873 BrandRef The Element Reference of a Brand element within 4874 the Brand List Component that is being selected 4875 that is to be used in the payment. 4877 ProtocolAmountRef The Element Reference of a Protocol Amount element 4878 within the Brand List Component which is to be 4879 used when making the payment. 4881 CurrencyAmountRef The Element Reference of a Currency Amount element 4882 within the Brand List Component which is to be 4883 used when making the payment. 4885 Content: 4887 BrandSelBrandInfo, This contains any additional data that 4888 BrandSelProtocolAmountInfo, may be required by a particular payment 4889 BrandSelCurrencyAmountInfo brand or protocol. See sections 6.7.1, 4890 6.7.2, and 6.7.3. 4892 The following rules apply: 4893 o the BrandListRef must contain the ID of a Brand List Component 4894 in the same IOTP Transaction 4895 o every Brand List Component in the Trading Protocol Options 4896 Block must be referenced by one and only one Brand Selection 4897 Component 4898 o the BrandRef must refer to the ID of a Brand contained within 4899 the Brand List Component referred to by BrandListRef 4900 o the ProtocolAmountRef must refer to one of the Element IDs 4901 listed in the ProtocolAmountRefs attribute of the Brand 4902 element identified by BrandRef 4903 o the CurrencyAmountRef must refer to one of the Element IDs 4904 listed in the CurrencyAmountRefs attribute of the Protocol 4905 Amount Element identified by ProtocolAmountRef. 4907 An example of a Brand Selection Component is included in 10 Brand List 4908 Examples. 4910 6.7.1 Brand Selection Brand Info Element 4912 The Brand Selection Brand Info Element contains any additional data 4913 that may be required by a particular payment brand. See the IOTP 4914 payment method supplement for a description of how and when it used. 4916 4917 4921 Attributes: 4923 ContentSoftwareId This contains information which identifies the 4924 software which generated the content of the 4925 element. Its purpose is to help resolve 4926 interoperability problems that might occur as a 4927 result of incompatibilities between messages 4928 produced by different software. It is a single 4929 text string in the language defined by xml:lang. 4930 It must contain, as a minimum: 4932 o the name of the software manufacturer 4933 o the name of the software 4934 o the version of the software, and 4935 o the build of the software 4937 It is recommended that this attribute is included 4938 if the software which generated the content cannot 4939 be identified from the SoftwareId attribute on the 4940 Message Id Component (see section 3.3.2) 4942 Content: 4944 PackagedContent Packaged Content information (see section 3.8) 4945 that contains additional data that may be required 4946 by a particular payment brand. See the payment 4947 method supplement for IOTP for rules on how this 4948 is used. 4950 6.7.2 Brand Selection Protocol Amount Info Element 4952 The Brand Selection Protocol Amount Info Element contains any 4953 additional data that is payment protocol specific that may be required 4954 by a particular payment brand or payment protocol. See the IOTP 4955 payment method supplement for a description of how and when it used. 4957 4958 4962 Attributes: 4964 ContentSoftwareId See section 6.7.1 Brand Selection Brand Info 4965 Element. 4967 Content: 4969 PackagedContent Packaged Content information (see section 3.8) 4970 that contains any additional data that may be 4971 required by a particular payment brand. See the 4972 payment method supplement for IOTP for rules on 4973 how this is used. 4975 6.7.3 Brand Selection Currency Amount Info Element 4977 The Brand Selection Currency Amount Info Element contains any 4978 additional data that is payment brand and currency specific that may 4979 be required by a particular payment brand. See the IOTP payment method 4980 supplement for a description of how and when it used. 4982 4983 4987 Attributes: 4989 ContentSoftwareId See section 6.7.1 Brand Selection Brand Info 4990 Element. 4992 Content: 4994 PackagedContent Packaged Content information (see section 3.8) 4995 that contains any additional data relating to the 4996 payment brand and currency. See the payment method 4997 supplement for IOTP for rules on how this is used. 4999 6.8 Payment Component 5001 A Payment Component contains information used to control how a payment 5002 is carried out. Its provides information on: 5003 o the times within which a Payment with a Payment Handler may be 5004 started 5005 o a reference to the Brand List (see section 6.6) which 5006 identifies the Brands, protocols, currencies and amounts which 5007 can be used to make a payment 5008 o whether or not an authentication of the consumer is required 5009 as part of the payment 5010 o whether or not a payment receipt will be provided 5011 o whether another payment precedes this payment. 5013 Its definition is as follows. 5015 5016 5025 Attributes: 5027 ID An identifier which uniquely identifies the 5028 Payment Component within the IOTP Transaction. 5030 OkFrom The date and time in [UTC] format after which a 5031 Payment Handler may accept for processing a 5032 Payment Request Block (see section 7.6) containing 5033 the Payment Component. 5035 OkTo The date and time in [UTC] format before which a 5036 Payment Handler may for processing accept a 5037 Payment Request Block containing the Payment 5038 Component. 5040 BrandListRef An Element Reference (see section 3.5) of a Brand 5041 List Component (see section 6.6) within the TPO 5042 Trading Block for the IOTP Transaction. The Brand 5043 List identifies the alternative ways in which the 5044 payment can be made. 5046 AuthDataRef An element reference (see section 3.4) of an 5047 Authentication Data Component (see section 6.2) 5048 which is to be used for authentication of the 5049 Trading Role which sends the Payment Request Block 5050 containing the Payment Component to the Payment 5051 Handler. If not present, then no authentication is 5052 to take place. 5054 SignedPayReceipt Indicates whether or not the Payment Response 5055 Block (7.8) generated by the payment handler for 5056 the payment must be digitally signed. 5058 StartAfter Contains Element References (see section 3.5) of 5059 other Payment Components which describe payments 5060 which must be complete before this payment can 5061 start. If no StartAfter attribute is present then 5062 there are no dependencies and the payment can 5063 start immediately 5065 Contents 5067 PackagedContent This optional element contains "user" data defined 5068 by the Merchant which is required by the Payment 5069 Handler. See section 3.8 Packaged Content Element. 5071 6.9 Payment Scheme Component 5073 A Payment Scheme Component contains payment protocol information for a 5074 specific payment scheme which is transferred between the parties 5075 involved in a payment for example a [SET] message. Its definition is 5076 as follows. 5078 5079 5085 Attributes: 5087 ID An identifier which uniquely identifies the 5088 Payment Scheme Component within the IOTP 5089 Transaction. 5091 ConsumerPaymentId An identifier specified by the Consumer which, 5092 if returned by the Payment Handler in another 5093 Payment Scheme Component or by other means, will 5094 enable the Consumer to identify which payment is 5095 being referred to. 5097 PaymentHandlerPayId An identifier specified by the Payment Handler 5098 which, if returned by the Consumer in another 5099 Payment Scheme Component, or by other means, 5100 will enable the Payment Handler to identify 5101 which payment is being referred to. It is 5102 required on every Payment Scheme Component apart 5103 from the one contained in a Payment Request 5104 Block. 5106 ContentSoftwareId This contains information which identifies the 5107 software which generated the content of the 5108 element. Its purpose is to help resolve 5109 interoperability problems that might occur as a 5110 result of incompatibilities between messages 5111 produced by different software. It is a single 5112 text string in the language defined by xml:lang. 5113 It must contain, as a minimum: 5114 o the name of the software manufacturer 5115 o the name of the software 5116 o the version of the software, and 5117 o the build of the software 5119 It is recommended that this attribute is 5120 included if the software which generated the 5121 content cannot be identified from the SoftwareId 5122 attribute on the Message Id Component (see 5123 section 3.3.2) 5125 Content: 5127 PackagedContent Contains the payment scheme protocol information 5128 as Packaged Content (see section 3.8). See the 5129 payment scheme supplement for the definition of 5130 its content. 5132 6.10 Payment Receipt Component 5134 A Payment Receipt is a record of a payment which demonstrates how much 5135 money has been paid or received. It is distinct from a purchase 5136 receipt in that it contains no record of what was being purchased. 5138 Typically the content of a Payment Receipt Component will contain data 5139 which describes: 5140 o the amount paid and its currency 5141 o the date and time of the payment 5142 o internal reference numbers which identify the payment to the 5143 payment system 5144 o potentially digital signatures generated by the payment method 5145 which can be used to prove after the event that the payment 5146 occurred. 5148 If the Payment Method being used provides the facility then the 5149 Payment Receipt Component should contain payment protocol messages, or 5150 references to messages, which prove the payment occurred. 5152 The precise definition of the content is Payment Method dependent. 5153 Refer to the supplement for the payment method being used to determine 5154 the rules that apply. 5156 Information contained in the Payment Receipt Component should be 5157 displayed or otherwise made available to the Consumer. 5159 [Note] If the Payment Receipt Component contains Payment Protocol 5160 Messages, then the Messages will need to be processed by 5161 Payment Method software to convert it into a format which 5162 can be understood by the Consumer 5163 [Note End] 5165 The definition of a Payment Receipt Component is as follows. 5167 5168 5174 Attributes: 5176 ID An identifier which uniquely identifies the 5177 Payment Receipt Component within the IOTP 5178 Transaction. 5180 PaymentRef Contains an Element Reference (see section 3.5) to 5181 the Payment Component (see section 6.8) to which 5182 this payment receipt applies 5184 PayReceiptRefs Optionally contains Element References to other 5185 Components (potentially including Pay Scheme 5186 Components) which together make up the receipt. 5187 Note that: 5188 o each payment scheme defines in its supplement 5189 the elements which must be referenced. 5190 o each of the components referenced must be 5191 hashed and signed in the Payment Response 5192 signature component, if one is being used. 5194 The client software should save all the components 5195 referenced so that the payment receipt can be 5196 reconstructed when required. 5198 ContentSoftwareId This contains information which identifies the 5199 software which generated the content of the 5200 element. Its purpose is to help resolve 5201 interoperability problems that might occur as a 5202 result of incompatibilities between messages 5203 produced by different software. It is a single 5204 text string in the language defined by xml:lang. 5205 It must contain, as a minimum: 5206 o the name of the software manufacturer 5207 o the name of the software 5208 o the version of the software, and 5209 o the build of the software 5211 It is recommended that this attribute is included 5212 if the software which generated the content cannot 5213 be identified from the SoftwareId attribute on the 5214 Message Id Component (see section 3.3.2) 5216 Content: 5218 PackagedContent Optionally contains the payment scheme specific 5219 record of the payment which can be used for 5220 receipt purposes as Packaged Content (see section 5221 3.8). Each payment scheme defines in its 5222 supplement the structure of the content. 5224 Note that either the PayReceiptRefs attribute, the PackagedContent 5225 element, or both must be present. 5227 6.11 Payment Note Component 5229 The Payment Note Component contains additional, non payment related, 5230 information which the Payment Handler wants to provide to the 5231 Consumer. For example, if a withdrawal or deposit were being made then 5232 it could contain information on the remaining balance on the account 5233 after the transfer was complete. The information should duplicate 5234 information contained within the Payment Receipt Component. 5236 Information contained in the Payment Note Component should be 5237 displayed or otherwise made available to the Consumer. For 5238 interoperability, the Payment Note Component should support, as a 5239 minimum, a content type of "Plain/Text". Its definition is as follows. 5241 5242 5246 Attributes: 5248 ID An identifier which uniquely identifies the 5249 Payment Receipt Component within the IOTP 5250 Transaction. 5252 ContentSoftwareId This contains information which identifies the 5253 software which generated the content of the 5254 element. Its purpose is to help resolve 5255 interoperability problems that might occur as a 5256 result of incompatibilities between messages 5257 produced by different software. It is a single 5258 text string in the language defined by xml:lang. 5259 It must contain, as a minimum: 5260 o the name of the software manufacturer 5261 o the name of the software 5262 o the version of the software, and 5263 o the build of the software 5265 It is recommended that this attribute is included 5266 if the software which generated the content cannot 5267 be identified from the SoftwareId attribute on the 5268 Message Id Component (see section 3.3.2) 5270 Content: 5272 PackagedContent Contains additional, non payment related, 5273 information which the Payment Handler wants to 5274 provide to the Consumer as Packaged Content (see 5275 section 3.8). 5277 6.12 Delivery Component 5279 The Delivery Element contains information required to deliver goods or 5280 services. Its definition is as follows. 5282 5283 5291 Attributes: 5293 ID An identifier which uniquely identifies the 5294 Delivery Component within the IOTP Transaction. 5296 xml:lang Defines the language used by attributes or child 5297 elements within this component, unless 5298 overridden by an xml:lang attribute on a child 5299 element. See section 3.9 Identifying Languages. 5301 DelivExch Indicates if this IOTP Transaction includes the 5302 messages associated with a Delivery Exchange. 5303 Valid values are: 5304 o True indicates it does include a Delivery 5305 Exchange 5306 o False indicates it does not include a Delivery 5307 Exchange 5309 If set to true then a DeliveryData element must 5310 be present. If set to false it may be absent. 5312 DelivAndPayResp Indicates if the Delivery Response Block (see 5313 section 7.10) and the Payment Response Block 5314 (see section 7.8 ) are combined into one IOTP 5315 Message. Valid values are: 5316 o True indicates both blocks will be in the same 5317 IOTP Message, and 5318 o False indicates each block will be in a 5319 different IOTP Message 5321 DelivAndPayResp should not be true if DelivExch 5322 is False. 5324 In practice combining the Delivery Response 5325 Block and Payment Response Block is only likely 5326 to be practical if the Merchant, the Payment 5327 Handler and the Delivery Handler are the same 5328 organisation since: 5329 o the Payment Handler must have access to Order 5330 Component information so that they know what 5331 to deliver, and 5332 o the Payment Handler must be able to carry out 5333 the delivery 5335 ActionOrgRef An Element Reference to the Organisation 5336 Component of the Delivery Handler for this 5337 delivery. 5339 ConsumerDeliveryId An identifier specified by the Consumer which, 5340 if returned by the Delivery Handler in another 5341 Delivery Component, or by other means, will 5342 enable the Consumer to identify which Delivery 5343 is being referred to. 5345 Content: 5347 DeliveryData Contains details about how the delivery will be 5348 carried out. See 6.12.1 Delivery Data Element 5349 below. 5351 PackagedContent This optional element contains "user" data defined 5352 for the Merchant which is required by the Delivery 5353 Handler. See section 3.8 Packaged Content Element. 5355 6.12.1 Delivery Data Element 5357 The DeliveryData element contains information about where and how 5358 goods are to be delivered. Its definition is as follows. 5360 5361 5371 Attributes: 5373 xml:lang Defines the language used by attributes within 5374 this component. See section 3.9 Identifying 5375 Languages. 5377 OkFrom The date and time in [UTC] format after which the 5378 Delivery Handler may accept for processing a 5379 Delivery Request Block (see section 7.9). 5381 OkTo The date and time in [UTC] format before which the 5382 Delivery Handler may accept for processing a 5383 Delivery Request Block. 5385 DelivMethod Indicates the method by which goods or services 5386 may be delivered. Valid values are: 5387 o Post the goods will be delivered by post or 5388 courier 5389 o Web the goods will be delivered electronically 5390 in the Delivery Note Component 5391 o Email the goods will be delivered 5392 electronically by e-mail 5393 o x-ddd:nnn a user defined delivery method see 5394 3.7.3 User Defined Codes. 5396 DelivToRef The Element Reference (see section 3.4) of an 5397 Organisation Component within the IOTP Transaction 5398 which has a role of DelivTo. The information in 5399 this block is used to determine where delivery is 5400 to be made. It must be compatible with 5401 DelivMethod. Specifically if the DelivMethod is: 5402 o Post, then the there must be a Postal Address 5403 Element containing sufficient information for a 5404 postal delivery, 5405 o Web, then there are no specific requirements. 5406 The information will be sent in a web page back 5407 to the Consumer 5408 o Email, then there must be Contact Information 5409 Element with a valid e-mail address 5411 DelivReqNetLocn This contains the Net Location to which an 5412 unsecured Delivery Request Block (see section 7.9) 5413 which contains the Delivery Component should be 5414 sent. 5416 The content of this attribute is dependent on the 5417 Transport Mechanism must conform to [RFC1738]. 5419 SecDelivReqNetLocn This contains the Net Location to which a secured 5420 Delivery Request Block (see section 7.9) which 5421 contains the Delivery Component should be sent. 5423 A secured delivery request involves the use of a 5424 secure channel such as [SSL] in order to 5425 communicate with the Payment Handler. 5427 The content of this attribute is dependent on the 5428 Transport Mechanism must conform to [RFC1738]. 5430 See also Section 3.10 Secure and Insecure Net 5431 Locations. 5433 ContentSoftwareId This contains information which identifies the 5434 software which generated the content of the 5435 element. Its purpose is to help resolve 5436 interoperability problems that might occur as a 5437 result of incompatibilities between messages 5438 produced by different software. It is a single 5439 text string in the language defined by xml:lang. 5440 It must contain, as a minimum: 5441 o the name of the software manufacturer 5442 o the name of the software 5443 o the version of the software, and 5444 o the build of the software 5446 It is recommended that this attribute is included 5447 if the software which generated the content cannot 5448 be identified from the SoftwareId attribute on the 5449 Message Id Component (see section 3.3.2) 5451 Content: 5453 PackagedContent Optional additional information about the delivery 5454 as Packaged Content (see section 3.8). provided to 5455 the Delivery Handler by the merchant. 5457 6.13 Delivery Note Component 5459 A Delivery Note contains delivery instructions about the delivery of 5460 goods or services or potentially the actual Delivery Information 5461 itself. It is information which the person or organisation receiving 5462 the Delivery Note can use when delivery occurs. 5464 5465 5471 Attributes: 5473 ID An identifier which uniquely identifies the 5474 Delivery Note Component within the IOTP 5475 Transaction. 5477 xml:lang Defines the language used by attributes or child 5478 elements within this component, unless overridden 5479 by an xml:lang attribute on a child element. See 5480 section 3.9 Identifying Languages. 5482 DelivHandlerDeliv An optional identifier specified by the Delivery 5483 Id Handler which, if returned by the Consumer in 5484 another Delivery Component, or by other means, 5485 will enable the Delivery Handler to identify which 5486 Delivery is being referred to. It is required on 5487 every Delivery Component apart from the one 5488 contained in a Delivery Request Block. 5490 An example use of this attribute is to contain a 5491 delivery tracking number. 5493 ContentSoftwareId This contains information which identifies the 5494 software which generated the content of the 5495 element. Its purpose is to help resolve 5496 interoperability problems that might occur as a 5497 result of incompatibilities between messages 5498 produced by different software. It is a single 5499 text string in the language defined by xml:lang. 5500 It must contain, as a minimum: 5501 o the name of the software manufacturer 5502 o the name of the software 5503 o the version of the software, and 5504 o the build of the software 5506 It is recommended that this attribute is included 5507 if the software which generated the content cannot 5508 be identified from the SoftwareId attribute on the 5509 Message Id Component (see section 3.3.2) 5511 Content: 5513 DeliveryNote Contains the actual delivery note information as 5514 Packaged Content (see section 3.8). 5516 [Note] If the content of the Delivery Message is a Mime message 5517 then the Delivery Note may trigger an application which 5518 causes the actual delivery to occur. 5519 [Note End] 5521 6.14 Payment Method Information Component 5523 A Payment Method Information Component contains data which describes 5524 the Payment Method which initiated the Payment Instrument Customer 5525 Care Transaction and the software which generated the message. Its 5526 definition is as follows. 5528 5529 5534 Attributes: 5536 ID An identifier which uniquely identifies the 5537 Payment Method Information Component within the 5538 IOTP Transaction. 5540 BrandId The Brand Identifier attribute copied from the 5541 BrandId attribute of the Brand Element (see 5542 section 6.6.1)of the Payment Instrument which 5543 needs customer care. 5545 PayProtocolId The ProtocolId attribute copied from the Pay 5546 Protocol Element (see section 6.6.4) of the Brand 5547 being used. This may not be required for all types 5548 of Payment Instrument. See the IOTP Supplement for 5549 the Payment Method to determine if this is to be 5550 used. 5552 6.15 Status Component 5554 A Status Component contains status information about the business 5555 success or failure (see section 4.2) of a process. 5557 Its definition is as follows. 5559 5560 5571 Attributes: 5573 ID An identifier which uniquely identifies the Status 5574 Component within the IOTP Transaction. 5576 xml:lang Defines the language used by attributes within 5577 this component. See section 3.9 Identifying 5578 Languages. 5580 StatusType Indicates the type of process which the Status is 5581 reporting on. It may be set to either Offer, 5582 Payment, Delivery or Authentication 5584 ElRef Contains an Element Reference (see section 3.5) to 5585 the Component for which the Status is being 5586 described. It must refer to either: 5587 o a Trading Protocol Options Block (see section 5588 7.1), if the StatusType is Offer, 5589 o a Payment Component (see section 6.8), if the 5590 StatusType is Payment, or 5591 o a Delivery Component (see section 6.12), if the 5592 StatusType is Delivery 5593 o an Authentication Data Component (see section 5594 6.2) if the statusType is Authentication. 5596 ProcessState Contains a State Code which indicates the current 5597 state of the process being carried out. Valid 5598 values for ProcessState are: 5599 o NotYetStarted. A Request Block has been 5600 received but the process has not yet started 5601 o InProgress. Processing of the Request Block has 5602 started but it is not yet complete 5603 o CompletedOk. The processing of the Request 5604 Block has completed successfully without any 5605 errors 5606 o Failed. The processing of the Request Block has 5607 failed because of a business error (see section 5608 4.2) 5609 o ProcessError. This value is only used when the 5610 Status Component is being used in connection 5611 with an Inquiry Request Trading Block (see 5612 section 7.14). It indicates there was a 5613 Technical Error (see section 4.1) in the Request 5614 Block which is being processed or some internal 5615 processing error. 5617 Note that this code reports on the processing of a 5618 Request Block. Further, asynchronous processing 5619 may occur after the Response Block associated with 5620 the Process has been sent. 5622 CompletionCode Indicates how the process completed. Valid values 5623 for the CompletionCode are given below together 5624 with the conditions when it must be present. 5626 A CompletionCode is a maximum of 14 characters 5627 long. 5629 ProcessReference This optional attribute holds a reference for the 5630 process whose status is being reported. It may 5631 hold the following values: 5632 o when StatusType is set to Offer, it should 5633 contain the OrderIdentifier from the Order 5634 Component 5635 o when StatusType is set to Payment, it should 5636 contain the PaymentHandlerPayId from the Payment 5637 Scheme Data Component 5638 o when StatusType is set to Delivery, it should 5639 contain the DelivHandlerDelivId from the 5640 Delivery Note Component 5641 o when StatusType is set to Authentication, it 5642 should contain the AuthenticationId from the 5643 Authentication Data Component 5645 This attribute should be absent in the Inquiry 5646 Request message when the Consumer has not been 5647 given such a reference number by the IOTP Service 5648 Provider. 5650 This attribute can be used in an Inquiry Response 5651 Block (see section 7.15) to give the reference 5652 number for a transaction which has previously been 5653 unavailable. 5655 For example, the package tracking number might not 5656 be assigned at the time a delivery response was 5657 received. However, if the Consumer issues a 5658 Baseline Transaction Status Inquiry later, the 5659 Delivery Handler can put the package tracking 5660 number into this attribute in the Inquiry Response 5661 message and send it back to the Consumer. 5663 StatusDesc An optional textual description of the current 5664 status of the process in the language identified 5665 by xml:lang. 5667 6.15.1.1 Offer Completion Codes 5669 The Completion Code is only required if the ProcessState attribute is 5670 set to Failed. The following table contains the valid values for the 5671 CompletionCode that may be used. It is recommended that the StatusDesc 5672 attribute is used to provide further explanation where appropriate. 5674 Value Description 5676 AuthError Authentication Error. The check of the 5677 Authentication Response which was carried out has 5678 failed. 5680 OfferDecl Offer Declined. The Merchant declines to generate 5681 an offer for some reason. 5683 Unspecified Unspecified error. There is some unknown problem 5684 or error which does not fall into one of the other 5685 CompletionCodes. 5687 6.15.1.2 Payment Completion Codes 5689 The CompletionCode is only required if the ProcessState attribute is 5690 set to Failed. The following table contains the valid values for the 5691 CompletionCode that may be used. It is recommended that the StatusDesc 5692 attribute is used by individual payment schemes to provide further 5693 explanation where appropriate. 5695 Value Description 5697 BrandNotSupp Brand not supported. The payment brand is not 5698 supported by the Payment Handler. 5700 CurrNotSupp Currency not supported. The currency in which the 5701 payment is to be made is not supported by either 5702 the Payment Instrument or the Payment Handler. 5704 AuthError Authentication Error. The Payment Scheme specific 5705 authentication check which was carried out has 5706 failed. 5708 InsuffFunds Insufficient funds. There are insufficient funds 5709 available for the payment to be made. 5711 InstBrandInvalid Payment Instrument not valid for Brand. A Payment 5712 Instrument is being used which does not correspond 5713 with the Brand selected. For example a Visa credit 5714 card is being used when MasterCard was selected as 5715 the Brand. 5717 PaymntDecl Payment declined. The Payment Handler declines to 5718 accept the payment for some reason. 5720 InstNotValid Payment instrument not valid for trade. The 5721 Payment Instrument cannot be used for the proposed 5722 type of trade, for some reason. 5724 BadInstrumenat Bad instrument. There is a problem with the 5725 Payment Instrument being used which means that it 5726 is unable to be used for the payment. 5728 Unspecified Unspecified error. There is some unknown problem 5729 or error which does not fall into one of the other 5730 CompletionCodes. The StatusDesc attribute should 5731 provide the explanation of the cause. 5733 6.15.1.3 Delivery Completion Codes 5735 The following table contains the valid values for the CompletionCode 5736 attribute for a Delivery. It is recommended that the StatusDesc 5737 attribute is used to provide further explanation where appropriate. 5739 Value Description 5741 BackOrdered Back Ordered. The goods to be delivered are on 5742 order but they have not yet been received. 5744 Shipping will be arranged when they are received. 5745 This is only valid if ProcessState is CompletedOk. 5747 PermNotAvail Permanently Not Available. The goods are 5748 permanently unavailable and cannot be re-ordered. 5749 This is only valid if ProcessState is Failed. 5751 TempNotAvail Temporarily Not Available. The goods are 5752 temporarily unavailable and may become available 5753 if they can be ordered. This is only valid if 5754 ProcessState is CompletedOk. 5756 ShipPending Shipping Pending. The goods are available and are 5757 scheduled for shipping but they have not yet been 5758 shipped. This is only valid if ProcessState is 5759 CompletedOk. 5761 Shipped Goods Shipped. The goods have been shipped. 5762 Confirmation of delivery is awaited. This is only 5763 valid if ProcessState is CompletedOk. 5765 ShippedNoConf Shipped - No Delivery Confirmation. The goods have 5766 been shipped but it is not possible to confirm 5767 delivery of the goods. This is only valid if 5768 ProcessState is CompletedOk. 5770 Confirmed Confirmed. All goods have been delivered and 5771 confirmation of their delivery has been received. 5772 This is only valid if ProcessState is CompletedOk. 5774 6.15.1.4 Authentication Completion Codes 5776 The Completion Code is only required if the ProcessState attribute is 5777 set to Failed. The following table contains the valid values for the 5778 CompletionCode that may be used. It is recommended that the StatusDesc 5779 attribute is used to provide further explanation where appropriate. 5781 Value Description 5783 AuthDecl Authentication Declined. The Authenticatee 5784 declines to be authenticated. This could be, for 5785 example because the signature on an Authentication 5786 Request was invalid or the Authenticator was not 5787 known or acceptable to the Authenticatee. 5789 TradRolesIncon Trading Roles Inconsistent. The Trading Roles 5790 contained within the TradingRoleList attribute of 5791 the Authentication Data Component are inconsistent 5792 with the Trading Role which the Authenticatee is 5793 taking in the OTP transaction or is able to take. 5794 Examples of inconsistencies include: 5796 o asking a PaymentHandler for DeliveryHandler 5797 information 5798 o asking a Consumer for Merchant information 5800 Unspecified Unspecified error. There is some unknown problem 5801 or error which does not fall into one of the other 5802 CompletionCodes. 5804 6.16 Trading Role Data Component 5806 The Trading Role Data Component contains opaque data which is needs to 5807 be communicated between the Trading Roles involved in an OTP 5808 Transaction. 5810 Trading Role Components identify: 5811 o the organisation that generated the component, and 5812 o the organisation that is to receive it. 5814 They are first generated and included in a "Response" Block, and then 5815 copied to the appropriate "Request" Block. For example a Payment 5816 Handler might need to inform a Delivery Handler that a credit card 5817 payment had been authorised but not captured. There may also be other 5818 information that the Payment Handler has generated who format is 5819 privately agreed with the Delivery Handler which needs to be 5820 communicated. 5822 Its definition is as follows. 5824 5825 5830 Attributes: 5832 ID An identifier which uniquely identifies the 5833 Trading Role Data Component within the IOTP 5834 Transaction. 5836 OrginatorElRef Contains an element reference to the Organisation 5837 Component of the Organisation that created the 5838 Trading Role Data Component and included it in a 5839 "Response" Block (e.g. an Offer Response or a 5840 Payment Response Block). 5842 DestinationElRefs Contains element references to the Organisation 5843 Components of the Organisations that are to 5844 receive the Trading Role Data Component in a 5845 "Request" Block (e.g. either a Payment Request or 5846 a Delivery Request Block). 5848 Content: 5850 PackagedContent This contains the data which is to be sent between 5851 the various Trading Roles. For a definition of 5852 PackagedContent see section 3.8. 5854 6.16.1 Who Receives a Trading Role Data Component 5856 The rules for deciding what to do with Trading Role Data Components 5857 are described below. 5858 o whenever a Trading Role Data Component is received in a 5859 "Response" block identify the Organisation Components of the 5860 Organisations that are to receive it as identified by the 5861 DestinationElRefs attribute. 5862 o whenever a "Request" Block is being sent, check to see if it 5863 is being sent to one of the Organisations identified by the 5864 DestinationElRef attribute. If it is then include in the 5865 "Request" block: 5866 - the Trading Role Data Component as well as, 5867 - the Organisation Component of the Organisation identified by the 5868 OrignatorElRef attribute (if not already present) 5870 6.17 Inquiry Type Component 5872 The Inquiry Component contains the information which indicates what 5873 type of process is being inquired upon. Its definition is as follows. 5875 5876 5882 Attributes: 5884 ID An identifier which uniquely identifies the 5885 Inquiry Type Component within the IOTP 5886 Transaction. 5888 Type Contains the type of inquiry. Valid values for 5889 Type are: 5890 o Offer. The inquiry is about the status of an 5891 offer and is addressed to the Merchant. 5892 o Payment. The inquiry is about the status of a 5893 payment and is addressed to the Payment Handler. 5894 o Delivery. The inquiry is about the status of a 5895 delivery and addressed to the Delivery Handler. 5897 ElRef Contains an Element Reference (see section 3.5) to 5898 the component to which this Inquiry Type Component 5899 applies. That is, 5900 o TPO Block when Type is Offer 5901 o Payment Component when Type is Payment 5902 o Delivery Component when Type is Delivery 5904 ProcessReference Optionally contains a reference to the process 5905 being inquired upon. It should be set if the 5906 information is available. For the definition of 5907 the values it may contain, see the 5908 ProcessReference attribute of the Status Component 5909 (see section 6.15). 5911 6.18 Signature Component 5913 Each Signature Component digitally signs one or more Blocks or 5914 Components including other Signature Components. 5916 For a general explanation of signatures see section 5 Security 5917 Considerations. Detailed definitions of the XML structures for 5918 signatures is described in the paper "Digital Signature for XML - 5919 Proposal", see [XMLSIG]. 5921 The Signature Component: 5922 o hashes one or more Blocks or Components in one or more IOTP 5923 Messages within the same IOTP Transaction 5924 o concatenates these hashes into a Signed Data element, and 5925 o signs the SignedData element using the optional certificate 5926 identified in the CertRef attribute of the Digital Signature 5927 element. 5929 Note that a Signed Data Element may be signed by more than one Digital 5930 Signature element. 5932 A Signature Component can be one of two types either: 5933 o an Offer Response Signature, or 5934 o a Payment Response Signature 5936 How these signatures are constructed is described below 5938 6.18.1 Offer Response Signature Component 5940 The Signed Data Element of the Offer Response Signature Component 5941 should contain hashes of the following Components: 5942 o the Transaction Id Component (see section 3.3.1) of the IOTP 5943 message that contains the Offer Response Signature 5945 o the Transaction Reference Block (see section 3.3) of the IOTP 5946 Message that contains the Offer Response Signature 5947 o from the TPO Block: 5948 - the Protocol Options Component 5949 - each of the Organisation Components 5950 - each of the Brand List Components 5951 o optionally, all the Brand Selection Components if they were 5952 sent to the Merchant in a TPO Selection Block 5953 o from the Offer Response Block: 5954 - the Order Component 5955 - each of the Payment Components 5956 - the Delivery Component 5957 - each of the Authentication Data Components 5958 - any Trading Role Data Components 5960 The Offer Response Signature Component should also contain Digital 5961 Signature Elements for each of the organisations that may or will need 5962 to verify the signature. This involves: 5963 o if the Merchant has received a TPO Selection Block containing 5964 Brand Selection Components, then generate a Digital Signature 5965 Element for the Payment Handler identified by the Brand 5966 Selection Component and the Delivery Handler identified by the 5967 Delivery Component. See section 5.3.1 Check the Action Request 5968 was sent to the Correct Organisation for a description of how 5969 this can be done. 5970 o if the Merchant is not expecting to receive a TPO Selection 5971 Block then generate a Digital Signature Element for the 5972 Delivery Handler and all the Payment Handlers that are 5973 involved. 5975 6.18.2 Payment Receipt Signature Component 5977 The Signed Data Element of the Payment Receipt Signature Component 5978 should contain hashes of the following Components: 5979 o the Transaction Id Component (see section 3.3.1) of the IOTP 5980 message that contains the Payment Receipt Signature 5981 o the Transaction Reference Block (see section 3.3) of the IOTP 5982 Message that contains the Payment Receipt Signature 5983 o the Offer Response Signature Component 5984 o the Payment Receipt Component 5985 o the Status Component 5986 o the Brand Selection Component. 5987 o any Trading Role Data Components 5989 6.18.3 Ping Signature Components 5991 If the Ping Response Transaction is generating a signature (see 5992 section 8.9), the Signed Data Element of the Ping Response or Ping 5993 Request Signature Components should contain hashes of the following 5994 Components: 5995 o all the Organisation Components. 5997 6.19 Error Component 5999 The Error Component contains information about Technical Errors (see 6000 section 4.1) in an IOTP Message which has been received by one of the 6001 Trading Roles involved in the trade. 6003 For clarity two phrases are defined which are used in the description 6004 of an Error Component: 6005 o message in error. An IOTP message which contains or causes an 6006 error of some kind 6007 o message reporting the error. An IOTP message that contains an 6008 Error Component that describes the error found in a message in 6009 error. 6011 The definition of the Error Component is as follows. 6013 6014 6023 Attributes: 6025 ID An identifier which uniquely identifies the Error 6026 Component within the IOTP Transaction. 6028 xml:lang Defines the language used by attributes or child 6029 elements within this component, unless overridden 6030 by an xml:lang attribute on a child element. See 6031 section 3.9 Identifying Languages. 6033 ErrorCode Contains an error code which indicates the nature 6034 of the error in the message in error. Valid values 6035 for the ErrorCode are given in section 6.19.2 6036 Error Codes. 6038 ErrorDesc Contains a narrative description of the error in 6039 the language defined by xml:lang. The content of 6040 this attribute is defined by the vendor/developer 6041 of the software which generated the Error 6042 Component 6044 Severity Indicates the severity of the error. Valid values 6045 are: 6046 o Warning. This indicates that although there is 6047 a message in error the IOTP Transaction can 6048 still continue. 6049 o TransientError. This indicates that the error 6050 in the message in error may be recovered if the 6051 message in error that is referred to by the 6052 ErrorLocation element is resent 6053 o HardError. This indicates that there is an 6054 unrecoverable error in the message in error and 6055 the IOTP Transaction must stop. 6057 MinRetrySecs This attribute should be present if Severity is 6058 set to TransientError. It is the minimum number of 6059 whole seconds which the IOTP aware application 6060 which received the message reporting the error 6061 should wait before re-sending the message in error 6062 identified by the ErrorLocation element. 6064 If Severity is not set to TransientError then the 6065 value of this attribute is ignored. 6067 SwVendorErrorRef This attribute is a reference whose value is set 6068 by the vendor/developer of the software which 6069 generated the Error Component. It should contain 6070 data which enables the vendor to identify the 6071 precise location in their software and the set of 6072 circumstances which caused the software to 6073 generate a message reporting the error. See also 6074 the SoftwareId attribute of the Message Id element 6075 in the Transaction Reference Block (section 3.3). 6077 Content: 6079 ErrorLocation This identifies the IOTP Transaction Id of the 6080 message in error and, where possible, the element 6081 and attribute in the message in error that caused 6082 the Error Component to be generated. 6084 If the Severity of the error is not 6085 TransientError, more than one ErrorLocation may be 6086 specified as appropriate depending on the nature 6087 of the error (see section 6.19.2 Error Codes) and 6088 at the discretion of the vendor/developer of the 6089 IOTP Aware Application. 6091 PackagedContent This contains additional data which can be used to 6092 understand the error. Its content may vary as 6093 appropriate depending on the nature of the error 6094 (see section 6.19.2 Error Codes) and at the 6095 discretion of the vendor/developer of the IOTP 6096 Aware Application. For a definition of 6097 PackagedContent see section 3.8. 6099 6.19.1 Error Processing Guidelines 6101 If there is more than one Error Component in a message reporting the 6102 error, carry out the actions appropriate for the Error Component with 6103 the highest severity. In this context, HardError has a higher severity 6104 than TransientError, which has a higher severity than Warning. 6106 6.19.1.1 Severity - Warning 6108 If an IOTP aware application is generating a message reporting the 6109 error with an Error Component where the Severity attribute is set to 6110 Warning, then if the message reporting the error does not contain 6111 another Error Component with a severity higher than Warning, the IOTP 6112 Message must also include the Trading Blocks and Trading Components 6113 that would have been included if no error was being reported. 6115 If a message reporting the error is received with an Error Component 6116 where Severity is set to Warning, then: 6117 o it is recommended that information about the error is either 6118 logged, or otherwise reported to the user, 6119 o the implementer of the IOTP aware application must either, at 6120 their or the user's discretion: 6121 - continue the IOTP transaction as normal, or 6122 - fail the IOTP transaction by generating a message reporting the 6123 error with an Error Component with Severity set to HardError 6124 (see section 6.19.1.3). 6126 If the intention is to continue the IOTP transaction then, if there 6127 are no other Error Components with a higher severity, check that the 6128 necessary Trading Blocks and Trading Components for normal processing 6129 of the transaction to continue are present. If they are not then 6130 generate a message reporting the error with an Error Component with 6131 Severity set to HardError. 6133 6.19.1.2 Severity - Transient Error 6135 If an IOTP Aware Application is generating a message reporting the 6136 error with an Error Component where the Severity attribute is set to 6137 TransientError, then there should be only one Error Component in the 6138 message reporting the error. In addition, the MinRetrySecs attribute 6139 should be present. 6141 If a message reporting the error is received with an Error Component 6142 where Severity is set to TransientError then: 6143 o if the MinRetrySecs attribute is present and a valid number, 6144 then use the MinRetrySecs value given. Otherwise if 6145 MinRetrySecs is missing or is invalid, then: 6146 - generate a message reporting the error containing an Error 6147 Component with a Severity of Warning and send it on the next 6148 IOTP message (if any) to be sent to the Trading Role which sent 6149 the message reporting the error with the invalid MinRetrySecs, 6150 and 6151 - use a value for MinRetrySecs which is set by the 6152 vendor/developer of the IOTP Aware Application. 6153 o check that only one ErrorLocation element is contained within 6154 the Error Component and that it refers to an IOTP Message 6155 which was sent by the recipient of the Error Component with a 6156 Severity of TransientError. If more than one ErrorLocation is 6157 present then generate a message reporting the error with a 6158 Severity of HardError. 6160 6.19.1.3 Severity - Hard Error 6162 If an IOTP Aware Application is generating a message reporting the 6163 error with an Error Component where the Severity attribute set to 6164 HardError, then there should be only one Error Component in the 6165 message reporting the error. 6167 If a message reporting the error is received with an Error Component 6168 where Severity is set to HardError then terminate the IOTP 6169 Transaction. 6171 6.19.2 Error Codes 6173 The following table contains the valid values for the ErrorCode 6174 attribute of the Error Component. The first sentence of the 6175 description contains the text that should be used to describe the 6176 error when displayed or otherwise reported. Individual implementations 6177 may translate this into alternative languages at their discretion. 6179 An Error Code must not be more that 14 characters long. 6181 Value Description 6183 Reserved Reserved. This error is reserved by the 6184 vendor/developer of the software. Contact the 6185 vendor/developer of the software for more 6186 information See the SoftwareId attribute of the 6187 Message Id element in the Transaction Reference 6188 Block(section 3.3). 6190 XmlNotWellFrmd XML not well formed. The XML document is not well 6191 formed. See [XML] for the meaning of "well 6192 formed". Even if the XML is not well formed, it 6193 should still be scanned to find the Transaction 6194 Reference Block so that a properly formed Error 6195 Response may be generated. 6197 Value Description 6199 XmlNotValid XML not valid. The XML document is well formed but 6200 the document is not valid. See [XML] for the 6201 meaning of "valid". Specifically: 6202 o the XML document does not comply with the 6203 constraints defined in the IOTP document type 6204 declaration (see section 12 Open Trading 6205 Protocol Data Type Definition), and 6206 o the XML document does not comply with the 6207 constraints defined in the document type 6208 declaration of any additional [XML Namespace] 6209 that are declared. 6211 As for XML not well formed, attempts should still 6212 be made to extract the Transaction Reference Block 6213 so that a properly formed Error Response may be 6214 generated. 6216 ElUnexpected Unexpected element. Although the XML document is 6217 well formed and valid, an element is present that 6218 is not expected in the particular context 6219 according to the rules and constraints contained 6220 in this specification. 6222 ElNotSupp Element not supported. Although the document is 6223 well formed and valid, an element is present that: 6224 o is consistent with the rules and constraints 6225 contained in this specification, but 6226 o is not supported by the IOTP Aware Application 6227 which is processing the IOTP Message. 6229 ElMissing Element missing. Although the document is well 6230 formed and valid, an element is missing that 6231 should have been present if the rules and 6232 constraints contained in this specification are 6233 followed. 6235 In this case set the PackagedContent of the Error 6236 Component to the type of the missing element. 6238 ElContIllegal Element content illegal. Although the document is 6239 well formed and valid, the element PackagedContent 6240 contains values which do not conform to the rules 6241 and constraints contained in this specification. 6243 EncapProtErr Encapsulated protocol error. Although the document 6244 is well formed and valid, the PackagedContent of 6245 an element contains data from an encapsulated 6246 protocol which contains errors. 6248 AttUnexpected Unexpected attribute. Although the XML document is 6249 Value Description 6250 well formed and valid, the presence of the 6251 attribute is not expected in the particular 6252 context according to the rules and constraints 6253 contained in this specification. 6255 AttNotSupp Attribute not supported. Although the XML document 6256 is well formed and valid, and the presence of the 6257 attribute in an element is consistent with the 6258 rules and constraints contained in this 6259 specification, it is not supported by the IOTP 6260 Aware Application which is processing the IOTP 6261 Message. 6263 AttMissing Attribute missing. Although the document is well 6264 formed and valid, an attribute is missing that 6265 should have been present if the rules and 6266 constraints contained in this specification are 6267 followed. 6269 In this case set the PackagedContent of the Error 6270 Component to the type of the missing attribute. 6272 AttValIllegal Attribute value illegal. The attribute contains a 6273 value which does not conform to the rules and 6274 constraints contained in this specification. 6276 AttValNotRecog Attribute Value Not Recognised. The attribute 6277 contains a value which the IOTP Aware Application 6278 generating the message reporting the error could 6279 not recognise even though it should have been able 6280 to since the information had been provided in an 6281 earlier IOTP message. 6283 MsgTooLarge Message too large. The message is too large to be 6284 processed by the IOTP Aware Application. 6286 ElTooLarge Element too large. The element is too large to be 6287 processed by the IOTP Aware Application 6289 ValueTooSmall Value too small or early. The value of all or part 6290 of the PackagedContent of an element or an 6291 attribute, although valid, is too small. 6293 ValueTooLarge Value too large or in the future. The value of all 6294 or part of the PackagedContent of an element or 6295 an attribute, although valid, is too large. 6297 ElInconsistent Element Inconsistent. Although the document is 6298 well formed and valid, according to the rules and 6299 constraints contained in this specification: 6300 o the content of an element is inconsistent with 6302 Value Description 6303 the content of other elements or their 6304 attributes, or 6305 o the value of an attribute is inconsistent with 6306 the value of one or more other attributes. 6308 In this case create ErrorLocation elements which 6309 identify all the attributes or elements which are 6310 inconsistent. 6312 TransportError Transport Error. This error code is used to 6313 indicate that there is a problem with the 6314 Transport Mechanism which is preventing the 6315 message from being received. It is typically 6316 associated with a Transient Error. Explanation of 6317 the Transport Error is contained within the 6318 ErrorDesc attribute. The values which can be used 6319 inside ErrorDesc with a TransportError is 6320 specified in the IOTP supplement for the Transport 6321 mechanism. 6323 6.19.3 Error Location Element 6325 An Error Location Element identifies an element and optionally an 6326 attribute in the message in error which is associated with the error. 6327 It contains a reference to the IOTP Message, Trading Block, Trading 6328 Component, element and attribute, which is in error. 6330 6331 6339 Attributes: 6341 ElementType This is the "type" (see [XML]) of the Element in 6342 the message in error where the error is located. 6344 OtpMsgRef This is the value of the ID attribute of the of 6345 the Message Id Component (see section 3.3.2) of 6346 the message in error to which this Error Component 6347 applies. 6349 BlkRef If the error is associated with a specific Trading 6350 Block, then this is the value of the ID attribute 6351 of the Trading Block where the error is located. 6353 CompRef If the error is associated with a specific Trading 6354 Component, then this is the value of the ID 6355 attribute of the Trading Component where the error 6356 is located. 6358 ElementRef If the error is associated with a specific element 6359 within a Trading Component then, if the element 6360 has an attribute with an "attribute type" (see 6361 [XML]) of "ID", then this is the value of that 6362 attribute. 6364 AttName If the error is associated with the value of an 6365 attribute, then this is the name of that 6366 attribute. In this case the PackagedContent of the 6367 Error Component should contain the value of the 6368 attribute. 6370 Note that as many as the attributes as possible should be included. 6371 For example if an attribute in a child element of a Trading Component 6372 contains an incorrect value, then all the attributes of ErrorLocation 6373 should be present. 6375 7. Trading Blocks 6377 Trading Blocks consist of one or more Trading Components and 6378 optionally one or more Signature Components. One or more Trading 6379 Blocks may be contained within the IOTP Messages which are physically 6380 sent in the form of [XML] documents between the different 6381 organisations that are taking part in a trade. 6383 This is illustrated in the diagram below. 6385 OTP MESSAGE <----------- OTP Message - an XML Document 6386 | which is transported between the 6387 | Trading Roles 6388 |-Trans Ref Block <----- Trans Ref Block - contains 6389 | | information which describes the 6390 | | OTP Transaction and the OTP 6391 | | Message. 6392 | |-Trans Id Comp. <--- Transaction Id Component - 6393 | | uniquely identifies the OTP 6394 | | Transaction. The Trans Id 6395 | | Components are the same across 6396 | | all OTP messages that comprise a 6397 | | single OTP transaction. 6398 | |-Msg Id Comp. <----- Message Id Component - identifies 6399 | and describes an OTP Message 6400 | within an OTP Transaction 6401 |-Signature Block <----- Signature Block (optional) - 6402 | | contains one or more Signature 6403 | | Components and their associated 6404 | | Certificates 6405 | |-Signature Comp. <-- Signature Component - contains 6406 | | digital signatures. Signatures 6407 | | may sign hashes of the Trans Ref 6408 | | Block and any Trading Component 6409 | | in any OTP Message in the same 6410 | | OTP Transaction. 6411 | |-Certificate Comp. <- Certificate Component. Used to 6412 | check the signature. 6413 ------> |-Trading Block <-------- Trading Block - an XML Element 6414 | | |-Component within an OTP Message that 6415 Trading | |-Component contains a predefined set of 6416 Blocks | |-Component Trading Components 6417 | | |-Component 6418 | | |-Component <--------- Trading Components - XML Elements 6419 | | within a Trading Block that 6420 ------> |-Trading Block contain a predefined set of XML 6421 | |-Component elements and attributes 6422 | |-Component containing information required 6423 | |-Component to support a Trading Exchange 6424 | |-Component 6425 | |-Component 6426 | 6427 | 6429 Figure 18 Trading Blocks 6431 Trading Blocks are defined as part of the definition of an IOTP 6432 Message (see section 3.1.1). The definition of an IOTP Message element 6433 is repeated here: 6435 6456 The remainder of this section defines the Trading Blocks in this 6457 version of IOTP. They are: 6458 o Authentication Request Block 6459 o Authentication Response Block 6460 o Delivery Request Block 6461 o Delivery Response Block 6462 o Error Block 6463 o Inquiry Request Block 6464 o Inquiry Response Block 6465 o Offer Response Block 6466 o Payment Exchange Block 6467 o Payment Request Block 6468 o Payment Response Block 6469 o Payment Instrument Customer Care Exchange Block 6470 o Payment Instrument Customer Care Request Block 6471 o Payment Instrument Customer Care Response Block 6472 o Signature Block 6473 o Trading Protocol Options Block 6474 o TPO Selection Block 6476 The Transaction Reference Block is described in section 3.3. 6478 7.1 Trading Protocol Options Block 6480 The TPO Trading Block contains options which apply to the IOTP 6481 Transaction. The definition of a TPO Trading Block is as follows. 6483 6484 6487 Attributes: 6489 ID An identifier which uniquely identifies the 6490 Trading Protocol Options Block within the IOTP 6491 Transaction (see section 3.4 ID Attributes). 6493 Content: 6495 ProtocolOptions The Protocol Options Component (see section 6496 6.1)defines the options which apply to the whole 6497 IOTP Transaction (see section 8). 6499 BrandList This Brand List Component contains one or more 6500 payment brands and protocols which may be selected 6501 (see section 6.6). 6503 Org The Organisation Components (see section 6.5) 6504 identify the organisations and their roles in the 6505 IOTP Transaction. The roles and organisations 6506 which must be present will depend on the 6507 particular type of IOTP Transaction. See the 6508 definition of each transaction in section 8. Open 6509 Trading Protocol Transactions. 6511 The TPO Block should contain: 6512 o the Protocol Options Component 6513 o the Organisation Component with the Trading Role of Merchant 6514 o the Organisation Component with the Trading Role of Consumer 6515 o optionally, the Organisation Component with the Trading Role 6516 of DeliverTo, if there is a Delivery included in the IOTP 6517 Transaction 6518 o Brand List Components for each payment in the IOTP Transaction 6519 o Organisation Components for all the Payment Handlers involved 6520 o optionally, Organisation Components for the Delivery Handler 6521 (if any) for the transaction 6522 o additional Organisation Components that the Merchant may want 6523 to include. For example 6524 - a Customer Care Provider 6525 - an Certificate Authority that offers Merchant "Credentials" or 6526 some other warranty on the goods or services being offered. 6528 7.2 TPO Selection Block 6530 The TPO Selection Block contains the results of selections made from 6531 the options contained in the Trading Protocol Options Block (see 6532 section 7.1).The definition of a TPO Selection Block is as follows. 6534 6535 6538 Attributes: 6540 ID An identifier which uniquely identifies the TPO 6541 Selection Block within the IOTP Transaction. 6543 Content: 6545 BrandSelection This identifies the choice of payment brand and 6546 payment protocol to be used in a payment within 6547 the IOTP Transaction. There is one Brand Selection 6548 Component (see section 6.7) for each payment to be 6549 made in the IOTP Transaction. 6551 The TPO Selection Block should contain one Brand Selection Component 6552 for each Brand List in the TPO Block. 6554 7.3 Offer Response Block 6556 The Offer Response Block contains details of the goods, services, 6557 amount, delivery instructions or financial transaction which is to 6558 take place. Its definition is as follows. 6560 6562 6565 Attributes: 6567 ID An identifier which uniquely identifies the Offer 6568 Response Block within the IOTP Transaction. 6570 Content: 6572 Status Contains status information about the business 6573 success (see section 4.2) or failure of the 6574 generation of the Offer. Note that in an Offer 6575 Response Block, a ProcessState of NotYetStarted or 6576 InProgress are illegal values. 6578 AuthData The Authentication Data Component contains 6579 information about how Authentication associated 6580 with the Offer will occur. See section 6.2. 6582 Order The Order Component contains details about the 6583 goods, services or financial transaction which is 6584 taking place see section 6.4. 6586 The Order Component must be present unless the 6587 ProcessState attribute of the Status Component is 6588 set to Failed. 6590 Payment The Payment Components contain information about 6591 the payments which are to be made see section 6.8. 6593 Delivery The Delivery Component contains details of the 6594 delivery to be made (see section 6.12). 6596 TradingRoleData The Trading Role Data Component contains opaque 6597 data which is needs to be communicated between the 6598 Trading Roles involved in an OTP Transaction (see 6599 section 6.16). 6601 The Offer Response Block should contain: 6602 o the Order Component for the IOTP Transaction 6603 o Payment Components for each Payment in the IOTP Transaction 6604 o the Delivery Component for IOTP Transaction requires (if any) 6605 o the Authentication Data Component (if required) for each 6606 Payment 6608 7.4 Authentication Request Block 6610 This Authentication Request Block contains the challenge data which is 6611 used to obtain information about and optionally authenticate a 6612 Consumer by another Trading Role. Its definition is as follows. 6614 6615 6618 Attributes 6620 ID An identifier which uniquely identifies the 6621 Authentication Request Block within the IOTP 6622 Transaction. 6624 Content 6626 AuthData If the Authentication Data Component is not 6627 present it means that the Authentication Request 6628 Block is just requesting the return of 6629 Organisation Components which describe the 6630 Consumer. 6632 If the optional Authentication Data Component (see 6633 section 6.2) is present it contains data which 6634 describes what additional Authentication the 6635 consumer must provide. 6637 7.5 Authentication Response Block 6639 The Authentication Response Block contains the response which results 6640 from processing the Authentication Request Block. Its definition is as 6641 follows. 6643 6644 6647 Attributes: 6649 ID An identifier which uniquely identifies the 6650 Authentication Response Block within the IOTP 6651 Transaction. 6653 Content: 6655 AuthResp The Authentication Response Component which 6656 contains the results of processing the challenge 6657 data in the Authentication Data Component - see 6658 section 6.3. 6660 Org Organisation Components which contain information 6661 corresponding to the Consumer and DelivTo Trading 6662 Roles. 6664 7.6 Payment Request Block 6666 The Payment Request Block contains information which requests that a 6667 payment is started. Its definition is as follows. 6669 6672 6675 Attributes: 6677 ID An identifier which uniquely identifies the 6678 Payment Request Block within the IOTP Transaction. 6680 Content: 6682 Status Contains the Status Components (see section 6.12) 6683 of the responses of the steps (e.g. an Offer 6684 Response and/or a Payment Response) on which this 6685 step depends. It is used to indicate the success 6686 or failure of those steps. Payment should only 6687 occur of the previous steps were successful. 6689 AuthData The optional Authentication Data Component 6690 contains data about how Authentication associated 6691 with the payment, if any, will occur. See section 6692 6.2. 6694 BrandList The Brand List Component contains a list of one or 6695 more payment brands and protocols which may be 6696 selected (see section 6.6). 6698 BrandSelection This identifies the choice of payment brand, the 6699 payment protocol and the payment handler to be 6700 used in a payment within the IOTP Transaction. 6701 There is one Brand Selection Component (see 6702 section 6.7) for each payment to be made in the 6703 IOTP Transaction. 6705 Payment The Payment Components contain information about 6706 the payment which is being made see section 6.8. 6708 PaySchemeData The Payment Scheme Component contains payment 6709 scheme specific data see section 6.9. 6711 Org The Organisation Component contains details of 6712 organisations involved in the payment (see section 6713 6.5). The Organisations present are dependent on 6714 the IOTP Transaction and the data which is to be 6715 signed. See section 5 Security Considerations for 6716 more details. 6718 TradingRoleData The Trading Role Data Component contains opaque 6719 data which is needs to be communicated between the 6720 Trading Roles involved in an OTP Transaction (see 6721 section 6.16). 6723 The Payment Request Block should contain: 6724 o the Organisation Component with a Trading Role of Merchant 6725 o the Organisation Component with the Trading Role of Consumer 6726 o the Payment Component for the Payment 6727 o the Brand List Component for the Payment 6728 o the Brand Selection Component for the Brand List 6729 o the Organisation Component for the Payment Handler of the 6730 Payment 6731 o the Organisation Component (if any) for the Organisation which 6732 carried out the previous step, for example another Payment 6733 Handler 6734 o the Organisation Component for the organisation which is to 6735 carry out the next step, if any. This may be, for example, 6736 either a Delivery Handler or a Payment Handler. 6737 o the Organisation Components for any additional Organisations 6738 that the Merchant has included in the Offer Response Block 6740 o an Optional Payment Scheme Data Component, if required by the 6741 Payment Method as defined in the IOTP supplement for the 6742 payment method 6743 o any Trading Role Data Components that may be required (see 6744 section 6.16.1). 6746 7.7 Payment Exchange Block 6748 The Payment Exchange Block contains payment scheme specific data which 6749 is exchanged between two of the roles in a trade. Its definition is as 6750 follows. 6752 6753 6756 Attributes: 6758 ID An identifier which uniquely identifies the 6759 Payment Exchange Block within the IOTP 6760 Transaction. 6762 Content: 6764 PaySchemeData This Trading Component contains payment scheme 6765 specific data see section 6.9 Payment Scheme 6766 Component. 6768 7.8 Payment Response Block 6770 This Payment Response Block contains a information about the Payment 6771 Status, a Payment Receipt, and an optional payment protocol message. 6772 Its definition is as follows. 6774 6776 6779 Attributes: 6781 ID An identifier which uniquely identifies the 6782 Payment Response Block within the IOTP 6783 Transaction. 6785 Content: 6787 Status Contains status information about the business 6788 success (see section 4.2) or failure of the 6789 payment. Note that in a Pay Response Block, a 6790 ProcessState of NotYetStarted or InProgress are 6791 illegal values. 6793 PayReceipt Contains payment scheme specific data which can be 6794 used to verify the payment occurred. See section 6795 6.10 Payment Receipt Component. 6797 PaySchemeData Contains payment scheme specific data see section, 6798 for example a payment protocol message. See 6.9 6799 Payment Scheme Component. 6801 PaymentNote Contains additional, non payment related, 6802 information which the Payment Handler wants to 6803 provide to the Consumer. For example, if a 6804 withdrawal or deposit were being made then it 6805 could contain information on the remaining balance 6806 on the account after the transfer was complete. 6807 See section 6.11 Payment Note Component. 6809 TradingRoleData The Trading Role Data Component contains opaque 6810 data which is needs to be communicated between the 6811 Trading Roles involved in an OTP Transaction (see 6812 section 6.16). 6814 7.9 Delivery Request Block 6816 The Delivery Request Block contains details of the goods or services 6817 which are to be delivered together with a signature which can be used 6818 to check that delivery is authorised. Its definition is as follows. 6820 6822 6825 Attributes: 6827 ID An identifier which uniquely identifies the 6828 Delivery Request Block within the IOTP 6829 Transaction. 6831 Content: 6833 Status Contains the Status Components (see section 6.12) 6834 of the responses of the steps (e.g. a Payment 6835 Response) on which this step is dependent. It is 6836 used to indicate the success or failure of those 6837 steps. Delivery should only occur of the previous 6838 steps were successful. 6840 Order The Order Component contains details about the 6841 goods, services or financial transaction which is 6842 taking place see section 6.4. 6844 Org The Organisation Components (see section 6.5) 6845 identify the organisations and their roles in the 6846 IOTP Transaction. The roles and organisations 6847 which must be present will depend on the 6848 particular type of IOTP Transaction. See the 6849 definition of each transaction in section 8. Open 6850 Trading Protocol Transactions. 6852 Delivery The Delivery Component contains details of the 6853 delivery to be made (see section 6.12). 6855 TradingRoleData The Trading Role Data Component contains opaque 6856 data which is needs to be communicated between the 6857 Trading Roles involved in an OTP Transaction (see 6858 section 6.16). 6860 The Delivery Request Block contains: 6861 o the Organisation Component with a Trading Role of Merchant 6862 o the Organisation Component for the Consumer and DeliverTo 6863 Trading Roles 6864 o the Delivery Component for the Delivery 6865 o the Organisation Component for the Delivery Handler. 6866 Specifically the Organisation Component identified by the 6867 ActionOrgRef attribute on the Delivery Component 6868 o the Organisation Component (if any) for the Organisation which 6869 carried out the previous step, for example a Payment Handler 6870 o the Organisation Components for any additional Organisations 6871 that the Merchant has included in the Offer Response Block 6872 o any Trading Role Data Components that may be required (see 6873 section 6.16.1). 6875 7.10 Delivery Response Block 6877 The Delivery Response Block contains a Delivery Note containing 6878 details on how the goods will be delivered. Its definition is as 6879 follows. Note that in a Delivery Response Block a Delivery Status 6880 Element with a DeliveryStatusCode of NotYetStarted or InProgress is 6881 invalid. 6883 6884 6887 Attributes: 6889 ID An identifier which uniquely identifies the 6890 Delivery Response Block within the IOTP 6891 Transaction. 6893 Content: 6895 Status Contains status information about the business 6896 success (see section 4.2) or failure of the 6897 delivery. Note that in a Delivery Response Block, 6898 a ProcessState of NotYetStarted or InProgress are 6899 illegal values. 6901 DeliveryNote The Delivery Note Component contains details about 6902 how the goods or services will be delivered (see 6903 section 6.13). 6905 7.11 Payment Instrument Customer Care Request Block 6907 The Payment Instrument Customer Care Request Block contains 6908 information which requests that an IOTP Payment Instrument Customer 6909 Care Transaction is started in order to provide Customer Care for the 6910 Consumer's Payment Instrument. Its definition is as follows. 6912 6913 6916 Attributes: 6918 ID An identifier which uniquely identifies the 6919 Payment Instrument Customer Care Request Block 6920 within the IOTP Transaction. 6922 Content: 6924 PayMethodInfo The Payment Method Information Component (see 6925 section 6.14) contains data which describes the 6926 Payment Method which initiated the Payment 6927 Instrument Customer Care Transaction 6929 PaySchemeData Optional Payment Scheme Components (see section 6930 6.9) that contain payment scheme specific data. 6931 The sequence of the Payment Scheme Components in 6932 the Block is the sequence in which they should be 6933 processed by the Payment Scheme software which 6934 receives this message. 6936 7.12 Payment Instrument Customer Care Exchange Block 6938 The Payment Instrument Customer Care Exchange Block contains payment 6939 scheme specific data which is exchanged between the Payment Instrument 6940 User and the Payment Scheme Customer Care Provider. Its definition is 6941 as follows. 6943 6944 6947 Attributes: 6949 ID An identifier which uniquely identifies the 6950 Payment Instrument Customer Care Exchange Block 6951 within the IOTP Transaction. 6953 Content: 6955 PaySchemeData Optional Payment Scheme Components (see section 6956 6.9) that contain payment scheme specific data. 6957 The sequence of the Payment Scheme Components in 6958 the Block is the sequence in which they should be 6959 processed by the Payment Scheme software which 6960 receives this message. 6962 7.13 Payment Instrument Customer Care Response Block 6964 The Payment Instrument Customer Care Response Block contains the final 6965 Payment Scheme Component of the IOTP Payment Instrument Customer Care 6966 Transaction. Its definition is as follows. 6968 6969 6972 Attributes: 6974 ID An identifier which uniquely identifies the 6975 Payment Instrument Customer Care Response Block 6976 within the IOTP Transaction. 6978 Content: 6980 PaySchemeData Optional Payment Scheme Components (see section 6981 6.9) that contain payment scheme specific data. 6982 The sequence of the Payment Scheme Components in 6983 the Block is the sequence in which they should be 6984 processed by the Payment Scheme software which 6985 receives this message. 6987 7.14 Inquiry Request Trading Block 6989 The Inquiry Request Trading Block contains an Inquiry Type Component 6990 and an optional Payment Scheme Component to contain payment scheme 6991 specific inquiry messages. 6993 6994 6997 Attributes: 6999 ID An identifier which uniquely identifies the 7000 Inquiry Request Trading Block within the IOTP 7001 Transaction. 7003 Content: 7005 InquiryType Inquiry Type Component (see section 6.17) that 7006 contains the type of inquiry. 7008 PaySchemeData Payment Scheme Component (see section 6.9) that 7009 contains payment scheme specific inquiry messages 7010 for inquiries on payments. This is present when 7011 the Type attribute of Inquiry Type Component is 7012 Payment. 7014 7.15 Inquiry Response Trading Block 7016 The Inquiry Response Trading Block contains a Status Component and an 7017 optional Payment Scheme Component to contain payment scheme specific 7018 inquiry messages. Its purpose is to enquire on the current status of 7019 an IOTP transaction at a server. 7021 7022 7027 Attributes: 7029 ID An identifier which uniquely identifies the 7030 Inquiry Response Trading Block within the IOTP 7031 Transaction. 7033 LastReceivedOtpMsgRef Contains an Element Reference (see section 7034 3.5) to the Message Id Component (see section 7035 3.3.2) of the last message this server has 7036 received from the Consumer. If there is no 7037 previously received message from the Consumer 7038 in the pertinent transaction, this attribute 7039 should be contain the value Null. This 7040 attribute exists for debugging purposes. 7042 LastSentOtpMsgRef Contains an Element Reference (see section 7043 3.5) to the Message Id Component (see section 7044 3.3.2) of the last message this server has 7045 sent to the Consumer. If there is no 7046 previously sent message to the Consumer in the 7047 pertinent transaction, this attribute should 7048 contain the value Null. This attribute exists 7049 for debugging purposes. 7051 Content: 7053 Status Contains status information about the business 7054 success (see section 4.2) or failure of a certain 7055 trading exchange (i.e., Offer, Payment, or 7056 Delivery). 7058 PaySchemeData Payment Scheme Component (see section 6.9) that 7059 contains payment scheme specific inquiry messages 7060 for inquiries on payments. This is present when 7061 the Type attribute of StatusType attribute of the 7062 Status Component is set to Payment. 7064 7.16 Ping Request Block 7066 The Ping Request Block is used to determine if a Server is operating 7067 and whether or not cryptography is compatible. 7069 The definition of a Ping Request Block is as follows. 7071 7072 7075 Attributes: 7077 ID An identifier which uniquely identifies the Ping 7078 Request Trading Block within the IOTP Transaction. 7080 Content: 7082 Org Optional Organisation Components (see section 7083 6.5). 7085 If no Organisation Component is present then the 7086 Ping Request is anonymous and simply determines if 7087 the server is operating. 7089 However if Organisation Components are present, 7090 then it indicates that the sender of the Ping 7091 Request wants to verify that digital signatures 7092 can be handled. 7094 In this case the sender includes: 7095 o an Organisation Component that identifies 7096 itself specifying the Trading Role(s) it is 7097 taking in IOTP transactions (Merchant, Payment 7098 Handler, etc) 7099 o an Organisation Component that identifies the 7100 intended recipient of the message. 7102 These are then used to generate a signature over 7103 the Ping Response Block. 7105 7.17 Ping Response Block 7107 The Ping Response Trading Block provides the result of a Ping Request. 7109 It contains an Organisation Component that identifies the sender of 7110 the Ping Response. 7112 If the Ping Request to which this block is a response contained 7113 Organisation Components, then it also contains those Organisation 7114 Components. 7116 7117 7124 Attributes: 7126 ID An identifier which uniquely identifies the Ping 7127 Request Trading Block within the IOTP 7128 Transaction. 7130 PingStatusCode Contains a code which shows the status of the 7131 sender software which processes IOTP messages. 7132 Valid values are: 7133 o Ok. Everything with the service is working 7134 normally, including the signature 7135 verification. 7136 o Busy. Things are working normally but there 7137 may be some delays. 7138 o Down. The server is not functioning fully but 7139 can still provide a Ping response. 7141 SigVerifyStatusCode Contains a code which shows the status of 7142 signature verification. This is present only 7143 when the message containing the Ping Request 7144 Block also contains a Signature Block. Valid 7145 values are: 7146 o Ok. The signature has successfully been 7147 verified and proved compatible. 7148 o NotSupported The receiver of this Ping Request 7149 Block does not support validation of 7150 signatures. 7151 o Fail. Signature verification failed. 7153 Xml:lang Defines the language used in PingStatusDesc. 7154 This is present when PingStatusDesc is present. 7156 PingStatusDesc Contains a short description of the status of 7157 the server which sends this Ping Response Block. 7158 Servers, if their designers want, can use this 7159 attribute to send more refined status 7160 information than PingStatusCode which can be 7161 used for debugging purposes, for example. 7163 Content: 7165 Org These are Organisation Components (see section 7166 6.5). 7168 The Organisation Components of the sender of the 7169 Ping Response is always included in addition to 7170 the Organisation Components sent in the Ping 7171 Request. 7173 [Note] Ping Status Code values do not include a value such as Fail, 7174 since, when the software receiving the Ping Request message 7175 is not working at all, no Ping Response message will be sent 7176 back. 7177 [Note End] 7179 7.18 Signature Block 7181 The Signature Block contains one or more Signature Components and 7182 associated Certificates which sign data associated with the IOTP 7183 Transaction. For a general discussion and introduction to how IOTP 7184 uses signatures, see section 5 Security Considerations. The definition 7185 of the Signature Component and certificates is contained in the paper 7186 "Digital Signature for XML - Proposal", see [XMLSIG]. 7188 The definition of a Signature Block is as follows: 7190 7191 7194 Attributes: 7196 ID An identifier which uniquely identifies the 7197 Signature Block within the IOTP Transaction. 7199 Content: 7201 OtpSig Contains a Digital Signature. See the paper 7202 "Digital Signature for XML - Proposal" [XMLSIG], 7203 for its definition 7205 OtpCert Contains a Digital Certificate. See the paper 7206 "Digital Signature for XML - Proposal" [XMLSIG], 7207 for its definition 7209 The contents of a Signature Block depends on the Trading Block that is 7210 contained in the same IOTP Message as the Signature Block. 7212 7.18.1 Offer Response 7214 A Signature Block which is in the same message as an Offer Response 7215 Block contains just an Offer Response Signature Component (see section 7216 6.18.1). 7218 7.18.2 Payment Request 7220 A Signature Block which is in the same message as a Payment Request 7221 Block contains: 7222 o an Offer Response Signature Component (see section 6.18.1), 7223 and 7224 o if the Payment is dependent on an earlier step (as indicated 7225 by the StartAfter attribute on the Payment Component), then 7226 the Payment Receipt Signature Component (see section 6.18.2) 7227 generated by the previous step 7229 7.18.3 Payment Response 7231 A Signature Block which is in the same message as a Payment Response 7232 Block contains just a Payment Receipt Signature Component (see section 7233 6.18.2) generated by the step. 7235 7.18.4 Delivery Request 7237 A Signature Block which is in the same message as a Delivery Request 7238 Block contains: 7240 o an Offer Response Signature Component (see section 6.18.1), 7241 and 7242 o the Payment Receipt Signature Component (see section 6.18.2) 7243 generated by the previous step. 7245 7.19 Error Block 7247 The Error Trading Block contains one or more Error Components (see 7248 section 6.19) which contain information about Technical Errors (see 7249 section 4.1) in an IOTP Message which has been received by one of the 7250 Trading Roles involved in the trade. 7252 For clarity two phrases are defined which are used in the description 7253 of an Error Trading Block: 7254 o message in error. An IOTP message which contains or causes an 7255 error of some kind 7256 o message reporting the error. An IOTP message that contains an 7257 Error Trading Block that describes the error found in a 7258 message in error. 7260 An Error Trading Block may be contained in any message reporting the 7261 error. The action which then follows depends on the severity of the 7262 error. See the definition of an Error Component, for an explanation of 7263 the different types of severity and the actions which can then occur. 7265 [Note] Although, an Error Trading Block can report multiple 7266 different errors using multiple Error Components, there is 7267 no obligation on a developer of an IOTP Aware Application to 7268 do so. 7269 [Note End] 7271 The structure of an Error Trading Block is as follows. 7273 7274 7277 Attributes: 7279 ID An identifier which uniquely identifies the Error 7280 Trading Block within the IOTP Transaction. 7282 Content: 7284 ErrorComp An Error Component (see section 6.19) that 7285 contains information about an individual 7286 Technical Error. 7288 PaySchemeData An optional Payment Scheme Component (see section 7289 6.9) which contains a Payment Scheme Message. See 7290 the appropriate payment scheme supplement to 7291 determine whether or not this component needs to 7292 be present and for the definition of what it must 7293 contain. 7295 8. Open Trading Protocol Transactions 7297 The Baseline Open Trading Protocol supports the following types of 7298 Baseline IOTP Transactions: 7299 o Authentication 7300 o Deposit 7301 o Purchase 7302 o Refund 7303 o Withdrawal 7304 o Baseline Value Exchange 7305 o Payment Instrument Customer Care 7306 o Transaction Status Inquiry, and 7307 o Ping 7309 Each of these transactions are described in more detail in the 7310 following sections providing descriptions of: 7311 o the Trading Blocks in each IOTP Transaction 7312 o the Trading Components in each Trading Block, and 7313 o how the Trading Components are signed 7315 [Note] There are many similarities between the transactions within 7316 IOTP. This is because there is a lot of reuse of the Trading 7317 Blocks between the different transactions. 7319 This means that there should be significant opportunity for 7320 software re-use. For example, from an IOTP perspective, the 7321 Deposit, Refund and Withdrawal transactions are essentially 7322 the same, although the processing which will occur, 7323 especially at the server end, will differ. 7324 [Note End] 7326 8.1 Baseline Authentication IOTP Transaction 7328 In a Baseline Authentication IOTP Transaction: 7329 o the Authenticator is the organisation which is requesting the 7330 authentication, and 7331 o the Authenticatee is the organisation being authenticated. 7333 A Baseline Authentication IOTP Transaction may occur at any time 7334 between any of the Trading Roles involved in OTP Transactions. This 7335 means it could occur: 7336 o before another IOTP Transaction 7337 o at the same time as another IOTP Transaction 7338 o independently of any other IOTP Transaction. 7340 The authentication consists of: 7341 o an Authentication Request being sent by the Authenticator to 7342 the Authenticatee, and 7343 o an Authentication Response being sent in return by the 7344 Authenticatee to the Authenticator which is then checked. 7346 A Baseline Authentication IOTP Transaction also: 7347 o provides an Authenticatee with an Organisation Component which 7348 describes the Authenticator, and 7349 o optionally provides the Authenticator with Organisation 7350 Components which describe the Authenticatee 7352 The Authentication Request may also be digitally signed which allows 7353 the Authenticatee to verify the credentials of the organisation which 7354 requesting the authentication. 7356 An Authenticatee may decline to be authenticated by sending setting 7357 the CompletionCode of the Status Component in the Authentication 7358 Response Block to Declined. 7360 Example uses of the Baseline Authentication IOTP Transaction include: 7361 o when the Baseline Authentication IOTP Transaction takes place 7362 as an early part of a session where strong continuity exists. 7363 For example, a Financial Institution could: 7364 - set up a secure channel (e.g. using SSL) with a customer 7365 - authenticate the customer using the Baseline Authentication IOTP 7366 Transaction, and then 7367 - provide the customer with access to account information and 7368 other services with the confidence that they are communicating 7369 with a bona fide customer. 7370 o as a means of providing a Merchant role with Organisation 7371 Components that contain information about Consumer and DelivTo 7372 Trading Roles 7373 o so that a Consumer may authenticate a Payment Handler before 7374 starting a payment. 7376 The Baseline Authentication IOTP Transaction consists of just the 7377 Authentication Trading Exchange (see section 2.2.4). 7379 The Trading Blocks used by the Baseline Authentication IOTP 7380 Transaction are: 7381 o Trading Protocol Options Block 7382 o Signature Block 7383 o Authentication Request Block, and 7384 o Authentication Response Block 7386 There are no variations of the Baseline Authentication IOTP 7387 Transaction. 7389 The IOTP Messages used in a Baseline Authentication are illustrated in 7390 the diagram below. 7392 ORGANISATION 1 OTP MESSAGE ORGANISATION 2 7394 1. First organisation 2. The second 7395 takes an action (for organisation generates 7396 example by pressing a ---------------------> an Authentication 7397 button on an HTML Authentication Need Request Block 7398 page) which requires (outside scope of OTP) containing challenge 7399 that the organisation data and the method of 7400 is authenticated authentication to be 7401 used then sends it to 7402 the first organisation 7403 | 7404 v 7405 3. OTP aware application OTPMsg:Trans 7406 started. If a Signature Block <-------------------- Ref Block; 7407 is present the first TPO & Signature 7408 organisation may use this to Authentication Block; TPO 7409 check the credentials of the Request Block; Auth. 7410 second organisation. If it is Response Block; 7411 OK the first organisation 7412 uses the challenge data and 7413 the authentication method 7414 specified in the 7415 Authentication Request Block 7416 to generate an Authentication 7417 Response Block which is sent 7418 back to the first 7419 organisation. Optionally 7420 keeps information on OTP 7421 Transaction for record 7422 keeping purposes and stops 7423 | 7424 v 7425 OTPMsg: Trans 4. The second organisation 7426 Ref Block; ----------------------> checks the Authentication 7427 Signature Authentication Response Response against the 7428 Block; Auth challenge data in the 7429 Response Block Authentication Request Block 7430 | to check that the first 7431 v organisation is who they 7432 STOP appear to be, and stops. 7433 | 7434 v 7435 STOP 7437 Figure 19 Baseline Authentication 7439 The remainder of this sub-section on the Baseline Authentication IOTP 7440 Transaction defines the contents of each Trading Block. 7442 8.1.1 Trading Protocol Options Block 7444 The TPO (Trading Protocol Options) Block (see section 7.1) must 7445 contain the following Trading Component: 7446 o one Protocol Options Component which defines the options which 7447 apply to the whole IOTP Transaction. See Section 6.1. 7449 8.1.2 Authentication Request Block 7451 The Authentication Request Block (see section 7.4) must contain the 7452 following Trading Component: 7453 o one Authentication Data Component (see section 6.2) 7454 o one Organisation Component (see section 6.5) which describes 7455 the Authenticator 7457 8.1.3 Signature Block (Authentication Request) 7459 If the Authentication Request is being digitally signed then a 7460 Signature Block must be included in the same IOTP message that 7461 contains an Authentication Request Block. The Signature Component 7462 contains hashes of the following XML elements: 7463 o the Transaction Reference Block (see section 3.3) for the IOTP 7464 Message which contains the first usage of the Authentication 7465 Request Block within the IOTP Transaction. It contains 7466 information that identifies the IOTP Message and IOTP 7467 Transaction 7468 o the Transaction Id Component (see section 3.3.1) which 7469 globally uniquely identifies the IOTP Transaction 7470 o the following components of the TPO Block : 7471 - the Protocol Options Component 7472 o the following components of the Authentication Request Block: 7473 - the Authentication Data Component 7475 8.1.4 Authentication Response Block 7477 The Authentication Response Block (see section 7.5) must contain the 7478 following Trading Component: 7479 o one Authentication Response Component (see section 6.3) 7480 o one Organisation Component for every Trading Role identified 7481 in the TradingRoleList attribute of the Authentication Data 7482 Component contained in the Authentication Request Block. 7484 8.1.5 Signature Block (Authentication Response) 7486 If the AuthMethod attribute of the Authentication Data Component 7487 contained in the Authentication Request Block indicates that the 7488 Authentication Response should consist of a digital signature then a 7489 Signature Block must be included in the same IOTP message that 7490 contains an Authentication Response Block. The Signature Component 7491 contains hashes of the following XML elements: 7492 o the Transaction Reference Block (see section 3.3) for the IOTP 7493 Message which contains the first usage of the Authentication 7494 Request Block within the IOTP Transaction. It contains 7495 information that identifies the IOTP Message and IOTP 7496 Transaction 7497 o the Transaction Id Component (see section 3.3.1) which 7498 globally uniquely identifies the IOTP Transaction 7499 o the following components of the Authentication Request Block: 7500 - the Authentication Data Component 7501 o the Organisation Components contained in the Authentication 7502 Response Block 7504 [Note] It should not be assumed that all trading roles can support 7505 the signing of data. Particularly it should not be assumed 7506 that Consumers support the signing of data. 7507 [Note End] 7509 8.2 Baseline Deposit IOTP Transaction 7511 The Baseline Deposit IOTP Transaction supports the deposit of 7512 electronic cash with a Financial Institution. 7514 [Note] The Financial Institution has, in IOTP terminology, a role 7515 of merchant in that a service (i.e. a deposit of electronic 7516 cash) is being offered in return for a fee, for example bank 7517 charges of some kind. The term "Financial Institution" is 7518 used in the diagrams and in the text for clarity. 7519 [Note End] 7521 The Baseline Deposit IOTP Transaction consists of the following 7522 Trading Exchanges: 7523 o an optional Authentication Exchange (see section 2.2.4), 7524 o an Offer Exchange (see section 2.2.1), and 7525 o a Payment Exchange (see section 2.2.2). 7527 These Trading Exchanges are implemented by a set of predefined IOTP 7528 Messages (see section o) which are exchanged between the Trading Roles 7529 (see section 2.1). Each IOTP Message contains Trading Blocks (see 7530 section 7) which contain the Trading Components (see section 6) which 7531 are required by the Trading Exchanges. 7533 The Trading Blocks used by the Baseline Purchase IOTP Transaction are: 7534 o Trading Protocol Options Block 7535 o TPO Selection Block 7536 o Authentication Request Block 7537 o Authentication Response Block 7538 o Offer Response Block 7539 o Payment Request Block 7540 o Payment Exchange Block 7541 o Payment Response Block 7542 o Signature Block 7544 8.2.1 Baseline Deposit Variations 7546 The Baseline Deposit IOTP Transaction occurs in two basic forms: 7547 o Baseline Deposit with Authentication. Where the Consumer 7548 making the deposit is authenticated before the deposit is 7549 made, and 7550 o Baseline Deposit without Authentication. Where the Consumer is 7551 not authenticated before the deposit is made. 7553 In both these forms it is assumed that the Payment Brand being used is 7554 determined before the Baseline Deposit transaction starts. This means 7555 that Brand Selection is limited to Payment Protocol selection only. 7557 8.2.2 Baseline Deposit Authentication 7559 In Baseline Deposit with Authentication an Authentication Exchange 7560 occurs before the Offer Exchange containing the details of the deposit 7561 is provided by the Financial Institution. 7563 In Baseline Deposit without Authentication, there is no Authentication 7564 Exchange and the Financial Institution provides details about the 7565 deposit immediately at the start of the IOTP Transaction. 7567 These two alternatives are illustrated in the two diagrams below. The 7568 first diagram illustrates the case when an Authentication Exchange is 7569 included. 7571 CONSUMER OTP MESSAGE FINANCIAL INSTITUTION 7572 1. Consumer decides 2. The Financial 7573 to deposit Institution sets the 7574 electronic cash and -------------------- payment brand and decides 7575 sends information > which protocols to offer, 7576 about how much to Deposit Information generates an 7577 deposit, the brand (outside scope of Authentication Request 7578 to be used, etc to OTP) Block containing challenge 7579 the Financial data and the method of 7580 Institution, e.g. authentication and sends 7581 using HTML to the Consumer 7582 | 7583 v 7584 3. OTP aware application started. OTPMsg:Tran 7585 The consumer selects the payment <--------------------- s Ref 7586 protocol to use, records TPO & Block; TPO 7587 selection in a Brand Selection Authentication Request Block; 7588 Component, generates an Auth.Respon 7589 Authentication Response Component se Block 7590 and sends back to the Financial 7591 Institution. 7593 | 7594 v 7595 OTPMsg: Trans 4. The Financial Institution 7596 Ref Block; Auth --------------------> checks the Authentication 7597 Response Block; TPO Selection & Response against the challenge 7598 TPO Selection Authentication data in the Authentication 7599 Response Request Block, uses the 7600 information to identify the 7601 consumer, generates an Offer 7602 Response Block containing 7603 information about the deposit, 7604 and optional Signature Block 7605 and sends to the Consumer 7606 | 7607 v 7608 5. Consumer checks Offer is OK, OTPMsg: Trans 7609 combines components from the TPO Ref Block; 7610 Block, the TPO Selection Block and <---------------- Signature 7611 the Offer Response Block to create a Offer Response Block; Offer 7612 Pay Request Block and sends to the Response Block 7613 Payment Handler with the Signature 7614 Block if present 7615 | Note that the Financial Institution 7616 v has, in OTP terminology, a role of 7617 CONTINUED "Merchant". 7619 Figure 20 Baseline Deposit with Authentication 7621 Note that the above diagram: 7622 o describes the general case where a Merchant can accept a 7623 deposit in several different types of electronic cash. In 7624 practice usually only one form of electronic cash may be 7625 accepted. However, there may be several different protocols 7626 which may be used for the same "brand" of electronic cash. 7627 o the financial institution may use the results of the 7628 authentication to identify not only the consumer but also the 7629 account to which the payment is to be deposited. If no single 7630 account can be identified, then it must be obtained by other 7631 means. For example: 7632 - the consumer could specify the account number in the initial 7633 dialogue (see step 1), or 7634 - the consumer could have been identified earlier, for example 7635 using a Baseline Authentication IOTP Transaction, and an account 7636 selected from a list provided by the Financial Institution. 7638 The second diagram illustrates the case when an Authentication 7639 Exchange is not included. 7641 CONSUMER OTP MESSAGE FINANCIAL INSTITUTION 7642 1. Consumer decides 2. Financial Institution 7643 to deposit electronic sets the payment brand and 7644 cash and sends ------------------> decides which protocols to 7646 information about how Deposit Information offer, generates an Offer 7647 much to deposit, the (outside scope of Response Block containing 7648 brand to use, etc to OTP) information about the 7649 the Financial deposit, an optional 7650 Institution, e.g. Signature Block and sends 7651 using HTML to the Consumer 7652 | 7653 v 7654 3. OTP aware application started. OTPMsg:Trans 7655 Consumer selects the payment protocol to <------------ Ref Block; 7656 use, records selection in a Brand TPO & Signature 7657 Selection Component, checks Offer is Offer Block; TPO 7658 OK, combines the Brand Selection Response Block; Offer 7659 Component with information from the TPO Response 7660 Block and Offer Response Block to create Block 7661 a Pay Request Block and sends it to the 7662 Payment Handler together with optional 7663 Signature Block 7664 | 7665 v Note that the Financial Institution has, 7666 CONTINUED in OTP terminology, a role of "Merchant". 7668 Figure 21 Baseline Deposit without Authentication 7670 The Baseline Deposit without authentication might be used: 7671 o if a previous IOTP transaction, for example a Baseline 7672 Withdrawal or a Baseline Authentication, authenticated the 7673 consumer, and a secure channel has been maintained, therefore 7674 the authenticity of the consumer is known 7675 o if authentication is achieved as part of a proprietary payment 7676 protocol and is therefore included in the Payment Exchange 7677 o if authentication of the consumer has been achieved by some 7678 other means outside of the scope of IOTP, for example, by 7679 using a pass phrase. 7681 IOTP aware applications supporting the Consumer Trading Role must 7682 check for the existence of an Authentication Request Block in the 7683 first IOTP Message to determine whether the Baseline Deposit includes 7684 an Authentication Exchange or not. 7686 8.2.3 Baseline Deposit Payment Messages 7688 Once the Offer Response Trading Block has been received, the sequence 7689 of IOTP Messages illustrated in Figure 22 occurs. These are the same 7690 whether or not an Authentication of the Consumer has occurred. Note 7691 that these continue where the previous diagrams (Figure 20 and Figure 7692 21) finish. 7694 CONSUMER OTP MESSAGE PAYMENT HANDLER 7695 3/5. Consumer generates Pay 7696 Request Block encapsulating a 7697 payment protocol message if 7698 required and sends to Payment 7699 Handler with the Signature Block 7700 if present 7701 | 7702 v 7703 OtpMsg: Trans 6. Payment Handler processes Pay Request 7704 Ref Block; ----------> Block, checks optional signature and 7705 Signature Payment starts exchanging payment protocol 7706 Block; Pay Request messages, encapsulated in a Pay Exchange 7707 Request Block Block, with the Consumer 7708 | 7709 v 7710 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 7711 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 7712 Exchange Blocks with Block; Pay Payment Exchange Exchange Block 7713 Payment Handler Exchange Block 7714 | 7715 v 7716 8. Eventually payment protocol messages 7717 finish so Payment Handler creates Pay 7718 Receipt Component inside a Pay Response 7719 Block, and an optional Signature 7720 Component inside the Signature Block, 7721 sends to Consumer and stops 7722 | 7723 v 7724 9. Consumer checks Pay OtpMsg: Trans Ref Block; 7725 Response is OK. Optionally <------------- Signature Block; Pay 7726 keeps information on OTP Payment Response Block 7727 Transaction for record Response | 7728 keeping purposes and stops v 7729 | STOP 7730 v 7731 STOP 7733 Figure 22 Baseline Deposit Payment Messages 7735 The remainder of this sub-section on the Baseline Deposit IOTP 7736 Transaction defines the contents of each Trading Block. For most 7737 Trading Blocks, the content does not alter with the variations 7738 described above. Where differences apply, these are stated. 7740 8.2.4 TPO (Trading Protocol Options) Block 7742 The TPO (Trading Protocol Options) Block (see section 8.3.2) must 7743 contain the following Trading Components: 7744 o one Protocol Options Component which defines the options which 7745 apply to the whole IOTP Transaction. See Section 6.1. 7747 o one Brand List Component (see section 6.6) which contains the 7748 payment brand and protocols which may be selected for use in 7749 the Payment Exchange 7750 o Organisation Components (see section 6.5) with the following 7751 roles: 7752 - the Merchant who is accepting the deposit 7753 - the Consumer who is making the deposit 7754 - the PaymentHandlers for the payment 7756 8.2.5 TPO Selection Block 7758 The TPO Selection Block (see section 7.2) is only used by Baseline 7759 Deposit with Authentication. It contains: 7760 o one Brand Selection Component (see section 6.7) for use in the 7761 Payment Exchange. It contains the results of the consumer 7762 selecting a Payment Brand and Payment Protocol from the list 7763 provided in the Brand List Component. 7765 8.2.6 Authentication Request Block 7767 The Authentication Request Block (see section 7.4) must contain the 7768 following Trading Component: 7769 o one Authentication Data Component (see section 6.2) 7771 8.2.7 Authentication Response Block 7773 The Authentication Response Block (see section 7.5) must contain the 7774 following Trading Component: 7775 o one Authentication Response Component (see section 6.3). 7777 8.2.8 Offer Response Block 7779 The Offer Response Block (see section 7.3) must contain the following 7780 components: 7781 o zero or one Authentication Data Component (see section 6.2) An 7782 Authentication Data Component is required for each Payment 7783 Exchange, where its Payment Component contains an AuthDataRef 7784 attribute 7785 o one Order Component (see section 6.4) which contains details 7786 about the deposit, for example the amount of value being 7787 deposited and any fees which might apply 7788 o one Payment Component (see section 6.8) which contains 7789 information about the payment which is to be made 7790 o one Delivery Component (see section 6.12) with the DelivExch 7791 attribute set to False 7793 The Offer Response Block may also contain one or more Trading Role 7794 Data Components (see section 6.16). 7796 [Note] A role of Merchant is used in the above description since a 7797 service (i.e. a deposit of electronic cash) is being offered 7798 in return for a fee, for example bank charges of some kind. 7799 The term "Financial Institution" is used in the diagrams and 7800 in the text for clarity. 7801 [Note End] 7803 8.2.9 Signature Block (Offer Response) 7805 If the Baseline Deposit Offer Response is being digitally signed then 7806 a Signature Block must be included in the same IOTP message that 7807 contains an "Offer Response" Signature Component (see section 6.18). 7808 The Signature Component contains hashes of the following XML elements: 7809 o the Transaction Reference Block (see section 3.3) for the IOTP 7810 Message which contains the first usage of the Offer Response 7811 Block within the IOTP Transaction. It contains information 7812 that identifies the IOTP Message and IOTP Transaction 7813 o the Transaction Id Component (see section 3.3.1) which 7814 globally uniquely identifies the IOTP Transaction 7815 o the following components of the Offer Response Block: 7816 - the Authentication Data Component if present 7817 - the Order Component 7818 - the Payment Component 7819 - all the Organisation Components present, and 7820 - the Delivery Component 7821 - any Trading Role Data Components 7822 o the following components of the TPO Block : 7823 - the Protocol Options Component, and 7824 - the Brand List Component 7826 If the Baseline Deposit is a Baseline Deposit with Authentication then 7827 the Signature Component additionally contains a hash of the following: 7828 o the Brand Selection Component contained in the TPO Selection 7829 Block. 7831 8.2.10 Payment Request Block 7833 The Payment Request Block (see section 7.6) contains: 7834 o the following components copied from the Offer Response Block: 7835 - the Status Component 7836 - the Authentication Data Component if present 7837 - the Payment Component 7838 - the Organisation Components with the roles of: Merchant and 7839 PaymentHandler 7840 o the following component from the TPO Block: 7841 - the Brand List Component 7842 o one Brand Selection Component either: 7843 - copied from the Offer Response Block if the deposit is a 7844 Baseline Deposit with Authentication, or 7846 - created by the Consumer, containing the payment brand and 7847 payment protocol selected, if the deposit is a Baseline Deposit 7848 without Authentication 7849 o one Payment Scheme Component (see section 6.9) if required by 7850 the payment method used (see the Payment Method supplement to 7851 determine if this is needed). 7853 The Payment Request Block may also contain one or more Trading Role 7854 Data Components (see section 6.16). 7856 Payment Handlers should check that they are authorised to carry out 7857 the Payment (see section 5 Security Considerations). 7859 8.2.11 Signature Block (Payment Request) 7861 If the Baseline Deposit Offer Response Block was signed then the IOTP 7862 Message that contains the Payment Request Block must also contain a 7863 Signature Block with a copy of the "Offer Response" Signature 7864 Component. 7866 8.2.12 Payment Exchange Block 7868 The Payment Exchange Block (see section 7.7) contains: 7869 o one Payment Scheme Component (see section 6.9) which contains 7870 payment method specific data. See the Payment Method 7871 supplement for the payment method being used to determine what 7872 this should contain. 7874 8.2.13 Payment Response Block 7876 The Payment Response Block (see section 7.8) contains: 7877 o one Payment Receipt Component(see section 6.10) which contains 7878 scheme specific data which can be used to verify the payment 7879 occurred 7880 o one Payment Scheme Component (see section 6.9) if required 7881 which contains payment method specific data. See the Payment 7882 Method supplement for the payment method being used to 7883 determine what this should contain 7884 o the "Offer Response" Signature Component (see section 6.18) 7885 from the Payment Request Block if present. 7887 The Payment Response Block may also contain: 7888 o a Payment Note Component (see section 6.11) 7889 o one or more Trading Role Data Components (see section 6.16). 7891 8.2.14 Signature Block (Payment Response) 7893 If a signed Payment Receipt is being provided, indicated by the 7894 SignedPayReceipt attribute of the Payment Component of the Offer 7895 Response Block being set to True, then the IOTP Message that contains 7896 the Payment Response Block must also contain a Signature Block with a 7897 "Payment Receipt" Signature Component which contains hashes of the 7898 following: 7899 o the Transaction Reference Block (see section 3.3) for the IOTP 7900 Message which contains the first usage of the Payment Response 7901 Block, 7902 o the Transaction Id Component (see section 3.3.1) within the 7903 Transaction Reference Block that globally uniquely identifies 7904 the IOTP Transaction, 7905 o the Payment Receipt Component from the Payment Response Block, 7906 o the other Components referenced by the PayReceiptRefs 7907 attribute (if present) of the Payment Receipt Component, 7908 o the Status Component from the Payment Response Block, 7909 o any Trading Role Data Components in the Payment Response 7910 Block, and 7911 o the "Offer Response" Signature Component from the Payment 7912 Request Block if present. 7914 8.3 Baseline Purchase IOTP Transaction 7916 The Baseline Purchase IOTP Transaction supports the purchase of goods 7917 or services using any payment method. It consists of the following 7918 Trading Exchanges: 7919 o an Offer Exchange (see section 2.2.1), 7920 o a Payment Exchange (see section 2.2.2), and 7921 o an optional Delivery Exchange (see section 2.2.3) 7923 These Trading Exchanges are implemented by a set of predefined IOTP 7924 Messages (see section o) which are exchanged between the Trading Roles 7925 (see section 2.1). Each IOTP Message contains Trading Blocks (see 7926 section 7) which contain the Trading Components (see section 6) which 7927 are required by the Trading Exchanges. 7929 The Trading Blocks used by the Baseline Purchase IOTP Transaction are: 7930 o Trading Protocol Options Block 7931 o TPO Selection Block 7932 o Offer Response Block 7933 o Payment Request Block 7934 o Payment Exchange Block 7935 o Payment Response Block 7936 o Delivery Request Block 7937 o Delivery Response Block 7938 o Signature Block 7940 8.3.1 Baseline Purchase Variations 7942 The Baseline Purchase IOTP Transaction occurs in two basic forms: 7943 o Brand Dependent Purchase. Where the content of the offer, e.g. 7944 the order details, amount, delivery details, etc., are 7945 dependent on the payment brand and protocol selected by the 7946 consumer, and 7947 o Brand Independent Purchase. Where the content of the offer is 7948 not dependent on the payment brand and protocol selected. 7950 Further variation is supported in that: 7951 o the Delivery Exchange is optional, and 7952 o the Delivery Response Block may be sent to the consumer 7953 either: 7954 - at the same time as the Payment Response Block, or 7955 - after the Payment Response Block as the result of the Consumer 7956 sending the Delivery Handler a Delivery Request Block. 7958 8.3.1.1 Brand Dependent Purchases 7960 In a Brand Dependent Purchase the TPO Block and the Offer Response 7961 Block are sent separately by the Merchant to the Consumer, i.e.: 7962 o the Brand List Component is sent to the Consumer in a TPO 7963 Block, 7964 o the Consumer selects a Payment Brand, Payment Protocol and 7965 optionally a Currency and amount from the Brand List Component 7966 o the Consumer sends the selected brand, protocol and 7967 currency/amount back to the Merchant in a TPO Selection Block, 7968 and 7969 o the Merchant uses the information received to define the 7970 content of and then send the Offer Response Block to the 7971 Consumer. 7973 In a Brand Independent Purchase the TPO Block and the Offer Response 7974 Block are sent together by the Merchant to the Consumer in the same 7975 IOTP Message at the start of the IOTP Transaction. 7977 These two alternatives are illustrated in the two diagrams below. The 7978 first diagram illustrates a Brand Dependent Purchase. 7980 CONSUMER OTP MESSAGE MERCHANT 7981 1. Consumer decides 2. Merchant decides which 7982 to trade and sends payment brand and 7983 information about --------------------> protocols to offer, places 7984 what to purchase to Purchase Information them in a Brand List 7985 the Merchant, e.g. (outside scope of Component in a TPO Block, 7986 using HTML OTP) and sends to Consumer 7987 | 7988 v 7989 3. OTP aware application started. Consumer OTPMsg: 7990 selects the payment brand and payment <----------- Trans Ref 7991 protocol to use, records selection in a TPO Block; TPO 7992 Brand Selection Component, and sends back Block 7993 to Merchant 7994 | 7995 v 7997 OTPMsg:Trans 4. Merchant uses payment brand and 7998 Ref Block; TPO ------------> protocol selected and information on 7999 Selection TPO Selection what is being purchased to create an 8000 Block Offer Response Block containing details 8001 about goods ordered, price, etc. 8002 optionally signs it and sends to 8003 Consumer 8004 | 8005 v 8006 5. Consumer checks Offer is OK, OTPMsg:Trans 8007 combines components from the TPO <--------------- Ref Block; 8008 Block, the TPO Selection Block and Offer Response Signature 8009 the Offer Response Block to create Block; Offer 8010 a Pay Request Block and sends it to Response Block 8011 the Payment Handler together with 8012 the Signature Block if present 8013 | 8014 v 8015 CONTINUED 8017 Figure 23 Brand Dependent Baseline Purchase 8019 The second diagram illustrates the Brand Independent Purchase. 8021 CONSUMER OTP MESSAGE MERCHANT 8022 1. Consumer 2. Merchant decides which 8023 decides to payment brand and protocols to 8024 trade and sends --------------------> offer, places them in a Brand 8025 information Purchase Information List Component in a TPO Block, 8026 about what to (outside scope of creates an Offer Response 8027 purchase to the OTP) Block containing details about 8028 Merchant, e.g. goods ordered, price, etc, 8029 using HTML optionally signs it and sends 8030 to Consumer 8031 | 8032 v 8033 3. OTP aware application OTPMsg: Trans Ref 8034 started. Consumer selects the <------------- Block; Signature 8035 payment brand and payment TPO & Block; TPO Block; 8036 protocol to use, records Offer Response Offer Response Block 8037 selection in a Brand Selection 8038 Component, checks Offer is OK, 8039 combines the Brand Selection 8040 Component with information from 8041 the TPO Block and Offer Response 8042 Block to create a Pay Request 8043 Block and sends it to the 8044 Payment Handler together with 8045 the Signature Block if present 8046 | 8047 v 8048 CONTINUED 8050 Figure 24 Brand Independent Baseline Purchase 8052 A Brand Independent Purchase always occurs when only one payment brand 8053 and protocol is being offered to the Consumer by the Merchant. It is 8054 also likely to, but will not necessarily, occur when multiple brands 8055 are being offered, the Payment Handler is the same, and all brands use 8056 the same set of protocols. 8058 Note that the TPO Block and the Offer Response Block may be sent in 8059 separate IOTP messages even if the Offer Response Block does not 8060 change. However this increases the number of messages in the 8061 transaction and is therefore likely to increase transaction response 8062 times. 8064 IOTP aware applications supporting the Consumer Trading Role must 8065 check for the existence of an Offer Response Block in the first IOTP 8066 Message to determine whether the Baseline Purchase is brand dependent 8067 or not. 8069 8.3.1.2 Combining Delivery Response Block and Payment Response Block 8071 The Delivery Response Block and the Payment Response Block may be 8072 sent: 8073 o separately by the Payment Handler to the Consumer, i.e.: 8074 - the Payment Response Block containing a Payment Receipt and 8075 optional signature for the payment is sent by the Payment 8076 Handler to the Consumer, 8077 - the Consumer combines these components from the Payment Response 8078 Block with components from the Offer Response Block, to create a 8079 Delivery Request Block 8080 - the Consumer sends the Delivery Request Block to the Delivery 8081 Handler 8082 - the Delivery Handler processes the Delivery Request Block and 8083 sends a Delivery Response Block back to the Consumer, or 8084 o together, from the Payment Handler to the Consumer, when the 8085 Payment Exchange is complete. 8087 These two alternatives are illustrated in the two diagrams below. 8089 The first diagram illustrates when the Delivery Response Block and the 8090 Payment Response Block are sent to the Consumer in separate IOTP 8091 Messages. Note, these diagrams continue where the previous diagrams 8092 (Figure 23 and Figure 24) finish. 8094 CONSUMER OTP MESSAGE PAYMENT HANDLER 8095 3/5. Consumer generates Pay Request 8096 Block encapsulating a payment 8097 protocol message if required and 8098 sends to Payment Handler 8099 | 8100 v 8101 tpMsg: Trans Ref 6. Payment Handler checks optional 8102 Block; Signature -------------> signature, processes Pay Request 8103 Block; Pay Payment Block, and starts exchanging payment 8104 Request Block Request protocol messages, encapsulated in a 8105 Pay Exchange Block, with the 8106 Consumer 8107 | 8108 v 8109 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 8110 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 8111 xchange Blocks with Block; Pay Payment Exchange Exchange Block 8112 Payment Handler Exchange Block 8113 | 8114 v 8115 8. Eventually payment protocol 8116 messages finish so Payment Handler 8117 creates Pay Receipt Component and 8118 inside a Pay Response Block, and an 8119 optional Signature Component in the 8120 Signature Block, sends to Consumer 8121 and stops 8122 | 8123 v 8124 9. Consumer checks Pay Response is OtpMsg: Trans 8125 OK, and creates Delivery Request <--------------- Ref Block; 8126 from Pay Response Block, Offer Payment Response Signature Block 8127 Response Block and Signature Block Pay Response 8128 and sends to the Delivery Handler Block 8129 | ==================================================== 8130 v DELIVERY HANDLER 8131 tpMsg: Trans Ref 10. Delivery Handler checks Pay 8132 Block; Signature -------------> Receipt, Order in Offer Response and 8133 Block Delivery Delivery the optional Signatures, creates a 8134 Request Block Request Delivery Response Block, sends to 8135 Consumer and stops 8136 | 8137 v 8138 10. Consumer checks Delivery OtpMsg: Trans Ref 8139 Response Block is OK, <------------- Block; Delivery 8140 ptionally keeps information on Delivery Response Block 8141 OTP Transaction for record Response | 8142 keeping purposes and stops v 8143 STOP 8144 | 8145 v 8146 STOP 8148 Figure 25 Baseline Purchase, Delivery Response Block and Payment 8149 Response Blocks Not Combined 8150 The second diagram illustrates the case when the Delivery Response 8151 Block and the Payment Response Block are combined into one IOTP 8152 Message. 8154 CONSUMER OTP MESSAGE MERCHANT 8155 3/5. Consumer generates Pay 8156 Request Block encapsulating a 8157 payment protocol message if 8158 required and sends to Payment 8159 Handler together with Signature 8160 Block if present 8161 | 8162 v 8163 OtpMsg: Trans 6. Payment Handler processes Pay 8164 Ref Block; -------------> Request, and starts exchanging 8165 Signature Block; Payment payment protocol messages, 8166 Pay Request Request encapsulated in a Pay Exchange 8167 Block Block, with the Consumer 8168 | 8169 v 8170 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 8171 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 8172 xchange Blocks with Block; Pay Payment Exchange Exchange Block 8173 Payment Handler Exchange Block 8174 | 8175 v 8176 8. Eventually payment protocol 8177 messages finish so Payment 8178 Handler creates Pay Receipt 8179 Component inside a Pay Response 8180 Block and an optional Signature 8181 Component, then uses information 8182 from the Offer Response Block to 8183 create a Delivery Response Block, 8184 sends both to Consumer and stops 8185 | 8186 v 8187 9. Consumer checks Pay OtpMsg: Trans Ref Block; 8188 Response and Delivery <--------------- Signature Block; Pay 8189 Response Blocks are OK, Payment Response Response Block; Delivery 8190 optionally keeps & Delivery Response Block 8191 information on OTP Response | 8192 Transaction for record v 8193 keeping purposes and stops STOP 8194 | 8195 v 8196 STOP 8198 Figure 26 Baseline Purchase, Delivery Response Block and Payment 8199 Response Block Combined 8200 The Delivery Response Block and the Payment Response Block may be 8201 combined into the same IOTP Message only if the Payment Handler has 8202 the information available so that she can send the Delivery Response 8203 Block. This is likely to, but will not necessarily, occur when the 8204 Merchant, the Payment Handler and the Delivery Handler Roles are 8205 combined. 8207 The DelivAndPayResp attribute of the Delivery Component (see section 8208 6.12) contained within the Offer Response Block (see section 7.3) is 8209 set to True if the Delivery Response Block and the Payment Response 8210 Block are combined into the same IOTP Message and is set to False if 8211 the Delivery Response Block and the Payment Response Block are sent in 8212 separate IOTP Messages. 8214 8.3.1.3 Optional Delivery Exchange 8216 The final variation of the Baseline Purchase IOTP Transactions is a 8217 purchase without a delivery step. This is illustrated in the following 8218 diagram which continues where the earlier diagrams (Figure 23and 8219 Figure 24) finish. 8221 CONSUMER OTP MESSAGE MERCHANT 8222 3/5. Consumer generates Pay 8223 Request Block encapsulating a 8224 payment protocol message if 8225 required and sends to Payment 8226 Handler together with Signature 8227 Block if present 8228 | 8229 v 8230 OtpMsg: Trans Ref 6. Payment Handler checks 8231 Block; Signature ---------------> signature, processes Pay Request 8232 Block; Pay Request Payment Request Block, and starts exchanging 8233 Block payment protocol messages, 8234 encapsulated in a Pay Exchange 8235 Block, with the Consumer 8236 | 8237 v 8238 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 8239 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 8240 Exchange Blocks with Block; Pay Payment Exchange Exchange Block 8241 Payment Handler Exchange Block | 8242 | 8243 v 8244 8. Eventually payment protocol 8245 messages finish so Payment 8246 Handler creates Pay Receipt 8247 Component inside a Pay 8248 Response Block and optional 8249 Signature Component, sends to 8250 Consumer and stops 8251 | 8252 v 8253 9. Consumer checks Pay OtpMsg: Trans Ref Block; 8254 Response is OK, <------------ Signature Block; Pay 8255 optionally keeps Payment Response Block 8256 information on OTP Response | 8257 Transaction for record v 8258 keeping purposes and STOP 8259 stops 8260 | 8261 v 8262 STOP 8264 Figure 27 Baseline Purchase, Purchase without Delivery Exchange 8266 The DelivExch attribute of the Delivery Component (see section 6.12) 8267 contained in the Offer Response Block (see section 7.3) is set to 8268 False if the Delivery Exchange is omitted and is set to True if the 8269 Delivery Exchange is included. 8271 8.3.1.4 Combining Variations 8273 The diagram below shows how the different variations in the Baseline 8274 Purchase Transaction may be combined. 8276 START 8277 | 8278 v 8279 Offer Response Block in first OTP Message? 8280 |=True |=False 8281 v v 8282 Brand Brand 8283 Independent Dependent 8284 Purchase Purchase 8285 | =True =False | 8286 ------------ ----------- 8287 | | 8288 v v 8289 DelivExch ? 8290 =True | | =False 8291 ----------- ------------ 8292 | | 8293 v v 8294 DelivAndPayResp ? Purchase without 8295 | | Delivery Exchange 8296 =False| |=True | 8297 -------- -------- v 8298 | | STOP 8299 v v 8300 Delivery Response Delivery 8301 Block and Pay Response Block 8302 Response Blocks and Pay Response 8303 Not Combined Blocks Combined 8304 | | 8305 v v 8306 STOP STOP 8308 Figure 28 Baseline Purchase Variations 8310 The remainder of this sub-section on the Baseline Purchase IOTP 8311 Transaction defines the contents of each Trading Block. For most 8312 Trading Blocks, the content does not alter with the variations 8313 described above. Where differences apply, these are stated. 8315 8.3.2 TPO (Trading Protocol Options) Block 8317 The TPO (Trading Protocol Options) Block (see section 8.3.2) must 8318 contain the following Trading Components: 8319 o one Protocol Options Component which defines the options which 8320 apply to the whole IOTP Transaction. See Section 6.1. 8321 o one Brand List Component (see section 6.6) which contains one 8322 or more payment brands and protocols which may be selected for 8323 use in the Payment Exchange 8324 o Organisation Components (see section 6.5) with the following 8325 roles: 8326 - Merchant who is providing the goods or services 8327 - Consumer who is making the purchase 8328 - PaymentHandlers for the payment. 8330 8.3.3 TPO Selection Block 8332 The TPO Selection Block (see section 7.2) is only used by Brand 8333 Dependent Purchase. It contains: 8334 o one Brand Selection Component (see section 6.7) for use in the 8335 Payment Exchange. It contains the results of the consumer 8336 selecting a Payment Brand and Payment Protocol from the list 8337 provided in the Brand List Component. 8339 8.3.4 Offer Response Block 8341 The Offer Response Block (see section 7.3) contains the following 8342 components: 8343 o zero or one Authentication Data Component (see section 6.2) An 8344 Authentication Data Component is required for each Payment 8345 Exchange, where its Payment Component (see section 6.8) 8346 contains an AuthDataRef attribute. 8347 o one Order Component (see section 6.4) which contains details 8348 about the goods, services which are being purchased 8350 o one Payment Component (see section 6.8) which contains 8351 information about the payment which is to be made 8352 o Organisation Components (see section 6.5) with the following 8353 roles: 8354 - Merchant who is providing the goods or services 8355 - Consumer who is making the purchase 8356 - PaymentHandler for the payment. The "ID" of the Payment Handler 8357 Organisation Component is contained within the VaOrgRef 8358 attribute of the Payment Component 8359 o one Delivery Component (see section 6.12) which contains 8360 details of the delivery to be made. 8362 If the Baseline Purchase includes a Delivery Exchange then the Offer 8363 Response Block must also contain: 8364 o Organisation Components with the following roles: 8365 - DeliveryHandler who will be delivering the goods or services 8366 - DelivTo i.e. the person or organisation which is to take 8367 delivery 8369 The Offer Response Block may also contain one or more Trading Role 8370 Data Components (see section 6.16). 8372 8.3.5 Signature Block (Offer Response) 8374 If the Baseline Purchase Offer Response is being digitally signed then 8375 a Signature Block must be included in the same IOTP message that 8376 contains an "Offer Response" Signature Component (see section 6.18). 8377 The Signature Component contains hashes of the following XML elements: 8378 o the Transaction Reference Block (see section 3.3) for the IOTP 8379 Message which contains the first usage of the Offer Response 8380 Block within the IOTP Transaction. It contains information 8381 that identifies the IOTP Message and IOTP Transaction 8382 o the Transaction Id Component (see section 3.3.1) which 8383 globally uniquely identifies the IOTP Transaction 8384 o the following components of the Offer Response Block: 8385 - the Authentication Data Component if present 8386 - the Order Component 8387 - the Payment Component 8388 - all the Organisation Components present, and 8389 - the Delivery Component, 8390 - any Trading Role Data Components 8391 o the following components of the TPO Block : 8392 - the Protocol Options Component, and 8393 - the Brand List Component 8395 If the Baseline Purchase is a Brand Dependent Purchase then the 8396 Signature Component additionally contains a hash of the following: 8397 o the Brand Selection Component contained in the TPO Selection 8398 Block. 8400 8.3.6 Payment Request Block 8402 The Payment Request Block (see section 7.6) contains: 8403 o the following components copied from the Offer Response Block: 8404 - the Status Component 8405 - the Authentication Data Component if present 8406 - the Payment Component 8407 - the Organisation Components with the roles of: Merchant and 8408 PaymentHandler 8409 o the following component from the TPO Block: 8410 - the Brand List Component 8411 o one Brand Selection Component either: 8412 - copied from the Offer Response Block if the purchase is a Brand 8413 Dependent Purchase, or 8414 - created by the Consumer, containing the payment brand and 8415 payment protocol selected, if the purchase is a Brand 8416 Independent Purchase 8417 o one Payment Scheme Component (see section 6.9) if required by 8418 the payment method used (see the Payment Method supplement to 8419 determine if this is needed). 8421 The Payment Request Block may also contain one or more Trading Role 8422 Data Components (see section 6.16). 8424 Payment Handlers should check that they are authorised to carry out 8425 the Payment (see section 5 Security Considerations). 8427 8.3.7 Signature Block (Payment Request) 8429 If the Baseline Purchase Offer Response Block was signed then the IOTP 8430 Message that contains the Payment Request Block must also contain a 8431 Signature Block with a copy of the "Offer Response" Signature 8432 Component. 8434 8.3.8 Payment Exchange Block 8436 The Payment Exchange Block (see section 7.7) contains: 8437 o one Payment Scheme Component (see section 6.9) which contains 8438 payment method specific data. See the Payment Method 8439 supplement for the payment method being used to determine what 8440 this should contain. 8442 8.3.9 Payment Response Block 8444 The Payment Response Block (see section 7.8) contains: 8445 o one Payment Receipt Component (see section 6.10) which 8446 contains scheme specific data which can be used to verify the 8447 payment occurred 8448 o one Payment Scheme Component (see section 6.9) if required 8449 which contains payment method specific data. See the Payment 8450 Method supplement for the payment method being used to 8451 determine what this should contain 8452 o the "Offer Response" Signature Component (see section 6.18) 8453 from the Payment Request Block if present 8455 The Payment Response Block may also contain: 8456 o a Payment Note Component (see section 6.11) 8457 o one or more Trading Role Data Components (see section 6.16). 8459 8.3.10 Signature Block (Payment Response) 8461 If a signed Payment Receipt is being provided, indicated by the 8462 SignedPayReceipt attribute of the Payment Component of the Offer 8463 Response Block being set to True, then the IOTP Message that contains 8464 the Payment Response Block must also contain a Signature Block with a 8465 "Payment Receipt" Signature Component which contains hashes of the 8466 following: 8467 o the Transaction Reference Block (see section 3.3) for the IOTP 8468 Message which contains the first usage of the Payment Response 8469 Block, 8470 o the Transaction Id Component (see section 3.3.1) within the 8471 Transaction Reference Block that globally uniquely identifies 8472 the IOTP Transaction, 8473 o the Payment Receipt Component from the Payment Response Block 8474 o the other Components referenced by the PayReceiptRefs 8475 attribute (if present) of the Payment Receipt Component, 8476 o the Status Component from the Payment Response Block 8477 o any Trading Role Data Components in the Payment Response 8478 Block, and 8479 o the "Offer Response" Signature Component from the Payment 8480 Request Block if present. 8482 8.3.11 Delivery Request Block 8484 The Delivery Request Block (see section 7.9) contains: 8485 o the following components copied from the Offer Response Block: 8486 - the Status Component (see section 6.15) 8487 - the Order Component (see section 6.4) 8488 - the Organisation Component (see section 6.5) with the roles of: 8489 Merchant, DeliveryHandler and DeliverTo 8490 - the Delivery Component (see section 6.12) 8491 o the following Component from the Payment Response Block: 8492 - the Status Component (see section 6.15). 8494 The Delivery Request Block may also contain one or more Trading Role 8495 Data Components (see section 6.16). 8497 Payment Handlers should check that they are authorised to carry out 8498 the Payment (see section 5 Security Considerations). 8500 8.3.12 Signature Block (Delivery Request) 8502 If the Baseline Purchase Offer Response or Payment Response Blocks 8503 were signed then the IOTP Message that contains the Delivery Request 8504 Block must also contain a Signature Block with a copy of: 8505 o the "Offer Response" Signature Component if present, and/or 8506 o the "Payment Receipt" Signature Component, if present 8508 8.3.13 Delivery Response Block 8510 The Delivery Response Block contains: 8511 o one Delivery Note Component (see section 6.13) which contains 8512 delivery instructions about the delivery of goods or services 8514 8.4 Baseline Refund IOTP Transaction 8516 In business terms the refund process typically consists of: 8517 o a request for a refund being made by the Consumer to the 8518 Merchant, typically supported by evidence to demonstrate: 8519 - the original trade took place, for example by providing a 8520 receipt for the original transaction 8521 - using some type of authentication, that the consumer requesting 8522 the refund is the consumer, or a representative of the consumer, 8523 who carried out the original trade 8524 - the reason why the merchant should make the refund 8525 o the merchant agreeing (or not) to the refund. This may involve 8526 some negotiation between the Consumer and the Merchant, and, 8527 if the merchant agrees, 8528 o a refund payment by the Merchant to the Consumer. 8530 The Baseline Refund IOTP Transaction supports a subset of the above, 8531 specifically it supports: 8532 o the optional authentication of the Consumer using an 8533 Authentication Exchange (see section 2.2.4), and 8534 o the refund payment by the Merchant to the Consumer using the 8535 following two Trading Exchanges: 8536 - an Offer Exchange (see section 2.2.1), and 8537 - a Payment Exchange (see section 2.2.2). 8539 These Trading Exchanges are implemented by a set of predefined IOTP 8540 Messages (see section o) which are exchanged between the Trading Roles 8541 (see section 2.1). Each IOTP Message contains Trading Blocks (see 8542 section 7) which contain the Trading Components (see section 6) which 8543 are required by the Trading Exchanges. 8545 The Trading Blocks used by the Baseline Purchase IOTP Transaction are: 8546 o Trading Protocol Options Block 8547 o TPO Selection Block 8548 o Authentication Request Block 8549 o Authentication Response Block 8550 o Offer Response Block 8551 o Payment Request Block 8552 o Payment Exchange Block 8553 o Payment Response Block 8554 o Signature Block 8556 8.4.1 Baseline Refund Variations 8558 The Baseline Refund IOTP Transaction occurs in two basic forms: 8559 o Baseline Refund with Authentication. Where the Consumer 8560 requesting the refund is authenticated before the refund is 8561 made, and 8562 o Baseline Refund without Authentication. Where the Consumer is 8563 not authenticated before the refund is made. 8565 8.4.2 Baseline Refund Authentication 8567 In Baseline Refund with Authentication an Authentication Exchange 8568 occurs before the Offer Exchange containing the details of the refund 8569 is provided by the Merchant. 8571 In Baseline Refund without Authentication, there is no Authentication 8572 Exchange and the Merchant provides details about the refund 8573 immediately at the start of the IOTP Transaction. 8575 These two alternatives are illustrated in the two diagrams below. The 8576 first diagram illustrates the case when an Authentication Exchange is 8577 included. 8579 CONSUMER OTP MESSAGE MERCHANT 8580 1. Consumer requests 2. The Merchant sets the 8581 payment of payment brand and decides 8582 previously agreed ------------------> which protocols to offer, 8583 refund, sends Refund Information generates an 8584 information about (outside scope of Authentication Request 8585 refund, such as a OTP) Block containing challenge 8586 reference number to data and the method of 8587 the Merchant, e.g. authentication and sends 8588 using HTML to the Consumer 8589 | 8590 v 8591 3. OTP aware application OTPMsg:Trans Ref 8592 started. The consumer selects <-------------- Block; TPO Block; 8593 payment protocol to use, TPO & Auth.Response Block 8594 records selection in a Brand Authentication 8595 Selection Component, generates Request 8596 an Authentication Response 8597 Component and sends both back 8598 to the Merchant. 8599 | 8600 v 8602 OTPMsg: Trans 4. The Merchant checks the 8603 Ref Block; ---------------> Authentication Response against the 8604 Auth Response TPO Selection & challenge data in the Authentication 8605 Block; TPO Authentication Request Block, uses the information 8606 Selection Response to identify the consumer and refund, 8607 Block generates an Offer Response Block 8608 containing information about the 8609 refund, an optional Signature Block 8610 and sends to the Consumer 8611 | 8612 v 8613 5. Consumer checks Offer is OK, OTPMsg: Trans 8614 combines components from the TPO <--------------- Ref Block; 8615 Block, the TPO Selection Block and Offer Response Signature 8616 the Offer Response Block to create Block; Offer 8617 a Pay Request Block and sends to Response Block 8618 the Payment Handler together with 8619 optional Signature 8620 | 8621 v 8622 CONTINUED 8624 Figure 29 Baseline Refund with Authentication 8626 The second diagram illustrates the case when an Authentication 8627 Exchange is not included. 8629 CONSUMER OTP MESSAGE MERCHANT 8630 1. Consumer requests 2. Merchant sets the payment 8631 payment of previously brand and decides which 8632 agreed refund, sends --------------> protocols to offer, 8633 information about Refund generates an Offer Response 8634 refund to the Merchant, Information Block containing information 8635 such as a reference (outside scope about the refund, an 8636 number, using, for of OTP) optional Signature Block and 8637 example, HTML sends to the Consumer 8638 | 8639 v 8640 3. OTP aware application started. OTPMsg:Trans 8641 Consumer selects the payment protocol <-------------- Ref Block; 8642 to use, records selection in a Brand TPO & Signature 8643 Selection Component, checks Offer is Offer Response Block; TPO 8644 OK, combines the Brand Selection Block; Offer 8645 Component with information from the TPO Response 8646 Block and Offer Response Block to Block 8647 create a Pay Request Block and sends it 8648 to the Payment Handler together with 8649 optional Signature Block 8650 | 8651 v 8652 CONTINUED 8654 Figure 30 Baseline Refund without Authentication 8656 The Baseline Refund without authentication might be used: 8657 o when authentication of the consumer has been achieved by some 8658 other means, for example, the consumer has entered some 8659 previously supplied code in order to identify herself and the 8660 refund to which the code applies. The code could be supplied, 8661 for example on a web page or by e-mail. 8662 o when a previous IOTP transaction, for example a Baseline 8663 Authentication, authenticated the consumer, and a secure 8664 channel has been maintained, therefore the authenticity of the 8665 consumer is known and therefore the previously agreed refund 8666 can be identified. 8667 o when the authentication of the consumer is carried out by the 8668 Payment Handler using a payment scheme authentication method. 8670 IOTP aware applications supporting the Consumer Trading Role must 8671 check for the existence of an Authentication Request Block in the 8672 first IOTP Message to determine whether the Baseline Refund includes 8673 an Authentication Exchange or not. 8675 8.4.3 Baseline Refund Payment Messages 8677 Once the Offer Response Trading Block has been received, the sequence 8678 of IOTP Messages illustrated in Figure 31 occurs. These are the same 8679 whether or not an Authentication of the Consumer has occurred. Note 8680 that these continue where the previous diagrams (Figure 29 and Figure 8681 30) finish. 8683 CONSUMER OTP MESSAGE PAYMENT HANDLER 8684 3/5. Consumer generates Pay 8685 Request Block encapsulating a 8686 payment protocol message if 8687 required and sends to Payment 8688 Handler together with optional 8689 Signature Block 8690 | 8691 v 8692 tpMsg: Trans Ref 6. Payment Handler checks signature, 8693 Block; Signature ------------> processes Pay Request Block, and 8694 Block; Pay Payment starts exchanging payment protocol 8695 Request Block Request messages, encapsulated in a Pay 8696 Exchange Block, with the Consumer 8697 | 8698 v 8699 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 8700 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 8701 xchange Blocks with Block; Pay Payment Exchange Exchange Block 8702 Payment Handler Exchange Block 8703 | 8704 v 8706 8. Eventually payment protocol 8707 messages finish so Payment Handler 8708 creates Pay Receipt Component 8709 inside a Pay Response Block, sends 8710 to Consumer with and optional 8711 Signature Component and stops 8712 | 8713 v 8714 9. Consumer checks Pay OtpMsg: Trans Ref Block; 8715 esponse is OK. Optionally <--------------- Signature Block; Pay 8716 keeps information on OTP Payment Response Response Block 8717 Transaction for record | 8718 eeping purposes and stops v 8719 | STOP 8720 v 8721 STOP 8723 Figure 31 Baseline Refund Payment Messages 8725 The remainder of this sub-section on the Baseline Refund IOTP 8726 Transaction defines the contents of each Trading Block. For most 8727 Trading Blocks, the content does not alter with the variations 8728 described above. Where differences apply, these are stated. 8730 8.4.4 TPO (Trading Protocol Options) Block 8732 The TPO (Trading Protocol Options) Block (see section 8.3.2) must 8733 contain the following Trading Components: 8734 o one Protocol Options Component which defines the options which 8735 apply to the whole IOTP Transaction. See Section 6.1. 8736 o one Brand List Component (see section 6.6) which contains the 8737 payment brand and protocols which may be selected for use in 8738 the Payment Exchange 8739 o Organisation Components (see section 6.5) with the following 8740 roles: 8741 - the Merchant who is making the refund 8742 - the Consumer who is requesting the refund 8743 - the PaymentHandlers for the payment. 8745 8.4.5 TPO Selection Block 8747 The TPO Selection Block (see section 7.2) is only used by Baseline 8748 Refund with Authentication. It contains: 8749 o one Brand Selection Component (see section 6.7) for use in the 8750 Payment Exchange. It contains the results of the consumer 8751 selecting a Payment Brand and Payment Protocol from the list 8752 provided in the Brand List Component. 8754 8.4.6 Authentication Request Block 8756 The Authentication Request Block (see section 7.4) must contain the 8757 following Trading Component: 8758 o one Authentication Data Component (see section 6.2) 8760 8.4.7 Authentication Response Block 8762 The Authentication Response Block (see section 7.5) must contain the 8763 following Trading Component: 8764 o one Authentication Response Component (see section 6.3). 8766 8.4.8 Offer Response Block 8768 The Offer Response Block (see section 7.3) must contain the following 8769 components: 8770 o zero or one Authentication Data Component (see section 6.2) An 8771 Authentication Data Component is required for each Payment 8772 Exchange, where its Payment Component contains an AuthDataRef 8773 attribute 8774 o one Order Component (see section 6.4) which contains details 8775 about the refund, for example the amount being refunded and 8776 any conditions which might apply 8777 o one Payment Component (see section 7.2) which contains 8778 information about the payment which is to be made 8779 o one Delivery Component (see section 6.12) with the DelivExch 8780 attribute set to False. 8782 The Offer Response Block may also contain one or more Trading Role 8783 Data Components (see section 6.16). 8785 8.4.9 Signature Block (Offer Response) 8787 If the Baseline Refund Offer Response is being digitally signed then a 8788 Signature Block must be included in the same IOTP message that 8789 contains an "Offer Response" Signature Component (see section 6.18). 8790 The Signature Component contains hashes of the following XML elements: 8791 o the Transaction Reference Block (see section 3.3) for the IOTP 8792 Message which contains the first usage of the Offer Response 8793 Block within the IOTP Transaction. It contains information 8794 that identifies the IOTP Message and IOTP Transaction 8795 o the Transaction Id Component (see section 3.3.1) which 8796 globally uniquely identifies the IOTP Transaction 8797 o the following components of the Offer Response Block: 8798 - the Authentication Data Component if present 8799 - the Order Component 8800 - the Payment Component 8801 - all the Organisation Components present, and 8802 - the Delivery Component, 8803 - any Trading Role Data Components 8805 o the following components of the TPO Block : 8806 - the Protocol Options Component, and 8807 - the Brand List Component 8809 If the Baseline Refund is a Baseline Refund with Authentication then 8810 the Signature Component additionally contains a hash of the following: 8811 o the Brand Selection Component contained in the TPO Selection 8812 Block. 8814 8.4.10 Payment Request Block 8816 The Payment Request Block (see section 7.6) contains: 8817 o the following components copied from the Offer Response Block: 8818 - the Status Component 8819 - the Authentication Data Component if present 8820 - the Payment Component 8821 - the Organisation Components with the roles of: Merchant and 8822 PaymentHandler 8823 o the following component from the TPO Block: 8824 - the Brand List Component 8825 o one Brand Selection Component either: 8826 - copied from the Offer Response Block if the refund is a Baseline 8827 Refund with Authentication, or 8828 - created by the Consumer, containing the payment brand and 8829 payment protocol selected, if the refund is a Baseline Refund 8830 with Authentication 8831 o one Payment Scheme Component (see section 6.9) if required by 8832 the payment method used (see the Payment Method supplement to 8833 determine if this is needed). 8835 The Payment Request Block may also contain one or more Trading Role 8836 Data Components (see section 6.16). 8838 Payment Handlers should check that they are authorised to carry out 8839 the Payment (see section 5 Security Considerations). 8841 8.4.11 Signature Block (Payment Request) 8843 If the Baseline Refund Offer Response Block was signed then the IOTP 8844 Message that contains the Payment Request Block must also contain a 8845 Signature Block with a copy of the "Offer Response" Signature 8846 Component. 8848 8.4.12 Payment Exchange Block 8850 The Payment Exchange Block (see section 7.7) contains: 8851 o one Payment Scheme Component (see section 6.9) which contains 8852 payment method specific data. See the Payment Method 8853 supplement for the payment method being used to determine what 8854 this should contain. 8856 8.4.13 Payment Response Block 8858 The Payment Response Block (see section 7.8) contains: 8859 o one Payment Receipt Component (see section 6.10) which 8860 contains scheme specific data which can be used to verify the 8861 payment occurred 8862 o one Payment Scheme Component (see section 6.9) if required 8863 which contains payment method specific data. See the Payment 8864 Method supplement for the payment method being used to 8865 determine what this should contain 8866 o the "Offer Response" Signature Component (see section 6.18) 8867 from the Payment Request Block if present 8869 The Payment Response Block may also contain: 8870 o a Payment Note Component (see section 6.11) 8871 o one or more Trading Role Data Components (see section 6.16). 8873 8.4.14 Signature Block (Payment Response) 8875 If a signed Payment Receipt is being provided, indicated by the 8876 SignedPayReceipt attribute of the Payment Component of the Offer 8877 Response Block being set to True, then the IOTP Message that contains 8878 the Payment Response Block must also contain a Signature Block with a 8879 "Payment Receipt" Signature Component which contains hashes of the 8880 following: 8881 o the Transaction Reference Block (see section 3.3) for the IOTP 8882 Message which contains the first usage of the Payment Response 8883 Block, 8884 o the Transaction Id Component (see section 3.3.1) within the 8885 Transaction Reference Block that globally uniquely identifies 8886 the IOTP Transaction, 8887 o the Payment Receipt Component from the Payment Response Block 8888 o the other Components referenced by the PayReceiptRefs 8889 attribute (if present) of the Payment Receipt Component, 8890 o the Status Component from the Payment Response Block, 8891 o any Trading Role Data Components in the Payment Response 8892 Block, and 8893 o the "Offer Response" Signature Component from the Payment 8894 Request Block if present. 8896 8.5 Baseline Withdrawal IOTP Transaction 8898 The Baseline Withdrawal IOTP Transaction supports the withdrawal of 8899 electronic cash from a Financial Institution. 8901 [Note] The Financial Institution has, in IOTP terminology, a role 8902 of merchant in that a service (i.e. a withdrawal of 8903 electronic cash) is being offered in return for a fee, for 8904 example bank charges of some kind. The term "Financial 8905 Institution" is used in the diagrams and in the text for 8906 clarity. 8907 [Note End] 8909 The Baseline Withdrawal IOTP Transaction consists of the following 8910 Trading Exchanges: 8911 o an optional Authentication Exchange (see section 2.2.4), 8912 o an Offer Exchange (see section 2.2.1), and 8913 o a Payment Exchange (see section 2.2.2). 8915 These Trading Exchanges are implemented by a set of predefined IOTP 8916 Messages (see section o) which are exchanged between the Trading Roles 8917 (see section 2.1). Each IOTP Message contains Trading Blocks (see 8918 section 7) which contain the Trading Components (see section 6) which 8919 are required by the Trading Exchanges. 8921 The Trading Blocks used by the Baseline Purchase IOTP Transaction are: 8922 o Trading Protocol Options Block 8923 o TPO Selection Block 8924 o Authentication Request Block 8925 o Authentication Response Block 8926 o Offer Response Block 8927 o Payment Request Block 8928 o Payment Exchange Block 8929 o Payment Response Block 8930 o Signature Block 8932 8.5.1 Baseline Withdrawal Variations 8934 The Baseline Withdrawal IOTP Transaction occurs in two basic forms: 8935 o Baseline Withdrawal with Authentication. Where the Consumer 8936 making the withdrawal is authenticated before the withdrawal 8937 is made, and 8938 o Baseline Withdrawal without Authentication. Where the Consumer 8939 is not authenticated before the withdrawal is made. 8941 In both these forms it is assumed that the Payment Brand being used is 8942 determined before the Baseline Withdrawal transaction starts. This 8943 means that Brand Selection is limited to Payment Protocol selection 8944 only. 8946 8.5.2 Baseline Withdrawal Authentication 8948 In Baseline Withdrawal with Authentication an Authentication Exchange 8949 occurs before the Offer Exchange containing the details of the 8950 withdrawal is provided by the Financial Institution. 8952 In Baseline Withdrawal without Authentication, there is no 8953 Authentication Exchange and the Financial Institution provides details 8954 about the withdrawal immediately at the start of the IOTP Transaction. 8956 These two alternatives are illustrated in the two diagrams below. The 8957 first diagram illustrates the case when an Authentication Exchange is 8958 included. 8960 CONSUMER OTP MESSAGE FINANCIAL 8961 INSTITUTION 8962 1. Consumer decides to 2. The Financial Institution 8963 withdraw electronic sets the payment brand and 8964 cash and sends --------------> decides the protocols to 8965 information about how Withdrawal offer, generates an 8966 much to withdraw to the Information Authentication Request Block 8967 Financial Institution, (outside scope containing challenge data 8968 e.g. using HTML of OTP) and the method of 8969 authentication and sends to 8970 the Consumer 8971 | 8972 v 8973 3. OTP aware application OTPMsg:Trans Ref 8974 started. The consumer selects <----------------- Block; TPO 8975 the payment protocol to use, TPO & Block; Auth. 8976 records selection in a Brand Authentication Response Block 8977 Selection Component, generates Request 8978 an Authentication Response 8979 Component and sends back to the 8980 Financial Institution. 8981 | 8982 v 8983 OTPMsg: 4. The Financial Institution checks 8984 Trans Ref ---------------> the Authentication Response against 8985 Block; Auth TPO Selection & the challenge data in the 8986 Response Authentication Authentication Request Block, uses the 8987 Block; TPO Response information to identify the consumer, 8988 Selection generates an Offer Response Block 8989 containing information about the 8990 withdrawal, an optional signature and 8991 sends to the Consumer 8992 | 8993 v 8994 5. Consumer checks Offer is OK, OTPMsg: Trans 8995 combines components from the Ref Block; 8996 TPO Block, the TPO Selection <------------------ Signature Block; 8997 Block and the Offer Response Offer Response Offer Response 8998 Block to create a Pay Request Block 8999 Block and sends to the Payment 9000 Handler together with optional 9001 Signature Block 9002 | 9003 v Note that the Financial Institution 9004 CONTINUED has, in OTP terminology, a role of 9005 "Merchant". 9007 Figure 32 Baseline Withdrawal with Authentication 9008 Note that the above diagram: 9009 o describes the general case where a Financial Institution can 9010 offer withdrawal of several different types of electronic 9011 cash. In practice usually only one form of electronic cash may 9012 be offered. However, there may be several different protocols 9013 which may be used for the same "brand" of electronic cash 9014 o the financial institution may use the results of the 9015 authentication to identify not only the consumer but also the 9016 account from which the withdrawal is to be made. If no single 9017 account can be identified, then it must be obtained by other 9018 means. For example: 9019 - the consumer could specify the account number in the initial 9020 dialogue (see step 1), or 9021 - the consumer could have been identified earlier, for example 9022 using a Baseline Authentication IOTP Transaction, and an account 9023 selected from a list provided by the Financial Institution. 9025 The second diagram illustrates the case when an Authentication 9026 Exchange is not included. 9028 CONSUMER OTP MESSAGE FINANCIAL 9029 INSTITUTION 9030 1. Consumer decides to 2. Financial Institution 9031 withdraw electronic decides sets the payment 9032 cash and sends ------------> brand and decides which 9033 information about how Withdrawal protocols to offer for 9034 much to withdraw, etc. Information withdrawal, generates an 9035 to the Financial (outside Offer Response Block 9036 Institution, e.g. using scope of OTP) containing information about 9037 HTML the withdrawal, an optional 9038 signature and sends to the 9039 Consumer 9040 | 9041 v 9042 3. OTP aware application started. OTPMsg: Trans 9043 Consumer selects the payment protocol <-------------- Ref Block; 9044 to use, records selection in a Brand TPO & Signature 9045 Selection Component, checks Offer is Offer Response Block; TPO 9046 OK, combines the Brand Selection Block; Offer 9047 Component with information from the Response 9048 TPO Block and Offer Response Block to Block 9049 create a Pay Request Block and sends 9050 it to the Payment Handler together 9051 with optional Signature Block 9052 | 9053 v Note that the Financial 9054 CONTINUED Institution has, in OTP 9055 terminology, a role of 9056 "Merchant". 9058 Figure 33 Baseline Withdrawal without Authentication 9059 The Baseline Withdrawal without Authentication might be used: 9060 o when a previous IOTP transaction, for example a Baseline 9061 Deposit or a Baseline Authentication, authenticated the 9062 consumer, and a secure channel has been maintained, therefore 9063 the authenticity of the consumer is known 9064 o when authentication is achieved as part of a proprietary 9065 payment protocol and is therefore included in the Payment 9066 Exchange 9067 o when authentication of the consumer has been achieved by some 9068 other means, for example, by using a pass phrase, or a 9069 proprietary banking software solution. 9071 IOTP aware applications supporting the Consumer Trading Role must 9072 check for the existence of an Authentication Request Block in the 9073 first IOTP Message to determine whether the Baseline Withdrawal 9074 includes an Authentication Exchange or not. 9076 8.5.3 Baseline Withdrawal Payment Messages 9078 Once the Offer Response Trading Block has been received, the sequence 9079 of IOTP Messages illustrated in Figure 34 occurs. These are the same 9080 whether or not an Authentication of the Consumer has occurred. Note 9081 that these continue where the previous diagrams (Figure 32 and Figure 9082 33) finish. 9084 CONSUMER OTP MESSAGE PAYMENT HANDLER 9085 3/5. Consumer generates Pay 9086 Request Block encapsulating a 9087 payment protocol message if 9088 required and sends to Payment 9089 Handler together with optional 9090 Signature Block 9091 | 9092 v 9093 OtpMsg: Trans 6. Payment Handler checks 9094 Ref Block; ---------------> optional signature, processes Pay 9095 Signature Block; Payment Request Request Block, and starts 9096 Pay Request exchanging payment protocol 9097 Block messages, encapsulated in a Pay 9098 Exchange Block, with the Consumer 9099 | 9100 v 9101 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 9102 on exchanging Pay Trans Ref <----------------->Ref Block; Pay 9103 Exchange Blocks with Block; Pay Payment Exchange Exchange Block 9104 Payment Handler Exchange Block 9105 | 9106 v 9107 8. Eventually payment protocol 9108 messages finish so Payment 9109 Handler creates Pay Receipt 9110 Component inside a Pay Response 9111 Block, an optional signature, 9112 sends to Consumer and stops 9113 | 9114 v 9115 9. Consumer checks Pay OtpMsg: Trans Ref Block; 9116 Response is OK. Optionally <------------ Signature Block 9117 keeps information on OTP Payment Pay Response Block 9118 Transaction for record Response | 9119 keeping purposes and stops v 9120 | STOP 9121 v 9122 STOP 9124 Figure 34 Baseline Withdrawal Payment Messages 9126 The remainder of this sub-section on the Baseline Withdrawal IOTP 9127 Transaction defines the contents of each Trading Block. For most 9128 Trading Blocks, the content does not alter with the variations 9129 described above. Where differences apply, these are stated. 9131 8.5.4 TPO (Trading Protocol Options) Block 9133 The TPO (Trading Protocol Options) Block (see section 8.3.2) must 9134 contain the following Trading Components: 9135 o one Protocol Options Component which defines the options which 9136 apply to the whole IOTP Transaction. See Section 6.1. 9137 o one Brand List Component (see section 6.6) which contains the 9138 payment brand and protocols which may be selected for use in 9139 the Payment Exchange 9140 o Organisation Components (see section 6.5) with the following 9141 roles: 9142 - the Merchant who is accepting the withdrawal 9143 - the Consumer who is making the withdrawal 9144 - the PaymentHandler for the payment. 9146 8.5.5 TPO Selection Block 9148 The TPO Selection Block (see section 7.2) is only used by Baseline 9149 Withdrawal with Authentication. It contains: 9150 o one Brand Selection Component (see section 6.7) for use in the 9151 Payment Exchange. It contains the results of the consumer 9152 selecting a Payment Brand and Payment Protocol from the list 9153 provided in the Brand List Component. 9155 8.5.6 Authentication Request Block 9157 The Authentication Request Block (see section 7.4) must contain the 9158 following Trading Component: 9159 o one Authentication Data Component (see section 6.2) 9161 8.5.7 Authentication Response Block 9163 The Authentication Response Block (see section 7.5) must contain the 9164 following Trading Component: 9165 o one Authentication Response Component (see section 6.3). 9167 8.5.8 Offer Response Block 9169 The Offer Response Block (see section 7.3) must contain the following 9170 components: 9171 o zero or one Authentication Data Components (see section 6.2) 9172 An Authentication Data Component is required for each Payment 9173 Exchange, where its Payment Component contains an AuthDataRef 9174 attribute 9175 o one Order Component (see section 6.4) which contains details 9176 about the withdrawal, for example the amount being withdrawn 9177 and any fees which might apply 9178 o one Payment Component (see section 7.2) which contains 9179 information about the payment which is to be made 9180 o one Delivery Component (see section 6.12) with the DelivExch 9181 attribute set to False. 9183 The Offer Response Block may also contain one or more Trading Role 9184 Data Components (see section 6.16). 9186 [Note] In the above an Organisation with a role of Merchant is used 9187 in that a service (i.e. a withdrawal of electronic cash) is 9188 being offered in return for a fee, for example bank charges 9189 of some kind. The term "Financial Institution" is used in 9190 the diagrams and in the text for clarity. 9191 [Note End] 9193 8.5.9 Signature Block (Offer Response) 9195 If the Baseline Withdrawal Offer Response is being digitally signed 9196 then a Signature Block must be included in the same IOTP message that 9197 contains an "Offer Response" Signature Component (see section 6.18). 9198 The Signature Component contains hashes of the following XML elements: 9199 o the Transaction Reference Block (see section 3.3) for the IOTP 9200 Message which contains the first usage of the Offer Response 9201 Block within the IOTP Transaction. It contains information 9202 that identifies the IOTP Message and IOTP Transaction 9203 o the Transaction Id Component (see section 3.3.1) which 9204 globally uniquely identifies the IOTP Transaction 9205 o the following components of the Offer Response Block: 9206 - the Authentication Data Component if present 9207 - the Order Component 9208 - the Payment Component 9209 - all the Organisation Components present 9210 - the Delivery Component, 9211 - any Trading Role Data Components 9213 o the following components of the TPO Block : 9214 - the Protocol Options Component, and 9215 - the Brand List Component 9217 If the Baseline Withdrawal is a Baseline Withdrawal with 9218 Authentication then the Signature Component additionally contains a 9219 hash of the following: 9220 o the Brand Selection Component contained in the TPO Selection 9221 Block. 9223 8.5.10 Payment Request Block 9225 The Payment Request Block (see section 7.6) contains: 9226 o the following components copied from the Offer Response Block: 9227 - the Status Component 9228 - the Authentication Data Component if present 9229 - the Payment Component 9230 - the Organisation Components with the roles of: Merchant and 9231 PaymentHandler 9232 o the following component from the TPO Block: 9233 - the Brand List Component 9234 o one Brand Selection Component either: 9235 - copied from the Offer Response Block if the withdrawal is a 9236 Baseline Withdrawal with Authentication, or 9237 - created by the Consumer, containing the payment brand and 9238 payment protocol selected, if the withdrawal is a Baseline 9239 Withdrawal without Authentication 9240 o one Payment Scheme Component (see section 6.9) if required by 9241 the payment method used (see the Payment Method supplement to 9242 determine if this is needed). 9244 The Payment Request Block may also contain one or more Trading Role 9245 Data Components (see section 6.16). 9247 Payment Handlers should check that they are authorised to carry out 9248 the Payment (see section 5 Security Considerations). 9250 8.5.11 Signature Block (Payment Request) 9252 If the Baseline Withdrawal Offer Response Block was signed then the 9253 IOTP Message that contains the Payment Request Block must also contain 9254 a Signature Block with a copy of the "Offer Response" Signature 9255 Component. 9257 8.5.12 Payment Exchange Block 9259 The Payment Exchange Block (see section 7.7) contains: 9260 o one Payment Scheme Component (see section 6.9) which contains 9261 payment method specific data. See the Payment Method 9262 supplement for the payment method being used to determine what 9263 this should contain. 9265 8.5.13 Payment Response Block 9267 The Payment Response Block (see section 7.8) contains: 9268 o one Payment Receipt Component (see section 6.10) which 9269 contains scheme specific data which can be used to verify the 9270 payment occurred 9271 o one Payment Scheme Component (see section 6.9) if required 9272 which contains payment method specific data. See the Payment 9273 Method supplement for the payment method being used to 9274 determine what this should contain 9275 o the "Offer Response" Signature Component (see section 6.18) 9276 from the Payment Request Block if present 9278 The Offer Response Block may also contain: 9279 o a Payment Note Component (see section 6.11) 9280 o one or more Trading Role Data Components (see section 6.16). 9282 8.5.14 Signature Block (Payment Response) 9284 If a signed Payment Receipt is being provided, indicated by the 9285 SignedPayReceipt attribute of the Payment Component of the Offer 9286 Response Block being set to True, then the IOTP Message that contains 9287 the Payment Response Block must also contain a Signature Block with a 9288 "Payment Receipt" Signature Component which contains hashes of the 9289 following: 9290 o the Transaction Reference Block (see section 3.3) for the IOTP 9291 Message which contains the first usage of the Payment Response 9292 Block, 9293 o the Transaction Id Component (see section 3.3.1) within the 9294 Transaction Reference Block that globally uniquely identifies 9295 the IOTP Transaction, 9296 o the Payment Receipt Component from the Payment Response Block 9297 o the other Components referenced by the PayReceiptRefs 9298 attribute (if present) of the Payment Receipt Component, 9299 o the Status Component from the Payment Response Block, 9300 o any Trading Role Data Components in the Payment Response 9301 Block, and 9302 o the "Offer Response" Signature Component from the Payment 9303 Request Block if present. 9305 8.6 Baseline Value Exchange IOTP Transaction 9307 The Baseline Value Exchange Transaction uses Payment Exchanges (see 9308 section 2.2.2) to support the exchange of value in one currency 9309 obtained using one payment method with value in the same or another 9310 currency using the same or another payment method. Examples of its use 9311 include: 9312 o electronic cash advance on a credit card. For example the 9313 first payment could be a dollar SET Payment Exchange on a 9314 credit card with the second Payment Exchange being a download 9315 of DigiCash e-cash in dollars. 9316 o foreign exchange using the same payment method. For example 9317 the payment could be an upload of Mondex value in French 9318 Francs and the second a download of Mondex value in British 9319 Pounds 9320 o foreign exchange using different payment methods. For example 9321 the first payment could be a SET payment in Euros followed a 9322 download of GeldKarte in Deutchmarks. 9324 The Baseline Value Exchange uses three Trading Exchanges: 9325 o an Offer Exchange (see section 2.2.1) which provides details 9326 of what values and currencies will be exchanged, and 9327 o two Payment Exchanges (see section 2.2.2) which carry out the 9328 two payments involved 9330 These Trading Exchanges are implemented by a set of predefined IOTP 9331 Messages (see section o) which are exchanged between the Trading Roles 9332 (see section 2.1). Each IOTP Message contains Trading Blocks (see 9333 section 7) which contain the Trading Components (see section 6) which 9334 are required by the Trading Exchanges. 9336 The Trading Blocks used by the Baseline Value Exchange IOTP 9337 Transaction are: 9338 o Trading Protocol Options Block 9339 o TPO Selection Block 9340 o Offer Response Block 9341 o Payment Request Block 9342 o Payment Exchange Block 9343 o Payment Response Block 9344 o Signature Block 9346 8.6.1 Baseline Value Exchange Variations 9348 The Baseline Value Exchange IOTP Transaction occurs in two basic 9349 forms: 9350 o Brand Dependent Value Exchange. Where the content of the 9351 offer, for example the rate at which one form of value is 9352 exchanged for another, is dependent on the payment brands and 9353 protocols selected by the consumer, and 9354 o Brand Independent Value Exchange. Where the content of the 9355 offer is not dependent on the payment brands and protocols 9356 selected. 9358 In Brand Dependent Value Exchange the TPO Block and the Offer Response 9359 Block are sent separately by the Merchant to the Consumer, i.e.: 9360 o the Brand List Components for the two payments are sent to the 9361 Consumer in a TPO Block, 9363 o the Consumer selects a Payment Brand and Payment Protocol from 9364 the Brand List Component for each of the payments in the Value 9365 Exchange 9366 o the Consumer sends the selected brands and protocols back to 9367 the Merchant in a TPO Selection Block, and 9368 o the Merchant Uses the information received to define the 9369 content of the Offer Response Block and then sends it to the 9370 Consumer. 9372 [Note] In the above the role is a Merchant even though the 9373 organisation carrying out the Value Exchange may be a Bank 9374 or some other Financial Institution. This is because the 9375 Bank is acting as a merchant in that they are making an 9376 offer which the Consumer can either accept or decline. 9377 [Note End] 9379 In Brand Independent Value Exchange the TPO Block and the Offer 9380 Response Block are sent together by the Merchant to the Consumer in 9381 the same IOTP Message at the start of the IOTP Transaction. 9383 These two alternatives are illustrated in the two diagrams below. The 9384 first diagram illustrates a Brand Dependent Value Exchange. 9386 CONSUMER OTP MESSAGE MERCHANT 9387 1. Consumer decides to 2. Merchant decides which 9388 conduct a Value Exchange --------------> payment brand and protocols 9389 and sends information Value Exchange to offer for each payment, 9390 about the exchange to Information places them in Brand List 9391 the Merchant, e.g. using (outside scope Components in a TPO Block, 9392 HTML of OTP) and sends to Consumer 9393 | 9394 v 9395 3. OTP aware application started. OTPMsg: Trans 9396 Consumer selects the payment brand <--------------- Ref Block; TPO 9397 and payment protocol to use for TPO Block 9398 each payment, records selections 9399 in two Brand Selection Components, 9400 and sends back to Merchant 9401 | 9402 v 9403 OTPMsg:Trans 4. Merchant uses payment brands and 9404 Ref Block; TPO protocols selected to create an Offer 9405 Selection -------------> Response Block containing details 9406 Block TPO Selection about the Value Exchange, e.g. 9407 exchange rates, commission, etc. and 9408 sends to Consumer together with 9409 optional signature 9410 | 9411 v 9412 5. Consumer checks Offer is OK, OTPMsg:Trans 9413 combines components from the TPO <---------------- Ref Block; 9414 Block, the TPO Selection Block Offer Response Signature 9415 and the Offer Response Block to Block; Offer 9416 create a Pay Request Block for Response Block 9417 the first payment and sends it to 9418 Payment Handler 1 together with 9419 the optional signature 9420 | 9421 v 9422 CONTINUED 9424 Figure 35 Brand Dependent Value Exchange 9426 The second diagram illustrates the a Brand Independent Value Exchange. 9428 CONSUMER OTP MESSAGE MERCHANT 9429 1. Consumer 2. Merchant decides which payment 9430 decides to brand and protocols to offer for each 9431 conduct a Value -----------> payment, places them in Brand List 9432 Exchange and Value Components in a TPO Block, creates an 9433 sends information Exchange Offer Response Block containing 9434 about the Information details about the Value Exchange, 9435 exchange to the (outside e.g. exchange rates, commission, etc. 9436 Merchant, e.g. scope of and sends to Consumer together with 9437 using HTML OTP) optional Signature Block 9438 | 9439 v 9440 3. OTP aware application started. OTPMsg:Trans 9441 Consumer selects the payment brand and <------------- Ref Block; 9442 payment protocol to use for each TPO & Signature 9443 payment, records selections in two Brand Offer Response Block; TPO 9444 Selection Components, checks Offer is Block; Offer 9445 OK, combines the Brand Selection Response 9446 Component for the first payment with Block 9447 information from the TPO Block and Offer 9448 Response Block to create a Pay Request 9449 Block for the first payment and sends it 9450 to Payment Handler 1 with the optional 9451 Signature Block 9452 | 9453 v 9454 CONTINUED 9456 Figure 36 Brand Independent Value Exchange 9458 The TPO Block and Offer Response Block may only be combined into the 9459 same IOTP Message if the content of the Offer Response Block does not 9460 change as a result of selecting the payment brands and payment 9461 protocols to be used in the Value Exchange. 9463 Note that the TPO Block and the Offer Response Block may be sent in 9464 separate IOTP messages even if the Offer Response Block does not 9465 change. However this increases the number of messages in the 9466 transaction and is therefore likely to increase transaction response 9467 times. 9469 IOTP aware applications supporting the Consumer Trading Role must 9470 check for the existence of an Offer Response Block in the first IOTP 9471 Message to determine whether the Baseline Value Exchange is brand 9472 dependent. 9474 Whether or not the Value Exchange is brand dependent, the exchange of 9475 Trading Blocks between the Consumer and the Payment Handlers are the 9476 same. This is illustrated in the diagram below. Note that this diagram 9477 continues where the previous diagrams (Figure 35 and Figure 36) 9478 finish. 9480 CONSUMER OTP MESSAGE PAYMENT HANDLER 1 9481 3/5. Consumer generates Pay 9482 Request Block encapsulating a 9483 payment protocol message if 9484 required and sends to Payment 9485 Handler 1 with optional 9486 Signature Block 9487 | 9488 v 9489 OtpMsg: Trans 6. Payment Handler 1 processes checks 9490 Ref Block; -----------> signature, Pay Request Block for the 9491 Signature Payment first payment, and starts exchanging 9492 Block; Pay Request 1 payment protocol messages , 9493 Request Block 1 encapsulated in a Pay Exchange Block, 9494 with the Consumer 9495 | 9496 v 9497 7. Consumer keeps<- ----->OtpMsg: OtpMsg: Trans 9498 on exchanging Pay Trans Ref <----------------->Ref Block; Pay 9499 Exchange Blocks with Block; Pay Payment Exchange 1 Exchange Block 9500 Payment Handler 1 Exchange Block 9501 | 9502 v 9503 8. Eventually payment protocol 9504 messages finish so Payment 9505 Handler 1 creates Pay Receipt 9506 Component and optional Signature 9507 Component inside a Pay Response 9508 Block for first payment, sends 9509 to Consumer with optional 9510 Signature Block and stops 9511 | 9512 v 9513 9. Consumer checks Pay OtpMsg: Trans Ref 9514 Response for first payment is <----------------- Block; Signature 9515 OK, and creates Pay Request Payment Response 1 Block; Pay 9516 for second payment using Response Block 1 9517 Offer Response Block and | 9518 optionally the signatures and v 9519 sends to Payment Handler 2 STOP 9520 | ==================================================== 9521 v PAYMENT HANDLER 2 9522 OtpMsg: Trans 10. Payment Handler 2 checks signature, 9523 Ref Block; -------> processes Pay Request Block for the second 9524 Signature Block Payment payment, and starts exchanging payment 9525 Pay Request Request protocol messages , encapsulated in a Pay 9526 Block (2) 2 Exchange Block, with the Consumer 9527 | 9528 v 9529 11. Consumer keeps<------>OtpMsg: OtpMsg: Trans 9530 on exchanging Pay Trans Ref <----------------->Ref Block; Pay 9531 Exchange Blocks with Block; Pay Payment Exchange 2 Exchange Block 9532 Payment Handler 2 Exchange Block | 9533 | 9534 12. Eventually payment protocol 9535 messages finish so Payment 9536 Handler 2 creates Pay Receipt 9537 Component and inside a Pay 9538 Response Block for second 9539 payment, sends to Consumer with 9540 optional signature and stops 9541 | 9542 v 9543 13. Consumer checks Payment OtpMsg: Trans Ref 9544 Response Block for second <------------- Block; Signature Block 9545 payment is OK, optionally Payment Pay Response Block 2 9546 keeps information on OTP Response 2 | 9547 Transaction for record keeping v 9548 purposes and stops STOP 9549 | 9550 v 9551 STOP 9553 Figure 37 Baseline Value Exchange Payment Messages 9555 The remainder of this sub-section on the Baseline Value Exchange IOTP 9556 Transaction defines the contents of each Trading Block. The content 9557 does not alter with the variations described above. 9559 8.6.2 PO (Trading Protocol Options) Block 9561 The TPO (Trading Protocol Options) Block (see section 8.3.2) must 9562 contain the following Trading Components: 9563 o one Protocol Options Component which defines the options which 9564 apply to the whole IOTP Transaction. See Section 6.1. 9565 o two Brand List Components (see section 6.6) one for each 9566 Payment Exchange where each Brand List Component contains one 9567 or more payment brands and protocols which may be selected for 9568 use in the Payment Exchange 9570 o Organisation Components (see section 6.5) with the following 9571 roles: 9572 - Merchant who is providing the goods or services 9573 - Consumer who is making the purchase 9574 - the PaymentHandlers for the payments. 9576 8.6.3 TPO Selection Block 9578 The TPO Selection Block (see section 7.2) is only used by Brand 9579 Dependent Value Exchange. It contains: 9580 o two Brand Selection Components (see section 6.7). One for each 9581 of the Payment Exchanges. Each Brand Selection Component 9582 contains the results of the consumer selecting a Payment Brand 9583 and Payment Protocol from the list provided in the Brand List 9584 Component. 9586 8.6.4 Offer Response Block 9588 The Offer Response Block (see section 7.3) contains the following 9589 components: 9590 o zero, one or two Authentication Data Component (see section 9591 6.2). An Authentication Data Component is required for each 9592 Payment Exchange, where its Payment Component contains an 9593 AuthDataRef attribute. 9594 o one Order Component (see section 6.4) which contains details 9595 about the Value Exchange, for example, exchange rates, 9596 commission, etc. 9597 o two Payment Components (see section 6.8) which contain 9598 information about each of the two payments which are to be 9599 made 9601 The Offer Response Block may also contain one or more Trading Role 9602 Data Components (see section 6.16). 9604 8.6.5 Signature Block (Offer Response) 9606 If the Baseline Value Exchange Offer Response is being digitally 9607 signed then a Signature Block must be included in the same IOTP 9608 message that contains an "Offer Response" Signature Component (see 9609 section 6.18). The Signature Component contains hashes of the 9610 following XML elements: 9611 o the Transaction Reference Block (see section 3.3) for the IOTP 9612 Message which contains the first usage of the Offer Response 9613 Block within the IOTP Transaction. It contains information 9614 that identifies the IOTP Message and IOTP Transaction 9615 o the Transaction Id Component (see section 3.3.1) which 9616 globally uniquely identifies the IOTP Transaction 9617 o the following components of the Offer Response Block: 9618 - the Authentication Data Component if present 9619 - the Order Component 9620 - the two Payment Components 9621 - all the Organisation Components present, and 9622 - any Trading Role Data Components 9623 o the following components of the TPO Block : 9624 - the Protocol Options Component, and 9625 - the Brand List Component 9627 If the Baseline Value Exchange is a Brand Dependent Value Exchange 9628 then the Signature Component additionally contains a hash of the 9629 following: 9630 o the two Brand Selection Components contained in the TPO 9631 Selection Block. 9633 8.6.6 Payment Request Block (first payment) 9635 The Payment Request Block (see section 7.6) for the first payment 9636 contains: 9637 o the following components copied from the Offer Response Block: 9638 - the Status Component 9639 - the Authentication Data Component for the first payment if 9640 required 9641 - the Payment Component for the first payment 9642 - the Organisation Components with the roles of: Merchant and 9643 PaymentHandler for the first payment 9644 o the following component copied from the TPO Block: 9645 - the Brand List Component for the first payment 9646 o one Brand Selection Component for the first payment which is 9647 either: 9648 - copied from the Offer Response Block if the purchase is a Brand 9649 Dependent Value Exchange, or 9650 - created by the Consumer, containing the payment brand and 9651 payment protocol selected, if the purchase is a Brand 9652 Independent Value Exchange 9653 o one Payment Scheme Component (see section 6.9) if required by 9654 the payment method used (see the Payment Method supplement to 9655 determine if this is needed). 9657 The Payment Request Block may also contain one or more Trading Role 9658 Data Components (see section 6.16). 9660 Note that: 9661 o the Payment Component for the first payment is the one within 9662 the Offer Response Block that contains no StartAfter attribute 9663 (see section 6.8) 9664 o the Authentication Data Component to include is identified by 9665 the AuthDataRef attribute of the Payment Component for the 9666 first payment. If no AuthDataRef attribute is present then no 9667 Authentication Data Component is required 9668 o the Payment Handler to include is identified by the Brand 9669 Selection Component (see section 6.7) for the first payment. 9670 Also see section 5.3.1 Check the Action Request was sent to 9671 the Correct Organisation for an explanation on how Payment 9672 Handlers are identified 9673 o the Brand List Component to include is the one identified by 9674 the BrandListRef attribute of the Payment Component for the 9675 first payment 9676 o the Brand Selection Component to include from the Offer 9677 Response Block is the one that contains an Element Reference 9678 (see section 3.5) which identifies the Brand List Component 9679 for the first payment 9681 8.6.7 Signature Block (Payment Request - first payment) 9683 If the Baseline Value Exchange Offer Response Block was signed then 9684 the IOTP Message that contains the Payment Request Block for the first 9685 payment must also contain a Signature Block with a copy of the "Offer 9686 Response" Signature Component. 9688 8.6.8 Payment Exchange Block (first payment) 9690 The Payment Exchange Block (see section 7.7) for the first payment 9691 contains: 9692 o one Payment Scheme Component (see section 6.9) which contains 9693 payment method specific data for the payment method being used 9694 by the first payment. See the Payment Method supplement for 9695 the payment method being used to determine what this should 9696 contain. 9698 8.6.9 Payment Response Block (first payment) 9700 The Payment Response Block for the first payment (see section 7.8) 9701 contains: 9702 o one Payment Receipt Component (see section 6.10) which 9703 contains scheme specific data which can be used to verify the 9704 first payment occurred 9705 o one Payment Scheme Component (see section 6.9) if required by 9706 the payment method used by the first payment which contains 9707 payment method specific data. See the Payment Method 9708 supplement for the payment method being used to determine what 9709 this should contain 9710 o the Signature Component (see section 6.18) from the Payment 9711 Request Block for the first payment if present. 9713 The Payment Response Block may also contain: 9714 o a Payment Note Component (see section 6.11) 9715 o one or more Trading Role Data Components (see section 6.16). 9717 8.6.10 Signature Block (Payment Response - first payment) 9719 If a signed Payment Receipt is being provided for the first payment, 9720 indicated by the SignedPayReceipt attribute of the Payment Component 9721 for the first payment in the Offer Response Block being set to True, 9722 then the IOTP Message that contains the Payment Response Block for the 9723 first payment must also contain a Signature Block with a "Payment 9724 Receipt" Signature Component which contains hashes of the following: 9725 o the Transaction Reference Block (see section 3.3) for the IOTP 9726 Message which contains the first usage of the Payment Response 9727 Block for the first payment, 9728 o the Transaction Id Component (see section 3.3.1) within the 9729 Transaction Reference Block that globally uniquely identifies 9730 the IOTP Transaction, 9731 o the Payment Receipt Component from the Payment Response Block 9732 for the first payment 9733 o the other Components referenced by the PayReceiptRefs 9734 attribute (if present) of the Payment Receipt Component for 9735 the first payment, 9736 o the Status Component from the Payment Response Block for the 9737 first payment, 9738 o any Trading Role Data Components in the Payment Response 9739 Block, and 9740 o the "Offer Response" Signature Component from the Payment 9741 Request Block for the first payment, if present. 9743 8.6.11 Payment Request Block (second payment) 9745 The Payment Request Block (see section 7.6) for the second payment 9746 contains: 9747 o the following components copied from the Offer Response Block: 9748 - the Status Component 9749 - the Authentication Data Component for the second payment if 9750 required 9751 - the Payment Component for the second payment 9752 - the Organisation Components with the roles of: Merchant and 9753 PaymentHandler for the second payment 9754 o the following component copied from the TPO Block: 9755 - the Brand List Component for the second payment 9756 o one Brand Selection Component for the second payment which is 9757 either: 9758 - copied from the Offer Response Block if the purchase is a Brand 9759 Dependent Value Exchange, or 9760 - created by the Consumer, containing the payment brand and 9761 payment protocol selected, if the purchase is a Brand 9762 Independent Value Exchange 9763 o one Payment Scheme Component (see section 6.9) if required by 9764 the payment method used (see the Payment Method supplement to 9765 determine if this is needed) 9766 o the following components copied from the Payment Response 9767 Block for the first payment: 9768 - the Status Component 9770 The Payment Request Block may also contain one or more Trading Role 9771 Data Components (see section 6.16). 9773 Note that: 9774 o the Payment Component for the second payment is the one 9775 within the Offer Response Block that contains a StartAfter 9776 attribute (see section 6.8) that identifies the Payment 9777 Component for the first payment 9778 o the Authentication Data Component to include is identified by 9779 the AuthDataRef attribute of the Payment Component for the 9780 second payment. If no AuthDataRef attribute is present then no 9781 Authentication Data Component is required 9782 o the Payment Handler to include is identified by the Brand 9783 Selection Component (see section 6.7) for the second payment. 9784 Also see section 5.3.1 Check the Action Request was sent to 9785 the Correct Organisation for an explanation on how Payment 9786 Handlers are identified 9787 o the Brand List Component to include is the one identified by 9788 the BrandListRef attribute of the Payment Component for the 9789 second payment 9790 o the Brand Selection Component to include from the Offer 9791 Response Block is the one that contains an Element Reference 9792 (see section 3.5) which identifies the Brand List Component 9793 for the second payment 9795 8.6.12 Signature Block (Payment Request - second payment) 9797 If the Baseline Value Exchange Offer Response Block or the Payment 9798 Response Block for the first payment was signed then the IOTP Message 9799 that contains the Payment Request Block for the second payment must 9800 also contain a Signature Block with a copy of: 9801 o the "Offer Response" Signature Component, if present, and/or 9802 o the "Payment Receipt" Signature Component copied from the 9803 Payment Response Block for the first payment, if present. 9805 8.6.13 Payment Exchange Block (second payment) 9807 The Payment Exchange Block (see section 7.7) for the second payment 9808 contains: 9809 o one Payment Scheme Component (see section 6.9) which contains 9810 payment method specific data for the payment method being used 9811 by the second payment. See the Payment Method supplement for 9812 the payment method being used to determine what this should 9813 contain. 9815 8.6.14 Payment Response Block (second payment) 9817 The Payment Response Block for the second payment (see section 7.8) 9818 contains: 9820 o one Payment Receipt Component (see section 6.10) which 9821 contains scheme specific data which can be used to verify the 9822 second payment occurred 9823 o one Payment Scheme Component (see section 6.9) if required by 9824 the payment method used by the second payment which contains 9825 payment method specific data. See the Payment Method 9826 supplement for the payment method being used to determine what 9827 this should contain 9828 o all the Signature Components (see section 6.18) from the 9829 Payment Request Block for the second payment if present 9831 The Payment Response Block may also contain: 9832 o a Payment Note Component (see section 6.11) 9833 o one or more Trading Role Data Components (see section 6.16). 9835 8.6.15 Signature Block (Payment Response - second payment) 9837 If a signed Payment Receipt is being provided for the second payment, 9838 indicated by the SignedPayReceipt attribute of the Payment Component 9839 for the second payment in the Offer Response Block being set to True, 9840 then the IOTP Message that contains the Payment Response Block for the 9841 second payment must also contain a Signature Block with a "Payment 9842 Receipt" Signature Component which contains hashes of the following: 9843 o the Transaction Reference Block (see section 3.3) for the IOTP 9844 Message which contains the first usage of the Payment Response 9845 Block for the second payment, 9846 o the Transaction Id Component (see section 3.3.1) within the 9847 Transaction Reference Block that globally uniquely identifies 9848 the IOTP Transaction, 9849 o the Payment Receipt Component from the Payment Response Block 9850 for the second payment 9851 o the Status Component from the Payment Response Block for the 9852 second payment, and 9853 o the other Components referenced by the PayReceiptRefs 9854 attribute (if present) of the Payment Receipt Component for 9855 the second payment, 9856 o any Trading Role Data Components in the Payment Response Block 9857 o the "Offer Response" Signature Component from the Payment 9858 Request Block for the second payment, if present, and 9859 o the "Payment Receipt" Signature Component from the Payment 9860 Request Block for the first payment, if present. 9862 8.6.16 Baseline Value Exchange Signatures 9864 The use of signatures to ensure the integrity of a Baseline Value 9865 Exchange is illustrated by the diagram below. 9867 Signature generated OtpMsg (TPO) 9868 by Merchant ensures - Trans Ref Block 9869 integrity of the Offer --------> - - Signature Block 9870 | - TPO Block MERCHANT 9871 | - Offer Response Block 9872 | 9873 Signature generated by | 9874 the Payment Handler of | OtpMsg (Pay Resp 1) 9875 the first payment binds | - Trans Ref Block PAYMENT 9876 Pay Receipt for the first -----> -> - Signature Block ----- HANDLER 9877 payment to the Offer - Pay Response Block 1 | 1 9878 | 9879 Signature generated by | 9880 the Payment Handler of OtpMsg (Pay Resp 2) | PAYMENT 9881 the second payment binds - Trans Ref Block | HANDLER 9882 the second payment to the -----> - Signature Block <------ 2 9883 first payment and therefore - Pay Response Block 2 9884 to the Offer 9886 Figure 38 Baseline Value Exchange Signatures 9888 If signatures are used then the Payment Handlers should check that all 9889 Signature Components they receive are valid (see section 5 Security 9890 Considerations). 9892 8.7 Payment Instrument Customer Care IOTP Transaction 9894 An IOTP Payment Instrument Customer Care Transaction is used to 9895 provide Payment Brand or Payment Method specific customer care. It 9896 allows Consumer Payment Brand software to exchange information with a 9897 Payment Instrument Customer Care Provider. 9899 The circumstances under which this transaction is used, if any, is 9900 defined in the IOTP Supplement for the Payment Brand. 9902 Note that the IOTP Payment Instrument Customer Care Transaction: 9903 o is initiated by the Consumer Payment Brand software which must 9904 identify the need for the transaction to occur. Note that in 9905 other IOTP Transactions, the transaction is initiated by the 9906 Merchant 9907 o has no TPO Block, as it is initiated by the Consumer 9908 o relies on the Consumer Payment Brand software to identify the 9909 net location of the Payment Instrument Customer Care Provider 9910 to which the first message in the transaction must be sent 9911 o ends when the Payment Scheme Customer Care Service determines 9912 that the exchange of messages with the Consumer is to stop. 9914 Note that a Payment Instrument Customer Care Transaction can be 9915 initiated at any time by a Consumer including in the middle of another 9916 IOTP Transaction. In this case, the transaction shall establish a 9917 different transport session from the ongoing transaction. See the 9918 Mapping to Transport for the Transport Mechanism being used. 9920 The transaction consists of three types of IOTP messages as 9921 illustrated in the figure below. 9923 CONSUMER OTP MESSAGE PAYMENT INSTRUMENT 9924 (PAYMENT INSTRUMENT CUSTOMER CARE 9925 USER) PROVIDER 9927 1. Consumer Payment Instrument Software 9928 identifies need to contact Payment 9929 Instrument Customer Care Provider then 9930 generates data to place in a Payment 9931 Instrument Customer Care Request Block 9932 and the net location it needs to be 9933 sent to. OTP aware application uses 9934 data to generate the Payment Instrument 9935 Customer Care Request Block then sends 9936 it to the Customer Care Provider. 9937 | 9938 v 9939 OtpMsg: Trans Ref 2. Payment Instrument Customer 9940 Block; Signature --------------> Care Provider processes Payment 9941 Block (Optional); Payment Instrument Customer Care Request 9942 Payment Instrument Instrument Block, and starts exchanging 9943 Cust Care Request Cust. Care Payment Instrument Customer Care 9944 Block Request Exchange Blocks, with the 9945 Consumer. 9946 | 9947 v 9948 3. Consumer keeps on OtpMsg: Trans OtpMsg: Trans 9949 exchanging Payment Ref Block; <-----------------> Ref Block; 9950 Instrument Customer Signature Block Payment Instrument Signature Block 9951 Care Exchange Blocks (optional) Cust. Care Exchange (optional) 9952 with Payment Payment Payment 9953 Instrument Customer Instrument Instrument 9954 Care Provider Cust. Care Cust. Care 9955 Exchange Block Exchange Block 9956 | 9957 v 9958 4. Eventually Payment Instrument 9959 Customer Care Provider software 9960 identifies Payment Instrument 9961 Customer Care Exchanges finished 9962 so generates a Payment Instrument 9963 Customer Care Response Block, 9964 sends it to the Consumer and 9965 stops. 9966 | 9967 v 9968 5. Consumer checks Pay OtpMsg: Trans Ref 9969 Instrument Response is OK, <---------------- Block; Signature Block 9970 optionally keeps Payment (Optional); 9971 information on OTP Instrument Payment Instrument 9972 Transaction for record Cust. Care Cust. Care Response 9974 keeping purposes and stops Response Block 9975 | | 9976 v v 9977 STOP STOP 9979 Figure 39 IOTP Payment Instrument Customer Care Transaction Message 9980 Flows 9982 The remainder of this sub-section on the Payment Instrument Customer 9983 Care Transaction defines the contents of each Trading Block. 9985 8.7.1 Payment Instrument Customer Care Request Block 9987 The Payment Instrument Customer Care Request Block contains: 9988 o a Payment Method Information Component (see section 6.14) 9989 which describes the Payment Method for which Customer Care is 9990 requested, and 9991 o zero or more optional Payment Scheme Components (see section 9992 6.9) which contain optional Payment scheme data 9994 8.7.2 Payment Instrument Customer Care Exchange Block 9996 The Payment Instrument Customer Care Exchange Block contains: 9997 o a Payment Method Information Component (see section 6.14) 9998 which describes the Payment Method for which Customer Care is 9999 being provided, and 10000 o zero or more optional Payment Scheme Components (see section 10001 6.9) which contain optional Payment scheme data 10003 8.7.3 Payment Instrument Customer Care Response Block 10005 The Payment Instrument Customer Care Response Block contains: 10006 o a Payment Method Information Component (see section 6.14) 10007 which describes the Payment Method for which Customer Care is 10008 complete, and 10009 o zero or more optional Payment Scheme Component (see section 10010 6.9) which contains optional Payment scheme data 10012 8.7.4 Signature Block 10014 Any of the IOTP Messages which contain Payment Instrument Customer 10015 care blocks may also include a Signature Block (see section 7.18) 10016 containing a Signature Component (see section 6.18). How these are 10017 used and what it signs is dependent on the Payment Brand and Payment 10018 method being used. See the IOTP Payment Supplement for the payment 10019 method. 10021 8.8 Baseline Transaction Status Inquiry IOTP Transaction 10023 The Baseline IOTP Transaction Status Inquiry provides a Consumer with 10024 information on the status of an existing or complete IOTP transaction. 10026 The Trading Blocks used by the Baseline Transaction Status Inquiry 10027 Transaction are: 10028 o an Inquiry Request Trading Block (see section 7.14), and 10029 o an Inquiry Response Trading Block (see section 7.15). 10031 [Note] Note that: 10033 . Consumer Inquiries on Authentication transaction are not 10034 supported. 10036 . Authentication of Consumers as part of an inquiry is not 10037 supported in the Baseline version of IOTP. 10038 [Note End] 10040 8.8.1 Which Trading Roles can receive Inquiry Requests 10042 The Consumer can send a Transaction Status Inquiry Block to the 10043 appropriate Trading Role after the following events have occurred: 10044 o to the Merchant, after sending TPO Selection Block, 10045 o to the Payment Handler, after sending Payment Request Block, 10046 o to the Delivery Handler, after sending Delivery Request Block. 10048 [Note] IOTP does not support sending Inquiry Requests to the 10049 Consumer since the consumer may not be on-line to receive 10050 and process them. 10051 [Note End] 10053 If the Consumer is inquiring on transaction that is not yet complete, 10054 it should send the Inquiry Request Block to the Trading Role to which 10055 it sent the last IOTP message. If the Consumer is inquiring on a 10056 transaction which is complete, there are two alternatives in deciding 10057 the Trading Roles that the Inquiry Request Block should be sent to: 10058 o the Consumer IOTP software can ask the end user to determine 10059 the type of inquiry they want to make, or 10060 o the Consumer IOTP software can send the inquiry request 10061 message to all the Trading Roles that were involved in the 10062 IOTP transaction. 10064 For the second case above, how the Consumer IOTP Aware Application 10065 displays the inquiry response data received from each Trading Role is 10066 up to each implementation. 10068 8.8.2 Transaction Status Inquiry Transport Session 10070 For a Transaction Status Inquiry on an ongoing transaction, the 10071 Consumer shall establish with a Trading Role, a different transport 10072 session from the ongoing transaction. For a Transaction Status Inquiry 10073 on a past transaction, how the IOTP module on the software at the 10074 Trading Role is started upon the receipt of Inquiry Request message is 10075 defined in each Mapping to Transport supplement for IOTP. 10077 8.8.3 Transaction Status Inquiry Error Handling 10079 Errors in a Transaction Status Inquiry can be categorised into one the 10080 following three cases: 10081 o Business errors (see section 4.2) in the original (inquired) 10082 messages 10083 o Technical errors (see section 4.1) - both IOTP and payment 10084 scheme specific ones - in the original IOTP (inquired) 10085 messages 10086 o Technical errors in the message containing the Inquiry Request 10087 Block itself 10089 The following outlines what the software should do in each case 10091 Business errors in the original messages 10093 Return an Inquiry Response Block containing the Status Component which 10094 was last sent to the Consumer. 10096 Technical errors in the original messages 10098 Return an Inquiry Response Block containing a Status Component. The 10099 Status Component should contain a ProcessState attribute set to 10100 ProcessError. In this case send back an Error Block indicating where 10101 the error was found in the original message. 10103 Technical errors in the Inquiry Request Block 10105 Return an Error message. That is, send back an Error Block containing 10106 the Error Code (see section 6.19.2) which describes the nature of the 10107 error in the Inquiry Request message. 10109 8.8.4 Inquiry Transaction Messages 10111 The following Figure outlines the Baseline IOTP Transaction Status 10112 Inquiry processes on both Consumer and Service Provider sides. 10114 CONSUMER OTP MESSAGE TRADING ROLE 10115 1. The Consumer decides to inquire (Merchant, 10116 on an OTP transaction by, for Payment Handler, 10117 example, cliking the inquiry button Delivery Handler 10118 of the OTP Aware Application. This or Financial 10119 will then generate an Inquiry Institution) 10120 Request Block and send it to the 10121 appropriate Trading Role. 10122 | 10123 v 10124 OtpMs: Trans Ref 2. The Trading Role checks the 10125 Block; Inquiry ----------> transaction status of the transaction 10126 Request Block Inquiry that is being inquired upon by using 10127 Request the Transaction Id Component of the 10128 Transaction Reference Block. He then 10129 generates the appropriate Inquiry 10130 Response Block based on the status of 10131 the transaction and sends the message 10132 back to the Consumer 10133 | 10134 v 10135 3. The OTP Aware OtpMsg: Trans Ref 10136 Application displays the <---------------- Block; Inquiry 10137 status information to the Inquiry Response Response Block 10138 end user 10139 | 10140 v 10141 STOP 10143 Figure 40 Baseline Transaction Status Inquiry 10145 The remainder of this sub-section on the Baseline Transaction Status 10146 Inquiry IOTP Transaction defines the contents of each Trading Block. 10148 8.8.5 Transaction Reference Block 10150 The Consumer must use the same Transaction Id Component (see section 10151 3.3.1) as in the inquired transaction. The OtpTransId attribute in 10152 this component serves as the key in querying the transaction logs 10153 maintained at the Trading Role's site. The value of the ID attribute 10154 of the Message Id Component should be different from those of the 10155 inquired transaction (see section 3.4.1). 10157 8.8.6 Inquiry Request Block 10159 The Inquiry Request Block (see section 7.14) contains the following 10160 components: 10161 o one Inquiry Type Component (see section 6.17). This identifies 10162 whether the inquiry is on an offer, payment, or delivery. 10163 o zero or one Payment Scheme Component (see section 6.9). This 10164 is for encapsulating payment scheme specific inquiry messages 10165 for inquiries on payment. 10167 8.8.7 Inquiry Response Block 10169 The Inquiry Response Block (see section 7.15) contains the following 10170 components: 10172 o one Status Component (see section 6.15). This component hold 10173 the status information on the inquired transaction, 10174 o zero or one Payment Scheme Components. These contain for 10175 encapsulated payment scheme specific inquiry messages for 10176 inquiries on payment. 10178 8.9 Baseline Ping IOTP Transaction 10180 The purpose of the Baseline IOTP Ping Transaction is to enable IOTP 10181 aware application software to determine if the IOTP aware application 10182 at another Trading Role is operating and verifying whether or not 10183 signatures can be handled. 10185 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 10186 o a Ping Request Block (see section 7.16) 10187 o a Ping Response Block (see section 7.17), and 10188 o a Signature Block (see section 7.18). 10190 8.9.1 Ping Messages 10192 The following figure outlines the message flows in the Baseline IOTP 10193 Ping Transaction. 10195 OTP TRADING ROLE OTP MESSAGE OTP TRADING ROLE 10196 1. The OTP Aware Application in an 10197 OTP Trading Role decides to check 10198 whether the counterparty OTP 10199 application is up and running. It 10200 generates a Ping Block and optional 10201 Signature Block and sends them to 10202 the other OTP Trading Role. 10203 | 10204 v 10205 OtpMs: Trans Ref --------> 2. The OTP Trading Role which receives 10206 Block; Ping Ping the Ping Request generates a Ping 10207 Request Block Request Response and sends it back to the 10208 sender of the original Ping Request. 10209 | 10210 v 10211 3. The original sender of the OtpMsg: Trans Ref 10212 Ping Request checks the returned <------------ Block; Ping 10213 Ping Response and takes Ping Response Response Block 10214 appropriate action, if necessary 10215 | 10216 v 10217 STOP 10219 Figure 41 Baseline Ping Messages 10220 The verification that signatures can be handled is indicated by the 10221 sender of the Ping Request Block including: 10222 o Organisation Components that identify itself and the intended 10223 recipient of the Ping Request Block, and 10224 o a Signature Block that signs data in the Ping Request. 10226 In this way the receiver of the Ping Request: 10227 o knows who is sending the Ping Request and can therefore verify 10228 the Signature on the Request, and 10229 o knows who to generate a signature for on the Ping Response. 10231 Note that a Ping Request: 10232 o does not affect any on-going transaction 10233 o does NOT start an IOTP aware application, unlike other IOTP 10234 transaction messages such as TPO or Transaction Status 10235 Inquiry. 10237 All IOTP aware applications must return a Ping Response message to the 10238 sender of a Ping Request message when it is received. 10240 A Baseline IOTP Ping request can also contain an optional Signature 10241 Block. IOTP aware applications can, for example, use the Signature 10242 Block to check the recipient of a Ping Request can successfully 10243 process and check signatures it has received. 10245 For each Baseline Ping IOTP Transaction, each IOTP role shall 10246 establish a different transport session from other IOTP transactions. 10248 Any IOTP Trading Role can send a Ping request to any other IOTP 10249 Trading Role at any time it wants. A Ping message has its own 10250 OtpTransID, which is different from other IOTP transactions. 10252 The remainder of this sub-section on the Baseline Ping IOTP 10253 Transaction defines the contents of each Trading Block. 10255 8.9.2 Transaction Reference Block 10257 The OtpTransId of a Ping transaction should be different from any 10258 other IOTP transaction. 10260 8.9.3 Ping Request Block 10262 If the Ping Transaction is anonymous then no Organisation Components 10263 are included in the Ping Request Block (see section 7.6). 10265 If the Ping Transaction is not anonymous then the Ping Request Block 10266 contains Organisation Components for: 10267 o the sender of the Ping Request Block, and 10268 o the verifier of the Signature Component 10269 If Organisation Components are present, then it indicates that the 10270 sender of the Ping Request message has generated a Signature Block. 10271 The signature block must be verified by the Trading Role that receives 10272 the Ping Request Block. 10274 8.9.4 Signature Block (Ping Request) 10276 The Ping Request Signature Block (see section 7.18) contains the 10277 following components: 10278 o one Signature Component (see section 6.18) 10279 o one or more Certificate Components, if required. 10281 8.9.5 Ping Response Block 10283 The Ping Response Block (see section 7.17) contains the following 10284 component: 10285 o the Organisation Component of the sender of the Ping Response 10286 message 10288 If the Ping Transaction is not anonymous then the Ping Response 10289 additionally contains: 10290 o copies of the Organisation Components contained in the Ping 10291 Request Block. 10293 8.9.6 Signature Block (Ping Response) 10295 The Ping Response Signature Block (see section 7.18) contains the 10296 following components: 10297 o one Signature Component (see section 6.18) 10298 o one or more Certificate Components, if required. 10300 9. Retrieving Logos 10302 This section describes how to retrieve logos for display by IOTP aware 10303 software using the Logo Net Locations attribute contained in the Brand 10304 Element (see section 6.6.1) and the Organisation Component (see 10305 section 6.5). 10307 The full address of a logo is defined as follows: 10308 Logo_address ::= Logo_net_location "/" Logo_size 10309 Logo_color_depth ".GIF" 10311 Where: 10312 o Logo_net_location is obtained from the LogoNetLocn attribute 10313 in the Brand Element (see section 6.6.1) or the Organisation 10314 Component. Note that: 10316 - the content of this attribute is dependent on the Transport 10317 Mechanism (such as HTTP) that is used. See the Transport 10318 Mechanism supplement, 10319 - implementers should check that if the rightmost character of 10320 Logo Net Location is set to right-slash "/" then another, right 10321 slash should not be included when generating the Logo Address, 10322 o Logo_size identifies the size of the logo, 10323 o Logo_color_depth identifies the colour depth of the logo 10324 o "GIF" indicates that the logos are in GIF format 10326 Logo_size and Logo_color_depth are specified by the implementer of the 10327 IOTP software that is retrieving the logo depending on the size and 10328 colour that they want to use. 10330 9.1 Logo Size 10332 There are five standard sizes for logos. The sizes in pixels and the 10333 corresponding values for Logo Size are given in the table below. 10335 Size in Logo Size 10336 Pixels Value 10338 32 x 32 or exsmall 10339 32 x 20 10341 53 x 33 small 10343 103 x 65 medium 10345 180 x 114 large 10347 263 x 166 exlarge 10349 9.2 Logo Color Depth 10351 There are three standard colour depths. The colour depth (including 10352 bits per pixel) and the corresponding value for Logo_Color_Depth are 10353 given in the table below. 10355 Color Depth Logo Color 10356 (bits per pixel) Depth Value 10358 4 (16 colors) 4 10360 8 (256 colors) nothing 10362 24 (16 million colors) 24 10364 Note that if Logo Color Depth is omitted then a logo with the default 10365 colour depth of 256 colours will be retrieved. 10367 9.3 Logo Net Location Examples 10369 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 10370 o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium 10371 size 256 colour logo 10372 o "ftp://logos.xzpay.com/small4.gif" would retrieve a small size 10373 16 colour logo 10375 [Note] Organisations which make logos available for use with IOTP 10376 should always make available "small" and "medium" size logos 10377 and use the GIF format. 10378 [Note End] 10380 10. Brand List Examples 10382 This example contains three examples of the XML for a Brand List 10383 Component. It covers: 10384 o a simple credit card based example 10385 o a credit card based brand list including promotional credit 10386 card brands, and 10387 o a complex electronic cash based brand list 10389 Note that: 10390 o brand lists can be as complex or as simple as required 10391 o all example techniques described in this appendix can be 10392 included in one brand list. 10394 10.1 Simple Credit Card Based Example 10396 This is a simple example involving: 10397 o only major credit card payment brands 10398 o a single price in a single currency 10399 o a single payment handler, and 10400 o a single payment protocol 10402 10406 10411 10412 10417 10418 10423 10424 10427 10428 10431 10435 10436 10438 10.2 Credit Card Brand List Including Promotional Brands 10440 An example of a Credit Card based Brand List follows. It includes: 10441 o two ordinary card association brands and two promotional 10442 credit card brands. The promotional brands consist of one 10443 loyalty based (British Airways MasterCard) which offers 10444 additional loyalty points and one store based (Walmart) which 10445 offers a discount on purchases over a certain amount 10446 o two payment protocols: 10447 - SET (Secure Electronic Transactions) see [SET], and 10448 - SCCD (Secure Channel Credit Debit) see [SCCD]. 10450 10454 10459 10460 10465 10466 10473 10474 10481 10482 10485 10486 238djqw1298erh18dhoire 10487 10488 10489 10492 10493 238djqw1298erh18dhoire 10494 10495 10496 10499 10503 10504 8ueu26e482hd82he82 10505 10506 10507 10511 10512 82hd82he8226e48ueu 10513 10515 10516 10518 10.3 Brand Selection Example 10520 In order to pay by 'British Airways' MasterCard using the example 10521 above using SET and therefore getting double air miles, the Brand 10522 Selection would be: 10524 10529 10531 10.4 Complex Electronic Cash Based Brand List 10533 The following is an fairly complex example which includes: 10534 o payments using either Mondex, GeldKarte, CyberCash or DigiCash 10535 o in currencies including US dollars, British Pounds, Italian 10536 Lira, German Marks and Canadian Dollars 10537 o a discount on the price if the payment is made in Mondex using 10538 British pounds or US dollars, and 10539 o more than one payment handler is used for payments involving 10540 Mondex or CyberCash 10541 o support for more than one version of a CyberCash CyberCoin 10542 payment protocol. 10544 10548 10553 10554 10559 10560 10565 10566 10573 10574 10577 10578 10581 10582 10585 10586 10589 10590 10593 10594 10597 10600 10603 10606 10609 10612 10615 10618 10622 10623 10627 10628 10632 10633 10637 10638 10642 10643 10647 10648 10650 11. XML Overview 10652 This section contains an overview of [XML]. Its purpose is to provide 10653 sufficient explanation so that the XML examples in this document may 10654 be understood. This description is not complete. For more detail and 10655 the full specification see the reference contained in the Preface to 10656 this document. 10658 XML is based on SGML has the goal of enabling "generic SGML to be 10659 served, received, and processed on the Web in the way that is now 10660 possible with HTML. XML has been designed for ease of implementation 10661 and for interoperability with both SGML and HTML." 10663 XML is designed as a universal, open data format for the Internet and 10664 allows the structure of data in messages to be clearly and 10665 unambiguously defined. 10667 In the following examples, underlined words are to be replaced by 10668 proper names; for example, document name could be OtpMessage, 10669 EDIMessage, and so on. 10671 The structure of data in XML is defined using a number of key 10672 components. These are: 10673 o document definitions 10674 o element declarations and 10675 o attribute declarations. 10677 These are described below. 10679 11.1 Document Definition 10681 A document definition has the following form: 10683 10685 DocumentName For IOTP this is always OtpMessage. 10687 DocumentStructure This contains the declarations of elements, 10688 Definition attributes and entities. 10690 For example: 10692 10694 10695 10696 10697 ]> 10699 11.2 Element Declaration 10701 An element declaration has the following form: 10703 10705 ElementContent This defines the relationships among the elements, 10706 the order of occurrences of the elements, and 10707 their number of occurrences. 10709 11.2.1 Example 1 10711 An element X consists of elements A, B, and C in that order. This 10712 would be declared as follows: 10714 10716 If the elements A, B, and C can appear in any order, "&" is used in 10717 place of ",". 10719 As XML this would be expressed as follows: 10721 10722 DataA 10723 DataB 10724 DataC 10725 10727 In this example 10728 o "" is a start tag and "" is an end tag 10729 o "DataA", "DataB", and "DataC" is the content of the element 10730 and can consist of other elements, or character data or may 10731 even be empty. 10733 11.2.2 Example 2 10735 An element X consists of one of the elements A, B, or C. This would be 10736 declared as follows: 10738 10740 If element A is selected then this would be expressed as: 10742 10743 DataA 10744 10746 11.2.3 Example 3 10748 An element X consists of element A occurring zero or more times and 10749 element B occurring one or more times in that order. This would be 10750 declared as follows: 10752 10754 The "*" indicates zero or more, and the "+" indicates one or more. 10756 If A occurred zero times and b occurred twice then this would be 10757 expressed as: 10759 10760 DataB 10761 DataB 10762 10764 11.2.4 Data Types used in element declarations 10766 The previous examples described how one element can be defined as 10767 having "children" elements. In element declarations XML also supports 10768 data types. The data types used in this IOTP specification are shown 10769 below. 10771 Data Types Descriptions 10773 #PCDATA The element content contains data which the XML 10774 parser can search to look for tags or entity 10775 declarations. 10777 ANY The element content can contain any element 10778 defined in any order. 10780 EMPTY The element content contains no data. 10782 11.3 Attribute declarations 10784 Attribute declarations describe information about an element. More 10785 than one attribute can be defined for one element. Attributes are 10786 contained within the start tag of an element. They are defined as 10787 follows: 10789 10795 11.3.1 Declared value 10797 When the permissible values of an attribute are known, those values 10798 are declared as a list in the declared value. 10800 When the list of permissible values are not pre-defined, data types 10801 are specified instead. The data types which can be used for attribute 10802 declarations are listed below. Only the ones used in this IOTP 10803 specification are shown. 10805 Attribute Types Descriptions 10807 CDATA Character data. Characters other than attribute 10808 value delimiters such as (_ ') can be used. 10809 Characters of zero length are allowed. 10811 NMTOKEN An attribute which conforms with the rules for an 10812 XML name. In outline it must start with a letter 10813 and be followed by any combination of letters, 10814 digits, or a few special characters. No spaces are 10815 allowed 10817 NMTOKENS One or more NMTOKEN separated by spaces. 10819 ID Identifier. This value of this attribute is unique 10820 for each element. 10822 IDREF This value of this attribute matches the value of 10823 some ID attribute of an element in the same XML 10824 document. It is used to point to that element. 10826 IDREFS One or more IDREFs separated by spaces. 10828 11.3.2 Default value 10830 Default values indicate whether or not the attribute must be present 10831 in an element. 10833 For default values, the following default keywords as well as some 10834 concrete values can be specified. Only the default keywords used in 10835 this IOTP specification are shown. 10837 Values Descriptions 10839 #REQUIRED CANNOT abbreviate. Some value must be specified 10840 for this attribute. 10842 #IMPLIED When an attribute with this default value is not 10843 specified, the application gives the pre- 10844 determined attribute value. 10846 'value' The 'value specified is the default. Other values 10847 may be used. 10849 #FIXED 'value' The value must and can only be the value specified 10851 Example 10853 An example of an attribute declaration follows: 10855 10857 In this example a value for ATT1 must be present as it is "#REQUIRED" 10858 and it must be either "A" or "B" for the XML document to be valid. For 10859 example: 10861 DataX 10863 12. Open Trading Protocol Data Type Definition 10865 This section contains a copy of the XML DTD for the Open Trading 10866 Protocols for information purposes. 10868 The master copy of the DTD for IOTP, which should be relied upon is 10869 available for download from the IOTP web site (http://www.IOTP.org). 10871 10924 10945 10951 10952 10955 10956 10963 10964 10971 10972 10979 10985 10986 10990 10995 10996 10997 11005 11006 11007 11014 11015 11016 11020 11021 11022 11032 11033 11035 11044 11045 11050 11051 11058 11059 11066 11067 11077 11078 11080 11086 11087 11097 11098 11104 11105 11111 11112 11122 11123 11126 11133 11134 11138 11139 11143 11144 11148 11149 11150 11159 11160 11161 11167 11168 11169 11175 11176 11177 11181 11182 11183 11191 11192 11202 11203 11204 11210 11211 11212 11217 11218 11219 11231 11232 11233 11238 11239 11240 11246 11247 11248 11257 11258 11266 11272 11273 11274 11277 11278 11279 11282 11283 11285 11288 11289 11290 11293 11294 11295 11298 11299 11302 11305 11306 11307 11310 11311 11313 11316 11317 11319 11322 11323 11324 11327 11328 11329 11332 11333 11334 11337 11338 11339 11342 11343 11344 11347 11348 11349 11354 11355 11356 11359 11360 11361 11368 11369 11370 11373 11374 11375 11378 11379 11381 11383 13. Glossary 11385 This section contains a glossary of some of the terms used within this 11386 specification in alphabetical order. 11388 NAME DESCRIPTION 11390 Authenticator The organisation which is requesting the 11391 authentication of another organisation, and 11393 Authenticatee The organisation being authenticated by 11394 authenticated by an Authenticator 11396 Brand A Brand is the mark which identifies a particular 11397 type of Payment Instrument. A list of Brands are 11398 the payment options which are presented by the 11400 NAME DESCRIPTION 11401 Merchant to the Consumer and from which the 11402 Consumer makes a selection. Each Brand may have a 11403 different Payment Handler. Examples of Brands 11404 include: 11405 o payment association and proprietary 11406 Brands, for example MasterCard, Visa, 11407 American Express, Diners Club, American 11408 Express, Mondex, GeldKarte, CyberCash, 11409 etc. 11410 o Promotional Brands (see below). These 11411 include: 11412 o store Brands, where the Payment 11413 Instrument is issued to a Consumer by a 11414 particular Merchant, for example Walmart, 11415 Sears, or Marks and Spencer (UK) 11416 o coBrands, for example American Advantage 11417 Visa, where an organisation uses their 11418 own Brand in conjunction with, typically, 11419 a payment association Brand. 11421 Consumer The person or organisation which is to receive 11422 and pay for the goods or services 11424 Delivery The entity that physically delivers the goods or 11425 Handler services to the Consumer on behalf of the 11426 Merchant. 11428 Dual Brand A Dual Brand means that a single Payment 11429 Instrument may be used as if it were two separate 11430 Brands. For example there could be a single 11431 Japanese "UC" MasterCard which can be used as 11432 either a UC card or a regular MasterCard. The UC 11433 card Brand and the MasterCard Brand could each 11434 have their own separate Payment Handlers. This 11435 means that: 11436 o the Merchant treats, for example "UC" and 11437 "MasterCard" as two separate Brands when 11438 offering a list of Brands to the 11439 Consumer, 11440 o the Consumer chooses a Brand, for example 11441 either "UC" or "MasterCard, 11442 o the Consumer IOTP aware application 11443 determines which Payment Instrument(s) 11444 match the chosen Brand, and selects, 11445 perhaps with user assistance, the correct 11446 Payment Instrument to use. 11448 IOTP Message An IOTP Message is a collection of IOTP Trading 11449 Blocks which carries the data required to carry 11450 out an IOTP Transaction. They are a well formed 11451 XML document sent between the Trading Roles that 11453 NAME DESCRIPTION 11454 are taking part in a trade. 11456 IOTP An Internet Open Trading Protocol Transaction is 11457 Transaction described as a predefined set of IOTP Messages 11458 transferred between the Trading Roles. 11460 Merchant The person or organisation from whom the purchase 11461 is being made and who is legally responsible for 11462 providing the goods or services and receives the 11463 benefit of the payment made 11465 Merchant The entity that is involved with customer dispute 11466 Customer Care negotiation and resolution on behalf of the 11467 Provider Merchant 11469 Payment The entity that physically receives the payment 11470 Handler from the Consumer on behalf of the Merchant 11472 Payment A Payment Instrument is the means by which 11473 Instrument Consumer pays for goods or services offered by a 11474 Merchant. It can be, for example: 11475 o a credit card such as MasterCard or Visa; 11476 o a debit card such as MasterCard's 11477 Maestro; 11478 o a smart card based electronic cash 11479 Payment Instrument such as a Mondex Card, 11480 a GeldKarte card or a Visa Cash card 11481 o a software based electronic payment 11482 account such as a CyberCash or DigiCash 11483 account. 11485 All Payment Instruments have a number, typically 11486 an account number, by which the Payment 11487 Instrument can be identified. 11489 Payment The entity that resolves problems with a 11490 Instrument particular Payment Instrument 11491 Customer Care 11492 Provider 11494 Promotional A Promotional Brand means that, if the Consumer 11495 Brand pays with that Brand, then the Consumer will 11496 receive some additional benefit which can be 11497 received in two ways: 11498 o at the time of purchase. For example if a 11499 Consumer pays with a "Walmart MasterCard" 11500 at a Walmart web site, then a 5% discount 11501 might apply, which means the Consumer 11502 actually pays less, 11503 o from their Payment Instrument (card) 11504 issuer when the payment appears on their 11506 NAME DESCRIPTION 11507 statement. For example loyalty points in 11508 a frequent flyer scheme could be awarded 11509 based on the total payments made with the 11510 Payment Instrument since the last 11511 statement was issued. 11513 Each Promotional Brand should be identified as a 11514 separate Brand in the list of Brands offered by 11515 the Merchant. For example: "Walmart", "Sears", 11516 "Marks and Spencer" and "American Advantage 11517 Visa", would each be a separate Brand. 11519 Trading Block A Trading Block consists of one or more Trading 11520 Components. One or more Trading Blocks may be 11521 contained within the IOTP Messages which are 11522 physically sent in the form of [XML] documents 11523 between the different organisations that are 11524 taking part in a trade. 11526 Trading A Trading Component is collections of XML 11527 Component elements and attributes. Trading Components are 11528 the child elements of the Trading Blocks. 11530 Trading Role A Trading Role identifies the different ways in 11531 which organisations can participate in a trade. 11532 There are five Trading Roles: Consumer, Merchant, 11533 Payment Handler, Delivery Handler, Merchant 11534 Customer Care Provider and Payment Instrument 11535 Customer Care Provider. 11537 14. Copyrights 11539 Copyright (C) The Internet Society (1998). All Rights Reserved. 11541 This document and translations of it may be copied and furnished to 11542 others, and derivative works that comment on or otherwise explain it 11543 or assist in its implementation may be prepared, copied, published and 11544 distributed, in whole or in part, without restriction of any kind, 11545 provided that the above copyright notice and this paragraph are 11546 included on all such copies and derivative works. However, this 11547 document itself may not be modified in any way, such as by removing 11548 the copyright notice or references to the Internet Society or other 11549 Internet organisations, except as needed for the purpose of developing 11550 Internet standards in which case the procedures for copyrights defined 11551 in the Internet Standards process must be followed, or as required to 11552 translate it into languages other than English. 11554 The limited permissions granted above are perpetual and will not be 11555 revoked by the Internet Society or its successors or assigns. 11557 This document and the information contained herein is provided on an 11558 AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 11559 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 11560 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 11561 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 11562 OR FITNESS FOR A PARTICULAR PURPOSE. 11564 15. References 11566 This section contains references to related documents identified in 11567 this specification. 11569 [Base64] Base64 Content-Transfer-Encoding. A method of 11570 transporting binary data defined by MIME. See: RFC 2045: 11571 Multipurpose Internet Mail Extensions (MIME) Part One: 11572 Format of Internet Message Bodies. N. Freed & N. 11573 Borenstein. November 1996. 11575 [DNS] The Internet Domain Name System which allocates Internet 11576 names to organisations for example "IOTP.org", the Domain 11577 Name for IOTP. See RFC 1034: Domain names - concepts and 11578 facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035: 11579 Domain names - implementation and specification. P.V. 11580 Mockapetris. Nov-01-1987. 11582 [DSA] The Digital Signature Algorithm (DSA) published by the 11583 National Institute of Standards and Technology (NIST) in 11584 the Digital Signature Standard (DSS), which is a part of 11585 the US government's Capstone project. 11587 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm 11588 (ECCDSA). Elliptic curve cryptosystems are analogs of 11589 public-key cryptosystems such as RSA in which modular 11590 multiplication is replaced by the elliptic curve addition 11591 operation. See: V. S. Miller. Use of elliptic curves in 11592 cryptography. In Advances in Cryptology - Crypto '85, 11593 pages 417-426, Springer-Verlag, 1986. 11595 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up 11596 Language (HTML) is a simple mark-up language used to 11597 create hypertext documents that are platform independent. 11598 See RFC 1866 and the World Wide Web (W3C) consortium web 11599 site at: http://www.w3.org/MarkUp/ 11601 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 11602 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 11604 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 11605 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 11606 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 11607 Lee. January 1997. 11609 [ISO4217] ISO 4217: Codes for the Representation of Currencies. 11610 Available from ANSI or ISO. 11612 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 11613 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 11615 [OPS] Open Profiling Standard. A proposed standard which 11616 provides a framework with built-in privacy safeguards for 11617 the trusted exchange of profile information between 11618 individuals and web sites. Being developed by Netscape 11619 and Microsoft amongst others. 11621 [RFC822] IETF (Internet Engineering Task Force). RFC 822: The 11622 Standard for the Format of ARPA Internet Messages 11624 . 13 August 1982, David H Crocker. 13 August 1982. 11626 [RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform 11627 Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, 11628 M. McCahill. 1994. 11630 [RSA] RSA is a public-key cryptosystem for both encryption and 11631 authentication supported by RSA Data Security Inc. See: 11632 R. L. Rivest, A. Shamir, and L.M. Adleman. A method for 11633 obtaining digital signatures and public-key 11634 cryptosystems. Communications of the ACM, 21(2): 120-126, 11635 February 1978. 11637 [SCCD] Secure Channel Credit Debit. A method of conducting a 11638 credit or debit card payment where unauthorised access to 11639 account information is prevented through use of secure 11640 channel transport mechanisms such as SSL. An IOTP 11641 supplement describing how SCCD works is under 11642 development. Author. Jonathan Sowler JCP, 11644 [SET] Secure Electronic Transaction Specification, Version 1.0, 11645 May 31, 1997. Supports credit and debit card payments 11646 using certificates at the Consumer and Merchant to help 11647 ensure authenticity. 11648 Download from: 11649 . 11651 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of 11652 Standards and Technology, US Department Of Commerce, 11653 April 1995. Also known as: 59 Fed Reg. 35317 (1994). 11655 [UTC] Universal Time Co-ordinated. A method of defining time 11656 absolutely relative to Greenwich Mean Time (GMT). 11658 Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" 11659 where the "+n" defines the number of hours from GMT. See 11660 ISO DIS8601. 11662 [UTF16] The Unicode Standard, Version 2.0. The Unicode 11663 Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 11664 Proposed Draft Amendment 1 11666 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, 11667 Including Draft Amendment 1: Certificate Extensions 11668 (Version 3 Certificate) 11670 [XML See Design decisions reached at the XML Working Group 11671 Namespace] meeting in Montreal, Canada, August 22, 1987 11673 [XML] Extensible Mark Up Language. See http://www.w3.org/TR/PR- 11674 xml-971208 for the 8 December 1997 version. 11676 [XMLSIG] A proposal developed by the IOTP consortium describing an 11677 approach to signing XML documents such as IOTP Messages. 11678 It is intended that this document is submitted to W3C for 11679 consideration. Author. Richard Brown. GlobeSet. (Under 11680 preparation August 1998) 11682 16. Author's Address 11684 The author of this document is: 11686 David Burdett 11687 Development Director 11688 Mondex International Ltd 11689 Advanced Technology Division 11690 111 Pine St, Suite 600 11691 San Francisco, 94111 11692 California 11693 USA 11695 Tel: +1 (415) 645 6973 11697 Email: david.burdett@mondex.com 11699 The author of this document appreciates the following contributors to 11700 this protocol (in alphabetic order of company) without which it could 11701 not have been developed. 11702 o Phillip Mullarkey, British Telecom plc 11703 o Andrew Marchewka, Canadian Imperial Bank of Commerce 11704 o Brian Boesch, CyberCash Inc. 11705 o Donald Eastlake 3rd, CyberCash Inc. 11706 o Mark Linehan, International Business Machines 11707 o Peter Chang, Hewlett Packard 11708 o Masaaki Hiroya, Hitachi Ltd 11709 o Yoshiaki Kawatsura, Hitachi Ltd 11710 o Jonathan Sowler, JCP Computer Services Ltd 11711 o John Wankmueller, MasterCard International 11712 o Steve Fabes, Mondex International Ltd 11713 o Surendra Reddy, Oracle Corporation 11714 o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) 11715 o Chris Smith, Royal Bank of Canada 11716 o Hans Bernhard-Beykirch, SIZ (IT Development and Coordination 11717 Centre of the German Savings Banks Organisation) 11718 o W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, 11719 formally AT&T Universal Card Services) 11720 o Efrem Lipkin, Sun Microsystems 11721 o Terry Allen, Veo Systems 11723 The author would also like to thank the following organisations for 11724 their support: 11725 o Amino Communications 11726 o DigiCash 11727 o Fujitsu 11728 o General Information Systems 11729 o Globe Id Software 11730 o Hyperion 11731 o InterTrader 11732 o Nobil I T Corp 11733 o Mercantec 11734 o Netscape 11735 o Nippon Telegraph and Telephone Corporation 11736 o Oracle Corporation 11737 o Smart Card Integrations Ltd. 11738 o Spyrus 11739 o Verifone 11740 o Unisource nv 11741 o Wells Fargo Bank 11743 Note: This is file draft-ietf-trade-iotp-v1.0-protocol-02.txt 11744 Expires: 23 May 1999