idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-00.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-00', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 608 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 218 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 604: '... The key words MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 605: '... NOT, SHOULD, SHOULD NOT, RECOMME...' RFC 2119 keyword, line 606: '... OPTIONAL in this document are to be ...' RFC 2119 keyword, line 610: '... more of the MUST requirements for th...' RFC 2119 keyword, line 611: '...atisfies all the MUST and all the SHOU...' (77 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 23 has weird spacing: '... shadow direc...' == Line 33 has weird spacing: '...ussions of t...' == Line 38 has weird spacing: '...rovides an...' == Line 63 has weird spacing: '...ilities to b...' == Line 85 has weird spacing: '...Systems deser...' == (603 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 (March 21, 1999) is 9167 days in the past. Is this intentional? 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 1401, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'SSL' is mentioned on line 8370, but not defined == Missing Reference: 'ISO 4217' is mentioned on line 5710, but not defined == Missing Reference: 'Alvestrand' is mentioned on line 8375, but not defined -- Looks like a reference, but probably isn't: '1998' on line 8381 == Missing Reference: 'Yergeau' is mentioned on line 8381, but not defined == Missing Reference: 'ISO-639' is mentioned on line 8387, but not defined == Unused Reference: 'Base64' is defined on line 8439, but no explicit reference was found in the text == Unused Reference: 'DSA' is defined on line 8450, but no explicit reference was found in the text == Unused Reference: 'ECCDSA' is defined on line 8455, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 8467, but no explicit reference was found in the text == Unused Reference: 'ISO4217' is defined on line 8473, but no explicit reference was found in the text == Unused Reference: 'MIME' is defined on line 8476, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 8491, but no explicit reference was found in the text == Unused Reference: 'SCCD' is defined on line 8497, but no explicit reference was found in the text == Unused Reference: 'SHA1' is defined on line 8508, but no explicit reference was found in the text == Unused Reference: 'UTF16' is defined on line 8517, 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) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- 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: 16 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 Surendra Reddy(Oracle) 2 Internet Draft David Burdett(Mondex) 3 draft-ietf-trade-iotp-v1.0-protocol-00.txt September 21,1998 4 Expires March 21, 1999 6 Internet Open Trading Protocol - IOTP 8 Status of this Memo 10 This document is an Internet draft. Internet drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas and its working groups. Note that other groups may also 13 distribute working information as Internet drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months and can be updated, replaced or obsoleted by other 17 documents at any time. It is inappropriate to use Internet drafts 18 as reference material or to cite them as other than as "work in 19 progress". 21 To learn the current status of any Internet draft please check 22 the "lid-abstracts.txt" listing contained in the Internet drafts 23 shadow directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 25 coast) or ftp.isi.edu (US West coast). Further information about 26 the IETF can be found at URL: http://www.ietf.org/ 28 Distribution of this document is unlimited. Please send comments 29 to the TRADE working group at , 30 which may be joined by sending a message with subject "subscribe" 31 to . 33 Discussions of the TRADE working group are archived at 34 http://www.elistx.com/archives/ietf-trade. 36 Abstract 38 The Internet Open Trading Protocol (IOTP) provides an 39 interoperable framework for Internet commerce. It is payment 40 system independent and encapsulates payment systems such as SET, 41 Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to 42 handle cases where such merchant roles as the shopping site, the 43 payment handler, the Delivery Handler of goods or services, and 44 the provider of customer support are performed by different 45 parties or by one party. 47 The developers of IOTP seek to provide a virtual capability that 48 safely replicates the real world, the paper based, traditional, 49 understood, accepted methods of trading, buying, selling, value 50 exchanging that has existed for many hundreds of years. The 51 negotiation of who will be the parties to the trade, how it will 52 be conducted, the presentment of an offer, the method of payment, 53 the provision of a payment receipt, the delivery of goods and the 54 receipt of goods. These are events that are taken for granted in 55 the course of real world trade. IOTP has been produced to provide 56 the same for the virtual world, and to prepare and provide for 57 the introduction of new models of trading made possible by the 58 expanding presence of the virtual world. 60 The other fundamental ideal of the IOTP effort is to produce a 61 definition of these trading events in such a way that no matter 62 where produced, two unfamiliar parties using electronic commerce 63 capabilities to buy and sell that conform to the IOTP 64 specifications will be able to complete the business safely and 65 successfully. 67 Acknowledgements 69 The Internet Open Trading Protocol has benefited from a large and 70 active developer community who have participated on the otp-dev 71 mailing list and has been most responsible for the successful 72 completion of this specification. 73 Phillip Mullarkey, British Telecom plc, Andrew Marchewka, Canadian 74 Imperial Bank of Commerce, Brian Boesch, CyberCash Inc., Donald 75 Eastlake 3rd, CyberCash Inc., Mark Linehan, International Business 76 Machines, Peter Chang, Hewlett Packard, Masaaki Hiroya, Hitachi 77 Ltd, Yoshiaki Kawatsura, Hitachi Ltd, Jonathan Sowler, JCP Computer 78 Services Ltd, John Wankmueller, MasterCard International, Steve 79 Fabes, Mondex International Ltd, Akihiro Nakano, Plat Home, Inc. 80 (ex Hitachi Ltd), Chris Smith, Royal Bank of Canada, Hans 81 Bernhard-Beykirch, SIZ (IT Development and Coordination Centre of 82 the German Savings Banks Organisation), W. Reid Carlisle, Spyrus 83 (ex Citibank Universal Card Services, formally AT&T Universal 84 Card Services), Efrem Lipkin, Sun Microsystems, Terry Allen, Veo 85 Systems deserve special recognition for their efforts in 86 defining early aspects of the protocol. 88 Table of Contents 90 i. Status of this Memo .......................................... 1 92 ii. Abstract ..................................................... 1 94 iii. Acknowledgements ............................................. 2 95 1 Introduction .................................................... 6 96 1.1 Commerce on the Internet - a Different Model ................ 6 97 1.2 What is IOTP? ............................................... 7 98 1.3 Benefits of IOTP ............................................ 7 99 1.4 Terminology ................................................. 9 100 1.5 IOTP - Abstract Model ....................................... 11 101 1.6 Interoperability Model ...................................... 12 102 1.7 Document Framework .......................................... 12 103 1.8 Document Scope .............................................. 12 104 1.9 Requirements ................................................ 13 106 2 Internet Open Trading Protocol .................................. 13 107 2.1 Introduction ................................................ 14 108 2.2 Trading Roles ............................................... 15 109 2.3 Trading Exchanges ........................................... 16 110 2.4 Offer Exchange .............................................. 17 111 2.5 Payment Exchange ............................................ 18 112 2.6 Delivery Exchange ........................................... 20 113 2.7 Authentication Exchange ..................................... 22 114 2.8 Brands and Brand Selection .................................. 22 116 3 IOTP Elements ................................................... 25 117 3.1 IOTP Message Structure ...................................... 25 118 3.2 IOTP Transactions ........................................... 27 119 3.3 IOTP Message ................................................ 28 120 3.4 XML Document Prolog ......................................... 29 121 3.5 Transaction Reference Block ................................. 29 122 3.6 ID Attributes ............................................... 34 123 3.7 Element References .......................................... 37 124 3.8 Packaged Content Element .................................... 37 125 3.9 Extending IOTP .............................................. 39 126 3.10 Identifying Languages ...................................... 41 127 3.11 Secure and Insecure Net Locations .......................... 42 129 4 Internet Open Trading Protocol Transactions ..................... 42 130 4.1 Baseline Authentication IOTP Transaction .................... 43 131 4.2 Baseline Deposit IOTP Transaction ........................... 44 132 4.3 Baseline Purchase IOTP Transaction .......................... 49 133 4.4 Baseline Refund IOTP Transaction ............................ 56 134 4.5 Baseline Withdrawal IOTP Transaction ........................ 61 135 4.6 Baseline Value Exchange IOTP Transaction .................... 67 136 4.7 Payment Instrument Customer Care IOTP Transaction ........... 75 137 4.8 Baseline Transaction Status Inquiry IOTP Transactin ......... 77 138 4.9 Baseline Ping IOTP Transaction .............................. 80 140 5 Trading Blocks .................................................. 81 141 5.1 Trading Protocol Options Block .............................. 82 142 5.2 TPO Selection Block ......................................... 83 143 5.3 Offer Response Block ........................................ 84 144 5.4 Authentication Request Block ................................ 85 145 5.5 Authentication Response Block ............................... 86 146 5.6 Payment Request Block ....................................... 86 147 5.7 Payment Exchange Block ...................................... 88 148 5.8 Payment Response Block ...................................... 88 149 5.9 Delivery Request Block ...................................... 89 150 5.10 Delivery Response Block .................................... 90 151 5.11 Payment Instrument Customer Care Request Block ............. 91 152 5.12 Payment Instrument Customer Care Exchange Block ............ 91 153 5.13 Payment Instrument Customer Care Response Block ............ 92 154 5.14 Inquiry Request Trading Block .............................. 92 155 5.15 Inquiry Response Trading Block ............................. 93 156 5.16 Ping Request Block ......................................... 94 157 5.17 Ping Response Block ........................................ 95 158 5.18 Signature Block ............................................ 97 159 5.19 Error Block ................................................ 98 161 6 Trading Components .............................................. 99 162 6.1 Protocol Options Component .................................. 100 163 6.2 Authentication Data Component ............................... 102 164 6.3 Authentication Response Component ........................... 103 165 6.4 Order Component ............................................. 104 166 6.5 Order Description Content ................................... 106 167 6.6 OkFrom and OkTo Timestamps .................................. 106 168 6.7 Organization Component ...................................... 107 169 6.8 Trading Role Element ........................................ 110 170 6.9 Contact Information Element ................................. 111 171 6.10 Person Name Element ........................................ 112 172 6.11 Postal Address Element ..................................... 113 173 6.12 Brand List Component ....................................... 114 174 6.13 Brand Element .............................................. 116 175 6.14 Protocol Amount Element .................................... 118 176 6.15 Currency Amount Element .................................... 120 177 6.16 Pay Protocol Element ....................................... 121 178 6.17 Brand Selection Component .................................. 123 179 6.18 Brand Selection Brand Info Element ......................... 125 180 6.19 Brand Selection Protocol Amount Info Element ............... 126 181 6.20 Brand Selection Currency Amount Info Element ............... 126 182 6.21 Payment Component .......................................... 127 183 6.22 Payment Scheme Component ................................... 128 184 6.23 Payment Receipt Component .................................. 130 185 6.24 Delivery Component ......................................... 131 186 6.25 Delivery Data Element ...................................... 133 187 6.26 Delivery Note Component .................................... 135 188 6.27 Payment Method Information Component ....................... 137 189 6.28 Status Component ........................................... 137 190 6.29 Inquiry Type Component ..................................... 142 191 6.30 Signature Component ........................................ 143 192 6.31 Offer Response Signature Component ......................... 144 193 6.32 Payment Receipt Signature Component ........................ 145 194 6.33 Ping Signature Components .................................. 145 195 6.34 Error Component ............................................ 145 196 6.35 Error Processing Guidelines ................................ 148 197 6.36 Error Codes ................................................ 149 198 6.37 Error Location Element ..................................... 153 200 7 IOTP Error Handling ............................................. 154 201 7.1 Technical Errors ............................................ 155 202 7.2 Business Errors ............................................. 155 203 7.3 Error Depth ................................................. 156 204 7.4 Idempotency, Processing Sequence, and Message Flow .......... 158 205 7.5 Client Role Processing Sequence ............................. 163 207 8 Retrieving Logos ................................................ 166 208 8.1 Logo Size ................................................... 167 209 8.2 Logo Color Depth ............................................ 167 210 8.3 Logo Net Location Examples .................................. 168 212 9 Security Considerations ......................................... 168 213 9.1 Digital Signatures and IOTP ................................. 168 214 9.2 IOTP Signature Example ...................................... 169 215 9.3 SignerOrgRef and VerifierOrgRef Attributes .................. 169 216 9.4 Symmetric and Asymmetric Cryptography ....................... 170 217 9.5 Mandatory and Optional Signatures ........................... 170 218 9.6 Using signatures to Prove Actions Complete 219 Successfully ................................................ 171 220 9.7 Check the Action Request was sent to the Correct 221 Organization ................................................ 173 222 9.8 Check the Correct Components are present in the 223 Request Block ............................................... 175 224 9.9 Check an Action is Authorised ............................... 175 225 9.10 Data Integrity and Privacy ................................. 177 227 10 Internationalization ........................................... 178 229 11 IANA Considerations ............................................ 178 231 12 Copyrights ..................................................... 178 233 13 References ..................................................... 179 235 14 Appendices ..................................................... 181 236 14.1 IOTP DTD Specification .................................... 181 238 15 Author's Address ............................................... 191 240 1. Introduction 242 1.1. Commerce on the Internet - a Different Model 244 The growth of the Internet and the advent of electronic commerce 245 are bringing about enormous changes around the world in society, 246 politics and government, and in business. The ways in which 247 trading partners communicate, conduct commerce, are governed have 248 been enriched and changed forever. 250 One of the very fundamental changes about which IOTP is concerned 251 is taking place in the way consumers and merchants trade. 252 Characteristics of trading that have changed markedly include: 254 - Presence: Face-to-face transactions become the exception, 255 not the rule. Already with the rise of mail order and 256 telephone order placement this change has been felt in 257 western commerce. Electronic commerce over the Internet will 258 further expand the scope and volume of transactions 259 conducted without ever seeing the people who are a part of 260 the enterprise with whom one does business. 261 - Authentication: An important part of personal presence is 262 the ability of the parties to use familiar objects and 263 dialogue to confirm they are who they claim to be. The 264 seller displays one or several well known financial logos 265 that declaim his ability to accept widely used credit and 266 debit instruments in the payment part of a purchase. The 267 buyer brings government or financial institution 268 identification that assures the seller she will be paid. 269 People use intangibles such as personal appearance and 270 conduct, location of the store, apparent quality and 271 familiarity with brands of merchandise, and a good clear 272 look in the eye to reinforce formal means of authentication. 273 - Payment Instruments: Despite the enormous size of bank card 274 financial payments associations and their members, most of 275 the world`s trade still takes place using the coin of the 276 realm or barter. The present infrastructure of the payments 277 business cannot economically support low value transactions 278 and could not survive under the consequent volumes of 279 transactions if it did accept low value transactions. 280 - Transaction Values: New meaning for low value transactions 281 arises in the Internet where sellers may wish to offer for 282 example, pages of information for fractions of currency that 283 do not exist in the real world. 284 - Delivery: New modes of delivery must be accommodated such as 285 direct electronic delivery. The means by which receipt is 286 confirmed and the execution of payment change dramatically 287 where the goods or services have extremely low delivery cost 288 but may in fact have very high value. Or, maybe the value is 289 not high, but once delivery occurs the value is 290 irretrievably delivered so payment must be final and 291 non-refundable but delivery nonetheless must still be 292 confirmed before payment. Incremental delivery such as 293 listening or viewing time or playing time are other models 294 that operate somewhat differently in the virtual world. 296 1.2. What is IOTP? 298 The Internet Open Trading Protocol (IOTP) provides an 299 interoperable framework for Internet commerce. It is payment 300 system independent and encapsulates payment systems such as SET, 301 Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to 302 handle cases where such merchant roles as the shopping site, the 303 payment handler, the Delivery Handler of goods or services, and 304 the provider of customer support are performed by different 305 parties or by one party. 307 The main goal of IOTP is to provide a virtual capability that 308 safely replicates the real world, the paper based, traditional, 309 understood, accepted methods of trading, buying, selling, value 310 exchanging that has existed for many hundreds of years. The 311 negotiation of who will be the parties to the trade, how it will 312 be conducted, the presentment of an offer, the method of payment, 313 the provision of a payment receipt, the delivery of goods and the 314 receipt of goods. These are events that are taken for granted in 315 the course of real world trade. IOTP has been produced to provide 316 the same for the virtual world, and to prepare and provide for 317 the introduction of new models of trading made possible by the 318 expanding presence of the virtual world. 320 The other fundamental goal of the IOTP effort is to define these 321 trading events in such a way that no matter where produced, two 322 unfamiliar parties using electronic commerce capabilities to buy 323 and sell that conform to the IOTP specifications will be able 324 to complete the business safely and successfully. 326 1.3. Benefits of IOTP 327 1. Electronic Commerce Software Vendors will be able to develop 328 e-commerce products which are more attractive as they will 329 inter-operate with any other vendors' software. However 330 since IOTP focuses on how these solutions communicate, there 331 is still plenty of opportunity for product differentiation. 333 2. IOTP provides a standard framework for encapsulating payment 334 protocols. This means that it is easier for payment products 335 to be incorporated into IOTP solutions. As a result the 336 payment brands will be more widely distributed and available 337 on a wider variety of platforms. 339 3. There are several benefits for Merchants: 341 o they will be able to offer a wider variety of payment 342 brands, 344 o they can be more certain that the customer will have the 345 software needed to complete the purchase 347 o through receiving payment and delivery receipts from 348 their customers, they will be able to provide customer 349 care knowing that they are dealing with the individual or 350 organisation with which they originally traded 352 o new merchants will be able to enter this new (Internet) 353 market-place with new products and services, using the 354 new trading opportunities which IOTP presents 356 4. There are also several benefits for Banks and Financial 357 Institutions: 359 o they will be able to provide IOTP support for merchants 361 o they will find new opportunities for IOTP related 362 services: 364 o providing customer care for merchants 366 o fees from processing new payments and deposits 368 o they have an opportunity to build relationships with new 369 types of merchants 371 5. For Customers there are several benefits: 373 o they will have a larger selection of merchants with whom 374 they can trade 376 o there is a more consistent interface when making the 377 purchase 379 o there are ways in which they can get their problems fixed 380 through the merchant (rather than the bank!) 382 o there is a record of their transaction which can be used, 383 for example, to feed into accounting systems or, 384 potentially, to present to the tax authorities 386 1.4. Terminology 388 Consumer 389 The person or organisation which is to receive and pay for 390 the goods or services 392 Merchant 393 The person or organisation from whom the purchase is being 394 made and who is legally responsible for providing the goods 395 or services and receives the benefit of the payment made 397 Payment Handler 398 The entity that physically receives the payment from the 399 Consumer on behalf of the Merchant 401 Delivery Handler 402 The entity that physically delivers the goods or services to 403 the Consumer on behalf of the Merchant. 405 Merchant Customer Care Provider 406 The entity that is involved with customer dispute 407 negotiation and resolution on behalf of the Merchant 409 Payment Instrument Customer Care Provider 410 The entity that resolves problems with a particular Payment 411 Instrument 413 Payment Instrument 414 A Payment Instrument is the means by which Consumer pays for 415 goods or services offered by a Merchant. It can be, for 416 example: 418 o a credit card such as MasterCard or Visa; 420 o a debit card such as MasterCard's Maestro; 422 o a smart card based electronic cash payment instrument 423 such as a Mondex Card, a GeldKarte card or a Visa Cash 424 card 426 o a software based electronic payment account such as a 427 CyberCash or DigiCash account. 429 All Payment Instruments have a number, typically an account 430 number, by which the Payment Instrument can be identified. 432 Brand 433 A Brand is the mark which identifies a particular type of 434 Payment Instrument. A list of Brands are the payment 435 options which are presented by the Merchant to the Consumer 436 and from which the Consumer makes a selection. Each Brand 437 may have a different Payment Handler. Examples of Brands 438 include: 440 o payment association and proprietary Brands, for example 441 MasterCard, Visa, American Express, Diners Club, American 442 Express, Mondex, GeldKarte, CyberCash, etc. 444 o promotional brands (see below). These include: 446 o store brands, where the Payment Instrument is issued to a 447 Consumer by a particular Merchant, for example Walmart, 448 Sears, or Marks and Spencer (UK) 450 o cobrands, for example American Advantage Visa, where an 451 organisation uses their own brand in conjunction with, 452 typically, a payment association Brand. 454 Dual Brand 455 A Dual Brand means that a single payment instrument may be 456 used as if it were two separate Brands. For example there 457 could be a single Japanese "UC" MasterCard which can be used 458 as either a UC card or a regular MasterCard. The UC card 459 Brand and the MasterCard Brand could each have their own 460 separate Payment Handlers. This means that: 462 o the merchant treats, for example "UC" and "MasterCard" as 463 two separate Brands when offering a list of Brands to the 464 Consumer, 466 o the consumer chooses a Brand, for example either "UC" or 467 "MasterCard, 469 o the consumer IOTP aware application determines which 470 Payment Instrument(s) match the chosen Brand, and 471 selects, perhaps with user assistance, the correct 472 Payment Instrument to use. 474 Promotional Brand 475 A Promotional Brand means that, if the Consumer pays with 476 that Brand, then the Consumer will receive some additional 477 benefit which can be received in two ways: 479 o at the time of purchase. For example if a Consumer pays 480 with a "Walmart MasterCard" at a Walmart web site, then a 481 5% discount might apply, which means the consumer 482 actually pays less, 484 o from their Payment Instrument (card) issuer when the 485 payment appears on their statement. For example loyalty 486 points in a frequent flyer scheme could be awarded based 487 on the total payments made with the Payment Instrument 488 since the last statement was issued. 490 each Promotional Brand should be identified as a separate 491 Brand in the list of Brands offered by the Merchant. For 492 example: "Walmart", "Sears", "Marks and Spencer" and 493 "American Advantage Visa", would each be a separate Brand. 495 1.5. IOTP - Abstract Model 496 The Internet Open Trading Protocol is described as a set of IOTP 497 messages trasnferred between the Trading Roles. The IOTP message is 498 a collection of IOTP Trading Blocks which carries the specification 499 Trading Transaction. Following sections describe each component 500 in detail: 502 1.5.1. Trading Roles: 503 Trading Roles identify the different parts which organizations 504 can participate in trade. There are five trading roles: Consumer, 505 Merchant, Payment Handler, Delivery Handler, Merchant Customer 506 Care Provider and Payment Instrument Customer Care Provider. A 507 Trading Role (OTR) performs a trading transactions using a IOTP 508 USER AGENT (OUA). A OUA uses the IOTP Transport-Independent 509 Interoperability Protocol (IOTP) to deliver Trading Components to 510 a Trading Role. 512 1.5.2. IOTP Messages 514 IOTP messages are well formed XML document sent between the IOTP 515 trading roles that are taking part in a trade. 517 1.5.3. Trading Transactions 518 A predefined set of IOTP Messages exchanged between the Trading 519 Roles constitute an IOTP Transaction. 521 1.5.4. Trading Blocks 522 Trading Blocks consist of one or more Trading Components and 523 optionally one or more Signature Components. One or more Trading 524 Blocks may be contained within the IOTP Messages which are 525 physically sent in the form of [XML] documents between the 526 different organizations that are taking part in a trade. 528 1.5.5. Trading Components 529 Trading Components are collections of property values. Trading 530 Components are the child elements of the Trading Blocks. 532 1.5.6. Properties 533 Properties are attributes of a Trading Component. They consist of 534 a name and a value. Properties are strongly typed. Some 535 properties are multi-valued. 537 1.6. Interoperability Model 538 There are two distinct protocols relevant to interoperability: an 539 "Application Protocol" and a "Transport Protocol". The 540 Application Protocol defines the content of the IOTP objects sent 541 between Trading Roles. The Transport Protocol defines how the IOTP 542 objects are sent between the sender and reciver. This document 543 focuses on the Application Protocol. Binding documents such as 544 [IOTP/HTTP] focus on the Transport Protocol. 546 1.7. Document Framework 547 Internet Open Trading Protocol is contained in a series of 548 related documents. This section describes the relationship 549 between the documents. 551 1.7.1. IOTP - Core Object Specification and Transport Independent 552 Trading Protocol 553 The IOTP, this document, is the dictionary Trading Blocks, Trading 554 Components and Transactions for Internet Trading protocol. It provides 555 the authoritative definition of all properties that may be used in 556 the Internet Open Trading protocols as well as the rules for 557 encoding and representing the trading objects that are 558 constructed from those properties. This document also specifies 559 how different systems use Trading Components to interoperate with 560 other systems. It does so in a general way so as to allow 561 multiple methods of communication between systems. 563 1.7.2. IOTP/HTTP: Binding of IOTP to HTTP 564 This document specifies an IOTP protocol over HTTP. 566 1.8. Document Scope 567 The Internet Open Trading Protocol (IOTP) is an application-level 568 protocol to provide an interoperable framework for Internet 569 commerce. The first version of IOTP, referred to as IOTP/1.0, 570 is a simple protocol for exchanging IOTP messages between 571 trading roles participating in e-commerce over the Internet. 573 This specification defines the protocol referred to as 574 "IOTP/1.0". This protocol is designed to be applicable to any 575 electronic payment scheme since it targets the complete purchase 576 process where the movement of electronic value from the payer to 577 the payee is only one, but important, step of many that may be 578 involved to complete the trade. 580 The protocol describes the content, format and sequences of 581 messages that pass among the participants in an electronic trade 582 - consumers, merchants and banks or other financial institutions, 583 and customer care providers. These are required to support the 584 electronic commerce transactions outlined in the objectives 585 above. 587 Payment Scheme which IOTP could support include MasterCard Credit, 588 Visa Credit, Mondex Cash, Visa Cash, GeldKarte, DigiCash, 589 CyberCoin, Millicent, Proton etc. Each payment scheme contains 590 some message flows which are specific to that scheme. These 591 scheme-specific parts of the protocol are contained in a set of 592 payment scheme supplements to this specification. 594 The document does not prescribe the software and processes that 595 will need to be implemented by each participant. It does describe 596 the framework necessary for trading to take place. 598 This document also does not address any legal or regulatory 599 issues surrounding the implementation of the protocol or the 600 information systems which use them. 602 1.9. Requirements 604 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL 605 NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and 606 OPTIONAL in this document are to be interpreted as described in 607 RFC 2119. 609 An implementation is not compliant if it fails to satisfy one or 610 more of the MUST requirements for the protocols it implements. An 611 implementation that satisfies all the MUST and all the SHOULD 612 requirements for its protocols is said to be unconditionally 613 compliant; one that satisfies all the MUST requirements but not 614 all the SHOULD requirements for its protocols is said to be 615 conditionally compliant. 617 2. Internet Open Trading Protocol 618 2.1. Introduction 620 The Internet Open Trading Protocol (IOTP) provides an 621 interoperable framework for Internet commerce. It is payment 622 system independent and encapsulates payment systems such as SET, 623 Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to 624 handle cases where such merchant roles as the shopping site, the 625 payment handler, the Delivery Handler of goods or services, and 626 the provider of customer support are performed by different 627 parties or by one party. 629 The developers of IOTP seek to provide a virtual capability that 630 safely replicates the real world, the paper based, traditional, 631 understood, accepted methods of trading, buying, selling, value 632 exchanging that has existed for many hundreds of years. The 633 negotiation of who will be the parties to the trade, how it will 634 be conducted, the presentment of an offer, the method of payment, 635 the provision of a payment receipt, the delivery of goods and the 636 receipt of goods. These are events that are taken for granted in 637 the course of real world trade. IOTP has been produced to provide 638 the same for the virtual world, and to prepare and provide for 639 the introduction of new models of trading made possible by the 640 expanding presence of the virtual world. 642 The other fundamental ideal of the IOTP effort is to produce a 643 definition of these trading events in such a way that no matter 644 where produced, two unfamiliar parties using electronic commerce 645 capabilities to buy and sell that conform to the IOTP 646 specifications will be able to complete the business safely and 647 successfully. 649 The Internet Open Trading Protocols (IOTP) define a number of 650 different types of IOTP Transactions: 652 - Purchase. This supports a purchase involving an offer, a 653 payment and optionally a delivery 654 - Refund. This supports the refund of a payment as a result 655 of, typically, an earlier purchase 656 - Value Exchange. This involves two payments which result in 657 the exchange of value from one combination of currency and 658 payment method to another 659 - Authentication. This supports the remote authentication of a 660 Consumer by another Trading Role using a variety of 661 authentication methods, and the provision of an Organisation 662 Component about a Consumer to another Trading Role for use 663 in, for example the creation of an offer 664 - Withdrawal. This supports the withdrawal of electronic cash 665 from a financial institution 667 - Deposit. This supports the deposit of electronic cash at a 668 financial institution 669 - Payment Instrument Customer Care. This supports the 670 provision of Payment Brand or Payment Method specific 671 customer care of a Payment Instrument 672 - Inquiry This supports inquiries on the status of an IOTP 673 transaction which is either in progress or is complete 674 - Ping This supports a simple query which enables one IOTP 675 aware application to determine whether another IOTP 676 application running elsewhere is working or not. 678 These IOTP Transactions are "Baseline" transactions since they 679 have been identified as a minimum useful set of transactions. 680 Later versions of IOTP may include additional types of 681 transactions. 683 Each of the IOTP Transactions above involve: 685 - a number organisations playing a Trading Role, and 686 - a set of Trading Exchanges. Each Trading Exchange involves 687 the exchange of data, between Trading Roles, in the form of 688 a set of Trading Components. 690 Trading Roles, Trading Exchanges and Trading Components are 691 described below. 693 2.2. Trading Roles 694 The Trading Roles identify the different parts which 695 organisations can take in a trade. The five Trading Roles used 696 within IOTP are: 698 - Consumer 699 - Merchant 700 - Payment Handler 701 - Delivery Handler 702 - Merchant Customer Care Provider 703 - Payment Instrument Customer Care Provider 705 Roles may be carried out by the same organisation or different 706 organisations. For example: 708 - in the simplest case one physical organisation (e.g. a 709 merchant) could handle the purchase, accept the payment, 710 deliver the goods and provide merchant customer care 711 - at the other extreme, a merchant could handle the purchase 712 but instruct the consumer to pay a bank or financial 713 institution, request that delivery be made by an overnight 714 courier firm and to contact an organisation which provides 715 24x7 service if problems arise. 717 Note that in this specification, unless stated to the contrary, 718 when the words Consumer, Merchant, Payment Handler, Delivery 719 Handler or Customer Care Provider are used, they refer to the 720 Trading Role rather than an actual organisation. 722 An individual organisation may take multiple roles. For example a 723 company which is selling goods and services on the Internet could 724 take the role of Merchant when selling goods or services and the 725 role of Consumer when the company is buying goods or services 726 itself. 728 As roles occur in different places there is a need for the 729 organisations involved in the trade to exchange data, i.e. to 730 carry out Trading Exchanges, so that the trade can be completed. 732 2.3. Trading Exchanges 734 The Internet Open Trading Protocols identify four Trading Exchanges 735 which involve the exchange of data between the Trading Roles. The 736 Trading Exchanges are: 738 - Offer. The Offer Exchange results in the Merchant providing 739 the Consumer with the reason why the trade is taking place. 740 It is called an Offer since the Consumer must accept the 741 Offer if a trade is to continue 742 - Payment. The Payment Exchange results in a payment of some 743 kind between the Consumer and the Payment Handler. This may 744 occur in either direction 745 - Delivery. The Delivery Exchange transmits either the on-line 746 goods, or delivery information about physical goods from the 747 Delivery Handler to the Consumer, and 748 - Authentication. The Authentication Exchange can be used by 749 any Trading Role to authenticate another Trading Role to 750 check that they are who they appear to be. 751 - IOTP Transactions are composed of various combinations of 752 these Trading Exchanges. For example, an IOTP Purchase 753 transaction includes Offer, Payment, and Delivery Trading 754 Exchanges. As another example, an IOTP Value Exchange 755 transaction is composed of an Offer Trading Exchange and two 756 Payment Trading Exchanges. 757 Trading Exchanges consist of Trading Components that are 758 transmitted between the various Trading Roles. Where possible, 759 the number of round-trip delays in an IOTP Transaction is 760 minimised by packing the Components from several Trading 761 Exchanges into combination IOTP Messages. For example, the IOTP 762 Purchase transaction combines a Delivery Organisation Component 763 with an Offer Response Component in order to avoid an extra 764 Consumer request and response. 766 Each of the IOTP Trading Exchanges is described in more detail 767 below. For clarity of description, these describe the Trading 768 Exchanges as though they were standalone operations. For 769 performance reasons, the Trading Exchanges are intermingled in 770 the actual IOTP Transaction definitions. 772 2.4. Offer Exchange 774 The goal of the Offer Exchange is for the Merchant to provide the 775 Consumer with information about the trade so that the Consumer 776 can decide whether to continue with the trade. This is explained 777 through following steps: 779 - Consumer decides to pay (request an offer) and sends 780 information on what to purchase to the merchant 781 - Merchant checks the information provided by the Consumer, 782 creates an Offer and sends it to the Consumer 783 - Consumer checks the information from the merchant and 784 decides whether to continue 786 An Offer Exchange uses the following Trading Components that are 787 passed between the Consumer and the Merchant: 789 - the Organisation Component contains information which 790 describes the organisations which are taking a role in the 791 trade: 792 - the consumer provides information, about who the consumer is 793 and, if goods or services are being delivered, where the 794 goods or services are to be delivered to 795 - the merchant augments this information by providing 796 information about the merchant, the Payment Handler, the 797 customer care provider and, if goods or services are being 798 delivered, the Delivery Handler 799 - the Order Component contains descriptions of the goods or 800 services which will result from the trade if the consumer 801 agrees to the offer. This information is sent by the 802 Merchant to the consumer who should verify it 803 - the Payment Component generated by the Merchant, contains 804 details of how much to pay, the currency and the payment 805 direction, for example the consumer could be asking for a 806 refund. Note that there may be more than one payment in a 807 trade 808 - the Delivery Component, also generated by the Merchant, is 809 used if goods or services are being delivered. This contains 810 information about how delivery will occur, for example by 811 post or using e-mail 812 - the "Offer Response" Signature Component, if present, 813 digitally signs all of the above components to ensure their 814 integrity. 816 The exact content of the information provided by the Merchant to 817 the Consumer will vary depending on the type of IOTP Transaction. 818 For example: 820 - low value purchases may not need a signature 821 - the amount to be paid may vary depending on the payment 822 brand and payment protocol used 823 - some offers may not involve the delivery of any goods 824 - a value exchange will involve two payments 825 - a merchant may not offer customer care. 827 Information provided by the consumer to the merchant could be 828 provided using a variety of methods, for example, it could be 829 provided: 831 - using [HTML] pages as part of the "shopping experience" of 832 the consumer. 833 - using the Open Profiling Standard [OPS] which has recently 834 been proposed, in the form of Organisation and Order 835 Components in a later version of IOTP. 837 2.5. Payment Exchange 839 The goal of the Payment Exchange is for a payment to be made from 840 the Consumer to a Payment Handler or vice versa using a payment 841 brand and payment protocol selected by the Consumer. A secondary 842 goal is to optionally provide the Consumer with a digitally 843 signed Payment Receipt which can be used to link the payment to 844 the reason for the payment as described in the Offer Exchange. 846 Payment Exchanges can work in a variety of ways. The most general 847 case where the trade is dependent on the payment brand and 848 protocol used is illustrated in the diagram below. Simpler 849 payment exchanges are possible. 851 - Consumer decides to trade and sends information on what to 852 purchase to the merchant 853 - Merchant decides which payment brand and payment protocols 854 to offer, places them in a Brand List Component and sends 855 them to the Consumer 856 - Consumer selects the payment brand and protocol to use, 857 creates a Brand Selection Component and sends it to the 858 Merchant 859 - Merchant checks Brand Selection, creates Payment Amount 860 information, optionally signs it to authorize payment and 861 sends it to the Consumer 862 - Consumer checks the Payment Amount information and if OK 863 requests that the payment starts by sending information to 864 the Payment Handler 865 - Payment Handler checks information including optional 866 signature and if OK starts exchanging Pay Scheme Component 867 using messages for selected payment brand and payment 868 protocol 869 - When payment protocol messages are finished Payment Hander 870 sends Pay Receipt and optional signature to Consumer as 871 proof of payment 872 - Consumer checks if Pay Receipt is OK 874 A Payment Exchange uses the following Trading Components that are 875 passed between the Consumer, the Merchant and the Payment 876 Handler: 878 - The Brand List Component contains a list of payment brands 879 (for example, MasterCard, Visa, Mondex, GeldKarte) and 880 payment protocols (for example SET Version 1.0, Secure 881 Channel Credit Debit (SCCD - the name used for a credit or 882 debit card payment where unauthorised access to account 883 information is prevented through use of secure channel 884 transport mechanisms such as SSL). The Merchant sends the 885 Brand List to the Consumer. The consumer compares the 886 payment brands and protocols on offer with those that the 887 Consumer supports and makes a selection. 888 - The Brand Selection Component contains the Consumer's 889 selection. Payment brand, protocol and possibly protocol- 890 specific information is sent back to the Merchant. This 891 information may be used to change information in the Offer 892 Exchange. For example, a merchant could choose to offer a 893 discount to encourage the use of a store card. 894 - The Organisation Components are generated by the Merchant. 895 They contain details of the Merchant and Payment Handler 896 Roles: 898 o the Merchant role is required so that the Payment Handler 899 can identify which Merchant initiated the payment. 900 Typically, the result of the Payment Handler accepting 901 (or making) a payment on behalf of the Merchant will be a 902 credit or debit transaction to the Merchant's account 903 held by the Payment Handler. These transactions are 904 outside the scope of IOTP 906 o the Payment Handler role is required so that the Payment 907 Handler can check that it is the correct Payment Handler 908 to be used for the payment 910 - The optional Authentication Data Component contains 911 challenge data which is used by the payment protocol to 912 authenticate the consumer. Authentication may not always 913 occur 914 - The Payment Component contains details of how much to pay, 915 the currency and the payment direction, and identifies the 916 Authentication Data Component to use. 917 - The "Offer Response" Signature Component, if present, 918 digitally signs all of the above components to ensure their 919 integrity. Note that the Brand List and Brand Selection 920 Components are not signed until the payment information is 921 created. 922 - The Payment Scheme Component contains messages from the 923 payment protocol used in the Trade. For example they could 924 be SET messages, Mondex messages, GeldKarte Messages or one 925 of the other payment methods supported by IOTP. The content 926 of the Payment Scheme Component is defined in the 927 supplements that describe how IOTP works with various payment 928 protocols. 929 - The Payment Receipt Component contains a record of the 930 payment. The content depends upon the payment protocol used. 931 - The "Payment Receipt" Signature Component provides proof of 932 payment by digitally signing both the Payment Receipt 933 Component and the Offer Signature. The signature on the 934 offer digitally signs the Order, Organisation and Delivery 935 Components contained in the Offer. This signature 936 effectively binds the payment to the offer. 937 The example of a Payment Exchange above is the most general case. 938 Simpler cases are also possible. For example, if the amount paid 939 is not dependent on the payment brand and protocol selected then 940 the payment information generated can be sent to the Consumer at 941 the same time as the Brand List Component generated. These and 942 other variations are described in the Baseline Purchase IOTP 943 Transaction (see section 5.20). 945 2.6. Delivery Exchange 947 The goal of the Delivery Exchange is to cause purchased goods to 948 be delivered to the consumer either online or via physical 949 delivery. A second goal is to provide a "delivery note" to the 950 consumer, providing details about the delivery, such as shipping 951 tracking number. A future goal is to have a signed delivery that 952 can be used for customer care in the case of problems with 953 physical delivery. This is illustrated in the diagram below. 955 - Consumer decides to trade and sends information about what 956 to deliver and who is to take delivery, to the merchant 957 - Merchant checks the information provided by the Consumer, 958 adds information about how the delivery will occur, 959 information about the organizations involved in the delivery 960 and optionally signs it 961 - Consumer checks the delivery information is OK, obtains 962 authorization for delivery(for example, by making a 963 payment), and sends the delivery information to the Delivery 964 Handler 965 - Delivery Handler checks information and authorization, 966 starts or schedule delivery and creates and then sends 967 Delievery Note to the Consumer 968 - Consumer checks delivery note is OK and accepts or waits for 969 delivery as described in the Delivery Note 971 A Delivery Exchange uses the following Trading Components that 972 are passed between the Consumer, the Merchant and the Delivery 973 Handler: 975 The Organisation Component(s) contain details of the Deliver 976 To, Delivery Handler and Merchant Roles: 977 - the Deliver To role indicates where the goods or services 978 are to be delivered to 979 - the Delivery Handler role is required so that the Delivery 980 Handler can check that she is the correct Delivery Handler 981 to do the delivery 982 - the Merchant role is required so that the Delivery Handler 983 can identify which Merchant initiated the delivery 984 - The Order Component, contains information about the goods or 985 services to be delivered 986 - The Delivery Component contains information about how 987 delivery will occur, for example by post or using e-mail. 988 - The "Offer Response" Signature Component, if present, 989 digitally signs all of the above components to ensure their 990 integrity. 991 - The " Payment Receipt" Signature Component provides proof of 992 payment by digitally signing the Payment Receipt Component 993 and the Offer Signature. This is used by the Delivery 994 Handler to check that delivery is authorised 995 - The Delivery Note Component contains customer care 996 information related to a physical delivery, or alternatively 997 the actual "electronic goods". The Consumer's software does 998 not interpret information about a physical delivery but 999 should have the ability to display the information, both at 1000 the time of the delivery and later if the Consumer selects 1001 the Trade to which this delivery relates from a transaction 1002 list. 1004 2.7. Authentication Exchange 1006 The goal of the Authentication Exchange is to allow one 1007 organisation, for example a financial institution, to be able to 1008 check that another organisation, for example a consumer, is who 1009 they appear to be. It uses a "challenge-response" mechanism. This 1010 is illustrated in the diagram below. 1012 - First organization send a request for authentication to the 1013 second organization 1014 - The Second organization generates Authentication Data 1015 containing challenge data and the method of authentication 1016 to be used and then sends it to the first organization 1017 - The first organization uses the challenge data with the 1018 specified authentication method to generate an 1019 Authentication Response which is sent back to the second 1020 organization 1021 - The Authentication Response is checked against the challenge 1022 data to check that the first organization is who they appear 1023 to be. 1025 An Authentication Exchange uses the following Trading Components 1026 that are passed between the two organisations: 1028 - the Authentication Data Component which contains the 1029 challenge data to be used in the "challenge-response" 1030 mechanism and indicates the authentication method to be 1031 used. It is sent by one organisation to the other. 1032 - the Authentication Response Component which contains the 1033 challenge response generated by the recipient of the 1034 Authentication Data Component. It is sent back to the first 1035 organisation for verification. 1037 2.8. Brands and Brand Selection 1039 One of the key features of IOTP is the ability for a merchant to 1040 offer a list of Brands from which a consumer may make a 1041 selection. This section provides an overview of what is involved 1042 and provides guidance on how selection of a brand and associated 1043 payment instrument can be carried out by a Consumer. It covers: 1045 definitions of Payment Instruments and Brands - what are 1046 Payment Instruments and Brands in an IOTP context. Further 1047 categorises Brands as optionally a "Dual Brand" or a 1048 "Promotional Brand", 1050 identification and selection of Promotional Brands - 1051 Promotional Brands offer a Consumer some additional benefit, 1052 for example loyalty points or a discount. This means that 1053 both Consumers and Merchant must be able to correctly 1054 identify that a valid Promotional Brand is being used. 1055 Also see the following sections: 1057 Brand List Component (section 6.12) which contains 1058 definitions of the XML elements which contain the list of 1059 Brands offered by a Merchant to a Consumer, and 1061 Brand Selection Component (section 6.17) for details of how 1062 a Consumer records the Brand that was selected. 1064 2.8.1. Identifying Promotional Brands 1066 There are two problems which need to handled in identifying 1067 Promotional Brands: 1069 - how does the Merchant or their Payment Handler positively 1070 identify the promotional brand being used at the time of 1071 purchase 1072 - how does the Consumer reliably identify the correct 1073 promotional brand from the Brand List presented by the 1074 Merchant 1075 The following is a description of how this could be achieved. 1077 2.8.2. Merchant/Payment Handler Identification of Promotional 1078 Brands 1080 Correct identification that the Consumer is paying using a 1081 Promotional Brand is important since a Consumer might 1082 fraudulently claim to have a Promotional Brand that offers a 1083 reduced payment amount when in reality they do not. 1085 Two approaches seem possible: 1087 - use some feature of the Payment Instrument or the payment 1088 method to positively identify the Brand being used. For 1089 example, the SET certificate for the Brand could be used, if 1090 one is available, or 1091 - use the Payment Instrument (card) number to look up 1092 information about the Payment Instrument on a Payment 1093 Instrument issuer database to determine if the Payment 1094 Instrument is a promotional brand 1095 Note that: 1097 - the first assumes that SET is available. 1098 - the second is only possible if the Merchant, or 1099 alternatively the Payment Handler, has access to card issuer 1100 information. 1102 IOTP does not provide the Merchant with Payment Instrument 1103 information (e.g. a card or account number). This is only sent as 1104 part of the encapsulated payment protocol to a Payment Handler. 1105 This means that: 1107 - the Merchant would have to assume that the Payment 1108 Instrument selected was a valid Promotional Brand, or 1109 - the Payment Handler would have to check that the Payment 1110 Instrument was for the valid Promotional Brand and fail the 1111 payment if it was not. 1112 A Payment Handler checking that a brand is a valid Promotional 1113 Brand is most likely if the Payment Handler is also the Card 1114 Issuer. 1116 2.8.3. Consumer Selection of Promotional Brands 1117 Two ways by which a Consumer can correctly select a Promotional 1118 Brand are: 1120 - the Consumer visually matching a logo for the Promotional 1121 Brand which has been provided to the Consumer by the 1122 Merchant, 1123 - the Consumer's IOTP aware application matching a code for the 1124 Promotional Brand which the application has registered 1125 against a similar code contained in the list of Brands 1126 offered by the Merchant. 1127 In the latter case, the code contained in the Consumer wallet 1128 must match exactly the code in the list offered by the Merchant 1129 otherwise no match will be found. Ways in which the Consumer's 1130 IOTP Aware Application could obtain such a code include: 1132 - the Consumer types the code in directly. This is error prone 1133 and not user friendly, also the consumer needs to be 1134 provided with the code. This approach is not recommended, 1135 - using some information contained in the software or other 1136 data associated with the Payment Instrument. This could be: 1138 o a SET certificate for Brands which use this payment 1139 method 1141 o a code provided by the payment software which handles the 1142 particular payment method, this could apply to, for 1143 example, GeldKarte, Mondex, CyberCash and DigiCash 1145 - the consumer making a initial "manual" link between a 1146 Promotional Brand in the list of Brands offered by the 1147 Merchant and an individual Payment Instrument, the first 1148 time the promotional brand is used. The IOTP Aware 1149 application would then "remember" the code for the 1150 Promotional Brand for use in future purchases 1152 Note: It is not the intention of the developers of this 1153 specification to develop a prescriptive list of payment brands. 1155 It is anticipated that owners of brands will develop distinctive 1156 names for Brands which should mean that name clashes are 1157 unlikely. 1159 3. IOTP Elements 1161 This section describes: 1163 - how Trading Components are constructed into Trading Blocks 1164 and the IOTP Messages which are physically sent in the form 1165 of [XML] documents between the different Trading Roles, 1166 - how IOTP Messages are exchanged between Trading Roles to 1167 create an IOTP Transaction 1168 - the XML definitions of an IOTP Message including a 1169 Transaction Reference Block - an XML element which 1170 identifies an IOTP Transaction and the IOTP Message within it 1171 - the definitions of the XML ID Attributes which are used to 1172 identify IOTP Messages, Trading Blocks and Trading Components 1173 and how these are referred to using Element References from 1174 other XML elements such as 1175 - IOTP Signature Components which use digital signature 1176 techniques to preserve the integrity of IOTP Messages and 1177 provide the trust relationships required by IOTP 1178 - how extra XML Elements and new user defined values for 1179 existing IOTP codes can be used when Extending IOTP, and 1180 finally 1182 3.1. IOTP Message Structure 1184 The structure of an IOTP Message and its relationship with Trading 1185 Blocks and Trading Components is illustrated in the diagram 1186 below. 1188 IOTP Message 1189 | 1190 | 1191 +--------- Trans Ref Block 1192 | | 1193 | +- Tran Id Comp 1194 | +- Msg Id Comp 1195 | . 1196 +--------- Signature Block 1197 | +- Signature 1198 | +- Certificate 1199 | . 1200 | . 1201 +--------- Trading Block 1202 | +- Component 1203 | +- Component 1204 | . 1205 | . 1206 +--------- Trading Block 1207 | +- Component 1208 | +- Component 1209 . . 1210 . . 1211 . . 1213 IOTP Message Structure 1215 IOTP Message is an XML document which is transported between the 1216 trading roles. 1218 Transaction Reference Block describes the IOTP transaction and IOTP 1219 message. 1221 Transaction Id Component uniquely identifies the IOTP transaction 1223 Message Id Component identifies and describes an IOTP message 1224 within an IOTP transaction 1226 Signature Block is optional and if present it contains one or 1227 more Signature Components and their associated certificates 1229 Trading Block is an XML element within an IOTP message that 1230 contains a predefined set of Trading Components 1231 Trading Components are XML elements within an IOTP message and 1232 contains a predefined set of XML elements and attributes 1233 containing information required to support trading exchange. 1235 The diagram also introduces the concept of a Transaction 1236 Reference Block. This block contains, amongst other things, a 1237 globally unique identifier for the IOTP Transaction. Also each 1238 block and component is given an ID Attribute (see section 3.6) 1239 which is unique within an IOTP Transaction. Therefore the 1240 combination of the ID attribute and the globally unique 1241 identifier in the Transaction Reference Block is sufficient to 1242 uniquely identify any Trading Block or Trading Component. 1244 3.2. IOTP Transactions 1246 A predefined set of IOTP Messages exchanged between the Trading 1247 Roles constitute an IOTP Transaction. IOTP Messages can be 1248 transported using a variety of transport mechanisms. 1250 The IOTP Transactions in this version of IOTP are specifically: 1252 Purchase. This supports a purchase involving an offer, a 1253 payment and optionally a delivery 1255 Refund. This supports the refund of a payment as a result of, 1256 typically, an earlier purchase 1258 Value Exchange. This involves two payments which result in the 1259 exchange of value from one combination of currency and 1260 payment method to another 1262 Authentication. This supports the remote authentication of a 1263 Consumer by another Trading Role using a variety of 1264 authentication methods, and the provision of an Organisation 1265 Component about a Consumer to another Trading Role for use 1266 in, for example the creation of an offer 1268 Withdrawal. This supports the withdrawal of electronic cash 1269 from a financial institution 1271 Deposit. This supports the deposit of electronic cash at a 1272 financial institution 1274 Payment Instrument Customer Care. This supports the provision 1275 of Payment Brand or Payment Method specific customer care of 1276 a Payment Instrument 1278 Inquiry This supports inquiries on the status of an IOTP 1279 transaction which is either in progress or is complete 1281 Ping This supports a simple query which enables one IOTP aware 1282 application to determine whether another IOTP application 1283 running elsewhere is working or not. 1285 3.3. IOTP Message 1287 As described earlier, IOTP Messages are [XML] documents which are 1288 physically sent between the different organisations that are 1289 taking part in a trade. 1291 The XML definition of an IOTP Message is as follows. 1293 1314 Content: 1316 TransRefBlk This contains information which describes an 1317 IOTP Message within an IOTP Transaction (see 1318 section 3.5 immediately below) 1320 AuthReqBlk, AuthRespBlk, DeliveryReqBlk, DeliveryRespBlk, ErrorBlk 1321 InquiryReqBlk, InquiryRespBlk, OfferRespBlk, PayExchBlk, PayReqBlk, 1322 PayInstCCExchBlk, PayInstCCReqBlk, PayInstCCRespBlk PayRespBlk, 1323 PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk 1325 3.4. XML Document Prolog 1327 The IOTP Message is the root element of the XML document. It 1328 therefore needs to be preceded by an appropriate XML Document 1329 Prolog. For example: 1331 1332 1333 1334 ... 1335 1337 3.5. Transaction Reference Block 1339 A Transaction Reference Block contains information which 1340 identifies the IOTP Transaction and IOTP Message. The Transaction 1341 Reference Block contains: 1343 - a Transaction Id Component which globally uniquely 1344 identifies the IOTP Transaction. The Transaction Id 1345 Components are the same across all IOTP messages that 1346 comprise a single IOTP transaction, 1347 - a Message Id Component which provides control information 1348 about the IOTP Message as well as uniquely identifying the 1349 IOTP Message within an IOTP Transaction, and 1350 - zero or more Related To Components which link this IOTP 1351 Transaction to either other IOTP Transactions or other events 1352 using the identifiers of those events. 1353 The definition of a Transaction Reference Block is as follows: 1355 1356 1359 Attributes: 1361 ID An identifier which uniquely identifies the 1362 Transaction Reference Block within the IOTP 1363 Transaction (see section 3.6 ID Attributes). 1365 Content: 1367 TransId See 3.5.1 Transaction Id Component 1368 immediately below. 1370 MsgId See 3.5.2 Message Id Component immediately 1371 below. 1373 RelatedTo See 3.5.3 Related To Component immediately 1374 below. 1376 3.5.1. Transaction Id Component 1378 This contains information which globally uniquely identifies the 1379 IOTP Transaction. Its definition is as follows: 1381 1382 1387 TransTimeStamp CDATA #REQUIRED > 1389 Attributes: 1391 ID An identifier which uniquely identifies the 1392 Transaction Id Component within the IOTP 1393 Transaction. 1395 Version This identifies the version of IOTP, and 1396 therefore the structure of the IOTP Messages, 1397 which the IOTP Transaction is using. 1399 OtpTransId Contains data which uniquely identifies the 1400 IOTP Transaction. It must conform to the 1401 rules for Message Ids in [RFC 822]. 1403 OtpTransType This is the type of IOTP Transaction being 1404 carried out. For Baseline IOTP it identifies 1405 a "standard" IOTP Transaction and implies the 1406 sequence and content of the IOTP Messages 1407 exchanged between the Trading Roles. The 1408 valid values for Baseline IOTP are: 1410 BaselineAuthentication 1411 BaselineDeposit 1412 BaselinePurchase 1413 BaselineRefund 1414 BaselineWithdrawal 1415 BaselineValueExchange 1416 BaselineInquiry 1417 BaselinePing 1418 BaselinePayInstrumentCustomerCare 1419 x-ddd:nnn 1421 A value for OtpTransType of x-ddd:nnn 1422 indicates a user defined transaction type. 1423 See section 3.9.3 User Defined Codes. 1425 In later versions of IOTP, this list will be 1426 extended to support different types of 1427 standard IOTP Transaction based on market 1428 demand. It is also likely to support the 1429 type Dynamic which indicates that the 1430 sequence of steps within the transaction are 1431 non-standard. 1433 TransTimeStamp Where the system initiating the IOTP 1434 Transaction has an internal clock, it is set 1435 to the time at which the IOTP Transaction 1436 started in [UTC] format. 1438 The main purpose of this attribute is to 1439 provide an alternative way of identifying a 1440 transaction by specifying the time at which 1441 it started. 1443 Some systems, for example, hand held devices 1444 may not be able to generate a time stamp. 1445 In this case this attribute should contain 1446 the value "NA" for Not Available. 1448 3.5.2. Message Id Component 1450 The Message Id Component provides control information about the 1451 IOTP Message as well as uniquely identifying the IOTP Message 1452 within an IOTP Transaction. Its definition is as follows. 1454 1455 1461 Attributes: 1463 ID An identifier which uniquely identifies the 1464 IOTP Message within the IOTP Transaction (see 1465 section 3.6 ID Attributes). Note that if an 1466 IOTP Message is resent then the value of this 1467 attribute remains the same. 1469 RespOtpMsg This contains the ID attribute of the 1470 Message Id Component of the IOTP Message to 1471 which this IOTP Message is a response. In 1472 this way all the IOTP Messages in an IOTP 1473 Transaction are unambiguously linked 1474 together. This field is required on every 1475 IOTP Message except the first IOTP Message in 1476 an IOTP Transaction. 1478 xml:lang Defines the language used by attributes or 1479 child elements within this component, unless 1480 overridden by an xml:lang attribute on a 1481 child element. See section 3.10 Identifying 1482 Languages. 1484 SoftwareId This contains information which identifies 1485 the software which generated the IOTP 1486 Message. Its purpose is to help resolve 1487 interoperability problems that might occur 1488 as a result of incompatibilities between 1489 messages produced by different software. It 1490 is a single text string in the language 1491 defined by xml:lang. It MUST contain, as a 1492 minimum: 1494 the name of the software manufacturer 1495 the name of the software 1496 the version of the software, and 1497 the build of the software 1499 TimeStamp Where the device sending the message has an 1500 internal clock, it is set to the time at 1501 which the IOTP Message was created in [UTC] 1502 format. 1504 3.5.3. Related To Component 1506 The Related To Component links IOTP Transactions to either other 1507 IOTP Transactions or other events using the identifiers of those 1508 events. Its definition is as follows. 1510 1511 1518 Attributes: 1520 ID An identifier which uniquely identifies the 1521 Related To Component within the IOTP 1522 Transaction. 1524 xml:lang Defines the language used by attributes or 1525 child elements within this component, unless 1526 overridden by an xml:lang attribute on a 1527 child element. See section 3.10 Identifying 1528 Languages. 1530 RelationshipType Defines the type of the relationship. Valid 1531 values are: 1533 OtpTransaction. in which case the Packaged 1534 Content Element contains an OtpTransId of 1535 another IOTP Transaction 1536 Reference in which case the Packaged Content 1537 Element contains the reference of some 1538 other, non-IOTP document. 1539 x-ddd:nnn a user defined code (see section 1540 3.9.3) 1542 Relation The Relation attribute contains a phrase in 1543 the language defined by xml:lang which 1544 describes the nature of the relationship 1545 between the IOTP transaction that contains 1546 this component and another IOTP Transaction 1547 or other event. The exact words to be used 1548 are left to the implementer of the IOTP 1549 software. 1551 The purpose of the attribute is to provide 1552 the Trading Roles involved in an IOTP 1553 Transaction with an explanation of the 1554 nature of the relationship between the 1555 transactions. 1557 Care should be taken that the words used to 1558 in the Relation attribute indicate the 1559 "direction" of the relationship correctly. 1560 For example: one transaction might be a 1561 refund for another earlier transaction. In 1562 this case the transaction which is a refund 1563 should contain in the Relation attribute 1564 words such as "refund for" rather than 1565 "refund to" or just "refund". 1567 RelnKeyWords This attribute contains keywords which could 1568 be used to help identify similar 1569 relationships, for example all refunds. It 1570 is anticipated that recommended keywords 1571 will be developed through examination of 1572 actual usage. In this version of the 1573 specification there are no specific 1574 recommendations and the keywords used are at 1575 the discretion of the implementer. 1577 Content: 1579 PackagedContent The Packaged Content (see section 3.8) 1580 contains data which identifies the related 1581 transaction. Its format varies depending on 1582 the value of the RelationshipType. 1584 3.6. ID Attributes 1586 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and 1587 Trading Blocks) and Trading Components (including the Transaction 1588 Id Component and the Signature Component) are each given an XML 1589 "ID" attribute which is used to identify an instance of these XML 1590 elements. These identifiers are used so that one element can be 1591 referenced by another. All these attributes are given the 1592 attribute name ID. 1594 The values of each ID attribute are unique within an IOTP 1595 transaction i.e. the set of IOTP Messages which have the same 1596 globally unique Transaction ID Component. This means that it is 1597 possible to use these IDs to refer to and locate the content of 1598 any IOTP Message, Block or Component from any other IOTP Message, 1599 Block or Component in the same IOTP Transaction using Element 1600 References (see section 3.7). 1602 This section defines the rules for setting the values for the ID 1603 attributes of IOTP Messages Blocks and Components. 1605 3.6.1. IOTP Message ID Attribute Definition 1607 The ID attribute of the Message Id Component of an IOTP Message 1608 must be unique within an IOTP Transaction. It's definition is as 1609 follows: 1611 OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix 1612 OtpMsgIdPrefix ::= NameChar (NameChar)* 1613 OtpMsgIdSuffix ::= Digit (Digit)* 1615 OtpMsgIdPrefix Apart from messages which contain an Inquiry 1616 Request Trading Block (see section 4.14), the 1617 same prefix is used for all messages sent by 1618 the Merchant or Consumer role as follows: 1620 "M" Merchant 1621 "C" Consumer 1623 For messages which contain an Inquiry Request 1624 Trading Block, the prefix is set to "I" for 1625 Inquiry. 1627 The prefix for the other roles in a trade is 1628 contained within the Organisation Component 1629 for the role and are typically set by the 1630 Merchant. The following is recommended as a 1631 guideline and must not be relied upon: 1633 "P" - First (only) Payment Handler 1634 "R" - Second Payment Handler 1635 "D" - Delivery Handler 1637 As a guideline, prefixes should be limited to 1638 one character. 1640 NameChar has the same definition as the [XML] 1641 definition of NameChar. 1643 OtpMsgIdSuffix The suffix consists of one or more digits. The 1644 suffix must be unique within a Trading Role 1645 within an IOTP Transaction. The following is 1646 recommended as a guideline and must not be 1647 relied upon: 1649 the first IOTP Message sent by a trading role 1650 is given the suffix "1" 1651 the second and subsequent IOTP Messages sent by 1652 the same trading role are incremented by one 1653 for each message 1654 no leading zeroes are included in the suffix 1656 Put more simply the Message Id Component of 1657 the first IOTP Message sent by a Consumer would 1658 have an ID attribute of, "C1", the second 1659 "C2", the third "C3" etc. 1661 Digit has the same definition as the [XML] 1662 definition of Digit. 1664 3.6.2. Block and Component ID Attribute Definitions 1666 The ID Attribute of Blocks and Components must also be unique 1667 within an IOTP Transaction. Their definition is as follows: 1669 BlkOrCompId_value ::= OtpMsgId "." IdSuffix 1670 IdSuffix ::= Digit (Digit)* 1672 OtpMsgId The ID attribute of the Message ID Component 1673 of the IOTP Message where the Block or 1674 Component is first used. 1676 In IOTP, Trading Components and Trading 1677 Blocks are copied from one IOTP Message to 1678 another. The ID attribute does not change 1679 when an existing Trading Block or Component 1680 is copied to another IOTP Message. 1682 IdSuffix The suffix consists of one or more digits. 1683 The suffix must be unique within the ID 1684 attribute of the Message ID Component used 1685 to generate the ID attribute. The following 1686 is recommended as a guideline and must not 1687 be relied upon: 1689 the first Block or Component sent by a 1690 trading role is given the suffix "1" 1691 the ID attributes of the second and 1692 subsequent Blocks or Components are 1693 incremented by one for each new Block or 1694 Component added to an IOTP Message 1695 no leading zeroes are included in the suffix 1697 Put more simply, the first new Block or 1698 Component added to the second IOTP Message 1699 sent, for example, by a consumer would have 1700 a an ID attribute of "C2.1", the second 1701 "C2.2", the third "C2.3" etc. 1703 Digit has the same definition as the [XML] 1704 definition of Digit. 1706 3.7. Element References 1708 A Trading Component or one of its child XML elements, may contain 1709 an XML attribute that refers to another Block (i.e. a Transaction 1710 Reference Block or a Trading Block) or Trading Component 1711 (including a Transaction Id and Signature Component). These 1712 Element References are used for many purposes, a few examples 1713 include: 1715 - identifying an XML element whose hash value is included in a 1716 Signature Component, 1717 - referring to the Payment Handler Organisation Component 1718 which is used when making a Payment 1720 An Element Reference always contains the value of an ID attribute 1721 of a Block or Component. 1723 - Identifying the IOTP Message, Trading Block or Trading 1724 Component which is referred to by an Element Reference, 1725 involves finding the XML element which: 1726 - belongs to the same IOTP Transaction (i.e. the Transaction Id 1727 Components of the IOTP Messages match), and 1728 - where the value of the ID attribute of the element matches 1729 the value of the Element Reference. 1731 3.8. Packaged Content Element 1733 The Packaged Content element supports the concept of an embedded 1734 data stream, transformed to both protect it against 1735 misinterpretation by transporting systems and to ensure XML 1736 compatibility. Examples of its use in IOTP include: 1738 - to encapsulate payment scheme messages, such as SET 1739 messages, 1740 - to encapsulate a description of an order. 1742 In general it is used to encapsulate any data stream. 1744 This data stream has two standardised attributes that allow for 1745 decoding and interpretation of the contents. Its definition is as 1746 follows. 1748 1749 1753 Attributes: 1755 Content This identifies what type of data is 1756 contained within the Content of the Packaged 1757 Content Element. The valid values for the 1758 Content attribute are as follows: 1760 PCDATA.The content of the Packaged Content 1761 Element can be treated as PCDATA with no 1762 further processing. 1763 MIME. The content of the Packaged Content 1764 Element is a complete MIME item. Processing 1765 should include looking for MIME headers 1766 inside the Packaged Content Element. 1767 MIME:mimetype. The content of the Packaged 1768 Content Element is MIME content, with the 1769 following header "Content-Type: mimetype". 1770 Although it is possible to have 1771 MIME:mimetype with the Transform attribute 1772 set to NONE, it is far more likely to have 1773 Transform attribute set to BASE64. Note that 1774 if Transform is NONE is used, then the 1775 entire content must still conform to PCDATA. 1776 Some characters will need to be encoded 1777 either as the XML default entities, or as 1778 numeric character entities. 1779 XML. The content of the Packaged Content 1780 Element can be treated as an XML document. 1781 Entities and CDATA sections, or Transform 1782 set to BASE64, must be used to ensure that 1783 the Packaged Content Element contents are 1784 legitimate PCDATA. 1785 x-ddd:usercode. The content is private, 1786 where ddd represents a domain name of a 1787 user, and usercode represents a particular 1788 content format defined by that user. The 1789 guidelines around a x-ddd are very loose. 1790 Given company FFGGHH Inc., all of 1791 x-www.ffgghh.com, x-ffgghh.comand and 1792 x-ffgghh are legitimate examples. However, 1793 only one should be the correct format, as 1794 defined by FFGGHH Inc. 1796 Transform This identifies the transformation that has 1797 been done to the data before it was placed 1798 in the content. Valid values are: 1800 NONE. The PCDATA content of the Packaged 1801 Content Element is the correct 1802 representation of the data. Note that entity 1803 expansion must occur first (i.e. replacement 1804 of & and ) before the data is 1805 examined. CDATA sections may legitimately 1806 occur in a Packaged Content Element where 1807 the Transform attribute is set to NONE. 1808 BASE64. The PCDATA content of the Packaged 1809 Content Element represents a BASE64 encoding 1810 of the actual content. 1811 Content: 1813 PCDATA This is the actual data which has been 1814 embedded. The format of the data and rules 1815 on how to decode it are contained in the 1816 Content and the Transform attributes 1818 Note that any special details, especially custom attributes, must 1819 be represented at a higher level. 1821 3.9. Extending IOTP 1823 Baseline IOTP defines a minimum protocol which systems supporting 1824 IOTP must be able to accept. As new versions of IOTP are developed, 1825 additional types of IOTP Transactions will be defined. In addition 1826 to this, Baseline and future versions of IOTP will support user 1827 extensions to IOTP through two mechanisms: 1829 o extra XML elements, and 1831 o new user-defined values for existing IOTP codes. 1833 3.9.1. Extra XML Elements 1835 The XML element and attribute names used within IOTP constitute an 1836 [XML Namespace]. This allows IOTP to support the inclusion of 1837 additional XML elements within IOTP messages through the use of 1838 [XML Namespaces]. 1840 Extra XML elements may be included at any level within an IOTP 1841 message including: 1843 - new Trading Blocks 1844 - new Trading Components 1845 - new XML elements within a Trading Component. 1847 The following rules apply: 1849 - any new XML element must be declared according to the rules 1850 for [XML Namespaces]. This means that: 1852 o the namespace must be declared to the XML parser 1854 o each element must have a start and end tags which conform 1855 to the rules for XML Namespaces 1857 - new XML elements which are either Trading Blocks or Trading 1858 Components MUST contain an ID attributes with an attribute 1859 name of ID. 1861 In order to make sure that extra XML elements can be processed 1862 properly, IOTP reserves the use of a special attribute, 1863 Otp:Critical, which takes the values True or False and may appear 1864 in extra elements added to an IOTP message. 1866 The purpose of this attribute is to allow an IOTP aware 1867 application to determine if the IOTP transaction can safely 1868 continue. Specifically: 1870 - if an extra XML element has an "Otp:Critical" attribute with 1871 a value of "True" and an IOTP aware application does not know 1872 how to process the element and its child elements, then the 1873 IOTP transaction must fail. See section 6.34 Error Component. 1874 - if an extra XML element has an "Otp:Critical" attribute with 1875 a value of "False" then the IOTP transaction may continue if 1876 the IOTP aware application does not know how to process it. 1877 In this case: 1879 o any extra XML elements contained within an XML element 1880 defined within the IOTP namespace, must be included with 1881 that element whenever the IOTP XML element is used or 1882 copied by IOTP 1884 o the content of the extra element must be ignored except 1885 that it must be included when it is hashed as part of the 1886 generation of a signature 1888 - if an extra XML element has no "Otp:Critical" attribute then 1889 it must be treated as if it had an "Otp:Critical" attribute 1890 with a value of "True" 1891 - if an XML element contains an "Otp:Critical" attribute, then 1892 the value of that attribute is assumed to apply to all the 1893 child elements within that element 1895 In order to ensure that documents containing "Otp:Critical" are 1896 valid, it is declared as part of the DTD for the extra element 1897 as: 1899 Otp:Critical(True | False ) #IMPLIED 1901 3.9.2. Opaque Embedded Data 1903 If IOTP is to be extended using Opaque Embedded Data then a 1904 Packaged Content Element (see section 3.8) should be used to 1905 encapsulate the data. 1907 3.9.3. User Defined Codes 1909 User defined codes provide a simple way to identify additional 1910 values for the codes contained within this specification. 1912 The definition of a user defined code is as follows: 1914 user_defined_code ::= ( "x-" | "X-" ) domain_name ":" 1915 name 1917 domain_name A name which identifies the organisation which is 1918 creating the user defined code (see [DNS]). The 1919 purpose of this field is to reduce the 1920 probability of two organisations creating the 1921 same user-defined name 1923 name A name specified by the organisation which owns 1924 the domain_name which identifies the user defined 1925 code within the domain_name. 1927 User defined codes are identified in this specification as "x- 1928 ddd:nnn". The values of User Defined Codes must conform to the 1929 rules for the specific code (see explanations of the individual 1930 codes). 1932 3.10. Identifying Languages 1934 IOTP uses [XML] Language Identification to specify which languages 1935 are used within the content and attributes of IOTP Messages. 1937 The following principles have been used in order to determine 1938 which XML elements contain an xml:lang Attributes: 1940 - a mandatory xml:lang attribute is contained on every Trading 1941 Component which contains attributes or content which may 1942 need to be displayed or printed in a particular language 1943 - an optional xml:lang attribute is included on child elements 1944 of these Trading Components. In this case the value of 1945 xml:lang, if present, overrides the value for the Trading 1946 Component. 1948 xml:lang attributes which follow these principles are included in 1949 the Trading Components and their child XML elements defined in 1950 section 6. 1952 3.11. Secure and Insecure Net Locations 1953 IOTP contains several "Net Locations" which identify places where, 1954 typically, IOTP Messages may be sent. Net Locations come in two 1955 types: 1957 - "Secure" Net Locations which are net locations where privacy 1958 of data is secured using, for example, encryption methods 1959 such as [SSL], and 1960 - "Insecure" Net Locations where privacy of data is not 1961 assured. 1963 Where both types of net location are present, the following rules 1964 apply: 1966 - either a Secure Net Location or an Insecure Net Location or 1967 both must be present 1968 - if only one of the two Net Locations is present, then the 1969 one present must be used 1970 - if both are present, then the either may be used depending 1971 on preference the preference of the sender of the message. 1973 4. Internet Open Trading Protocol Transactions 1974 The Baseline Internet Open Trading Protocol supports the following 1975 types of Baseline IOTP Transactions: 1977 - Authentication 1978 - Deposit 1979 - Purchase 1980 - Refund 1981 - Withdrawal 1982 - Baseline Value Exchange 1983 - Payment Instrument Customer Care 1984 - Transaction Status Inquiry, and 1985 - Ping 1986 Each of these transactions are described in more detail in the 1987 following sections providing descriptions of: 1989 - the Trading Blocks in each IOTP Transaction 1990 - the Trading Components in each Trading Block, and 1991 - how the Trading Components are signed 1993 Note: There are many similarities between the transactions within 1994 IOTP. This is because there is a lot of reuse of the Trading 1995 Blocks between the different transactions. 1996 This means that there should be significant opportunity for 1997 software re-use. For example, from an IOTP perspective, the 1998 Deposit, Refund and Withdrawal transactions are essentially the 1999 same, although the processing which will occur, especially at the 2000 server end, will differ. 2002 4.1. Baseline Authentication IOTP Transaction 2004 The Baseline Authentication IOTP Transaction supports: 2006 - the remote authentication of a Consumer by another Trading 2007 Role using a variety of authentication methods, and 2008 - the provision of Organization Component about a Consumer to 2009 another Trading Role. 2010 Typical use includes: 2012 - when the Baseline Authentication IOTP Transaction takes place 2013 as an early part of a session where strong continuity 2014 exists. For example, a Financial Institution could: 2016 o set up a secure channel (e.g. using SSL) with a customer 2018 o authenticate the customer using the Baseline 2019 Authentication IOTP Transaction, and then 2021 o provide the customer with access to account information 2022 and other services with the confidence that they are 2023 communicating with a bona fide customer. 2025 - as a means of providing a Merchant role with Organization 2026 Components that contain information about Consumer and 2027 DelivTo Trading Roles. 2029 1. The Baseline Authentication IOTP Transaction consists of just 2030 the Authentication Trading Exchange.The Authentication 2031 Exchange consists of a set of predefined IOTP Messages which 2032 are exchanged between the Trading Roles. 2034 2. OUA initiates the IOTP transaction using out-of-band process. 2036 3. OTR SHALL send an Authentication Request Block containing 2037 challenge data and authentication method along with the TPO 2038 Block. 2040 4. Trading Protocol Options Block MUST contain one Protocol 2041 Options Component which defines the options which apply to 2042 the whole IOTP Transaction. Authentication Request Block MUST 2043 contain one Authentication Data Component (see section 6.2) 2045 5. OUA uses the challenge data, authentication method to 2046 generate Authentication Response Block. OUA MAY store all or 2047 partial information on IOTP transaction for record keeping 2048 purposes. 2050 6. OUA SHALL send Authentication Response to the OTR. 2051 Authentication Response Block MUST contain one 2052 Authentication Response Component (see section 6.3). 2054 7. OTR SHALL checks the Authentication Response against the 2055 challenge data and authentication method to verify the 2056 validity of the OUA identity. 2058 8. There are no variations of the Baseline Authentication IOTP 2059 Transaction. 2061 4.2. Baseline Deposit IOTP Transaction 2063 The Baseline Deposit IOTP Transaction supports the deposit of 2064 electronic cash with a Financial Institution. 2066 The Baseline Deposit IOTP Transaction occurs in two basic forms: 2068 - Baseline Deposit with Authentication. Where the Consumer 2069 making the deposit is authenticated before the deposit is 2070 made, and 2071 - Baseline Deposit without Authentication. Where the Consumer 2072 is not authenticated before the deposit is made. 2074 4.2.1. Baseline Desposit with Authentication 2076 1. OUA sends information about how much to deposit, the brand 2077 to be used etc. to the OTR using out-of-band process. 2079 2. OTR sets the payment brand, protocol to offer and generates 2080 the Authentication Request and sends to OUA. Trading 2081 Protocol Options Block MUST contain one Protocol Options 2082 Component which defines the options which apply to the whole 2083 IOTP Transaction and one Brand List Component(see section 2084 6.12) which contains the payment brand and protocols which 2085 may be selected for use in the Payment Exchange. 2086 Authentication Request Block MUST contain one Authentication 2087 Data Component (see section 6.2). 2089 3. OUA selects the payment protocol to use, records selection 2090 in Brand Selection Component, generates an Authentication 2091 Response Block and sends back to the OTR. TPO Selection 2092 Block MUST contain one Brand Selection Component (see 2093 section 6.17) for use in the Payment Exchange. It contains 2094 the results of the consumer selecting a Payment Brand and 2095 Payment Protocol from the list provided in the Brand List 2096 Component. Authentication Response Block MUST contain one 2097 Authentication Response Component (see section 6.3). 2099 4. OTR checks the Authentication Response against the challenge 2100 data and authentication method to validate the OUA identity. 2102 5. On successful authentication, OTR SHALL generate Offer 2103 Response Block containing information about the deposit. OTR 2104 MAY optionally include the Signature Block and sends it to 2105 the OUA. Offer Response Block MUST contain: 2107 o zero or one Authentication Data Component (see section 2108 6.2) An Authentication Data Component is required for 2109 each Payment Exchange, where its Payment Component 2110 contains an AuthDataRef attribute 2112 o one Order Component (see section 6.4) which contains 2113 details about the deposit, for example the amount of 2114 value being deposited and any fees which might apply 2116 o one Payment Component (see section 6.21) which contains 2117 information about the payment which is to be made 2119 o Organization Components (see section 6.7) with the 2120 following roles: 2122 * the Merchant who is accepting the deposit 2124 * the Consumer who is making the deposit 2126 * the PaymentHandler for the payment. The "ID" of the 2127 Payment Handler Organization Component is contained 2128 within the VaOrgRef attribute of the Payment Component 2129 (see section 6.21) 2131 o one Delivery Component (see section 6.24) with the 2132 DelivExch attribute set to False. 2134 6. If the Offer Response is being digitally signed then a 2135 Signature Block MUST be included in the same IOTP message 2136 that contains an "Offer Response" Signature Component (see 2137 section 6.30). The Signature Component contains hashes of 2138 the following XML elements: 2140 o the Transaction Reference Block (see section 3.5) for the 2141 IOTP Message which contains the first usage of the Offer 2142 Response Block within the IOTP Transaction. It contains 2143 information that identifies the IOTP Message and IOTP 2144 Transaction 2146 o the Transaction Id Component (see section 3.5.1) which 2147 globally uniquely identifies the IOTP Transaction 2149 o the Authentication Data Component if present, the Order 2150 Component, the Payment Component, all the Organization 2151 Components present, andthe Delivery Component of the 2152 Offer Response Block 2154 o the Protocol Options Component, and the Brand List 2155 Component of the TPO Block. 2157 o the Brand Selection Component contained in the TPO 2158 Selection Block. 2160 7. OUA checks if Offer is OK, combines components from the TPO 2161 Block, the TPO Selection Block and the Offer Response Block 2162 to create the Payment Request Block and sends it to the 2163 Payment Handler with the Signature Block if it present. The 2164 Payment Request Block (see section 5.6) MUSTcontains: 2166 o the following components copied from the Offer Response 2167 Block: 2169 * the Authentication Data Component if present 2171 * the Payment Component 2173 * the Organization Components with the roles of: Merchant 2174 and PaymentHandler 2176 o the following component from the TPO Block: 2178 * the Brand List Component 2180 o one Brand Selection Component either: 2182 * copied from the Offer Response Block if the deposit is 2183 a Baseline Deposit with Authentication, or 2185 * created by the Consumer, containing the payment brand 2186 and payment protocol selected, if the deposit is a 2187 Baseline Deposit without Authentication 2189 o one Payment Scheme Component (see section 6.22) if 2190 required by the payment method used (see the Payment 2191 Method supplement to determine if this is needed). 2193 8. If the Baseline Deposit Offer Response Block was signed then 2194 the IOTP Message that contains the Payment Request Block must 2195 also contain a Signature Block with a copy of the "Offer 2196 Response" Signature Component. 2198 9. Payment Handlers SHOULD check that they are authorised to 2199 carry out the Payment (see section 9 Security 2200 Considerations). Payment Handler starts exchanging the 2201 payment protocol messages, encapsulated in the Payment 2202 Exchange Block. On successful completion of payment protocol 2203 messages, Payment Handler creates Payment Response Block 2204 with an optional Signature Block and sends it to the OUA.The 2205 Payment Exchange Block (see section 5.7) MUST contain one 2206 Payment Scheme Component (see section 6.22) which contains 2207 payment method specific data. See the Payment Method 2208 supplement for the payment method being used to determine 2209 what this should contain. The Payment Response Block (see 2210 section 5.8) MUST contain 2212 o one Payment Receipt Component(see section 6.23) which 2213 contains scheme specific data which can be used to verify 2214 the payment occurred 2216 o one Payment Scheme Component (see section 6.22) if 2217 required which contains payment method specific data. See 2218 the Payment Method supplement for the payment method 2219 being used to determine what this should contain 2221 o the "Offer Response" Signature Component (see section 2222 6.30) from the Payment Request Block if present. 2224 10. If a signed Payment Receipt is being provided, indicated by 2225 the SignedPayReceipt attribute of the Payment Component of 2226 the Offer Response Block being set to True, then the IOTP 2227 Message that contains the Payment Response Block must also 2228 contain a Signature Block with a "Payment Receipt" Signature 2229 Component which contains hashes of the following: 2231 o the Transaction Reference Block (see section 3.5) for the 2232 IOTP Message which contains the first usage of the Payment 2233 Response Block, 2235 o the Transaction Id Component (see section 3.5.1) within 2236 the Transaction Reference Block that globally uniquely 2237 identifies the IOTP Transaction, 2239 o the Payment Receipt Component from the Payment Response 2240 Block and 2242 o the "Offer Response" Signature Component from the Payment 2243 Request Block if present. 2245 11. OUA checks Payment Response is OK. OUA MAY store information 2246 on IOTP transaction for record keeping purposes. 2248 4.2.2. Baseline Deposit Without Authentication 2250 In Baseline Deposit without Authentication, there is no 2251 Authentication Exchange and the OTR provides details about the 2252 deposit immediately at the start of the IOTP Transaction. 2254 The Baseline Deposit without authentication might be used: 2256 - if a previous IOTP transaction, for example a Baseline 2257 Withdrawal or a Baseline Authentication, authenticated the 2258 consumer, and a secure channel has been maintained, 2259 therefore the authenticity of the consumer is known 2260 - if authentication is achieved as part of a proprietary 2261 payment protocol and is therefore included in the Payment 2262 Exchange 2263 - if authentication of the consumer has been achieved by some 2264 other means outside of the scope of IOTP, for example, by 2265 using a pass phrase. 2267 IOTP aware applications supporting the Consumer Trading Role must 2268 check for the existence of an Authentication Request Block in the 2269 first IOTP Message to determine whether the Baseline Deposit 2270 includes an Authentication Exchange or not. 2272 4.3. Baseline Purchase IOTP Transaction 2274 The Baseline Purchase IOTP Transaction supports the purchase of 2275 goods or services using any payment method. The Baseline Purchase 2276 IOTP Transaction occurs in two basic forms: 2278 - Brand Dependent Purchase. Where the content of the offer, 2279 e.g. the order details, amount, delivery details, etc., are 2280 dependent on the payment brand and protocol selected by the 2281 consumer, and 2282 - Brand Independent Purchase. Where the content of the offer 2283 is not dependent on the payment brand and protocol selected. 2284 Further variation is supported in that: 2286 - the Delivery Exchange is optional, and 2287 - the Delivery Response Block may be sent to the consumer 2288 either: 2290 o at the same time as the Payment Response Block, or 2292 o after the Payment Response Block as the result of the 2293 Consumer sending the Delivery Handler a Delivery Request 2294 Block. 2296 4.3.1. Brand Dependent Purchases 2298 1. In a Brand Dependent Purchase the TPO Block and the Offer 2299 Response Block MUST BE sent separately by the Merchant to 2300 the Consumer, i.e.: 2302 o the Brand List Component is sent to the Consumer in a TPO 2303 Block, 2305 o the Consumer selects a Payment Brand, Payment Protocol 2306 and optionally a Currency and amount from the Brand List 2307 Component 2309 o the Consumer sends the selected brand, protocol and 2310 currency/amount back to the Merchant in a TPO Selection 2311 Block, and 2313 o the Merchant uses the information received to define the 2314 content of and then send the Offer Response Block to the 2315 Consumer. 2317 2. In a Brand Independent Purchase the TPO Block and the Offer 2318 Response Block are sent together by the Merchant to the 2319 Consumer in the same IOTP Message at the start of the IOTP 2320 Transaction. 2322 3. A Brand Independent Purchase always occurs when only one 2323 payment brand and protocol is being offered to the Consumer 2324 by the Merchant. It is also likely to, but will not 2325 necessarily, occur when multiple brands are being offered, 2326 the Payment Handler is the same, and all brands use the same 2327 set of protocols. 2329 4. Note that the TPO Block and the Offer Response Block may be 2330 sent in separate IOTP messages even if the Offer Response 2331 Block does not change. However this increases the number of 2332 messages in the transaction and is therefore likely to 2333 increase transaction response times. 2335 5. IOTP aware applications supporting the Consumer Trading Role 2336 must check for the existence of an Offer Response Block in 2337 the first IOTP Message to determine whether the Baseline 2338 Purchase is brand dependent or not. 2340 4.3.2. Combining Delivery Response Block and Payment Response Block 2342 1. The Delivery Response Block and the Payment Response Block 2343 may be sent: 2345 o separately by the Payment Handler to the Consumer, i.e.: 2347 * the Payment Response Block containing a Payment Receipt 2348 and optional signature for the payment is sent by the 2349 Payment Handler to the Consumer, 2351 * the Consumer combines these components from the Payment 2352 Response Block with components from the Offer Response 2353 Block, to create a Delivery Request Block 2355 * the Consumer sends the Delivery Request Block to the 2356 Delivery Handler 2358 * the Delivery Handler processes the Delivery Request 2359 Block and sends a Delivery Response Block back to the 2360 Consumer, or 2362 o together, from the Payment Handler to the Consumer, when 2363 the Payment Exchange is complete. 2365 2. The Delivery Response Block and the Payment Response Block 2366 are sent to the Consumer in separate IOTP Messages. 2368 3. The Delivery Response Block and the Payment Response Block 2369 may be combined into the same IOTP Message only if the 2370 Payment Handler has the information available so that she 2371 can send the Delivery Response Block. This is likely to, but 2372 will not necessarily, occur when the Merchant, the Payment 2373 Handler and the Delivery Handler Roles are combined. The 2374 DelivAndPayResp attribute of the Delivery Component (see 2375 section 6.24) contained within the Offer Response Block (see 2376 section 5.3) is set to True if the Delivery Response Block 2377 and the Payment Response Block are combined into the same 2378 IOTP Message and is set to False if the Delivery Response 2379 Block and the Payment Response Block are sent in separate 2380 IOTP Messages. 2382 4.3.3. Optional Delivery Exchange 2384 The final variation of the Baseline Purchase IOTP Transactions is 2385 a purchase without a delivery. The DelivExch attribute of the 2386 Delivery Component (see section 6.24) contained in the Offer 2387 Response Block (see section 5.3) is set to False if the Delivery 2388 Exchange is omitted and is set to True if the Delivery Exchange 2389 is included. 2391 4.3.4. Baseline Purchase Transaction 2393 1. OUA starts the IOTP Purchase Transaction by sending 2394 information about what to purchase using the out-of-band 2395 process. 2397 2. OTR(Merchant) decides which payment brand and protocols to 2398 offer, places them in the TPO Block and sends to 2399 OUA(Consumer).The Error! Reference source not found. (see 2400 section Error! Reference source not found.) MUST contain: 2402 o one Protocol Options Component which defines the options 2403 which apply to the whole IOTP Transaction. See Section 2404 6.1. 2406 o one Brand List Component (see section 6.12) which 2407 contains one or more payment brands and protocols which 2408 may be selected for use in the Payment Exchange. 2410 3. OUA selects the payment brand and payment protocol and 2411 records the selection in a TPO Selection Block and sends 2412 back to the OTR(Merchant).The TPO Selection Block (see 2413 section 5.2) is only used by Brand Dependent Purchase. It 2414 MUST contain one Brand Selection Component (see section 2415 6.17) for use in the Payment Exchange. It contains the 2416 results of the consumer selecting a Payment Brand and 2417 Payment Protocol from the list provided in the Brand List 2418 Component. 2420 4. The OTR(Merchant) uses payment brand and protocol selected 2421 and information on what being purchased to create an Offer 2422 Response Block containing details about goods ordered, price 2423 etc and MAY optionally include Signature Block and sends it 2424 to OUA(Consumer).The Offer Response Block (see section 5.3) 2425 MUST contain: 2427 o zero or one Authentication Data Component (see section 2428 6.2) An Authentication Data Component is required for 2429 each Payment Exchange, where its Payment Component (see 2430 section 6.21) contains an AuthDataRef attribute. 2432 o one Order Component (see section 6.4) which contains 2433 details about the goods, services which are being 2434 purchased 2436 o one Payment Component (see section 6.21) which contains 2437 information about the payment which is to be made 2439 o Organization Components (see section 6.7) with the 2440 following roles: 2442 * Merchant who is providing the goods or services 2444 * Consumer who is making the purchase 2446 * PaymentHandler for the payment. The "ID" of the Payment 2447 Handler Organization Component is contained within the 2448 VaOrgRef attribute of the Payment Component 2450 o one Delivery Component (see section 6.24) which contains 2451 details of the delivery to be made. 2453 5. If the Baseline Purchase includes a Delivery Exchange then 2454 the Offer Response Block MUST also contain Organization 2455 Components with the following roles: 2457 o DeliveryHandler who will be delivering the goods or 2458 services 2460 o DelivTo i.e. the person or Organization which is to take 2461 delivery 2463 6. If the Baseline Purchase Offer Response is being digitally 2464 signed then a Signature Block MUST BE included in the same 2465 IOTP message that contains an "Offer Response" Signature 2466 Component (see section 6.30). The Signature Component MUST 2467 contain hashes of the following XML elements: 2469 o the Transaction Reference Block (see section 3.5) for the 2470 IOTP Message which contains the first usage of the Offer 2471 Response Block within the IOTP Transaction. It contains 2472 information that identifies the IOTP Message and IOTP 2473 Transaction 2475 o the Transaction Id Component (see section 3.5.1) which 2476 globally uniquely identifies the IOTP Transaction 2478 o the following components of the Offer Response Block: 2480 * the Authentication Data Component if present 2482 * the Order Component 2484 * the Payment Component 2486 * all the Organization Components present, and 2488 * the Delivery Component, 2490 o the following components of the TPO Block : 2492 * the Protocol Options Component, and 2494 * the Brand List Component 2496 o If the Baseline Purchase is a Brand Dependent Purchase 2497 then the Signature Component additionally contains a hash 2498 of the following: 2500 * the Brand Selection Component contained in the TPO 2501 Selection Block. 2503 7. OUA(Consumer) checks Offer is OK, combines components from 2504 the TPO Block, TPO Selection Block and ther Offer Response 2505 Block to create a Payment Request Block and sends it back to 2506 the Payment Handler together with the Signature Block if 2507 present. The Payment Request Block (see section 5.6) MUST 2508 contain: 2510 o the following components copied from the Offer Response 2511 Block: 2513 * the Authentication Data Component if present 2515 * the Payment Component 2517 * the Organization Components with the roles of: Merchant 2518 and PaymentHandler 2520 o the following component from the TPO Block: 2522 * the Brand List Component 2524 o one Brand Selection Component either: 2526 * copied from the Offer Response Block if the purchase is 2527 a Brand Dependent Purchase, or 2529 * created by the Consumer, containing the payment brand 2530 and payment protocol selected, if the purchase is a 2531 Brand Independent Purchase 2533 o one Payment Scheme Component (see section 6.22) if 2534 required by the payment method used (see the Payment 2535 Method supplement to determine if this is needed). 2537 8. If the Baseline Purchase Offer Response Block was signed 2538 then the IOTP Message that contains the Payment Request Block 2539 must also contain a Signature Block with a copy of the 2540 "Offer Response" Signature Component. 2542 9. The Payment Exchange Block (see section 5.7) MUST contain 2543 one Payment Scheme Component (see section 6.22) which 2544 contains payment method specific data. See the Payment 2545 Method supplement for the payment method being used to 2546 determine what this should contain. 2548 10. Payment Handlers SHOULD check that they are authorised to 2549 carry out the Payment (see section 9 Security 2550 Considerations). Payment Handler checks optional signature, 2551 processes Payment Request Block and starts exchanging 2552 payment protocol messages, encapsulated in a Payment 2553 Exchange Block with the OUA(Consumer). On successful 2554 completion of the payment protocol messages, Payment Handler 2555 creates Payment Response Block and send to the 2556 OUA(Consumer).The Payment Response Block (see section 5.8) 2557 MUST contain: 2559 o one Payment Receipt Component (see section) which 2560 contains scheme specific data which can be used to verify 2561 the payment occurred 2563 o one Payment Scheme Component (see section 6.22) if 2564 required which contains payment method specific data. See 2565 the Payment Method supplement for the payment method 2566 being used to determine what this should contain 2568 o the "Offer Response" Signature Component (see section 2569 6.30) from the Payment Request Block if present. 2571 11. If a signed Payment Receipt is being provided, indicated by 2572 the SignedPayReceipt attribute of the Payment Component of 2573 the Offer Response Block being set to True, then the IOTP 2574 Message that contains the Payment Response Block must also 2575 contain a Signature Block with a "Payment Receipt" Signature 2576 Component which contains hashes of the following: 2578 o the Transaction Reference Block (see section 3.5) for the 2579 IOTP Message which contains the first usage of the Payment 2580 Response Block, 2582 o the Transaction Id Component (see section 3.5.1) within 2583 the Transaction Reference Block that globally uniquely 2584 identifies the IOTP Transaction, 2586 o the Payment Receipt Component from the Payment Response 2587 Block and 2589 o the "Offer Response" Signature Component from the Payment 2590 Request Block if present. 2592 12. OUA(Consumer checks Payment Response is OK and creates a 2593 Delivery Request from Payment Response Block, Offer Response 2594 Block and Signature Block, if present, and sends to the 2595 Delivert Handler. The Delivery Request Block (see section 2596 5.9) MUSTcontain: 2598 o the following components copied from the Offer Response 2599 Block: 2601 * the Order Component (see section 6.4) 2603 * the Organization Component (see section 6.7) with the 2604 roles of: Merchant, DeliveryHandler and DeliverTo 2606 * the Delivery Component (see section 6.24) 2608 13. Delivery Handler checks Payment Receipt, Order in Offer 2609 Response and the optional signatures, creates a Delivery 2610 Response Block, sends it to OUA(Consumer). The Delivery 2611 Response Block MUST contain one Delivery Note Component (see 2612 section 6.26) which contains delivery instructions about the 2613 delivery of goods or services 2615 Payment Handlers should check that they are authorised to carry 2616 out the Payment (see section 9 Security Considerations). 2618 If the Baseline Purchase Offer Response or Payment Response 2619 Blocks were signed then the IOTP Message that contains the 2620 Delivery Request Block MUST also contain a Signature Block with a 2621 copy of: 2623 - the "Offer Response" Signature Component if present, and/or 2624 - the "Payment Receipt" Signature Component, if present 2626 4.4. Baseline Refund IOTP Transaction 2628 In business terms the refund process typically consists of: 2630 - a request for a refund being made by the Consumer to the 2631 Merchant, typically supported by evidence to demonstrate: 2633 o the original trade took place, for example by providing a 2634 receipt for the original transaction 2636 o using some type of authentication, that the consumer 2637 requesting the refund is the consumer, or a 2638 representative of the consumer, who carried out the 2639 original trade 2641 o the reason why the merchant should make the refund 2643 - the merchant agreeing (or not) to the refund. This may 2644 involve some negotiation between the Consumer and the 2645 Merchant, and, if the merchant agrees, 2646 - a refund payment by the Merchant to the Consumer. 2648 The Baseline Refund IOTP Transaction supports a subset of the 2649 above, specifically it supports: 2651 - the optional authentication of the Consumer using an 2652 Authentication Exchange (see section 2.7), and 2653 - the refund payment by the Merchant to the Consumer using the 2654 following two Trading Exchanges: 2656 o an Offer Exchange (see section 2.4), and 2658 o a Payment Exchange (see section 2.5). 2660 The Baseline Refund IOTP Transaction occurs in two basic forms: 2662 - Baseline Refund with Authentication. Where the Consumer 2663 requesting the refund is authenticated before the refund is 2664 made, and 2666 - Baseline Refund without Authentication. Where the Consumer 2667 is not authenticated before the refund is made. 2669 4.4.1. Baseline Refund with Authentication 2671 In Baseline Refund with Authentication an Authentication Exchange 2672 occurs before the Offer Exchange containing the details of the 2673 refund is provided by the Merchant. 2675 Following sequences of messages are exchanged between the trading 2676 roles for refund transaction: 2678 1. OUA(Consumer) requests payment of previously agreed refund, 2679 sends information about refund, such as a reference number to 2680 the OTR(Merchant) using out-of-band process. 2682 2. The OTR(Merchant) sets the payment brand and decided which 2683 protocol to offer in TPO Block, generates an Authentication 2684 Request Block containing challenge data and the authentication 2685 method and sends it to the Consumer. The TPO Block must 2686 contain: 2687 - one Protocol Options Component which defines the options 2688 which apply to the whole IOTP Transaction. See Section 6.1. 2689 - one Brand List Component (see section 6.12) which contains 2690 the payment brand and protocols which may be selected for 2691 use in the Payment Exchange. 2693 The Authentication Request Block (see section 5.4) MUST contain 2694 one Authentication Data Component (see section 6.2) 2696 3. IOTP aware applications supporting the Consumer Trading Role must 2697 check for the existence of an Authentication Request Block in the 2698 first IOTP Message to determine whether the Baseline Refund 2699 includes an Authentication Exchange or not. The Consumer selects 2700 payment protocol to use, records selection in a Brand Selection 2701 Component, generates an Authentication Response Block and sends 2702 them back to the Merchant. The TPO Selection Block (see section 5.2) 2703 MUST contain: 2705 - one Brand Selection Component (see section 6.17) for use in 2706 the Payment Exchange. It contains the results of the 2707 consumer selecting a Payment Brand and Payment Protocol from 2708 the list provided in the Brand List Component. 2710 The Authentication Response Block (see section 5.5) MUST contain 2711 one Authentication Response Component (see section 6.3). 2713 4. The OTR(Merchant) checks the Authentication Response against the 2714 challenge data and authentication method, based on the Consumer 2715 identity and refund information generates the Offer Response Block 2716 containing the information about the refund and optional Signature 2717 Block and sends them to the Consumer. The Offer Response Block 2718 (see section 5.3) MUST contain: 2720 - zero or one Authentication Data Component (see section 6.2) 2721 An Authentication Data Component is required for each 2722 Payment Exchange, where its Payment Component contains an 2723 AuthDataRef attribute 2725 - one Order Component (see section 6.4) which contains details 2726 about the refund, for example the amount being refunded and 2727 any conditions which might apply 2728 - one Payment Component (see section 5.2) which contains 2729 information about the payment which is to be made 2730 - Organization Components (see section 6.7) with the following 2731 roles: 2733 o the Merchant who is making the refund 2735 o the Consumer who is requesting the refund 2737 o the PaymentHandler for the payment. The "ID" of the 2738 Payment Handler Organization Component is contained 2739 within the VaOrgRef attribute of the Payment Component 2741 - one Delivery Component (see section 6.24) with the DelivExch 2742 attribute set to False. 2744 5. If the Baseline Refund Offer Response is being digitally signed 2745 then a Signature Block must be included in the same IOTP message 2746 that contains an "Offer Response" Signature Component (see 2747 section 6.30). The Signature Component contains hashes of the 2748 following XML elements: 2750 - the Transaction Reference Block (see section 3.5) for the 2751 IOTP Message which contains the first usage of the Offer 2752 Response Block within the IOTP Transaction. It contains 2753 information that identifies the IOTP Message and IOTP 2754 Transaction 2755 - the Transaction Id Component (see section 3.5.1) which 2756 globally uniquely identifies the IOTP Transaction 2757 - the following components of the Offer Response Block: 2759 o the Authentication Data Component if present 2761 o the Order Component 2763 o the Payment Component 2765 o all the Organization Components present, and 2767 o the Delivery Component, 2769 - the following components of the TPO Block : 2771 o the Protocol Options Component, and 2773 o the Brand List Component 2775 - If the Baseline Refund is a Baseline Refund with 2776 Authentication then the Signature Component additionally 2777 contains a hash of the following: 2778 - the Brand Selection Component contained in the TPO Selection 2779 Block. 2781 6. OUA(Consumer) checks Offer is OK, combines components from 2782 the TPO Block, the TPO Selection Block and the Offer Response 2783 Block to create a Payment Request Block and sends to the 2784 Payment Handler together with the optional Signature Block. 2785 The Payment Request Block (see section 5.6) MUST contain: 2787 - the following components copied from the Offer Response 2788 Block: 2790 o the Authentication Data Component if present 2792 o the Payment Component 2794 o the Organization Components with the roles of: Merchant 2795 and PaymentHandler 2797 - the following component from the TPO Block: 2799 o the Brand List Component 2801 - one Brand Selection Component either: 2803 o copied from the Offer Response Block if the refund is a 2804 Baseline Refund with Authentication, or 2806 o created by the Consumer, containing the payment brand and 2807 payment protocol selected, if the refund is a Baseline 2808 Refund with Authentication 2810 - one Payment Scheme Component (see section 6.22) if required 2811 by the payment method used (see the Payment Method 2812 supplement to determine if this is needed). 2814 7. If the Baseline Refund Offer Response Block was signed then the 2815 IOTP Message that contains the Payment Request Block must also 2816 contain a Signature Block with a copy of the "Offer Response" 2817 Signature Component. 2819 8. Payment Handlers should check that they are authorised to carry 2820 out the Payment (see section 9 Security Considerations). Payment 2821 Handler checks signature(if present), process Pay Request Block, 2822 starts payment protocol message exchanges with the Consumer. 2823 The Payment Exchange Block (see section 5.7) MUST contain one 2824 Payment Scheme Component (see section 6.22) which contains 2825 payment method specific data. See the Payment Method supplement 2826 for the payment method being used to determine what this should 2827 contain. 2829 9. On successful completion of the payment protocol messages creates a 2830 Pay Receipt component inside Pay Response Block, sends to the 2831 Consumer with the optional Signature Block. The Payment Response 2832 Block (see section 5.8) contains: 2834 - one Payment Receipt Component (see section 6.23) which 2835 contains scheme specific data which can be used to verify 2836 the payment occurred 2837 - one Payment Scheme Component (see section 6.22) if required 2838 which contains payment method specific data. See the Payment 2839 Method supplement for the payment method being used to 2840 determine what this should contain 2841 - the "Offer Response" Signature Component (see section 6.30) 2842 from the Payment Request Block if present. 2844 10. If a signed Payment Receipt is being provided, indicated by the 2845 SignedPayReceipt attribute of the Payment Component of the Offer 2846 Response Block being set to True, then the IOTP Message that 2847 contains the Payment Response Block must also contain a Signature 2848 Block with a "Payment Receipt" Signature Component which contains 2849 hashes of the following: 2851 - the Transaction Reference Block (see section 3.5) for the 2852 IOTP Message which contains the first usage of the Payment 2853 Response Block, 2854 - the Transaction Id Component (see section 3.5.1) within the 2855 Transaction Reference Block that globally uniquely 2856 identifies the IOTP Transaction, 2857 - the Payment Receipt Component from the Payment Response 2858 Block and 2859 - the "Offer Response" Signature Component from the Payment 2860 Request Block if present. 2862 11. Consumer checks Pay Response is OK. OUA MAY optionally keep 2863 all information related to the transaction for record keeping 2864 purposes. 2866 4.4.2. Baseline Refund without Authentication 2867 In Baseline Refund without Authentication, there is no 2868 Authentication Exchange and the Merchant provides details about 2869 the refund immediately at the start of the IOTP Transaction. 2871 The Baseline Refund without authentication might be used: 2873 - when authentication of the consumer has been achieved by 2874 some other means, for example, the consumer has entered some 2875 previously supplied code in order to identify herself and 2876 the refund to which the code applies. The code could be 2877 supplied, for example on a web page or by e-mail. 2878 - when a previous IOTP transaction, for example a Baseline 2879 Authentication, authenticated the consumer, and a secure 2880 channel has been maintained, therefore the authenticity of 2881 the consumer is known and therefore the previously agreed 2882 refund can be identified. 2884 4.5. Baseline Withdrawal IOTP Transaction 2886 The Baseline Withdrawal IOTP Transaction supports the withdrawal 2887 of electronic cash from a Financial Institution. 2889 Note: The Financial Institution has, in IOTP terminology, a role 2890 of merchant in that a service (i.e. a withdrawal of electronic 2891 cash) is being offered in return for a fee, for example bank 2892 charges of some kind. The term "Financial Institution" is used in 2893 the diagrams and in the text for clarity. 2895 The Baseline Withdrawal IOTP Transaction occurs in two basic 2896 forms: 2898 - Baseline Withdrawal with Authentication. Where the Consumer 2899 making the withdrawal is authenticated before the withdrawal 2900 is made, and 2901 - Baseline Withdrawal without Authentication. Where the 2902 Consumer is not authenticated before the withdrawal is made. 2904 4.5.1. Baseline Withdrawal with Authentication 2906 In Baseline Withdrawal with Authentication an Authentication 2907 Exchange occurs before the Offer Exchange containing the details 2908 of the withdrawal is provided by the Financial Institution. 2910 Following sequences of messages are exchanged between the Consumer 2911 and the financial institution(OTR) for withdrawl transaction: 2913 1. OUA(Consumer) decides to withdraw electronic cash and sends 2914 information about hoe much to withdraw to the OTR(Financial 2915 Institution playing a merchant role) using out-of-band process. 2917 2. The OTR(Financial Institution) sets the payment brand and decided 2918 which protocol to offer in TPO Block, generates an Authentication 2919 Request Block containing challenge data and the authentication 2920 method and sends it to the Consumer. The TPO Block must 2921 contain: 2922 - one Protocol Options Component which defines the options 2923 which apply to the whole IOTP Transaction. See Section 6.1. 2924 - one Brand List Component (see section 6.12) which contains 2925 the payment brand and protocols which may be selected for 2926 use in the Payment Exchange. 2928 The Authentication Request Block (see section 5.4) MUST contain 2929 one Authentication Data Component (see section 6.2) 2931 3. IOTP aware applications supporting the Consumer Trading Role must 2932 check for the existence of an Authentication Request Block in the 2933 first IOTP Message to determine whether the Baseline Withdrawal 2934 includes an Authentication Exchange or not. The Consumer selects 2935 payment protocol to use, records selection in a Brand Selection 2936 Component, generates an Authentication Response Block and sends 2937 them back to the Financial Institution. The TPO Selection Block 2938 (see section 5.2) MUST contain: 2940 - one Brand Selection Component (see section 6.17) for use in 2941 the Payment Exchange. It contains the results of the 2942 consumer selecting a Payment Brand and Payment Protocol from 2943 the list provided in the Brand List Component. 2945 The Authentication Response Block (see section 5.5) MUST contain 2946 one Authentication Response Component (see section 6.3). 2948 4. The OTR(Financial Institution) checks the Authentication Response 2949 against the challenge data and authentication method, based on the 2950 Consumer identity and refund information generates the Offer 2951 Response Block containing the information about the withdrawal and 2952 optional Signature Block and sends them to the Consumer. 2953 The Offer Response Block (see section 5.3) MUST contain: 2955 - zero or one Authentication Data Component (see section 6.2) 2956 An Authentication Data Component is required for each 2957 Payment Exchange, where its Payment Component contains an 2958 AuthDataRef attribute 2960 - one Order Component (see section 6.4) which contains details 2961 about the refund, for example the amount being withdrawn and 2962 any conditions which might apply 2963 - one Payment Component (see section 5.2) which contains 2964 information about the payment which is to be made 2965 - Organization Components (see section 6.7) with the following 2966 roles: 2968 o the Merchant who is making the refund 2970 o the Consumer who is requesting the refund 2972 o the PaymentHandler for the payment. The "ID" of the 2973 Payment Handler Organization Component is contained 2974 within the VaOrgRef attribute of the Payment Component 2976 - one Delivery Component (see section 6.24) with the DelivExch 2977 attribute set to False. 2979 5. If the Baseline Withdrawal Offer Response is being digitally signed 2980 then a Signature Block must be included in the same IOTP message 2981 that contains an "Offer Response" Signature Component (see 2982 section 6.30). The Signature Component contains hashes of the 2983 following XML elements: 2985 - the Transaction Reference Block (see section 3.5) for the 2986 IOTP Message which contains the first usage of the Offer 2987 Response Block within the IOTP Transaction. It contains 2988 information that identifies the IOTP Message and IOTP 2989 Transaction 2990 - the Transaction Id Component (see section 3.5.1) which 2991 globally uniquely identifies the IOTP Transaction 2992 - the following components of the Offer Response Block: 2994 o the Authentication Data Component if present 2996 o the Order Component 2998 o the Payment Component 3000 o all the Organization Components present, and 3002 o the Delivery Component, 3004 - the following components of the TPO Block : 3006 o the Protocol Options Component, and 3008 o the Brand List Component 3010 - If the Baseline Withdrawal is a Baseline withdrawal with 3011 Authentication then the Signature Component additionally 3012 contains a hash of the following: 3013 - the Brand Selection Component contained in the TPO Selection 3014 Block. 3016 6. OUA(Consumer) checks Offer is OK, combines components from 3017 the TPO Block, the TPO Selection Block and the Offer Response 3018 Block to create a Payment Request Block and sends to the 3019 Payment Handler together with the optional Signature Block. 3020 The Payment Request Block (see section 5.6) MUST contain: 3022 - the following components copied from the Offer Response 3023 Block: 3025 o the Authentication Data Component if present 3027 o the Payment Component 3029 o the Organization Components with the roles of: Merchant 3030 and PaymentHandler 3032 - the following component from the TPO Block: 3034 o the Brand List Component 3036 - one Brand Selection Component either: 3038 o copied from the Offer Response Block if the refund is a 3039 Baseline Refund with Authentication, or 3041 o created by the Consumer, containing the payment brand and 3042 payment protocol selected, if the refund is a Baseline 3043 Refund with Authentication 3045 - one Payment Scheme Component (see section 6.22) if required 3046 by the payment method used (see the Payment Method 3047 supplement to determine if this is needed). 3049 7. If the Baseline Withdrawal Offer Response Block was signed then the 3050 IOTP Message that contains the Payment Request Block must also 3051 contain a Signature Block with a copy of the "Offer Response" 3052 Signature Component. 3054 8. Payment Handlers should check that they are authorised to carry 3055 out the Payment (see section 9 Security Considerations). Payment 3056 Handler checks signature(if present), process Pay Request Block, 3057 starts payment protocol message exchanges with the Consumer. 3058 The Payment Exchange Block (see section 5.7) MUST contain one 3059 Payment Scheme Component (see section 6.22) which contains 3060 payment method specific data. See the Payment Method supplement 3061 for the payment method being used to determine what this should 3062 contain. 3064 9. On successful completion of the payment protocol messages creates a 3065 Pay Receipt component inside Pay Response Block, sends to the 3066 Consumer with the optional Signature Block. The Payment Response 3067 Block (see section 5.8) MUST contains 3069 - one Payment Receipt Component (see section 6.23) which 3070 contains scheme specific data which can be used to verify 3071 the payment occurred 3072 - one Payment Scheme Component (see section 6.22) if required 3073 which contains payment method specific data. See the Payment 3074 Method supplement for the payment method being used to 3075 determine what this should contain 3076 - the "Offer Response" Signature Component (see section 6.30) 3077 from the Payment Request Block if present. 3079 10. If a signed Payment Receipt is being provided, indicated by the 3080 SignedPayReceipt attribute of the Payment Component of the Offer 3081 Response Block being set to True, then the IOTP Message that 3082 contains the Payment Response Block must also contain a Signature 3083 Block with a "Payment Receipt" Signature Component which contains 3084 hashes of the following: 3086 - the Transaction Reference Block (see section 3.5) for the 3087 IOTP Message which contains the first usage of the Payment 3088 Response Block, 3089 - the Transaction Id Component (see section 3.5.1) within the 3090 Transaction Reference Block that globally uniquely 3091 identifies the IOTP Transaction, 3092 - the Payment Receipt Component from the Payment Response 3093 Block and 3094 - the "Offer Response" Signature Component from the Payment 3095 Request Block if present. 3097 11. Consumer checks Pay Response is OK. OUA MAY optionally keep 3098 all information related to the transaction for record keeping 3099 purposes. 3101 Note: 3103 1. The Financial Institution can offer withdrawal of several different 3104 types of electronic cash. In practice usually only one form of 3105 electronic cash may be offered. However, there may be several 3106 different protocols which may be used for the same "brand" 3107 of electronic cash 3109 2. The financial institution may use the results of the 3110 authentication to identify not only the consumer but also 3111 the account from which the withdrawal is to be made. If no 3112 single account can be identified, then it must be obtained 3113 by other means. For example: 3114 - the consumer could specify the account number in the initial 3115 dialogue , or 3116 - the consumer could have been identified earlier, for example 3117 using a Baseline Authentication IOTP Transaction, and an 3118 account selected from a list provided by the Financial 3119 Institution. 3121 4.5.2. Baseline Withdrawal without Authentication 3122 In Baseline Withdrawal without Authentication, there is no 3123 Authentication Exchange and the Financial Institution provides 3124 details about the withdrawal immediately at the start of the IOTP 3125 Transaction. 3127 The Baseline Withdrawal without Authentication might be used: 3129 - when a previous IOTP transaction, for example a Baseline 3130 Deposit or a Baseline Authentication, authenticated the 3131 consumer, and a secure channel has been maintained, 3132 therefore the authenticity of the consumer is known 3134 - when authentication is achieved as part of a proprietary 3135 payment protocol and is therefore included in the Payment 3136 Exchange 3137 - when authentication of the consumer has been achieved by 3138 some other means, for example, by using a pass phrase, or a 3139 proprietary banking software solution. 3141 4.6. Baseline Value Exchange IOTP Transaction 3143 The Baseline Value Exchange Transaction uses Payment Exchanges 3144 (see section 2.5) to support the exchange of value in one 3145 currency obtained using one payment method with value in the same 3146 or another currency using the same or another payment method. 3147 Examples of its use include: 3149 - electronic cash advance on a credit card. For example the 3150 first payment could be a dollar SET Payment Exchange on a 3151 credit card with the second Payment Exchange being a 3152 download of DigiCash e-cash in dollars. 3153 - foreign exchange using the same payment method. For example 3154 the payment could be an upload of Mondex value in French 3155 Francs and the second a download of Mondex value in British 3156 Pounds 3157 - foreign exchange using different payment methods. For 3158 example the first payment could be a SET payment in Euros 3159 followed a download of GeldKarte in Deutchmarks. 3161 The Baseline Value Exchange IOTP Transaction occurs in two basic 3162 forms: 3164 - Brand Dependent Value Exchange. Where the content of the 3165 offer, for example the rate at which one form of value is 3166 exchanged for another, is dependent on the payment brands 3167 and protocols selected by the consumer, and 3168 - Brand Independent Value Exchange. Where the content of the 3169 offer is not dependent on the payment brands and protocols 3170 selected. 3172 4.6.1. Brand Dependent Value Exchange 3174 In Brand Dependent Value Exchange the TPO Block and the Offer 3175 Response Block are sent separately by the Merchant to the 3176 Consumer, i.e.: 3178 - the Brand List Components for the two payments are sent to 3179 the Consumer in a TPO Block, 3180 - the Consumer selects a Payment Brand and Payment Protocol 3181 from the Brand List Component for each of the payments in 3182 the Value Exchange 3183 - the Consumer sends the selected brands and protocols back to 3184 the Merchant in a TPO Selection Block, and 3185 - the Merchant Uses the information received to define the 3186 content of the Offer Response Block and then sends it to the 3187 Consumer. 3189 Whether or not the Value Exchange is brand dependent, the 3190 exchange of Trading Blocks between the Consumer and the Payment 3191 Handlers are the same. The following sequences of messages are 3192 exchanged between the Trading Roles for the Value Exchange 3193 Transaction: 3195 1. OUA(Consumer) sends information about the value exchange to 3196 the OTR(Merchant) using out-of-band process. 3198 2. OTR(Merchant) decides which payment brand and protocols to 3199 offer for each payment, places them in Brand List Components 3200 in a TPO Block and sends them to OUA(Consumer). The TPO 3201 Block MUST contain the following Trading Components: 3203 o one Protocol Options Component which defines the options 3204 which apply to the whole IOTP Transaction. See Section 3205 6.1. 3207 o two Brand List Components (see section 6.12) one for each 3208 Payment Exchange where each Brand List Component contains 3209 one or more payment brands and protocols which may be 3210 selected for use in the Payment Exchange. 3212 3. OUA(Consumer) selects the payment brand and payment protocol 3213 to use each payment, records selections in two Brand 3214 Selection Components in TPO Selection Block, and sends back 3215 to OTR(Merchant). The TPO Selection Block (see section 5.2) 3216 is only used by Brand Dependent Value Exchange. It contains: 3218 o two Brand Selection Components (see section 6.17). One 3219 for each of the Payment Exchanges. Each Brand Selection 3220 Component contains the results of the consumer selecting 3221 a Payment Brand and Payment Protocol from the list 3222 provided in the Brand List Component. 3224 4. OTR(Merchant) uses payments brands and protocols selected to 3225 create an Offer Response Block containing details about the 3226 value exchange and sends it to OUA(Consumer) together with 3227 the optional digital signature. The Offer Response Block 3228 (see section 5.3) contains the following components: 3230 o zero, one or two Authentication Data Component (see 3231 section 6.2). An Authentication Data Component is 3232 required for each Payment Exchange, where its Payment 3233 Component contains an AuthDataRef attribute. 3235 o one Order Component (see section 6.4) which contains 3236 details about the Value Exchange, for example, exchange 3237 rates, commission, etc. 3239 o two Payment Components (see section 6.21) which contain 3240 information about each of the two payments which are to 3241 be made 3243 o Organization Components (see section 6.7) with the 3244 following roles: 3246 * Merchant who is providing the goods or services 3248 * Consumer who is making the purchase 3250 * the PaymentHandlers for the payments. The "ID" of a 3251 Payment Handler Organization Component is contained 3252 within the VaOrgRef attribute of each of the Payment 3253 Components 3255 4. If the Baseline Value Exchange Offer Response is being 3256 digitally signed then a Signature Block must be included in 3257 the same IOTP message that contains an "Offer Response" 3258 Signature Component (see section 6.30). The Signature 3259 Component contains hashes of the following XML elements: 3261 o the Transaction Reference Block (see section 3.5) for the 3262 IOTP Message which contains the first usage of the Offer 3263 Response Block within the IOTP Transaction. It contains 3264 information that identifies the IOTP Message and IOTP 3265 Transaction 3267 o the Transaction Id Component (see section 3.5.1) which 3268 globally uniquely identifies the IOTP Transaction 3270 o the following components of the Offer Response Block: 3272 * the Authentication Data Component if present 3274 * the Order Component 3276 * the two Payment Components 3277 * all the Organization Components present, and 3279 o the following components of the TPO Block : 3281 * the Protocol Options Component, and 3283 * the Brand List Component 3285 o If the Baseline Value Exchange is a Brand Dependent Value 3286 Exchange then the Signature Component additionally 3287 contains a hash of the following: 3289 o the two Brand Selection Components contained in the TPO 3290 Selection Block. 3292 5. OUA(Consumer) checks Offer is OK, combines components from 3293 TPO Block, TPO Selection Block and Offer Response Block to 3294 create a Payment Request Block for the first payment and 3295 sends it to the Payment Handler 1 together with the optional 3296 Signature Block.The Payment Request Block (see section 5.6) 3297 for the first payment contains: 3299 o the following components copied from the Offer Response 3300 Block: 3302 * the Authentication Data Component for the first payment 3303 if required 3305 * the Payment Component for the first payment 3307 * the Organization Components with the roles of: Merchant 3308 and PaymentHandler for the first payment 3310 o the following component copied from the TPO Block: 3312 * the Brand List Component for the first payment 3314 o one Brand Selection Component for the first payment which 3315 is either: 3317 * copied from the Offer Response Block if the purchase is 3318 a Brand Dependent Value Exchange, or 3320 * created by the Consumer, containing the payment brand 3321 and payment protocol selected, if the purchase is a 3322 Brand Independent Value Exchange 3324 o one Payment Scheme Component (see section 6.22) if 3325 required by the payment method used (see the Payment 3326 Method supplement to determine if this is needed). 3328 6. If the Baseline Value Exchange Offer Response Block was 3329 signed then the IOTP Message that contains the Payment 3330 Request Block for the first payment must also contain a 3331 Signature Block with a copy of the "Offer Response" 3332 Signature Component. The Payment Exchange Block (see section 3333 5.7) for the first payment contains: 3335 o one Payment Scheme Component (see section 6.22) which 3336 contains payment method specific data for the payment 3337 method being used by the first payment. See the Payment 3338 Method supplement for the payment method being used to 3339 determine what this should contain. 3341 7. Payment Handler 1 processes Payment Request Block for the 3342 first payment and starts payment protocol messages. On 3343 successful completion of the payment protocol messages, 3344 Payment Handler creates Payment Response Block and sends it 3345 to the OUA(Consumer) along with the optional Signature 3346 Block.The Payment Response Block for the first payment (see 3347 section 5.8) contains: 3349 o one Payment Receipt Component (see section 6.23) which 3350 contains scheme specific data which can be used to verify 3351 the first payment occurred 3353 o one Payment Scheme Component (see section 6.22) if 3354 required by the payment method used by the first payment 3355 which contains payment method specific data. See the 3356 Payment Method supplement for the payment method being 3357 used to determine what this should contain 3359 o the Signature Component (see section 6.30) from the 3360 Payment Request Block for the first payment if present. 3362 8. If a signed Payment Receipt is being provided for the first 3363 payment, indicated by the SignedPayReceipt attribute of the 3364 Payment Component for the first payment in the Offer 3365 Response Block being set to True, then the IOTP Message that 3366 contains the Payment Response Block for the first payment 3367 must also contain a Signature Block with a "Payment Receipt" 3368 Signature Component which contains hashes of the following: 3370 o the Transaction Reference Block (see section 3.5) for the 3371 IOTP Message which contains the first usage of the Payment 3372 Response Block for the first payment, 3374 o the Transaction Id Component (see section 3.5.1) within 3375 the Transaction Reference Block that globally uniquely 3376 identifies the IOTP Transaction, 3378 o the Payment Receipt Component from the Payment Response 3379 Block for the first payment and 3381 o the "Offer Response" Signature Component from the Payment 3382 Request Block for the first payment, if present. 3384 9. OUA(Consumer) checks Payment Response for first payment is 3385 OK and create a Payment Request for Second payment using the 3386 Offer Response Block along with the optional Signature Block 3387 and sends it to Payment Handler 2.The Payment Request Block 3388 (see section 5.6) for the second payment contains: 3390 o the following components copied from the Offer Response 3391 Block: 3393 * the Authentication Data Component for the second 3394 payment if required 3396 * the Payment Component for the second payment 3398 * the Organization Components with the roles of: Merchant 3399 and PaymentHandler for the second payment 3401 o the following component copied from the TPO Block: 3403 * the Brand List Component for the second payment 3405 o one Brand Selection Component for the second payment 3406 which is either: 3408 * copied from the Offer Response Block if the purchase is 3409 a Brand Dependent Value Exchange, or 3411 * created by the Consumer, containing the payment brand 3412 and payment protocol selected, if the purchase is a 3413 Brand Independent Value Exchange 3415 o one Payment Scheme Component (see section 6.22) if 3416 required by the payment method used (see the Payment 3417 Method supplement to determine if this is needed) 3419 10. Payment Handler 2 processes Payment Request Block for the 3420 second payment and starts payment protocol messages. 3422 11. The Payment Exchange Block (see section 5.7) for the second 3423 payment contains: 3425 o one Payment Scheme Component (see section 6.22) which 3426 contains payment method specific data for the payment 3427 method being used by the second payment. See the Payment 3428 Method supplement for the payment method being used to 3429 determine what this should contain. 3431 12. On successful completion of the payment protocol messages, 3432 Payment Handler creates Payment Response Block and sends it 3433 to the OUA(Consumer) along with the optional Signature 3434 Block.The Payment Response Block for the second payment (see 3435 section 5.8) contains: 3437 o one Payment Receipt Component (see section 6.23) which 3438 contains scheme specific data which can be used to verify 3439 the second payment occurred 3441 o one Payment Scheme Component (see section 6.22) if 3442 required by the payment method used by the second payment 3443 which contains payment method specific data. See the 3444 Payment Method supplement for the payment method being 3445 used to determine what this should contain 3447 o all the Signature Components (see section 6.30) from the 3448 Payment Request Block for the second payment if present. 3450 13. If a signed Payment Receipt is being provided for the second 3451 payment, indicated by the SignedPayReceipt attribute of the 3452 Payment Component for the second payment in the Offer 3453 Response Block being set to True, then the IOTP Message that 3454 contains the Payment Response Block for the second payment 3455 must also contain a Signature Block with a "Payment Receipt" 3456 Signature Component which contains hashes of the following: 3458 o the Transaction Reference Block (see section 3.5) for the 3459 IOTP Message which contains the first usage of the Payment 3460 Response Block for the second payment, 3462 o the Transaction Id Component (see section 3.5.1) within 3463 the Transaction Reference Block that globally uniquely 3464 identifies the IOTP Transaction, 3466 o the Payment Receipt Component from the Payment Response 3467 Block for the second payment 3469 o the "Offer Response" Signature Component from the Payment 3470 Request Block for the second payment, if present, and 3472 o the "Payment Receipt" Signature Component from the 3473 Payment Request Block for the first payment, if present. 3475 14. OUA(Consumer) checks Payment Response for first payment is 3476 OK and create a Payment Request for Second payment using the 3477 Offer Response Block along with the optional Signature Block 3478 and sends it to Payment Handler 2. 3480 15. If the Baseline Value Exchange Offer Response Block or the 3481 Payment Response Block for the first payment was signed then 3482 the IOTP Message that contains the Payment Request Block for 3483 the second payment must also contain a Signature Block with 3484 a copy of: 3486 o the "Offer Response" Signature Component, if present, 3487 and/or 3489 o the "Payment Receipt" Signature Component copied from the 3490 Payment Response Block for the first payment, if present. 3492 16. If signatures are used then the Payment Handlers should 3493 check that all Signature Components they receive are valid 3494 (see section 9 Security Considerations). 3496 Note that: 3498 - the Payment Component for the first payment is the one 3499 within the Offer Response Block that contains no StartAfter 3500 attribute (see section 6.21) 3501 - the Authentication Data Component to include is identified 3502 by the AuthDataRef attribute of the Payment Component for 3503 the first payment. If no AuthDataRef attribute is present 3504 then no Authentication Data Component is required 3505 - the Payment Handler to include is identified by the Brand 3506 Selection Component (see section 6.17) for the first 3507 payment. Also see section 9.7 Check the Action Request was 3508 sent to the Correct Organization for an explanation on how 3509 Payment Handlers are identified 3510 - the Brand List Component to include is the one identified by 3511 the BrandListRef attribute of the Payment Component for the 3512 first payment 3513 - the Brand Selection Component to include from the Offer 3514 Response Block is the one that contains an Element Reference 3515 (see section 3.7) which identifies the Brand List Component 3516 for the first payment 3517 - the Payment Component for the second payment is the one 3518 within the Offer Response Block that contains a StartAfter 3519 attribute (see section 6.21) that identifies the Payment 3520 Component for the first payment 3521 - the Authentication Data Component to include is identified 3522 by the AuthDataRef attribute of the Payment Component for 3523 the second payment. If no AuthDataRef attribute is present 3524 then no Authentication Data Component is required 3525 - the Payment Handler to include is identified by the Brand 3526 Selection Component (see section 6.17) for the second 3527 payment. Also see section 9.7 Check the Action Request was 3528 sent to the Correct Organization for an explanation on how 3529 Payment Handlers are identified 3530 - the Brand List Component to include is the one identified by 3531 the BrandListRef attribute of the Payment Component for the 3532 second payment 3533 - the Brand Selection Component to include from the Offer 3534 Response Block is the one that contains an Element Reference 3535 (see section 3.7) which identifies the Brand List Component 3536 for the second payment 3538 4.6.2. Brand Independent Value Exchange 3539 In Brand Independent Value Exchange the TPO Block and the Offer 3540 Response Block are sent together by the Merchant to the Consumer 3541 in the same IOTP Message at the start of the IOTP Transaction. 3543 The TPO Block and Offer Response Block may only be combined into 3544 the same IOTP Message if the content of the Offer Response Block 3545 does not change as a result of selecting the payment brands and 3546 payment protocols to be used in the Value Exchange. 3548 Note that the TPO Block and the Offer Response Block may be sent 3549 in separate IOTP messages even if the Offer Response Block does 3550 not change. However this increases the number of messages in the 3551 transaction and is therefore likely to increase transaction 3552 response times. 3554 IOTP aware applications supporting the Consumer Trading Role must 3555 check for the existence of an Offer Response Block in the first 3556 IOTP Message to determine whether the Baseline Value Exchange is 3557 brand dependent. 3559 4.7. Payment Instrument Customer Care IOTP Transaction 3561 An IOTP Payment Instrument Customer Care Transaction is used to 3562 provide Payment Brand or Payment Method specific customer care. 3563 It allows Consumer Payment Brand software to exchange information 3564 with a Payment Instrument Customer Care Provider. 3566 The circumstances under which this transaction is used, if any, 3567 is defined in the IOTP Supplement for the Payment Brand. 3569 Note that the IOTP Payment Instrument Customer Care Transaction: 3571 - is initiated by the Consumer Payment Brand software which 3572 must identify the need for the transaction to occur. Note 3573 that in other IOTP Transactions, the transaction is initiated 3574 by the Merchant 3575 - has no TPO Block, as it is initiated by the Consumer 3576 - relies on the Consumer Payment Brand software to identify 3577 the net location of the Payment Instrument Customer Care 3578 Provider to which the first message in the transaction must 3579 be sent 3580 - ends when the Payment Scheme Customer Care Service 3581 determines that the exchange of messages with the Consumer 3582 is to stop. 3584 Note that a Payment Instrument Customer Care Transaction can be 3585 initiated at any time by a Consumer including in the middle of 3586 another IOTP Transaction. In this case, the transaction shall 3587 establish a different transport session from the ongoing 3588 transaction. See the Mapping to Transport for the Transport 3589 Mechanism being used. 3591 Following OTP messages are exchanged between the Payment Instrument 3592 User and Payment Instrument Care Provider roles: 3594 1. OUA(Consumer) identifies the need to contact Payment instrument 3595 Care Provider and generates Payment Instrument Customer Care 3596 Request Block and sends it to the Customer Care Provider. OUA 3597 determines the Customer Care Provider by Net Location. The Payment 3598 Instrument Customer Care Request Block MUST contain: 3600 - a Payment Method Information Component (see section 6.27) 3601 which describes the Payment Method for which Customer Care 3602 is requested, and 3603 - zero or more optional Payment Scheme Components (see section 3604 6.22) which contain optional Payment scheme data 3606 2. OTR(Payment Instrument Customer Care Provider) process the Payment 3607 Instrument Customer Care Request Block and starts exchaging 3608 Payment Instrument Customer Care Exchange Block with the 3609 OUA(Consumer). The Payment Instrument Customer Care Exchange 3610 Block MUST contain: 3612 - a Payment Method Information Component (see section 6.27) 3613 which describes the Payment Method for which Customer Care 3614 is being provided, and 3615 - zero or more optional Payment Scheme Components (see section 3616 6.22) which contain optional Payment scheme data 3617 3. On successful completion of the Customer Care Exchange messages, 3618 OTR(Payment Instrument Customer Care Provider) generates the payment 3619 instrument customer care response block and sends it to the OUA( 3620 consumer). The Payment Instrument Customer Care Response Block 3621 MUST contain: 3623 - a Payment Method Information Component (see section 6.27) 3624 which describes the Payment Method for which Customer Care 3625 is complete, and 3626 - zero or more optional Payment Scheme Component (see section 3627 6.22) which contains optional Payment scheme data 3629 Any of the IOTP Messages which contain Payment Instrument Customer 3630 care blocks may also include a Signature Block (see section 5.18) 3631 containing a Signature Component (see section 6.30). How these 3632 are used and what it signs is dependent on the Payment Brand and 3633 Payment method being used. 3635 4.8. Baseline Transaction Status Inquiry IOTP Transaction 3637 The Baseline IOTP Transaction Status Inquiry provides a Consumer 3638 with information on the status of an existing or complete IOTP 3639 transaction. 3641 The Trading Blocks used by the Baseline Transaction Status 3642 Inquiry Transaction are: 3644 - an Inquiry Request Trading Block (see section 5.14), and 3645 - an Inquiry Response Trading Block (see section 5.15). 3647 Note that: 3648 - Consumer Inquiries on Authentication transaction are not 3649 supported. 3650 - Authentication of Consumers as part of an inquiry is not 3651 supported in the Baseline version of IOTP. 3653 4.8.1. Which Trading Roles can receive Inquiry Requests 3655 The Consumer can send a Transaction Status Inquiry Block to the 3656 appropriate Trading Role after the following events have 3657 occurred: 3659 - to the Merchant, after sending TPO Selection Block, 3660 - to the Payment Handler, after sending Payment Request Block, 3661 - to the Delivery Handler, after sending Delivery Request 3662 Block. 3664 Note: IOTP does not support sending Inquiry Requests to the 3665 Consumer since the consumer may not be on-line to receive and 3666 process them. 3668 If the Consumer is inquiring on transaction that is not yet 3669 complete, it should send the Inquiry Request Block to the Trading 3670 Role to which it sent the last IOTP message. If the Consumer is 3671 inquiring on a transaction which is complete, there are two 3672 alternatives in deciding the Trading Roles that the Inquiry 3673 Request Block should be sent to: 3675 - the Consumer IOTP software can ask the end user to determine 3676 the type of inquiry they want to make, or 3677 - the Consumer IOTP software can send the inquiry request 3678 message to all the Trading Roles that were involved in the 3679 IOTP transaction. 3681 For the second case above, how the Consumer IOTP Aware Application 3682 displays the inquiry response data received from each Trading 3683 Role is up to each implementation. 3685 4.8.2. Transaction Status Inquiry Transport Session 3687 For a Transaction Status Inquiry on an ongoing transaction, the 3688 Consumer SHALL establish with a Trading Role, a different 3689 transport session from the ongoing transaction. For a Transaction 3690 Status Inquiry on a past transaction, how the IOTP module on the 3691 software at the Trading Role is started upon the receipt of 3692 Inquiry Request message is defined in each Mapping to Transport 3693 supplement for IOTP. 3695 4.8.3. Transaction Status Inquiry Error Handling 3697 Errors in a Transaction Status Inquiry can be categorised into 3698 one the following three cases: 3700 - Business errors (see section 7.2) in the original (inquired) 3701 messages 3702 - Technical errors (see section 7.1) - both IOTP and payment 3703 scheme specific ones - in the original IOTP (inquired) 3704 messages 3705 - Technical errors in the message containing the Inquiry 3706 Request Block itself 3708 The following outlines what the software should do in each case 3709 Business errors in the original messages: Return an Inquiry Response 3710 Block containing the Status Component which was last sent to the Consumer. 3712 Technical errors in the original messages: Return an Inquiry Response 3713 Block containing a Status Component. The Status Component should contain 3714 a ProcessState attribute set to ProcessError. In this case send back an 3715 Error Block indicating where the error was found in the original message. 3717 Technical errors in the Inquiry Request Block: Return an Error message. That 3718 is, send back an Error Block containing the Error Code (see section 6.36) 3719 which describes the nature of the error in the Inquiry Request message. 3721 4.8.4. Inquiry Transaction Messages 3723 Following messages are exchanged between trading roles for 3724 Inquiry Transaction: 3726 1. OUA(Consumer) generates an Inquiry Request Block and sends it 3727 to the appropriate trading role. The Inquiry Request Block 3728 (see section 5.14) MUST contain: 3730 - one Inquiry Type Component (see section 6.29). This 3731 identifies whether the inquiry is on an offer, payment, or 3732 delivery. 3733 - zero or one Payment Scheme Component (see section 6.22). 3734 This is for encapsulating payment scheme specific inquiry 3735 messages for inquiries on payment. 3737 2. The Consumer must use the same Transaction Id Component (see 3738 section 3.5.1) as in the inquired transaction. The OtpTransId 3739 attribute in this component serves as the key in querying the 3740 transaction logs maintained at the Trading Role's site. The value 3741 of the ID attribute of the Message Id Component should be 3742 different from those of the inquired transaction (see section 3743 3.6.1). 3745 3. The OTR checks the transaction status of the transaction being 3746 inquired upon by using the Transaction Id component of the 3747 Transaction Reference Block. OTR generates the appropriate 3748 response block based on the status of the transaction and sends 3749 it back to the OUA(Consumer). The Inquiry Response Block (see 3750 section 5.15) MUST contain: 3752 - one Status Component (see section 6.28). This component hold 3753 the status information on the inquired transaction, 3754 - zero or one Payment Scheme Components. These contain for 3755 encapsulated payment scheme specific inquiry messages for 3756 inquiries on payment. 3758 4.9. Baseline Ping IOTP Transaction 3760 The purpose of the Baseline IOTP Ping Transaction is to enable IOTP 3761 aware application software to determine if the IOTP aware 3762 application at another Trading Role is operating and verifying 3763 whether or not signatures can be handled. 3765 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 3767 - a Ping Request Block (see section 5.16) 3768 - a Ping Response Block (see section 5.17), and 3769 - a Signature Block (see section 5.18). 3771 The verification that signatures can be handled is indicated by 3772 the sender of the Ping Request Block including: 3774 - Organization Components that identify itself and the 3775 intended recipient of the Ping Request Block, and 3776 - a Signature Block that signs data in the Ping Request. 3778 In this way the receiver of the Ping Request: 3780 - knows who is sending the Ping Request and can therefore 3781 verify the Signature on the Request, and 3782 - knows who to generate a signature for on the Ping Response. 3784 Note that a Ping Request: 3786 - does not affect any on-going transaction 3787 - does NOT start an IOTP aware application, unlike other IOTP 3788 transaction messages such as TPO or Transaction Status 3789 Inquiry. 3791 Following sequences of messages are exchanged bewteen the tranding 3792 roles for the Ping transaction: 3794 1. The OUA in an IOTP Trading Role decides to check whether the 3795 counterparty IOTP application is running or not. It generates 3796 a Ping Request Block with an optional Signature Block and sends 3797 it to the other IOTP Trading Role. If the Ping Transaction 3798 is anonymous then no Organization Components are included 3799 in the Ping Request Block (see section 5.6). 3801 2. If the Ping Transaction is not anonymous then the Ping Request 3802 Block MUST contain Organization Components for: 3804 - the sender of the Ping Request Block, and 3805 - the verifier of the Signature Component 3806 - If Organization Components are present, then it indicates 3807 that the sender of the Ping Request message has generated a 3808 Signature Block. The signature block must be verified by 3809 the Trading Role that receives the Ping Request Block. 3811 3. A Baseline IOTP Ping request can also contain an optional 3812 Signature Block. IOTP aware applications can, for example, use the 3813 Signature Block to check the recipient of a Ping Request can 3814 successfully process and check signatures it has received. The 3815 Ping Request Signature Block MUST contain: 3817 - one Signature Component(see section 6.30) 3818 - one or more Certificate Components, if required. 3820 4. The OTR which receives the Ping Request generates a Ping Response 3821 and sends it back to the sender of the original Ping Request. The 3822 Ping Response Block (see section 5.17) MUST contain: 3824 - the Organization Component of the sender of the Ping 3825 Response message 3826 - If the Ping Transaction is not anonymous then the Ping 3827 Response additionally contains: 3828 o copies of the Organization Components contained in the 3829 Ping Request Block. 3831 5. The Ping Response Signature Block (see section 5.18) MUST contain: 3833 - one Signature Component (see section 6.30) 3834 - one or more Certificate Components, if required. 3835 Note: 3836 1. For each Baseline Ping IOTP Transaction, each IOTP role shall 3837 establish a different transport session from other IOTP 3838 transactions. 3840 2. Any IOTP Trading Role can send a Ping request to any other IOTP 3841 Trading Role at any time it wants. A Ping message has its own 3842 OtpTransID, which is different from other IOTP transactions. 3844 3. The OtpTransId of a Ping transaction SHOULD BE different from any 3845 other IOTP transaction. 3847 5. Trading Blocks 3849 Trading Blocks consist of one or more Trading Components and 3850 optionally one or more Signature Components. One or more Trading 3851 Blocks may be contained within the IOTP Messages which are 3852 physically sent in the form of [XML] documents between the 3853 different Organizations that are taking part in a trade. 3855 Trading Blocks are defined as part of the definition of an IOTP 3856 Message (see section 3.1). 3858 This section describes the Trading Blocks used in this version of 3859 IOTP. They are: 3861 - Authentication Request Block 3862 - Authentication Response Block 3863 - Delivery Request Block 3864 - Delivery Response Block 3865 - Error Block 3866 - Inquiry Request Block 3867 - Inquiry Response Block 3868 - Offer Response Block 3869 - Payment Exchange Block 3870 - Payment Request Block 3871 - Payment Response Block 3872 - Payment Instrument Customer Care Exchange Block 3873 - Payment Instrument Customer Care Request Block 3874 - Payment Instrument Customer Care Response Block 3875 - Signature Block 3876 - Trading Protocol Options Block 3877 - TPO Selection Block 3878 The Transaction Reference Block is described in section 3.5. 3880 5.1. Trading Protocol Options Block 3882 The TPO Trading Block contains options which apply to the IOTP 3883 Transaction. The definition of a TPO Trading Block is as follows. 3885 3886 3889 Attributes: 3891 ID An identifier which uniquely identifies the 3892 Trading Protocol Options Block within the 3893 IOTP Transaction (see section 3.6 ID 3894 Attributes). 3896 Content: 3898 ProtocolOptions The Protocol Options Component (see section 3899 6.1)defines the options which apply to the 3900 whole IOTP Transaction (see section 4). 3902 BrandList This Brand List Component contains one or 3903 more payment brands and protocols which may 3904 be selected (see section 6.12). 3906 Org The Organization Components (see section 3907 6.7) identify the Organizations and their 3908 roles in the IOTP Transaction. The roles and 3909 Organizations which must be present will 3910 depend on the particular type of IOTP 3911 Transaction. See the definition of each 3912 transaction in section 4. Open Trading 3913 Protocol Transactions. 3915 The TPO Block should contain: 3917 - the Protocol Options Component 3918 - the Organization Component with the Trading Role of Merchant 3919 - the Organization Component with the Trading Role of Consumer 3920 - optionally, the Organization Component with the Trading Role 3921 of DeliverTo, if there is a Delivery included in the IOTP 3922 Transaction 3923 - Brand List Components for each payment in the IOTP 3924 Transaction 3925 - Organization Components for all the Payment Handlers 3926 involved 3927 - optionally, Organization Components for the Delivery Handler 3928 (if any) for the transaction 3929 - additional Organization Components that the Merchant may 3930 want to include. For example 3932 o a Customer Care Provider 3933 o an Certificate Authority that offers Merchant 3934 "Credentials" or some other warranty on the goods or 3935 services being offered. 3937 5.2. TPO Selection Block 3938 The TPO Selection Block contains the results of selections made 3939 from the options contained in the Trading Protocol Options Block 3940 (see section 5.1).The definition of a TPO Selection Block is as 3941 follows. 3943 TpoSelectionBlk (BrandSelection+) > 3944 3947 Attributes: 3949 ID An identifier which uniquely identifies the 3950 TPO Selection Block within the IOTP 3951 Transaction. 3953 Content: 3955 BrandSelection This identifies the choice of payment brand 3956 and payment protocol to be used in a payment 3957 within the IOTP Transaction. There is one 3958 Brand Selection Component (see section 6.17) 3959 for each payment to be made in the IOTP 3960 Transaction. 3962 The TPO Selection Block should contain one Brand Selection 3963 Component for each Brand List in the TPO Block. 3965 5.3. Offer Response Block 3967 The Offer Response Block contains details of the goods, services, 3968 amount, delivery instructions or financial transaction which is 3969 to take place. Its definition is as follows. 3971 3973 3976 Attributes: 3978 ID An identifier which uniquely identifies the 3979 Offer Response Block within the IOTP 3980 Transaction. 3982 Content: 3984 AuthData The Authentication Data Component contains 3985 information about how Authentication 3986 associated with the Offer will occur. See 3987 section 6.2. 3989 Order The Order Component contains details about 3990 the goods, services or financial transaction 3991 which is taking place see section 6.4. 3993 The Order Component must be present unless 3994 the ProcessState attribute of the Status 3995 Component is set to Failed. 3997 Payment The Payment Components contain information 3998 about the payments which are to be made see 3999 section 6.21. 4001 Delivery The Delivery Component contains details of 4002 the delivery to be made (see section 6.24). 4004 Status Contains status information about the 4005 business success (see section 7.2) or 4006 failure of the generation of the Offer. Note 4007 that in an Offer Response Block, a 4008 ProcessState of NotYetStarted or InProgress 4009 are illegal values. 4011 The Offer Response Block should contain: 4013 - the Order Component for the IOTP Transaction 4014 - Payment Components for each Payment in the IOTP Transaction 4015 - the Delivery Component for IOTP Transaction requires (if any) 4016 - the Authentication Data Component (if required) for each 4017 Payment 4019 5.4. Authentication Request Block 4021 This Authentication Request Block contains the challenge data 4022 which is used to obtain information about and optionally 4023 authenticate a Consumer by another Trading Role. Its definition 4024 is as follows. 4026 4027 4030 Attributes 4032 ID An identifier which uniquely identifies the 4033 Authentication Request Block within the IOTP 4034 Transaction. 4036 Content 4038 AuthData If the Authentication Data Component is not 4039 present it means that the Authentication 4040 Request Block is just requesting the return 4041 of Organization Components which describe 4042 the Consumer. 4044 If the optional Authentication Data 4045 Component (see section 6.2) is present it 4046 contains data which describes what 4047 additional Authentication the consumer must 4048 provide. 4050 5.5. Authentication Response Block 4052 The Authentication Response Block contains the response which 4053 results from processing the Authentication Request Block. Its 4054 definition is as follows. 4056 4057 4060 Attributes: 4062 ID An identifier which uniquely identifies the 4063 Authentication Response Block within the IOTP 4064 Transaction. 4066 Content: 4068 AuthResp The Authentication Response Component which 4069 contains the results of processing the 4070 challenge data in the Authentication Data 4071 Component - see section 6.3. 4073 Org Organization Components which contain 4074 information corresponding to the Consumer 4075 and DelivTo Trading Roles. 4077 5.6. Payment Request Block 4079 The Payment Request Block contains information which requests 4080 that a payment is started. Its definition is as follows. 4082 4084 4087 Attributes: 4089 ID An identifier which uniquely identifies the 4090 Payment Request Block within the IOTP 4091 Transaction. 4093 Content: 4095 AuthData The optional Authentication Data Component 4096 contains data about how Authentication 4097 associated with the payment, if any, will 4098 occur. See section 6.2. 4100 BrandList The Brand List Component contains a list of 4101 one or more payment brands and protocols 4102 which may be selected (see section 6.12). 4104 BrandSelection This identifies the choice of payment brand, 4105 the payment protocol and the payment handler 4106 to be used in a payment within the IOTP 4107 Transaction. There is one Brand Selection 4108 Component (see section 6.17) for each 4109 payment to be made in the IOTP Transaction. 4111 Payment The Payment Components contain information 4112 about the payment which is being made see 4113 section 6.21. 4115 PaySchemeData The Payment Scheme Component contains 4116 payment scheme specific data see section 4117 6.22. 4119 Org The Organization Component contains details 4120 of Organizations involved in the payment 4121 (see section 6.7). The Organizations present 4122 are dependent on the IOTP Transaction and the 4123 data which is to be signed. See section 9 4124 Security Considerations for more details. 4126 The Payment Request Block should contain: 4128 - the Organization Component with a Trading Role of Merchant 4129 - the Organization Component with the Trading Role of Consumer 4130 - the Payment Component for the Payment 4131 - the Brand List Component for the Payment 4132 - the Brand Selection Component for the Brand List 4133 - the Organization Component for the Payment Handler of the 4134 Payment 4135 - the Organization Component (if any) for the Organization 4136 which carried out the previous step, for example another 4137 Payment Handler 4138 - the Organization Component for the Organization which is to 4139 carry out the next step, if any. This may be, for example, 4140 either a Delivery Handler or a Payment Handler. 4141 - the Organization Components for any additional Organizations 4142 that the Merchant has included in the Offer Response Block 4143 - an Optional Payment Scheme Data Component, if required by 4144 the Payment Method as defined in the IOTP supplement for the 4145 payment method. 4147 5.7. Payment Exchange Block 4149 The Payment Exchange Block contains payment scheme specific data 4150 which is exchanged between two of the roles in a trade. Its 4151 definition is as follows. 4153 4154 4157 Attributes: 4159 ID An identifier which uniquely identifies the 4160 Payment Exchange Block within the IOTP 4161 Transaction. 4163 Content: 4165 PaySchemeData This Trading Component contains payment 4166 scheme specific data see section 6.22 4167 Payment Scheme Component. 4169 5.8. Payment Response Block 4171 This Payment Response Block contains a information about the 4172 Payment Status, a Payment Receipt, and an optional payment 4173 protocol message. Its definition is as follows. 4175 4176 4179 Attributes: 4181 ID An identifier which uniquely identifies the 4182 Payment Response Block within the IOTP 4183 Transaction. 4185 Content: 4187 Status Contains status information about the 4188 business success (see section 7.2) or 4189 failure of the payment. Note that in a Pay 4190 Response Block, a ProcessState of 4191 NotYetStarted or InProgress are illegal 4192 values. 4194 PayReceipt Contains payment scheme specific data which 4195 can be used to verify the payment occurred. 4196 See section 6.23 Payment Receipt Component. 4198 PaySchemeData Contains payment scheme specific data see 4199 section, for example a payment protocol 4200 message. See 6.22 Payment Scheme Component. 4202 5.9. Delivery Request Block 4204 The Delivery Request Block contains details of the goods or 4205 services which are to be delivered together with a signature 4206 which can be used to check that delivery is authorised. Its 4207 definition is as follows. 4209 4210 4213 Attributes: 4215 ID An identifier which uniquely identifies the 4216 Delivery Request Block within the IOTP 4217 Transaction. 4219 Content: 4221 Order The Order Component contains details about 4222 the goods, services or financial transaction 4223 which is taking place see section 6.4. 4225 Org The Organization Components (see section 4226 6.7) identify the Organizations and their 4227 roles in the IOTP Transaction. The roles and 4228 Organizations which must be present will 4229 depend on the particular type of IOTP 4230 Transaction. See the definition of each 4231 transaction in section 4. Open Trading 4232 Protocol Transactions. 4234 Delivery The Delivery Component contains details of 4235 the delivery to be made (see section 6.24). 4237 The Delivery Request Block contains: 4239 - the Organization Component with a Trading Role of Merchant 4240 - the Organization Component for the Consumer and DeliverTo 4241 Trading Roles 4242 - the Delivery Component for the Delivery 4243 - the Organization Component for the Delivery Handler. 4244 Specifically the Organization Component identified by the 4245 ActionOrgRef attribute on the Delivery Component 4246 - the Organization Component (if any) for the Organization 4247 which carried out the previous step, for example a Payment 4248 Handler 4249 - the Organization Components for any additional Organizations 4250 that the Merchant has included in the Offer Response Block 4252 5.10. Delivery Response Block 4254 The Delivery Response Block contains a Delivery Note containing 4255 details on how the goods will be delivered. Its definition is as 4256 follows. Note that in a Delivery Response Block a Delivery Status 4257 Element with a DeliveryStatusCode of NotYetStarted or InProgress 4258 is invalid. 4260 4261 4263 Attributes: 4265 ID An identifier which uniquely identifies the 4266 Delivery Response Block within the IOTP 4267 Transaction. 4269 Content: 4271 Status Contains status information about the 4272 business success (see section 7.2) or 4273 failure of the delivery. Note that in a 4274 Delivery Response Block, a ProcessState of 4275 NotYetStarted or InProgress are illegal 4276 values. 4278 DeliveryNote The Delivery Note Component contains details 4279 about how the goods or services will be 4280 delivered (see section 6.26). 4282 5.11. Payment Instrument Customer Care Request Block 4284 The Payment Instrument Customer Care Request Block contains 4285 information which requests that an IOTP Payment Instrument 4286 Customer Care Transaction is started in order to provide Customer 4287 Care for the Consumer's Payment Instrument. Its definition is as 4288 follows. 4290 4291 4294 Attributes: 4296 ID An identifier which uniquely identifies the 4297 Payment Instrument Customer Care Request 4298 Block within the IOTP Transaction. 4300 Content: 4302 PayMethodInfo The Payment Method Information Component 4303 (see section 6.27) contains data which 4304 describes the Payment Method which initiated 4305 the Payment Instrument Customer Care 4306 Transaction 4308 PaySchemeData Optional Payment Scheme Components (see 4309 section 6.22) that contain payment scheme 4310 specific data. The sequence of the Payment 4311 Scheme Components in the Block is the 4312 sequence in which they should be processed 4313 by the Payment Scheme software which 4314 receives this message. 4316 5.12. Payment Instrument Customer Care Exchange Block 4318 The Payment Instrument Customer Care Exchange Block contains 4319 payment scheme specific data which is exchanged between the 4320 Payment Instrument User and the Payment Scheme Customer Care 4321 Provider. Its definition is as follows. 4323 4324 4327 Attributes: 4329 ID An identifier which uniquely identifies the 4330 Payment Instrument Customer Care Exchange 4331 Block within the IOTP Transaction. 4333 Content: 4335 PaySchemeData Optional Payment Scheme Components (see 4336 section 6.22) that contain payment scheme 4337 specific data. The sequence of the Payment 4338 Scheme Components in the Block is the 4339 sequence in which they should be processed 4340 by the Payment Scheme software which 4341 receives this message. 4343 5.13. Payment Instrument Customer Care Response Block 4345 The Payment Instrument Customer Care Response Block contains the 4346 final Payment Scheme Component of the IOTP Payment Instrument 4347 Customer Care Transaction. Its definition is as follows. 4349 4350 4353 Attributes: 4355 ID An identifier which uniquely identifies the 4356 Payment Instrument Customer Care Response 4357 Block within the IOTP Transaction. 4359 Content: 4361 PaySchemeData Optional Payment Scheme Components (see 4362 section 6.22) that contain payment scheme 4363 specific data. The sequence of the Payment 4364 Scheme Components in the Block is the 4365 sequence in which they should be processed 4366 by the Payment Scheme software which 4367 receives this message. 4369 5.14. Inquiry Request Trading Block 4371 The Inquiry Request Trading Block contains an Inquiry Type 4372 Component and an optional Payment Scheme Component to contain 4373 payment scheme specific inquiry messages. 4375 4376 4379 Attributes: 4381 ID An identifier which uniquely identifies the 4382 Inquiry Request Trading Block within the IOTP 4383 Transaction. 4385 Content: 4387 InquiryType Inquiry Type Component (see section 6.29) 4388 that contains the type of inquiry. 4390 PaySchemeData Payment Scheme Component (see section 6.22) 4391 that contains payment scheme specific 4392 inquiry messages for inquiries on payments. 4393 This is present when the Type attribute of 4394 Inquiry Type Component is Payment. 4396 5.15. Inquiry Response Trading Block 4398 The Inquiry Response Trading Block contains a Status Component 4399 and an optional Payment Scheme Component to contain payment 4400 scheme specific inquiry messages. Its purpose is to enquire on 4401 the current status of an IOTP transaction at a server. 4403 4404 4409 Attributes: 4411 ID An identifier which uniquely identifies the 4412 Inquiry Response Trading Block within the 4413 IOTP Transaction. 4415 LastReceivedOtpMs Contains an Element Reference (see section 4416 gRef 3.7) to the Message Id Component (see 4417 section 3.5.2) of the last message this 4418 server has received from the Consumer. If 4419 there is no previously received message from 4420 the Consumer in the pertinent transaction, 4421 this attribute should be contain the value 4422 Null. This attribute exists for debugging 4423 purposes. 4425 LastSentOtpMsgRef Contains an Element Reference (see section 4426 3.7) to the Message Id Component (see 4427 section 3.5.2) of the last message this 4428 server has sent to the Consumer. If there is 4429 no previously sent message to the Consumer 4430 in the pertinent transaction, this attribute 4431 should contain the value Null. This 4432 attribute exists for debugging purposes. 4434 Content: 4436 Status Contains status information about the 4437 business success (see section 7.2) or 4438 failure of a certain trading exchange (i.e., 4439 Offer, Payment, or Delivery). 4441 PaySchemeData Payment Scheme Component (see section 6.22) 4442 that contains payment scheme specific 4443 inquiry messages for inquiries on payments. 4444 This is present when the Type attribute of 4445 StatusType attribute of the Status Component 4446 is set to Payment. 4448 5.16. Ping Request Block 4450 The Ping Request Block is used to determine if a Server is 4451 operating and whether or not cryptography is compatible. 4453 The definition of a Ping Request Block is as follows. 4455 4456 4459 Attributes: 4461 ID An identifier which uniquely identifies the 4462 Ping Request Trading Block within the IOTP 4463 Transaction. 4465 Content: 4467 Org Optional Organization Components (see 4468 section 6.7). 4470 If no Organization Component is present then 4471 the Ping Request is anonymous and simply 4472 determines if the server is operating. 4474 However if Organization Components are 4475 present, then it indicates that the sender 4476 of the Ping Request wants to verify that 4477 digital signatures can be handled. 4479 In this case the sender includes: 4481 an Organization Component that identifies 4482 itself specifying the Trading Role(s) it is 4483 taking in IOTP transactions (Merchant, 4484 Payment Handler, etc) 4485 an Organization Component that identifies 4486 the intended recipient of the message. 4488 These are then used to generate a signature 4489 over the Ping Response Block. 4491 5.17. Ping Response Block 4493 The Ping Response Trading Block provides the result of a Ping 4494 Request. 4496 It contains an Organization Component that identifies the sender 4497 of the Ping Response. 4499 If the Ping Request to which this block is a response contained 4500 Organization Components, then it also contains those Organization 4501 Components. 4503 4504 4511 Attributes: 4513 ID An identifier which uniquely identifies the 4514 Ping Request Trading Block within the IOTP 4515 Transaction. 4517 PingStatusCode Contains a code which shows the status of 4518 the sender software which processes IOTP 4519 messages. Valid values are: 4521 Ok. Everything with the service is working 4522 normally, including the signature 4523 verification. 4524 Busy. Things are working normally but there 4525 may be some delays. 4526 Down. The server is not functioning fully 4527 but can still provide a Ping response. 4529 SigVerifyStatusCo Contains a code which shows the status of 4530 de signature verification. This is present only 4531 when the message containing the Ping Request 4532 Block also contains a Signature Block. Valid 4533 values are: 4535 Ok. The signature has successfully been 4536 verified and proved compatible. 4537 NotSupported The receiver of this Ping 4538 Request Block does not support validation of 4539 signatures. 4540 Fail. Signature verification failed. 4542 Xml:lang Defines the language used in PingStatusDesc. 4543 This is present when PingStatusDesc is 4544 present. 4546 PingStatusDesc Contains a short description of the status 4547 of the server which sends this Ping Response 4548 Block. Servers, if their designers want, can 4549 use this attribute to send more refined 4550 status information than PingStatusCode which 4551 can be used for debugging purposes, for 4552 example. 4554 Content: 4556 Org These are Organization Components (see 4557 section 6.7). 4559 The Organization Components of the sender of 4560 the Ping Response is always included in 4561 addition to the Organization Components sent 4562 in the Ping Request. 4564 Note: Ping Status Code values do not include a value such as 4565 Fail, since, when the software receiving the Ping Request message 4566 is not working at all, no Ping Response message will be sent 4567 back. 4569 5.18. Signature Block 4570 The Signature Block contains one or more Signature Components and 4571 associated Certificates which sign data associated with the IOTP 4572 Transaction. For a general discussion and introduction to how IOTP 4573 uses signatures, see section 9 Security Considerations. The 4574 definition of the Signature Component and certificates is 4575 contained in the paper "Digital Signature for XML - Proposal", 4576 see [XMLSIG]. 4578 The definition of a Signature Block is as follows: 4580 4581 4584 Attributes: 4586 ID An identifier which uniquely identifies the 4587 Signature Block within the IOTP Transaction. 4589 Content: 4591 OtpSig Contains a Digital Signature. See the paper 4592 "Digital Signature for XML - Proposal" 4593 [XMLSIG], for its definition 4595 OtpCert Contains a Digital Certificate. See the 4596 paper "Digital Signature for XML - Proposal" 4597 [XMLSIG], for its definition 4599 The contents of a Signature Block depends on the Trading Block 4600 that is contained in the same IOTP Message as the Signature Block. 4602 5.18.1. Offer Response 4604 A Signature Block which is in the same message as an Offer 4605 Response Block contains just an Offer Response Signature 4606 Component (see section 6.31). 4608 5.18.2. Payment Request 4610 A Signature Block which is in the same message as a Payment 4611 Request Block contains: 4613 - an Offer Response Signature Component (see section 6.31), 4614 and 4615 - if the Payment is dependent on an earlier step (as indicated 4616 by the StartAfter attribute on the Payment Component), then 4617 the Payment Receipt Signature Component (see section 6.32) 4618 generated by the previous step 4620 5.18.3. Payment Response 4622 A Signature Block which is in the same message as a Payment 4623 Response Block contains just a Payment Receipt Signature 4624 Component (see section 6.32) generated by the step. 4626 5.18.4. Delivery Request 4628 A Signature Block which is in the same message as a Delivery 4629 Request Block contains: 4631 - an Offer Response Signature Component (see section 6.31), 4632 and 4633 - the Payment Receipt Signature Component (see section 6.32) 4634 generated by the previous step. 4636 5.19. Error Block 4638 The Error Trading Block contains one or more Error Components 4639 (see section 6.34) which contain information about Technical 4640 Errors (see section 7.1) in an IOTP Message which has been 4641 received by one of the Trading Roles involved in the trade. 4643 For clarity two phrases are defined which are used in the 4644 description of an Error Trading Block: 4646 - message in error. An IOTP message which contains or causes an 4647 error of some kind 4648 - message reporting the error. An IOTP message that contains an 4649 Error Trading Block that describes the error found in a 4650 message in error. 4651 An Error Trading Block may be contained in any message reporting 4652 the error. The action which then follows depends on the severity 4653 of the error. See the definition of an Error Component, for an 4654 explanation of the different types of severity and the actions 4655 which can then occur. 4657 Note: Although, an Error Trading Block can report multiple 4658 different errors using multiple Error Components, there is no 4659 obligation on a developer of an IOTP Aware Application to do so. 4661 The structure of an Error Trading Block is as follows. 4663 4664 4667 Attributes: 4669 ID An identifier which uniquely identifies 4670 the Error Trading Block within the IOTP 4671 Transaction. 4673 Content: 4675 ErrorComp An Error Component (see section 6.34) that 4676 contains information about an individual 4677 Technical Error. 4679 PaySchemeDat An optional Payment Scheme Component (see 4680 a section 6.22) which contains a Payment 4681 Scheme Message. See the appropriate 4682 payment scheme supplement to determine 4683 whether or not this component needs to be 4684 present and for the definition of what it 4685 MUST contain. 4687 6. Trading Components 4689 This section describes the Trading Components used within IOTP. 4690 Trading Components are the child XML elements which occur 4691 immediately below a Trading Block. 4693 The Trading Components described in this section are listed below 4694 in approximately the sequence they are likely to be used: 4696 - Protocol Options Component 4697 - Authentication Data Component 4698 - Authentication Response Component 4699 - Order Component 4700 - Organization Component 4701 - Brand List Component 4702 - Brand Selection Component 4703 - Payment Component 4704 - Payment Scheme Component 4705 - Payment Receipt Component 4706 - Delivery Component 4707 - Delivery Note Component 4708 - Signature Component 4709 - Certificate Component 4710 - Error Component 4711 Note that the following components are listed in other sections 4712 of this specification: 4714 - Transaction Id Component (see section 3.5.1) 4715 - Message Id Component (see section 3.5.2) 4717 6.1. Protocol Options Component 4719 Protocol options are options which apply to the IOTP Transaction 4720 as a whole. Essentially it is used to identify what type of IOTP 4721 Transaction is being carried out. For Baseline IOTP it will 4722 identify one of the "Baseline" IOTP Transactions (see section 4. 4723 Internet Open Trading Protocol Transactions) by name. 4725 The definition of a Protocol Options Component is as follows. 4727 4728 4738 Attributes: 4740 ID An identifier which uniquely identifies the 4741 Protocol Options Component within the IOTP 4742 Transaction. 4744 xml:lang Defines the language used by attributes or 4745 child elements within this component, unless 4746 overridden by an xml:lang attribute on a 4747 child element. See section 3.10 Identifying 4748 Languages. 4750 ShortDesc This contains a short description of the IOTP 4751 Transaction in the language defined by 4752 xml:lang. Its purpose is to provide an 4753 explanation of what type of IOTP Transaction 4754 is being conducted by the parties involved. 4756 It is used to facilitate selecting an 4757 individual transaction from a list of 4758 similar transactions , for example from a 4759 database of IOTP transactions which has been 4760 stored by a Consumer, Merchant, etc. 4762 SenderNetLocn This contains the non secured net location 4763 of the sender of the TPO Block in which the 4764 Protocol Options Component is contained. 4766 It is the net location to which the 4767 recipient of the TPO block should send a TPO 4768 Selection Block if required. 4770 The content of this attribute is dependent 4771 on the Transport Mechanism see the Transport 4772 Mechanism Supplement. 4774 SecureSenderNetLo This contains the secured net location of 4775 cn the sender of the TPO Block in which the 4776 Protocol Options Component is contained. 4778 The content of this attribute is dependent 4779 on the Transport Mechanism see the Transport 4780 Mechanism Supplement. 4782 SuccessNetLocn This contains the net location that the 4783 should be displayed after the IOTP 4784 Transaction has successfully completed. 4786 The content of this attribute is dependent 4787 on the Transport Mechanism see the Transport 4788 Mechanism Supplement. 4790 CancelNetLocn This contains the net location that should 4791 be displayed by the Consumer after the IOTP 4792 Transaction has been cancelled by one of the 4793 Trading Roles. 4795 For this purpose, cancel is defined as 4796 sending or receiving a Fail Trading Block 4797 (see section 5) where the FailType attribute 4798 of all the FailReasons in the block are set 4799 to Cancel. 4801 The content of this attribute is dependent 4802 on the Transport Mechanism see the Transport 4803 Mechanism Supplement. 4805 ErrorNetLocn This contains the net location that should 4806 be displayed after the IOTP Transaction has 4807 failed due to an error. 4809 For this purpose, an error is defined as 4810 sending or receiving an Error Block (see 4811 section 5.23) where the Severity attribute 4812 of at least one of the Error Components (see 4813 section 6.34) in the Error Block is set to 4814 HardError, or there has been an 4815 irrecoverable loss of communication. 4817 The content of this attribute is dependent 4818 on the Transport Mechanism see the Transport 4819 Mechanism Supplement. 4821 6.2. Authentication Data Component 4823 This Trading Component contains data about how an Authentication 4824 within the IOTP Transaction will occur. Its definition is as 4825 follows. 4827 4828 4833 Attributes: 4835 ID An identifier which uniquely identifies the 4836 Authentication Data Component within the IOTP 4837 Transaction. 4839 AuthMethod This identifies the content of the 4840 Authentication Data Component. Valid values 4841 are: 4843 sha1 This indicates that the recipient of 4844 the Authentication Data Component should 4845 generate a hash. See 6.3 Authentication 4846 Response Component. 4847 pay:ppp A payment protocol specific 4848 authentication method. The "ppp" identifies 4849 a payment protocol associated with a payment 4850 exchange which is part of the IOTP 4851 Transaction. In this case the content and 4852 format of the AuthData element is defined 4853 in the appropriate Payment Scheme 4854 supplement. For example if a payment method 4855 "xzpay" provided an authentication method, 4856 then this attribute would have the value 4857 "pay:xzpay" 4858 x-ddd:nnn a user defined authentication 4859 scheme type see section (3.9.3 User Defined 4860 Codes). 4862 ContentSoftwareId This contains information which identifies 4863 the software which generated the content of 4864 the element. Its purpose is to help resolve 4865 interoperability problems that might occur 4866 as a result of incompatibilities between 4867 messages produced by different software. It 4868 is a single text string in the language 4869 defined by xml:lang. It MUST contain, as a 4870 minimum: 4872 the name of the software manufacturer 4873 the name of the software 4874 the version of the software, and 4875 the build of the software 4877 It is recommended that this attribute is 4878 included if the software which generated the 4879 content cannot be identified from the 4880 SoftwareId attribute on the Message Id 4881 Component (see section 3.5.2) 4883 Content: 4885 PackagedContent This contains the challenge data as Packaged 4886 Content (see section 3.8) that is to be 4887 responded to using the method indicated by 4888 AuthMethod. 4890 6.3. Authentication Response Component 4892 This Authentication Response Component contains the results of an 4893 authentication. Its definition is as follows. 4895 4896 4900 Attributes: 4902 ID An identifier which uniquely identifies the 4903 Authentication Response Component within the 4904 IOTP Transaction. 4906 ContentSoftwareId This contains information which identifies 4907 the software which generated the content of 4908 the element. Its purpose is to help resolve 4909 interoperability problems that might occur 4910 as a result of incompatibilities between 4911 messages produced by different software. It 4912 is a single text string in the language 4913 defined by xml:lang. It MUST contain, as a 4914 minimum: 4916 the name of the software manufacturer 4917 the name of the software 4918 the version of the software, and 4919 the build of the software 4921 It is recommended that this attribute is 4922 included if the software which generated the 4923 content cannot be identified from the 4924 SoftwareId attribute on the Message Id 4925 Component (see section 3.5.2) 4927 Content: 4929 PackagedContent This contains the response to the content of 4930 the Authentication Data Component see 4931 section 6.2 as Packaged Content (see section 4932 3.8). 4934 For a payment specific scheme, it may 4935 contain scheme-specific data. Refer to the 4936 scheme-specific supplemental documentation. 4938 6.4. Order Component 4940 An Order Component contains information about an order. Its 4941 definition is as follows. 4943 4944 4954 Attributes: 4956 ID An identifier which uniquely identifies the 4957 Order Component within the IOTP Transaction. 4959 xml:lang Defines the language used by attributes or 4960 child elements within this component, unless 4961 overridden by an xml:lang attribute on a 4962 child element. See section 3.10 Identifying 4963 Languages. 4965 OrderIdentifier This is a code, reference number or other 4966 identifier which the creator of the Order 4967 may use to identify the order. It must be 4968 unique within an IOTP Transaction. If it is 4969 used in this way, then it may remove the 4970 need to specify any content for the Order 4971 element as the reference can be used to look 4972 up the necessary information in a database. 4974 ShortDesc A short description of the order in the 4975 language defined by xml:lang. It is used to 4976 facilitate selecting an individual order 4977 from a list of orders, for example from a 4978 database of orders which has been stored by 4979 a Consumer, Merchant, etc. 4981 OkFrom The date and time in [UTC] format after 4982 which the offer made by the Merchant lapses. 4984 OkTo The date and time in [UTC] format before 4985 which a Value Acquirer may accept the offer 4986 made by the Merchant is not valid. 4988 ApplicableLaw A phrase in the language defined by xml:lang 4989 which describes the state or country of 4990 jurisdiction which will apply in resolving 4991 problems or disputes. 4993 ContentSoftwareId This contains information which identifies 4994 the software which generated the content of 4995 the element. Its purpose is to help resolve 4996 interoperability problems that might occur 4997 as a result of incompatibilities between 4998 messages produced by different software. It 4999 is a single text string in the language 5000 defined by xml:lang. It MUST contain, as a 5001 minimum: 5003 the name of the software manufacturer 5004 the name of the software 5005 the version of the software, and 5006 the build of the software 5008 It is recommended that this attribute is 5009 included if the software which generated the 5010 content cannot be identified from the 5011 SoftwareId attribute on the Message Id 5012 Component (see section 3.5.2) 5014 Content: 5016 PackagedContent An optional description of the order 5017 information as Packaged Content (see section 5018 3.8). 5020 6.5. Order Description Content 5022 The Packaged Content element will normally be required, however 5023 it may be omitted where sufficient information about the purchase 5024 can be provided in the ShortDesc attribute 5026 The description of the order in the Packaged Content should not 5027 include currency and amount information since this is contained 5028 in the payment related trading components (Brand List, Brand 5029 Selection and Payment). 5031 For interoperability, implementations must support Plain Text as 5032 a minimum so that it can be easily displayed. 5034 6.6. OkFrom and OkTo Timestamps 5036 Note that: 5038 the OkFrom date may be later than the OkFrom date on the 5039 Payment Component (see section 6.21) associated with this 5040 order, and 5042 similarly, the OkTo date may be earlier that the OkTo date 5043 on the Payment Component (see section 6.21). 5045 Note: Disclaimer. The following information provided in this note 5046 does not represent formal advice of the Internet Open Trading Protocol 5047 Consortium, any of its members or the authors of this 5048 specification. Readers of this specification must form their own 5049 views and seek their own legal counsel on the usefulness and 5050 applicability of this information. 5052 The merchant in the context of Internet commerce with anonymous 5053 consumers initially frames the terms of the offer on the web 5054 page, and in order to obtain the good or service, the consumer 5055 must accept them. 5057 If there is to be a time-limited offer, it recommended that 5058 merchants communicate this to the consumer and state in the order 5059 description in a manner which is clear to the consumer that: 5060 - the offer is time limited 5061 - the OkFrom and OkTo timestamps specify the validity of the 5062 offer 5063 - the clock, e.g. the merchant's clock, that will be used to 5064 determine the validity of the offer 5066 6.7. Organization Component 5068 The Organization Component provides information about an 5069 individual or an Organization. This can be used for a variety of 5070 purposes. For example: 5072 - to describe the merchant who is selling the goods, 5073 - to identify who made a purchase, 5074 - to identify who will take delivery of goods, 5075 - to provide a customer care contact, 5076 - to describe who will be the Payment Handler. 5078 Its definition is as follows. 5080 5082 5091 Attributes: 5093 ID An identifier which uniquely identifies the 5094 Organization Component within the IOTP 5095 Transaction. 5097 xml:lang Defines the language used by attributes or 5098 child elements within this component, unless 5099 overridden by an xml:lang attribute on a 5100 child element. See section 3.10 Identifying 5101 Languages. 5103 OrgId A code which identifies the Organization 5104 described by the Organization Component. See 5105 6.7.1 Organization IDs, below. 5107 OtpMsgIdPrefix Contains the prefix which must be used for 5108 all IOTP Messages sent by the Organization in 5109 this IOTP Transaction. The values to be used 5110 are defined in 3.6.1 IOTP Message ID 5111 Attribute Definition. 5113 LegalName For Organizations which are companies this 5114 is their legal name in the language defined 5115 by xml:lang. It is required for 5116 Organizations who have a Trading Role other 5117 than Consumer or DeliverTo. 5119 ShortDesc A short description of the Organization in 5120 the language defined by xml:lang. It is 5121 typically the name by which the Organization 5122 is commonly known. For example, if the legal 5123 name was "Blue Meadows Financial Services 5124 Inc.". Then its short name would likely be 5125 "Blue Meadows". 5127 It is used to facilitate selecting an 5128 individual Organization from a list of 5129 Organizations, for example from a database 5130 of Organizations involved in IOTP 5131 Transactions which has been stored by a 5132 consumer. 5134 LogoNetLocn The net location which can be used to 5135 download the logo for the Organization. See 5136 section 0. 5138 The content of this attribute must conform 5139 to [RFC1738]. 5141 Content: 5143 TradingRole See 6.8 Trading Role Element below. 5145 ContactInfo See 6.9 Contact Information Element below. 5147 PersonName See 6.10 Person Name below. 5149 PostalAddress See 6.11 Postal Address below. 5151 6.7.1. Organization IDs 5153 Organization IDs are used by one IOTP Trading Role to identify 5154 another. In order to avoid confusion, this means that these IDs 5155 must be globally unique. 5157 In principle this is achieved in the following way: 5159 - the Organization Id for all trading roles, apart from the 5160 Consumer Trading Role, uses a domain name as their globally 5161 unique identifier, 5162 - the Organization Id for a Consumer Trading Role is allocated 5163 by one of the other Trading Roles in an IOTP Transaction and 5164 is made unique by concatenating it with that other roles' 5165 Organization Id, 5166 - once a Consumer is allocated an Organization Id within an 5167 IOTP Transaction the same Organization Id is used by all the 5168 other trading roles in that IOTP transaction to identify that 5169 Consumer. 5171 Specifically, the content of the Organization ID is defined as 5172 follows: 5174 OrgId ::= NonConsumerOrgId | ConsumerOrgId 5175 NonConsumerOrgId ::= DomainName 5176 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" 5177 NonConsumerOrgId 5178 ConsumerOrgIdPrefix ::= "Consumer:" 5180 ConsumerOrgId If the Organization ID for a Consumer 5181 consists of: 5183 a standard prefix is to identify that the 5184 Organization Id is for a consumer, followed 5185 by 5186 one or more characters which conform to the 5187 definition of an XML "namechar". See [XML] 5188 specifications, followed by 5189 the NonConsumerOrgId for the Organization 5190 which allocated the ConsumerOrgId. It is 5191 normally the Merchant role. 5193 Use of upper and lower case is significant. 5195 NonConsumerOrgId If the Role is not Consumer then this 5196 contains the Canonical Name for the non- 5197 consumer Organization being described by the 5198 Organization Component. See [DNS]. 5200 Note that a NonConsumerOrgId may not start 5201 with the ConsumerOrgIdPrefix. 5203 Use of upper and lower case is not 5204 significant. 5206 Examples of Organization Ids follow: 5208 newjerseybooks.com - a merchant Organization id 5210 westernbank.co.uk - a payment handler Organization id 5212 consumer:1000247ABH/newjerseybooks.com - a consumer 5213 Organization id allocated by a merchant 5215 6.8. Trading Role Element 5217 This identifies the Trading Role of an individual or Organization 5218 in the IOTP Transaction. Note, an Organization may have more than 5219 one Trading Role and several roles may be present in one 5220 Organization element. Its definition is as follows: 5222 5223 5227 Attributes: 5229 TradingRole The trading role of the Organization. Valid 5230 values are: 5232 Consumer. The person or Organization that is 5233 acting in the role of a consumer in the IOTP 5234 Transaction. 5235 Merchant. The person or Organization that is 5236 acting in the role of merchant in the IOTP 5237 Transaction. 5238 PaymentHandler. The financial institution or 5239 other Organization which is a Payment 5240 Handler for the IOTP Transaction 5241 DeliveryHandler. The person or Organization 5242 that is the delivering the goods or services 5243 for the IOTP Transaction 5244 DelivTo. The person or Organization that is 5245 receiving the delivery of goods or services 5246 in the IOTP Transaction 5247 CustCare. The Organization and/or individual 5248 who will provide customer care for an IOTP 5249 Transaction. 5250 x-ddd:nnn a user defined role (see section 5251 3.9.3 User Defined Codes). 5253 ErrorNetLocn The net location to which IOTP messages 5254 containing Error Components with a Severity 5255 of either HardError or TransientError are 5256 sent. See section 6.35 Error Processing 5257 Guidelines for more details. 5259 This attribute must be set when TradingRole 5260 is set to PaymentHandler or DeliveryHandler. 5262 The content of this attribute is dependent 5263 on the Transport Mechanism see the Transport 5264 Mechanism Supplement. 5266 6.9. Contact Information Element 5268 This contains information which can be used to contact an 5269 Organization or an individual. All attributes are optional 5270 however at least one item of contact information should be 5271 present. Its definition is as follows. 5273 5274 5281 Attributes: 5283 xml:lang Defines the language used by attributes 5284 within this element. See section 3.10 5285 Identifying Languages. 5287 Tel A telephone number by which the Organization 5288 may be contacted. Note that this is a text 5289 field and no validation is carried out on 5290 it. 5292 Fax A fax number by which the Organization may 5293 be contacted. Note that this is a text field 5294 and no validation is carried out on it. 5296 Email An email address by which the Organization 5297 may be contacted. Note that this field 5298 should conform to the conventions for 5299 address specifications contained in 5300 [RFC822]. 5302 NetLocn A location on the Internet by which 5303 information about the Organization may be 5304 obtained that can be displayed using a web 5305 browser. 5307 The content of this attribute must conform 5308 to [RFC1738]. 5310 6.10. Person Name Element 5312 This contains the name of an individual person. All fields are 5313 optional however as a minimum either the GivenName or the 5314 FamilyName should be present. Its definition is as follows. 5316 5317 5324 Attributes: 5326 xml:lang Defines the language used by attributes 5327 within this element. See section 3.10 5328 Identifying Languages. 5330 Title A distinctive name; personal appellation, 5331 hereditary or not, denoting or implying 5332 office (e.g. judge, mayor) or nobility (e.g. 5333 duke, duchess, earl), or used in addressing 5334 or referring to a person (e.g. Mr, Mrs, 5335 Miss) 5337 GivenName The primary or main name by which a person 5338 is known amongst and identified by their 5339 family, friends and acquaintances. Otherwise 5340 known as first name or Christian Name. 5342 Initials The first letter of the secondary names 5343 (other than the Given Name) by which a 5344 person is known amongst or identified by 5345 their family, friends and acquaintances. 5347 FamilyName The name by which family of related 5348 individuals are known. It is typically the 5349 part of an individual's name which is passed 5350 on by parents to their children. 5352 6.11. Postal Address Element 5354 This contains an address which can be used, for example, for the 5355 physical delivery of goods, services or letters. Its definition 5356 is as follows. 5358 5359 5369 Attributes: 5371 xml:lang Defines the language used by attributes 5372 within this element. See section 3.10 5373 Identifying Languages. 5375 AddressLine1 The first line of a postal address. e.g. 5376 "The Meadows" 5378 AddressLine2 The second line of a postal address. e.g. 5379 "Sandy Lane" 5381 CityOrTown The city of town of the address. e.g. 5382 "Carpham" 5384 StateOrRegion The state or region within a country where 5385 the city or town is placed. e.g. "Surrey" 5387 Country The country for the address. e.g. "UK" 5389 LegalLocation This identifies whether the address is the 5390 Registered Address for the Organization. At 5391 least one address for the Organization must 5392 have a value set to True unless the Trading 5393 Role is either Consumer or DeliverTo. 5395 6.12. Brand List Component 5397 Brand List Components are contained within the Trading Protocol 5398 Options Block (see section 5.1) of the IOTP Transaction. They 5399 contains lists of: 5401 payment Brands (see also section 2.8 Brands and Brand 5402 Selection), 5404 amounts to be paid in the currencies that are accepted or 5405 offered by the Merchant, 5407 the payment protocols which can be used to make payments 5408 with a Brand, and 5410 the net locations of the Payment Handlers which accept 5411 payment for a payment protocol 5412 The definition of a Brand List Component is as follows. 5414 5417 5423 Attributes: 5425 ID An identifier which uniquely identifies the 5426 Brand List Component within the IOTP 5427 Transaction. 5429 xml:lang Defines the language used by attributes or 5430 child elements within this component, unless 5431 overridden by an xml:lang attribute on a 5432 child element. See section 3.10 Identifying 5433 Languages. 5435 ShortDesc A text description in the language defined 5436 by xml:Lang giving details of the purpose of 5437 the Brand List. This information must be 5438 displayed to the receiver of the Brand List 5439 in order to assist with making the 5440 selection. It is of particular benefit in 5441 allowing a Consumer to distinguish the 5442 purpose of a Brand List when an IOTP 5443 Transaction involves more than one payment. 5445 PayDirection Indicates the direction in which the payment 5446 for which a Brand is being selected is to be 5447 made. Its values may be: 5449 Debit The sender of the Payment Request 5450 Block (e.g. the Consumer) to which this 5451 Brand List relates will make the payment to 5452 the Payment Handler, or 5453 Credit The sender of the Payment Request 5454 Block to which this Brand List relates will 5455 receive a payment from the Payment Handler. 5456 Content: 5458 Brand This describes a Brand. The sequence of the 5459 Brand elements within the Brand List does not 5460 indicate any preference. 5461 It is recommended that software which 5462 processes this Brand List presents Brands in 5463 a sequence which the receiver of the Brand 5464 List prefers. 5466 ProtocolAmount This links a particular Brand to: 5468 the currencies and amounts in CurrencyAmount 5469 elements that can be used with the Brand, 5470 and 5471 the Payment Protocols and Payment Handlers, 5472 which can be used with those currencies and 5473 amounts, and a particular Brand 5475 CurrencyAmount This contains a currency code and an amount. 5477 PayProtocol This contains information about a Payment 5478 Protocol and the Payment Handler which may 5479 be used with a particular Brand. 5481 6.13. Brand Element 5483 A Brand Element describes a brand that can be used for making a 5484 payment. One or more of these elements is carried in each Brand 5485 List Component that has the PayDirection attribute set to Debit. 5486 Exactly one Brand Element may be carried in a Brand List 5487 Component that has the PayDirection attribute set to Credit. 5489 5490 5500 Attributes: 5502 Id Element identifier, potentially referenced 5503 in a Brand Selection Component contained in 5504 a later Payment Request message and 5505 uniquely identifies the Brand element 5506 within the IOTP Transaction. 5508 xml:lang Defines the language used by attributes and 5509 content of this element. See section 3.10 5510 Identifying Languages. 5512 BrandId This contains a unique identifier for the 5513 brand or promotional brand. It is used to 5514 match against a list of Payment Instruments 5515 which the Consumer holds to determine 5516 whether or not the Consumer can pay with 5517 the Brand. 5519 The syntax for a BrandId is as follows: 5521 BrandId ::= UserDefinedCode | 5522 BrandIdDomain ":" BrandValue 5524 Currently the only valid value for the 5525 BrandIdDomain is otp which indicates that 5526 the BrandValue is registered with IOTP. 5528 The valid values for BrandValue for brands 5529 defined within the IOTP Brand domain are 5530 obtainable from the IOTP web site 5531 http:www.otp.org. 5533 A user defined code follows the conventions 5534 defined in section 3.9.3. Uniqueness of a 5535 user defined BrandId is not guaranteed. 5537 BrandName This contains the name of the brand, for 5538 example MasterCard Credit. This is the 5539 description of the Brand which is displayed 5540 to the consumer in the Consumers language 5541 defined by xml:lang. For example it might 5542 be "American Airlines Advantage Visa". Note 5543 that this attribute is not used for 5544 matching against the payment instruments 5545 held by the Consumer. 5547 BrandLogoNetLocn The net location which can be used to 5548 download the logo for the Organization. 5549 The content of this attribute must conform 5550 to [RFC1738]. 5552 BrandNarrative This optional attribute is designed to be 5553 used by the Merchant to indicate some 5554 special conditions or benefit which would 5555 apply if the Consumer selected that brand. 5556 For example "5% discount", "free shipping 5557 and handling", "free breakage insurance for 5558 1 year", "double air miles apply", etc. 5560 ProtocolAmountRefs Identifies the protocols and related 5561 currencies and amounts which can be used 5562 with this Brand. Specified as a list of 5563 ID's of Protocol Amount Elements (see 5564 section 6.14) contained within the Brand 5565 List. 5567 ContentSoftwareId This optional attribute contains 5568 information which identifies the software 5569 which generated the content of the element. 5570 Its purpose is to help resolve 5571 interoperability problems that might occur 5572 as a result of incompatibilities between 5573 messages produced by different software. It 5574 is a single text string in the language 5575 defined by xml:lang. It MUST contain, as a 5576 minimum: 5578 the name of the software manufacturer 5579 the name of the software 5580 the version of the software, and 5581 the build of the software 5583 It is recommended that this attribute is 5584 included if the software which generated 5585 the content cannot be identified from the 5586 SoftwareId attribute on the Message Id 5587 Component (see section 3.5.2) 5589 Content: 5591 PackagedContent Optional Packaged Content (see section 3.8) 5592 containing information about the brand which 5593 may be used by the payment protocol. The 5594 content of this information is defined in 5595 the supplement for a payment protocol which 5596 describes how the payment protocol works 5597 with IOTP. 5599 6.14. Protocol Amount Element 5601 The Protocol Amount element links a Brand to: 5603 the currencies and amounts in Currency Amount Elements (see 5604 section 6.15) that can be used with the Brand, and 5606 the Payment Protocols and Payment Handlers defined in a Pay 5607 Protocol Element (see section 6.16), which can be used with 5608 those currencies and amounts. 5609 Its definition is as follows: 5611 5612 5618 Attributes: 5620 Id Element identifier, potentially referenced 5621 in a Brand element; or in a Brand Selection 5622 Component contained in a later Payment 5623 Request message which uniquely identifies 5624 the Protocol Amount element within the IOTP 5625 Transaction. 5627 PayProtocolRef Contains an Element Reference (see section 5628 3.7) that refers to the Pay Protocol 5629 Element (see section 6.16) that contains 5630 the Payment Protocol and Payment Handlers 5631 that can be used with the Brand. 5633 CurrencyamountRefs Contains a list of Element References (see 5634 section 3.7) that refer to the Currency 5635 Amount Element (see section 6.15) that 5636 describes the currencies and amounts that 5637 can be used with the Brand. 5639 ContentSoftwareId This contains information which identifies 5640 the software which generated the content of 5641 the element. Its purpose is to help resolve 5642 interoperability problems that might occur 5643 as a result of incompatibilities between 5644 messages produced by different software. It 5645 is a single text string in the language 5646 defined by xml:lang. It MUST contain, as a 5647 minimum: 5649 the name of the software manufacturer 5650 the name of the software 5651 the version of the software, and 5652 the build of the software 5653 It is recommended that this attribute is 5654 included if the software which generated 5655 the content cannot be identified from the 5656 SoftwareId attribute on the Message Id 5657 Component (see section 3.5.2) 5659 Content: 5661 PackagedContent Optional Packaged Content (see section 3.8) 5662 containing information about the protocol 5663 amount which may be used by the payment 5664 protocol. The content of this information is 5665 defined in the supplement for a payment 5666 protocol which describes how the payment 5667 protocol works with IOTP. 5669 6.15. Currency Amount Element 5671 A Currency Amount element contains: 5673 - a currency code (and its type), and 5674 - an amount. 5675 - One or more of these elements is carried in each Brand List 5676 Component. 5678 Its definition is as follows: 5680 5681 5687 Attributes: 5689 Id Element identifier, potentially referenced 5690 in a Brand element; or in a Brand Selection 5691 Component contained in a later Payment 5692 Request message which uniquely identifies 5693 the Currency Amount Element within the IOTP 5694 Transaction. 5696 Amount Indicates the amount to be paid in whole and 5697 fractional units of the currency. For 5698 example $245.35 would be expressed "245.35". 5699 Note that values smaller than the smallest 5700 denomination are allowed. For example one 5701 tenth of a cent would be "0.001". 5703 CurrCodeType Indicates the domain of the CurrCode. This 5704 attribute is included so that the currency 5705 code may support non-standard "currencies" 5706 such as frequent flyer points, trading 5707 stamps, etc. Its values may be: 5709 ISO4217 indicates the currency code conforms 5710 to [ISO 4217] 5711 x-ddd:nnn a user defined currency code type 5712 (see section 3.9.3 User Defined Codes). 5714 CurrCode A code which identifies the currency to be 5715 used in the payment. The domain of valid 5716 currency codes is defined by CurrCodeType 5718 Note that Amount, CurrCodeType and CurrCode have identical 5719 meanings to the attributes of the same name on the Payment 5720 Component (see section 6.21). 5722 6.16. Pay Protocol Element 5724 A Pay Protocol element specifies details of a Payment Protocol 5725 and the Payment Handler that can be used with a Brand. One or 5726 more of these elements is carried in each Brand List. 5728 5729 5739 Attributes: 5741 Id Element identifier, potentially referenced 5742 in a Brand element; or in a Brand Selection 5743 Component contained in a later Payment 5744 Request message which uniquely identifies 5745 the Pay Protocol element within the IOTP 5746 Transaction. 5748 xml:lang Defines the language used by attributes and 5749 content of this element. See section 3.10 5750 Identifying Languages. 5752 ProtocolId Consists of a protocol name and version. For 5753 example "SETv1.0". 5755 The value used for the ProtocolId is defined 5756 in the payment supplement for the payment 5757 method. 5759 ProtocolName A narrative description of the payment 5760 protocol and its version in the language 5761 identified by xml:lang. For example "Secure 5762 Electronic Transaction Version 1.0". Its 5763 purpose is to help provide information on 5764 the payment protocol being used if problems 5765 arise. 5767 ActionOrgRef An Element Reference (see section 3.7) to 5768 the Organization Component for the Payment 5769 Handler for the Payment Protocol. 5771 PayReqNetLocn The Net Location indicating where an 5772 unsecured Payment Request message should be 5773 sent if this protocol choice is used. 5775 The content of this attribute is dependent 5776 on the Transport Mechanism (such must 5777 conform to [RFC1738]. 5779 SecPayReqNetLocn The Net Location indicating where a secured 5780 Payment Request message should be sent if 5781 this protocol choice is used. 5783 A secured payment involves the use of a 5784 secure channel such as [SSL] in order to 5785 communicate with the Payment Handler. 5787 The content of this attribute must conform 5788 to [RFC1738]. See also See section 3.11 5789 Secure and Insecure Net Locations. 5791 ContentSoftwareId This contains information which identifies 5792 the software which generated the content of 5793 the element. Its purpose is to help resolve 5794 interoperability problems that might occur 5795 as a result of incompatibilities between 5796 messages produced by different software. It 5797 is a single text string in the language 5798 defined by xml:lang. It MUST contain, as a 5799 minimum: 5800 the name of the software manufacturer 5801 the name of the software 5802 the version of the software, and 5803 the build of the software 5805 It is recommended that this attribute is 5806 included if the software which generated the 5807 content cannot be identified from the 5808 SoftwareId attribute on the Message Id 5809 Component (see section 3.5.2) 5811 Content: 5813 PackagedContent Optional Packaged Content information (see 5814 section 3.8) about the protocol which is 5815 used by the payment protocol. The content of 5816 this information is defined in the 5817 supplement for a payment protocol which 5818 describes how the payment protocol works 5819 with IOTP. An example of its use could be to 5820 include a payment protocol message. 5822 6.17. Brand Selection Component 5824 A Brand Selection Component identifies the choice of payment 5825 brand, payment protocol and the Payment Handler. This element is 5826 used: 5828 - in Payment Request messages within Baseline Purchase and 5829 Baseline Value IOTP Transactions to identify the brand, 5830 protocol and payment handler for a payment, or 5831 - to, optionally, inform a merchant in a purchase of the 5832 payment brand being used so that the offer and order details 5833 can be amended accordingly. 5834 In Baseline IOTP, the integrity of Brand Selection Components is 5835 not guaranteed. However, modification of Brand Selection 5836 Components can only cause denial of service if the payment 5837 protocol itself is secure against message modification, 5838 duplication, and swapping attacks. 5840 The definition of a Brand Selection Component is as follows. 5842 5845 5852 Attributes: 5854 ID An identifier which uniquely identifies the 5855 Brand Selection Component within the IOTP 5856 Transaction. 5858 BrandListRef The Element Reference (see section 3.7) of 5859 the Brand List Component from which a Brand 5860 is being selected 5862 BrandRef The Element Reference of a Brand element 5863 within the Brand List Component that is 5864 being selected that is to be used in the 5865 payment. 5867 ProtocolAmountRef The Element Reference of a Protocol Amount 5868 element within the Brand List Component 5869 which is to be used when making the payment. 5871 CurrencyAmountRef The Element Reference of a Currency Amount 5872 element within the Brand List Component 5873 which is to be used when making the payment. 5875 Content: 5877 BrandSelBrandInfo, This contains any additional data that 5878 BrandSelProtocolAmount may be required by a particular payment 5879 Info, brand or protocol. See sections 6.18, 5880 BrandSelCurrencyAmount 6.19, and 6.20. 5881 Info 5883 The following rules apply: 5885 - the BrandListRef MUST contain the ID of a Brand List 5886 Component in the same IOTP Transaction 5887 - every Brand List Component in the Trading Protocol Options 5888 Block must be referenced by one and only one Brand Selection 5889 Component 5890 - the BrandRef must refer to the ID of a Brand contained 5891 within the Brand List Component referred to by BrandListRef 5892 - the ProtocolAmountRef must refer to one of the Element IDs 5893 listed in the ProtocolAmountRefs attribute of the Brand 5894 element identified by BrandRef 5895 - the CurrencyAmountRef must refer to one of the Element IDs 5896 listed in the CurrencyAmountRefs attribute of the Protocol 5897 Amount Element identified by ProtocolAmountRef. 5899 6.18. Brand Selection Brand Info Element 5901 The Brand Selection Brand Info Element contains any additional 5902 data that may be required by a particular payment brand. See the 5903 IOTP payment method supplement for a description of how and when 5904 it used. 5906 5907 5911 Attributes: 5913 ContentSoftwareId This contains information which identifies 5914 the software which generated the content of 5915 the element. Its purpose is to help resolve 5916 interoperability problems that might occur 5917 as a result of incompatibilities between 5918 messages produced by different software. It 5919 is a single text string in the language 5920 defined by xml:lang. It MUST contain, as a 5921 minimum: 5923 the name of the software manufacturer 5924 the name of the software 5925 the version of the software, and 5926 the build of the software 5928 It is recommended that this attribute is 5929 included if the software which generated the 5930 content cannot be identified from the 5931 SoftwareId attribute on the Message Id 5932 Component (see section 3.5.2) 5934 Content: 5936 PackagedContent Packaged Content information (see section 5937 3.8) that contains additional data that may 5938 be required by a particular payment brand. 5939 See the payment method supplement for IOTP 5940 for rules on how this is used. 5942 6.19. Brand Selection Protocol Amount Info Element 5944 The Brand Selection Protocol Amount Info Element contains any 5945 additional data that is payment protocol specific that may be 5946 required by a particular payment brand or payment protocol. See 5947 the IOTP payment method supplement for a description of how and 5948 when it used. 5950 5951 5955 Attributes: 5957 ContentSoftwareId See section 6.18 Brand Selection Brand Info 5958 Element. 5960 Content: 5962 PackagedContent Packaged Content information (see section 5963 3.8) that contains any additional data that 5964 may be required by a particular payment 5965 brand. See the payment method supplement for 5966 IOTP for rules on how this is used. 5968 6.20. Brand Selection Currency Amount Info Element 5970 The Brand Selection Currency Amount Info Element contains any 5971 additional data that is payment brand and currency specific that 5972 may be required by a particular payment brand. See the IOTP 5973 payment method supplement for a description of how and when it 5974 used. 5976 5977 5981 Attributes: 5983 ContentSoftwareId See section 6.18 Brand Selection Brand Info 5984 Element. 5986 Content: 5988 PackagedContent Packaged Content information (see section 5989 3.8) that contains any additional data 5990 relating to the payment brand and currency. 5991 See the payment method supplement for IOTP 5992 for rules on how this is used. 5994 6.21. Payment Component 5996 A Payment Component contains information used to control how a 5997 payment is carried out. Its provides information on: 5999 - the times within which a Payment with a Payment Handler may 6000 be started 6001 - a reference to the Brand List (see section 6.12) which 6002 identifies the Brands, protocols, currencies and amounts 6003 which can be used to make a payment 6004 - whether or not an authentication of the consumer is required 6005 as part of the payment 6006 - whether or not a payment receipt will be provided 6007 - whether another payment precedes this payment. 6009 Its definition is as follows. 6011 6012 6021 Attributes: 6023 ID An identifier which uniquely identifies the 6024 Payment Component within the IOTP 6025 Transaction. 6027 OkFrom The date and time in [UTC] format after 6028 which a Payment Handler may accept for 6029 processing a Payment Request Block (see 6030 section 5.6) containing the Payment 6031 Component. 6033 OkTo The date and time in [UTC] format before 6034 which a Payment Handler may for processing 6035 accept a Payment Request Block containing 6036 the Payment Component. 6038 BrandListRef An Element Reference (see section 3.7) of a 6039 Brand List Component (see section 6.12) 6040 within the TPO Trading Block for the IOTP 6041 Transaction. The Brand List identifies the 6042 alternative ways in which the payment can be 6043 made. 6045 AuthDataRef An element reference (see section 3.6) of an 6046 Authentication Data Component (see section 6047 6.2) which is to be used for authentication 6048 of the Trading Role which sends the Payment 6049 Request Block containing the Payment 6050 Component to the Payment Handler. If not 6051 present, then no authentication is to take 6052 place. 6054 SignedPayReceipt Indicates whether or not the Payment 6055 Response Block (5.8) generated by the 6056 payment handler for the payment must be 6057 digitally signed. 6059 StartAfter Contains Element References (see section 6060 3.7) of other Payment Components which 6061 describe payments which must be complete 6062 before this payment can start. If no 6063 StartAfter attribute is present then there 6064 are no dependencies and the payment can 6065 start immediately 6067 Contents 6069 PackagedContent This optional element contains "user" data 6070 defined by the Merchant which is required by 6071 the Payment Handler. See section 3.8 6072 Packaged Content Element. 6074 6.22. Payment Scheme Component 6076 A Payment Scheme Component contains payment protocol information 6077 for a specific payment scheme which is transferred between the 6078 parties involved in a payment for example a [SET] message. Its 6079 definition is as follows. 6081 6082 6088 Attributes: 6090 ID An identifier which uniquely identifies 6091 the Payment Scheme Component within the 6092 IOTP Transaction. 6094 ConsumerPaymentId An identifier specified by the Consumer 6095 which, if returned by the Payment Handler 6096 in another Payment Scheme Component or by 6097 other means, will enable the Consumer to 6098 identify which payment is being referred 6099 to. 6101 PaymentHandlerPayId An identifier specified by the Payment 6102 Handler which, if returned by the Consumer 6103 in another Payment Scheme Component, or by 6104 other means, will enable the Payment 6105 Handler to identify which payment is being 6106 referred to. It is required on every 6107 Payment Scheme Component apart from the 6108 one contained in a Payment Request Block. 6110 ContentSoftwareId This contains information which identifies 6111 the software which generated the content 6112 of the element. Its purpose is to help 6113 resolve interoperability problems that 6114 might occur as a result of 6115 incompatibilities between messages 6116 produced by different software. It is a 6117 single text string in the language defined 6118 by xml:lang. It must contain, as a 6119 minimum: 6121 the name of the software manufacturer 6122 the name of the software 6123 the version of the software, and 6124 the build of the software 6125 It is recommended that this attribute is 6126 included if the software which generated 6127 the content cannot be identified from the 6128 SoftwareId attribute on the Message Id 6129 Component (see section 3.5.2) 6131 Content: 6133 PackagedContent Contains the payment scheme protocol 6134 information as Packaged Content (see 6135 section 3.8). See the payment scheme 6136 supplement for the definition of its 6137 content. 6139 6.23. Payment Receipt Component 6141 A Payment Receipt Component contains payment scheme specific data 6142 which can be used after the payment has completed to verify the 6143 payment occurred. Its definition is as follows. 6145 6146 6151 Attributes: 6153 ID An identifier which uniquely identifies the 6154 Payment Receipt Component within the IOTP 6155 Transaction. 6157 PaymentRef Contains an Element Reference (see section 6158 3.7) to the Payment Component (see section 6159 6.21) to which this payment receipt applies 6161 ContentSoftwareId This contains information which identifies 6162 the software which generated the content of 6163 the element. Its purpose is to help resolve 6164 interoperability problems that might occur 6165 as a result of incompatibilities between 6166 messages produced by different software. It 6167 is a single text string in the language 6168 defined by xml:lang. It MUST contain, as a 6169 minimum: 6171 the name of the software manufacturer 6172 the name of the software 6173 the version of the software, and 6174 the build of the software 6176 It is recommended that this attribute is 6177 included if the software which generated the 6178 content cannot be identified from the 6179 SoftwareId attribute on the Message Id 6180 Component (see section 3.5.2) 6182 Content: 6184 PackagedContent Contains the payment scheme specific record 6185 of the payment which can be used for receipt 6186 purposes as Packaged Content (see section 6187 3.8). Each payment scheme defines in its 6188 supplement the structure of the content. 6190 6.24. Delivery Component 6192 The Delivery Element contains information required to deliver 6193 goods or services. Its definition is as follows. 6195 6196 6204 Attributes: 6206 ID An identifier which uniquely identifies the 6207 Delivery Component within the IOTP 6208 Transaction. 6210 xml:lang Defines the language used by attributes or 6211 child elements within this component, unless 6212 overridden by an xml:lang attribute on a 6213 child element. See section 3.10 Identifying 6214 Languages. 6216 DelivExch Indicates if this IOTP Transaction includes 6217 the messages associated with a Delivery 6218 Exchange. Valid values are: 6220 True indicates it does include a Delivery 6221 Exchange 6222 False indicates it does not include a 6223 Delivery Exchange 6225 If set to true then a DeliveryData element 6226 must be present. If set to false it may be 6227 absent. 6229 DelivAndPayResp Indicates if the Delivery Response Block 6230 (see section 5.10) and the Payment Response 6231 Block (see section 5.8 ) are combined into 6232 one IOTP Message. Valid values are: 6234 True indicates both blocks will be in the 6235 same IOTP Message, and 6236 False indicates each block will be in a 6237 different IOTP Message 6239 DelivAndPayResp should not be true if 6240 DelivExch is False. 6242 In practice combining the Delivery Response 6243 Block and Payment Response Block is only 6244 likely to be practical if the Merchant, the 6245 Payment Handler and the Delivery Handler are 6246 the same Organization since: 6248 the Payment Handler must have access to 6249 Order Component information so that they 6250 know what to deliver, and 6251 the Payment Handler must be able to carry 6252 out the delivery 6254 ActionOrgRef An Element Reference to the Organization 6255 Component of the Delivery Handler for this 6256 delivery. 6258 ConsumerDeliveryI An identifier specified by the Consumer 6259 d which, if returned by the Delivery Handler 6260 in another Delivery Component, or by other 6261 means, will enable the Consumer to identify 6262 which Delivery is being referred to. 6264 Content: 6266 DeliveryData Contains details about how the delivery will 6267 be carried out. See 6.25 Delivery Data 6268 Element below. 6270 PackagedContent This optional element contains "user" data 6271 defined for the Merchant which is required 6272 by the Delivery Handler. See section 3.8 6273 Packaged Content Element. 6275 6.25. Delivery Data Element 6277 The DeliveryData element contains information about where and how 6278 goods are to be delivered. Its definition is as follows. 6280 6281 6291 Attributes: 6293 xml:lang Defines the language used by attributes 6294 within this component. See section 3.10 6295 Identifying Languages. 6297 OkFrom The date and time in [UTC] format after 6298 which the Delivery Handler may accept for 6299 processing a Delivery Request Block (see 6300 section 5.9). 6302 OkTo The date and time in [UTC] format before 6303 which the Delivery Handler may accept for 6304 processing a Delivery Request Block. 6306 DelivMethod Indicates the method by which goods or 6307 services may be delivered. Valid values 6308 are: 6310 Post the goods will be delivered by post or 6311 courier 6312 Web the goods will be delivered electronically 6313 in the Delivery Note Component 6314 Email the goods will be delivered 6315 electronically by e-mail 6316 x-ddd:nnn a user defined delivery method 6317 see 3.9.3 User Defined Codes. 6319 DelivToRef The Element Reference (see section 3.6) of 6320 an Organization Component within the IOTP 6321 Transaction which has a role of DelivTo. 6322 The information in this block is used to 6323 determine where delivery is to be made. It 6324 must be compatible with DelivMethod. 6325 Specifically if the DelivMethod is: 6327 Post, then the there must be a Postal 6328 Address Element containing sufficient 6329 information for a postal delivery, 6330 Web, then there are no specific 6331 requirements. The information will be sent 6332 in a web page back to the Consumer 6333 Email, then there must be Contact 6334 Information Element with a valid e-mail 6335 address 6337 DelivReqNetLocn This contains the Net Location to which an 6338 unsecured Delivery Request Block (see 6339 section 5.9) which contains the Delivery 6340 Component should be sent. 6342 The content of this attribute is dependent 6343 on the Transport Mechanism must conform to 6344 [RFC1738]. 6346 SecDelivReqNetLocn This contains the Net Location to which a 6347 secured Delivery Request Block (see section 6348 5.9) which contains the Delivery Component 6349 should be sent. 6351 A secured delivery request involves the use 6352 of a secure channel such as [SSL] in order 6353 to communicate with the Payment Handler. 6355 The content of this attribute is dependent 6356 on the Transport Mechanism must conform to 6357 [RFC1738]. 6359 See also Section 3.11 Secure and Insecure 6360 Net Locations. 6362 ContentSoftwareId This contains information which identifies 6363 the software which generated the content of 6364 the element. Its purpose is to help resolve 6365 interoperability problems that might occur 6366 as a result of incompatibilities between 6367 messages produced by different software. It 6368 is a single text string in the language 6369 defined by xml:lang. It MUST contain, as a 6370 minimum: 6372 the name of the software manufacturer 6373 the name of the software 6374 the version of the software, and 6375 the build of the software 6377 It is recommended that this attribute is 6378 included if the software which generated 6379 the content cannot be identified from the 6380 SoftwareId attribute on the Message Id 6381 Component (see section 3.5.2) 6383 Content: 6385 PackagedContent Optional additional information about the 6386 delivery as Packaged Content (see section 6387 3.8). provided to the Delivery Handler by 6388 the merchant. 6390 6.26. Delivery Note Component 6392 A Delivery Note contains delivery instructions about the delivery 6393 of goods or services or potentially the actual Delivery 6394 Information itself. It is information which the person or 6395 Organization receiving the Delivery Note can use when delivery 6396 occurs. 6398 6399 6405 Attributes: 6407 ID An identifier which uniquely identifies the 6408 Delivery Note Component within the IOTP 6409 Transaction. 6411 xml:lang Defines the language used by attributes or 6412 child elements within this component, unless 6413 overridden by an xml:lang attribute on a 6414 child element. See section 3.10 Identifying 6415 Languages. 6417 DelivHandlerDeliv An optional identifier specified by the 6418 Id Delivery Handler which, if returned by the 6419 Consumer in another Delivery Component, or 6420 by other means, will enable the Delivery 6421 Handler to identify which Delivery is being 6422 referred to. It is required on every 6423 Delivery Component apart from the one 6424 contained in a Delivery Request Block. 6426 An example use of this attribute is to 6427 contain a delivery tracking number. 6429 ContentSoftwareId This contains information which identifies 6430 the software which generated the content of 6431 the element. Its purpose is to help resolve 6432 interoperability problems that might occur 6433 as a result of incompatibilities between 6434 messages produced by different software. It 6435 is a single text string in the language 6436 defined by xml:lang. It MUST contain, as a 6437 minimum: 6439 - the name of the software manufacturer 6440 - the name of the software 6441 - the version of the software, and 6442 - the build of the software 6444 It is recommended that this attribute is 6445 included if the software which generated the 6446 content cannot be identified from the 6447 SoftwareId attribute on the Message Id 6448 Component (see section 3.5.2) 6450 Content: 6452 DeliveryNote Contains the actual delivery note 6453 information as Packaged Content (see section 6454 3.8). 6456 Note: If the content of the Delivery Message is a Mime message 6457 then the Delivery Note may trigger an application which causes 6458 the actual delivery to occur. 6460 6.27. Payment Method Information Component 6462 A Payment Method Information Component contains data which 6463 describes the Payment Method which initiated the Payment 6464 Instrument Customer Care Transaction and the software which 6465 generated the message. Its definition is as follows. 6467 6468 6473 Attributes: 6475 ID An identifier which uniquely identifies the 6476 Payment Method Information Component within 6477 the IOTP Transaction. 6479 BrandId The Brand Identifier attribute copied from 6480 the BrandId attribute of the Brand Element 6481 (see section 6.13)of the Payment Instrument 6482 which needs customer care. 6484 PayProtocolId The ProtocolId attribute copied from the Pay 6485 Protocol Element (see section 6.16) of the 6486 Brand being used. This may not be required 6487 for all types of Payment Instrument. See the 6488 IOTP Supplement for the Payment Method to 6489 determine if this is to be used. 6491 6.28. Status Component 6493 A Status Component contains status information about the business 6494 success or failure (see section 7.2) of a process. 6496 Its definition is as follows. 6498 6499 6510 Attributes: 6512 ID An identifier which uniquely identifies the 6513 Status Component within the IOTP Transaction. 6515 xml:lang Defines the language used by attributes 6516 within this component. See section 3.10 6517 Identifying Languages. 6519 StatusType Indicates the type of process which the 6520 Status is reporting on. It may be set to 6521 either Offer, Payment or Delivery. 6523 ElRef Contains an Element Reference (see section 6524 3.7) to the Component for which the Status 6525 is being described. It must refer to either: 6527 a Trading Protocol Options Block (see 6528 section 5.1), if the StatusType is Offer, 6529 a Payment Component (see section 6.21), if 6530 the StatusType is Payment, or 6531 a Delivery Component (see section 6.24), if 6532 the StatusType is Delivery. 6534 ProcessState Contains a State Code which indicates the 6535 current state of the process being carried 6536 out. Valid values for ProcessState are: 6538 NotYetStarted. A Request Block has been 6539 received but the process has not yet started 6540 InProgress. Processing of the Request Block 6541 has started but it is not yet complete 6542 CompletedOk. The processing of the Request 6543 Block has completed successfully without any 6544 errors 6545 Failed. The processing of the Request Block 6546 has failed because of a business error (see 6547 section 7.2) 6548 ProcessError. This value is only used when 6549 the Status Component is being used in 6550 connection with an Inquiry Request Trading 6551 Block (see section 5.14). It indicates there 6552 was a Technical Error (see section 7.1) in 6553 the Request Block which is being processed 6554 or some internal processing error. 6556 Note that this code reports on the 6557 processing of a Request Block. Further, 6558 asynchronous processing may occur after the 6559 Response Block associated with the Process 6560 has been sent to the Consumer. 6562 CompletionCode Indicates how the process completed. Valid 6563 values for the CompletionCode are given 6564 below together with the conditions when it 6565 must be present. 6567 A CompletionCode is a maximum of 14 6568 characters long. 6570 ProcessReference This optional attribute holds a reference 6571 for the process whose status is being 6572 reported. It may hold the following values: 6574 when StatusType is set to Offer, it should 6575 contain the OrderIdentifier from the Order 6576 Component 6577 when StatusType is set to Payment, it should 6578 contain the PaymentHandlerPayId from the 6579 Payment Scheme Data Component 6580 when StatusType is set to Delivery, it 6581 should contain the DelivHandlerDelivId from 6582 the Delivery Note Component 6584 This attribute should be absent in the 6585 Inquiry Request message when the Consumer 6586 has not been given such a reference number 6587 by the IOTP Service Provider. 6589 This attribute can be used in an Inquiry 6590 Response Block (see section 5.15) to give 6591 the Consumer the reference number for a 6592 transaction which has previously been 6593 unavailable. 6595 For example, the package tracking number 6596 might not be assigned at the time of a 6597 delivery response was received. However, if 6598 the Consumer issues a Baseline Transaction 6599 Status Inquiry later, the Delivery Handler 6600 can put the package tracking number into 6601 this attribute in the Inquiry Response 6602 message and send it back to the Consumer. 6604 StatusDesc An optional textual description of the 6605 current status of the payment in the 6606 language identified by xml:lang. 6608 6.28.1. Offer Completion Codes 6610 The Completion Code is only required if the ProcessState 6611 attribute is set to Failed. The following table contains the 6612 valid values for the CompletionCode that may be used. It is 6613 recommended that the StatusDesc attribute is used to provide 6614 further explanation where appropriate. 6616 Value Description 6617 ========= ============================================= 6619 AuthError Authentication Error. The authentication 6620 check which was carried out has failed. 6622 OfferDecl Offer Declined. The Merchant declines to 6623 generate an offer for some reason. 6625 Unspecified Unspecified error. There is some unknown 6626 problem or error which does not fall into 6627 one of the other CompletionCodes. 6629 6.28.2. Payment Completion Codes 6631 The CompletionCode is only required if the ProcessState attribute 6632 is set to Failed. The following table contains the valid values 6633 for the CompletionCode that may be used. It is recommended that 6634 the StatusDesc attribute is used by individual payment schemes to 6635 provide further explanation where appropriate. 6637 Value Description 6638 ========= ============================================= 6640 BrandNotSupp Brand not supported. The payment brand is 6641 not supported by the Payment Handler. 6643 CurrNotSupp Currency not supported. The currency in 6644 which the payment is to be made is not 6645 supported by either the Payment Instrument 6646 or the Payment Handler. 6648 AuthError Authentication Error. The Payment Scheme 6649 specific authentication check which was 6650 carried out has failed. 6652 InsuffFunds Insufficient funds. There are insufficient 6653 funds available for the payment to be made. 6655 InstBrandInvalid Payment Instrument not valid for Brand. A 6656 Payment Instrument is being used which does 6657 not correspond with the Brand selected. For 6658 example a Visa credit card is being used 6659 when MasterCard was selected as the Brand. 6661 PaymntDecl Payment declined. The Payment Handler 6662 declines to accept the payment for some 6663 reason. 6665 InstNotValid Payment instrument not valid for trade. The 6666 Payment Instrument cannot be used for the 6667 proposed type of trade, for some reason. 6669 BadInstrumenat Bad instrument. There is a problem with the 6670 Payment Instrument being used which means 6671 that it is unable to be used for the 6672 payment. 6674 Unspecified Unspecified error. There is some unknown 6675 problem or error which does not fall into 6676 one of the other CompletionCodes. The 6677 StatusDesc attribute should provide the 6678 explanation of the cause. 6680 6.28.3. Delivery Completion Codes 6682 The following table contains the valid values for the 6683 CompletionCode attribute for a Delivery. It is recommended that 6684 the StatusDesc attribute is used to provide further explanation 6685 where appropriate. 6687 Value Description 6688 ========= ============================================= 6690 BackOrdered Back Ordered. The goods to be delivered are 6691 on order but they have not yet been 6692 received. Shipping will be arranged when 6693 they are received. This is only valid if 6694 ProcessState is CompletedOk. 6696 PermNotAvail Permanently Not Available. The goods are 6697 permanently unavailable and cannot be re- 6698 ordered. This is only valid if ProcessState 6699 is Failed. 6701 TempNotAvail Temporarily Not Available. The goods are 6702 temporarily unavailable and may become 6703 available if they can be ordered. This is 6704 only valid if ProcessState is CompletedOk. 6706 ShipPending Shipping Pending. The goods are available 6707 and are scheduled for shipping but they have 6708 not yet been shipped. This is only valid if 6709 ProcessState is CompletedOk. 6711 Shipped Goods Shipped. The goods have been shipped. 6712 Confirmation of delivery is awaited. This is 6713 only valid if ProcessState is CompletedOk. 6715 ShippedNoConf Shipped - No Delivery Confirmation. The 6716 goods have been shipped but it is not 6717 possible to confirm delivery of the goods. 6718 This is only valid if ProcessState is 6719 CompletedOk. 6721 Confirmed Confirmed. All goods have been delivered and 6722 confirmation of their delivery has been 6723 received. This is only valid if ProcessState 6724 is CompletedOk. 6726 6.29. Inquiry Type Component 6728 The Inquiry Component contains the information which indicates 6729 what type of process is being inquired upon. 6731 6732 6738 Attributes: 6740 ID An identifier which uniquely identifies the 6741 Inquiry Type Component within the IOTP 6742 Transaction. 6744 Type Contains the type of inquiry. Valid values 6745 for Type are: 6747 Offer. The inquiry is about the status of an 6748 offer and is addressed to the Merchant. 6749 Payment. The inquiry is about the status of 6750 a payment and is addressed to the Payment 6751 Handler. 6752 Delivery. The inquiry is about the status of 6753 a delivery and addressed to the Delivery 6754 Handler. 6756 ElRef Contains an Element Reference (see section 6757 3.7) to the component to which this Inquiry 6758 Type Component applies. That is, 6760 TPO Block when Type is Offer 6761 Payment Component when Type is Payment 6762 Delivery Component when Type is Delivery 6764 ProcessReference Optionally contains a reference to the 6765 process being inquired upon. It should be 6766 set if the information is available. For the 6767 definition of the values it may contain, see 6768 the ProcessReference attribute of the Status 6769 Component (see section 6.28). 6771 6.30. Signature Component 6773 Each Signature Component digitally signs one or more Blocks or 6774 Components including other Signature Components. 6776 For a general explanation of signatures see section 9 Security 6777 Considerations. Detailed definitions of the XML structures for 6778 signatures is described in the paper "Digital Signature for XML - 6779 Proposal", see [XMLSIG]. 6781 The Signature Component: 6783 - hashes one or more Blocks or Components in one or more IOTP 6784 Messages within the same IOTP Transaction 6785 - concatenates these hashes into a Signed Data element, and 6786 - signs the SignedData element using the optional certificate 6787 identified in the CertRef attribute of the Digital Signature 6788 element. 6790 Note that a Signed Data Element may be signed by more than one 6791 Digital Signature element. 6793 A Signature Component can be one of two types either: 6795 - an Offer Response Signature, or 6796 - a Payment Response Signature 6798 How these signatures are constructed is described below 6800 6.31. Offer Response Signature Component 6802 The Signed Data Element of the Offer Response Signature Component 6803 should contain hashes of the following Components: 6805 - the Transaction Id Component (see section 3.5.1) of the IOTP 6806 message that contains the Offer Response Signature 6807 - the Transaction Reference Block (see section 3.5) of the IOTP 6808 Message that contains the Offer Response Signature 6809 - from the TPO Block: 6811 o the Protocol Options Component 6813 o each of the Organization Components 6815 o each of the Brand List Components 6817 - optionally, all the Brand Selection Components if they were 6818 sent to the Merchant in a TPO Selection Block 6819 - from the Offer Response Block: 6821 o the Order Component 6823 o each of the Payment Components 6825 o the Delivery Component 6827 - each of the Authentication Data Components 6828 The Offer Response Signature Component should also contain 6829 Digital Signature Elements for each of the Organizations that may 6830 or will need to verify the signature. This involves: 6832 - if the Merchant has received a TPO Selection Block 6833 containing Brand Selection Components, then generate a 6834 Digital Signature Element for the Payment Handler identified 6835 by the Brand Selection Component and the Delivery Handler 6836 identified by the Delivery Component. See section 9.7 Check 6837 the Action Request was sent to the Correct Organization for 6838 a description of how this can be done. 6839 - if the Merchant is not expecting to receive a TPO Selection 6840 Block then generate a Digital Signature Element for the 6841 Delivery Handler and all the Payment Handlers that are 6842 involved. 6844 6.32. Payment Receipt Signature Component 6845 The Signed Data Element of the Payment Receipt Signature 6846 Component should contain hashes of the following Components: 6848 - the Transaction Id Component (see section 3.5.1) of the IOTP 6849 message that contains the Payment Receipt Signature 6850 - the Transaction Reference Block (see section 3.5) of the IOTP 6851 Message that contains the Payment Receipt Signature 6852 - the Offer Response Signature Component 6853 - the Payment Receipt Component 6854 - the Status Component 6855 - the Brand Selection Component. 6857 6.33. Ping Signature Components 6859 If the Ping Response Transaction is generating a signature (see 6860 section 4.8), the Signed Data Element of the Ping Response or 6861 Ping Request Signature Components should contain hashes of the 6862 following Components: 6864 - all the Organization Components. 6866 6.34. Error Component 6868 The Error Component contains information about Technical Errors 6869 (see section 7.1) in an IOTP Message which has been received by 6870 one of the Trading Roles involved in the trade. 6872 For clarity two phrases are defined which are used in the 6873 description of an Error Component: 6875 - message in error. An IOTP message which contains or causes an 6876 error of some kind 6877 - message reporting the error. An IOTP message that contains an 6878 Error Component that describes the error found in a message 6879 in error. 6880 The definition of the Error Component is as follows. 6882 6883 6892 Attributes: 6894 ID An identifier which uniquely identifies the 6895 Error Component within the IOTP Transaction. 6897 xml:lang Defines the language used by attributes or 6898 child elements within this component, unless 6899 overridden by an xml:lang attribute on a 6900 child element. See section 3.10 Identifying 6901 Languages. 6903 ErrorCode Contains an error code which indicates the 6904 nature of the error in the message in error. 6905 Valid values for the ErrorCode are given in 6906 section 6.36 Error Codes. 6908 ErrorDesc Contains a narrative description of the 6909 error in the language defined by xml:lang. 6910 The content of this attribute is defined by 6911 the vendor/developer of the software which 6912 generated the Error Component 6914 Severity Indicates the severity of the error. Valid 6915 values are: 6917 Warning. This indicates that although there 6918 is a message in error the IOTP Transaction 6919 can still continue. 6920 TransientError. This indicates that the 6921 error in the message in error may be 6922 recovered if the message in error that is 6923 referred to by the ErrorLocation element is 6924 resent 6925 HardError. This indicates that there is an 6926 unrecoverable error in the message in error 6927 and the IOTP Transaction must stop. 6929 MinRetrySecs This attribute should be present if Severity 6930 is set to TransientError. It is the minimum 6931 number of whole seconds which the IOTP aware 6932 application which received the message 6933 reporting the error should wait before re- 6934 sending the message in error identified by 6935 the ErrorLocation element. 6937 If Severity is not set to TransientError 6938 then the value of this attribute is ignored. 6940 SwVendorErrorRef This attribute is a reference whose value is 6941 set by the vendor/developer of the software 6942 which generated the Error Component. It 6943 should contain data which enables the vendor 6944 to identify the precise location in their 6945 software and the set of circumstances which 6946 caused the software to generate a message 6947 reporting the error. See also the SoftwareId 6948 attribute of the Message Id element in the 6949 Transaction Reference Block (section 3.5). 6951 Content: 6953 ErrorLocation This identifies the IOTP Transaction Id of 6954 the message in error and, where possible, 6955 the element and attribute in the message in 6956 error that caused the Error Component to be 6957 generated. 6959 If the Severity of the error is not 6960 TransientError, more than one ErrorLocation 6961 may be specified as appropriate depending on 6962 the nature of the error (see section 6.36 6963 Error Codes) and at the discretion of the 6964 vendor/developer of the IOTP Aware 6965 Application. 6967 PackagedContent This contains additional data which can be 6968 used to understand the error. Its content 6969 may vary as appropriate depending on the 6970 nature of the error (see section 6.36 Error 6971 Codes) and at the discretion of the 6972 vendor/developer of the IOTP Aware 6973 Application. For a definition of 6974 PackagedContent see section 3.8. 6976 6.35. Error Processing Guidelines 6977 If there is more than one Error Component in a message reporting 6978 the error, carry out the actions appropriate for the Error 6979 Component with the highest severity. In this context, HardError 6980 has a higher severity than TransientError, which has a higher 6981 severity than Warning. 6983 6.35.1. Severity - Warning 6985 If an IOTP aware application is generating a message reporting the 6986 error with an Error Component where the Severity attribute is set 6987 to Warning, then if the message reporting the error does not 6988 contain another Error Component with a severity higher than 6989 Warning, the IOTP Message must also include the Trading Blocks and 6990 Trading Components that would have been included if no error was 6991 being reported. 6993 If a message reporting the error is received with an Error 6994 Component where Severity is set to Warning, then: 6996 it is recommended that information about the error is either 6997 logged, or otherwise reported to the user, 6999 the implementer of the IOTP aware application must either, at 7000 their or the user's discretion: 7001 - continue the IOTP transaction as normal, or 7002 - fail the IOTP transaction by generating a message reporting 7003 the error with an Error Component with Severity set to 7004 HardError (see section 6.35.3). 7005 If the intention is to continue the IOTP transaction then, if 7006 there are no other Error Components with a higher severity, check 7007 that the necessary Trading Blocks and Trading Components for 7008 normal processing of the transaction to continue are present. If 7009 they are not then generate a message reporting the error with an 7010 Error Component with Severity set to HardError. 7012 6.35.2. Severity - Transient Error 7014 If an IOTP Aware Application is generating a message reporting the 7015 error with an Error Component where the Severity attribute is set 7016 to TransientError, then there should be only one Error Component 7017 in the message reporting the error. In addition, the MinRetrySecs 7018 attribute should be present. 7020 If a message reporting the error is received with an Error 7021 Component where Severity is set to TransientError then: 7023 if the MinRetrySecs attribute is present and a valid number, 7024 then use the MinRetrySecs value given. Otherwise if 7025 MinRetrySecs is missing or is invalid, then: 7026 - generate a message reporting the error containing an Error 7027 Component with a Severity of Warning and send it on the next 7028 IOTP message (if any) to be sent to the Trading Role which 7029 sent the message reporting the error with the invalid 7030 MinRetrySecs, and 7031 - use a value for MinRetrySecs which is set by the 7032 vendor/developer of the IOTP Aware Application. 7034 check that only one ErrorLocation element is contained 7035 within the Error Component and that it refers to an IOTP 7036 Message which was sent by the recipient of the Error 7037 Component with a Severity of TransientError. If more than 7038 one ErrorLocation is present then generate a message 7039 reporting the error with a Severity of HardError. 7041 6.35.3. Severity - Hard Error 7043 If an IOTP Aware Application is generating a message reporting the 7044 error with an Error Component where the Severity attribute set to 7045 HardError, then there should be only one Error Component in the 7046 message reporting the error. 7048 If a message reporting the error is received with an Error 7049 Component where Severity is set to HardError then terminate the 7050 IOTP Transaction. 7052 6.36. Error Codes 7054 The following table contains the valid values for the ErrorCode 7055 attribute of the Error Component. The first sentence of the 7056 description contains the text that should be used to describe the 7057 error when displayed or otherwise reported. Individual 7058 implementations may translate this into alternative languages at 7059 their discretion. 7061 An Error Code must not be more that 14 characters long. 7063 Value Description 7064 ========= ============================================= 7065 Reserved Reserved. This error is reserved by the 7066 vendor/developer of the software. Contact 7067 the vendor/developer of the software for 7068 more information See the SoftwareId 7069 attribute of the Message Id element in the 7070 Transaction Reference Block(section 3.5). 7072 XmlNotWellFrmd XML not well formed. The XML document is not 7073 well formed. See [XML] for the meaning of 7074 "well formed". Even if the XML is not well 7075 formed, it should still be scanned to find 7076 the Transaction Reference Block so that a 7077 properly formed Error Response may be 7078 generated. 7080 XmlNotValid XML not valid. The XML document is well 7081 formed but the document is not valid. See 7082 [XML] for the meaning of "valid". 7083 Specifically: 7085 the XML document does not comply with the 7086 constraints defined in the IOTP document type 7087 declaration (see section Error! Reference 7088 source not found. Error! Reference source 7089 not found.), and 7090 the XML document does not comply with the 7091 constraints defined in the document type 7092 declaration of any additional [XML 7093 Namespace] that are declared. 7095 As for XML not well formed, attempts should 7096 still be made to extract the Transaction 7097 Reference Block so that a properly formed 7098 Error Response may be generated. 7100 ElUnexpected Unexpected element. Although the XML 7101 document is well formed and valid, an 7102 element is present that is not expected in 7103 the particular context according to the 7104 rules and constraints contained in this 7105 specification. 7107 ElNotSupp Element not supported. Although the document 7108 is well formed and valid, an element is 7109 present that: 7111 is consistent with the rules and constraints 7112 contained in this specification, but 7113 is not supported by the IOTP Aware 7114 Application which is processing the IOTP 7115 Message. 7117 ElMissing Element missing. Although the document is 7118 well formed and valid, an element is missing 7119 that should have been present if the rules 7120 and constraints contained in this 7121 specification are followed. 7122 In this case set the PackagedContent of the 7123 Error Component to the type of the missing 7124 element. 7126 ElContIllegal Element content illegal. Although the 7127 document is well formed and valid, the 7128 element PackagedContent contains values 7129 which do not conform to the rules and 7130 constraints contained in this specification. 7132 EncapProtErr Encapsulated protocol error. Although the 7133 document is well formed and valid, the 7134 PackagedContent of an element contains data 7135 from an encapsulated protocol which contains 7136 errors. 7138 AttUnexpected Unexpected attribute. Although the XML 7139 document is well formed and valid, the 7140 presence of the attribute is not expected in 7141 the particular context according to the 7142 rules and constraints contained in this 7143 specification. 7145 AttNotSupp Attribute not supported. Although the XML 7146 document is well formed and valid, and the 7147 presence of the attribute in an element is 7148 consistent with the rules and constraints 7149 contained in this specification, it is not 7150 supported by the IOTP Aware Application which 7151 is processing the IOTP Message. 7153 AttMissing Attribute missing. Although the document is 7154 well formed and valid, an attribute is 7155 missing that should have been present if the 7156 rules and constraints contained in this 7157 specification are followed. 7159 In this case set the PackagedContent of the 7160 Error Component to the type of the missing 7161 attribute. 7163 AttValIllegal Attribute value illegal. The attribute 7164 contains a value which does not conform to 7165 the rules and constraints contained in this 7166 specification. 7168 AttValNotRecog Attribute Value Not Recognised. The 7169 attribute contains a value which the IOTP 7170 Aware Application generating the message 7171 reporting the error could not recognise even 7172 though it should have been able to since the 7173 information had been provided in an earlier 7174 IOTP message. 7176 MsgTooLarge Message too large. The message is too large 7177 to be processed by the IOTP Aware 7178 Application. 7180 ElTooLarge Element too large. The element is too large 7181 to be processed by the IOTP Aware Application 7183 ValueTooSmall Value too small or early. The value of all 7184 or part of the PackagedContent of an 7185 element or an attribute, although valid, is 7186 too small. 7188 ValueTooLarge Value too large or in the future. The value 7189 of all or part of the PackagedContent of an 7190 element or an attribute, although valid, is 7191 too large. 7193 ElInconsistent Element Inconsistent. Although the document 7194 is well formed and valid, according to the 7195 rules and constraints contained in this 7196 specification: 7198 the content of an element is inconsistent 7199 with the content of other elements or their 7200 attributes, or 7201 the value of an attribute is inconsistent 7202 with the value of one or more other 7203 attributes. 7205 In this case create ErrorLocation elements 7206 which identify all the attributes or 7207 elements which are inconsistent. 7209 TransportError Transport Error. This error code is used to 7210 indicate that there is a problem with the 7211 Transport Mechanism which is preventing the 7212 message from being received. It is typically 7213 associated with a Transient Error. 7214 Explanation of the Transport Error is 7215 contained within the ErrorDesc attribute. 7216 The values which can be used inside 7217 ErrorDesc with a TransportError is specified 7218 in the IOTP supplement for the Transport 7219 mechanism. 7221 6.37. Error Location Element 7223 An Error Location Element identifies an element and optionally an 7224 attribute in the message in error which is associated with the 7225 error. It contains a reference to the IOTP Message, Trading Block, 7226 Trading Component, element and attribute, which is in error. 7228 7229 7237 Attributes: 7239 ElementType This is the "type" (see [XML]) of the 7240 Element in the message in error where the 7241 error is located. 7243 OtpMsgRef This is the value of the ID attribute of the 7244 of the Message Id Component (see section 7245 3.5.2) of the message in error to which this 7246 Error Component applies. 7248 BlkRef If the error is associated with a specific 7249 Trading Block, then this is the value of the 7250 ID attribute of the Trading Block where the 7251 error is located. 7253 CompRef If the error is associated with a specific 7254 Trading Component, then this is the value of 7255 the ID attribute of the Trading Component 7256 where the error is located. 7258 ElementRef If the error is associated with a specific 7259 element within a Trading Component then, if 7260 the element has an attribute with an 7261 "attribute type" (see [XML]) of "ID", then 7262 this is the value of that attribute. 7264 AttName If the error is associated with the value of 7265 an attribute, then this is the name of that 7266 attribute. In this case the PackagedContent 7267 of the Error Component should contain the 7268 value of the attribute. 7270 Note that as many as the attributes as possible should be 7271 included. For example if an attribute in a child element of a 7272 Trading Component contains an incorrect value, then all the 7273 attributes of ErrorLocation should be present. 7275 7. IOTP Error Handling 7277 IOTP is designed as a request/response protocol where each message 7278 is composed of a number of Trading Blocks which contain a number 7279 of Trading Components. There are a several interrelated 7280 considerations in handling errors, re-transmissions, duplicates, 7281 and the like. These factors mean IOTP aware applications must 7282 manage message flows more complex than the simple 7283 request/response model. Also a wide variety of errors can occur 7284 in messages as well as at the transport level or in Trading 7285 Blocks or Components. 7287 This section describes at a high level how IOTP handles errors, 7288 retries and idempotency. It covers: 7290 - the different types of errors which can occur. This is 7291 divided into: 7293 o "technical errors" which are independent of the meaning 7294 of the IOTP Message, 7296 o "business errors" which indicate that there is a problem 7297 specific to the process (payment or delivery) which is 7298 being carried out, and 7300 - the depth of the error which indicates whether the error is 7301 at the transport, message or block/component level 7302 - how the different trading roles should handle the different 7303 types of messages which they may receive. 7305 7.1. Technical Errors 7306 Technical errors are those which are independent of the meaning 7307 of the message. This means, they can affect any attempt at IOTP 7308 communication. Typically they are handled in a standard fashion 7309 with a limited number of standard options for the user. 7310 Specifically these are: 7312 - retrying the transmission, or 7313 - cancelling the transaction. 7314 When communications are operating sufficiently well, a technical 7315 error is indicated by an Error Component in an Error Block (see 7316 section 5.23) sent by the party which detected the error in an 7317 IOTP message to the party which sent the erroneous message. 7319 If communications too poor, a message which was sent may not 7320 reach its destination. In this case a time-out might occur. 7322 The Error codes associated with Technical Errors are recorded in 7323 Error Components which lists all the different technical errors 7324 which can be set. 7326 7.2. Business Errors 7328 Business errors may occur when the IOTP messages are "technically" 7329 correct. They are connected with a particular process, for 7330 example, an offer, payment, or delivery, where each process has a 7331 different set of possible business errors. 7333 For example, "Insufficient funds" is a reasonable payment error 7334 but makes no sense for a delivery while "Back ordered" is a 7335 reasonable delivery error but not meaningful for a payment. 7336 Business errors are indicated in the Status Component (see 7337 section 6.28) of a "response block" of the normal type, for 7338 example a Payment Response Block or a Delivery Response Block. 7339 This allows whatever additional response related information is 7340 needed to accompany the error indication. 7342 Business errors must usually be presented to the user so that 7343 they can decide what to do next. For example, if the error is 7344 insufficient funds in a Brand Independent Purchase (see section 7345 Error! Reference source not found.), the user might wish to 7346 choose a different payment instrument/account of the same brand 7347 or a different brand or payment system. Alternatively, if the IOTP 7348 based implementation allows it and it makes sense for that 7349 instrument, the user might want to put more funds into the 7350 instrument/account and try again. 7352 7.3. Error Depth 7354 The three levels at which IOTP errors can occur are the transport 7355 level, the message level, and the block level. Each is described 7356 below. 7358 7.3.1. Transport Level 7359 This level of error indicates a fundamental problem in the 7360 transport mechanism over which the IOTP communication is taking 7361 place. 7363 All transport level errors are technical errors and are indicated 7364 by either an explicit transport level error indication, such as a 7365 "No route to destination" error from TCP/IP, or by a time out 7366 where no response has been received to a request. 7368 The only reasonable automatic action when faced with transport 7369 level errors is to retry and, after some number of automatic 7370 retries, to inform the user. 7372 The explicit error indications that can be received are transport 7373 dependent and the documentation for appropriate IOTP Transport 7374 supplement should be consulted for errors and appropriate 7375 actions. 7377 Appropriate time outs to use are a function of both the transport 7378 being used and of the payment system if the request encapsulates 7379 payment information. The transport and payment system specific 7380 documentation should be consulted for time out and automatic 7381 retry parameters. Frequently there is no way to directly inform 7382 the other party of transport level errors but they should 7383 generally be logged and if automatic recovery is unsuccessful and 7384 there is a human user, the user should be informed. 7386 7.3.2. Message Level 7388 This level of error indicates a fundamental technical problem 7389 with an entire IOTP message. For example, the XML is not Well 7390 formed, or the message is too large for the receiver to handle or 7391 there are errors in the Transaction Reference Block (see section 7392 3.5) so it is not possible to figure out what transaction the 7393 message relates to. 7395 All message level errors are technical errors and are indicated 7396 by an Error Component sent to the other party. The Error Component 7397 includes a Severity attribute which indicates whether the error 7398 is a Warning and may be ignored, a TransientError which indicates 7399 that a retry may resolve the problem or a HardError in which case 7400 the transaction must fail. 7402 The Technical Errors (see section 6.36 Error Codes) that are 7403 Message Level errors are: 7405 - XML not well formed. The document is not well formed XML 7406 (see [XML]) 7407 - XML not valid. The document is not valid XML (see [XML]) 7408 - block level technical errors (see section 7.3.3) on the 7409 Transaction Reference Block (see section 3.5) and the 7410 Signature Block only. This should only be carried out if the 7411 XML is valid 7413 Note that checks on the Signature Block includes checking, where 7414 possible, that each Signature Component is correctly calculated. 7415 If the Digital Signature Element is incorrectly calculated then 7416 the data that should have been covered by the signature can not 7417 be trusted and must be treated as erroneous. A description of how 7418 to check a signature is correctly calculate is contained in 7419 section 9.6.1 Checking a Signature is Correctly Calculated. 7421 7.3.3. Block Level 7423 A Block level error indicates a problem with a block or one of 7424 its components in an IOTP message (apart from Transaction 7425 Reference or Signature Blocks). The message has been transported 7426 properly, the overall message structure and the 7427 block/component(s) including the Transaction Reference and 7428 Signature Blocks are meaningful but there is some error related 7429 to one of the other blocks. 7431 Block level errors can be either: 7433 - technical errors, or 7434 - business errors 7436 Technical Errors are further divided into: 7438 - Block Level Attribute and Element Checks, and 7439 - Block and Component Consistency Checks 7441 If a technical error occurs related to a block or component, then 7442 an Error Component is returned and, unless it is merely a 7443 warning, the usual response block is suppressed. 7445 7.3.4. 7447 Block Level Attribute and Element Checks 7449 Block Level Attribute and Element Checks occur only within the 7450 same block. Checks which involve cross-checking against other 7451 blocks are covered by Block and Component Consistency Checks. 7453 The Block Level Attribute & Element checks are: 7455 - checking that each attribute value within each element in a 7456 block conforms to any rules contained within this IOTP 7457 specification 7458 - checking that the content of each element conforms to any 7459 rules contained within this IOTP specification 7460 - if the previous checks are OK, then cross-checking attribute 7461 values and element content against other attribute values or 7462 element content within any other components in the same 7463 block. 7465 7.3.5. Block and Component Consistency Checks 7467 Block and Component Consistency Checks consist of: 7469 - checking that the combination of blocks and/or components 7470 present in the IOTP Message are consistent with the rules 7471 contained within this IOTP specification 7472 - checking for consistency between attributes and element 7473 content within the blocks within the same IOTP message. 7474 - checking for consistency between attributes and elements in 7475 blocks in this IOTP message and blocks received in earlier 7476 IOTP messages for the same IOTP transaction 7478 7.3.6. Block Business Errors 7480 If a business error occurs in a process such as a Payment or a 7481 Delivery, then the usual type of response block is returned. The 7482 Status Component (see section 6.28) within that response block 7483 indicates the error and its severity. No Error Component or Error 7484 Block is generated for business errors. 7486 7.4. Idempotency, Processing Sequence, and Message Flow 7488 IOTP messages are actually a combination of blocks and components 7489 as described in 3.1 IOTP Message Structure. Especially in future 7490 extensions of IOTP, a rich variety of combinations of such blocks 7491 and components can occur. It is important that the multiple 7492 transmission/receipt of the "same" request for state changing 7493 action not result in that action occurring more than once. This 7494 is called idempotency. For example, a customer paying for an 7495 order would want to pay the full amount only once. Most network 7496 transport mechanisms have some probability of delivering a 7497 message more than once or not at all, perhaps requiring 7498 retransmission. On the other hand, a request for status can 7499 reasonably be repeated and should be processed fresh each time it 7500 is received. 7502 Correct implementation of IOTP can be modelled by a particular 7503 processing order as detailed below. Any other method that is 7504 indistinguishable in the messages sent between the parties is 7505 equally acceptable. 7507 7.4.1. Server Role Processing Sequence 7509 "Server roles" are any Trading Role which is not the Consumer 7510 role. They are "Server roles" since they typically receive a 7511 request which they must service and then produce a response. 7513 7.4.2. Check for Transport or Message Level Error 7515 On receipt of an IOTP request message, first check for transport or 7516 message level errors (see sections 7.3.1 and 7.3.2). These are 7517 errors which indicate that the entire message is corrupt and can 7518 not reliably be associated with any particular transaction or, if 7519 it can be associated with a transaction, the interior information 7520 in the message can not be reliably accessed. 7522 If the OtpTransId attribute in the Transaction Id Component (see 7523 section 3.5.1) can be determined, set up a response message with 7524 an appropriate Error Component. Perform local actions such as 7525 making log entries. 7527 If the value of the OtpTransId attribute is not recognised as 7528 belonging to an IOTP transaction when other Blocks in the IOTP 7529 Message indicate that it should be recognised, then report the 7530 error using an Error Component with a Severity of HardError, an 7531 ErrorCode set to AttValNotRecog (attribute value not recognised), 7532 and an Error Location element (see section 6.37) that points to 7533 the OtpTransId attribute. 7535 No idempotency related actions are necessary. 7537 7.4.3. Process all the blocks 7539 If there are no message level errors, process each of the blocks 7540 within the message which has not been processed. 7542 Once all the blocks have been processed, generate a response 7543 message and send it to the requester unless there are fatal transport 7544 level problems. As recommended for the particular transport used, a 7545 limited number of automatic response retransmission attempts may be 7546 appropriate. 7548 It may be desirable to log the complete response message at the 7549 server. Failure of the requester to receive a response may lead 7550 to a time-out and a retransmission of the request. Following the 7551 procedures above, a duplicate request message should produce a 7552 duplicate of the previous response except for changes in status 7553 and transient error conditions that have changed. 7555 7.4.4. Check the Block is OK 7557 Check the block is OK (see section 7.3.3). For each block level 7558 error found, an appropriate Error Component should be created to 7559 be included in the IOTP Message sent back to the Consumer. Note 7560 that some checking of the Transaction Reference Block and the 7561 Signature Block has occurred as part of Message Level error 7562 checking. 7564 If one or more of the Error Components contain a Severity 7565 attribute with a value of TransientError or HardError, then no 7566 response block need be generated and no further processing of the 7567 block, including idempotency related actions are necessary. 7569 7.4.5. Determine the Type of the Block 7571 Trading Blocks that survive the above steps and thus have no 7572 errors, or at worst have added a warning error component to the 7573 response, can receive further processing. The nature of the 7574 processing depends on whether the block is a Status Request, 7575 Action Request, an Error Block or contains an Encapsulated 7576 Message. 7578 7.4.6. Status Request Blocks 7580 Status Request Blocks are either: 7582 - Inquiry Request Trading Block (see section 5.14), or 7584 - Ping Request Block (see section 5.16). 7586 These status requests do not change state and are processed fresh 7587 to get the current status. The appropriate response block should 7588 be added to the IOTP message being composed. 7590 No idempotency actions are required. 7592 7.4.7. Action Request Blocks 7594 Blocks which request an action and change state need to be 7595 subject to idempotency duplicate filtering by checking to see if 7596 the same block for the same transaction has been previously 7597 stored at the server as described later. 7599 If the Block has been received previously then: 7601 if processing of the previously stored block is complete 7602 then the same IOTP Block as previously produced must be included 7603 for resending to the Consumer. 7605 if processing is not complete, wait until the processing is 7606 complete before sending the response. If the block has not been 7607 received before, the action request is processed normally producing 7608 a response block that is added to the response message. This might 7609 or might not indicate a business error. 7611 If there is a transient error indicated by an Error Component 7612 that contains a Severity attribute set to TransientError, then 7613 apart from sending the Error Block, no further actions should be 7614 taken so the action can be retried. 7616 If there is no Transient Error, then the transaction id, the 7617 request block, and the response block must be stored so they can be 7618 found as described above should a duplicate IOTP action request block 7619 be received for this transaction in the future. 7621 Note: Most business errors should be labeled as a TransientError 7622 as there is usually some possibility they will be corrected over 7623 time or some user action exists that can fix them. Requesters are 7624 expected to understand business errors and the appropriate time 7625 scale for user actions for retrying. 7627 7.4.8. Encapsulating Blocks 7629 Blocks which encapsulate a payment protocol pass along the enclosed 7630 information to the payment system involved. 7632 IOTP does not know the meaning of the enclosed information. It is 7633 thus up to the payment system involved to handle error detection 7634 and idempotency. Payment systems adapted for the Internet include 7635 idempotency handling because duplicates are always possible. 7636 Should a payment system have no idempotency handling, a layer 7637 between IOTP and the payment system must be added to take care of 7638 this. 7640 No IOTP level idempotency actions are required for encapsulating 7641 blocks. The payment system must return material to be 7642 encapsulated in the IOTP response message along with indications 7643 as to whether the exchange will continue or this is the final 7644 response and an indication whether an error occurred. If a 7645 payment protocol error has occurred, an Error Component is added 7646 to the response block. 7648 7.4.9. Error Block Received 7650 An error block should not occur in a request and should be treated 7651 as an unexpected element with a Severity of HardError. No response 7652 to the block should be made in order to avoid the risk of loops. 7654 Note: Consumers should send Error Blocks to a server specified in 7655 the ErrorNetLocn attribute of the appropriate Trading Role 7656 element as a response to the detection of an error in an IOTP 7657 Message that has been received (see section 7.4.10 Generate Error 7658 Block). This may be the same server as is used to accept IOTP 7659 Messages which contain no error. In this case, the error block 7660 must not considered as a fatal error. 7662 7.4.10. Generate Error Block 7664 If any of the previous steps resulted in an error being detected 7665 and an Error Component being created then generate an Error Block 7666 containing the Error Components that describe the error(s). 7668 Unless the error is a "Transient Error", the Error Component(s) 7669 and the request block which caused the Error Components to be 7670 generated should be stored so that it can be reused if the action 7671 request is received again. 7673 "Transient Errors" are not stored so that if the original 7674 Response Block is received again, then it can be processed as if 7675 it had never been received before. 7677 7.4.11. Add Block to Output Message 7679 Any Blocks which have been created as a result of processing the 7680 block received are added to the output message. 7682 7.5. Client Role Processing Sequence 7683 The "Client role" in IOTP is the Consumer Trading Role. 7685 Note: A company or Organization that is a Merchant, for example, 7686 may take on the Trading Role of a Consumer when making a purchase 7687 or downloading or withdrawing electronic cash. 7689 7.5.1. Check for Transport or Message Level Error 7691 On receipt of an IOTP response message, first check for transport 7692 or message level errors (see sections 7.3.1 and 7.3.2). These are 7693 errors which indicate that the entire message is corrupt and can 7694 not reliably be associated with any particular transaction or, if 7695 it can be associated with a transaction, the interior information 7696 in the message can not be reliably accessed. Set up an error 7697 indication message with an Error Component indicating the error. 7699 If the value of the OtpTransId attribute is not recognised as 7700 belonging to an IOTP transaction when other Blocks in the IOTP 7701 Message indicate that it should be recognised, then report the 7702 error using an Error Component with a Severity of HardError, an 7703 ErrorCode set to AttValNotRecog (attribute value not recognised), 7704 and an Error Location element (see section 6.37) that points to 7705 the OtpTransId attribute. 7707 On failure to receive an expected response message, the time out 7708 strategy indicated in the documentation for the transport method 7709 being used should be followed. This may include some number of 7710 automatic retransmissions of the request. If a user is present, 7711 they may be offered options of continuing to retransmit the 7712 request or of cancelling the transaction. 7714 7.5.2. Process all the blocks 7716 If there are no message level errors, process each of the blocks 7717 within the message which has not been processed. 7719 Once all the blocks have been processed, check to see if there 7720 are any blocks to be sent. There may be no blocks to send if the 7721 last response message received was the last message of the transaction. 7723 If blocks are to be sent then generate a request message and send it 7724 to the server. It may be desirable to log the complete request message 7725 at the client. Failure of the server to receive a response may lead to 7726 a time-out and a retransmission of the request. 7728 7.5.3. Check the Block is OK 7730 If there are no message level errors process each of the blocks 7731 within the message. 7733 Check the block is OK (see section 7.3.3). For each block level 7734 error found, an appropriate Error Component should be created to 7735 be included in an Error Component sent back to the Server. 7737 If one or more of the Error Components contain a Severity 7738 attribute with a value of TransientError or HardError, no further 7739 processing of the block should occur and it is likely that this 7740 will result in termination of the transaction. 7742 7.5.4. Determine the Type of the Block 7744 Trading Blocks that survive the above steps and thus have no 7745 errors, or at worst have added a warning error component to the 7746 error indication message, can receive further processing. The 7747 nature of the processing depends on whether the block is 7748 a Status Response, Action Response, an Error Block or contains an 7749 Encapsulated Message. 7751 7.5.5. Status Response Blocks 7753 Status Response Blocks are either: 7755 - Inquiry Response Trading Blocks (see section 5.15), or 7757 - Ping Response Blocks (see section 5.17) 7759 In general, such blocks should be considered a status update. The 7760 best action to take at the requester may depend on whether this 7761 is in response to a user originated or automatic status request, 7762 whether a status display that could be updated is being presented 7763 to the user, and whether the status response block shows a change 7764 in status from a previous response block for the same type of 7765 status. Thus client detection of duplication in successive status 7766 response blocks may be useful. 7768 7.5.6. Action Response Blocks 7770 Check to determine if the Block has been received previously. If it 7771 has then it should be ignored. 7773 These indicate an action taken at the server in response to an 7774 action request block or a business error. If the response 7775 indicates success the block should be processed and, if required by 7776 the transaction, another Action Request Block generated and stored. 7778 The Response Block should always be stored with the transaction 7779 id and until the transaction is terminated. If the Response Block 7780 indicates a transient business error, appropriate manually chosen 7781 or automatic steps to fix the problem or cancel the transaction 7782 should be provided. 7784 7.5.7. Encapsulating Blocks 7786 Blocks which encapsulate a payment protocol pass along the enclosed 7787 information to the payment system involved. 7789 IOTP does not know the meaning of the enclosed information. It is 7790 up to the payment system involved to handle error detection and 7791 idempotency. Payment systems adapted for the Internet include 7792 idempotency handling because duplicates are always possible. 7793 Should a payment system have no idempotency handling, a layer 7794 between IOTP and the payment system must be added to take care of 7795 this. 7797 No IOTP level idempotency actions are required for encapsulating 7798 blocks. The payment system must return an indication of whether 7799 an error occurred. In addition, for a continuing exchange, it 7800 must return material to be encapsulated in the next IOTP 7801 request/exchange. If the response was a final response for that 7802 payment exchange and there was an error, the payment system may 7803 optionally return material to be encapsulated in the error indication. 7805 7.5.8. Error Block 7807 An error block in a response indicates some problem was detected by 7808 the server. If all of the error components are warnings, they may be 7809 optionally logged and/or presented to the user. 7811 Transient errors may be used to provide a manual or automatic 7812 resending of a block previously stored or alternatively may result in 7813 transaction cancellation. Hard errors will always terminate the transaction, 7814 unless they are in optional blocks, with appropriate indication to he user. 7816 7.5.9. Generate Error Block 7818 If an error indication message was created above, try to send it 7819 to the server unless all of the error components are of the 7820 warning severity in which case attempted transmission to the 7821 server is optional. 7823 Note: To avoid error message loops, such an error indication from 7824 a requester must be sent to the Error Net Location specified in 7825 the Trading Role Element (see section 6.8) for the Organization 7826 that is the server. Any errors encountered in sending such an 7827 error indication should be, at most, logged and must not result 7828 in any further attempts to transmit any error indication. 7830 7.5.10. Add Block to Output Message 7832 Any Blocks which have been created as a result of processing the 7833 block received are added to the output message. 7835 8. Retrieving Logos 7837 This section describes how to retrieve logos for display by IOTP 7838 aware software using the Logo Net Locations attribute contained 7839 in the Brand Element (see section 6.13) and the Organization 7840 Component (see section 6.7). 7842 The full address of a logo is defined as follows: 7844 Logo_address ::= Logo_net_location "/" Logo_size 7845 Logo_color_depth 7846 ".GIF" 7847 Where: 7849 Logo_net_location is obtained from the LogoNetLocn attribute 7850 in the Brand Element (see section 6.13) or the Organization 7851 Component. Note that: 7852 - the content of this attribute is dependent on the Transport 7853 Mechanism (such as HTTP) that is used. See the Transport 7854 Mechanism supplement, 7856 - implementers should check that if the rightmost character of 7857 Logo Net Location is set to right-slash "/" then another, 7858 right slash should not be included when generating the Logo 7859 Address, 7861 Logo_size identifies the size of the logo, 7863 Logo_color_depth identifies the colour depth of the logo 7865 "GIF" indicates that the logos are in GIF format 7866 Logo_size and Logo_color_depth are specified by the implementer 7867 of the IOTP software that is retrieving the logo depending on the 7868 size and colour that they want to use. 7870 8.1. Logo Size 7872 There are five standard sizes for logos. The sizes in pixels and 7873 the corresponding values for Logo Size are given in the table 7874 below. 7876 Size in Logo Size 7877 Pixels Value 7879 32 x 32 or exsmall 7880 32 x 20 7882 53 x 33 small 7884 103 x 65 medium 7886 180 x 114 large 7888 263 x 166 exlarge 7890 8.2. Logo Color Depth 7892 There are three standard colour depths. The colour depth 7893 (including bits per pixel) and the corresponding value for 7894 Logo_Color_Depth are given in the table below. 7896 Color Depth Logo Color 7897 (bits per pixel) Depth Value 7899 4 (16 colors) 4 7900 8 (256 colors) nothing 7902 24 (16 million colors) 24 7904 Note that if Logo Color Depth is omitted then a logo with the 7905 default colour depth of 256 colours will be retrieved. 7907 8.3. Logo Net Location Examples 7909 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 7911 "ftp://logos.xzpay.com/medium.gif" would retrieve a medium 7912 size 256 colour logo 7914 "ftp://logos.xzpay.com/small4.gif" would retrieve a small 7915 size 16 colour logo 7917 Note: Organizations which make logos available for use with IOTP 7918 should always make available "small" and "medium" size logos and 7919 use the GIF format. 7921 9. Security Considerations 7923 This section considers the security associated with IOTP. It 7924 covers: 7926 - an overview of how IOTP uses digital signatures 7927 - how to check a signature is correctly calculated 7928 - how Payment Handlers and Delivery Handlers check they can 7929 carry out payments or deliveries on behalf of a Merchant. 7930 - how IOTP handles data integrity and privacy 7932 9.1. Digital Signatures and IOTP 7934 In general, signatures when used with IOTP: 7936 - are always treated as a IOTP Components (see section 5) 7937 - hash one or more IOTP Components or Trading Blocks, possibly 7938 including other Signature Components, in any IOTP message 7939 within the same IOTP Transaction 7941 identify: 7942 - which Organization signed (generated) the signature, and 7943 - which Organization(s) should verify the signature in order 7944 to check that the Action the Organization should take can 7945 occur. 7947 Note: The classic example of one signature signing another in 7948 IOTP, is when an Offer is first signed by a Merchant creating an 7949 "Offer Response" signature, which is then later signed by a 7950 Payment Handler together with a record of the payment creating a 7951 "Payment Receipt" signature. In this way, the payment in an IOTP 7952 Transaction is bound to the Merchant's offer. 7954 The detailed definitions of how signatures are created is 7955 contained in the paper "Digital Signature for XML - Proposal", 7956 see [XMLSIG]. That document should be read in conjunction with 7957 this section. 7959 The remainder of this section contains: 7961 - an example of how IOTP uses signatures 7962 - how the SignerOrgRef and VerifierOrgRef attributes within a 7963 Signature Component are used to identify the Organizations 7964 associated with the signature 7965 - how signatures may use either Symmetric or Asymmetric 7966 Cryptography 7967 - Mandatory and Optional use of Signatures by IOTP, and 7968 - how IOTP uses signatures to prove actions complete 7969 successfully 7971 9.2. IOTP Signature Example 7973 An example of how signatures are used is illustrated in the 7974 figure below which shows how the various components and elements 7975 in a Baseline Purchase relate to one another. Refer to this 7976 example in the later description of how signatures are used to 7977 check a payment or delivery can occur (see section 9.6.2). 7979 Note: A Baseline Purchase transaction has been used for 7980 illustration purposes. The usage of the elements and attributes 7981 is the same for all types of IOTP Transactions. 7983 9.3. SignerOrgRef and VerifierOrgRef Attributes 7985 The SignerOrgRef attribute on the Signature Component contains an 7986 Element Reference (see section 3.7) that points to the 7987 Organization Component of the Organization which generated the 7988 Signature. In this example its the Merchant. 7990 Note that the type of the Signature Component must match the 7991 Trading Role of the Organization which signed it. If it does not, 7992 then it is an error. Valid combinations are given in the table 7993 below. 7995 Signature Valid 7996 Component Trading 7997 Type Role 7999 OfferResponse Merchant 8001 PaymentResponse PaymentHandler 8003 The VerifierOrgRef attribute on the DigSig elements, contains 8004 Element References to the Organization Components of the 8005 Organizations that should use the signature to verify that: 8007 they have a pre-existing relationship with the Organization 8008 that generated the signature, 8010 the data which is secured by the signature has not been 8011 changed, 8013 the data has been signed correctly, and 8015 the action they are required to undertake on behalf of the 8016 Merchant is therefore authorised. 8018 9.4. Symmetric and Asymmetric Cryptography 8020 The Signer of an Action and a Verifier of an Action may have 8021 agreed to use cryptography which is understood only by the two 8022 Organizations involved. This requires that a separate Digital 8023 Signature Element for use by the verifier is contained within the 8024 Signature Component. This approach is more likely if symmetric 8025 cryptography is being used between the Trading Roles. 8027 Equally the same cryptography may be understood by several or all 8028 of the Trading Roles. In this case one Digital Signature Element 8029 may refer to multiple Verifiers of an Action. This is more likely 8030 if public key/asymmetric cryptography is being used. 8032 Note that one transaction may involve use of both symmetric and 8033 asymmetric cryptography. 8035 9.5. Mandatory and Optional Signatures 8037 IOTP does not mandate the use of signatures. For example, if a 8038 micro payment is being made for 0.1 cents, then the cost of the 8039 cryptography required to generate the signature may be greater 8040 than the income generated from the payment. Therefore it is up to 8041 the Merchant to decide whether IOTP Messages will include 8042 signatures, and for the Consumer to decide whether carrying out a 8043 transaction without signatures is an acceptable risk. If 8044 Merchants discover that transactions without signatures are not 8045 being accepted, then they will start using signatures or accept a 8046 lower volume and value of business. 8048 Additional optional signatures, over and above the ones required 8049 by the Trading Roles may be included, for example, to identify a 8050 Customer Care Provider or so that a Merchant can sign an Offer 8051 using a certificate issued by a Certificate Authority which 8052 offers Merchant "Credentials" or some other warranty on the goods 8053 or services being offered. 8055 9.6. Using signatures to Prove Actions Complete Successfully 8057 Proving an action completed successfully, is achieved by signing 8058 data on Response messages. Specifically: 8060 on the Offer Response, when a Merchant is making an Offer to 8061 the Consumer which can then be sent to either: 8062 - a Payment Handler to prove that payment is authorised, or 8063 - a Delivery Handler to prove that Delivery is authorised 8065 on the Payment Response, when a Payment Handler is 8066 generating a Payment Receipt which can be sent to either: 8067 - a Delivery Handler, in a Delivery Request Block to prove 8068 that delivery is authorised, or 8069 - another Payment Handler, in a second Payment Request, to 8070 prove that the second payment in a Value Exchange IOTP 8071 Transaction is authorised. 8072 This proof of an action may, in future versions of IOTP, also be 8073 used to prove after the event that the IOTP transaction occurred. 8074 For example to a Customer Care Provider. 8076 9.6.1. Checking a Signature is Correctly Calculated 8078 Checking a signature is correctly calculated is part of checking 8079 for Message Level Errors (see section 7.3.2). It is included here 8080 so that all signature and security related considerations are 8081 kept together. 8083 Before a Trading Role can check a signature it must identify 8084 which of the potentially multiple digital signature elements 8085 should be checked. The steps involved are as follows: 8087 check that a Signature Block is present and it contains one 8088 or more Signature Components 8089 identify the Organization Component which contains an OrgId 8090 attribute for the Organization which is carrying out the 8091 signature check. If no or more than one Organization 8092 Component is found then it is an error 8094 use the ID attribute of the Organization Component to 8095 identify the Digital Signatures Elements which the Trading 8096 Role should verify. Note there may be no signatures for a 8097 Trading Role to verify. 8099 verify the Signature Components that contain the Digital 8100 Signature Elements as follows: 8101 - check that the Digital Signature Element correctly signs the 8102 Signed Data Element 8103 - check that the Hash Elements in the Signed Data Element are 8104 correctly calculated where Components or Blocks that are 8105 hashed have been received by the Organization checking the 8106 signature 8108 9.6.2. Checking a Payment or Delivery can occur 8110 This section describes the processes required for a Payment 8111 Handler or Delivery Handler to check that a payment or delivery 8112 can occur. This may include checking signatures if this is 8113 specified by the Merchant. 8115 In outline the steps are: 8117 - check that the Payment Request or Delivery Request has been 8118 sent to the correct Organization 8119 - check that correct IOTP components are present in the 8120 request, and 8121 - check that the payment or delivery is authorised 8123 For clarity and brevity the following terms or phrases are used 8124 in this section: 8126 - a "Request Block" is used to refer to either a Payment 8127 Request Block (see section 5.6) or a Delivery Request Block 8128 (see section 5.9) unless specified to the contrary 8129 - a "Response Block" is used to refer to either a Payment 8130 Response Block (see section 5.8) or a Delivery Response 8131 Block (see section 5.10) 8132 - an "Action" is used to refer to an action which occurs on 8133 receipt of a Request Block. Actions can be either a Payment 8134 or a Delivery 8136 - an "Action Organization", is used to refer to the Payment 8137 Handler or Delivery Handler that carries out an Action 8138 - a "Signer of an Action", is used to refer to the 8139 Organizations that sign data about an Action to authorise 8140 the Action, either in whole or in part 8141 - a "Verifier of an Action", is used to refer to the 8142 Organizations that verify data to determine if they are 8143 authorised to carry out the Action 8144 - an ActionOrgRef attribute contains Element References which 8145 can be used to identify the "Action Organization" that 8146 should carry out an Action 8148 9.7. Check the Action Request was sent to the Correct Organization 8150 Checking the Action Request was sent to the correct Organization 8151 varies depending on whether the Action is a Payment or a 8152 Delivery. 8154 9.7.1. Payment 8156 In outline a Payment Handler checks if it can accept or make a 8157 payment by identifying the Payment Component in the Payment 8158 Request Block it has received, then using the ID of the Payment 8159 Component to track through the Brand List and Brand Selection 8160 Components to identify the Organization selected by the Consumer 8161 and then checking that this Organization is itself. 8163 The following describes the steps involved and the checks which 8164 need to be made: 8166 - Identify the Payment Component (see section 6.21) in the 8167 Payment Request Block that was received. 8168 - Identify the Brand List and Brand Selection Components for 8169 the Payment Component. This involves: 8170 - identifying the Brand List Component (see section 6.12) 8171 where the value of its ID attribute matches the BrandListRef 8172 attribute of the Payment Component. If no or more than one 8173 Brand List Component is found there is an error. 8174 - identifying the Brand Selection Component (see section 6.17) 8175 where the value of its BrandListRef attribute matches the 8176 BrandListRef of the Payment Component. If no or more than 8177 one matching Brand Selection Component is found there is an 8178 error. 8179 - Identify the Brand, Protocol Amount, Pay Protocol and 8180 Currency Amount elements within the Brand List that have 8181 been selected by the Consumer as follows: 8183 o the Brand Element selected is the element where the value 8184 of its Id attribute matches the value of the BrandRef 8185 attribute in the Brand Selection. If no or more than one 8186 matching Brand Element is found then there is an error. 8188 o the Protocol Amount Element selected is the element where 8189 the value of its Id attribute matches the value of the 8190 ProtocolAmountRef attribute in the Brand Selection Component. 8191 If no or more than one matching Protocol Amount Element is 8192 found there is an error 8194 o the Pay Protocol Element (see section 6.16) selected is 8195 the element where the value of its Id attribute matches 8196 the value of the PayProtocolRef attribute in the 8197 identified Protocol Amount Element. If no or more than 8198 one matching Pay Protocol Element is found there is an 8199 error 8201 o the Currency Amount Element (see section 6.15) selected 8202 is the element where the value of its Id attribute 8203 matches the value of the CurrencyAmountRef attribute in 8204 the Brand Selection Component. If no or more than one 8205 matching Currency Amount element is found there is an 8206 error 8208 - Check the consistency of the references in the Brand List 8209 and Brand Selection Components: 8210 - check that an Element Reference exists in the 8211 ProtocolAmountRefs attribute of the identified Brand Element 8212 that matches the Id attribute of the identified Protocol 8213 Amount Element. If no or more than one matching Element 8214 Reference can be found there is an error 8215 - check that the CurrencyAmountRefs attribute of the 8216 identified Protocol Amount element contains an element 8217 reference that matches the Id attribute of the identified 8218 Currency Amount element. If no or more than one matching 8219 Element Reference is found there is an error. 8220 - check the consistency of the elements in the Brand List. 8221 Specifically, the selected Brand, Protocol Amount, Pay 8222 Protocol and Currency Amount Elements are all child elements 8223 of the identified Brand List Component. If they are not 8224 there is an error. 8225 - Check that the Payment Handler that received the Payment 8226 Request Block is the Payment Handler selected by the 8227 Consumer. This involves: 8229 o identifying the Organization Component for the Payment 8230 Handler. This is the Organization Component where its ID 8231 attribute matches the ActionOrgRef attribute in the 8232 identified Pay Protocol Element. If no or more than one 8233 matching Organization Component is found there is an 8234 error 8236 o checking the Organization Component has a Trading Role 8237 Element with a Role attribute of PaymentHandler. If not 8238 there is an error 8240 o finally, if the identified Organization Component is not 8241 the same as the Organization that received the Payment 8242 Request Block, then there is an error. 8244 9.7.2. Delivery 8246 The steps involved are as follows: 8248 - Identify the Delivery Component in the Delivery Request 8249 Block. If there is no or more than one matching Delivery 8250 Component there is an error 8251 - Use the ActionOrgRef attribute of the Delivery Component to 8252 identify the Organization Component of the Delivery Handler. 8253 If there is no or more than one matching Organization 8254 Component there is an error 8255 - If the Organization Component for the Delivery Handler does 8256 not have a Trading Role Element with a Role attribute of 8257 DeliveryHandler there is an error 8258 - Finally, if the Organization that received the Delivery 8259 Request Block does not identify the Organization Component 8260 for the Delivery Handler as itself, then there is an error. 8262 9.8. Check the Correct Components are present in the Request Block 8264 Check that the correct components are present in the Payment 8265 Request Block (see section 5.6) or in the Delivery Request Block 8266 (see section 5.9). 8268 If components are missing, there is an error. 8270 9.9. Check an Action is Authorised 8272 The previous steps identified the Action Organization and that 8273 all the necessary components are present. This step checks that 8274 the Action Organization is authorised to carry out the Action. 8276 In outline the Action Organization identifies the Merchant, 8277 checks that it has a pre-existing agreement which allows it carry 8278 out the Action and that any constraints implied by that agreement 8279 are being followed, then, if signatures are required, it checks 8280 that they sign the correct data. 8282 The steps involved are as follows: 8284 - Identify the Merchant. This is the Organization Component 8285 with a Trading Role Element which has a Role attribute with 8286 a value of Merchant. If no or more than one Trading Role 8287 Element is found, there is an error 8288 - Check the Action Organization's agreements with the Merchant 8289 allows the Action to be carried out. To do this the Action 8290 Organization must check that: 8292 o the Merchant is known and a pre-existing agreement exists 8293 for the Action Organization to be their agent for the 8294 payment or delivery 8296 o they are allowed to take part in the type of IOTP 8297 transaction that is occurring. For example a Payment 8298 Handler may have agreed to accept payments as part of a 8299 Baseline Purchase, but not make payments as part of a 8300 Baseline Refund 8302 o any constraints in their agreement with the Merchant are 8303 being followed, for example, whether or not an Offer 8304 Response signature is required 8306 - Check the signatures are correct. If signatures are required 8307 then they need to be checked. This involves: 8308 - Identifying the correct signatures to check. This involves 8309 the Action Organization identifying the Signature Components 8310 where the VerifierOrgRef attribute of the Digital Signature 8311 element points to the Action Organization's Organization 8312 Component. Depending on the IOTP Transaction being carried 8313 out (see section 4) either one or two signatures may be 8314 identified 8315 - checking that the Signature Components are correct. This 8316 involves checking that the necessary Trading Components have 8317 been hashed (see section 9.9.1). 8319 Note: Validation that the signature is correct and that the Hash 8320 elements within the signature are correctly calculated is 8321 described in section 7 IOTP Error Handling. This is because errors 8322 in the signature or calculation of hashes is considered a Message 8323 Level Error and is carried out before the Request Block is 8324 processed. 8326 9.9.1. Check the Signatures Sign Correct Data 8328 All Signature Components contained within IOTP Messages must 8329 always hash: 8331 the Transaction Id Component (see section 3.5.1) of the IOTP 8332 message that contains the Signature Component. This binds 8333 the globally unique OtpTransId to other components which 8334 make up the IOTP Transaction 8336 the Transaction Reference Block (see section 3.5) of the 8337 first IOTP Message that contained the signature. This binds 8338 the OtpTransId with information about the IOTP Message 8339 contained inside the Message Id Component (see section 8340 3.5.2). 8341 Checking that each signature signs the correct data, involves 8342 checking that hashes of the necessary components are present in 8343 the SignedData element of the Signature Component. 8345 The hashes that need to be present depend on the Trading Role of 8346 the Organization which generated (signed) the signature: 8348 if the signer of the signature is a Merchant then: 8349 - hashes must be present for all the components in the Request 8350 Block apart from the Brand Selection Component which is 8351 optional 8353 if the signer of the signature is a Payment Handler then 8354 hashes should be present for: 8355 - the Signature Component signed by the Merchant, and 8356 optionally 8357 - one or more Signature Components signed by the Payment 8358 Handler(s) identified by the appropriate ActionSignerRefs 8359 attribute. 8361 9.10. Data Integrity and Privacy 8363 The overall integrity of data in IOTP Messages is ensured by the 8364 signing of hashes of Components and Trading Blocks contained in a 8365 Signature Component (see section 6.30) in a Signature Block (see 8366 section 5.18). 8368 Privacy of information is provided by sending IOTP Messages 8369 between the various Trading Roles using a secure channel such as 8370 [SSL]. Use of a secure channel within IOTP is optional. 8372 10. Internationalization Considerations 8374 In the realm of internationalization, this specification complies 8375 with the IETF Character Set Policy [Alvestrand, 1998]. In this 8376 specification, human-readable fields can be found either in the 8377 value of a property, or in an error message returned in a response 8378 entity body. In both cases, the human-readable content is encoded 8379 using XML, which has explicit provisions for character set tagging 8380 and encoding, and requires that XML processors read XML elements 8381 encoded, at minimum, using the UTF-8 [Yergeau, 1998] encoding of the 8382 ISO 10646 multilingual plane. 8384 XML also provides a language tagging capability for specifying the 8385 language of the contents of a particular XML element. XML uses 8386 either IANA registered language tags (see RFC 1766, [Alvestrand, 8387 1995]) or ISO 639 language tags [ISO-639] in the "xml:lang" 8388 attribute of an XML element to identify the language of its content 8389 and attributes. 8391 IOTP applications MUST support the character set tagging, 8392 character set encoding, and the language tagging functionality of 8393 the XML specification. 8395 Since interoperation of clients and servers does not require locale 8396 information, this specification does not specify any mechanism for 8397 transmission of this information. 8399 11. IANA Considerations 8400 This specification defines a distinguished set of XML elements that 8401 are understood by all IOTP applications. The XML elements in this 8402 specification are all derived from the base URI IOTP: by adding a 8403 suffix to this URI. 8405 To ensure correct interoperation based on this specification, IANA 8406 must reserve the URI namespaces starting with "IOTP:" for use by 8407 this specification, its revisions, and related IOTP specifications. 8409 12. Copyrights 8410 Copyright (C) The Internet Society (1998). All Rights Reserved. 8412 This document and translations of it may be copied and furnished 8413 to others, and derivative works that comment on or otherwise 8414 explain it or assist in its implmentation may be prepared, 8415 copied, published and distributed, in whole or in part, without 8416 restriction of any kind, provided that the above copyright notice 8417 and this paragraph are included on all such copies and derivative 8418 works. However, this document itself may not be modified in any 8419 way, such as by removing the copyright notice or references to 8420 the Internet Society or other Internet organizations, except as 8421 needed for the purpose of developing Internet standards in which 8422 case the procedures for copyrights defined in the Internet 8423 Standards process must be followed, or as required to translate 8424 it into languages other than English. 8426 The limited permissions granted above are perpetual and will not 8427 be revoked by the Internet Society or its successors or assigns. 8429 This document and the information contained herein is provided on 8430 an AS IS basis and THE INTERNET SOCIETY AND THE INTERNET 8431 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 8432 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 8433 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 8434 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 8435 PURPOSE. 8437 13. References 8439 [Base64] Base64 Content-Transfer-Encoding. A method of transporting binary 8440 data defined by MIME. See: RFC 2045: Multipurpose Internet Mail 8441 Extensions (MIME) Part One: Format of Internet Message Bodies. N. 8442 Freed & N. Borenstein. November 1996. 8444 [DNS] The Internet Domain Name System which allocates Internet names to 8445 organisations for example "otp.org", the Domain Name for IOTP. See 8446 RFC 1034: Domain names - concepts and facilities. P.V. Mockapetris. 8447 Nov-01-1987, and RFC 1035: Domain names - implementation and 8448 specification. P.V. Mockapetris. Nov-01-1987. 8450 [DSA] The Digital Signature Algorithm (DSA) published by the National 8451 Institute of Standards and Technology (NIST) in the Digital 8452 Signature Standard (DSS), which is a part of the US government's 8453 Capstone project. 8455 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). 8456 Elliptic curve cryptosystems are analogs of public-key cryptosystems 8457 such as RSA in which modular multiplication is replaced by the 8458 elliptic curve addition operation. See: V. S. Miller. Use of 8459 elliptic curves in cryptography. In Advances in Cryptology - 8460 Crypto '85, pages 417-426, Springer-Verlag, 1986. 8462 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) 8463 is a simple mark-up language used to create hypertext documents 8464 that are platform independent. See RFC 1866 and the World Wide 8465 Web (W3C) consortium web site at: http://www.w3.org/MarkUp/ 8467 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC 1945: 8468 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding 8469 & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Protocol -- 8470 HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, 8471 T. Berners-Lee. January 1997. 8473 [ISO4217] ISO 4217: Codes for the Representation of Currencies. Available 8474 from ANSI or ISO. 8476 [MIME] Multipurpose Internet Mail Extensions. See RFC822, RFC2045, RFC2046, 8477 RFC2047, RFC2048 and RFC2049. 8479 [OPS] Open Profiling Standard. A proposed standard which provides a 8480 framework with built-in privacy safeguards for the trusted exchange 8481 of profile information between individuals and web sites. Being 8482 developed by Netscape and Microsoft amongst others. 8484 [RFC822] IETF (Internet Engineering Task Force). RFC 822: The Standard for 8485 the Format of ARPA Internet Messages . 13 August 1982, David H 8486 Crocker. 13 August 1982. 8488 [RFC1738] IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource 8489 Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994. 8491 [RSA] RSA is a public-key cryptosystem for both encryption and 8492 authentication supported by RSA Data Security Inc. See: R. L. 8493 Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital 8494 signatures and public-key cryptosystems. Communications of the 8495 ACM, 21(2): 120-126, February 1978. 8497 [SCCD] Secure Channel Credit Debit. A method of conducting a credit or 8498 debit card payment where unauthorised access to account information 8499 is prevented through use of secure channel transport mechanisms such 8500 as SSL. An IOTP supplement describing how SCCD works is under 8501 development. Author. Jonathan Sowler JCP, 8503 [SET] Secure Electronic Transaction Specification, Version 1.0, May 31, 8504 1997. Supports credit and debit card payments using certificates at 8505 the Consumer and Merchant to help ensure authenticity. 8506 Download from: . 8508 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of Standards 8509 and Technology, US Department Of Commerce, April 1995. Also known 8510 as: 59 Fed Reg. 35317 (1994). 8512 [UTC] Universal Time Co-ordinated. A method of defining time absolutely 8513 relative to Greenwich Mean Time (GMT). Typically of the form: 8514 "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of 8515 hours from GMT. See ISO DIS8601. 8517 [UTF16] The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, 8518 Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1 8520 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including 8521 Draft Amendment 1: Certificate Extensions (Version 3 Certificate) 8523 [XML Namespace] See Design decisions reached at the XML Working Group 8524 meeting in Montreal, Canada, August 22, 1987 8526 [XML] Extensible Mark Up Language. See http://www.w3.org/TR/PR-xml-971208 8527 for the 8 December 1997 version. 8529 [XMLSIG] A proposal developed by the IOTP consortium describing an approach 8530 to signing XML documents such as IOTP Messages. It is intended that 8531 this document is submitted to W3C for consideration. Author. 8532 Richard Brown. GlobeSet. (Under preparation August 1998) 8534 14. Appendices 8536 14.1. IOTP - XML DTD 8537 8549 8570 8576 8577 8580 8581 8586 TransTimeStamp CDATA #REQUIRED > 8588 8589 8596 8597 8604 8610 8611 8615 8620 8621 8622 8632 8633 8634 8639 8640 8641 8645 8646 8647 8657 8658 8660 8669 8670 8674 8675 8682 8683 8690 8691 8701 8702 8705 8711 8712 8722 8723 8729 8730 8736 8737 8747 8748 8751 8758 8759 8763 8764 8768 8769 8773 8774 8775 8784 8785 8786 8792 8793 8794 8799 8800 8801 8809 8810 8820 8821 8822 8828 8829 8830 8835 8836 8837 8848 8849 8850 8856 8857 8858 8867 8868 8876 8882 8883 8884 8887 8888 8889 8892 8893 8896 8899 8900 8901 8904 8905 8906 8909 8910 8913 8916 8917 8918 8921 8922 8923 8926 8927 8928 8931 8932 8933 8936 8937 8939 8942 8943 8944 8947 8948 8949 8952 8953 8954 8957 8958 8959 8964 8965 8966 8969 8970 8971 8978 8979 8980 8983 8984 8985 8988 15. Author's Address 8990 Surendra K Reddy 8991 Oracle Corporation 8992 500 Oracle Parkway, M/S 4op12 8993 Redwoodshores, CA 94065 8994 USA 8996 Tel: +1 (650) 506 5441 8997 email: skreddy@us.oracle.com 8999 David Burdett 9000 Development Director 9001 Mondex International Ltd 9002 Advanced Technology Division 9003 111 Pine St 9004 San Francisco, CA 94111 9005 USA 9007 Tel: +1 (415) 645 6973 9008 Email: david.burdett@mondex.com 9010 Expires on March 21, 1999