idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-03.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 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-03', 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 55 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 11156: '...* - Changed the REQUIRED to IMPLIED on...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 839 has weird spacing: '...out the bein...' == Line 1081 has weird spacing: '...rmation inf...' == Line 1082 has weird spacing: '...ut what on ...' == Line 1181 has weird spacing: '...cope of authe...' == Line 1204 has weird spacing: '...ication check...' == (21 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. -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'XML' on line 12239 looks like a reference -- Missing reference section? 'HTML' on line 12151 looks like a reference -- Missing reference section? 'OPS' on line 12177 looks like a reference -- Missing reference section? 'RFC 822' on line 1694 looks like a reference -- Missing reference section? 'UTC' on line 12221 looks like a reference -- Missing reference section? 'Note' on line 10844 looks like a reference -- Missing reference section? 'IANA' on line 12164 looks like a reference -- Missing reference section? 'SET' on line 12210 looks like a reference -- Missing reference section? 'MIME' on line 12174 looks like a reference -- Missing reference section? 'DNS' on line 12127 looks like a reference -- Missing reference section? 'SSL' on line 6017 looks like a reference -- Missing reference section? 'RFC1738' on line 12188 looks like a reference -- Missing reference section? 'RFC822' on line 12183 looks like a reference -- Missing reference section? 'ISO 4217' on line 5299 looks like a reference -- Missing reference section? 'XMLDSIG' on line 12243 looks like a reference -- Missing reference section? 'DOM-HASH' on line 12122 looks like a reference -- Missing reference section? 'SHA1' on line 12217 looks like a reference -- Missing reference section? 'MD5' on line 12172 looks like a reference -- Missing reference section? 'DSA' on line 12134 looks like a reference -- Missing reference section? 'HMAC' on line 12147 looks like a reference -- Missing reference section? 'RSA' on line 12196 looks like a reference -- Missing reference section? 'SCCD' on line 12203 looks like a reference -- Missing reference section? 'Base64' on line 12116 looks like a reference -- Missing reference section? 'ECCDSA' on line 12139 looks like a reference -- Missing reference section? 'HTTP' on line 12157 looks like a reference -- Missing reference section? 'ISO4217' on line 12169 looks like a reference -- Missing reference section? 'RFC2434' on line 12192 looks like a reference -- Missing reference section? 'FIPS-180-1' on line 12217 looks like a reference -- Missing reference section? 'UTF16' on line 12227 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRADE Working Group David Burdett 3 Internet Draft Mondex International 4 draft-ietf-trade-iotp-v1.0-protocol-03.txt 5 Expires: 28 August 1999 7 Internet Open Trading Protocol - IOTP 8 Version 1.0 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Distribution of this document is unlimited. Please send comments to 28 the TRADE working group at , which may 29 be joined by sending a message with subject "subscribe" to . 32 Discussions of the TRADE working group are archived at 33 http://www.elistx.com/archives/ietf-trade. 35 Abstract 37 The Internet Open Trading Protocol (IOTP) provides an interoperable 38 framework for Internet commerce. It is payment system independent and 39 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 40 GeldKarte, etc. IOTP is able to handle cases where such merchant roles 41 as the shopping site, the payment handler, the Delivery Handler of 42 goods or services, and the provider of customer support are performed 43 by different parties or by one party. 45 Table of Contents 47 Status of this Memo..................................................2 49 Abstract.............................................................3 51 1. Background.......................................................10 52 1.1 Commerce on the Internet _ a Different Model.................11 53 1.2 Benefits of IOTP.............................................12 54 1.3 Baseline IOTP................................................13 55 1.4 Objectives of Document.......................................14 56 1.5 Purpose......................................................14 57 1.6 Scope of Document............................................14 58 1.7 Document Structure...........................................15 59 1.8 Intended Readership..........................................16 60 1.8.1 Reading Guidelines ......................................17 61 1.9 History......................................................17 63 2. Introduction.....................................................19 64 2.1 Trading Roles................................................20 65 2.2 Trading Exchanges............................................21 66 2.2.1 Offer Exchange ..........................................23 67 2.2.2 Payment Exchange ........................................25 68 2.2.3 Delivery Exchange .......................................29 69 2.2.4 Authentication Exchange .................................31 70 2.3 Scope of Baseline IOTP.......................................33 72 3. Protocol Structure...............................................38 73 3.1 Overview.....................................................40 74 3.1.1 IOTP Message Structure ..................................40 75 3.1.2 IOTP Transactions .......................................42 76 3.2 IOTP Message.................................................43 77 3.2.1 XML Document Prolog .....................................45 78 3.3 Transaction Reference Block..................................45 79 3.3.1 Transaction Id Component ................................46 80 3.3.2 Message Id Component ....................................48 81 3.3.3 Related To Component ....................................49 82 3.4 ID Attributes................................................51 83 3.4.1 IOTP Message ID Attribute Definition ....................52 84 3.4.2 Block and Component ID Attribute Definitions ............53 85 3.4.3 Example of use of ID Attributes .........................54 86 3.5 Element References...........................................55 87 3.6 Brands and Brand Selection...................................56 88 3.6.1 Definition of Payment Instrument ........................57 89 3.6.2 Definition of Brand .....................................58 90 3.6.3 Definition of Dual Brand ................................58 91 3.6.4 Definition of Promotional Brand .........................59 92 3.6.5 Identifying Promotional Brands ..........................59 93 3.7 Extending IOTP...............................................62 94 3.7.1 Extra XML Elements ......................................62 95 3.7.2 Opaque Embedded Data ....................................63 96 3.7.3 Values for IOTP Codes ...................................63 97 3.8 Packaged Content Element.....................................66 98 3.8.1 Packaging HTML ..........................................68 99 3.9 Identifying Languages........................................69 100 3.10 Secure and Insecure Net Locations...........................70 101 3.11 Cancelled Transactions......................................70 102 3.11.1 Cancelling Transactions ................................70 103 3.11.2 Handling Cancelled Transactions ........................71 105 4. IOTP Error Handling..............................................73 106 4.1 Technical Errors.............................................73 107 4.2 Business Errors..............................................74 108 4.3 Error Depth..................................................74 109 4.3.1 Transport Level .........................................75 110 4.3.2 Message Level ...........................................75 111 4.3.3 Block Level .............................................76 112 4.4 Idempotency, Processing Sequence, and Message Flow...........78 113 4.4.1 Server Role Processing Sequence .........................78 114 4.4.2 Client Role Processing Sequence .........................84 116 5. Security Considerations..........................................90 117 5.1 Digital Signatures and IOTP..................................90 118 5.1.1 IOTP Signature Example ..................................92 119 5.1.2 OriginatorInfo and RecipientInfo Elements ...............94 120 5.1.3 Symmetric and Asymmetric Cryptography ...................95 121 5.1.4 Mandatory and Optional Signatures .......................95 122 5.1.5 Using signatures to Prove Actions Complete Successfully .95 123 5.2 Checking a Signature is Correctly Calculated.................96 124 5.3 Checking a Payment or Delivery can occur.....................97 125 5.3.1 Check the Action Request was sent to the Correct 126 Organisation ..................................................99 127 5.3.2 Check the Correct Components are present in the Request 128 Block ........................................................103 129 5.3.3 Check an Action is Authorised ..........................103 130 5.4 Data Integrity and Privacy..................................105 132 6. Trading Components..............................................106 133 6.1 Protocol Options Component..................................108 134 6.2 Authentication Data Component...............................110 135 6.3 Authentication Response Component...........................112 136 6.4 Order Component.............................................113 137 6.4.1 Order Description Content ..............................115 138 6.4.2 OkFrom and OkTo Timestamps .............................115 139 6.5 Organisation Component......................................116 140 6.5.2 Trading Role Element ...................................119 141 6.5.3 Contact Information Element ............................122 142 6.5.4 Person Name Element ....................................123 143 6.5.5 Postal Address Element .................................124 144 6.6 Brand List Component........................................125 145 6.6.1 Brand Element ..........................................127 146 6.6.2 Protocol Amount Element ................................130 147 6.6.3 Currency Amount Element ................................132 148 6.6.4 Pay Protocol Element ...................................133 149 6.7 Brand Selection Component...................................135 150 6.7.1 Brand Selection Brand Info Element .....................137 151 6.7.2 Brand Selection Protocol Amount Info Element ...........138 152 6.7.3 Brand Selection Currency Amount Info Element ...........138 153 6.8 Payment Component...........................................139 154 6.9 Payment Scheme Component....................................141 155 6.10 Payment Receipt Component..................................142 156 6.11 Payment Note Component.....................................144 157 6.12 Delivery Component.........................................145 158 6.12.1 Delivery Data Element .................................147 159 6.13 Delivery Note Component....................................149 160 6.14 Status Component...........................................151 161 6.14.1 Offer Completion Codes ................................154 162 6.14.2 Payment Completion Codes ..............................154 163 6.14.3 Delivery Completion Codes .............................155 164 6.14.4 Authentication Completion Codes .......................157 165 6.15 Trading Role Data Component................................158 166 6.15.1 Who Receives a Trading Role Data Component ............159 167 6.16 Inquiry Type Component.....................................159 168 6.17 Signature Component........................................160 169 6.17.1 IOTP usage of signature elements and attributes .......164 170 6.17.2 Offer Response Signature Component ....................166 171 6.17.3 Payment Receipt Signature Component ...................167 172 6.17.4 Delivery Response Signature Component .................168 173 6.17.5 Authentication Request Signature Component ............168 174 6.17.6 Authentication Response Signature Component ...........168 175 6.17.7 Ping Request Signature Component ......................169 176 6.17.8 Ping Response Signature Component .....................169 177 6.18 Certificate Component......................................169 178 6.18.1 IOTP usage of signature elements and attributes .......170 179 6.19 Error Component............................................170 180 6.19.1 Error Processing Guidelines ...........................173 181 6.19.2 Error Codes ...........................................174 182 6.19.3 Error Location Element ................................178 184 7. Trading Blocks..................................................180 185 7.1 Trading Protocol Options Block..............................183 186 7.2 TPO Selection Block.........................................184 187 7.3 Offer Response Block........................................185 188 7.4 Authentication Request Block................................186 189 7.5 Authentication Response Block...............................187 190 7.6 Authentication Status Block.................................187 191 7.7 Payment Request Block.......................................188 192 7.8 Payment Exchange Block......................................190 193 7.9 Payment Response Block......................................190 194 7.10 Delivery Request Block.....................................191 195 7.11 Delivery Response Block....................................193 196 7.12 Inquiry Request Trading Block..............................194 197 7.13 Inquiry Response Trading Block.............................194 198 7.14 Ping Request Block.........................................195 199 7.15 Ping Response Block........................................196 200 7.16 Signature Block............................................198 201 7.16.1 Offer Response ........................................199 202 7.16.2 Payment Request .......................................199 203 7.16.3 Payment Response ......................................199 204 7.16.4 Delivery Request ......................................199 205 7.17 Error Block................................................199 206 7.18 Cancel Block...............................................201 208 8. Internet Open Trading Protocol Transactions.....................202 209 8.1 Authentication and Payment Related IOTP Transactions........202 210 8.1.1 Authentication Document Exchange .......................205 211 8.1.2 Offer Document Exchange ................................212 212 8.1.3 Payment Document Exchange ..............................222 213 8.1.4 Delivery Document Exchange .............................228 214 8.1.5 Payment and Delivery Document Exchange .................231 215 8.1.6 Baseline Authentication IOTP Transaction ...............234 216 8.1.7 Baseline Deposit IOTP Transaction ......................236 217 8.1.8 Baseline Purchase IOTP Transaction .....................238 218 8.1.9 Baseline Refund IOTP Transaction .......................240 219 8.1.10 Baseline Withdrawal IOTP Transaction ..................242 220 8.1.11 Baseline Value Exchange IOTP Transaction ..............244 221 8.1.12 Valid Combinations of Document Exchanges ..............248 222 8.1.13 Combining Authentication Transactions with other 223 Transactions .................................................252 224 8.2 Infrastructure Transactions.................................253 225 8.2.1 Baseline Transaction Status Inquiry IOTP Transaction ...254 226 8.2.2 Baseline Ping IOTP Transaction .........................258 228 9. Retrieving Logos................................................262 229 9.1 Logo Size...................................................262 230 9.2 Logo Color Depth............................................263 231 9.3 Logo Net Location Examples..................................263 233 10. Brand List Examples............................................265 234 10.1 Simple Credit Card Based Example...........................265 235 10.2 Credit Card Brand List Including Promotional Brands........266 236 10.3 Brand Selection Example....................................269 237 10.4 Complex Electronic Cash Based Brand List...................269 239 11. Open Trading Protocol Data Type Definition.....................274 241 12. Glossary.......................................................289 243 13. Copyrights.....................................................298 245 14. References.....................................................299 247 15. Author's Address...............................................303 248 Table of Figures 250 Figure 1 IOTP Trading Roles ........................................20 251 Figure 2 Offer Exchange ............................................23 252 Figure 3 Payment Exchange ..........................................26 253 Figure 4 Delivery Exchange .........................................30 254 Figure 5 Authentication Exchange ...................................33 255 Figure 6 IOTP Message Structure ....................................41 256 Figure 7 An IOTP Transaction .......................................42 257 Figure 8 Example use of ID attributes ..............................54 258 Figure 9 Element References ........................................56 259 Figure 10 Server Role Processing Sequence ..........................80 260 Figure 11 Client Role Processing Sequence ..........................86 261 Figure 12 Signature Digests ........................................91 262 Figure 13 Example use of Signatures for Baseline Purchase ..........93 263 Figure 14 Checking a Payment Handler can carry out a Payment ......100 264 Figure 15 Checking a Delivery Handler can carry out a Delivery ....102 265 Figure 16 Trading Components ......................................107 266 Figure 17 Brand List Element Relationships ........................127 267 Figure 18 Trading Blocks ..........................................181 268 Figure 19 Payment and Authentication Message Flow Combinations ....204 269 Figure 20 Authentication Document Exchange ........................208 270 Figure 21 Brand Dependent Offer Document Exchange .................214 271 Figure 22 Brand Independent Offer Exchange ........................217 272 Figure 23 Payment Document Exchange ...............................224 273 Figure 24 Delivery Document Exchange ..............................229 274 Figure 25 Payment and Delivery Document Exchange ..................232 275 Figure 26 Baseline Authentication IOTP Transaction ................235 276 Figure 27 Baseline Deposit IOTP Transaction .......................237 277 Figure 28 Baseline Purchase IOTP Transaction ......................239 278 Figure 29 Baseline Refund IOTP Transaction ........................241 279 Figure 30 Baseline Withdrawal IOTP Transaction ....................243 280 Figure 31 Baseline Value Exchange IOTP Transaction ................246 281 Figure 32 Baseline Value Exchange Signatures ......................247 282 Figure 33 Valid Combinations of Document Exchanges ................250 283 Figure 34 Baseline Transaction Status Inquiry .....................257 284 Figure 35 Baseline Ping Messages ..................................259 285 1. Background 287 The Internet Open Trading Protocol (IOTP) provides an interoperable 288 framework for Internet commerce. It is payment system independent and 289 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 290 GeldKarte, etc. IOTP is able to handle cases where such merchant roles 291 as the shopping site, the payment handler, the Delivery Handler of 292 goods or services, and the provider of customer support are performed 293 by different parties or by one party. 295 The developers of IOTP seek to provide a virtual capability that 296 safely replicates the real world, the paper based, traditional, 297 understood, accepted methods of trading, buying, selling, value 298 exchanging that has existed for many hundreds of years. The 299 negotiation of who will be the parties to the trade, how it will be 300 conducted, the presentment of an offer, the method of payment, the 301 provision of a payment receipt, the delivery of goods and the receipt 302 of goods. These are events that are taken for granted in the course of 303 real world trade. IOTP has been produced to provide the same for the 304 virtual world, and to prepare and provide for the introduction of new 305 models of trading made possible by the expanding presence of the 306 virtual world. 308 The other fundamental ideal of the IOTP effort is to produce a 309 definition of these trading events in such a way that no matter where 310 produced, two unfamiliar parties using electronic commerce 311 capabilities to buy and sell that conform to the IOTP specifications 312 will be able to complete the business safely and successfully. 314 In summary, IOTP supports: 316 o Familiar trading models 318 o New trading models 320 o Global interoperability 322 The remainder of this section provides background to why IOTP was 323 developed. The specification itself starts in the next chapter. 325 1.1 Commerce on the Internet _ a Different Model 327 The growth of the Internet and the advent of electronic commerce are 328 bringing about enormous changes around the world in society, politics 329 and government, and in business. The ways in which trading partners 330 communicate, conduct commerce, are governed have been enriched and 331 changed forever. 333 One of the very fundamental changes about which IOTP is concerned is 334 taking place in the way consumers and merchants trade. Characteristics 335 of trading that have changed markedly include: 337 o Presence: Face-to-face transactions become the exception, not 338 the rule. Already with the rise of mail order and telephone 339 order placement this change has been felt in western commerce. 340 Electronic commerce over the Internet will further expand the 341 scope and volume of transactions conducted without ever seeing 342 the people who are a part of the enterprise with whom one does 343 business. 345 o Authentication: An important part of personal presence is the 346 ability of the parties to use familiar objects and dialogue to 347 confirm they are who they claim to be. The seller displays one 348 or several well known financial logos that declaim his ability 349 to accept widely used credit and debit instruments in the 350 payment part of a purchase. The buyer brings government or 351 financial institution identification that assures the seller 352 she will be paid. People use intangibles such as personal 353 appearance and conduct, location of the store, apparent quality 354 and familiarity with brands of merchandise, and a good clear 355 look in the eye to reinforce formal means of authentication. 357 o Payment Instruments: Despite the enormous size of bank card 358 financial payments associations and their members, most of the 359 world's trade still takes place using the coin of the realm or 360 barter. The present infrastructure of the payments business 361 cannot economically support low value transactions and could 362 not survive under the consequent volumes of transactions if it 363 did accept low value transactions. 365 o Transaction Values: New meaning for low value transactions 366 arises in the Internet where sellers may wish to offer for 367 example, pages of information for fractions of currency that do 368 not exist in the real world. 370 o Delivery: New modes of delivery must be accommodated such as 371 direct electronic delivery. The means by which receipt is 372 confirmed and the execution of payment change dramatically 373 where the goods or services have extremely low delivery cost 374 but may in fact have very high value. Or, maybe the value is 375 not high, but once delivery occurs the value is irretrievably 376 delivered so payment must be final and non-refundable but 377 delivery nonetheless must still be confirmed before payment. 378 Incremental delivery such as listening or viewing time or 379 playing time are other models that operate somewhat differently 380 in the virtual world. 382 1.2 Benefits of IOTP 384 ELECTRONIC COMMERCE SOFTWARE VENDORS 386 Electronic Commerce Software Vendors will be able to develop e- 387 commerce products which are more attractive as they will inter-operate 388 with any other vendors' software. However since IOTP focuses on how 389 these solutions communicate, there is still plenty of opportunity for 390 product differentiation. 392 PAYMENT BRANDS 394 IOTP provides a standard framework for encapsulating payment 395 protocols. This means that it is easier for payment products to be 396 incorporated into IOTP solutions. As a result the payment brands will 397 be more widely distributed and available on a wider variety of 398 platforms. 400 MERCHANTS 402 There are several benefits for Merchants: 404 o they will be able to offer a wider variety of payment brands, 406 o they can be more certain that the customer will have the 407 software needed to complete the purchase 409 o through receiving payment and delivery receipts from their 410 customers, they will be able to provide customer care knowing 411 that they are dealing with the individual or organisation with 412 which they originally traded 414 o new merchants will be able to enter this new (Internet) market- 415 place with new products and services, using the new trading 416 opportunities which IOTP presents 418 BANKS AND FINANCIAL INSTITUTIONS 420 There are also several benefits for Banks and Financial Institutions: 422 o they will be able to provide IOTP support for merchants 424 o they will find new opportunities for IOTP related services: 425 - providing customer care for merchants 426 - fees from processing new payments and deposits 428 o they have an opportunity to build relationships with new types 429 of merchants 431 CUSTOMERS 433 For Customers there are several benefits: 435 o they will have a larger selection of merchants with whom they 436 can trade 438 o there is a more consistent interface when making the purchase 440 o there are ways in which they can get their problems fixed 441 through the merchant (rather than the bank!) 443 o there is a record of their transaction which can be used, for 444 example, to feed into accounting systems or, potentially, to 445 present to the tax authorities 447 1.3 Baseline IOTP 449 This specification is Baseline IOTP. It is a Baseline in that it 450 contains ways of doing trades on the Internet which are the most 451 common. The team working on the IOTP see an extended versions of this 452 specification being developed as needs demand but at this stage feel a 453 need to develop a limited function but usable specification in order 454 that technology providers can develop pathway-pilot products that will 455 be placed in the market in order to understand the real _market place_ 456 demands and requirements for electronic trading or electronic 457 commerce. To proceed otherwise would be presumptuous, time consuming, 458 expensive and foolish. 460 Accordingly the IOTP Baseline specification has been produced for 461 pathway-pilot product development, expecting to transact live trades 462 to prove the interoperability of solutions based on this specification 463 by end '98. 465 During this period it is anticipated that there will be no changes to 466 the scope of this specification with the only changes made being 467 limited to corrections where problems are found. Software solutions 468 have been developed based on earlier versions of this specification 469 which prove that the basic concepts work. 471 1.4 Objectives of Document 473 The objectives of this document are to provide a functional 474 specification of version 1.0 of the Open Trading Protocols which can 475 be used to design and implement systems which support electronic 476 trading on the Internet using the Open Trading Protocols. 478 An overview of IOTP is provided the IOTP Business Description which 479 explains the Business Requirements for IOTP. 481 1.5 Purpose 483 The purpose of the document is: 485 o to allow potential developers of products based on the protocol 486 to start development of software/hardware solutions which use 487 the protocol 489 o to allow the financial services industry to understand a 490 developing electronic commerce trading protocol that 491 encapsulates (without modification) any of the current or 492 developing payment schemes now being used or considered by 493 their merchant customer base 495 1.6 Scope of Document 497 The protocol describes the content, format and sequences of messages 498 that pass among the participants in an electronic trade - consumers, 499 merchants and banks or other financial institutions, and customer care 500 providers. These are required to support the electronic commerce 501 transactions outlined in the objectives above. 503 The protocol is designed to be applicable to any electronic payment 504 scheme since it targets the complete purchase process where the 505 movement of electronic value from the payer to the payee is only one, 506 but important, step of many that may be involved to complete the 507 trade. 509 Payment Scheme which IOTP could support include MasterCard Credit, 510 Visa Credit, Mondex Cash, Visa Cash, GeldKarte, DigiCash, CyberCoin, 511 Millicent, Proton etc. 513 Each payment scheme contains some message flows which are specific to 514 that scheme. These scheme-specific parts of the protocol are contained 515 in a set of payment scheme supplements to this specification. 517 The document does not prescribe the software and processes that will 518 need to be implemented by each participant. It does describe the 519 framework necessary for trading to take place. 521 This document also does not address any legal or regulatory issues 522 surrounding the implementation of the protocol or the information 523 systems which use them. 525 1.7 Document Structure 527 The document consists of the following sections: 529 o Section 1 - Background: This section gives a brief background 530 on electronic commerce and the benefits IOTP offers. 532 o Section 2 - Introduction: This section describes the various 533 Trading Exchanges and shows how these trading exchanges are 534 used to construct the IOTP Transactions. This section also 535 explains various Trading Roles that would participate in 536 electronic trade. 538 o Section 3 - Protocol Structure: This section summarises how 539 various IOTP transactions are constructed using the Trading 540 Blocks and Trading Components that are the fundamental building 541 blocks for IOTP transactions. All IOTP transaction messages are 542 well formed XML documents. 544 o Section 4 - IOTP Error Handling: This section describes how to 545 process exceptions and errors during the protocol message 546 exchange and trading exchange processing. This section provides 547 a generic overview of the exception handling. This section 548 should be read carefully. 550 o Section 5 - Security Considerations: This section describes 551 security considerations and digital signatures for the XML 552 elements exchanged between the Trading Roles. 554 o Section 6 - Trading Components: This section defines the XML 555 elements required by Trading Components. 557 o Section 7 - Trading Blocks: This section describes how Trading 558 Blocks are constructed from Trading Components. 560 o Section 8 - Open Trading Protocol Transactions: This section 561 describes all the IOTP Baseline transactions. It refers to 562 Trading Blocks and Trading Components and Signatures. This 563 section doesn't directly link error handling during the 564 protocol exchanges, the reader is advised to understand Error 565 Handling as defined in section before reading this section. 567 o Section 9 - Retrieving Logos: This section describes how IOTP 568 specific logos can be retrieved. 570 o Section 10 - Brand List Examples: This section gives some 571 examples for Brand List. 573 o Section 11 - XML Overview: This section gives brief 574 introduction to XML. 576 o Section 12 - Open Trading Protocol Data Type Definition: This 577 section contains the XML Data Type Definitions for IOTP. 579 o Section 12 - Glossary. This describes all the major terminology 580 used by IOTP. 582 1.8 Intended Readership 584 Software and hardware developers; development analysts; business and 585 technical planners; industry analysts; merchants; bank and other 586 payment handlers; owners, custodians, and users of payment protocols. 588 1.8.1 Reading Guidelines 590 This IOTP specification is structured primarily in a sequence targeted 591 at people who want to understand the principles of IOTP. However from 592 practical implementation experience by implementers of earlier of 593 versions of the protocol new readers who plan to implement IOTP may 594 prefer to read the document in a different sequence as described 595 below. 597 Review the transport independent parts of the specification: This 598 covers 600 o Section 12 - Glossary 602 o Section 1 - Background 604 o Section 2 - Introduction 606 o Section 3 - Protocol Structure 608 o Section 4 - IOTP Error Handling 610 o Section 8 - Open Trading Protocol Transactions 612 o Section 10 - Brand List Examples 614 o Section 4 - IOTP Error Handling 616 o Section 9 - Retrieving Logos 618 Review the detailed XML definitions: 620 o Section 11 - XML Overview (if the reader does not know XML) 622 o Section 7 - Trading Blocks 624 o Section 6 - Trading Components 626 1.9 History 628 Version 0.1 20 February 1997 Initial draft for comment 630 Version 0.2 14 April 1997 Revised draft including changes 631 arising from comments 633 Version 0.2a 24 April 1997 Same as version 0-2 with 634 typographic corrections 636 Version 0.3 9 October 1997 Revised draft for comment 637 including revised encoding 638 approach using [XML] 640 Version 0.4 31 October 1997 Published draft for limited public 641 review by groups working within 642 the OTP consortium 644 Version 0.9 12 January 1998 Revisions following limited public 645 review _ draft for public comment 646 only. 648 Version 0.9.1 20 May 1998 Revisions following public review 649 - internal IOTP Consortium review. 651 Version 0.9.9 17 August 1998 Draft published for submission to 652 IETF for information. 654 Version 1.0 23 October 1998 Draft published incorporating 655 comments received on version 656 0.9.9. 658 Version 1.0 28 February 1998 Revised draft published incorporating 659 comments received on version 1.0 661 2. Introduction 663 The Internet Open Trading Protocols (IOTP) define a number of 664 different types of IOTP Transactions: 666 o Purchase. This supports a purchase involving an offer, a 667 payment and optionally a delivery 669 o Refund. This supports the refund of a payment as a result of, 670 typically, an earlier purchase 672 o Value Exchange. This involves two payments which result in the 673 exchange of value from one combination of currency and payment 674 method to another 676 o Authentication. This supports one organisation or individual to 677 check that another organisation or individual are who they 678 appear to be. 680 o Withdrawal. This supports the withdrawal of electronic cash 681 from a financial institution 683 o Deposit. This supports the deposit of electronic cash at a 684 financial institution 686 o Inquiry This supports inquiries on the status of an IOTP 687 transaction which is either in progress or is complete 689 o Ping This supports a simple query which enables one IOTP aware 690 application to determine whether another IOTP application 691 running elsewhere is working or not. 693 These IOTP Transactions are "Baseline" transactions since they have 694 been identified as a minimum useful set of transactions. Later 695 versions of IOTP may include additional types of transactions. 697 Each of the IOTP Transactions above involve: 699 o a number organisations playing a Trading Role, and 701 o a set of Trading Exchanges. Each Trading Exchange involves the 702 exchange of data, between Trading Roles, in the form of a set 703 of Trading Components. 705 Trading Roles, Trading Exchanges and Trading Components are described 706 below. 708 2.1 Trading Roles 710 The Trading Roles identify the different parts which organisations can 711 take in a trade. The six Trading Roles used within IOTP are 712 illustrated in the diagram below. 713 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 715 Merchant Customer Care Provider resolves ---------- 716 ---------------------------------------------->| Merchant | 717 | Consumer disputes and problems |Cust.Care.| 718 | | Provider | 719 | ---------- 720 | 721 Payment Handler accepts or makes ---------- 722 | ------------------------------------------>| Payment | 723 | | Payment for Merchant | Handler | 724 | | ---------- 725 v v 726 ---------- Consumer makes purchases or obtains ---------- 727 | Consumer |<--------------------------------------->| Merchant | 728 ---------- refund from Merchant ---------- 729 ^ 730 | Delivery Handler supplies goods or ---------- 731 |---------------------------------------------->|Deliverer | 732 services for Merchant ---------- 734 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 736 Figure 1 IOTP Trading Roles 738 The roles are: 740 o Consumer. The person or organisation which is to receive and 741 pay for the goods or services 743 o Merchant. The person or organisation from whom the purchase is 744 being made and who is legally responsible for providing the 745 goods or services and receives the benefit of the payment made 747 o Payment Handler. The entity that physically receives the 748 payment from the Consumer on behalf of the Merchant 750 o Delivery Handler. The entity that physically delivers the goods 751 or services to the Consumer on behalf of the Merchant. 753 o Merchant Customer Care Provider. The entity that is involved 754 with customer dispute negotiation and resolution on behalf of 755 the Merchant 757 Roles may be carried out by the same organisation or different 758 organisations. For example: 760 o in the simplest case one physical organisation (e.g. a 761 merchant) could handle the purchase, accept the payment, 762 deliver the goods and provide merchant customer care 764 o at the other extreme, a merchant could handle the purchase but 765 instruct the consumer to pay a bank or financial institution, 766 request that delivery be made by an overnight courier firm and 767 to contact an organisation which provides 24x7 service if 768 problems arise. 770 Note that in this specification, unless stated to the contrary, when 771 the words Consumer, Merchant, Payment Handler, Delivery Handler or 772 Customer Care Provider are used, they refer to the Trading Role rather 773 than an actual organisation. 775 An individual organisation may take multiple roles. For example a 776 company which is selling goods and services on the Internet could take 777 the role of Merchant when selling goods or services and the role of 778 Consumer when the company is buying goods or services itself. 780 As roles occur in different places there is a need for the 781 organisations involved in the trade to exchange data, i.e. to carry 782 out Trading Exchanges, so that the trade can be completed. 784 2.2 Trading Exchanges 786 The Open Trading Protocols identify four Trading Exchanges which 787 involve the exchange of data between the Trading Roles. The Trading 788 Exchanges are: 790 o Offer. The Offer Exchange results in the Merchant providing the 791 Consumer with the reason why the trade is taking place. It is 792 called an Offer since the Consumer must accept the Offer if a 793 trade is to continue 795 o Payment. The Payment Exchange results in a payment of some kind 796 between the Consumer and the Payment Handler. This may occur in 797 either direction 799 o Delivery. The Delivery Exchange transmits either the on-line 800 goods, or delivery information about physical goods from the 801 Delivery Handler to the Consumer, and 803 o Authentication. The Authentication Exchange can be used by any 804 Trading Role to authenticate another Trading Role to check that 805 they are who they appear to be. 807 IOTP Transactions are composed of various combinations of these 808 Trading Exchanges. For example, an IOTP Purchase transaction includes 809 Offer, Payment, and Delivery Trading Exchanges. As another example, 810 an IOTP Value Exchange transaction is composed of an Offer Trading 811 Exchange and two Payment Trading Exchanges. 813 Trading Exchanges consist of Trading Components that are transmitted 814 between the various Trading Roles. Where possible, the number of 815 round-trip delays in an IOTP Transaction is minimised by packing the 816 Components from several Trading Exchanges into combination IOTP 817 Messages. For example, the IOTP Purchase transaction combines a 818 Delivery Organisation Component with an Offer Response Component in 819 order to avoid an extra Consumer request and response. 821 Each of the IOTP Trading Exchanges is described in more detail below. 822 For clarity of description, these describe the Trading Exchanges as 823 though they were standalone operations. For performance reasons, the 824 Trading Exchanges are intermingled in the actual IOTP Transaction 825 definitions. 827 2.2.1 Offer Exchange 829 The goal of the Offer Exchange is for the Merchant to provide the 830 Consumer with information about the trade so that the Consumer can 831 decide whether to continue with the trade. This is illustrated in the 832 figure below. 834 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 836 CONSUMER IOTP MESSAGE MERCHANT 837 1. Consumer decides to ----------------------> 2. Merchant checks 838 trade and sends Information on what is the information 839 information about the being purchased (Offer provided by the 840 transaction (requests Request) (outside scope Consumer, creates an 841 an offer) to the of IOTP) Offer and sends it 842 Merchant, e.g using to the Consumer| 843 HTML 844 v 845 3. Consumer checks the Components: Organisation(s) 846 information from the (Consumer, DeliverTo, Merchant, 847 Merchant and decides <---------- Payment Handler, Delivery 848 whether to continue Offer Handler, Cust Care); Order; Pay 849 Response Amount; Delivery; Signature 850 (Offer Response)(which signs 851 other components) 853 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 855 Figure 2 Offer Exchange 857 An Offer Exchange uses the following Trading Components that are 858 passed between the Consumer and the Merchant: 860 o the Organisation Component contains information which describes 861 the organisations which are taking a role in the trade: 862 - the consumer provides information, about who the consumer is and, 863 if goods or services are being delivered, where the goods or 864 services are to be delivered to 865 - the merchant augments this information by providing information 866 about the merchant, the Payment Handler, the customer care 867 provider and, if goods or services are being delivered, the 868 Delivery Handler 870 o the Order Component contains descriptions of the goods or 871 services which will result from the trade if the consumer 872 agrees to the offer. This information is sent by the Merchant 873 to the consumer who should verify it 875 o the Payment Component generated by the Merchant, contains 876 details of how much to pay, the currency and the payment 877 direction, for example the consumer could be asking for a 878 refund. Note that there may be more than one payment in a trade 880 o the Delivery Component, also generated by the Merchant, is used 881 if goods or services are being delivered. This contains 882 information about how delivery will occur, for example by post 883 or using e-mail 885 o the "Offer Response" Signature Component, if present, digitally 886 signs all of the above components to ensure their integrity. 888 The exact content of the information provided by the Merchant to the 889 Consumer will vary depending on the type of IOTP Transaction. For 890 example: 892 o low value purchases may not need a signature 894 o the amount to be paid may vary depending on the payment brand 895 and payment protocol used 897 o some offers may not involve the delivery of any goods 899 o a value exchange will involve two payments 901 o a merchant may not offer customer care. 903 Information provided by the consumer to the merchant is provided using 904 a variety of methods, for example, it could be provided: 906 o using [HTML] pages as part of the "shopping experience" of the 907 consumer. 909 o Using the Open Profiling Standard [OPS] which has recently been 910 proposed, 912 o in the form of Organisation Components associated with an 913 authentication of a Consumer by a Merchant 915 o as Order Components in a later version of IOTP. 917 2.2.2 Payment Exchange 919 The goal of the Payment Exchange is for a payment to be made from the 920 Consumer to a Payment Handler or vice versa using a payment brand and 921 payment protocol selected by the Consumer. A secondary goal is to 922 optionally provide the Consumer with a digitally signed Payment 923 Receipt which can be used to link the payment to the reason for the 924 payment as described in the Offer Exchange. 926 Payment Exchanges can work in a variety of ways. The most general case 927 where the trade is dependent on the payment brand and protocol used is 928 illustrated in the diagram below. Simpler payment exchanges are 929 possible. 931 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 933 CONSUMER IOTP MESSAGE MERCHANT 934 1. Consumer decides to 2. Merchant decides 935 trade and sends Information on what is which payment 936 information about the being paid for brand, payment 937 transaction (requests an ----------------------> protocols and 938 offer) to the Merchant, (outside scope of IOTP) currencies/amounts 939 e.g using HTML to offer, places 940 them in a Brand 941 List Component and 942 sends them to the 943 Consumer 944 | 945 v 946 3. Consumer selects the payment <----------------- Brand List 947 brand, protocol and currency/amount Brand List Component 948 to use, creates a Brand Selection 949 Component and sends it to the 950 Merchant 951 | 952 v 953 Brand Selection ----------------> 4. Merchant checks Brand 954 Brand Selection Selection, creates Payment Amount 955 information, optionally signs it 956 to authorise payment and sends it 957 to the Consumer 958 | 959 v 960 5. Consumer checks the Components: 961 Payment Amount information <-------- Pay Amount; Auth data; 962 and if OK requests that the Payment Organisation(s) (Merchant & 963 payment starts by sending Information Payment Handler); Signature 965 information to the Payment (Offer) (signs other 966 Handler components) 967 | 968 | ======================================== 969 v PAYMENT HANDLER 970 Components: Pay Scheme; Auth 6. Payment Handler checks 971 Data; Brand List; Pay Amount; information including 972 Brand Selection; ----------> optional signature and if 973 Organisation(s) (Merchant & Payment OK starts exchanging Pay 974 Payment Handler); Signature Request Scheme Components using 975 (Offer) (signs all other messages for selected 976 ----- components except payment brand and payment 977 | Pay Scheme) protocol 978 | | | 979 | v v 980 | Component: Pay Scheme <------------------> Component: Pay Scheme 981 | Payment Exchange 982 | | 983 | v 984 | 7. Eventually payment protocol messages 985 ----------- finish so Payment Handler sends Pay 986 | Receipt and optional signature to 987 | Consumer as proof of payment 988 | | 989 | v 990 8. Consumer checks Pay Components: Pay Receipt; Pay 991 Receipt is OK <------- scheme; Signature (Offer); 992 Payment Signature (Pay Receipt) (signs Pay 993 Response Receipt and Signature (Offer) 994 components) 996 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 998 Figure 3 Payment Exchange 1000 A Payment Exchange uses the following Trading Components that are 1001 passed between the Consumer, the Merchant and the Payment Handler: 1003 o The Brand List Component contains a list of payment brands (for 1004 example, MasterCard, Visa, Mondex, GeldKarte), payment 1005 protocols (for example SET Version 1.0, Secure Channel Credit 1006 Debit (SCCD - the name used for a credit or debit card payment 1007 where unauthorised access to account information is prevented 1008 through use of secure channel transport mechanisms such as SSL) 1009 as well as currencies/amounts that apply. The Merchant sends 1010 the Brand List to the Consumer. The consumer compares the 1011 payment brands, protocols and currencies/amounts on offer with 1012 those that the Consumer supports and makes a selection. 1014 o The Brand Selection Component contains the Consumer's 1015 selection. Payment brand, protocol, currency/amount and 1016 possibly protocol-specific information is sent back to the 1017 Merchant. This information may be used to change information in 1018 the Offer Exchange. For example, a merchant could choose to 1019 offer a discount to encourage the use of a store card. 1021 o The Organisation Components are generated by the Merchant. They 1022 contain details of the Merchant and Payment Handler Roles: 1023 - the Merchant role is required so that the Payment Handler can 1024 identify which Merchant initiated the payment. Typically, the 1025 result of the Payment Handler accepting (or making) a payment on 1026 behalf of the Merchant will be a credit or debit transaction to 1027 the Merchant's account held by the Payment Handler. These 1028 transactions are outside the scope of this version of IOTP 1029 - the Payment Handler role is required so that the Payment Handler 1030 can check that it is the correct Payment Handler to be used for 1031 the payment 1033 o The Payment Component contains details of how much to pay, the 1034 currency and the payment direction 1036 o The "Offer Response" Signature Component, if present, digitally 1037 signs all of the above components to ensure their integrity. 1038 Note that the Brand List and Brand Selection Components are not 1039 signed until the payment information is created (step 4 in the 1040 diagram) 1042 o The Payment Scheme Component contains messages from the payment 1043 protocol used in the Trade. For example they could be SET 1044 messages, Mondex messages, GeldKarte Messages or one of the 1045 other payment methods supported by IOTP. The content of the 1046 Payment Scheme Component is defined in the supplements that 1047 describe how IOTP works with various payment protocols. 1049 o The Payment Receipt Component contains a record of the payment. 1050 The content depends upon the payment protocol used. 1052 o The "Payment Receipt" Signature Component provides proof of 1053 payment by digitally signing both the Payment Receipt Component 1054 and the Offer Response Signature. The signature on the offer 1055 digitally signs the Order, Organisation and Delivery Components 1056 contained in the Offer. This signature effectively binds the 1057 payment to the offer. 1059 The example of a Payment Exchange above is the most general case. 1060 Simpler cases are also possible. For example, if the amount paid is 1061 not dependent on the payment brand and protocol selected then the 1062 payment information generated by step 3 can be sent to the Consumer at 1063 the same time as the Brand List Component generated by step 1. These 1064 and other variations are described in the Baseline Purchase IOTP 1065 Transaction (see section Baseline Purchase IOTP Transaction). 1067 2.2.3 Delivery Exchange 1069 The goal of the Delivery Exchange is to cause purchased goods to be 1070 delivered to the consumer either online or via physical delivery. A 1071 second goal is to provide a "delivery note" to the consumer, providing 1072 details about the delivery, such as shipping tracking number. The 1073 result of the delivery may also be signed so that it can be used for 1074 customer care in the case of problems with physical delivery. The 1075 message flow is illustrated in the diagram below. 1077 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1079 CONSUMER IOTP MESSAGE MERCHANT 1080 1. Consumer decides to ------------> 2. Merchant checks the 1081 trade and sends Information information provided by the 1082 information about what on what is Consumer, adds information 1083 to deliver and who is being about how the delivery will 1084 to take delivery, to delivered occur, information about the 1085 the Merchant, using for (outside organisations involved in the 1086 example, HTML scope of delivery and optionally signs 1087 IOTP) it 1088 | 1089 v 1090 3. Consumer checks the Components: 1091 delivery information is OK, Delivery; 1092 obtains authorisation for <----------------- Organisation(s) 1093 the delivery, for example by Delivery Delivery Handler, 1094 making a payment, and sends Information Deliver To; Order; 1095 the delivery information to Signature (Offer) 1096 the Delivery Handler. 1097 | 1098 v 1099 Components: Delivery; 4. Delivery Handler checks 1100 Organisation(s), Merchant, information and 1101 Delivery Handler, DelivTo; --------> authorisation. Starts or 1102 Order; Signature (Offer); Delivery schedules delivery and 1103 Signature (Pay Receipt) Request creates and then sends a 1104 (from Payment Exchange) delivery note to the Consumer 1105 which can optionally be signed 1106 | 1107 v 1108 5. Consumer checks delivery <--------- Component: Delivery 1109 note is OK and accepts or waits Delivery Note; Signature 1110 for delivery as described in Response (Delivery Response) 1111 the Delivery Note 1113 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1114 Figure 4 Delivery Exchange 1116 A Delivery Exchange uses the following Trading Components that are 1117 passed between the Consumer, the Merchant and the Delivery Handler: 1119 o The Organisation Component(s) contain details of the Deliver 1120 To, Delivery Handler and Merchant Roles: 1121 - the Deliver To role indicates where the goods or services are to 1122 be delivered to 1123 - the Delivery Handler role is required so that the Delivery Handler 1124 can check that she is the correct Delivery Handler to do the 1125 delivery 1126 - the Merchant role is required so that the Delivery Handler can 1127 identify which Merchant initiated the delivery 1129 o The Order Component, contains information about the goods or 1130 services to be delivered 1132 o The Delivery Component contains information about how delivery 1133 will occur, for example by post or using e-mail. 1135 o The "Offer Response" Signature Component, if present, digitally 1136 signs all of the above components to ensure their integrity. 1138 o The "Payment Receipt" Signature Component provides proof of 1139 payment by digitally signing the Payment Receipt Component and 1140 the Offer Signature. This is used by the Delivery Handler to 1141 check that delivery is authorised 1143 o The Delivery Note Component contains customer care information 1144 related to a physical delivery, or alternatively the actual 1145 "electronic goods". The Consumer's software does not interpret 1146 information about a physical delivery but should have the 1147 ability to display the information, both at the time of the 1148 delivery and later if the Consumer selects the Trade to which 1149 this delivery relates from a transaction list 1151 o The "Delivery Response" Signature Component, if present, 1152 provides proof of the results of the Delivery by digitally 1153 signing the Delivery Note and any Offer Response or Payment 1154 Response signatures that the Delivery Handler received. 1156 2.2.4 Authentication Exchange 1158 The goal of the Authentication Exchange is to allow one organisation, 1159 for example a financial institution, to be able to check that another 1160 organisation, for example a consumer, is who they appear to be. It 1161 uses a "challenge-response" mechanism. 1163 An Authentication Exchange involves: 1165 o an Authenticator - the organisation which is requesting the 1166 authentication, and 1168 o an Authenticatee - the organisation being authenticated. 1170 This is illustrated in the diagram below. 1172 +*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1174 ORGANISATION 1 IOTP MESSAGE ORGANISATION 2 1175 (AUTHENTICATEE) (AUTHENTICATOR) 1176 1. First organisation, 2. The second 1177 e.g a consumer, takes an organisation generates 1178 action (for example by ----------------> Authentication Data 1179 pressing a button on an Need for containing challenge 1180 HTML page) which Authentication data, the method of 1181 requires that the (outside scope of authentication to be used 1182 organisation is IOTP) and optionally a request 1183 authenticated for Organisation 1184 information then sends it 1185 to the first organisation 1186 | 1187 v 1188 3. The first organisation Component: 1189 optionally checks any signature <------------ Authentication Data 1190 associated with the Authentication 1191 Authentication request then Request 1192 uses the challenge data with 1193 the specified authentication 1194 method to generate an 1195 Authentication Response which 1196 is sent back to the second 1197 organisation together with 1198 details of any Organisation 1199 information requested 1200 | 1201 v 1202 Component: 4. The Authentication Response is 1203 Authentication -------------> checked against the challenge data to 1204 Response Authentication check that the first organisation is 1205 Response who they appear to be and the result 1206 recorded in a Status Component which 1207 is then sent back to the first 1208 organisation 1209 | 1210 v 1211 5. The first organisation then Component: Status 1212 optionally checks the results <------------ 1213 of the Status and any Authentication 1214 associated signature and takes Status 1215 the appropriate action or 1216 stops. 1218 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1219 Figure 5 Authentication Exchange 1221 An Authentication Exchange uses the following Trading Components that 1222 are passed between the two organisations: 1224 o the Authentication Data Component which contains the challenge 1225 data to be used in the "challenge-response" mechanism, 1226 indicates the authentication method to be used and optionally 1227 request Organisation data about the first organisation, for 1228 example a ship to or billing address. It is sent by one 1229 organisation to the other. 1231 o The Authentication Response Component which contains the 1232 challenge response generated by the recipient of the 1233 Authentication Data Component. It is sent back to the first 1234 organisation for verification together with Organisation 1235 Components requested 1237 o the Status Component which contains the results of the second 1238 party's verification of the Authentication Response. 1240 2.3 Scope of Baseline IOTP 1242 This specification describes the IOTP Transactions which make up 1243 Baseline IOTP. As described in the preface, IOTP will evolve over 1244 time. This section defines the initial conformance criteria for 1245 implementations that claim to _support IOTP._ 1247 The main determinant on the scope of an IOTP implementation is the 1248 roles which the solution is designed to support. The roles within IOTP 1249 are described in more detail in section 2.1 Trading Roles. To 1250 summarise the roles are: Merchant, Consumer, Payment Handler, Delivery 1251 Handler and Customer Care Provider. 1253 Payment Handlers who can be of three types: 1255 o those who accept a payment as part of a purchase or make a 1256 payment as part of a refund, 1258 o those who accept value as part of a deposit transaction, or 1260 o those that issue value a withdrawal transaction 1261 The following table defines, for each role, the IOTP Transactions and 1262 Trading Blocks which must be supported for that role. 1264 Merchants 1266 ECash ECash 1267 Store Value Value Consumer Payment Delivery 1268 Issuer Acquirer Handler Handler 1270 TRANSACTIONS 1272 Purchase Must Must 1274 Refund Must b) 1275 Depends 1277 Authentication May Must May b) 1278 Depends 1280 Value Exchange May Must 1282 Withdrawal Must b) 1283 Depends 1285 Deposit Must b) 1286 Depends 1288 Inquiry Must Must Must Must Must Must 1290 Ping Must Must Must Must Must Must 1291 Merchants 1293 ECash ECash 1294 Store Value Value Consumer Payment Delivery 1295 Issuer Acquirer Handler Handler 1297 TRADING BLOCKS 1299 TPO Must Must Must Must 1301 TPO Selection Must Must Must Must 1303 Auth-Request a) a) a) 1304 Depends Depends Depends 1306 Auth-Reply a) a) a) 1307 Depends Depends Depends 1309 Offer Response Must Must Must Must 1311 Payment Must Must 1312 Request 1314 Payment Must Must 1315 Exchange 1317 Payment Must Must 1318 Response 1320 Delivery Must Must 1321 Request 1322 Merchants 1324 ECash ECash 1325 Store Value Value Consumer Payment Delivery 1326 Issuer Acquirer Handler Handler 1328 Delivery Must Must 1329 Response 1331 Inquiry Must Must Must Must Must Must 1332 Request 1334 Inquiry Must Must Must Must Must Must 1335 Response 1337 Ping Request Must Must Must Must Must Must 1339 Ping Response Must Must Must Must Must Must 1341 Signature Must Must Must Limited Must Must 1343 Error Must Must Must Must Must Must 1345 In the above table: 1347 o _Must_ means that a Trading Role must support the Transaction 1348 or Trading Block. 1350 o _May_ means that an implementation may support the Transaction 1351 or Trading Block at the option of the developer. 1353 o _Depends_ means implementation of the Transaction or Trading 1354 Block depends on one of the following conditions: 1356 a) if Baseline Authentication IOTP Transaction is supported; 1357 b) if required by a Payment Method as defined in its IOTP 1358 Supplement document. 1360 o "Limited" means the Trading Block must be understood and its 1361 content manipulated but not in every respect. Specifically, on 1362 the Signature Block, Consumers do not have to be able to 1363 validate digital signatures. 1365 An IOTP solution must support all the IOTP Transactions and Trading 1366 Blocks required by at least one role (column) as described in the 1367 above table for that solution to be described as "supporting IOTP". 1369 3. Protocol Structure 1371 The previous section provided an introduction which explained: 1373 o Trading Roles which are the different roles which organisations 1374 can take in a trade: Consumer, Merchant, Payment Handler, 1375 Delivery Handler and Customer Care Provider, and 1377 o Trading Exchanges where each Trading Exchange involves the 1378 exchange of data, between Trading Roles, in the form of a set 1379 of Trading Components. 1381 This section describes: 1383 o how Trading Components are constructed into Trading Blocks and 1384 the IOTP Messages which are physically sent in the form of 1385 [XML] documents between the different Trading Roles, 1387 o how IOTP Messages are exchanged between Trading Roles to create 1388 an IOTP Transaction 1390 o the XML definitions of an IOTP Message including a Transaction 1391 Reference Block - an XML element which identifies an IOTP 1392 Transaction and the IOTP Message within it 1394 o the definitions of the XML ID Attributes which are used to 1395 identify IOTP Messages, Trading Blocks and Trading Components 1396 and how these are referred to using Element References from 1397 other XML elements 1399 o an overview of Brands and Brand Selection which describes how a 1400 Consumer can select a Brand from a list provided by the 1401 Merchant 1403 o how extra XML Elements and new user defined values for existing 1404 IOTP codes can be used when Extending IOTP, 1406 o how IOTP uses the Packaged Content Element to embed data such 1407 as payment protocol messages or detailed order definitions 1408 within an IOTP Message 1410 o how IOTP Identifies Languages so that different languages can 1411 be used within IOTP Messages 1413 o how IOTP handles both Secure and Insecure Net Locations when 1414 sending messages 1416 o how an IOTP Transaction can be cancelled. 1418 3.1 Overview 1420 3.1.1 IOTP Message Structure 1422 The structure of an IOTP Message and its relationship with Trading 1423 Blocks and Trading Components is illustrated in the diagram below. 1425 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1427 IOTP MESSAGE <---------- IOTP Message - an XML Document which is 1428 | transported between the Trading Roles 1429 |-Trans Ref Block <----- Trans Ref Block - contains information which 1430 | | describes the IOTP Transaction and the IOTP 1431 | | Message. 1432 | |-Trans Id Comp. <--- Transaction Id Component - uniquely 1433 | | identifies the IOTP Transaction. The Trans Id 1434 | | Components are the same across all IOTP 1435 | | messages that comprise a single IOTP 1436 | | transaction. 1437 | |-Msg Id Comp. <----- Message Id Component - identifies and 1438 | describes an IOTP Message within an IOTP 1439 | Transaction 1440 |-Signature Block <----- Signature Block (optional) - contains one or 1441 | | more Signature Components and their 1442 | | associated Certificates 1443 | |-Signature Comp. <-- Signature Component - contains digital 1444 | | signatures. Signatures may sign digests of 1445 | | the Trans Ref Block and any Trading Component 1446 | | in any IOTP Message in the same IOTP 1447 | | transaction. 1448 | |-Certificate Comp. < Certificate Component. Used to check the 1449 | signature. 1450 |-Trading Block <------- Trading Block - an XML Element within an IOTP 1451 | |-Component Message that contains a predefined set of 1452 | |-Component Trading Components 1453 | |-Component 1454 | |-Component <-------- Trading Components - XML Elements within a 1455 | Trading Block that contain a predefined set 1456 |-Trading Block of XML elements and attributes containing 1457 | |-Component information required to support a Trading 1458 | |-Component Exchange 1459 | |-Component 1460 | |-Component 1461 | |-Component 1463 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1464 Figure 6 IOTP Message Structure 1466 The diagram also introduces the concept of a Transaction Reference 1467 Block. This block contains, amongst other things, a globally unique 1468 identifier for the IOTP Transaction. Also each block and component is 1469 given an ID Attribute (see section 3.4) which is unique within an IOTP 1470 Transaction. Therefore the combination of the ID attribute and the 1471 globally unique identifier in the Transaction Reference Block is 1472 sufficient to uniquely identify any Trading Block or Trading 1473 Component. 1475 3.1.2 IOTP Transactions 1477 A predefined set of IOTP Messages exchanged between the Trading Roles 1478 constitute an IOTP Transaction. This is illustrated in the diagram 1479 below. 1481 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 1483 CONSUMER MERCHANT 1484 Generate first 1485 IOTP Message 1486 --- | 1487 | | v 1488 Process incoming | I | ------------- 1489 IOTP Message & <------------- | | -------------- | IOTP Message | 1490 generate next IOTP | | ------------- 1491 Message | N | 1492 | | | 1493 v | | 1494 ------------- | T | Process incoming 1495 | IOTP Message | -------------- | | -------------> IOTP Message & 1496 ------------- | | generate next 1497 | E | IOTP Message 1498 | | | 1499 | | v 1500 Process incoming | R | ------------- 1501 IOTP Message <------------- | | -------------- | IOTP Message | 1502 generate last IOTP | | ------------- 1503 Message & stop | N | 1504 | | | 1505 v | | 1506 ------------- | E | Process last 1507 | IOTP Message | -------------- | | -------------> incoming IOTP 1508 ------------- | | Message & stop 1509 | | T | | 1510 v | | v 1511 STOP --- STOP 1513 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1515 Figure 7 An IOTP Transaction 1517 In the above diagram the Internet is shown as the transport mechanism. 1518 This is not necessarily the case. IOTP Messages can be transported 1519 using a variety of transport mechanisms. 1521 The IOTP Transactions (see section 8) in this version of IOTP are 1522 specifically: 1524 o Purchase. This supports a purchase involving an offer, a 1525 payment and optionally a delivery 1527 o Refund. This supports the refund of a payment as a result of, 1528 typically, an earlier purchase 1530 o Value Exchange. This involves two payments which result in the 1531 exchange of value from one combination of currency and payment 1532 method to another 1534 o Authentication. This supports the remote authentication of a 1535 Consumer by another Trading Role using a variety of 1536 authentication methods, and the provision of an Organisation 1537 Component about a Consumer to another Trading Role for use in, 1538 for example the creation of an offer 1540 o Withdrawal. This supports the withdrawal of electronic cash 1541 from a financial institution 1543 o Deposit. This supports the deposit of electronic cash at a 1544 financial institution 1546 o Inquiry This supports inquiries on the status of an IOTP 1547 transaction which is either in progress or is complete 1549 o Ping This supports a simple query which enables one IOTP aware 1550 application to determine whether another IOTP application 1551 running elsewhere is working or not. 1553 3.2 IOTP Message 1555 As described earlier, IOTP Messages are [XML] documents which are 1556 physically sent between the different Trading Roles that are taking 1557 part in a trade. 1559 The XML definition of an IOTP Message is as follows. 1561 1583 1587 Content: 1589 TransRefBlk This contains information which describes an 1590 IOTP Message within an IOTP Transaction (see 1591 section 3.3 immediately below) 1593 AuthReqBlk, These are the Trading Blocks. 1594 AuthRespBlk, 1595 DeliveryReqBlk, The Trading Blocks present within an IOTP 1596 DeliveryRespBlk Message, and the content of a Trading Block 1597 ErrorBlk itself is dependent on the type of IOTP 1598 InquiryReqBlk, Transaction being carried out - see the 1599 InquiryRespBlk, definition of each transaction in section 8 1600 OfferRespBlk, Internet Open Trading Protocol Transactions. 1601 PayExchBlk, 1602 PayReqBlk, Full definitions of each Trading Block are 1603 PayRespBlk, described in section 7. 1604 PingReqBlk, 1605 PingRespBlk, 1606 SigBlk, 1607 TpoBlk, 1608 TpoSelectionBlk 1610 Attributes 1612 xmlns:iotp The [XML Namespace] definition for IOTP 1613 messages. 1615 3.2.1 XML Document Prolog 1617 The IOTP Message is the root element of the XML document. It therefore 1618 needs to be preceded by an appropriate XML Document Prolog. For 1619 example: 1621 1622 1623 1624 ... 1625 1627 3.3 Transaction Reference Block 1629 A Transaction Reference Block contains information which identifies 1630 the IOTP Transaction and IOTP Message. The Transaction Reference Block 1631 contains: 1633 o a Transaction Id Component which globally uniquely identifies 1634 the IOTP Transaction. The Transaction Id Components are the 1635 same across all IOTP messages that comprise a single IOTP 1636 transaction, 1638 o a Message Id Component which provides control information about 1639 the IOTP Message as well as uniquely identifying the IOTP 1640 Message within an IOTP Transaction, and 1642 o zero or more Related To Components which link this IOTP 1643 Transaction to either other IOTP Transactions or other events 1644 using the identifiers of those events. 1646 The definition of a Transaction Reference Block is as follows: 1648 1649 1652 Attributes: 1654 ID An identifier which uniquely identifies the 1655 Transaction Reference Block within the IOTP 1656 Transaction (see section 3.4 ID Attributes). 1658 Content: 1660 TransId See 3.3.1 Transaction Id Component immediately 1661 below. 1663 MsgId See 3.3.2 Message Id Component immediately 1664 below. 1666 RelatedTo See 3.3.3 Related To Component immediately 1667 below. 1669 3.3.1 Transaction Id Component 1671 This contains information which globally uniquely identifies the IOTP 1672 Transaction. Its definition is as follows: 1674 1675 1682 Attributes: 1684 ID An identifier which uniquely identifies the 1685 Transaction Id Component within the IOTP 1686 Transaction. 1688 Version This identifies the version of IOTP, and 1689 therefore the structure of the IOTP Messages, 1690 which the IOTP Transaction is using. 1692 OtpTransId Contains data which uniquely identifies the IOTP 1693 Transaction. It must conform to the rules for 1694 Message Ids in [RFC 822]. 1696 OtpTransType This is the type of IOTP Transaction being 1697 carried out. For Baseline IOTP it identifies a 1698 "standard" IOTP Transaction and implies the 1699 sequence and content of the IOTP Messages 1700 exchanged between the Trading Roles. The valid 1701 values for Baseline IOTP are: 1702 o BaselineAuthentication 1703 o BaselineDeposit 1704 o BaselinePurchase 1705 o BaselineRefund 1706 o BaselineWithdrawal 1707 o BaselineValueExchange 1708 o BaselineInquiry 1709 o BaselinePing 1711 Values of OtpTransType are managed under the 1712 procedure described in section 3.7.3 Values for 1713 IOTP Codes which also allows user defined values 1714 of OtpTransType to be defined. 1716 In later versions of IOTP, this list will be 1717 extended to support different types of standard 1718 IOTP Transaction based on market demand. It is 1719 also likely to support the type Dynamic which 1720 indicates that the sequence of steps within the 1721 transaction are non-standard. 1723 TransTimeStamp Where the system initiating the IOTP Transaction 1724 has an internal clock, it is set to the time at 1725 which the IOTP Transaction started in [UTC] 1726 format. 1728 The main purpose of this attribute is to provide 1729 an alternative way of identifying a transaction 1730 by specifying the time at which it started. 1732 Some systems, for example, hand held devices may 1733 not be able to generate a time stamp. In this 1734 case this attribute should contain the value 1735 "NA" for Not Available. 1737 3.3.2 Message Id Component 1739 The Message Id Component provides control information about the IOTP 1740 Message as well as uniquely identifying the IOTP Message within an 1741 IOTP Transaction. Its definition is as follows. 1743 1744 1752 Attributes: 1754 ID An identifier which uniquely identifies the IOTP 1755 Message within the IOTP Transaction (see section 1756 3.4 ID Attributes). Note that if an IOTP Message 1757 is resent then the value of this attribute 1758 remains the same. 1760 RespOtpMsg This contains the ID attribute of the Message Id 1761 Component of the IOTP Message to which this IOTP 1762 Message is a response. In this way all the IOTP 1763 Messages in an IOTP Transaction are 1764 unambiguously linked together. This field is 1765 required on every IOTP Message except the first 1766 IOTP Message in an IOTP Transaction. 1768 SenderTradingRoleR The Element Reference (see section 3.5) of the 1769 ef Trading Role which has generated the IOTP 1770 message. It is used to identify the Net 1771 Locations (see section 3.10) of the Trading Role 1772 to which problems Technical Errors (see section 1773 4.1) with any of Trading Blocks should be 1774 reported. 1776 xml:lang Defines the language used by attributes or child 1777 elements within this component, unless 1778 overridden by an xml:lang attribute on a child 1779 element. See section 3.9 Identifying Languages. 1781 SoftwareId This contains information which identifies the 1782 software which generated the IOTP Message. Its 1783 purpose is to help resolve interoperability 1784 problems that might occur as a result of 1785 incompatibilities between messages produced by 1786 different software. It is a single text string 1787 in the language defined by xml:lang. It must 1788 contain, as a minimum: 1789 o the name of the software manufacturer 1790 o the name of the software 1791 o the version of the software, and 1792 o the build of the software 1794 TimeStamp Where the device sending the message has an 1795 internal clock, it is set to the time at which 1796 the IOTP Message was created in [UTC] format. 1798 3.3.3 Related To Component 1800 The Related To Component links IOTP Transactions to either other IOTP 1801 Transactions or other events using the identifiers of those events. 1802 Its definition is as follows. 1804 1805 1812 Attributes: 1814 ID An identifier which uniquely identifies the 1815 Related To Component within the IOTP 1816 Transaction. 1818 xml:lang Defines the language used by attributes or child 1819 elements within this component, unless 1820 overridden by an xml:lang attribute on a child 1821 element. See section 3.9 Identifying Languages. 1823 RelationshipType Defines the type of the relationship. Valid 1824 values are: 1825 o OtpTransaction. in which case the Packaged 1826 Content Element contains an OtpTransId of 1827 another IOTP Transaction 1828 o Reference in which case the Packaged Content 1829 Element contains the reference of some other, 1830 non-IOTP document. 1832 Values of RelationshipType are controlled under 1833 the procedures defined in section 3.7.3 Values 1834 for IOTP Codes which also allows user defined 1835 values to be defined. 1837 Relation The Relation attribute contains a phrase in the 1838 language defined by xml:lang which describes the 1839 nature of the relationship between the IOTP 1840 transaction that contains this component and 1841 another IOTP Transaction or other event. The 1842 exact words to be used are left to the 1843 implementers of the IOTP software. 1845 The purpose of the attribute is to provide the 1846 Trading Roles involved in an IOTP Transaction 1847 with an explanation of the nature of the 1848 relationship between the transactions. 1850 Care should be taken that the words used to in 1851 the Relation attribute indicate the "direction" 1852 of the relationship correctly. For example: one 1853 transaction might be a refund for another 1854 earlier transaction. In this case the 1855 transaction which is a refund should contain in 1856 the Relation attribute words such as "refund 1857 for" rather than "refund to" or just "refund". 1859 RelnKeyWords This attribute contains keywords which could be 1860 used to help identify similar relationships, for 1861 example all refunds. It is anticipated that 1862 recommended keywords will be developed through 1863 examination of actual usage. In this version of 1864 the specification there are no specific 1865 recommendations and the keywords used are at the 1866 discretion of implementers. 1868 Content: 1870 PackagedContent The Packaged Content (see section 3.8) contains 1871 data which identifies the related transaction. 1872 Its format varies depending on the value of the 1873 RelationshipType. 1875 3.4 ID Attributes 1877 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading 1878 Blocks), Trading Components (including the Transaction Id Component 1879 and the Signature Component) and some of their child elements are each 1880 given an XML "ID" attribute which is used to identify an instance of 1881 these XML elements. These identifiers are used so that one element can 1882 be referenced by another. All these attributes are given the attribute 1883 name ID. 1885 The values of each ID attribute are unique within an IOTP transaction 1886 i.e. the set of IOTP Messages which have the same globally unique 1887 Transaction ID Component. Also, once the ID attribute of an element 1888 has been assigned a value it is never changed. This means that 1889 whenever an element is copied, the value of the ID attribute remains 1890 the same. 1892 As a result it is possible to use these IDs to refer to and locate the 1893 content of any IOTP Message, Block or Component from any other IOTP 1894 Message, Block or Component in the same IOTP Transaction using Element 1895 References (see section 3.5). 1897 This section defines the rules for setting the values for the ID 1898 attributes of IOTP Messages, Blocks and Components. 1900 3.4.1 IOTP Message ID Attribute Definition 1902 The ID attribute of the Message Id Component of an IOTP Message must 1903 be unique within an IOTP Transaction. It's definition is as follows: 1905 OtpMsgId_value ::= OtpMsgIdPrefix OtpMsgIdSuffix 1906 OtpMsgIdPrefix ::= NameChar (NameChar)* 1907 OtpMsgIdSuffix ::= Digit (Digit)* 1909 OtpMsgIdPrefix Apart from messages which contain an Inquiry 1910 Request Trading Block (see section 7.12), the 1911 same prefix is used for all messages sent by the 1912 Merchant or Consumer role as follows: 1913 o "M" - Merchant 1914 o "C" - Consumer 1916 For messages which contain an Inquiry Request 1917 Trading Block, the prefix is set to "I" for 1918 Inquiry. 1920 The prefix for the other roles in a trade is 1921 contained within the Organisation Component for 1922 the role and are typically set by the Merchant. 1923 The following is recommended as a guideline and 1924 must not be relied upon: 1925 o "P" - First (only) Payment Handler 1926 o "R" - Second Payment Handler 1927 o "D" - Delivery Handler 1929 As a guideline, prefixes should be limited to 1930 one character. 1932 NameChar has the same definition as the [XML] 1933 definition of NameChar. 1935 OtpMsgIdSuffix The suffix consists of one or more digits. The 1936 suffix must be unique within a Trading Role 1937 within an IOTP Transaction. The following is 1938 recommended as a guideline and must not be 1939 relied upon: 1940 o the first IOTP Message sent by a trading role 1941 is given the suffix "1" 1942 o the second and subsequent IOTP Messages sent 1943 by the same trading role are incremented by 1944 one for each message 1945 o no leading zeroes are included in the suffix 1946 Put more simply the Message Id Component of the 1947 first IOTP Message sent by a Consumer would have 1948 an ID attribute of, "C1", the second "C2", the 1949 third "C3" etc. 1951 Digit has the same definition as the [XML] 1952 definition of Digit. 1954 3.4.2 Block and Component ID Attribute Definitions 1956 The ID Attribute of Blocks and Components must also be unique within 1957 an IOTP Transaction. Their definition is as follows: 1959 BlkOrCompId_value ::= OtpMsgId_value "." IdSuffix 1960 IdSuffix ::= Digit (Digit)* 1962 OtpMsgId_value The ID attribute of the Message ID Component of 1963 the IOTP Message where the Block or Component is 1964 first used. 1966 In IOTP, Trading Components and Trading Blocks 1967 are copied from one IOTP Message to another. The 1968 ID attribute does not change when an existing 1969 Trading Block or Component is copied to another 1970 IOTP Message. 1972 IdSuffix The suffix consists of one or more digits. The 1973 suffix must be unique within the ID attribute of 1974 the Message ID Component used to generate the ID 1975 attribute. The following is recommended as a 1976 guideline and must not be relied upon: 1977 o the first Block or Component sent by a trading 1978 role is given the suffix "1" 1979 o the ID attributes of the second and subsequent 1980 Blocks or Components are incremented by one 1981 for each new Block or Component added to an 1982 IOTP Message 1983 o no leading zeroes are included in the suffix 1985 Put more simply, the first new Block or 1986 Component added to the second IOTP Message sent, 1987 for example, by a consumer would have a an ID 1988 attribute of "C2.1", the second "C2.2", the 1989 third "C2.3" etc. 1991 Digit has the same definition as the [XML] 1992 definition of Digit. 1994 3.4.3 Example of use of ID Attributes 1996 The diagram below illustrates how ID attribute values are used. 1998 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 2000 1st IOTP MESSAGE 2nd IOTP MESSAGE 2001 (e.g. from Merchant to (e.g. from Consumer to 2002 Consumer Payment Handler) 2004 IOTP MESSAGE IOTP MESSAGE * 2005 |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* 2006 | |-Trans Id Comp. ID = M1. ------------->| |-Trans Id Comp. 2007 | | Copy Element | | ID=M1.2 2008 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * 2009 | | 2010 |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* 2011 | |-Sig Comp. ID=M1.15 ---- ------------->| |-Comp. ID=M1.15 2012 | Copy Element | 2013 |-Trading Block. ID=M1.3 |-Trading Block. ID=C1.2 * 2014 | |-Comp. ID=M1.4 --------- ---------------->|-Comp. ID=M1.4 2015 | | Copy Element | 2016 | |-Comp. ID=M1.5 --------- ---------------->|-Comp. ID=M1.5 2017 | | Copy Element | 2018 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * 2019 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * 2020 | 2021 |-Trading Block. ID=M1.3 2022 |-Comp. ID=M1.4 * = new elements 2023 |-Comp. ID=M1.5 2024 |-Comp. ID=M1.6 2025 |-Comp. ID=M1.7 2027 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 2029 Figure 8 Example use of ID attributes 2031 3.5 Element References 2033 A Trading Component or one of its child XML elements, may contain an 2034 XML attribute that refers to another Block (i.e. a Transaction 2035 Reference Block or a Trading Block) or Trading Component (including a 2036 Transaction Id and Signature Component). These Element References are 2037 used for many purposes, a few examples include: 2039 o identifying an XML element whose Digest is included in a 2040 Signature Component, 2042 o referring to the Payment Handler Organisation Component which 2043 is used when making a Payment 2045 An Element Reference always contains the value of an ID attribute of a 2046 Block or Component. 2048 Identifying the IOTP Message, Trading Block or Trading Component which 2049 is referred to by an Element Reference, involves finding the XML 2050 element which: 2052 o belongs to the same IOTP Transaction (i.e. the Transaction Id 2053 Components of the IOTP Messages match), and 2055 o where the value of the ID attribute of the element matches the 2056 value of the Element Reference. 2058 [Note] The term "match" in this specification has the same 2059 definition as the [XML] definition of match. 2060 [Note End] 2062 An example of "matching" an Element Reference is illustrated in the 2063 example below. 2065 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 2067 1st IOTP MESSAGE 2nd IOTP MESSAGE 2068 (e.g. from Merchant to (e.g. from Consumer to 2069 Consumer Payment Handler) 2071 IOTP MESSAGE IOTP MESSAGE 2072 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans Ref Block. ID=C1.1 2073 | |-Trans Id Comp. ID = M1. <-Components--|->|-Trans Id Comp.ID=M1.2 2074 | | must be | | 2075 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 2076 | ^ | 2077 |-Signature Block. ID=M1.8 | |-Signature Block. ID=C1.5 2078 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 2079 | AND | 2080 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 2081 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 2082 | | v | 2083 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 2084 | | and El Ref | 2085 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 2086 | | match--------|--> El Ref=M1.6 2087 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 2088 | 2089 |-Trading Block. ID=M1.3 2090 |-Comp. ID=M1.4 2091 |-Comp. ID=M1.5 2092 |-Comp. ID=M1.6 2093 |-Comp. ID=M1.7 2095 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 2097 Figure 9 Element References 2099 [Note] Element Reference attributes are defined as "NMTOKEN" rather 2100 than "IDREF" (see [XML]). This is because an IDREF requires 2101 that the XML element referred to is in the same XML 2102 Document. With IOTP this is not necessarily the case. 2103 [Note End] 2105 3.6 Brands and Brand Selection 2107 One of the key features of IOTP is the ability for a merchant to offer 2108 a list of Brands from which a consumer may make a selection. This 2109 section provides an overview of what is involved and provides guidance 2110 on how selection of a brand and associated payment instrument can be 2111 carried out by a Consumer. It covers: 2113 o definitions of Payment Instruments and Brands - what are 2114 Payment Instruments and Brands in an IOTP context. Further 2115 categorises Brands as optionally a "Dual Brand" or a 2116 "Promotional Brand", 2118 o identification and selection of Promotional Brands - 2119 Promotional Brands offer a Consumer some additional benefit, 2120 for example loyalty points or a discount. This means that both 2121 Consumers and Merchant must be able to correctly identify that 2122 a valid Promotional Brand is being used. 2124 Also see the following sections: 2126 o Brand List Component (section 6.6) which contains definitions 2127 of the XML elements which contain the list of Brands offered by 2128 a Merchant to a Consumer, and 2130 o Brand Selection Component (section 6.7) for details of how a 2131 Consumer records the Brand that was selected. 2133 3.6.1 Definition of Payment Instrument 2135 A Payment Instrument is the means by which a Consumer pays for goods 2136 or services offered by a Merchant. It can be, for example: 2138 o a credit card such as MasterCard or Visa; 2140 o a debit card such as MasterCard's Maestro; 2142 o a smart card based electronic cash payment instrument such as a 2143 Mondex Card, a GeldKarte card or a Visa Cash card 2145 o a software based electronic payment account such as a CyberCash 2146 or DigiCash account. 2148 All Payment Instruments have a number, typically an account number, by 2149 which the Payment Instrument can be identified. 2151 3.6.2 Definition of Brand 2153 A Brand is the mark which identifies a particular type of Payment 2154 Instrument. A list of Brands are the payment options which are 2155 presented by the Merchant to the Consumer and from which the Consumer 2156 makes a selection. Each Brand may have a different Payment Handler. 2157 Examples of Brands include: 2159 o payment association and proprietary Brands, for example 2160 MasterCard, Visa, American Express, Diners Club, Mondex, 2161 GeldKarte, CyberCash, etc. 2163 o promotional brands (see below). These include: 2164 - store brands, where the Payment Instrument is issued to a Consumer 2165 by a particular Merchant, for example Walmart, Sears, or Marks and 2166 Spencer (UK) 2167 - cobrands, for example American Advantage Visa, where an 2168 organisation uses their own brand in conjunction with, typically, 2169 a payment association Brand. 2171 3.6.3 Definition of Dual Brand 2173 A Dual Brand means that a single payment instrument may be used as if 2174 it were two separate Brands. For example there could be a single 2175 Japanese "UC" MasterCard which can be used as either a UC card or a 2176 regular MasterCard. The UC card Brand and the MasterCard Brand could 2177 each have their own separate Payment Handlers. This means that: 2179 o the merchant treats, for example "UC" and "MasterCard" as two 2180 separate Brands when offering a list of Brands to the Consumer, 2182 o the consumer chooses a Brand, for example either "UC" or 2183 "MasterCard, 2185 o the consumer IOTP aware application determines which Payment 2186 Instrument(s) match the chosen Brand, and selects, perhaps with 2187 user assistance, the correct Payment Instrument to use. 2189 [Note] Dual Brands need no special treatment by the Merchant and 2190 therefore no explicit reference is made to Dual Brands in 2191 the DTD. This is because, as far as the Merchant is 2192 concerned, each Brand in a Dual Brand is treated as a 2193 separate Brand. It is at the Consumer, that the matching of 2194 a Brand to a Dual Brand Payment Instrument needs to be done. 2195 [Note End] 2196 3.6.4 Definition of Promotional Brand 2198 A Promotional Brand means that, if the Consumer pays with that Brand, 2199 then the Consumer will receive some additional benefit which can be 2200 received in two ways: 2202 o at the time of purchase. For example if a Consumer pays with a 2203 "Walmart MasterCard" at a Walmart web site, then a 5% discount 2204 might apply, which means the consumer actually pays less, 2206 o from their Payment Instrument (card) issuer when the payment 2207 appears on their statement. For example loyalty points in a 2208 frequent flyer scheme could be awarded based on the total 2209 payments made with the Payment Instrument since the last 2210 statement was issued. 2212 Note that: 2214 o the first example (obtaining the benefit at the time of 2215 purchase), requires that: 2216 - the Consumer is informed of the benefits which arise if that Brand 2217 is selected 2218 - if the Brand is selected, the Merchant changes the relevant IOTP 2219 Components in the Offer Response to reflect the correct amount to 2220 be paid 2222 o the second (obtaining a benefit through the Payment Instrument 2223 issuer) does not require that the Offer Response is changed 2225 o each Promotional Brand should be identified as a separate Brand 2226 in the list of Brands offered by the Merchant. For example: 2227 "Walmart", "Sears", "Marks and Spencer" and "American Advantage 2228 Visa", would each be a separate Brand. 2230 3.6.5 Identifying Promotional Brands 2232 There are two problems which need to handled in identifying 2233 Promotional Brands: 2235 o how does the Merchant or their Payment Handler positively 2236 identify the promotional brand being used at the time of 2237 purchase 2239 o how does the Consumer reliably identify the correct promotional 2240 brand from the Brand List presented by the Merchant 2242 The following is a description of how this could be achieved. 2244 [Note] Please note that the approach described here is a model 2245 approach that solves the problem. Other equivalent methods 2246 may be used. 2247 [Note End] 2249 3.6.5.1 Merchant/Payment Handler Identification of Promotional Brands 2251 Correct identification that the Consumer is paying using a Promotional 2252 Brand is important since a Consumer might fraudulently claim to have a 2253 Promotional Brand that offers a reduced payment amount when in reality 2254 they do not. 2256 Two approaches seem possible: 2258 o use some feature of the Payment Instrument or the payment 2259 method to positively identify the Brand being used. For 2260 example, the SET certificate for the Brand could be used, if 2261 one is available, or 2263 o use the Payment Instrument (card) number to look up information 2264 about the Payment Instrument on a Payment Instrument issuer 2265 database to determine if the Payment Instrument is a 2266 promotional brand 2268 Note that: 2270 o the first assumes that SET is available. 2272 o the second is only possible if the Merchant, or alternatively 2273 the Payment Handler, has access to card issuer information. 2275 IOTP does not provide the Merchant with Payment Instrument information 2276 (e.g. a card or account number). This is only sent as part of the 2277 encapsulated payment protocol to a Payment Handler. This means that: 2279 o the Merchant would have to assume that the Payment Instrument 2280 selected was a valid Promotional Brand, or 2282 o the Payment Handler would have to check that the Payment 2283 Instrument was for the valid Promotional Brand and fail the 2284 payment if it was not. 2286 A Payment Handler checking that a brand is a valid Promotional Brand 2287 is most likely if the Payment Handler is also the Card Issuer. 2289 3.6.5.2 Consumer Selection of Promotional Brands 2291 Two ways by which a Consumer can correctly select a Promotional Brand 2292 are: 2294 o the Consumer visually matching a logo for the Promotional Brand 2295 which has been provided to the Consumer by the Merchant, 2297 o the Consumer's IOTP aware application matching a code for the 2298 Promotional Brand which the application has registered against 2299 a similar code contained in the list of Brands offered by the 2300 Merchant. 2302 In the latter case, the code contained in the Consumer wallet must 2303 match exactly the code in the list offered by the Merchant otherwise 2304 no match will be found. Ways in which the Consumer's IOTP Aware 2305 Application could obtain such a code include: 2307 o the Consumer types the code in directly. This is error prone 2308 and not user friendly, also the consumer needs to be provided 2309 with the code. This approach is not recommended, 2311 o using some information contained in the software or other data 2312 associated with the Payment Instrument. This could be: 2313 - a SET certificate for Brands which use this payment method 2314 - a code provided by the payment software which handles the 2315 particular payment method, this could apply to, for example, 2316 GeldKarte, Mondex, CyberCash and DigiCash 2318 o the consumer making a initial "manual" link between a 2319 Promotional Brand in the list of Brands offered by the Merchant 2320 and an individual Payment Instrument, the first time the 2321 promotional brand is used. The IOTP Aware application would 2322 then "remember" the code for the Promotional Brand for use in 2323 future purchases 2325 [Note] It is not the intention of the developers of this 2326 specification to develop a prescriptive list of payment 2327 brands. It is anticipated that owners of brands will develop 2328 distinctive names for Brands which should mean that name 2329 clashes are unlikely. 2330 [Note End] 2331 3.7 Extending IOTP 2333 Baseline IOTP defines a minimum protocol which systems supporting IOTP 2334 must be able to accept. As new versions of IOTP are developed, 2335 additional types of IOTP Transactions will be defined. In addition to 2336 this, Baseline and future versions of IOTP will support user 2337 extensions to IOTP through two mechanisms: 2339 o extra XML elements, and 2341 o new values for existing IOTP codes. 2343 3.7.1 Extra XML Elements 2345 The XML element and attribute names used within IOTP constitute an 2346 [XML Namespace] as identified by the xmlns attribute on the OtpMessage 2347 element. This allows IOTP to support the inclusion of additional XML 2348 elements within IOTP messages through the use of [XML Namespaces]. 2350 Using XML Namespaces, extra XML elements may be included at any level 2351 within an IOTP message including: 2353 o new Trading Blocks 2355 o new Trading Components 2357 o new XML elements within a Trading Component. 2359 The following rules apply: 2361 o any new XML element must be declared according to the rules for 2362 [XML Namespaces] 2364 o new XML elements which are either Trading Blocks or Trading 2365 Components must contain an ID attributes with an attribute name 2366 of ID. 2368 In order to make sure that extra XML elements can be processed 2369 properly, IOTP reserves the use of a special attribute, IOTP:Critical, 2370 which takes the values True or False and may appear in extra elements 2371 added to an IOTP message. 2373 The purpose of this attribute is to allow an IOTP aware application to 2374 determine if the IOTP transaction can safely continue. Specifically: 2376 o if an extra XML element has an "IOTP:Critical" attribute with a 2377 value of "True" and an IOTP aware application does not know how 2378 to process the element and its child elements, then the IOTP 2379 transaction has a Technical Error (see section 4.1) and must 2380 fail. 2382 o if an extra XML element has an "IOTP:Critical" attribute with a 2383 value of "False" then the IOTP transaction may continue if the 2384 IOTP aware application does not know how to process it. In this 2385 case: 2386 - any extra XML elements contained within an XML element defined 2387 within the IOTP namespace, must be included with that element 2388 whenever the IOTP XML element is used or copied by IOTP 2389 - the content of the extra element must be ignored except that it 2390 must be included when it is used in the creation of a digest as 2391 part of the generation of a signature 2393 o if an extra XML element has no "IOTP:Critical" attribute then 2394 it must be treated as if it had an "IOTP:Critical" attribute 2395 with a value of "True" 2397 o if an XML element contains an "IOTP:Critical" attribute, then 2398 the value of that attribute is assumed to apply to all the 2399 child elements within that element 2401 In order to ensure that documents containing "IOTP:Critical" are 2402 valid, it is declared as part of the DTD for the extra element as: 2404 IOTP:Critical (True | False ) #TRUE 2406 3.7.2 Opaque Embedded Data 2408 If IOTP is to be extended using Opaque Embedded Data then a Packaged 2409 Content Element (see section 3.8) should be used to encapsulate the 2410 data. 2412 3.7.3 Values for IOTP Codes 2414 Codes used by IOTP are registered by [IANA] so that new values can be 2415 co-ordinated based on an IETF consensus as defined in RFC 2434. 2417 The element types, attributes names to which this procedure applies is 2418 shown in the table below together with the original values for 2419 attributes which apply. For more up-to-date information on valid 2420 values and how these relate to versions of the IOTP specification 2421 contact IANA. 2423 Element Type Attribute Attribute Values 2424 Name 2426 AuthData AuthMethod sha1 2428 signature 2430 pay:ppp where ppp may be set to any 2431 valid value for iotpbrand (see below) 2433 Brand BrandId SET:setbrand where setbrand is a brand 2434 which is accepted by the [SET] payment 2435 protocol 2437 IOTP:iotpbrand where iotpbrand may be: 2438 o GeldKarte 2439 o Mondex 2441 CurrencyAmount CurrCode TBD. Codes which apply when the 2442 CurrCodeType attribute is set to IOTP 2443 are to be defined 2445 CurrencyAmount CurrCodeType ISO4217 2447 IOTP 2449 DeliveryData DelivMethod Post 2451 Web 2453 Email 2455 PackagedContent Content PCDATA 2457 MIME 2459 MIME:mimetype (where mimetype must be 2460 the same as content-type as defined by 2461 [MIME] ) 2463 XML 2465 PayProtocol ProtocolId The values of ProtocolId are to be 2466 defined by the payment scheme/method 2467 owners. 2469 RelatedTo Relationship OtpTransaction 2470 Type 2471 Reference 2473 Status StatusType Offer 2475 Payment 2477 Delivery 2479 Authentication 2481 TradingRole TradingRole Consumer 2483 Merchant 2485 PaymentHandler 2487 DeliveryHandler 2489 DelivTo 2491 CustCare 2493 TransId OtpTransType BaselineAuthentication 2495 BaselineDeposit 2497 BaselinePurchase 2499 BaselineRefund 2501 BaselineWithdrawal 2503 BaselineValueExchange 2505 BaselineInquiry 2507 BaselinePing 2509 Attibute Content OfferResponse 2510 (within 2511 Signature PaymentResponse 2512 Component) 2513 DeliveryResponse 2514 AuthenticationRequest 2516 AuthenticationResponse 2518 PingRequest 2520 PingResponse 2522 However there is still a need for developers to experiment using new 2523 IOTP codes. For this reason, "user defined codes" may be used to 2524 identify additional values for the codes contained within this 2525 specification with the need for them to be registered with IANA. 2527 The definition of a user defined code is as follows: 2529 user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)* 2531 NameChar NameChar has the same definition as the [XML] 2532 definition of NameChar 2534 Use of domain names (see [DNS]) to make user defined codes unique is 2535 recommended although this method cannot be relied upon. 2537 3.8 Packaged Content Element 2539 The Packaged Content element supports the concept of an embedded data 2540 stream, transformed to both protect it against misinterpretation by 2541 transporting systems and to ensure XML compatibility. Examples of its 2542 use in IOTP include: 2544 o to encapsulate payment scheme messages, such as SET messages, 2546 o to encapsulate a description of an order, a payment note, or a 2547 delivery note. 2549 In general it is used to encapsulate one or more data streams. 2551 This data stream has three standardised attributes that allow for 2552 identification, decoding and interpretation of the contents. Its 2553 definition is as follows. 2555 2556 2561 Attributes: 2563 Name Optional. Distinguishes between multiple 2564 occurrences of Packaged Content Elements at the 2565 same point in IOTP. For example: 2566 2567 2568 snroasdfnas934k 2569 2570 2571 dvdsjnl5poidsdsflkjnw45 2572 2573 2575 The name attribute may be omitted, for example 2576 if there is only one Packaged Content element. 2578 Content This identifies what type of data is contained 2579 within the Content of the Packaged Content 2580 Element. The valid values for the Content 2581 attribute are as follows: 2582 o PCDATA. The content of the Packaged Content 2583 Element can be treated as PCDATA with no 2584 further processing. 2585 o MIME. The content of the Packaged Content 2586 Element is a complete MIME item. Processing 2587 should include looking for MIME headers inside 2588 the Packaged Content Element. 2589 o MIME:mimetype. The content of the Packaged 2590 Content Element is MIME content, with the 2591 following header "Content-Type: mimetype". 2592 Although it is possible to have MIME:mimetype 2593 with the Transform attribute set to NONE, it 2594 is far more likely to have Transform attribute 2595 set to BASE64. Note that if Transform is NONE 2596 is used, then the entire content must still 2597 conform to PCDATA. Some characters will need 2598 to be encoded either as the XML default 2599 entities, or as numeric character entities. 2600 o XML. The content of the Packaged Content 2601 Element can be treated as an XML document. 2602 Entities and CDATA sections, or Transform set 2603 to BASE64, must be used to ensure that the 2604 Packaged Content Element contents are 2605 legitimate PCDATA. 2607 Values of the Content attribute are controlled 2608 under the procedures defined in section 3.7.3 2609 Values for IOTP Codes which also allows user 2610 defined values to be defined. 2612 Transform This identifies the transformation that has been 2613 done to the data before it was placed in the 2614 content. Valid values are: 2615 o NONE. The PCDATA content of the Packaged 2616 Content Element is the correct representation 2617 of the data. Note that entity expansion must 2618 occur first (i.e. replacement of & and 2619 ) before the data is examined. CDATA 2620 sections may legitimately occur in a Packaged 2621 Content Element where the Transform attribute 2622 is set to NONE. 2623 o BASE64. The PCDATA content of the Packaged 2624 Content Element represents a BASE64 encoding 2625 of the actual content. 2627 Content: 2629 PCDATA This is the actual data which has been embedded. 2630 The format of the data and rules on how to 2631 decode it are contained in the Content and the 2632 Transform attributes 2634 Note that any special details, especially custom attributes, must be 2635 represented at a higher level. 2637 3.8.1 Packaging HTML 2639 The packaged content may contain HTML. In this case the following 2640 conventions are followed: 2642 o references to any documents, images or other things, such as 2643 sounds or web pages, which can affect the recipient's 2644 understanding of the data which is being packaged must refer to 2645 other Packaged Elements contained within the same parent 2646 element, e.g. an Order Description 2648 o if more than one Packaged Content element is included within a 2649 parent element in order to meet the previous requirement, then 2650 the Name attribute of the top level Packaged Content from which 2651 references to all other Packaged Elements can be determined, 2652 should have a value of Main. This means that the "Main" 2653 Packaged Content element must not be referred to from the HTML 2654 in any other Packaged Content 2656 o relative references to other documents, images, etc. from one 2657 Packaged Content element to another are realised by setting the 2658 value of the relative reference to the Name attribute of 2659 another Packaged Content element at the same level and within 2660 the same parent element 2662 o no external references that require the reference to be 2663 resolved immediately should be used. As this could make the 2664 HTML difficult or impossible to display completely 2666 o [MIME] is used to encapsulate the data inside each Packaged 2667 Element. This means that the information in the MIME header 2668 used to identify the type of data which has been encapsulated 2669 and therefore how it should be displayed. 2671 If the above conventions are not followed by, for example, including 2672 external references which must be resolved, then the recipient of the 2673 HTML should be informed. 2675 [Note] As an implementation guideline the values of the Name 2676 Attributes allocated to Packaged Content elements should 2677 make it possible to extract each Packaged Content into a 2678 directory and then display the HTML directly 2679 [Note End] 2681 3.9 Identifying Languages 2683 IOTP uses [XML] Language Identification to specify which languages are 2684 used within the content and attributes of IOTP Messages. 2686 The following principles have been used in order to determine which 2687 XML elements contain an xml:lang Attributes: 2689 o a mandatory xml:lang attribute is contained on every Trading 2690 Component which contains attributes or content which may need 2691 to be displayed or printed in a particular language 2693 o an optional xml:lang attribute is included on child elements of 2694 these Trading Components. In this case the value of xml:lang, 2695 if present, overrides the value for the Trading Component. 2697 xml:lang attributes which follow these principles are included in the 2698 Trading Components and their child XML elements defined in section 6. 2700 3.10 Secure and Insecure Net Locations 2702 IOTP contains several "Net Locations" which identify places where, 2703 typically, IOTP Messages may be sent. Net Locations come in two types: 2705 o "Secure" Net Locations which are net locations where privacy of 2706 data is secured using, for example, encryption methods such as 2707 [SSL], and 2709 o "Insecure" Net Locations where privacy of data is not assured. 2711 Where both types of net location are present, the following rules 2712 apply: 2714 o either a Secure Net Location or an Insecure Net Location or 2715 both must be present 2717 o if only one of the two Net Locations is present, then the one 2718 present must be used 2720 o if both are present, then the either may be used depending on 2721 the preference of the sender of the message. 2723 3.11 Cancelled Transactions 2725 Any Trading Role involved in an IOTP transaction may cancel that 2726 transaction at any time. 2728 3.11.1 Cancelling Transactions 2730 IOTP Transactions are cancelled by sending an IOTP message containing 2731 just a Cancel Block with an appropriate Status Component to the other 2732 Trading Role involved in the Trading Exchange. 2734 [Note] The Cancel Block can be sent asynchronously of any other 2735 IOTP Message. Specifically it can be sent either before 2736 sending or after receiving an IOTP Message from the other 2737 Trading Role 2738 [Note End] 2740 If an IOTP Transaction is cancelled during a Trading Exchange (i.e. 2741 the interval between sending a _request_ block and receiving the 2742 matching _response_ block) then the Cancel Block is sent to the same 2743 location as the next IOTP Message in the Trading Exchange would have 2744 been sent. 2746 If a Consumer cancels a transaction after a Trading Exchange has 2747 completed (i.e. the "response" block for the Trading Exchange has been 2748 received), but before the IOTP Transaction has finished then the 2749 Consumer sends a Cancel Block with an appropriate Status Component to 2750 the net location identified by the SenderNetLocn or 2751 SecureSenderNetLocn contained in the Protocol Options Component 2752 contained in the TPO Block for the transaction. This is normally the 2753 Merchant Trading Role. 2755 A Consumer should not send a Cancel Block after the IOTP Transaction. 2756 Cancelling a complete should be treated as a technical error. 2758 After cancelling the IOTP Transaction, the Consumer should go to the 2759 net location specified by the CancelNetLocn attribute contained in the 2760 Trading Role Element for the organisation that was sent the Cancel 2761 Block. 2763 A non-Consumer Trading Role should only cancel a transaction: 2765 o after a request block has been received and 2767 o before the response block has been sent 2769 If a non-Consumer Trading Role cancels a transaction at any other time 2770 it should be treated by the recipient is an error. 2772 3.11.2 Handling Cancelled Transactions 2774 If a Cancel Block is received by a Consumer at a point in the IOTP 2775 Transaction when cancellation is allowed, then the Consumer should 2776 stop the transaction. 2778 If a Cancel Block is received by a non-Consumer role, then the Trading 2779 Role should anticipate that the Consumer may go to the location 2780 specified by the CancelNetLocn attribute contained in the Trading Role 2781 Element for the Trading Role. 2783 4. IOTP Error Handling 2785 IOTP is designed as a request/response protocol where each message is 2786 composed of a number of Trading Blocks which contain a number of 2787 Trading Components. There are a several interrelated considerations in 2788 handling errors, re-transmissions, duplicates, and the like. These 2789 factors mean IOTP aware applications must manage message flows more 2790 complex than the simple request/response model. Also a wide variety of 2791 errors can occur in messages as well as at the transport level or in 2792 Trading Blocks or Components. 2794 This section describes at a high level how IOTP handles errors, 2795 retries and idempotency. It covers: 2797 o the different types of errors which can occur. This is divided 2798 into: 2799 - "technical errors" which are independent of the meaning of the 2800 IOTP Message, 2801 - "business errors" which indicate that there is a problem specific 2802 to the process (e.g. payment or delivery) which is being carried 2803 out, and 2805 o the depth of the error which indicates whether the error is at 2806 the transport, message or block/component level 2808 o how the different trading roles should handle the different 2809 types of messages which they may receive. 2811 4.1 Technical Errors 2813 Technical Errors are those which are independent of the meaning of the 2814 message. This means, they can affect any attempt at IOTP 2815 communication. Typically they are handled in a standard fashion with a 2816 limited number of standard options for the user. Specifically these 2817 are: 2819 o retrying the transmission, or 2821 o cancelling the transaction. 2823 When communications are operating sufficiently well, a technical error 2824 is indicated by an Error Component (see section 0) in an Error Block 2825 (see section 7.17) sent by the party which detected the error in an 2826 IOTP message to the party which sent the erroneous message. 2828 If communications are too poor, a message which was sent may not reach 2829 its destination. In this case a time-out might occur. 2831 The Error Codes associated with Technical Errors are recorded in Error 2832 Components 6.19) which lists all the different technical errors which 2833 can be set. 2835 4.2 Business Errors 2837 Business Errors may occur when the IOTP messages are "technically" 2838 correct. They are connected with a particular process, for example, an 2839 offer, payment, delivery or authentication, where each process has a 2840 different set of possible business errors. 2842 For example, "Insufficient funds" is a reasonable payment error but 2843 makes no sense for a delivery while "Back ordered" is a reasonable 2844 delivery error but not meaningful for a payment. Business errors are 2845 indicated in the Status Component (see section 6.14) of a "response 2846 block" of the appropriate type, for example a Payment Response Block 2847 or a Delivery Response Block. This allows whatever additional response 2848 related information is needed to accompany the error indication. 2850 Business errors must usually be presented to the user so that they can 2851 decide what to do next. For example, if the error is insufficient 2852 funds in a Brand Independent Offer (see section 8.1.2.2), the user 2853 might wish to choose a different payment instrument/account of the 2854 same brand or a different brand or payment system. Alternatively, if 2855 the IOTP based implementation allows it and it makes sense for that 2856 instrument, the user might want to put more funds into the 2857 instrument/account and try again. 2859 4.3 Error Depth 2861 The three levels at which IOTP errors can occur are the transport 2862 level, the message level, and the block level. Each is described 2863 below. 2865 4.3.1 Transport Level 2867 This level of error indicates a fundamental problem in the transport 2868 mechanism over which the IOTP communication is taking place. 2870 All transport level errors are technical errors and are indicated by 2871 either an explicit transport level error indication, such as a "No 2872 route to destination" error from TCP/IP, or by a time out where no 2873 response has been received to a request. 2875 The only reasonable automatic action when faced with transport level 2876 errors is to retry and, after some number of automatic retries, to 2877 inform the user. 2879 The explicit error indications that can be received are transport 2880 dependent and the documentation for appropriate IOTP Transport 2881 supplement should be consulted for errors and appropriate actions. 2883 Appropriate time outs to use are a function of both the transport 2884 being used and of the payment system if the request encapsulates 2885 payment information. The transport and payment system specific 2886 documentation should be consulted for time out and automatic retry 2887 parameters. Frequently there is no way to directly inform the other 2888 party of transport level errors but they should generally be logged 2889 and if automatic recovery is unsuccessful and there is a human user, 2890 the user should be informed. 2892 4.3.2 Message Level 2894 This level of error indicates a fundamental technical problem with an 2895 entire IOTP message. For example, the XML is not _Well Formed_, or the 2896 message is too large for the receiver to handle or there are errors in 2897 the Transaction Reference Block (see section 3.3) so it is not 2898 possible to figure out what transaction the message relates to. 2900 All message level errors are technical errors and are indicated by an 2901 Error Components (see section 6.19) sent to the other party. The Error 2902 Component includes a Severity attribute which indicates whether the 2903 error is a Warning and may be ignored, a TransientError which 2904 indicates that a retry may resolve the problem or a HardError in which 2905 case the transaction must fail. 2907 The Technical Errors (see section 6.19.2 Error Codes) that are Message 2908 Level errors are: 2910 o XML not well formed. The document is not well formed XML (see 2911 [XML]) 2913 o XML not valid. The document is not valid XML (see [XML]) 2915 o block level technical errors (see section 4.3.3) on the 2916 Transaction Reference Block (see section 3.3) and the Signature 2917 Block only. Checks on these blocks should only be carried out 2918 if the XML is valid 2920 Note that checks on the Signature Block includes checking, where 2921 possible, that each Signature Component is correctly calculated. If 2922 the Digital Signature Element is incorrectly calculated then the data 2923 that should have been covered by the signature can not be trusted and 2924 must be treated as erroneous. A description of how to check a 2925 signature is correctly calculated is contained in section 5.2 Checking 2926 a Signature is Correctly Calculated. 2928 4.3.3 Block Level 2930 A Block level error indicates a problem with a block or one of its 2931 components in an IOTP message (apart from Transaction Reference or 2932 Signature Blocks). The message has been transported properly, the 2933 overall message structure and the block/component(s) including the 2934 Transaction Reference and Signature Blocks are meaningful but there is 2935 some error related to one of the other blocks. 2937 Block level errors can be either: 2939 o technical errors, or 2941 o business errors 2943 Technical Errors are further divided into: 2945 o Block Level Attribute and Element Checks, and 2947 o Block and Component Consistency Checks 2949 If a technical error occurs related to a block or component, then an 2950 Error Component is returned and, unless it is merely a warning, the 2951 usual response block is suppressed. 2953 4.3.3.1 Block Level Attribute and Element Checks 2955 Block Level Attribute and Element Checks occur only within the same 2956 block. Checks which involve cross-checking against other blocks are 2957 covered by Block and Component Consistency Checks. 2959 The Block Level Attribute & Element checks are: 2961 o checking that each attribute value within each element in a 2962 block conforms to any rules contained within this IOTP 2963 specification 2965 o checking that the content of each element conforms to any rules 2966 contained within this IOTP specification 2968 o if the previous checks are OK, then checking the consistency of 2969 attribute values and element content against other attribute 2970 values or element content within any other components in the 2971 same block. 2973 4.3.3.2 Block and Component Consistency Checks 2975 Block and Component Consistency Checks consist of: 2977 o checking that the combination of blocks and/or components 2978 present in the IOTP Message are consistent with the rules 2979 contained within this IOTP specification 2981 o checking for consistency between attributes and element content 2982 within the blocks within the same IOTP message. 2984 o checking for consistency between attributes and elements in 2985 blocks in this IOTP message and blocks received in earlier IOTP 2986 messages for the same IOTP transaction 2988 4.3.3.3 Block Business Errors 2990 If a business error occurs in a process such as a Payment or a 2991 Delivery, then the appropriate type of response block is returned. The 2992 Status Component (see section 6.14) within that response block 2993 indicates the error and its severity. No Error Component or Error 2994 Block is generated for business errors. 2996 4.4 Idempotency, Processing Sequence, and Message Flow 2998 IOTP messages are actually a combination of blocks and components as 2999 described in 3.1.1 IOTP Message Structure. Especially in future 3000 extensions of IOTP, a rich variety of combinations of such blocks and 3001 components can occur. It is important that the multiple 3002 transmission/receipt of the "same" request for state changing action 3003 not result in that action occurring more than once. This is called 3004 idempotency. For example, a customer paying for an order would want to 3005 pay the full amount only once. Most network transport mechanisms have 3006 some probability of delivering a message more than once or not at all, 3007 perhaps requiring retransmission. On the other hand, a request for 3008 status can reasonably be repeated and should be processed fresh each 3009 time it is received. 3011 Correct implementation of IOTP can be modelled by a particular 3012 processing order as detailed below. Any other method that is 3013 indistinguishable in the messages sent between the parties is equally 3014 acceptable. 3016 4.4.1 Server Role Processing Sequence 3018 "Server roles" are any Trading Role which is not the Consumer role. 3019 They are "Server roles" since they typically receive a request which 3020 they must service and then produce a response. 3022 The model processing sequence for a Server role is indicated in the 3023 diagram below. 3025 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3027 ------------- 3028 | Input | 3029 | IOTP Message| 3030 ------------- 3031 | 3032 v 3033 1. Check for transport --------------> 3034 or message level errors Errors | 3035 |OK | 3036 v | 3037 11. Generate output <-------2. More Blocks <----------------- + - 3038 message No to process? | | 3039 | |Yes | | 3040 v v | | 3041 ------------- 3. Check Block OK ---------------> | | 3042 | Output | | Errors | | 3043 | IOTP Message| |Checks OK | | 3044 ------------- v | | 3045 ---------4. Type of Block ? ------- | | 3046 | | | | | | 3047 ---------Status Action Encapsulating Error | | 3048 | Request Request Block Block | | 3049 | | | | | | 3050 | v v v | | 3051 | 6a. Action 7. Process 8.Error | | 3052 | Request - encapsulated Block ? | | 3053 | received message and | | | 3054 | before?-- generate -- v | | 3055 | | | response | STOP --- | 3056 | |Yes |No OK| | | | 3057 | v v | |Errors v | 3058 | 6b. Processing 6e. Process Action | ------> 9. Gen | 3059 | of Block Request & generate-+--------->Error | 3060 | Complete ?- response block- | Errors Block & | 3061 | | | ^ | | store | 3062 | | | | | | | | 3063 | |Yes |No | Ok or | | | | 3064 | | --- | Warning | -------- | | 3065 v v v | v | | | 3066 5. Generate 6c. Retrieve 6d. Wait for 6f. Store | | | 3067 Status and resend process request & | | | 3068 Response previous completion response | | | 3069 Block Block block | | | 3070 | | | v v | 3071 ---------------------------------------------- 10. Add block-- 3072 to output 3073 message 3075 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3077 Figure 10 Server Role Processing Sequence 3079 Each of the processes in the sequence is described in more detail 3080 below. 3082 4.4.1.1 Check for Transport or Message Level Error 3084 On receipt of an IOTP request message (step 1), first check for 3085 transport or message level errors (see sections 4.3.1 and 4.3.2). 3086 These are errors which indicate that the entire message is corrupt and 3087 can not reliably be associated with any particular transaction or, if 3088 it can be associated with a transaction, the interior information in 3089 the message can not be reliably accessed. 3091 If the OtpTransId attribute in the Transaction Id Component (see 3092 section 3.3.1) can be determined, set up a response message with an 3093 appropriate Error Component. Perform local actions such as making log 3094 entries. 3096 If the value of the OtpTransId attribute is not recognised as 3097 belonging to an IOTP transaction when other Blocks in the IOTP Message 3098 indicate that it should be recognised, then report the error using an 3099 Error Component with a Severity of HardError, an ErrorCode set to 3100 AttValNotRecog (attribute value not recognised), and an Error Location 3101 element (see section 6.19.3) that points to the OtpTransId attribute. 3103 No idempotency related actions are necessary. 3105 4.4.1.2 Process all the blocks 3107 If there are no message level errors, process each of the blocks 3108 within the message which has not been processed (step 2). 3110 Once all the blocks have been processed, generate a response message 3111 (step 11) and send it to the requester unless there are fatal 3112 transport level problems. As recommended for the particular transport 3113 used, a limited number of automatic response retransmission attempts 3114 may be appropriate. 3116 It may be desirable to log the complete response message at the 3117 server. Failure of the requester to receive a response may lead to a 3118 time-out and a retransmission of the request. Following the procedures 3119 above, a duplicate request message should produce a duplicate of the 3120 previous response except for changes in status and transient error 3121 conditions that have changed. 3123 4.4.1.3 Check the Block is OK 3125 Check the block is OK (see section 4.3.3). For each block level 3126 technical error found, an appropriate Error Component should be 3127 created to be included in the IOTP Message sent back to the Consumer. 3128 Note that some checking of the Transaction Reference Block and the 3129 Signature Block has occurred as part of Message Level error checking. 3131 If one or more of the Error Components contain a Severity attribute 3132 with a value of TransientError or HardError, then no response block 3133 need be generated and no further processing of the block, including 3134 idempotency related actions are necessary. 3136 4.4.1.4 Determine the Type of the Block 3138 Trading Blocks that survive the above steps and thus have no errors, 3139 or at worst have added a warning error component to the response, can 3140 receive further processing. The nature of the processing depends (step 3141 4) on whether the block is a Status Request, Action Request, an Error 3142 Block or contains an Encapsulated Message. 3144 4.4.1.5 Status Request Blocks 3146 Status Request Blocks (step 5) are either: 3148 o Inquiry Request Trading Block (see section 7.12), or 3150 o Ping Request Block (see section 7.14). 3152 These status requests do not change state and are processed fresh to 3153 get the current status. The appropriate response block should be added 3154 to the IOTP message being composed. 3156 No idempotency actions are required. 3158 4.4.1.6 Action Request Blocks 3160 Blocks which request an action and change state need to be subject to 3161 idempotency duplicate filtering by checking to see if the same block 3162 for the same transaction has been previously stored (step 6a) at the 3163 server as described later. 3165 If the Block has been received previously then: 3167 o if processing of the previously stored block is complete (step 3168 6b) then the same IOTP Block as previously produced must be 3169 included for resending to the Consumer (step 6c). 3171 o if processing is not complete, wait until the processing is 3172 complete (step 6d) before sending the response. 3174 If the block has not been received before, the action request is 3175 processed normally (step 6e) producing a response block that is added 3176 to the response message. This might or might not indicate a business 3177 error. 3179 If there is a transient error indicated by an Error Component that 3180 contains a Severity attribute set to TransientError, then apart from 3181 sending the Error Block, no further actions should be taken so the 3182 action can be retried. 3184 If there is no Transient Error, then the transaction id, the request 3185 block, and the response block must be stored (step 6f) so they can be 3186 found as described above (step 6a) should a duplicate IOTP action 3187 request block be received for this transaction in the future. 3189 [Note] Most business errors should be labelled as a TransientError 3190 as there is usually some possibility they will be corrected 3191 over time or some user action exists that can fix them. 3192 Requesters are expected to understand business errors and 3193 the appropriate time scale for user actions for retrying. 3194 [Note End] 3196 4.4.1.7 Encapsulating Blocks 3198 Blocks which encapsulate a payment protocol (step 7) pass along the 3199 enclosed information to the payment system involved. 3201 IOTP does not know the meaning of the enclosed information. It is thus 3202 up to the payment system involved to handle error detection and 3203 idempotency. Payment systems adapted for the Internet include 3204 idempotency handling because duplicates are always possible. Should a 3205 payment system have no idempotency handling, a layer between IOTP and 3206 the payment system must be added to take care of this. 3208 No IOTP level idempotency actions are required for encapsulating 3209 blocks. The payment system must return material to be encapsulated in 3210 the IOTP response message along with indications as to whether the 3211 exchange will continue or this is the final response and an indication 3212 whether an error occurred. If a payment protocol error has occurred, 3213 an Error Component is added to the response block. 3215 4.4.1.8 Error Block Received 3217 An error block (step 8) should not occur in a request block and should 3218 be treated as an unexpected element with a Severity of HardError. 3220 Error Blocks are sent by Consumers to potentially two locations: 3222 o the _request_ location, i.e. the location from which they 3223 received the IOTP message that contained the error, and 3225 o optionally, the ErrorLogNetLocn which may be a separate 3226 location maintained for the purpose of logging errors 3228 The ErrorLogNetLocn block may be the same location as the _request_ 3229 location. In this case, the error block must not considered as a fatal 3230 error. 3232 In order to avoid loops, no Error Block should be sent to the Consumer 3233 in response to an IOTP Message received from a Consumer where the IOTP 3234 message contains an Error Block with a severity of HardError. 3236 4.4.1.9 Generate Error Block 3238 If any of the previous steps resulted in an error being detected and 3239 an Error Component being created then generate an Error Block (step 9) 3240 containing the Error Components that describe the error(s). 3242 Unless the error is a "Transient Error", the Error Component(s) and 3243 the request block which caused the Error Components to be generated 3244 should be stored so that it can be reused if the action request is 3245 received again (step 6a). 3247 "Transient Errors" are not stored so that if the original Response 3248 Block is received again, then it can be processed as if it had never 3249 been received before. 3251 4.4.1.10 Add Block to Output Message 3253 Any Blocks which have been created as a result of processing the block 3254 received are added to the output message. 3256 4.4.2 Client Role Processing Sequence 3258 The "Client role" in IOTP is the Consumer Trading Role. 3260 [Note] A company or organisation that is a Merchant, for example, 3261 may take on the Trading Role of a Consumer when making a 3262 purchase or downloading or withdrawing electronic cash. 3263 [Note End] 3264 The model processing sequence for a Client role is indicted in the 3265 diagram below. 3267 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3269 ------------- 3270 | Input | 3271 | IOTP Message| 3272 ------------- 3273 | 3274 v 3275 1. Check for transport --> 3276 or message level errors |Errors 3277 |OK | 3278 v | 3279 11.Blocks to be sent?<---------2. More Blocks <-- ------------------ 3280 | |No No to process? | ^ 3281 Yes| v |Yes | | 3282 v STOP v | | 3283 12. Generate 3. Check Block OK - -->| | 3284 output message | |Errors | 3285 | |Checks OK | | 3286 v v | | 3287 ------------- ------ 4. Type of Block ? -----| | 3288 | Output | | | | | | | 3289 | IOTP Message| | ---- | | | | 3290 ------------- | | | | | | 3291 ------------ | | | | | 3292 | -- | | | | 3293 v v v v | | 3294 Status Action Encapsulating Error | | 3295 Request Response Block Block | | 3296 | | | | | | 3297 | v v v | | 3298 | 6a. Action 7. Process 8a.Error Block---- > Transient | 3299 | Response encapsulated severity ? | Error | 3300 | received message |Hard Error | (retry) | 3301 | before ? | | | | | | 3302 | Yes| |No Ok| | v | WAIT | 3303 | (Ig-| | | | STOP | | | 3304 | nore|) v | | v v | 3305 | | 6b. Process | -------> 9. Generate 8b. | 3306 | | Action | Errors Error Block Retrieve | 3307 | | Response --+----------> & store and resend | 3308 | | Block | Errors | previous | 3309 | | |Ok | | Block(s) | 3310 | | v v | | | 3311 | | 6c. New | | | 3312 | | request | | | 3313 | | required ? | | | 3314 | | No| |Yes 6d. Generate | | | 3315 | | | ---- > Request | | | 3316 | | | Block & Store v v | 3317 v | | | 10. Add Block to | 3318 ----------+-------+------------------------> output message | 3319 v v | 3320 ---------------------------------------------------> 3322 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3324 Figure 11 Client Role Processing Sequence 3326 Each of the processes in the sequence is described in more detail below. 3328 4.4.2.1 Check for Transport or Message Level Error 3330 On receipt of an IOTP response message (step 1), first check for 3331 transport or message level errors (see sections 4.3.1 and 4.3.2). 3332 These are errors which indicate that the entire message is corrupt and 3333 can not reliably be associated with any particular transaction or, if 3334 it can be associated with a transaction, the interior information in 3335 the message can not be reliably accessed. Set up an error indication 3336 message with an Error Component indicating the error. 3338 If the value of the OtpTransId attribute is not recognised as 3339 belonging to an IOTP transaction when other Blocks in the IOTP Message 3340 indicate that it should be recognised, then report the error using an 3341 Error Component with a Severity of HardError, an ErrorCode set to 3342 AttValNotRecog (attribute value not recognised), and an Error Location 3343 element (see section 6.19.3) that points to the OtpTransId attribute. 3345 On failure to receive an expected response message, the time out 3346 strategy indicated in the documentation for the transport method being 3347 used should be followed. This may include some number of automatic re- 3348 transmissions of the request. If a user is present, they may be 3349 offered options of continuing to retransmit the request or of 3350 cancelling the transaction. 3352 4.4.2.2 Process all the blocks 3354 If there are no transport or message level errors, process each of the 3355 blocks within the message which has not been processed (step 2). 3357 Once all the blocks have been processed, check to see if there are any 3358 blocks to be sent (step 11). There may be no blocks to send if the 3359 last response message received was the last message of the 3360 transaction. 3362 If blocks are to be sent then generate a request message (step 12) and 3363 send it to the server. It may be desirable to log the complete request 3364 message at the client. Failure of the server to receive a response may 3365 lead to a time-out and a retransmission of the request. 3367 4.4.2.3 Check the Block is OK 3369 If there are no message level errors process each of the blocks within 3370 the message (step 2). 3372 Check the block is OK (see section 4.3.3). For each block level error 3373 found, an appropriate Error Component should be created to be included 3374 in an Error Component sent back to the Server. 3376 If one or more of the Error Components contain a Severity attribute 3377 with a value of TransientError or HardError, no further processing of 3378 the block should occur and it is likely that this will result in 3379 termination of the transaction. 3381 4.4.2.4 Determine the Type of the Block 3383 Trading Blocks that survive the above steps and thus have no errors, 3384 or at worst have added a warning error component to the error 3385 indication message, can receive further processing. The nature of the 3386 processing depends (step 4) on whether the block is a Status Response, 3387 Action Response, an Error Block or contains an Encapsulated Message. 3389 4.4.2.5 Status Response Blocks 3391 Status Response Blocks (step 4) are either: 3393 o Inquiry Response Trading Blocks (see section 7.13), or 3395 o Ping Response Blocks (see section 7.15) 3397 In general, such blocks should be considered a status update. The best 3398 action to take at the requester may depend on whether this is in 3399 response to a user originated or automatic status request, whether a 3400 status display that could be updated is being presented to the user, 3401 and whether the status response block shows a change in status from a 3402 previous response block for the same type of status. Thus client 3403 detection of duplication in successive status response blocks may be 3404 useful. 3406 4.4.2.6 Action Response Blocks 3408 Check to determine if the Block has been received previously (step 3409 6a). If it has then it should be ignored. 3411 These indicate an action taken at the server in response to an action 3412 request block or a business error. If the response indicates success 3413 the block should be processed (step 6b) and, if required by the 3414 transaction (step 6c), another Action Request Block generated and 3415 stored (step 6d). 3417 The Response Block should always be stored with the transaction id 3418 until the transaction is terminated. If the Response Block indicates a 3419 transient business error, appropriate manually chosen or automatic 3420 steps to fix the problem or cancel the transaction should be provided. 3422 4.4.2.7 Encapsulating Blocks 3424 Blocks which encapsulate a payment protocol (step 7) pass along the 3425 enclosed information to the payment system involved. 3427 IOTP does not know the meaning of the enclosed information. It is up 3428 to the payment system involved to handle error detection and 3429 idempotency. Payment systems adapted for the Internet include 3430 idempotency handling because duplicates are always possible. Should a 3431 payment system have no idempotency handling, a layer between IOTP and 3432 the payment system must be added to take care of this. 3434 No IOTP level idempotency actions are required for encapsulating 3435 blocks. The payment system must return an indication of whether an 3436 error occurred. In addition, for a continuing exchange, it must return 3437 material to be encapsulated in the next IOTP request/exchange (step 3438 6d). If the response was a final response for that payment exchange 3439 and there was an error, the payment system may optionally return 3440 material to be encapsulated in the error indication. 3442 4.4.2.8 Error Block 3444 An error block in a response (step 8a) indicates some problem was 3445 detected by the server. If all of the error components are warnings, 3446 they may be optionally logged and/or presented to the user. 3448 Transient errors may be used to provide a manual or automatic 3449 resending (step 8b) of a block previously stored or alternatively may 3450 result in transaction cancellation. Hard errors will always terminate 3451 the transaction, unless they are in optional blocks, with appropriate 3452 indication to he user. 3454 4.4.2.9 Generate Error Block 3456 If an error indication message was created above, try to send it to 3457 the unless all of the error components are of the warning severity in 3458 which case attempted transmission to the server is optional. 3460 The net locations consumers send Error Blocks to are: 3462 o the net location which sent them the IOTP Message which was in 3463 error, this is either: 3464 - the location specified by the SenderNetLocn or SecureSenderNetLocn 3465 attribute of the Protocol Options Component if the problem was 3466 contained in the TPO Block or the Offer Response Block 3467 - the location to which the Payment Request Block was sent if the 3468 problem is in either a Payment Exchange or a Payment Response 3469 Block, or 3470 - the location to which the Delivery request Block if the problems 3471 in a Delivery Response Block, and 3473 o if present, the server identified by the ErrorLogNetLocn 3474 attribute of the Trading Role element identified by the 3475 SenderTradingRoleRef the Message Id Component. 3477 4.4.2.10 Add Block to Output Message 3479 Any Blocks which have been created as a result of processing the block 3480 received are added to the output message. 3482 5. Security Considerations 3484 This section considers the security associated with IOTP. It covers: 3486 o an overview of how IOTP uses digital signatures 3488 o how to check a signature is correctly calculated 3490 o how Payment Handlers and Delivery Handlers check they can carry 3491 out payments or deliveries on behalf of a Merchant. 3493 o how IOTP handles data integrity and privacy 3495 5.1 Digital Signatures and IOTP 3497 In general, signatures when used with IOTP: 3499 o are always treated as a IOTP Components (see section 6) 3501 o contain digests of one or more IOTP Components or Trading 3502 Blocks, possibly including other Signature Components, in any 3503 IOTP message within the same IOTP Transaction 3505 o identify: 3506 - which Organisation signed (originated) the signature, and 3507 - which Organisation(s) should be the receive the signature in order 3508 to check that the Action the Organisation should take can occur. 3510 The way in which Signatures Components digest one or more elements is 3511 illustrated in the figure below. 3513 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3515 IOTP MESSAGE SIGNATURE COMPONENT 3517 IOTP MESSAGE Signature Id = P1.3 3518 |-Trans Ref Block digest TransRefBlk |-Manifest 3519 | | ID=P1.1-----------------------------|->|-Digest of P1.1-- 3520 | |-Trans Id Comp digest TransIdComp | | | 3521 | | ID = M1.2----------------------------|->|-Digest of M1.2--| 3522 | |-Msg Id Comp. digest Signature | | | 3523 | | ID = P1 -------------------|->|-Digest of M1.5--| 3524 | | digest element | | | 3525 |-IOTPSignatures Block | -----------------|->|-Digest of M1.7--| 3526 | | ID=P1.2 | | digest element | | | 3527 | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| 3528 | |-Signature ID=M1.5---- | | | | 3529 | |-Signature ID=P1.4 | | Points to |-RecipientInfo* | 3530 | |-Certificate ID=M1.6<---|-|---------------|---CertRef=M1.6 | 3531 | | | | Certs to use | SignatureValueRef| 3532 | | | | | Points|to Value El| 3533 | | | | | v | 3534 |-Trading Block. ID=P1.5 | | -Value* ID=P1.4: | 3535 | |-Comp. ID=M1.7---------- | JtvwpMdmSfMbhK<--| 3536 | | | r1Ln3vovbMQttbBI | 3537 | |-Comp. ID=P1.6 | J8pxLjoSRfe1o6k| 3538 | | | OGG7nTFzTi+/0<- 3539 | |-Comp. ID=C1.4------------ 3540 | |-Comp. ID=C1.5 Digital signature of- 3541 SignedData element 3542 using certificate 3543 identified by CertRef 3545 Elements that are digested can be in any IOTP Message 3546 within the same IOTP Transaction 3547 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3549 Figure 12 Signature Digests 3551 [Note] The classic example of one signature signing another in 3552 IOTP, is when an Offer is first signed by a Merchant 3553 creating an "Offer Response" signature, which is then later 3554 signed by a Payment Handler together with a record of the 3555 payment creating a "Payment Receipt" signature. In this way, 3556 the payment in an IOTP Transaction is bound to the 3557 Merchant's offer. 3559 [Note End] 3561 Note that one Manifest may be associated with multiple signature 3562 "Value" elements where each Value element contains a digital signature 3563 over the same manifest, perhaps using the same (or different) 3564 signature algorithm but using a different certificate 3566 This may be used to allow each potential recipient of a signature to 3567 use different certificates. Specifically it will allow the Merchant to 3568 agreed different shared secrets with their Payment Handler and 3569 Delivery Handler. 3571 The detailed definitions of a Signature component is contained in 3572 section 6.17. 3574 The remainder of this section contains: 3576 o an example of how IOTP uses signatures 3578 o how the OriginatorInfo and RecipientInfo elements within a 3579 Signature Component are used to identify the organisations 3580 associated with the signature 3582 o how signatures may use either Symmetric or Asymmetric 3583 Cryptography 3585 o Mandatory and Optional use of Signatures by IOTP, and 3587 o how IOTP uses signatures to prove actions complete successfully 3589 5.1.1 IOTP Signature Example 3591 An example of how signatures are used is illustrated in the figure 3592 below which shows how the various components and elements in a 3593 Baseline Purchase relate to one another. Refer to this example in the 3594 later description of how signatures are used to check a payment or 3595 delivery can occur (see section 5.3). 3597 [Note] A Baseline Purchase transaction has been used for 3598 illustration purposes. The usage of the elements and 3599 attributes is the same for all types of IOTP Transactions. 3600 [Note End] 3602 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3604 TPO SELECTION BLOCK TPO BLOCK SIGNATURE BLOCK 3605 (Offer Response) 3606 Brand Selection Organisation<--- Signature 3607 Component Component | Component 3608 | | | | 3609 |BrandList -Trading Role | | 3610 | Ref Element | Originator |-Originator 3611 v (Merchant) ------------|--Info 3612 Brand List Ref | 3613 >Component | 3614 | |-Protocol ------> Organisation Recipient |-Recipient 3615 | | Amount Elem | Component <------------------|--Info 3616 | | | | | Refs | 3617 | | Pa|Protocol |Action -Trading Role | 3618 | | | Ref |OrgRef Element | 3619 | | v | (Payment Handler) | 3620 | -PayProtocol-- | 3621 | Elem ->Organisation Recipient |-Recipient 3622 | | Component <-----------------|--Info 3623 | | | Refs | 3624 | | -Trading Role | 3625 | | Element | 3626 | | (Delivery Handler) -Manifest 3627 | | ^ 3628 | OFFER RESPONSE BLOCK | 3629 | | Contains digests of:-- 3630 |BrandListRef |ActionOrgRef -Trans Ref Block (not 3631 | | shown) 3632 --Payment ---Delivery -Transaction Id Component 3633 Component Component (not shown) 3634 -Org Components (Merchant, 3635 Payment Handler, 3636 Delivery Handler 3637 -Brand List Component 3638 -Order Component 3639 -Payment Component 3640 -Delivery Component 3641 -Brand Selection Component 3642 (if Brand Dependent) 3643 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3645 Figure 13 Example use of Signatures for Baseline Purchase 3647 5.1.2 OriginatorInfo and RecipientInfo Elements 3649 The OriginatorRef attribute of the OriginatorInfo element in the 3650 Signature Component contains an Element Reference (see section 3.5) 3651 that points to the Organisation Component of the Organisation which 3652 generated the Signature. In this example its the Merchant. 3654 Note that the value of the content of the Attribute element with a 3655 type attribute set to IOTPSignatureType must match the Trading Role of 3656 the Organisation which signed it. If it does not, then it is an error. 3657 Valid combinations are given in the table below. 3659 IOTP Signature Type Valid Trading Role 3661 OfferResponse Merchant 3663 PaymentResponse PaymentHandler 3665 DeliveryResponse DeliveryHandler 3667 AuthenticationRequest any role 3669 AuthenticationResponse any role 3671 PingRequest any role 3673 PingResponse any role 3675 The RecipientRef attribute of the RecipientInfo element in the 3676 Signature Component contains Element References to the Organisation 3677 Components of the Organisations that should use the signature to 3678 verify that: 3680 o they have a pre-existing relationship with the Organisation 3681 that generated the signature, 3683 o the data which is secured by the signature has not been 3684 changed, 3686 o the data has been signed correctly, and 3688 o the action they are required to undertake on behalf of the 3689 Merchant is therefore authorised. 3691 5.1.3 Symmetric and Asymmetric Cryptography 3693 The Originator and Recipient of a signature may have agreed to use 3694 cryptography which is understood only by the two organisations 3695 involved. This requires that a separate RecipientInfo and Value 3696 elements are contained within the Signature Component. This approach 3697 is more likely if symmetric cryptography is being used between the 3698 Trading Roles. 3700 Equally the same cryptography may be understood by several or all of 3701 the Trading Roles. In this case the RecpientRefs attribute of one 3702 RecipientInfo element may refer to multiple Organisation Components. 3703 This is more likely if public key/asymmetric cryptography is being 3704 used. 3706 Note that one transaction may involve use of both symmetric and 3707 asymmetric cryptography. 3709 5.1.4 Mandatory and Optional Signatures 3711 IOTP does not mandate the use of signatures. For example, if a micro 3712 payment is being made for 0.1 cents, then the cost of the cryptography 3713 required to generate the signature may be greater than the income 3714 generated from the payment. Therefore it is up to the Merchant to 3715 decide whether IOTP Messages will include signatures, and for the 3716 Consumer to decide whether carrying out a transaction without 3717 signatures is an acceptable risk. If Merchants discover that 3718 transactions without signatures are not being accepted, then they will 3719 start using signatures or accept a lower volume and value of business. 3721 Additional optional signatures, over and above the ones required by 3722 the Trading Roles may be included, for example, to identify a Customer 3723 Care Provider or so that a Merchant can sign an Offer using a 3724 certificate issued by a Certificate Authority which offers Merchant 3725 "Credentials" or some other warranty on the goods or services being 3726 offered. 3728 5.1.5 Using signatures to Prove Actions Complete Successfully 3730 Proving an action completed successfully, is achieved by signing data 3731 on Response messages. Specifically: 3733 o on the Offer Response, when a Merchant is making an Offer to 3734 the Consumer which can then be sent to either: 3736 - a Payment Handler to prove that the Merchant authorises Payment, 3737 or 3738 - a Delivery Handler to prove that Merchant authorises Delivery, 3739 provided other necessary authorisations are complete (see below) 3741 o on the Payment Response, when a Payment Handler is generating a 3742 Payment Receipt which can be sent to either: 3743 - a Delivery Handler, in a Delivery Request Block to authorise 3744 Delivery together with the Offer Response signature, or 3745 - another Payment Handler, in a second Payment Request, to authorise 3746 the second payment in a Value Exchange IOTP Transaction. 3748 This proof of an action may, in future versions of IOTP, also be used 3749 to prove after the event that the IOTP transaction occurred. For 3750 example to a Customer Care Provider. 3752 5.2 Checking a Signature is Correctly Calculated 3754 Checking a signature is correctly calculated is part of checking for 3755 Message Level Errors (see section 4.3.2). It is included here so that 3756 all signature and security related considerations are kept together. 3758 Before a Trading Role can check a signature it must identify which of 3759 the potentially multiple Signature elements should be checked. The 3760 steps involved are as follows: 3762 o check that a Signature Block is present and it contains one or 3763 more Signature Components 3765 o identify the Organisation Component which contains an OrgId 3766 attribute for the Organisation which is carrying out the 3767 signature check. If no or more than one Organisation Component 3768 is found then it is an error 3770 o use the ID attribute of the Organisation Component to find the 3771 RecipientInfo element that contains a RecipientRefs attribute 3772 that refers to that Organisation Component. Note there may be 3773 no signatures to verify 3775 o check the Signature Component that contains the identified 3776 RecipientInfo element as follows as follows: 3777 - use the SignatureValueRef, the SignatureAlgoritmRef and the 3778 SignatureCertRef attributes to identify: respectively, the Value 3779 element that contains the signature to be checked, the Algorithm 3780 element that describes the signature algorithm to be used to 3781 verify the Signature and the Certificate to be used by the 3782 signature algorithm, then 3783 - check that the Value Element correctly signs the Manifest Element 3784 - check that the Digest Elements in the Manifest Element are 3785 correctly calculated where Components or Blocks referenced by the 3786 Digest have been received by the organisation checking the 3787 signature 3789 5.3 Checking a Payment or Delivery can occur 3791 This section describes the processes required for a Payment Handler or 3792 Delivery Handler to check that a payment or delivery can occur. This 3793 may include checking signatures if this is specified by the Merchant. 3795 In outline the steps are: 3797 o check that the Payment Request or Delivery Request has been 3798 sent to the correct organisation 3800 o check that correct IOTP components are present in the request, 3801 and 3803 o check that the payment or delivery is authorised 3805 For clarity and brevity the following terms or phrases are used in 3806 this section: 3808 o a "Request Block" is used to refer to either a Payment Request 3809 Block (see section 7.7) or a Delivery Request Block (see 3810 section 7.10) unless specified to the contrary 3812 o a "Response Block" is used to refer to either a Payment 3813 Response Block (see section 7.9) or a Delivery Response Block 3814 (see section 7.11) 3816 o an "Action" is used to refer to an action which occurs on 3817 receipt of a Request Block. Actions can be either a Payment or 3818 a Delivery 3820 o an "Action Organisation", is used to refer to the Payment 3821 Handler or Delivery Handler that carries out an Action 3823 o a "Signer of an Action", is used to refer to the Organisations 3824 that sign data about an Action to authorise the Action, either 3825 in whole or in part 3827 o a "Verifier of an Action", is used to refer to the 3828 Organisations that verify data to determine if they are 3829 authorised to carry out the Action 3831 o an ActionOrgRef attribute contains Element References which can 3832 be used to identify the "Action Organisation" that should carry 3833 out an Action 3835 5.3.1 Check the Action Request was sent to the Correct Organisation 3837 Checking the Action Request was sent to the correct Organisation 3838 varies depending on whether the Action is a Payment or a Delivery. 3840 5.3.1.1 Payment 3842 In outline a Payment Handler checks if it can accept or make a payment 3843 by identifying the Payment Component in the Payment Request Block it 3844 has received, then using the ID of the Payment Component to track 3845 through the Brand List and Brand Selection Components to identify the 3846 Organisation selected by the Consumer and then checking that this 3847 organisation is itself. 3849 The way data is accessed to do this is illustrated in the figure 3850 below. 3852 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3853 Start 3854 | 3855 v 3856 Brand List<--------------------------+-----------Payment 3857 Component BrandListRef | Component 3858 | | 3859 |-Brand<-------------------------- | 3860 | Element BrandRef | | 3861 | | Brand Selection 3862 | |Protocol Component 3863 | | AmountRefs | | 3864 | v Protocol | | 3865 |-Protocol Amount<---------------- | 3866 | Element---------- AmountRef | 3867 | | | | 3868 | |Currency |Pay | 3869 | | AmountRefs |Protocol | 3870 | v |Ref | 3871 |-Currency Amount | | 3872 | Element<---------|---------------- 3873 | | 3874 -PayProtocol<----- 3875 Element---------------------->Organisation 3876 Action Component 3877 OrgRef | 3878 -Trading Role 3879 Element 3880 (Payment Handler) 3882 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3883 Figure 14 Checking a Payment Handler can carry out a Payment 3885 Figure 14 Checking a Payment Handler can carry out a Payment 3887 The following describes the steps involved and the checks which need 3888 to be made: 3890 1) Identify the Payment Component (see section 6.8) in the Payment 3891 Request Block that was received. 3893 2) Identify the Brand List and Brand Selection Components for the 3894 Payment Component. This involves: 3896 a) identifying the Brand List Component (see section 6.6) where 3897 the value of its ID attribute matches the BrandListRef 3898 attribute of the Payment Component. If no or more than one 3899 Brand List Component is found there is an error. 3901 b) identifying the Brand Selection Component (see section 6.7) 3902 where the value of its BrandListRef attribute matches the 3903 BrandListRef of the Payment Component. If no or more than one 3904 matching Brand Selection Component is found there is an 3905 error. 3907 3) Identify the Brand, Protocol Amount, Pay Protocol and Currency 3908 Amount elements within the Brand List that have been selected by 3909 the Consumer as follows: 3911 a) the Brand Element (see section 6.6.1) selected is the element 3912 where the value of its Id attribute matches the value of the 3913 BrandRef attribute in the Brand Selection. If no or more than 3914 one matching Brand Element is found then there is an error. 3916 b) the Protocol Amount Element (see section 6.6.2) selected is 3917 the element where the value of its Id attribute matches the 3918 value of the ProtocolAmountRef attribute in the Brand 3919 Selection Component. If no or more than one matching Protocol 3920 Amount Element is found there is an error 3922 c) the Pay Protocol Element (see section 6.6.4) selected is the 3923 element where the value of its Id attribute matches the value 3924 of the PayProtocolRef attribute in the identified Protocol 3925 Amount Element. If no or more than one matching Pay Protocol 3926 Element is found there is an error 3928 d) the Currency Amount Element (see section 6.6.3) selected is 3929 the element where the value of its Id attribute matches the 3930 value of the CurrencyAmountRef attribute in the Brand 3931 Selection Component. If no or more than one matching Currency 3932 Amount element is found there is an error 3934 4) Check the consistency of the references in the Brand List and 3935 Brand Selection Components: 3937 a) check that an Element Reference exists in the 3938 ProtocolAmountRefs attribute of the identified Brand Element 3939 that matches the Id attribute of the identified Protocol 3940 Amount Element. If no or more than one matching Element 3941 Reference can be found there is an error 3943 b) check that the CurrencyAmountRefs attribute of the identified 3944 Protocol Amount element contains an element reference that 3945 matches the Id attribute of the identified Currency Amount 3946 element. If no or more than one matching Element Reference is 3947 found there is an error. 3949 c) check the consistency of the elements in the Brand List. 3950 Specifically, the selected Brand, Protocol Amount, Pay 3951 Protocol and Currency Amount Elements are all child elements 3952 of the identified Brand List Component. If they are not there 3953 is an error. 3955 5) Check that the Payment Handler that received the Payment Request 3956 Block is the Payment Handler selected by the Consumer. This 3957 involves: 3959 a) identifying the Organisation Component for the Payment 3960 Handler. This is the Organisation Component where its ID 3961 attribute matches the ActionOrgRef attribute in the 3962 identified Pay Protocol Element. If no or more than one 3963 matching Organisation Component is found there is an error 3965 b) checking the Organisation Component has a Trading Role 3966 Element with a Role attribute of PaymentHandler. If not there 3967 is an error 3969 c) finally, if the identified Organisation Component is not the 3970 same as the organisation that received the Payment Request 3971 Block, then there is an error. 3973 5.3.1.2 Delivery 3975 The way data is accessed by a Delivery Handler in order to check that 3976 it may carry out a delivery is illustrated in the figure below. 3978 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 3979 Start 3980 | 3981 v 3982 Delivery 3983 Component 3984 | 3985 |ActionOrgRef 3986 | 3987 v 3988 Organisation 3989 Component 3990 | 3991 -Trading Role 3992 Element 3993 (Delivery Handler) 3995 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3997 Figure 15 Checking a Delivery Handler can carry out a Delivery 3999 The steps involved are as follows: 4001 1) Identify the Delivery Component in the Delivery Request Block. 4002 If there is no or more than one matching Delivery Component 4003 there is an error 4005 2) Use the ActionOrgRef attribute of the Delivery Component to 4006 identify the Organisation Component of the Delivery Handler. If 4007 there is no or more than one matching Organisation Component 4008 there is an error 4010 3) If the Organisation Component for the Delivery Handler does not 4011 have a Trading Role Element with a Role attribute of 4012 DeliveryHandler there is an error 4014 4) Finally, if the organisation that received the Delivery Request 4015 Block does not identify the Organisation Component for the 4016 Delivery Handler as itself, then there is an error. 4018 5.3.2 Check the Correct Components are present in the Request Block 4020 Check that the correct components are present in the Payment Request 4021 Block (see section 7.7) or in the Delivery Request Block (see section 4022 7.10). 4024 If components are missing, there is an error. 4026 5.3.3 Check an Action is Authorised 4028 The previous steps identified the Action Organisation and that all the 4029 necessary components are present. This step checks that the Action 4030 Organisation is authorised to carry out the Action. 4032 In outline the Action Organisation identifies the Merchant, checks 4033 that it has a pre-existing agreement which allows it carry out the 4034 Action and that any constraints implied by that agreement are being 4035 followed, then, if signatures are required, it checks that they sign 4036 the correct data. 4038 The steps involved are as follows: 4040 1) Identify the Merchant. This is the Organisation Component with a 4041 Trading Role Element which has a Role attribute with a value of 4042 Merchant. If no or more than one Trading Role Element is found, 4043 there is an error 4045 2) Check the Action Organisation's agreements with the Merchant 4046 allows the Action to be carried out. To do this the Action 4047 Organisation must check that: 4049 a) the Merchant is known and a pre-existing agreement exists for 4050 the Action Organisation to be their agent for the payment or 4051 delivery 4053 b) they are allowed to take part in the type of IOTP transaction 4054 that is occurring. For example a Payment Handler may have 4055 agreed to accept payments as part of a Baseline Purchase, but 4056 not make payments as part of a Baseline Refund 4058 c) any constraints in their agreement with the Merchant are 4059 being followed, for example, whether or not an Offer Response 4060 signature is required 4062 3) Check the signatures are correct. If signatures are required 4063 then they need to be checked. This involves: 4065 a) Identifying the correct signatures to check. This involves 4066 the Action Organisation identifying the Signature Components 4067 that contain references to the Action Organisation (see 4068 5.3.1). Depending on the IOTP Transaction being carried out 4069 (see section 8) either one or two signatures may be 4070 identified 4072 b) checking that the Signature Components are correct. This 4073 involves checking that Digest elements exist within the 4074 Manifest Element that refer to the necessary Trading 4075 Components (see section 5.3.3.1). 4077 [Note] Validation that the signature is correct and that the Digest 4078 elements within the signature are correctly calculated is 4079 described in section 4 IOTP Error Handling. This is because 4080 errors in the signature or generation of digests is 4081 considered a Message Level Error and is carried out before 4082 the Request Block is processed. 4083 [Note End] 4085 5.3.3.1 Check the Signatures Digests are correct 4087 All Signature Components contained within IOTP Messages must include 4088 Digest elements that refer to: 4090 o the Transaction Id Component (see section 3.3.1) of the IOTP 4091 message that contains the Signature Component. This binds the 4092 globally unique OtpTransId to other components which make up 4093 the IOTP Transaction 4095 o the Transaction Reference Block (see section 3.3) of the first 4096 IOTP Message that contained the signature. This binds the 4097 OtpTransId with information about the IOTP Message contained 4098 inside the Message Id Component (see section 3.3.2). 4100 Check that each Signature Component contains Digest elements that 4101 refer to the correct data required. 4103 The Digest elements that need to be present depend on the Trading Role 4104 of the Organisation which generated (signed) the signature: 4106 o if the signer of the signature is a Merchant then: 4107 - Digest elements must be present for all the components in the 4108 Request Block apart from the Brand Selection Component which is 4109 optional 4111 o if the signer of the signature is a Payment Handler then Digest 4112 elements must be present for: 4113 - the Signature Component signed by the Merchant, and optionally 4114 - one or more Signature Components signed by the previous Payment 4115 Handler(s) in the Transaction. 4117 5.4 Data Integrity and Privacy 4119 The overall integrity of data in IOTP Messages is ensured by the 4120 signing of Digests of Components and Trading Blocks contained in a 4121 Signature Component (see section 6.17) in a Signature Block (see 4122 section 7.16). 4124 Privacy of information is provided by sending IOTP Messages between 4125 the various Trading Roles using a secure channel such as [SSL]. Use of 4126 a secure channel within IOTP is optional. 4128 6. Trading Components 4130 This section describes the Trading Components used within IOTP. 4131 Trading Components are the child XML elements which occur immediately 4132 below a Trading Block as illustrated in the diagram below. 4134 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 4136 IOTP MESSAGE <----------- IOTP Message - an XML Document 4137 | which is transported between the 4138 | Trading Roles 4139 |-Trans Ref Block <----- Trans Ref Block - contains 4140 | | information which describes the 4141 | | IOTP Transaction and the IOTP 4142 Message. 4143 --------> | |-Trans Id Comp. <--- Transaction Id Component - 4144 | | | uniquely identifies the IOTP 4145 | | | Transaction. The Trans Id 4146 | | | Components are the same across 4147 | | | all IOTP messages that comprise 4148 | | | a single IOTP transaction. 4149 | | |-Msg Id Comp. <----- Message Id Component - 4150 | | identifies and describes an IOTP 4151 | | Message within an IOTP 4152 | | Transaction 4153 | |-Signature Block <----- Signature Block (optional) - 4154 | | | contains one or more Signature 4155 | | | Components and their associated 4156 | | | Certificates 4157 | ---> | |-Signature Comp. <-- Signature Component - contains 4158 | | | | digital signatures. Signatures 4159 | | | | may sign digests of the Trans Ref 4160 | | | | Block and any Trading Component 4161 | | | | in any IOTP Message in the same 4162 | | | | IOTP Transaction. 4163 | | | |-Certificate Comp. <- Certificate Component. Used to 4164 | | | check the signature. 4165 Trading |-Trading Block <-------- Trading Block - an XML Element 4166 Components | |-Component within an IOTP Message that 4167 | | | |-Component contains a predefined set of 4168 | ---> | |-Component Trading Components 4169 | | |-Component 4170 | | |-Component <--------- Trading Components - XML 4171 | | Elements within a Trading Block 4172 | |-Trading Block that contain a predefined set of 4173 --------> | |-Component XML elements and attributes 4174 | |-Component containing information required 4175 | |-Component to support a Trading Exchange 4176 | |-Component 4177 | |-Component 4178 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 4180 Figure 16 Trading Components 4182 The Trading Components described in this section are listed below in 4183 approximately the sequence they are likely to be used: 4185 o Protocol Options Component 4187 o Authentication Data Component 4189 o Authentication Response Component 4191 o Order Component 4193 o Organisation Component 4195 o Brand List Component 4197 o Brand Selection Component 4199 o Payment Component 4201 o Payment Scheme Component 4203 o Payment Receipt Component 4205 o Delivery Component 4207 o Delivery Note Component 4209 o Signature Component 4211 o Certificate Component 4213 o Error Component 4215 Note that the following components are listed in other sections of 4216 this specification: 4218 o Transaction Id Component (see section 3.3.1) 4220 o Message Id Component (see section 3.3.2) 4222 6.1 Protocol Options Component 4224 Protocol options are options which apply to the IOTP Transaction as a 4225 whole. Essentially it provides a short description of the entire 4226 transaction and the net location which the Consumer role should branch 4227 to if the IOTP Transaction is successful. 4229 The definition of a Protocol Options Component is as follows. 4231 4232 4240 Attributes: 4242 ID An identifier which uniquely identifies the 4243 Protocol Options Component within the IOTP 4244 Transaction. 4246 Xml:lang Defines the language used by attributes or 4247 child elements within this component, unless 4248 overridden by an xml:lang attribute on a child 4249 element. See section 3.9 Identifying Languages. 4251 ShortDesc This contains a short description of the IOTP 4252 Transaction in the language defined by 4253 xml:lang. Its purpose is to provide an 4254 explanation of what type of IOTP Transaction is 4255 being conducted by the parties involved. 4257 It is used to facilitate selecting an 4258 individual transaction from a list of similar 4259 transactions, for example from a database of 4260 IOTP transactions which has been stored by a 4261 Consumer, Merchant, etc. 4263 SenderNetLocn This contains the non secured net location of 4264 the sender of the TPO Block in which the 4265 Protocol Options Component is contained. 4267 It is the net location to which the recipient 4268 of the TPO block should send a TPO Selection 4269 Block if required. 4271 The content of this attribute is dependent on 4272 the Transport Mechanism see the Transport 4273 Mechanism Supplement. 4275 SecureSenderNetLocn This contains the secured net location of the 4276 sender of the TPO Block in which the Protocol 4277 Options Component is contained. 4279 The content of this attribute is dependent on 4280 the Transport Mechanism see the Transport 4281 Mechanism Supplement. 4283 SuccessNetLocn This contains the net location that the should 4284 be displayed after the IOTP Transaction has 4285 successfully completed. 4287 The content of this attribute is dependent on 4288 the Transport Mechanism see the Transport 4289 Mechanism Supplement. 4291 Either SenderNetLocn, SecureSenderNetLocn or both must be present. 4293 6.2 Authentication Data Component 4295 This Trading Component contains data about how an Authentication 4296 within the IOTP Transaction will occur. Its definition is as follows. 4298 4299 4306 Attributes: 4308 ID An identifier which uniquely identifies the 4309 Authentication Data Component within the IOTP 4310 Transaction. 4312 AuthenticationId An identifier specified by the Authenticator 4313 which, if returned by the Organisation that 4314 receives the Authentication Request, will enable 4315 the Authenticator to identify which 4316 Authentication is being referred to. 4318 AlgorithmRefs This contains a list of the Algorithm Elements 4319 contained within the Auth Data Component from 4320 which the recipient of the AuthData Component 4321 must choose one to use to generate the 4322 Authentication Response (see section 6.3). Note 4323 there only one Algorithm may be present. 4325 TradingRoleList If present, contains a list of the Trading Roles 4326 (see the TradingRole attribute of the Trading 4327 Role Element - section 6.5.2) for which the 4328 Authenticator is requesting the Authenticatee 4329 provides Organisation Components in the 4330 Authentication Response. 4332 For example a Merchant could request that a 4333 Consumer provides Organisation Components for 4334 the Consumer and DelivTo Trading Roles. 4336 ContentSoftwareId This contains information which identifies the 4337 software which generated the content of the 4338 element. Its purpose is to help resolve 4339 interoperability problems that might occur as a 4340 result of incompatibilities between messages 4341 produced by different software. It is a single 4342 text string in the language defined by xml:lang. 4343 It must contain, as a minimum: 4344 o the name of the software manufacturer 4345 o the name of the software 4346 o the version of the software, and 4347 o the build of the software 4349 It is recommended that this attribute is 4350 included if the software which generated the 4351 content cannot be identified from the SoftwareId 4352 attribute on the Message Id Component (see 4353 section 3.3.2) 4355 Content: 4357 PackagedContent This contains the challenge data as one or more 4358 Packaged Content (see section 3.8) that is to be 4359 responded to using the method indicated by 4360 AuthMethod. 4362 Algorithm This contains information which describes an 4363 Algorithm (see 6.17 Signature Components) that 4364 may be used to generate the Authentication 4365 Response. 4367 6.3 Authentication Response Component 4369 This Authentication Response Component contains the results of an 4370 authentication. It uses one of the Algorithms selected contained in 4371 the AuthData Component (see section 6.2). Depending on the Algorithm 4372 selected, the results of the applying the algorithm will either be 4373 contained in a Signature Component that signs the Authentication 4374 Response and other data, or in the Packaged Content element within the 4375 Authentication Response Component. Its definition is as follows. 4377 4378 4383 Attributes: 4385 ID An identifier which uniquely identifies the 4386 Authentication Response Component within the 4387 IOTP Transaction. 4389 SelectedAlgorithmRef An Element Reference that identifies the 4390 Algorithm used in generating the 4391 Authentication Response. It must be one of the 4392 Element References contained within the 4393 AlgorithmRefs attribute of the Authentication 4394 Data Component (see section 6.2) 4396 ContentSoftwareId This contains information which identifies the 4397 software which generated the content of the 4398 element. Its purpose is to help resolve 4399 interoperability problems that might occur as 4400 a result of incompatibilities between messages 4401 produced by different software. It is a single 4402 text string in the language defined by 4403 xml:lang. It must contain, as a minimum: 4404 o the name of the software manufacturer 4405 o the name of the software 4406 o the version of the software, and 4407 o the build of the software 4408 It is recommended that this attribute is 4409 included if the software which generated the 4410 content cannot be identified from the 4411 SoftwareId attribute on the Message Id 4412 Component (see section 3.3.2) 4414 Content: 4416 PackagedContent This may contain the response generated as a 4417 result of applying the Algorithm selected from 4418 the Authentication Data Component see section 4419 6.2. 4421 For example, for a payment specific scheme, it 4422 may contain scheme-specific data. Refer to the 4423 scheme-specific supplemental documentation. 4425 6.4 Order Component 4427 An Order Component contains information about an order. Its definition 4428 is as follows. 4430 4431 4441 Attributes: 4443 ID An identifier which uniquely identifies the 4444 Order Component within the IOTP Transaction. 4446 xml:lang Defines the language used by attributes or child 4447 elements within this component, unless 4448 overridden by an xml:lang attribute on a child 4449 element. See section 3.9 Identifying Languages. 4451 OrderIdentifier This is a code, reference number or other 4452 identifier which the creator of the Order may 4453 use to identify the order. It must be unique 4454 within an IOTP Transaction. If it is used in 4455 this way, then it may remove the need to specify 4456 any content for the Order element as the 4457 reference can be used to look up the necessary 4458 information in a database. 4460 ShortDesc A short description of the order in the language 4461 defined by xml:lang. It is used to facilitate 4462 selecting an individual order from a list of 4463 orders, for example from a database of orders 4464 which has been stored by a Consumer, Merchant, 4465 etc. 4467 OkFrom The date and time in [UTC] format after which 4468 the offer made by the Merchant lapses. 4470 OkTo The date and time in [UTC] format before which a 4471 Value Acquirer may accept the offer made by the 4472 Merchant is not valid. 4474 ApplicableLaw A phrase in the language defined by xml:lang 4475 which describes the state or country of 4476 jurisdiction which will apply in resolving 4477 problems or disputes. 4479 ContentSoftwareId This contains information which identifies the 4480 software which generated the content of the 4481 element. Its purpose is to help resolve 4482 interoperability problems that might occur as a 4483 result of incompatibilities between messages 4484 produced by different software. It is a single 4485 text string in the language defined by xml:lang. 4486 It must contain, as a minimum: 4487 o the name of the software manufacturer 4488 o the name of the software 4489 o the version of the software, and 4490 o the build of the software 4492 It is recommended that this attribute is 4493 included if the software which generated the 4494 content cannot be identified from the SoftwareId 4495 attribute on the Message Id Component (see 4496 section 3.3.2) 4498 Content: 4500 PackagedContent An optional description of the order information 4501 as one or more Packaged Contents (see section 4502 3.8). 4504 6.4.1 Order Description Content 4506 The Packaged Content element will normally be required, however it may 4507 be omitted where sufficient information about the purchase can be 4508 provided in the ShortDesc attribute. If the full Order Description 4509 requires it several Packaged Content elements may be used. 4511 Although the amount and currency are likely to appear in the Packaged 4512 Content of the Order Description it is the amount and currency 4513 contained in the payment related trading components (Brand List, Brand 4514 Selection and Payment) that is authoritative. This means it is 4515 important that the amount actually being paid (as contained in the 4516 payment related trading components) is prominently displayed to the 4517 Consumer. 4519 For interoperability, implementations must support Plain Text and HTML 4520 as a minimum so that it can be easily displayed. 4522 6.4.2 OkFrom and OkTo Timestamps 4524 Note that: 4526 o the OkFrom date may be later than the OkFrom date on the 4527 Payment Component (see section 6.8) associated with this order, 4528 and 4530 o similarly, the OkTo date may be earlier that the OkTo date on 4531 the Payment Component (see section 6.8). 4533 [Note] Disclaimer. The following information provided in this note 4534 does not represent formal advice of the Open Trading 4535 Protocol Consortium, any of its members or the authors of 4536 this specification. Readers of this specification must form 4537 their own views and seek their own legal counsel on the 4538 usefulness and applicability of this information. 4540 The merchant in the context of Internet commerce with 4541 anonymous consumers initially frames the terms of the offer 4542 on the web page, and in order to obtain the good or service, 4543 the consumer must accept them. 4545 If there is to be a time-limited offer, it recommended that 4546 merchants communicate this to the consumer and state in the 4547 order description in a manner which is clear to the consumer 4548 that: 4550 o the offer is time limited 4552 o the OkFrom and OkTo timestamps specify the validity of the 4553 offer 4555 o the clock, e.g. the merchant's clock, that will be used to 4556 determine the validity of the offer 4557 [Note End] 4559 6.5 Organisation Component 4561 The Organisation Component provides information about an individual or 4562 an organisation. This can be used for a variety of purposes. For 4563 example: 4565 o to describe the merchant who is selling the goods, 4567 o to identify who made a purchase, 4569 o to identify who will take delivery of goods, 4571 o to provide a customer care contact, 4573 o to describe who will be the Payment Handler. 4575 Note that the Organisation Components which must be present in an OTP 4576 Message are dependent on the particular transaction being carried out. 4577 Refer to section 8. Internet Open Trading Protocol Transactions, for 4578 more details. 4580 Its definition is as follows. 4582 4584 4593 Attributes: 4595 ID An identifier which uniquely identifies the 4596 Organisation Component within the IOTP 4597 Transaction. 4599 xml:lang Defines the language used by attributes or child 4600 elements within this component, unless 4601 overridden by an xml:lang attribute on a child 4602 element. See section 3.9 Identifying Languages. 4604 OrgId A code which identifies the organisation 4605 described by the Organisation Component. See 4606 6.5.1.1 Organisation IDs, below. 4608 OtpMsgIdPrefix Contains the prefix which must be used for all 4609 IOTP Messages sent by the Organisation in this 4610 IOTP Transaction. The values to be used are 4611 defined in 3.4.1 IOTP Message ID Attribute 4612 Definition. 4614 LegalName For organisations which are companies this is 4615 their legal name in the language defined by 4616 xml:lang. It is required for Organisations who 4617 have a Trading Role other than Consumer or 4618 DeliverTo. 4620 ShortDesc A short description of the organisation in the 4621 language defined by xml:lang. It is typically 4622 the name by which the organisation is commonly 4623 known. For example, if the legal name was "Blue 4624 Meadows Financial Services Inc.". Then its short 4625 name would likely be "Blue Meadows". 4627 It is used to facilitate selecting an individual 4628 organisation from a list of organisations, for 4629 example from a database of organisations 4630 involved in IOTP Transactions which has been 4631 stored by a consumer. 4633 LogoNetLocn The net location which can be used to download 4634 the logo for the organisation. 4636 See section 9 Retrieving Logos. 4638 The content of this attribute must conform to 4639 [RFC1738]. 4641 Content: 4643 TradingRole See 6.5.2 Trading Role Element below. 4645 ContactInfo See 6.5.3 Contact Information Element below. 4647 PersonName See 6.5.4 Person Name below. 4649 PostalAddress See 6.5.5 Postal Address below. 4651 6.5.1.1 Organisation IDs 4653 Organisation IDs are used by one IOTP Trading Role to identify 4654 another. In order to avoid confusion, this means that these IDs must 4655 be globally unique. 4657 In principle this is achieved in the following way: 4659 o the Organisation Id for all trading roles, apart from the 4660 Consumer Trading Role, uses a domain name as their globally 4661 unique identifier, 4663 o the Organisation Id for a Consumer Trading Role is allocated by 4664 one of the other Trading Roles in an IOTP Transaction and is 4665 made unique by concatenating it with that other roles' 4666 Organisation Id, 4668 o once a Consumer is allocated an Organisation Id within an IOTP 4669 Transaction the same Organisation Id is used by all the other 4670 trading roles in that IOTP transaction to identify that 4671 Consumer. 4673 Specifically, the content of the Organisation ID is defined as 4674 follows: 4676 OrgId ::= NonConsumerOrgId | ConsumerOrgId 4677 NonConsumerOrgId ::= DomainName 4678 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" 4679 NonConsumerOrgId 4680 ConsumerOrgIdPrefix ::= "Consumer:" 4682 ConsumerOrgId If the Organisation ID for a Consumer consists 4683 of: 4684 o a standard prefix is to identify that the 4685 Organisation Id is for a consumer, followed by 4686 o one or more characters which conform to the 4687 definition of an XML "namechar". See [XML] 4688 specifications, followed by 4689 o the NonConsumerOrgId for the Organisation 4690 which allocated the ConsumerOrgId. It is 4691 normally the Merchant role. 4693 Use of upper and lower case is significant. 4695 NonConsumerOrgId If the Role is not Consumer then this contains 4696 the Canonical Name for the non-consumer 4697 organisation being described by the Organisation 4698 Component. See [DNS]. 4700 Note that a NonConsumerOrgId may not start with 4701 the ConsumerOrgIdPrefix. 4703 Use of upper and lower case is not significant. 4705 Examples of Organisation Ids follow: 4707 o newjerseybooks.com - a merchant organisation id 4709 o westernbank.co.uk - a payment handler organisation id 4711 o consumer:1000247ABH/newjerseybooks.com - a consumer 4712 organisation id allocated by a merchant 4714 6.5.2 Trading Role Element 4716 This identifies the Trading Role of an individual or organisation in 4717 the IOTP Transaction. Note, an organisation may have more than one 4718 Trading Role and several roles may be present in one organisation 4719 element. Its definition is as follows: 4721 4722 4729 Attributes: 4731 ID An identifier which uniquely identifies the 4732 Trading Role Element within the IOTP 4733 Transaction. 4735 TradingRole The trading role of the organisation. Valid 4736 values are: 4737 o Consumer. The person or organisation that is 4738 acting in the role of a consumer in the IOTP 4739 Transaction. 4740 o Merchant. The person or organisation that is 4741 acting in the role of merchant in the IOTP 4742 Transaction. 4743 o PaymentHandler. The financial institution or 4744 other organisation which is a Payment Handler 4745 for the IOTP Transaction 4746 o DeliveryHandler. The person or organisation 4747 that is the delivering the goods or services 4748 for the IOTP Transaction 4749 o DelivTo. The person or organisation that is 4750 receiving the delivery of goods or services in 4751 the IOTP Transaction 4752 o CustCare. The organisation and/or individual 4753 who will provide customer care for an IOTP 4754 Transaction. 4756 Values of TradingRole are controlled under the 4757 procedures defined in section 3.7.3 Values for 4758 IOTP Codes which also allows user defined values 4759 to be defined. 4761 CancelNetLocn This contains the net location of where the 4762 Consumer should go to if the Consumer cancels 4763 the transaction for some reason. It can be used 4764 by the Trading Role to provide a response which 4765 is more tailored to the circumstances of a 4766 particular transaction. 4768 This attribute: 4769 o must not be present when TradingRole is set to 4770 Consumer role, 4771 o must be present when TradingRole is set to 4772 Merchant, PaymentHandler or DeliveryHandler. 4774 The content of this attribute is dependent on 4775 the Transport Mechanism see the Transport 4776 Mechanism Supplement. 4778 ErrorNetLocn This contains the net location that should be 4779 displayed by the Consumer after the Consumer has 4780 either received or generated an Error Block 4781 containing an Error Component with the Severity 4782 attribute set to either: 4783 o HardError, 4784 o Warning but the Consumer decides to not 4785 continue with the transaction 4786 o TransientError and the transaction has 4787 subsequently timed out. 4789 See section 6.19.1 Error Processing Guidelines 4790 for more details. 4792 This attribute: 4793 o must not be present when TradingRole is set to 4794 Consumer role, 4795 o must be present when TradingRole is set to 4796 Merchant, PaymentHandler or DeliveryHandler. 4798 The content of this attribute is dependent on 4799 the Transport Mechanism see the Transport 4800 Mechanism Supplement. 4802 ErrorLogNetLocn Optional. This contains the net location that 4803 Consumers should send IOTP Messages that contain 4804 Error Blocks with an Error Component with the 4805 Severity attribute set to either: 4806 o HardError, 4807 o Warning but the Consumer decides to not 4808 continue with the transaction 4809 o TransientError and the transaction has 4810 subsequently timed out. 4812 This attribute: 4813 o must not be present when TradingRole is set to 4814 Consumer role, 4815 o must be present when TradingRole is set to 4816 Merchant, PaymentHandler or DeliveryHandler. 4818 The content of this attribute is dependent on 4819 the Transport Mechanism see the Transport 4820 Mechanism Supplement. 4822 The ErrorLogNetLocn can be used to send error 4823 messages to the software company or some other 4824 organisation responsible for fixing problems in 4825 the software which sent the incoming message. 4826 See section 6.19.1 Error Processing Guidelines 4827 for more details. 4829 6.5.3 Contact Information Element 4831 This contains information which can be used to contact an organisation 4832 or an individual. All attributes are optional however at least one 4833 item of contact information should be present. Its definition is as 4834 follows. 4836 4837 4844 Attributes: 4846 xml:lang Defines the language used by attributes within 4847 this element. See section 3.9 Identifying 4848 Languages. 4850 Tel A telephone number by which the organisation may 4851 be contacted. Note that this is a text field and 4852 no validation is carried out on it. 4854 Fax A fax number by which the organisation may be 4855 contacted. Note that this is a text field and no 4856 validation is carried out on it. 4858 Email An email address by which the organisation may 4859 be contacted. Note that this field should 4860 conform to the conventions for address 4861 specifications contained in [RFC822]. 4863 NetLocn A location on the Internet by which information 4864 about the organisation may be obtained that can 4865 be displayed using a web browser. 4867 The content of this attribute must conform to 4868 [RFC1738]. 4870 6.5.4 Person Name Element 4872 This contains the name of an individual person. All fields are 4873 optional however as a minimum either the GivenName or the FamilyName 4874 should be present. Its definition is as follows. 4876 4877 4884 Attributes: 4886 xml:lang Defines the language used by attributes within 4887 this element. See section 3.9 Identifying 4888 Languages. 4890 Title A distinctive name; personal appellation, 4891 hereditary or not, denoting or implying office 4892 (e.g. judge, mayor) or nobility (e.g. duke, 4893 duchess, earl), or used in addressing or 4894 referring to a person (e.g. Mr, Mrs, Miss) 4896 GivenName The primary or main name by which a person is 4897 known amongst and identified by their family, 4898 friends and acquaintances. Otherwise known as 4899 first name or Christian Name. 4901 Initials The first letter of the secondary names (other 4902 than the Given Name) by which a person is known 4903 amongst or identified by their family, friends 4904 and acquaintances. 4906 FamilyName The name by which family of related individuals 4907 are known. It is typically the part of an 4908 individual's name which is passed on by parents 4909 to their children. 4911 6.5.5 Postal Address Element 4913 This contains an address which can be used, for example, for the 4914 physical delivery of goods, services or letters. Its definition is as 4915 follows. 4917 4918 4928 Attributes: 4930 xml:lang Defines the language used by attributes within 4931 this element. See section 3.9 Identifying 4932 Languages. 4934 AddressLine1 The first line of a postal address. e.g. "The 4935 Meadows" 4937 AddressLine2 The second line of a postal address. e.g. "Sandy 4938 Lane" 4940 CityOrTown The city of town of the address. e.g. "Carpham" 4942 StateOrRegion The state or region within a country where the 4943 city or town is placed. e.g. "Surrey" 4945 Country The country for the address. e.g. "UK" 4947 LegalLocation This identifies whether the address is the 4948 Registered Address for the Organisation. At 4949 least one address for the Organisation must have 4950 a value set to True unless the Trading Role is 4951 either Consumer or DeliverTo. 4953 6.6 Brand List Component 4955 Brand List Components are contained within the Trading Protocol 4956 Options Block (see section 7.1) of the IOTP Transaction. They contains 4957 lists of: 4959 o payment Brands (see also section 3.6 Brands and Brand 4960 Selection), 4962 o amounts to be paid in the currencies that are accepted or 4963 offered by the Merchant, 4965 o the payment protocols which can be used to make payments with a 4966 Brand, and 4968 o the net locations of the Payment Handlers which accept payment 4969 for a payment protocol 4971 The definition of a Brand List Component is as follows. 4973 4975 4981 Attributes: 4983 ID An identifier which uniquely identifies the 4984 Brand List Component within the IOTP 4985 Transaction. 4987 xml:lang Defines the language used by attributes or child 4988 elements within this component, unless 4989 overridden by an xml:lang attribute on a child 4990 element. See section 3.9 Identifying Languages. 4992 ShortDesc A text description in the language defined by 4993 xml:Lang giving details of the purpose of the 4994 Brand List. This information must be displayed 4995 to the receiver of the Brand List in order to 4996 assist with making the selection. It is of 4997 particular benefit in allowing a Consumer to 4998 distinguish the purpose of a Brand List when an 4999 IOTP Transaction involves more than one payment. 5001 PayDirection Indicates the direction in which the payment for 5002 which a Brand is being selected is to be made. 5003 Its values may be: 5004 o Debit The sender of the Payment Request Block 5005 (e.g. the Consumer) to which this Brand List 5006 relates will make the payment to the Payment 5007 Handler, or 5008 o Credit The sender of the Payment Request Block 5009 to which this Brand List relates will receive 5010 a payment from the Payment Handler. 5012 Content: 5014 Brand This describes a Brand. The sequence of the 5015 Brand elements (see section 6.6.1) within the 5016 Brand List does not indicate any preference. It 5017 is recommended that software which processes 5018 this Brand List presents Brands in a sequence 5019 which the receiver of the Brand List prefers. 5021 ProtocolAmount This links a particular Brand to: 5022 o the currencies and amounts in CurrencyAmount 5023 elements that can be used with the Brand, and 5024 o the Payment Protocols and Payment Handlers, 5025 which can be used with those currencies and 5026 amounts, and a particular Brand 5028 CurrencyAmount This contains a currency code and an amount. 5030 PayProtocol This contains information about a Payment 5031 Protocol and the Payment Handler which may be 5032 used with a particular Brand. 5034 The relationships between the elements which make up the content of 5035 the Brand List is illustrated in the diagram below. 5037 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 5039 Brand List 5040 Component 5041 | 5042 |-Brand 5043 | Element 5044 | | 5045 | |Protocol 5046 | | AmountRefs 5047 | v 5048 |-Protocol Amount 5049 | Element---------- 5050 | | | 5051 | |Currency |Pay 5052 | | AmountRefs |Protocol 5053 | v |Ref 5054 |-Currency Amount | 5055 | Element | 5056 | | 5057 -PayProtocol<----- 5058 Element 5060 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 5062 Figure 17 Brand List Element Relationships 5064 Examples of complete Brand Lists are contained in section 10 Brand 5065 List Examples. 5067 6.6.1 Brand Element 5069 A Brand Element describes a brand that can be used for making a 5070 payment. One or more of these elements is carried in each Brand List 5071 Component that has the PayDirection attribute set to Debit. Exactly 5072 one Brand Element may be carried in a Brand List Component that has 5073 the PayDirection attribute set to Credit. 5075 5076 5086 Attributes: 5088 Id Element identifier, potentially referenced in a 5089 Brand Selection Component contained in a later 5090 Payment Request message and uniquely identifies 5091 the Brand element within the IOTP Transaction. 5093 xml:lang Defines the language used by attributes and 5094 content of this element. See section 3.9 5095 Identifying Languages. 5097 BrandId This contains a unique identifier for the brand 5098 or promotional brand. It is used to match 5099 against a list of Payment Instruments which the 5100 Consumer holds to determine whether or not the 5101 Consumer can pay with the Brand. 5103 The syntax for a BrandId is as follows: 5105 BrandId ::= BrandIdDomain ":" BrandValue 5107 Currently the two valid values for the 5108 BrandIdDomain have been defined: 5109 o IOTP which indicates that values of BrandValue 5110 are managed under the procedure described in 5111 section 3.7.3 Values for IOTP Codes, and 5112 o SET which indicates that the BrandValue 5113 conforms to [SET] conventions 5115 Examples of BrandIds are: IOTP:Mondex, 5116 SET:MasterCard::, and 5117 SET:Visa:Gold:AmericanAirlines. The first 5118 BrandId is an example of an IOTP BrandId, and 5119 the following two are SET BrandIds. 5121 As values of BrandId are controlled under the 5122 procedures defined in section 3.7.3 Values for 5123 IOTP Codes user defined values may be defined. 5125 BrandName This contains the name of the brand, for example 5126 MasterCard Credit. This is the description of 5127 the Brand which is displayed to the consumer in 5128 the Consumers language defined by xml:lang. For 5129 example it might be "American Airlines Advantage 5130 Visa". Note that this attribute is not used for 5131 matching against the payment instruments held by 5132 the Consumer. 5134 BrandLogoNetLocn The net location which can be used to download 5135 the logo for the organisation. See section 5136 Retrieving Logos (see section 9). 5138 The content of this attribute must conform to 5139 [RFC1738]. 5141 BrandNarrative This optional attribute is designed to be used 5142 by the Merchant to indicate some special 5143 conditions or benefit which would apply if the 5144 Consumer selected that brand. For example "5% 5145 discount", "free shipping and handling", "free 5146 breakage insurance for 1 year", "double air 5147 miles apply", etc. 5149 ProtocolAmountRefs Identifies the protocols and related currencies 5150 and amounts which can be used with this Brand. 5151 Specified as a list of ID's of Protocol Amount 5152 Elements (see section 6.6.2) contained within 5153 the Brand List. 5155 ContentSoftwareId This optional attribute contains information 5156 which identifies the software which generated 5157 the content of the element. Its purpose is to 5158 help resolve interoperability problems that 5159 might occur as a result of incompatibilities 5160 between messages produced by different software. 5161 It is a single text string in the language 5162 defined by xml:lang. It must contain, as a 5163 minimum: 5164 o the name of the software manufacturer 5165 o the name of the software 5166 o the version of the software, and 5167 o the build of the software 5169 It is recommended that this attribute is 5170 included if the software which generated the 5171 content cannot be identified from the SoftwareId 5172 attribute on the Message Id Component (see 5173 section 3.3.2) 5175 Content: 5177 PackagedContent Optional Packaged Content (see section 3.8) 5178 elements containing information about the brand 5179 which may be used by the payment protocol. The 5180 content of this information is defined in the 5181 supplement for a payment protocol which 5182 describes how the payment protocol works with 5183 IOTP. 5185 Examples Brand Elements are contained in section 10 Brand List 5186 Examples. 5188 6.6.2 Protocol Amount Element 5190 The Protocol Amount element links a Brand to: 5192 o the currencies and amounts in Currency Amount Elements (see 5193 section 6.6.3) that can be used with the Brand, and 5195 o the Payment Protocols and Payment Handlers defined in a Pay 5196 Protocol Element (see section 6.6.4), which can be used with 5197 those currencies and amounts. 5199 Its definition is as follows: 5201 5202 5208 Attributes: 5210 Id Element identifier, potentially referenced in a 5211 Brand element; or in a Brand Selection Component 5212 contained in a later Payment Request message 5213 which uniquely identifies the Protocol Amount 5214 element within the IOTP Transaction. 5216 PayProtocolRef Contains an Element Reference (see section 3.5) 5217 that refers to the Pay Protocol Element (see 5218 section 6.6.4) that contains the Payment 5219 Protocol and Payment Handlers that can be used 5220 with the Brand. 5222 CurrencyAmountRefs Contains a list of Element References (see 5223 section 3.5) that refer to the Currency Amount 5224 Element (see section 6.6.3) that describes the 5225 currencies and amounts that can be used with the 5226 Brand. 5228 ContentSoftwareId This contains information which identifies the 5229 software which generated the content of the 5230 element. Its purpose is to help resolve 5231 interoperability problems that might occur as a 5232 result of incompatibilities between messages 5233 produced by different software. It is a single 5234 text string in the language defined by xml:lang. 5235 It must contain, as a minimum: 5236 o the name of the software manufacturer 5237 o the name of the software 5238 o the version of the software, and 5239 o the build of the software 5241 It is recommended that this attribute is 5242 included if the software which generated the 5243 content cannot be identified from the SoftwareId 5244 attribute on the Message Id Component (see 5245 section 3.3.2) 5247 Content: 5249 PackagedContent Optional Packaged Content (see section 3.8) 5250 elements containing information about the 5251 protocol amount which may be used by the payment 5252 protocol. The content of this information is 5253 defined in the supplement for a payment protocol 5254 which describes how the payment protocol works 5255 with IOTP. 5257 Examples of Protocol Amount Elements are contained in10 Brand List 5258 Examples. 5260 6.6.3 Currency Amount Element 5262 A Currency Amount element contains: 5264 o a currency code (and its type), and 5266 o an amount. 5268 One or more of these elements is carried in each Brand List Component. 5269 Its definition is as follows: 5271 5272 5278 Attributes: 5280 Id Element identifier, potentially referenced in a 5281 Brand element; or in a Brand Selection Component 5282 contained in a later Payment Request message 5283 which uniquely identifies the Currency Amount 5284 Element within the IOTP Transaction. 5286 Amount Indicates the amount to be paid in whole and 5287 fractional units of the currency. For example 5288 $245.35 would be expressed "245.35". Note that 5289 values smaller than the smallest denomination 5290 are allowed. For example one tenth of a cent 5291 would be "0.001". 5293 CurrCodeType Indicates the domain of the CurrCode. This 5294 attribute is included so that the currency code 5295 may support non-standard "currencies" such as 5296 frequent flyer points, trading stamps, etc. Its 5297 values may be: 5298 . ISO4217 indicates the currency code conforms 5299 to [ISO 4217] 5300 . IOTP indicates that values of CurrCode are 5301 managed under the procedure described in 5302 section 3.7.3 Values for IOTP Codes 5304 CurrCode A code which identifies the currency to be used 5305 in the payment. The domain of valid currency 5306 codes is defined by CurrCodeType 5307 As values of CurrCodeType are managed under the 5308 procedure described in section 3.7.3 Values for 5309 IOTP Codes user defined values of CurrCodeType 5310 may be defined. 5312 Examples of Currency Amount Elements are contained in 10 Brand List 5313 Examples. 5315 6.6.4 Pay Protocol Element 5317 A Pay Protocol element specifies details of a Payment Protocol and the 5318 Payment Handler that can be used with a Brand. One or more of these 5319 elements is carried in each Brand List. 5321 5322 5332 Attributes: 5334 Id Element identifier, potentially referenced in a 5335 Brand element; or in a Brand Selection Component 5336 contained in a later Payment Request message 5337 which uniquely identifies the Pay Protocol 5338 element within the IOTP Transaction. 5340 xml:lang Defines the language used by attributes and 5341 content of this element. See section 3.9 5342 Identifying Languages. 5344 ProtocolId Consists of a protocol name and version. For 5345 example "SETv1.0". 5347 Values of ProtocolId are managed under the 5348 procedure described in section 3.7.3 Values for 5349 IOTP Codes. 5351 Each payment supplement defines the value to be 5352 used with that payment method. 5354 ProtocolName A narrative description of the payment protocol 5355 and its version in the language identified by 5356 xml:lang. For example "Secure Electronic 5357 Transaction Version 1.0". Its purpose is to help 5358 provide information on the payment protocol 5359 being used if problems arise. 5361 ActionOrgRef An Element Reference (see section 3.5) to the 5362 Organisation Component for the Payment Handler 5363 for the Payment Protocol. 5365 PayReqNetLocn The Net Location indicating where an unsecured 5366 Payment Request message should be sent if this 5367 protocol choice is used. 5369 The content of this attribute is dependent on 5370 the Transport Mechanism (such must conform to 5371 [RFC1738]. 5373 SecPayReqNetLocn The Net Location indicating where a secured 5374 Payment Request message should be sent if this 5375 protocol choice is used. 5377 A secured payment involves the use of a secure 5378 channel such as [SSL] in order to communicate 5379 with the Payment Handler. 5381 The content of this attribute must conform to 5382 [RFC1738]. See also See section 3.10 Secure and 5383 Insecure Net Locations. 5385 ContentSoftwareId This contains information which identifies the 5386 software which generated the content of the 5387 element. Its purpose is to help resolve 5388 interoperability problems that might occur as a 5389 result of incompatibilities between messages 5390 produced by different software. It is a single 5391 text string in the language defined by xml:lang. 5392 It must contain, as a minimum: 5393 o the name of the software manufacturer 5394 o the name of the software 5395 o the version of the software, and 5396 o the build of the software 5398 It is recommended that this attribute is 5399 included if the software which generated the 5400 content cannot be identified from the SoftwareId 5401 attribute on the Message Id Component (see 5402 section 3.3.2) 5404 Content: 5406 PackagedContent Optional Packaged Content elements (see section 5407 3.8) containing information about the protocol 5408 which is used by the payment protocol. The 5409 content of this information is defined in the 5410 supplement for a payment protocol which 5411 describes how the payment protocol works with 5412 IOTP. An example of its use could be to include 5413 a payment protocol message. 5415 Examples of Pay Protocol Elements are contained in section 6.6 Brand 5416 List Component. 5418 6.7 Brand Selection Component 5420 A Brand Selection Component identifies the choice of payment brand, 5421 payment protocol and the Payment Handler. This element is used: 5423 o in Payment Request messages within Baseline Purchase and 5424 Baseline Value IOTP Transactions to identify the brand, 5425 protocol and payment handler for a payment, or 5427 o to, optionally, inform a merchant in a purchase of the payment 5428 brand being used so that the offer and order details can be 5429 amended accordingly. 5431 In Baseline IOTP, the integrity of Brand Selection Components is not 5432 guaranteed. However, modification of Brand Selection Components can 5433 only cause denial of service if the payment protocol itself is secure 5434 against message modification, duplication, and swapping attacks. 5436 The definition of a Brand Selection Component is as follows. 5438 5441 5448 Attributes: 5450 ID An identifier which uniquely identifies the 5451 Brand Selection Component within the IOTP 5452 Transaction. 5454 BrandListRef The Element Reference (see section 3.5) of the 5455 Brand List Component from which a Brand is being 5456 selected 5458 BrandRef The Element Reference of a Brand element within 5459 the Brand List Component that is being selected 5460 that is to be used in the payment. 5462 ProtocolAmountRef The Element Reference of a Protocol Amount 5463 element within the Brand List Component which is 5464 to be used when making the payment. 5466 CurrencyAmountRef The Element Reference of a Currency Amount 5467 element within the Brand List Component which is 5468 to be used when making the payment. 5470 Content: 5472 BrandSelBrandInfo, This contains any additional data that may be 5473 BrandSelProtocolAm required by a particular payment brand or 5474 ountInfo, protocol. See sections 6.7.1, 6.7.2, and 6.7.3. 5475 BrandSelCurrencyAm 5476 ountInfo 5478 The following rules apply: 5480 o the BrandListRef must contain the ID of a Brand List Component 5481 in the same IOTP Transaction 5483 o every Brand List Component in the Trading Protocol Options 5484 Block must be referenced by one and only one Brand Selection 5485 Component 5487 o the BrandRef must refer to the ID of a Brand contained within 5488 the Brand List Component referred to by BrandListRef 5490 o the ProtocolAmountRef must refer to one of the Element IDs 5491 listed in the ProtocolAmountRefs attribute of the Brand 5492 element identified by BrandRef 5494 o the CurrencyAmountRef must refer to one of the Element IDs 5495 listed in the CurrencyAmountRefs attribute of the Protocol 5496 Amount Element identified by ProtocolAmountRef. 5498 An example of a Brand Selection Component is included in 10 Brand List 5499 Examples. 5501 6.7.1 Brand Selection Brand Info Element 5503 The Brand Selection Brand Info Element contains any additional data 5504 that may be required by a particular payment brand. See the IOTP 5505 payment method supplement for a description of how and when it used. 5507 5508 5512 Attributes: 5514 ContentSoftwareId This contains information which identifies the 5515 software which generated the content of the 5516 element. Its purpose is to help resolve 5517 interoperability problems that might occur as a 5518 result of incompatibilities between messages 5519 produced by different software. It is a single 5520 text string in the language defined by xml:lang. 5521 It must contain, as a minimum: 5522 o the name of the software manufacturer 5523 o the name of the software 5524 o the version of the software, and 5525 o the build of the software 5527 It is recommended that this attribute is 5528 included if the software which generated the 5529 content cannot be identified from the SoftwareId 5530 attribute on the Message Id Component (see 5531 section 3.3.2) 5533 Content: 5535 PackagedContent Packaged Content elements (see section 3.8) that 5536 contain additional data that may be required by 5537 a particular payment brand. See the payment 5538 method supplement for IOTP for rules on how this 5539 is used. 5541 6.7.2 Brand Selection Protocol Amount Info Element 5543 The Brand Selection Protocol Amount Info Element contains any 5544 additional data that is payment protocol specific that may be required 5545 by a particular payment brand or payment protocol. See the IOTP 5546 payment method supplement for a description of how and when it used. 5548 5549 5553 Attributes: 5555 ContentSoftwareId See section 6.7.1 Brand Selection Brand Info 5556 Element. 5558 Content: 5560 PackagedContent Packaged Content elements (see section 3.8) that 5561 may contain additional data that may be required 5562 by a particular payment brand. See the payment 5563 method supplement for IOTP for rules on how this 5564 is used. 5566 6.7.3 Brand Selection Currency Amount Info Element 5568 The Brand Selection Currency Amount Info Element contains any 5569 additional data that is payment brand and currency specific that may 5570 be required by a particular payment brand. See the IOTP payment method 5571 supplement for a description of how and when it used. 5573 5574 5578 Attributes: 5580 ContentSoftwareId See section 6.7.1 Brand Selection Brand Info 5581 Element. 5583 Content: 5585 PackagedContent Packaged Content elements (see section 3.8) that 5586 contain additional data relating to the payment 5587 brand and currency. See the payment method 5588 supplement for IOTP for rules on how this is 5589 used. 5591 6.8 Payment Component 5593 A Payment Component contains information used to control how a payment 5594 is carried out. Its provides information on: 5596 o the times within which a Payment with a Payment Handler may be 5597 started 5599 o a reference to the Brand List (see section 6.6) which 5600 identifies the Brands, protocols, currencies and amounts which 5601 can be used to make a payment 5603 o whether or not a payment receipt will be provided 5605 o whether another payment precedes this payment. 5607 Its definition is as follows. 5609 5610 5618 Attributes: 5620 ID An identifier which uniquely identifies the 5621 Payment Component within the IOTP Transaction. 5623 OkFrom The date and time in [UTC] format after which a 5624 Payment Handler may accept for processing a 5625 Payment Request Block (see section 7.7) 5626 containing the Payment Component. 5628 OkTo The date and time in [UTC] format before which a 5629 Payment Handler may for processing accept a 5630 Payment Request Block containing the Payment 5631 Component. 5633 BrandListRef An Element Reference (see section 3.5) of a 5634 Brand List Component (see section 6.6) within 5635 the TPO Trading Block for the IOTP Transaction. 5636 The Brand List identifies the alternative ways 5637 in which the payment can be made. 5639 SignedPayReceipt Indicates whether or not the Payment Response 5640 Block (7.9) generated by the payment handler for 5641 the payment must be digitally signed. 5643 StartAfter Contains Element References (see section 3.5) of 5644 other Payment Components which describe payments 5645 which must be complete before this payment can 5646 start. If no StartAfter attribute is present 5647 then there are no dependencies and the payment 5648 can start immediately 5650 6.9 Payment Scheme Component 5652 A Payment Scheme Component contains payment protocol information for a 5653 specific payment scheme which is transferred between the parties 5654 involved in a payment for example a [SET] message. Its definition is 5655 as follows. 5657 5658 5664 Attributes: 5666 ID An identifier which uniquely identifies the 5667 Payment Scheme Component within the IOTP 5668 Transaction. 5670 ConsumerPaymentId An identifier specified by the Consumer which, 5671 if returned by the Payment Handler in another 5672 Payment Scheme Component or by other means, 5673 will enable the Consumer to identify which 5674 payment is being referred to. 5676 PaymentHandlerPayId An identifier specified by the Payment Handler 5677 which, if returned by the Consumer in another 5678 Payment Scheme Component, or by other means, 5679 will enable the Payment Handler to identify 5680 which payment is being referred to. It is 5681 required on every Payment Scheme Component 5682 apart from the one contained in a Payment 5683 Request Block. 5685 ContentSoftwareId This contains information which identifies the 5686 software which generated the content of the 5687 element. Its purpose is to help resolve 5688 interoperability problems that might occur as a 5689 result of incompatibilities between messages 5690 produced by different software. It is a single 5691 text string in the language defined by 5692 xml:lang. It must contain, as a minimum: 5693 o the name of the software manufacturer 5694 o the name of the software 5695 o the version of the software, and 5696 o the build of the software 5697 It is recommended that this attribute is 5698 included if the software which generated the 5699 content cannot be identified from the 5700 SoftwareId attribute on the Message Id 5701 Component (see section 3.3.2) 5703 Content: 5705 PackagedContent Contains payment scheme protocol information as 5706 Packaged Content elements (see section 3.8). See 5707 the payment scheme supplement for the definition 5708 of its content. 5710 6.10 Payment Receipt Component 5712 A Payment Receipt is a record of a payment which demonstrates how much 5713 money has been paid or received. It is distinct from a purchase 5714 receipt in that it contains no record of what was being purchased. 5716 Typically the content of a Payment Receipt Component will contain data 5717 which describes: 5719 o the amount paid and its currency 5721 o the date and time of the payment 5723 o internal reference numbers which identify the payment to the 5724 payment system 5726 o potentially digital signatures generated by the payment method 5727 which can be used to prove after the event that the payment 5728 occurred. 5730 If the Payment Method being used provides the facility then the 5731 Payment Receipt Component should contain payment protocol messages, or 5732 references to messages, which prove the payment occurred. 5734 The precise definition of the content is Payment Method dependent. 5735 Refer to the supplement for the payment method being used to determine 5736 the rules that apply. 5738 Information contained in the Payment Receipt Component should be 5739 displayed or otherwise made available to the Consumer. 5741 [Note] If the Payment Receipt Component contains Payment Protocol 5742 Messages, then the Messages will need to be processed by 5743 Payment Method software to convert it into a format which 5744 can be understood by the Consumer 5745 [Note End] 5747 The definition of a Payment Receipt Component is as follows. 5749 5750 5756 Attributes: 5758 ID An identifier which uniquely identifies the 5759 Payment Receipt Component within the IOTP 5760 Transaction. 5762 PaymentRef Contains an Element Reference (see section 3.5) 5763 to the Payment Component (see section 6.8) to 5764 which this payment receipt applies 5766 PayReceiptRefs Optionally contains Element References to other 5767 Components (potentially including Pay Scheme 5768 Components) which together make up the receipt. 5769 Note that: 5770 o each payment scheme defines in its supplement 5771 the elements which must be referenced. 5772 o each of the components must be referenced by 5773 Digests in the Payment Response signature 5774 component, if one is being used. 5776 The client software should save all the 5777 components referenced so that the payment 5778 receipt can be reconstructed when required. 5780 ContentSoftwareId This contains information which identifies the 5781 software which generated the content of the 5782 element. Its purpose is to help resolve 5783 interoperability problems that might occur as a 5784 result of incompatibilities between messages 5785 produced by different software. It is a single 5786 text string in the language defined by xml:lang. 5787 It must contain, as a minimum: 5789 o the name of the software manufacturer 5790 o the name of the software 5791 o the version of the software, and 5792 o the build of the software 5794 It is recommended that this attribute is 5795 included if the software which generated the 5796 content cannot be identified from the SoftwareId 5797 attribute on the Message Id Component (see 5798 section 3.3.2) 5800 Content: 5802 PackagedContent Contains payment scheme specific record of the 5803 payment which can be used for receipt purposes 5804 as Packaged Content elements (see section 3.8). 5805 Each payment scheme defines in its supplement 5806 the structure of the content. 5808 Note that either the PayReceiptRefs attribute, the PackagedContent 5809 element, or both must be present. 5811 6.11 Payment Note Component 5813 The Payment Note Component contains additional, non payment related, 5814 information which the Payment Handler wants to provide to the 5815 Consumer. For example, if a withdrawal or deposit were being made then 5816 it could contain information on the remaining balance on the account 5817 after the transfer was complete. The information should duplicate 5818 information contained within the Payment Receipt Component. 5820 Information contained in the Payment Note Component should be 5821 displayed or otherwise made available to the Consumer. For 5822 interoperability, the Payment Note Component should support, as a 5823 minimum, the content types of Plain/Text and HTML. Its definition is 5824 as follows. 5826 5827 5831 Attributes: 5833 ID An identifier which uniquely identifies the 5834 Payment Receipt Component within the IOTP 5835 Transaction. 5837 ContentSoftwareId This contains information which identifies the 5838 software which generated the content of the 5839 element. Its purpose is to help resolve 5840 interoperability problems that might occur as a 5841 result of incompatibilities between messages 5842 produced by different software. It is a single 5843 text string in the language defined by xml:lang. 5844 It must contain, as a minimum: 5845 o the name of the software manufacturer 5846 o the name of the software 5847 o the version of the software, and 5848 o the build of the software 5850 It is recommended that this attribute is 5851 included if the software which generated the 5852 content cannot be identified from the SoftwareId 5853 attribute on the Message Id Component (see 5854 section 3.3.2) 5856 Content: 5858 PackagedContent Contains additional, non payment related, 5859 information which the Payment Handler wants to 5860 provide to the Consumer as one or more Packaged 5861 Content elements (see section 3.8). 5863 6.12 Delivery Component 5865 The Delivery Element contains information required to deliver goods or 5866 services. Its definition is as follows. 5868 5869 5877 Attributes: 5879 ID An identifier which uniquely identifies the 5880 Delivery Component within the IOTP Transaction. 5882 xml:lang Defines the language used by attributes or child 5883 elements within this component, unless 5884 overridden by an xml:lang attribute on a child 5885 element. See section 3.9 Identifying Languages. 5887 DelivExch Indicates if this IOTP Transaction includes the 5888 messages associated with a Delivery Exchange. 5889 Valid values are: 5890 . True indicates it does include a Delivery 5891 Exchange 5892 . False indicates it does not include a Delivery 5893 Exchange 5895 If set to true then a DeliveryData element must 5896 be present. If set to false it may be absent. 5898 DelivAndPayResp Indicates if the Delivery Response Block (see 5899 section 7.11) and the Payment Response Block 5900 (see section 7.9 ) are combined into one IOTP 5901 Message. Valid values are: 5902 o True indicates both blocks will be in the same 5903 IOTP Message, and 5904 o False indicates each block will be in a 5905 different IOTP Message 5907 DelivAndPayResp should not be true if DelivExch 5908 is False. 5910 In practice combining the Delivery Response 5911 Block and Payment Response Block is only likely 5912 to be practical if the Merchant, the Payment 5913 Handler and the Delivery Handler are the same 5914 organisation since: 5915 o the Payment Handler must have access to Order 5916 Component information so that they know what 5917 to deliver, and 5918 o the Payment Handler must be able to carry out 5919 the delivery 5921 ActionOrgRef An Element Reference to the Organisation 5922 Component of the Delivery Handler for this 5923 delivery. 5925 ConsumerDeliveryId An identifier specified by the Consumer which, 5926 if returned by the Delivery Handler in another 5927 Delivery Component, or by other means, will 5928 enable the Consumer to identify which Delivery 5929 is being referred to. 5931 Content: 5933 DeliveryData Contains details about how the delivery will be 5934 carried out. See 6.12.1 Delivery Data Element 5935 below. 5937 PackagedContent Contains "user" data defined for the Merchant 5938 which is required by the Delivery Handler as one 5939 or more Packaged Content Elements see section 5940 3.8. 5942 6.12.1 Delivery Data Element 5944 The DeliveryData element contains information about where and how 5945 goods are to be delivered. Its definition is as follows. 5947 5948 5958 Attributes: 5960 xml:lang Defines the language used by attributes within 5961 this component. See section 3.9 Identifying 5962 Languages. 5964 OkFrom The date and time in [UTC] format after which 5965 the Delivery Handler may accept for processing a 5966 Delivery Request Block (see section 7.10). 5968 OkTo The date and time in [UTC] format before which 5969 the Delivery Handler may accept for processing a 5970 Delivery Request Block. 5972 DelivMethod Indicates the method by which goods or services 5973 may be delivered. Valid values are: 5974 o Post the goods will be delivered by post or 5975 courier 5976 o Web the goods will be delivered electronically 5977 in the Delivery Note Component 5978 o Email the goods will be delivered 5979 electronically by e-mail 5981 Values of DelivMethod are managed under the 5982 procedure described in section 3.7.3 Values for 5983 IOTP Codes which allows user defined codes to be 5984 defined. 5986 DelivToRef The Element Reference (see section 3.4) of an 5987 Organisation Component within the IOTP 5988 Transaction which has a role of DelivTo. The 5989 information in this block is used to determine 5990 where delivery is to be made. It must be 5991 compatible with DelivMethod. Specifically if the 5992 DelivMethod is: 5993 o Post, then the there must be a Postal Address 5994 Element containing sufficient information for 5995 a postal delivery, 5996 o Web, then there are no specific requirements. 5997 The information will be sent in a web page 5998 back to the Consumer 5999 o Email, then there must be Contact Information 6000 Element with a valid e-mail address 6002 DelivReqNetLocn This contains the Net Location to which an 6003 unsecured Delivery Request Block (see section 6004 7.10) which contains the Delivery Component 6005 should be sent. 6007 The content of this attribute is dependent on 6008 the Transport Mechanism must conform to 6009 [RFC1738]. 6011 SecDelivReqNetLocn This contains the Net Location to which a 6012 secured Delivery Request Block (see section 6013 7.10) which contains the Delivery Component 6014 should be sent. 6016 A secured delivery request involves the use of a 6017 secure channel such as [SSL] in order to 6018 communicate with the Payment Handler. 6020 The content of this attribute is dependent on 6021 the Transport Mechanism must conform to 6022 [RFC1738]. 6024 See also Section 3.10 Secure and Insecure Net 6025 Locations. 6027 ContentSoftwareId This contains information which identifies the 6028 software which generated the content of the 6029 element. Its purpose is to help resolve 6030 interoperability problems that might occur as a 6031 result of incompatibilities between messages 6032 produced by different software. It is a single 6033 text string in the language defined by xml:lang. 6034 It must contain, as a minimum: 6035 o the name of the software manufacturer 6036 o the name of the software 6037 o the version of the software, and 6038 o the build of the software 6040 It is recommended that this attribute is 6041 included if the software which generated the 6042 content cannot be identified from the SoftwareId 6043 attribute on the Message Id Component (see 6044 section 3.3.2) 6046 Content: 6048 PackagedContent Additional information about the delivery as one 6049 or more Packaged Content elements (see section 6050 3.8) provided to the Delivery Handler by the 6051 merchant. 6053 6.13 Delivery Note Component 6055 A Delivery Note contains delivery instructions about the delivery of 6056 goods or services or potentially the actual Delivery Information 6057 itself. It is information which the person or organisation receiving 6058 the Delivery Note can use when delivery occurs. 6060 For interoperability, the Delivery Note Component Packaged Content 6061 should support both Plain Text and HTML. 6063 6064 6070 Attributes: 6072 ID An identifier which uniquely identifies the 6073 Delivery Note Component within the IOTP 6074 Transaction. 6076 xml:lang Defines the language used by attributes or 6077 child elements within this component, unless 6078 overridden by an xml:lang attribute on a child 6079 element. See section 3.9 Identifying Languages. 6081 DelivHandlerDelivId An optional identifier specified by the 6082 Delivery Handler which, if returned by the 6083 Consumer in another Delivery Component, or by 6084 other means, will enable the Delivery Handler 6085 to identify which Delivery is being referred 6086 to. It is required on every Delivery Component 6087 apart from the one contained in a Delivery 6088 Request Block. 6090 An example use of this attribute is to contain 6091 a delivery tracking number. 6093 ContentSoftwareId This contains information which identifies the 6094 software which generated the content of the 6095 element. Its purpose is to help resolve 6096 interoperability problems that might occur as a 6097 result of incompatibilities between messages 6098 produced by different software. It is a single 6099 text string in the language defined by 6100 xml:lang. It must contain, as a minimum: 6101 o the name of the software manufacturer 6102 o the name of the software 6103 o the version of the software, and 6104 o the build of the software 6106 It is recommended that this attribute is 6107 included if the software which generated the 6108 content cannot be identified from the 6109 SoftwareId attribute on the Message Id 6110 Component (see section 3.3.2) 6112 Content: 6114 DeliveryNote Contains actual delivery note information as one 6115 or more Packaged Content elements (see section 6116 3.8). 6118 [Note] If the content of the Delivery Message is a Mime message 6119 then the Delivery Note may trigger an application which 6120 causes the actual delivery to occur. 6121 [Note End] 6123 6.14 Status Component 6125 A Status Component contains status information about the business 6126 success or failure (see section 4.2) of a process. 6128 Its definition is as follows. 6130 6131 6142 Attributes: 6144 ID An identifier which uniquely identifies the 6145 Status Component within the IOTP Transaction. 6147 xml:lang Defines the language used by attributes within 6148 this component. See section 3.9 Identifying 6149 Languages. 6151 StatusType Indicates the type of process which the Status 6152 is reporting on. It may be set to either Offer, 6153 Payment, Delivery or Authentication. 6155 Values of StatusType are managed under the 6156 procedure described in section 3.7.3 Values for 6157 IOTP Codes which also allows user defined values 6158 of StatusType to be defined. 6160 ElRef Contains an Element Reference (see section 3.5) 6161 to the Component for which the Status is being 6162 described. It must refer to either: 6163 o a Trading Protocol Options Block (see section 6164 7.1), if the StatusType is Offer, 6165 o a Payment Component (see section 6.8), if the 6166 StatusType is Payment, or 6167 o a Delivery Component (see section 6.12), if 6168 the StatusType is Delivery 6169 o an Authentication Data Component (see section 6170 6.2) if the StatusType is Authentication. 6172 ProcessState Contains a State Code which indicates the 6173 current state of the process being carried out. 6174 Valid values for ProcessState are: 6175 o NotYetStarted. A Request Block has been 6176 received but the process has not yet started 6177 o InProgress. Processing of the Request Block 6178 has started but it is not yet complete 6179 o CompletedOk. The processing of the Request 6180 Block has completed successfully without any 6181 errors 6182 o Failed. The processing of the Request Block 6183 has failed because of a business error (see 6184 section 4.2) 6185 o ProcessError. This value is only used when the 6186 Status Component is being used in connection 6187 with an Inquiry Request Trading Block (see 6188 section 7.12). It indicates there was a 6189 Technical Error (see section 4.1) in the 6190 Request Block which is being processed or some 6191 internal processing error. 6193 Note that this code reports on the processing of 6194 a Request Block. Further, asynchronous 6195 processing may occur after the Response Block 6196 associated with the Process has been sent. 6198 CompletionCode Indicates how the process completed. Valid 6199 values for the CompletionCode are given below 6200 together with the conditions when it must be 6201 present. 6203 A CompletionCode is a maximum of 14 characters 6204 long. 6206 ProcessReference This optional attribute holds a reference for 6207 the process whose status is being reported. It 6208 may hold the following values: 6209 o when StatusType is set to Offer, it should 6210 contain the OrderIdentifier from the Order 6211 Component 6212 o when StatusType is set to Payment, it should 6213 contain the PaymentHandlerPayId from the 6214 Payment Scheme Data Component 6215 o when StatusType is set to Delivery, it should 6216 contain the DelivHandlerDelivId from the 6217 Delivery Note Component 6218 o when StatusType is set to Authentication, it 6219 should contain the AuthenticationId from the 6220 Authentication Data Component 6222 This attribute should be absent in the Inquiry 6223 Request message when the Consumer has not been 6224 given such a reference number by the IOTP 6225 Service Provider. 6227 This attribute can be used in an Inquiry 6228 Response Block (see section 7.13) to give the 6229 reference number for a transaction which has 6230 previously been unavailable. 6232 For example, the package tracking number might 6233 not be assigned at the time a delivery response 6234 was received. However, if the Consumer issues a 6235 Baseline Transaction Status Inquiry later, the 6236 Delivery Handler can put the package tracking 6237 number into this attribute in the Inquiry 6238 Response message and send it back to the 6239 Consumer. 6241 StatusDesc An optional textual description of the current 6242 status of the process in the language identified 6243 by xml:lang. 6245 6.14.1 Offer Completion Codes 6247 The Completion Code is only required if the ProcessState attribute is 6248 set to Failed. The following table contains the valid values for the 6249 CompletionCode that may be used. It is recommended that the StatusDesc 6250 attribute is used to provide further explanation where appropriate. 6252 Value Description 6254 AuthError Authentication Error. The check of the 6255 Authentication Response which was carried out 6256 has failed. 6258 ConsCancelled Consumer Cancelled. The Consumer decides to 6259 cancel the transaction for some reason. This 6260 code is only valid in a Status Component 6261 contained in a Cancel Block. 6263 MerchCancelled Offer Cancelled. The Merchant declines to 6264 generate an offer for some reason and cancels 6265 the transaction. This code is only valid in a 6266 Status Component contained in a Cancel Block. 6268 Unspecified Unspecified error. There is some unknown problem 6269 or error which does not fall into one of the 6270 other CompletionCodes. 6272 6.14.2 Payment Completion Codes 6274 The CompletionCode is only required if the ProcessState attribute is 6275 set to Failed. The following table contains the valid values for the 6276 CompletionCode that may be used. It is recommended that the StatusDesc 6277 attribute is used by individual payment schemes to provide further 6278 explanation where appropriate. 6280 Value Description 6282 BrandNotSupp Brand not supported. The payment brand is not 6283 supported by the Payment Handler. 6285 CurrNotSupp Currency not supported. The currency in which 6286 the payment is to be made is not supported by 6287 either the Payment Instrument or the Payment 6288 Handler. 6290 ConsCancelled Consumer Cancelled. The Consumer decides to 6291 cancel the payment for some reason. This code is 6292 only valid in a Status Component contained in a 6293 Cancel Block. 6295 PaymtCancelled Payment Cancelled. The Payment Handler declines 6296 to complete the payment for some reason and 6297 cancels the transaction. This code is only valid 6298 in a Status Component contained in a Cancel 6299 Block. 6301 AuthError Authentication Error. The Payment Scheme 6302 specific authentication check which was carried 6303 out has failed. 6305 InsuffFunds Insufficient funds. There are insufficient funds 6306 available for the payment to be made. 6308 InstBrandInvalid Payment Instrument not valid for Brand. A 6309 Payment Instrument is being used which does not 6310 correspond with the Brand selected. For example 6311 a Visa credit card is being used when MasterCard 6312 was selected as the Brand. 6314 InstNotValid Payment instrument not valid for trade. The 6315 Payment Instrument cannot be used for the 6316 proposed type of trade, for some reason. 6318 BadInstrument Bad instrument. There is a problem with the 6319 Payment Instrument being used which means that 6320 it is unable to be used for the payment. 6322 Unspecified Unspecified error. There is some unknown problem 6323 or error which does not fall into one of the 6324 other CompletionCodes. The StatusDesc attribute 6325 should provide the explanation of the cause. 6327 6.14.3 Delivery Completion Codes 6329 The following table contains the valid values for the CompletionCode 6330 attribute for a Delivery. It is recommended that the StatusDesc 6331 attribute is used to provide further explanation where appropriate. 6333 Value Description 6335 BackOrdered Back Ordered. The goods to be delivered are on 6336 order but they have not yet been received. 6338 Shipping will be arranged when they are 6339 received. This is only valid if ProcessState is 6340 CompletedOk. 6342 PermNotAvail Permanently Not Available. The goods are 6343 permanently unavailable and cannot be re- 6344 ordered. This is only valid if ProcessState is 6345 Failed. 6347 TempNotAvail Temporarily Not Available. The goods are 6348 temporarily unavailable and may become available 6349 if they can be ordered. This is only valid if 6350 ProcessState is CompletedOk. 6352 ShipPending Shipping Pending. The goods are available and 6353 are scheduled for shipping but they have not yet 6354 been shipped. This is only valid if ProcessState 6355 is CompletedOk. 6357 Shipped Goods Shipped. The goods have been shipped. 6358 Confirmation of delivery is awaited. This is 6359 only valid if ProcessState is CompletedOk. 6361 ShippedNoConf Shipped - No Delivery Confirmation. The goods 6362 have been shipped but it is not possible to 6363 confirm delivery of the goods. This is only 6364 valid if ProcessState is CompletedOk. 6366 ConsCancelled Consumer Cancelled. The Consumer decides to 6367 cancel the delivery for some reason. This code 6368 is only valid in a Status Component contained in 6369 a Cancel Block. 6371 DelivCancelled Delivery Cancelled. The Delivery Handler 6372 declines to complete the Delivery for some 6373 reason and cancels the transaction. This code is 6374 only valid in a Status Component contained in a 6375 Cancel Block. 6377 Confirmed Confirmed. All goods have been delivered and 6378 confirmation of their delivery has been 6379 received. This is only valid if ProcessState is 6380 CompletedOk. 6382 Unspecified Unspecified error. There is some unknown problem 6383 or error which does not fall into one of the 6384 other CompletionCodes. The StatusDesc attribute 6385 should provide the explanation of the cause. 6387 6.14.4 Authentication Completion Codes 6389 The Completion Code is only required if the ProcessState attribute is 6390 set to Failed. The following table contains the valid values for the 6391 CompletionCode that may be used. It is recommended that the StatusDesc 6392 attribute is used to provide further explanation where appropriate. 6394 Value Description 6396 AutEeCancel Authenticatee Cancel. The organisation being 6397 authenticated declines to be authenticated for 6398 some reason. This could be, for example because 6399 the signature on an Authentication Request was 6400 invalid or the Authenticator was not known or 6401 acceptable to the Authenticatee. 6403 AutOrCancel Authenticator Cancel. The organisation 6404 requesting authentication declines to validate 6405 the Authentication Response received for some 6406 reason and cancels the transaction. 6408 NoAuthData Authentication Data Not Available. The 6409 Authenticatee does not have the data that must 6410 be provided so that they may be successfully 6411 authenticated. For example a password may have 6412 been forgotten, the Authenticatee has not yet 6413 become a member, or a smart card token is not 6414 present. 6416 AuthFailed Authentication Failed. The Authenticator checked 6417 the Authentication Response but the 6418 authentication failed for some reason. For 6419 example a password may have been incorrect. 6421 TradRolesIncon Trading Roles Inconsistent. The Trading Roles 6422 contained within the TradingRoleList attribute 6423 of the Authentication Data Component are 6424 inconsistent with the Trading Role which the 6425 Authenticatee is taking in the IOTP Transaction 6426 or is able to take. Examples of inconsistencies 6427 include: 6428 o asking a PaymentHandler for DeliveryHandler 6429 information 6430 o asking a Consumer for Merchant information 6432 Unspecified Unspecified error. There is some unknown problem 6433 or error which does not fall into one of the 6434 other CompletionCodes. 6436 6.15 Trading Role Data Component 6438 The Trading Role Data Component contains opaque data which is needs to 6439 be communicated between the Trading Roles involved in an IOTP 6440 Transaction. 6442 Trading Role Components identify: 6444 o the organisation that generated the component, and 6446 o the organisation that is to receive it. 6448 They are first generated and included in a "Response" Block, and then 6449 copied to the appropriate "Request" Block. For example a Payment 6450 Handler might need to inform a Delivery Handler that a credit card 6451 payment had been authorised but not captured. There may also be other 6452 information that the Payment Handler has generated where the format is 6453 privately agreed with the Delivery Handler which needs to be 6454 communicated. In another example a Merchant might need to provide a 6455 Payment Handler with some specific information about a Consumer so 6456 that consumer can acquire double loyalty points with the payment. 6458 Its definition is as follows. 6460 6461 6466 Attributes: 6468 ID An identifier which uniquely identifies the 6469 Trading Role Data Component within the IOTP 6470 Transaction. 6472 OrginatorElRef Contains an element reference to the 6473 Organisation Component of the Organisation that 6474 created the Trading Role Data Component and 6475 included it in a "Response" Block (e.g. an Offer 6476 Response or a Payment Response Block). 6478 DestinationElRefs Contains element references to the Organisation 6479 Components of the Organisations that are to 6480 receive the Trading Role Data Component in a 6481 "Request" Block (e.g. either a Payment Request 6482 or a Delivery Request Block). 6484 Content: 6486 PackagedContent This contains the data which is to be sent 6487 between the various Trading Roles as one or more 6488 PackagedContent elements see section 3.8. 6490 6.15.1 Who Receives a Trading Role Data Component 6492 The rules for deciding what to do with Trading Role Data Components 6493 are described below. 6495 o whenever a Trading Role Data Component is received in a 6496 "Response" block identify the Organisation Components of the 6497 Organisations that are to receive it as identified by the 6498 DestinationElRefs attribute. 6500 o whenever a "Request" Block is being sent, check to see if it is 6501 being sent to one of the Organisations identified by the 6502 DestinationElRefs attribute. If it is then include in the 6503 "Request" block: 6504 - the Trading Role Data Component as well as, 6505 - the Organisation Component of the Organisation identified by the 6506 OriginatorElRef attribute (if not already present) 6508 6.16 Inquiry Type Component 6510 The Inquiry Component contains the information which indicates what 6511 type of process is being inquired upon. Its definition is as follows. 6513 6514 6520 Attributes: 6522 ID An identifier which uniquely identifies the 6523 Inquiry Type Component within the IOTP 6524 Transaction. 6526 Type Contains the type of inquiry. Valid values for 6527 Type are: 6528 o Offer. The inquiry is about the status of an 6529 offer and is addressed to the Merchant. 6530 o Payment. The inquiry is about the status of a 6531 payment and is addressed to the Payment 6532 Handler. 6533 o Delivery. The inquiry is about the status of a 6534 delivery and addressed to the Delivery 6535 Handler. 6537 ElRef Contains an Element Reference (see section 3.5) 6538 to the component to which this Inquiry Type 6539 Component applies. That is, 6540 o TPO Block when Type is Offer 6541 o Payment Component when Type is Payment 6542 o Delivery Component when Type is Delivery 6544 ProcessReference Optionally contains a reference to the process 6545 being inquired upon. It should be set if the 6546 information is available. For the definition of 6547 the values it may contain, see the 6548 ProcessReference attribute of the Status 6549 Component (see section 6.14). 6551 6.17 Signature Component 6553 [Note] Definitions of the XML structures for signatures and 6554 certificates are described in the paper "Digital Signatures 6555 for XML - Proposal", see [XMLDSIG]. As this is an Internet 6556 Draft, it will be subject to revision. 6558 However there is an immediate need for a more stable version 6559 to be used with pilots of IOTP that are currently planned. 6560 Therefore, this section contains a definition of a Signature 6561 Component that closely follows the definitions contained in 6562 XMLDSIG, but has been modified to meet some specific IOTP 6563 requirements. 6565 In the future it is anticipated that future versions of IOTP 6566 will adopt a stable version of the XMLDSIG once it becomes 6567 available. 6568 [Note End] 6570 Each Signature Component digitally signs one or more Blocks or 6571 Components including other Signature Components. 6573 The Signature Component: 6575 o contains digests of one or more Blocks or Components in one or 6576 more IOTP Messages within the same IOTP Transaction and places 6577 the result in a Digest Element 6579 o concatenates these Digest elements with other information on 6580 the type of signature, the originator and potential recipients 6581 of the signature and details of the signature algorithms being 6582 used and places them in a Manifest element, and 6584 o signs the Manifest element using the optional certificate 6585 identified in the Certificate element within the Signature 6586 Block placing the result in a Value element within a Signature 6587 Component 6589 Note that there may be multiple Value elements that contain signatures 6590 of a Manifest Element. 6592 A Signature Component can be one of four types either: 6594 o an Offer Response Signature, 6596 o a Payment Response Signature, 6598 o a Delivery Response Signature, or 6600 o an Authentication Response Signature. 6602 For a general explanation of signatures see section 5 Security 6603 Considerations. 6605 The definition of a Signature Component is as follows: 6607 6608 6611 6621 6622 6627 6628 6632 6634 6635 6639 6640 6643 6644 6650 6651 6653 6.17.1 IOTP usage of signature elements and attributes 6655 Detailed definitions of the above elements and attributes are 6656 contained in [XMLDSIG]. The following contains additional information 6657 that describes how these elements and attributes are used by IOTP. 6659 SIGNATURE ELEMENT 6661 The ID attribute is mandatory. 6663 MANIFEST ELEMENT 6665 The optional LocatorHrefBase attribute contains text which should be 6666 concatenated before the text contained in the LocatorHREF attribute of 6667 all Digest elements within the Manifest. 6669 Its purpose is to reduce the size of LocatorHREF attribute values 6670 since the first part of the LocatorHREF attributes in the same 6671 signature are likely to be the same. 6673 Typically, within IOTP, it will contain all the characters in a 6674 LocatorHref attribute up to the sharp ("#") character (see immediately 6675 below). 6677 ALGORITHM AND PARAMETER ELEMENTS 6679 The algorithm element identifies the algorithms used in generating the 6680 signature. The type of the algorithm is defined by the value of the 6681 Type attribute which indicates if it is the algorithm is to be used as 6682 a Digest algorithm, a Signature algorithm or a Key Agreement 6683 algorithm. 6685 The following Digest algorithms must be implemented: 6687 o a [DOM-HASH] algorithm. This is identified by setting the Name 6688 attribute of the Algorithm element to "urn:ibm:dom-hash" 6690 o a [SHA1] algorithm. This is identified by setting the Name 6691 attribute of the Algorithm element to "urn:fips:sha1", and 6693 o a [MD5] algorithm. This is identified by setting the Name 6694 attribute of the Algorithm element to "urn:rsa:md5" 6696 The following Signature algorithms must be implemented: 6698 o a [DSA] algorithm. This is identified by setting the Name 6699 attribute of the Algorithm element to "urn:us.gov:dsa" 6701 o a [HMAC] algorithm. This is identified by setting the Name 6702 attribute of the Algorithm element to "urn:ibm:hmac" 6704 It is recommended that the following Signature algorithm is also 6705 implemented: 6707 o a [RSA] algorithm. This is identified by setting the Name 6708 attribute of the Algorithm element to "urn:rsa:rsa" 6710 In addition other payment scheme specific algorithms may be used. In 6711 this case the value of the name attribute to use is specified in the 6712 payment scheme supplement for that algorithm. 6714 One algorithm may make use of other algorithms by use of the Parameter 6715 element, for example: 6717 6718 A2 6719 6720 6721 6722 6723 A1 6724 6726 DIGEST ELEMENT 6728 The LocatorHREF attribute identifies the IOTP element which is being 6729 digitally signed. Specifically it consists of: 6731 o the value of the OtpTransId attribute of the Transaction ID 6732 Component, followed by: 6734 o a sharp character, i.e. "#", followed by 6736 o an Element Reference (see section 3.5) to the element within 6737 the IOTP Transaction which is the subject of the digest. 6739 Before analysing the structure of the LocatorHREF attribute, it must 6740 be concatenated with the value of the LocatorHrefBase attribute of the 6741 Manifest element (see immediately above). 6743 ATTRIBUTE ELEMENT 6745 There must be one and only one Attribute Element that contains a Type 6746 attribute with a value of IOTPSignatureType and with content set to 6747 either: OfferResponse, PaymentResponse, DeliveryResponse, 6748 AuthenticationRequest, AuthenticationResponse, PingRequest or 6749 PingResponse; depending on the type of the signature. 6751 Values of the content of the Attribute element are controlled under 6752 the procedures defined in section 3.7.3 Values for IOTP Codes which 6753 also allows user defined values to be defined. 6755 The Critical attribute must be set to true. 6757 ORIGINATORINFO ELEMENT 6759 The OriginatorRef attribute of the OriginatorInfo element must always 6760 be present and contain an Element Reference (see section 3.5) to the 6761 Organisation Component of the Organisation that generated the 6762 Signature Component. 6764 RECIPIENTINFO ELEMENT 6766 The RecipientRefs attribute contains a list of Element References (see 6767 section 3.5), that point to the Organisations that might need to 6768 validate the signature. For details see below. 6770 6.17.2 Offer Response Signature Component 6772 The Manifest Element of a signature which has a type of OfferResponse 6773 should contain Digest elements for the following Components: 6775 o the Transaction Id Component (see section 3.3.1) of the IOTP 6776 message that contains the Offer Response Signature 6778 o the Transaction Reference Block (see section 3.3) of the IOTP 6779 Message that contains the Offer Response Signature 6781 o from the TPO Block: 6782 - the Protocol Options Component 6783 - each of the Organisation Components 6784 - each of the Brand List Components 6786 o optionally, all the Brand Selection Components if they were 6787 sent to the Merchant in a TPO Selection Block 6789 o from the Offer Response Block: 6790 - the Order Component 6791 - each of the Payment Components 6792 - the Delivery Component 6793 - each of the Authentication Data Components 6794 - any Trading Role Data Components 6796 The Offer Response Signature should also contain Digest elements for 6797 the components that describe each of the organisations that may or 6798 will need to verify the signature. This involves: 6800 o if the Merchant has received a TPO Selection Block containing 6801 Brand Selection Components, then generate a Digest element for 6802 the Payment Handler identified by the Brand Selection Component 6803 and the Delivery Handler identified by the Delivery Component. 6804 See section 5.3.1 Check the Action Request was sent to the 6805 Correct Organisation for a description of how this can be done. 6807 o if the Merchant is not expecting to receive a TPO Selection 6808 Block then generate a Digest element for the Delivery Handler 6809 and all the Payment Handlers that are involved. 6811 6.17.3 Payment Receipt Signature Component 6813 The Manifest Element of the Payment Receipt Signature Component should 6814 contain Digest Elements for the following Components: 6816 o the Transaction Id Component (see section 3.3.1) of the IOTP 6817 message that contains the Payment Receipt Signature 6819 o the Transaction Reference Block (see section 3.3) of the IOTP 6820 Message that contains the Payment Receipt Signature 6822 o the Offer Response Signature Component 6824 o the Payment Receipt Component 6826 o the Status Component 6828 o the Brand Selection Component. 6830 o any Trading Role Data Components 6831 6.17.4 Delivery Response Signature Component 6833 The Manifest Element of the Delivery Response Signature Component 6834 should contain Digest Elements for the following Components: 6836 o the Transaction Id Component (see section 3.3.1) of the IOTP 6837 message that contains the Delivery Response Signature 6839 o the Transaction Reference Block (see section 3.3) of the IOTP 6840 Message that contains the Delivery Response Signature 6842 o the Signature Components contained in the preceding Delivery 6843 Request (if any) 6845 o the Status Component 6847 o the Delivery Note Component 6849 6.17.5 Authentication Request Signature Component 6851 The Manifest Element of the Authentication Request Signature Component 6852 should contain Digest Elements for the following Components: 6854 o the Transaction Reference Block (see section 3.3) for the IOTP 6855 Message that contains information that describes the IOTP 6856 Message and IOTP Transaction 6858 o the Transaction Id Component (see section 3.3.1) which globally 6859 uniquely identifies the IOTP Transaction 6861 o the following components of the TPO Block : 6862 - the Protocol Options Component 6863 - the Organisation Component 6865 o the following components of the Authentication Request Block: 6866 - the Authentication Data Component 6868 6.17.6 Authentication Response Signature Component 6870 The Manifest Element of the Authentication Response Signature 6871 Component should contain Digest Elements for the following Components: 6873 o the Transaction Reference Block (see section 3.3) for the IOTP 6874 Message that contains information that describes the IOTP 6875 Message and IOTP Transaction 6877 o the Transaction Id Component (see section 3.3.1) which globally 6878 uniquely identifies the IOTP Transaction 6880 o the following components of the Authentication Request Block: 6881 - the Authentication Data Component 6883 o the Organisation Components contained in the Authentication 6884 Response Block 6886 6.17.7 Ping Request Signature Component 6888 If the Ping Request is being singed (see section 8.2.2), the Manifest 6889 Element of the Ping Request Signature Component should contain Digest 6890 elements for all the Organisation Components. 6892 6.17.8 Ping Response Signature Component 6894 If the Ping Response is being singed (see section 8.2.2), the Manifest 6895 Element of the Ping Response Signature Component should contain Digest 6896 elements fir all the Organisation Components. 6898 6.18 Certificate Component 6900 [Note] Definitions of the XML structures for signatures and 6901 certificates are described in the paper "Digital Signatures 6902 for XML - Proposal", see [XMLDSIG]. As this is an Internet 6903 Draft, it will be subject to revision. 6905 See note at the start of section 6.17 Signature Component 6906 for more details. 6907 [Note End] 6909 A Certificate Component contains a Digital Certificate. Its structure 6910 is as follows: 6912 6915 6919 6920 6924 6925 6929 6930 6933 6.18.1 IOTP usage of signature elements and attributes 6935 Detailed definitions of the above elements and attributes are 6936 contained in [XMLDSIG]. The following contains additional information 6937 that describes how these elements and attributes are used by IOTP. 6939 CERTIFICATE COMPONENT 6941 The ID attribute is mandatory. 6943 VALUE ELEMENT 6945 The ID attribute is mandatory. 6947 6.19 Error Component 6949 The Error Component contains information about Technical Errors (see 6950 section 4.1) in an IOTP Message which has been received by one of the 6951 Trading Roles involved in the trade. 6953 For clarity two phrases are defined which are used in the description 6954 of an Error Component: 6956 o message in error. An IOTP message which contains or causes an 6957 error of some kind 6959 o message reporting the error. An IOTP message that contains an 6960 Error Component that describes the error found in a message in 6961 error. 6963 The definition of the Error Component is as follows. 6965 6966 6975 Attributes: 6977 ID An identifier which uniquely identifies the 6978 Error Component within the IOTP Transaction. 6980 xml:lang Defines the language used by attributes or child 6981 elements within this component, unless 6982 overridden by an xml:lang attribute on a child 6983 element. See section 3.9 Identifying Languages. 6985 ErrorCode Contains an error code which indicates the 6986 nature of the error in the message in error. 6987 Valid values for the ErrorCode are given in 6988 section 6.19.2 Error Codes. 6990 ErrorDesc Contains a narrative description of the error in 6991 the language defined by xml:lang. The content of 6992 this attribute is defined by the 6993 vendor/developer of the software which generated 6994 the Error Component 6996 Severity Indicates the severity of the error. Valid 6997 values are: 6998 o Warning. This indicates that although there is 6999 a message in error the IOTP Transaction can 7000 still continue. 7001 o TransientError. This indicates that the error 7002 in the message in error may be recovered if 7003 the message in error that is referred to by 7004 the ErrorLocation element is resent 7005 o HardError. This indicates that there is an 7006 unrecoverable error in the message in error 7007 and the IOTP Transaction must stop. 7009 MinRetrySecs This attribute should be present if Severity is 7010 set to TransientError. It is the minimum number 7011 of whole seconds which the IOTP aware 7012 application which received the message reporting 7013 the error should wait before re-sending the 7014 message in error identified by the ErrorLocation 7015 element. 7017 If Severity is not set to TransientError then 7018 the value of this attribute is ignored. 7020 SwVendorErrorRef This attribute is a reference whose value is set 7021 by the vendor/developer of the software which 7022 generated the Error Component. It should contain 7023 data which enables the vendor to identify the 7024 precise location in their software and the set 7025 of circumstances which caused the software to 7026 generate a message reporting the error. See also 7027 the SoftwareId attribute of the Message Id 7028 element in the Transaction Reference Block 7029 (section 3.3). 7031 Content: 7033 ErrorLocation This identifies the IOTP Transaction Id of the 7034 message in error and, where possible, the 7035 element and attribute in the message in error 7036 that caused the Error Component to be generated. 7038 If the Severity of the error is not 7039 TransientError, more than one ErrorLocation may 7040 be specified as appropriate depending on the 7041 nature of the error (see section 6.19.2 Error 7042 Codes) and at the discretion of the 7043 vendor/developer of the IOTP Aware Application. 7045 PackagedContent This contains additional data which can be used 7046 to understand the error. Its content may vary as 7047 appropriate depending on the nature of the error 7048 (see section 6.19.2 Error Codes) and at the 7049 discretion of the vendor/developer of the IOTP 7050 Aware Application. For a definition of 7051 PackagedContent see section 3.8. 7053 6.19.1 Error Processing Guidelines 7055 If there is more than one Error Component in a message reporting the 7056 error, carry out the actions appropriate for the Error Component with 7057 the highest severity. In this context, HardError has a higher severity 7058 than TransientError, which has a higher severity than Warning. 7060 6.19.1.1 Severity - Warning 7062 If an IOTP aware application is generating a message reporting the 7063 error with an Error Component where the Severity attribute is set to 7064 Warning, then if the message reporting the error does not contain 7065 another Error Component with a severity higher than Warning, the IOTP 7066 Message must also include the Trading Blocks and Trading Components 7067 that would have been included if no error was being reported. 7069 If a message reporting the error is received with an Error Component 7070 where Severity is set to Warning, then: 7072 o it is recommended that information about the error is either 7073 logged, or otherwise reported to the user, 7075 o the implementer of the IOTP aware application must either, at 7076 their or the user's discretion: 7077 - continue the IOTP transaction as normal, or 7078 - fail the IOTP transaction by generating a message reporting the 7079 error with an Error Component with Severity set to HardError (see 7080 section 6.19.1.3). 7082 If the intention is to continue the IOTP transaction then, if there 7083 are no other Error Components with a higher severity, check that the 7084 necessary Trading Blocks and Trading Components for normal processing 7085 of the transaction to continue are present. If they are not then 7086 generate a message reporting the error with an Error Component with 7087 Severity set to HardError. 7089 6.19.1.2 Severity - Transient Error 7091 If an IOTP Aware Application is generating a message reporting the 7092 error with an Error Component where the Severity attribute is set to 7093 TransientError, then there should be only one Error Component in the 7094 message reporting the error. In addition, the MinRetrySecs attribute 7095 should be present. 7097 If a message reporting the error is received with an Error Component 7098 where Severity is set to TransientError then: 7100 o if the MinRetrySecs attribute is present and a valid number, 7101 then use the MinRetrySecs value given. Otherwise if 7102 MinRetrySecs is missing or is invalid, then: 7103 - generate a message reporting the error containing an Error 7104 Component with a Severity of Warning and send it on the next IOTP 7105 message (if any) to be sent to the Trading Role which sent the 7106 message reporting the error with the invalid MinRetrySecs, and 7107 - use a value for MinRetrySecs which is set by the vendor/developer 7108 of the IOTP Aware Application. 7110 o check that only one ErrorLocation element is contained within 7111 the Error Component and that it refers to an IOTP Message which 7112 was sent by the recipient of the Error Component with a 7113 Severity of TransientError. If more than one ErrorLocation is 7114 present then generate a message reporting the error with a 7115 Severity of HardError. 7117 6.19.1.3 Severity - Hard Error 7119 If an IOTP Aware Application is generating a message reporting the 7120 error with an Error Component where the Severity attribute set to 7121 HardError, then there should be only one Error Component in the 7122 message reporting the error. 7124 If a message reporting the error is received with an Error Component 7125 where Severity is set to HardError then terminate the IOTP 7126 Transaction. 7128 6.19.2 Error Codes 7130 The following table contains the valid values for the ErrorCode 7131 attribute of the Error Component. The first sentence of the 7132 description contains the text that should be used to describe the 7133 error when displayed or otherwise reported. Individual implementations 7134 may translate this into alternative languages at their discretion. 7136 An Error Code must not be more that 14 characters long. 7138 Value Description 7140 Reserved Reserved. This error is reserved by the 7141 vendor/developer of the software. Contact the 7143 Value Description 7144 vendor/developer of the software for more 7145 information See the SoftwareId attribute of the 7146 Message Id element in the Transaction Reference 7147 Block(section 3.3). 7149 XmlNotWellFrmd XML not well formed. The XML document is not 7150 well formed. See [XML] for the meaning of "well 7151 formed". Even if the XML is not well formed, it 7152 should still be scanned to find the Transaction 7153 Reference Block so that a properly formed Error 7154 Response may be generated. 7156 XmlNotValid XML not valid. The XML document is well formed 7157 but the document is not valid. See [XML] for the 7158 meaning of "valid". Specifically: 7159 o the XML document does not comply with the 7160 constraints defined in the IOTP document type 7161 declaration (see section 11 Open Trading 7162 Protocol Data Type Definition), and 7163 o the XML document does not comply with the 7164 constraints defined in the document type 7165 declaration of any additional [XML Namespace] 7166 that are declared. 7168 As for XML not well formed, attempts should 7169 still be made to extract the Transaction 7170 Reference Block so that a properly formed Error 7171 Response may be generated. 7173 ElUnexpected Unexpected element. Although the XML document is 7174 well formed and valid, an element is present 7175 that is not expected in the particular context 7176 according to the rules and constraints contained 7177 in this specification. 7179 ElNotSupp Element not supported. Although the document is 7180 well formed and valid, an element is present 7181 that: 7182 o is consistent with the rules and constraints 7183 contained in this specification, but 7184 o is not supported by the IOTP Aware Application 7185 which is processing the IOTP Message. 7187 ElMissing Element missing. Although the document is well 7188 formed and valid, an element is missing that 7190 Value Description 7191 should have been present if the rules and 7192 constraints contained in this specification are 7193 followed. 7195 In this case set the PackagedContent of the 7196 Error Component to the type of the missing 7197 element. 7199 ElContIllegal Element content illegal. Although the document 7200 is well formed and valid, the element 7201 PackagedContent contains values which do not 7202 conform to the rules and constraints contained 7203 in this specification. 7205 EncapProtErr Encapsulated protocol error. Although the 7206 document is well formed and valid, the 7207 PackagedContent of an element contains data from 7208 an encapsulated protocol which contains errors. 7210 AttUnexpected Unexpected attribute. Although the XML document 7211 is well formed and valid, the presence of the 7212 attribute is not expected in the particular 7213 context according to the rules and constraints 7214 contained in this specification. 7216 AttNotSupp Attribute not supported. Although the XML 7217 document is well formed and valid, and the 7218 presence of the attribute in an element is 7219 consistent with the rules and constraints 7220 contained in this specification, it is not 7221 supported by the IOTP Aware Application which is 7222 processing the IOTP Message. 7224 AttMissing Attribute missing. Although the document is well 7225 formed and valid, an attribute is missing that 7226 should have been present if the rules and 7227 constraints contained in this specification are 7228 followed. 7230 In this case set the PackagedContent of the 7231 Error Component to the type of the missing 7232 attribute. 7234 AttValIllegal Attribute value illegal. The attribute contains 7235 a value which does not conform to the rules and 7237 Value Description 7238 constraints contained in this specification. 7240 AttValNotRecog Attribute Value Not Recognised. The attribute 7241 contains a value which the IOTP Aware 7242 Application generating the message reporting the 7243 error could not recognise even though it should 7244 have been able to since the information had been 7245 provided in an earlier IOTP message. 7247 MsgTooLarge Message too large. The message is too large to 7248 be processed by the IOTP Aware Application. 7250 ElTooLarge Element too large. The element is too large to 7251 be processed by the IOTP Aware Application 7253 ValueTooSmall Value too small or early. The value of all or 7254 part of the PackagedContent of an element or an 7255 attribute, although valid, is too small. 7257 ValueTooLarge Value too large or in the future. The value of 7258 all or part of the PackagedContent of an 7259 element or an attribute, although valid, is too 7260 large. 7262 ElInconsistent Element Inconsistent. Although the document is 7263 well formed and valid, according to the rules 7264 and constraints contained in this specification: 7265 o the content of an element is inconsistent with 7266 the content of other elements or their 7267 attributes, or 7268 o the value of an attribute is inconsistent with 7269 the value of one or more other attributes. 7271 In this case create ErrorLocation elements which 7272 identify all the attributes or elements which 7273 are inconsistent. 7275 TransportError Transport Error. This error code is used to 7276 indicate that there is a problem with the 7277 Transport Mechanism which is preventing the 7278 message from being received. It is typically 7279 associated with a Transient Error. Explanation 7280 of the Transport Error is contained within the 7281 ErrorDesc attribute. The values which can be 7282 used inside ErrorDesc with a TransportError is 7284 Value Description 7285 specified in the IOTP supplement for the 7286 Transport mechanism. 7288 UnknownError Unknown Error. Indicates that the transaction 7289 cannot complete for some reason that is not 7290 covered explicitly by any of the other errors. 7291 The ErrorDesc attribute should be used to 7292 indicate the nature of the problem. 7294 This could be used to indicate, for example, an 7295 internal error in a backend server or client 7296 process of some kind. 7298 6.19.3 Error Location Element 7300 An Error Location Element identifies an element and optionally an 7301 attribute in the message in error which is associated with the error. 7302 It contains a reference to the IOTP Message, Trading Block, Trading 7303 Component, element and attribute, which is in error. 7305 7306 7314 Attributes: 7316 ElementType This is the "type" (see [XML]) of the Element in 7317 the message in error where the error is located. 7319 OtpMsgRef This is the value of the ID attribute of the of 7320 the Message Id Component (see section 3.3.2) of 7321 the message in error to which this Error 7322 Component applies. 7324 BlkRef If the error is associated with a specific 7325 Trading Block, then this is the value of the ID 7326 attribute of the Trading Block where the error 7327 is located. 7329 CompRef If the error is associated with a specific 7330 Trading Component, then this is the value of the 7331 ID attribute of the Trading Component where the 7332 error is located. 7334 ElementRef If the error is associated with a specific 7335 element within a Trading Component then, if the 7336 element has an attribute with an "attribute 7337 type" (see [XML]) of "ID", then this is the 7338 value of that attribute. 7340 AttName If the error is associated with the value of an 7341 attribute, then this is the name of that 7342 attribute. In this case the PackagedContent of 7343 the Error Component should contain the value of 7344 the attribute. 7346 Note that as many as the attributes as possible should be included. 7347 For example if an attribute in a child element of a Trading Component 7348 contains an incorrect value, then all the attributes of ErrorLocation 7349 should be present. 7351 7. Trading Blocks 7353 Trading Blocks consist of one or more Trading Components and 7354 optionally one or more Signature Components. One or more Trading 7355 Blocks may be contained within the IOTP Messages which are physically 7356 sent in the form of [XML] documents between the different 7357 organisations that are taking part in a trade. 7359 This is illustrated in the diagram below. 7361 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 7363 IOTP MESSAGE <----------- IOTP Message - an XML Document 7364 | which is transported between the 7365 | Trading Roles 7366 |-Trans Ref Block <----- Trans Ref Block - contains 7367 | | information which describes the 7368 | | IOTP Transaction and the IOTP 7369 | | Message. 7370 | |-Trans Id Comp. <--- Transaction Id Component - 7371 | | uniquely identifies the IOTP 7372 | | Transaction. The Trans Id 7373 | | Components are the same across 7374 | | all IOTP messages that comprise a 7375 | | single IOTP transaction. 7376 | |-Msg Id Comp. <----- Message Id Component - identifies 7377 | and describes an IOTP Message 7378 | within an IOTP Transaction 7379 |-Signature Block <----- Signature Block (optional) - 7380 | | contains one or more Signature 7381 | | Components and their associated 7382 | | Certificates 7383 | |-Signature Comp. <-- Signature Component - contains 7384 | | digital signatures. Signatures 7385 | | may sign digests of the Trans Ref 7386 | | Block and any Trading Component 7387 | | in any IOTP Message in the same 7388 | | IOTP Transaction. 7389 | |-Certificate Comp. <- Certificate Component. Used to 7390 | check the signature. 7391 ------> |-Trading Block <-------- Trading Block - an XML Element 7392 | | |-Component within an IOTP Message that 7393 Trading | |-Component contains a predefined set of 7394 Blocks | |-Component Trading Components 7395 | | |-Component 7396 | | |-Component <--------- Trading Components - XML Elements 7397 | | within a Trading Block that 7398 ------> |-Trading Block contain a predefined set of XML 7399 | |-Component elements and attributes 7400 | |-Component containing information required 7401 | |-Component to support a Trading Exchange 7402 | |-Component 7403 | |-Component 7404 | 7405 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 7407 Figure 18 Trading Blocks 7409 Trading Blocks are defined as part of the definition of an IOTP 7410 Message (see section 3.1.1). The definition of an IOTP Message element 7411 is repeated here: 7413 7436 The remainder of this section defines the Trading Blocks in this 7437 version of IOTP. They are: 7439 o Authentication Request Block 7441 o Authentication Response Block 7443 o Authentication Status Block 7445 o Cancel Block 7447 o Delivery Request Block 7449 o Delivery Response Block 7451 o Error Block 7453 o Inquiry Request Block 7455 o Inquiry Response Block 7456 o Offer Response Block 7458 o Payment Exchange Block 7460 o Payment Request Block 7462 o Payment Response Block 7464 o Signature Block 7466 o Trading Protocol Options Block 7468 o TPO Selection Block 7470 The Transaction Reference Block is described in section 3.3. 7472 7.1 Trading Protocol Options Block 7474 The TPO Trading Block contains options which apply to the IOTP 7475 Transaction. The definition of a TPO Trading Block is as follows. 7477 7478 7481 Attributes: 7483 ID An identifier which uniquely identifies the 7484 Trading Protocol Options Block within the IOTP 7485 Transaction (see section 3.4 ID Attributes). 7487 Content: 7489 ProtocolOptions The Protocol Options Component (see section 7490 6.1)defines the options which apply to the whole 7491 IOTP Transaction (see section 8). 7493 BrandList This Brand List Component contains one or more 7494 payment brands and protocols which may be 7495 selected (see section 6.6). 7497 Org The Organisation Components (see section 6.5) 7498 identify the organisations and their roles in 7499 the IOTP Transaction. The roles and 7500 organisations which must be present will depend 7501 on the particular type of IOTP Transaction. See 7502 the definition of each transaction in section 8. 7503 Internet Open Trading Protocol Transactions. 7505 The TPO Block should contain: 7507 o the Protocol Options Component 7509 o the Organisation Component with the Trading Role of Merchant 7511 o the Organisation Component with the Trading Role of Consumer 7513 o optionally, the Organisation Component with the Trading Role of 7514 DeliverTo, if there is a Delivery included in the IOTP 7515 Transaction 7517 o Brand List Components for each payment in the IOTP Transaction 7519 o Organisation Components for all the Payment Handlers involved 7521 o optionally, Organisation Components for the Delivery Handler 7522 (if any) for the transaction 7524 o additional Organisation Components that the Merchant may want 7525 to include. For example 7526 - a Customer Care Provider 7527 - an Certificate Authority that offers Merchant "Credentials" or 7528 some other warranty on the goods or services being offered. 7530 7.2 TPO Selection Block 7532 The TPO Selection Block contains the results of selections made from 7533 the options contained in the Trading Protocol Options Block (see 7534 section 7.1).The definition of a TPO Selection Block is as follows. 7536 7537 7540 Attributes: 7542 ID An identifier which uniquely identifies the TPO 7543 Selection Block within the IOTP Transaction. 7545 Content: 7547 BrandSelection This identifies the choice of payment brand and 7548 payment protocol to be used in a payment within 7549 the IOTP Transaction. There is one Brand 7550 Selection Component (see section 6.7) for each 7551 payment to be made in the IOTP Transaction. 7553 The TPO Selection Block should contain one Brand Selection Component 7554 for each Brand List in the TPO Block. 7556 7.3 Offer Response Block 7558 The Offer Response Block contains details of the goods, services, 7559 amount, delivery instructions or financial transaction which is to 7560 take place. Its definition is as follows. 7562 7564 7567 Attributes: 7569 ID An identifier which uniquely identifies the 7570 Offer Response Block within the IOTP 7571 Transaction. 7573 Content: 7575 Status Contains status information about the business 7576 success (see section 4.2) or failure of the 7577 generation of the Offer. Note that in an Offer 7578 Response Block, a ProcessState of NotYetStarted 7579 or InProgress are illegal values. 7581 Order The Order Component contains details about the 7582 goods, services or financial transaction which 7583 is taking place see section 6.4. 7585 The Order Component must be present unless the 7586 ProcessState attribute of the Status Component 7587 is set to Failed. 7589 Payment The Payment Components contain information about 7590 the payments which are to be made see section 7591 6.8. 7593 Delivery The Delivery Component contains details of the 7594 delivery to be made (see section 6.12). 7596 TradingRoleData The Trading Role Data Component contains opaque 7597 data which is needs to be communicated between 7598 the Trading Roles involved in an OTP Transaction 7599 (see section 6.15). 7601 The Offer Response Block should contain: 7603 o the Order Component for the IOTP Transaction 7605 o Payment Components for each Payment in the IOTP Transaction 7607 o the Delivery Component the IOTP Transaction requires (if any). 7609 7.4 Authentication Request Block 7611 This Authentication Request Block contains the challenge data which is 7612 used to obtain information about and optionally authenticate a 7613 Consumer by another Trading Role. Its definition is as follows. 7615 7616 7619 Attributes 7621 ID An identifier which uniquely identifies the 7622 Authentication Request Block within the IOTP 7623 Transaction. 7625 Content 7627 AuthData If the Authentication Data Component is not 7628 present it means that the Authentication Request 7629 Block is just requesting the return of 7630 Organisation Components which describe the 7631 Trading Role that received the Authentication 7632 Request Block. 7634 If the optional Authentication Data Component 7635 (see section 6.2) is present it contains data 7636 which describes the different types of 7637 Authentication the consumer should provide. 7639 7.5 Authentication Response Block 7641 The Authentication Response Block contains the response which results 7642 from processing the Authentication Request Block. Its definition is as 7643 follows. 7645 7646 7649 Attributes: 7651 ID An identifier which uniquely identifies the 7652 Authentication Response Block within the IOTP 7653 Transaction. 7655 Content: 7657 AuthResp The Authentication Response Component which 7658 contains the results of processing the challenge 7659 data in the Authentication Data Component - see 7660 section 6.3. 7662 Org Organisation Components which contain 7663 information corresponding to the Trading Roles 7664 as requested by the TradingRoleList attribute of 7665 the AuthData component. 7667 7.6 Authentication Status Block 7669 The Authentication Status Block indicates the success or failure of 7670 the validation of an Authentication Response Block by an 7671 Authenticator. Its definition is as follows. 7673 7674 7677 Attributes: 7679 ID An identifier which uniquely identifies the 7680 Authentication Status Block within the IOTP 7681 Transaction. 7683 Content: 7685 Status Contains status information about the business 7686 success (see section 4.2) or failure of the 7687 authentication 7689 7.7 Payment Request Block 7691 The Payment Request Block contains information which requests that a 7692 payment is started. Its definition is as follows. 7694 7696 7699 Attributes: 7701 ID An identifier which uniquely identifies the 7702 Payment Request Block within the IOTP 7703 Transaction. 7705 Content: 7707 Status Contains the Status Components (see section 7708 6.12) of the responses of the steps (e.g. an 7709 Offer Response and/or a Payment Response) on 7710 which this step depends. It is used to indicate 7711 the success or failure of those steps. Payment 7712 should only occur of the previous steps were 7713 successful. 7715 BrandList The Brand List Component contains a list of one 7716 or more payment brands and protocols which may 7717 be selected (see section 6.6). 7719 BrandSelection This identifies the choice of payment brand, the 7720 payment protocol and the payment handler to be 7721 used in a payment within the IOTP Transaction. 7722 There is one Brand Selection Component (see 7723 section 6.7) for each payment to be made in the 7724 IOTP Transaction. 7726 Payment The Payment Components contain information about 7727 the payment which is being made see section 6.8. 7729 PaySchemeData The Payment Scheme Component contains payment 7730 scheme specific data see section 6.9. 7732 Org The Organisation Component contains details of 7733 organisations involved in the payment (see 7734 section 6.5). The Organisations present are 7735 dependent on the IOTP Transaction and the data 7736 which is to be signed. See section 5 Security 7737 Considerations for more details. 7739 TradingRoleData The Trading Role Data Component contains opaque 7740 data which is needs to be communicated between 7741 the Trading Roles involved in an OTP Transaction 7742 (see section 6.15). 7744 The Payment Request Block should contain: 7746 o the Organisation Component with a Trading Role of Merchant 7748 o the Organisation Component with the Trading Role of Consumer 7750 o the Payment Component for the Payment 7752 o the Brand List Component for the Payment 7754 o the Brand Selection Component for the Brand List 7756 o the Organisation Component for the Payment Handler of the 7757 Payment 7759 o the Organisation Component (if any) for the Organisation which 7760 carried out the previous step, for example another Payment 7761 Handler 7763 o the Organisation Component for the organisation which is to 7764 carry out the next step, if any. This may be, for example, 7765 either a Delivery Handler or a Payment Handler. 7767 o the Organisation Components for any additional Organisations 7768 that the Merchant has included in the Offer Response Block 7770 o an Optional Payment Scheme Data Component, if required by the 7771 Payment Method as defined in the IOTP supplement for the 7772 payment method 7774 o any Trading Role Data Components that may be required (see 7775 section 6.15.1). 7777 7.8 Payment Exchange Block 7779 The Payment Exchange Block contains payment scheme specific data which 7780 is exchanged between two of the roles in a trade. Its definition is as 7781 follows. 7783 7784 7787 Attributes: 7789 ID An identifier which uniquely identifies the 7790 Payment Exchange Block within the IOTP 7791 Transaction. 7793 Content: 7795 PaySchemeData This Trading Component contains payment scheme 7796 specific data see section 6.9 Payment Scheme 7797 Component. 7799 7.9 Payment Response Block 7801 This Payment Response Block contains a information about the Payment 7802 Status, a Payment Receipt, and an optional payment protocol message. 7803 Its definition is as follows. 7805 7807 7810 Attributes: 7812 ID An identifier which uniquely identifies the 7813 Payment Response Block within the IOTP 7814 Transaction. 7816 Content: 7818 Status Contains status information about the business 7819 success (see section 4.2) or failure of the 7820 payment. Note that in a Pay Response Block, a 7821 ProcessState of NotYetStarted or InProgress are 7822 illegal values. 7824 PayReceipt Contains payment scheme specific data which can 7825 be used to verify the payment occurred. See 7826 section 6.10 Payment Receipt Component. 7828 PaySchemeData Contains payment scheme specific data see 7829 section, for example a payment protocol message. 7830 See 6.9 Payment Scheme Component. 7832 PaymentNote Contains additional, non payment related, 7833 information which the Payment Handler wants to 7834 provide to the Consumer. For example, if a 7835 withdrawal or deposit were being made then it 7836 could contain information on the remaining 7837 balance on the account after the transfer was 7838 complete. See section 6.11 Payment Note 7839 Component. 7841 TradingRoleData The Trading Role Data Component contains opaque 7842 data which is needs to be communicated between 7843 the Trading Roles involved in an OTP Transaction 7844 (see section 6.15). 7846 7.10 Delivery Request Block 7848 The Delivery Request Block contains details of the goods or services 7849 which are to be delivered together with a signature which can be used 7850 to check that delivery is authorised. Its definition is as follows. 7852 7854 7857 Attributes: 7859 ID An identifier which uniquely identifies the 7860 Delivery Request Block within the IOTP 7861 Transaction. 7863 Content: 7865 Status Contains the Status Components (see section 7866 6.12) of the responses of the steps (e.g. a 7867 Payment Response) on which this step is 7868 dependent. It is used to indicate the success or 7869 failure of those steps. Delivery should only 7870 occur of the previous steps were successful. 7872 Order The Order Component contains details about the 7873 goods, services or financial transaction which 7874 is taking place see section 6.4. 7876 Org The Organisation Components (see section 6.5) 7877 identify the organisations and their roles in 7878 the IOTP Transaction. The roles and 7879 organisations which must be present will depend 7880 on the particular type of IOTP Transaction. See 7881 the definition of each transaction in section 8. 7882 Internet Open Trading Protocol Transactions. 7884 Delivery The Delivery Component contains details of the 7885 delivery to be made (see section 6.12). 7887 TradingRoleData The Trading Role Data Component contains opaque 7888 data which is needs to be communicated between 7889 the Trading Roles involved in an OTP Transaction 7890 (see section 6.15). 7892 The Delivery Request Block contains: 7894 o the Organisation Component with a Trading Role of Merchant 7896 o the Organisation Component for the Consumer and DeliverTo 7897 Trading Roles 7899 o the Delivery Component for the Delivery 7901 o the Organisation Component for the Delivery Handler. 7902 Specifically the Organisation Component identified by the 7903 ActionOrgRef attribute on the Delivery Component 7905 o the Organisation Component (if any) for the Organisation which 7906 carried out the previous step, for example a Payment Handler 7908 o the Organisation Components for any additional Organisations 7909 that the Merchant has included in the Offer Response Block 7911 o any Trading Role Data Components that may be required (see 7912 section 6.15.1). 7914 7.11 Delivery Response Block 7916 The Delivery Response Block contains a Delivery Note containing 7917 details on how the goods will be delivered. Its definition is as 7918 follows. Note that in a Delivery Response Block a Delivery Status 7919 Element with a DeliveryStatusCode of NotYetStarted or InProgress is 7920 invalid. 7922 7923 7926 Attributes: 7928 ID An identifier which uniquely identifies the 7929 Delivery Response Block within the IOTP 7930 Transaction. 7932 Content: 7934 Status Contains status information about the business 7935 success (see section 4.2) or failure of the 7936 delivery. Note that in a Delivery Response 7937 Block, a ProcessState of NotYetStarted or 7938 InProgress are illegal values. 7940 DeliveryNote The Delivery Note Component contains details 7941 about how the goods or services will be 7942 delivered (see section 6.13). 7944 7.12 Inquiry Request Trading Block 7946 The Inquiry Request Trading Block contains an Inquiry Type Component 7947 and an optional Payment Scheme Component to contain payment scheme 7948 specific inquiry messages. 7950 7951 7954 Attributes: 7956 ID An identifier which uniquely identifies the 7957 Inquiry Request Trading Block within the IOTP 7958 Transaction. 7960 Content: 7962 InquiryType Inquiry Type Component (see section 6.16) that 7963 contains the type of inquiry. 7965 PaySchemeData Payment Scheme Component (see section 6.9) that 7966 contains payment scheme specific inquiry 7967 messages for inquiries on payments. This is 7968 present when the Type attribute of Inquiry Type 7969 Component is Payment. 7971 7.13 Inquiry Response Trading Block 7973 The Inquiry Response Trading Block contains a Status Component and an 7974 optional Payment Scheme Component to contain payment scheme specific 7975 inquiry messages. Its purpose is to enquire on the current status of 7976 an IOTP transaction at a server. 7978 7979 7984 Attributes: 7986 ID An identifier which uniquely identifies the 7987 Inquiry Response Trading Block within the IOTP 7988 Transaction. 7990 LastReceivedOtpMsg Contains an Element Reference (see section 3.5) 7991 Ref to the Message Id Component (see section 3.3.2) 7992 of the last message this server has received 7993 from the Consumer. If there is no previously 7994 received message from the Consumer in the 7995 pertinent transaction, this attribute should be 7996 contain the value Null. This attribute exists 7997 for debugging purposes. 7999 LastSentOtpMsgRef Contains an Element Reference (see section 3.5) 8000 to the Message Id Component (see section 3.3.2) 8001 of the last message this server has sent to the 8002 Consumer. If there is no previously sent message 8003 to the Consumer in the pertinent transaction, 8004 this attribute should contain the value Null. 8005 This attribute exists for debugging purposes. 8007 Content: 8009 Status Contains status information about the business 8010 success (see section 4.2) or failure of a 8011 certain trading exchange (i.e., Offer, Payment, 8012 or Delivery). 8014 PaySchemeData Payment Scheme Component (see section 6.9) that 8015 contains payment scheme specific inquiry 8016 messages for inquiries on payments. This is 8017 present when the Type attribute of StatusType 8018 attribute of the Status Component is set to 8019 Payment. 8021 7.14 Ping Request Block 8023 The Ping Request Block is used to determine if a Server is operating 8024 and whether or not cryptography is compatible. 8026 The definition of a Ping Request Block is as follows. 8028 8029 8032 Attributes: 8034 ID An identifier which uniquely identifies the Ping 8035 Request Trading Block within the IOTP 8036 Transaction. 8038 Content: 8040 Org Optional Organisation Components (see section 8041 6.5). 8043 If no Organisation Component is present then the 8044 Ping Request is anonymous and simply determines 8045 if the server is operating. 8047 However if Organisation Components are present, 8048 then it indicates that the sender of the Ping 8049 Request wants to verify that digital signatures 8050 can be handled. 8052 In this case the sender includes: 8053 o an Organisation Component that identifies 8054 itself specifying the Trading Role(s) it is 8055 taking in IOTP transactions (Merchant, Payment 8056 Handler, etc) 8057 o an Organisation Component that identifies the 8058 intended recipient of the message. 8060 These are then used to generate a signature over 8061 the Ping Response Block. 8063 7.15 Ping Response Block 8065 The Ping Response Trading Block provides the result of a Ping Request. 8067 It contains an Organisation Component that identifies the sender of 8068 the Ping Response. 8070 If the Ping Request to which this block is a response contained 8071 Organisation Components, then it also contains those Organisation 8072 Components. 8074 8075 8082 Attributes: 8084 ID An identifier which uniquely identifies the 8085 Ping Request Trading Block within the IOTP 8086 Transaction. 8088 PingStatusCode Contains a code which shows the status of the 8089 sender software which processes IOTP messages. 8090 Valid values are: 8091 o Ok. Everything with the service is working 8092 normally, including the signature 8093 verification. 8094 o Busy. Things are working normally but there 8095 may be some delays. 8096 o Down. The server is not functioning fully but 8097 can still provide a Ping response. 8099 SigVerifyStatusCode Contains a code which shows the status of 8100 signature verification. This is present only 8101 when the message containing the Ping Request 8102 Block also contains a Signature Block. Valid 8103 values are: 8104 o Ok. The signature has successfully been 8105 verified and proved compatible. 8106 o NotSupported The receiver of this Ping 8107 Request Block does not support validation of 8108 signatures. 8109 o Fail. Signature verification failed. 8111 Xml:lang Defines the language used in PingStatusDesc. 8112 This is present when PingStatusDesc is present. 8114 PingStatusDesc Contains a short description of the status of 8115 the server which sends this Ping Response 8116 Block. Servers, if their designers want, can 8117 use this attribute to send more refined status 8118 information than PingStatusCode which can be 8119 used for debugging purposes, for example. 8121 Content: 8123 Org These are Organisation Components (see section 8124 6.5). 8126 The Organisation Components of the sender of the 8127 Ping Response is always included in addition to 8128 the Organisation Components sent in the Ping 8129 Request. 8131 [Note] Ping Status Code values do not include a value such as Fail, 8132 since, when the software receiving the Ping Request message 8133 is not working at all, no Ping Response message will be sent 8134 back. 8135 [Note End] 8137 7.16 Signature Block 8139 The Signature Block contains one or more Signature Components and 8140 associated Certificates which sign data associated with the IOTP 8141 Transaction. For a general discussion and introduction to how IOTP 8142 uses signatures, see section 5 Security Considerations. The definition 8143 of the Signature Component and certificates is contained in the paper 8144 "Digital Signature for XML - Proposal", see [XMLDSIG]. Descriptions of 8145 how these are used by IOTP is contained in sections 6.17 and 6.18. 8147 The definition of a Signature Block is as follows: 8149 8150 8153 Attributes: 8155 ID An identifier which uniquely identifies the 8156 Signature Block within the IOTP Transaction. 8158 Content: 8160 Signature A Signature Component. See section 6.17. 8162 Certificate A Certificate Component. See section 6.18. 8164 The contents of a Signature Block depends on the Trading Block that is 8165 contained in the same IOTP Message as the Signature Block. 8167 7.16.1 Offer Response 8169 A Signature Block which is in the same message as an Offer Response 8170 Block contains just an Offer Response Signature Component (see section 8171 6.17.2). 8173 7.16.2 Payment Request 8175 A Signature Block which is in the same message as a Payment Request 8176 Block contains: 8178 o an Offer Response Signature Component (see section 6.17.2), and 8180 o if the Payment is dependent on an earlier step (as indicated by 8181 the StartAfter attribute on the Payment Component), then the 8182 Payment Receipt Signature Component (see section 6.17.3) 8183 generated by the previous step 8185 7.16.3 Payment Response 8187 A Signature Block which is in the same message as a Payment Response 8188 Block contains just a Payment Receipt Signature Component (see section 8189 6.17.3) generated by the step. 8191 7.16.4 Delivery Request 8193 A Signature Block which is in the same message as a Delivery Request 8194 Block contains: 8196 o an Offer Response Signature Component (see section 6.17.2), and 8198 o the Payment Receipt Signature Component (see section 6.17.3) 8199 generated by the previous step. 8201 7.17 Error Block 8203 The Error Trading Block contains one or more Error Components (see 8204 section 6.19) which contain information about Technical Errors (see 8205 section 4.1) in an IOTP Message which has been received by one of the 8206 Trading Roles involved in the trade. 8208 For clarity two phrases are defined which are used in the description 8209 of an Error Trading Block: 8211 o message in error. An IOTP message which contains or causes an 8212 error of some kind 8214 o message reporting the error. An IOTP message that contains an 8215 Error Trading Block that describes the error found in a message 8216 in error. 8218 An Error Trading Block may be contained in any message reporting the 8219 error. The action which then follows depends on the severity of the 8220 error. See the definition of an Error Component, for an explanation of 8221 the different types of severity and the actions which can then occur. 8223 [Note] Although, an Error Trading Block can report multiple 8224 different errors using multiple Error Components, there is 8225 no obligation on a developer of an IOTP Aware Application to 8226 do so. 8227 [Note End] 8229 The structure of an Error Trading Block is as follows. 8231 8232 8235 Attributes: 8237 ID An identifier which uniquely identifies the 8238 Error Trading Block within the IOTP Transaction. 8240 Content: 8242 ErrorComp An Error Components (see section 6.19) that 8243 contains information about an individual 8244 Technical Error. 8246 PaySchemeData An optional Payment Scheme Component (see 8247 section 6.9) which contains a Payment Scheme 8248 Message. See the appropriate payment scheme 8249 supplement to determine whether or not this 8250 component needs to be present and for the 8251 definition of what it must contain. 8253 7.18 Cancel Block 8255 The Cancel Block is used to inform a non-Consumer role such as a 8256 Merchant, Payment Handler or Delivery Handler that a transaction has 8257 been cancelled by the Consumer. It's main purpose is to allow the 8258 server to close down the transaction without a waiting for a time-out 8259 to occur. Its definition is as follows. 8261 8262 8265 Attributes: 8267 ID An identifier which uniquely identifies the 8268 Cancel Block within the IOTP Transaction. 8270 Content: 8272 Status Contains status information indicating that the 8273 IOTP transaction has been cancelled. 8275 8. Internet Open Trading Protocol Transactions 8277 The Baseline Open Trading Protocol supports four types of transactions 8278 for different purposes. These are 8280 o an Authentication IOTP transaction which supports 8281 authentication of one party in a trade by another 8283 o IOTP Transactions that involve one or more payments. 8284 Specifically: 8285 - Deposit 8286 - Purchase 8287 - Refund 8288 - Withdrawal, and 8289 - Value Exchange 8291 o IOTP Transactions designed to check the correct function of the 8292 IOTP infrastructure. Specifically: 8293 - Transaction Status Inquiry, and 8294 - Ping 8296 Although the Authentication IOTP Transaction can operate on its own, 8297 authentication can optionally precede any of the _payment_ 8298 transactions. Therefore, the rest of this section is divided into two 8299 parts covering: 8301 o Authentication and Payment transactions (Authentication, 8302 Deposit, Purchase, Refund, Withdrawal and Value Exchange) 8304 o Infrastructure Transactions (Transaction Status Inquiry and 8305 Ping) that are designed to support inquiries on whether or not 8306 a transaction has succeeded or a Trading Role's servers are 8307 operating correctly, and 8309 8.1 Authentication and Payment Related IOTP Transactions 8311 The Authentication and Payment related IOTP Transactions consist of 8312 six Document Exchanges which are then combined in sequence to 8313 implement a specific transaction. 8315 Generally, there is a close, but not exact, correspondence between a 8316 Document Exchange and a Trading Exchange. The main difference is that 8317 some Document Exchanges implement part or all of two Trading Exchanges 8318 simultaneously in order to minimise the number of actual OTP Messages 8319 which must be sent over the Internet. 8321 The six Document Exchanges are: 8323 o Authentication. This is a direct implementation of the 8324 Authentication Trading Exchange 8326 o Brand Dependent Offer. This is the Offer Trading Exchange 8327 combined with the Brand Selection part of the Payment Trading 8328 Exchange. Its purpose is to provide the Merchant with 8329 information on the Brand selected so that the content of the 8330 Offer Response may be adapted accordingly 8332 o Brand Independent Offer. This is also an Offer Trading 8333 Exchange. However, in this instance, the content of the Offer 8334 Response does depend on the Brand selected. 8336 o Payment. This is a direct implementation of the Payment part of 8337 a Payment Trading Exchange 8339 o Delivery. This is a direct implementation of the Delivery 8340 Exchange 8342 o Delivery with Payment. This is an implementation of combined 8343 Payment and Delivery Trading Exchanges 8345 These Document Exchanges are combined together in different sequences 8346 to implement each IOTP Transaction. The way in which they may be 8347 combined is illustrated by the diagram below. 8349 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 8351 START ----------------------------------------------------- 8352 | v 8353 | ---------------- 8354 | | AUTHENTICATION | 8355 | ---------------- 8356 -------------------------------------- | | 8357 | | | | 8358 | -------------- | ------------- | 8359 v v v v | 8360 ------------------- ----------------- | 8361 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 8362 | OFFER | | OFFER | | 8363 ------------------- ----------------- | 8364 | | | | | 8365 | --------------- | | | 8366 | | | | | 8367 | -------------- | -- | | 8368 v v v v | 8369 --------- -------------- | 8370 | PAYMENT | | PAYMENT WITH | | 8371 | (first) | | DELIVERY | | 8372 --------- -------------- | 8373 | | | 8374 ----------------------------- | | 8375 v v | | | 8376 ---------- --------- | | | 8377 | DELIVERY | | PAYMENT | | | | 8378 | | | {second)| | | | 8379 ---------- --------- | | | 8380 | | | | v 8381 ----------------------------------------------> STOP 8383 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8385 Figure 19 Payment and Authentication Message Flow Combinations 8387 The combinations of Document Exchanges that are valid depend on the 8388 particular IOTP transaction. 8390 The remainder of this sub-section describes: 8392 o each Document Exchange in more detail including descriptions of 8393 the content of each Trading Block in the Document Exchanges, 8394 and 8396 o descriptions of how each IOTP Transaction uses the Document 8397 Exchange to effect the desired result. 8399 [Note] The descriptions of the Document Exchanges which follow 8400 describe the ways in which various Business Errors (see 8401 section 4.2) are handled. No reference is made however to 8402 the handling of Technical Errors (see section 4.1) in any of 8403 the messages since these are handled the same way 8404 irrespective of the context in which the message is being 8405 sent. See section 4 for more details. 8406 [Note End] 8408 8.1.1 Authentication Document Exchange 8410 The Authentication Document Exchange is a direct implementation of the 8411 Authentication Trading Exchange (see section 2.2.4). It involves: 8413 o an Authenticator - the organisation which is requesting the 8414 authentication, and 8416 o an Authenticatee - the organisation being authenticated. 8418 The authentication consists of: 8420 o an Authentication Request being sent by the Authenticator to 8421 the Authenticatee, 8423 o an Authentication Response being sent in return by the 8424 Authenticatee to the Authenticator which is then checked, and 8426 o an Authentication Status being sent by the Authenticator to the 8427 Authenticatee to provide an indication of the success or 8428 failure of the authentication. 8430 An Authentication Document Exchange also: 8432 o provides an Authenticatee with an Organisation Component which 8433 describes the Authenticator, and 8435 o optionally provides the Authenticator with Organisation 8436 Components which describe the Authenticatee. 8438 The Authentication Request may also be digitally signed which allows 8439 the Authenticatee to verify the credentials of the Authenticator. 8441 The IOTP Messages which are involved are illustrated by the diagram 8442 below. 8444 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 8446 ORGANISATION 1 IOTP MESSAGE ORGANISATION 2 8447 (AUTHENTICATEE) (AUTHENTICATOR) 8448 1. First organisation 2. The second 8449 takes an action (for organisation generates 8450 example by pressing a ---------------------> an Authentication 8451 button on an HTML Authentication Need Request Block 8452 page) which requires (outside scope of containing challenge 8453 that the organisation IOTP) data and list of the 8454 is authenticated Algorithms that may be 8455 used then sends it to 8456 the first organisation 8457 | 8458 v 8459 3. IOTP aware application IotpMsg:Trans 8460 started. If a Signature Block <-------------------- Ref Block; 8461 is present the first TPO & Signature 8462 organisation may use this to Authentication Block; TPO 8463 check the credentials of the Request Block; Auth. 8464 second organisation. If it is Request Block; 8465 OK the first organisation 8466 selects an Algorithm then 8467 uses the challenge data and 8468 the authentication method 8469 selected from the 8470 Authentication Request Block 8471 to generate an Authentication 8472 Response Block and optional 8473 Organisation and Signature 8474 Components which are sent 8475 back to the second 8476 organisation for validation. 8477 | 8478 v 8479 IotpMsg: Trans 4. The second organisation 8480 Ref Block; ----------------------> checks the Authentication 8481 Signature Authentication Response Response against the 8482 Block; Auth challenge data in the 8483 Response Block; Authentication Request Block 8484 Organisation Block to check that the first 8485 | organisation is who they 8486 v appear to be, and sends an 8487 STOP Authentication Status Block 8488 to the first Organisation to 8489 indicate the Result then 8490 stops. 8492 | 8493 v 8494 5. The first organisation IotpMsg: Trans 8495 checks the Authentication <-------------------- Ref Block; 8496 Status Block and optionally Authentication Status Signature Block; 8497 keeps information on the IOTP Auth Response 8498 Transaction for record Block 8499 keeping purposes and stops. | 8500 v v 8501 STOP STOP 8503 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8505 Figure 20 Authentication Document Exchange 8507 8.1.1.1 Message Processing Guidelines 8509 On receiving a TPO & Authentication Request IOTP Message (see below), 8510 an Authenticatee may either: 8512 o generate and send an Authentication Response IOTP Message back 8513 to the Authenticator, or 8515 o indicate failure to comply with the Authentication Request by 8516 sending a Cancel Block back to the Authenticator containing a 8517 Status Component with a StatusType of Authentication a 8518 ProcessState of Failed and the CompletionCode (see section 8519 6.14.4) set to either: AutEeCancel, NoAuthData, TradRolesIncon 8520 or Unspecified. 8522 On receiving an Authentication Response IOTP Message (see below), an 8523 Authenticator should send in return, an Authentication Status IOTP 8524 Message (see below) containing a Status Block with a Status Component 8525 where the StatusType is set to Authentication, and: 8527 o the ProcessState attribute of the Status Component is set to 8528 CompletedOk which indicates a successful completion, or 8530 o the ProcessState attribute is set to Failed and the 8531 CompletionCode attribute is set to either: AutOrCancel, 8532 AuthFailed or Unspecified which indicates a failed 8533 authentication, 8535 On receiving an Authentication Status IOTP Message (see below), the 8536 Authenticatee should check the Status Component in the Status Block. 8537 If this indicates: 8539 o a successful authentication, then the Authenticatee should 8540 either: 8541 - continue with the next step in the IOTP Transaction of which the 8542 Authentication Document Exchange is part (if any), or 8543 - indicate a failure to continue with the rest of the IOTP 8544 Transaction, by sending back to the Authenticator a Cancel block 8545 containing a Status Component with a StatusType of Authentication, 8546 a ProcessState of Failed and the CompletionCode (see section 8547 6.14.4) set to AutEeCancel. 8549 o a failed authentication, then the failure should be reported to 8550 the Authenticatee and any further processing stopped. 8552 If the Authenticator receives an IOTP Message containing a Cancel 8553 block, then the Authenticatee is likely to go to the CancelNetLocn 8554 specified on the Trading Role Element in the Organisation Component 8555 for the Authenticator contained in the Authentication Request Block. 8557 8.1.1.2 TPO & Authentication Request IOTP Message 8559 Apart from a Transaction Reference Block (see section 3.3), this 8560 message consists of: 8562 o a Trading Protocol Options Block (see section 7.1) 8564 o an Authentication Request Block (see section 7.4), and 8566 o an optional Signature Block (see section 7.16). 8568 Each of these are described below. 8570 TRADING PROTOCOL OPTIONS BLOCK 8572 The Trading Protocol Options Block (see section 7.1) must contain the 8573 following Trading Components: 8575 o one Protocol Options Component (see Section 6.1) which defines 8576 the options which apply to the whole Authentication Document 8577 Exchange. 8579 o one Organisation Component (see section 6.5) which describes 8580 the Authenticator. The Trading Role on the Organisation 8581 Component should indicate the role which the Authenticator is 8582 taking in the Trade, for example a Merchant or a Consumer. 8584 AUTHENTICATION REQUEST BLOCK 8586 The Authentication Request Block (see section 7.4) must contain the 8587 following Trading Components: 8589 o one Authentication Data Component (see section 6.2), and 8591 SIGNATURE BLOCK (AUTHENTICATION REQUEST) 8593 If the Authentication Request is being digitally signed then a 8594 Signature Block must be included. It contains Digests of the following 8595 XML elements: 8597 o the Transaction Reference Block (see section 3.3) for the IOTP 8598 Message that contains information that describes the IOTP 8599 Message and IOTP Transaction 8601 o the Transaction Id Component (see section 3.3.1) which globally 8602 uniquely identifies the IOTP Transaction 8604 o the following components of the TPO Block : 8605 - the Protocol Options Component 8606 - the Organisation Component 8608 o the following components of the Authentication Request Block: 8609 - the Authentication Data Component 8611 8.1.1.3 Authentication Response IOTP Message 8613 Apart from a Transaction Reference Block (see section 3.3), this 8614 message consists of: 8616 o an Authentication Response Block (see section 7.5), and 8618 o an optional Signature Block (see section 7.16). 8620 Each of these are described below. 8622 AUTHENTICATION RESPONSE BLOCK 8624 The Authentication Response Block must contain the following Trading 8625 Component: 8627 o one Authentication Response Component (see section 6.3) 8628 o one Organisation Component for every Trading Role identified in 8629 the TradingRoleList attribute of the Authentication Data 8630 Component contained in the Authentication Request Block. 8632 SIGNATURE BLOCK (AUTHENTICATION RESPONSE) 8634 If the AuthMethod attribute of the Authentication Data Component 8635 contained in the Authentication Request Block indicates that the 8636 Authentication Response should consist of a digital signature then a 8637 Signature Block must be included in the same IOTP message that 8638 contains an Authentication Response Block. The Signature Component 8639 contains Digest Elements for the following XML elements: 8641 o the Transaction Reference Block (see section 3.3) for the IOTP 8642 Message that contains information that describes the IOTP 8643 Message and IOTP Transaction 8645 o the Transaction Id Component (see section 3.3.1) which globally 8646 uniquely identifies the IOTP Transaction 8648 o the following components of the Authentication Request Block: 8649 - the Authentication Data Component 8651 o the Organisation Components contained in the Authentication 8652 Response Block 8654 [Note] It should not be assumed that all trading roles can support 8655 the signing of data. Particularly it should not be assumed 8656 that Consumers support the signing of data. 8657 [Note End] 8659 8.1.1.4 Authentication Status IOTP Message 8661 Apart from a Transaction Reference Block (see section 3.3), this 8662 message consists of: 8664 o an Authentication Status Block (see section 7.5), and 8666 o an optional Signature Block (see section 7.16). 8668 Each of these are described below. 8670 AUTHENTICATION STATUS BLOCK 8672 The Authentication Status Block (see section 7.6) must contain the 8673 following Trading Components: 8675 o one Status Component (see section 6.14) with a ProcessState 8676 attribute set to CompletedOk. 8678 SIGNATURE BLOCK (AUTHENTICATION STATUS) 8680 If the Authentication Status Block is being digitally signed then a 8681 Signature Block must be included that contains a Signature Component 8682 with Digest elements for the following XML elements: 8684 o the Transaction Reference Block (see section 3.3) for the IOTP 8685 Message that contains information that describes the IOTP 8686 Message and IOTP Transaction 8688 o the Transaction Id Component (see section 3.3.1) which globally 8689 uniquely identifies the IOTP Transaction 8691 o the following components of the Authentication Status Block: 8692 - the Status Component (see section 6.14). 8694 [Note] If the Authentication Document Exchange is followed by an 8695 Offer Document Exchange (see section 8.1.2) then the 8696 Authentication Status Block and the Signature Block 8697 (Authentication Status) may be combined with either: 8699 o a TPO IOTP Message (see section 8.1.2.3), or 8701 o a TPO and Offer Response IOTP Message (see section 8702 8.1.2.6) 8703 [Note End] 8705 8.1.2 Offer Document Exchange 8707 The Offer Document Exchange occurs in two basic forms: 8709 o Brand Dependent Offer Exchange. Where the content of the offer, 8710 e.g. the order details, amount, delivery details, etc., are 8711 dependent on the payment brand and protocol selected by the 8712 consumer, and 8714 o Brand Independent Offer Exchange. Where the content of the 8715 offer is not dependent on the payment brand and protocol 8716 selected. 8718 Each of these types of Offer Document Exchange may be preceded by an 8719 Authentication Document Exchange (see section 8.1.1). 8721 8.1.2.1 Brand Dependent Offer Document Exchange 8723 In a Brand Dependent Offer Document Exchange the TPO Block and the 8724 Offer Response Block are sent separately by the Merchant to the 8725 Consumer, i.e.: 8727 o the Brand List Component is sent to the Consumer in a TPO 8728 Block, 8730 o the Consumer selects a Payment Brand, Payment Protocol and 8731 optionally a Currency and amount from the Brand List Component 8733 o the Consumer sends the selected brand, protocol and 8734 currency/amount back to the Merchant in a TPO Selection Block, 8735 and 8737 o the Merchant uses the information received to define the 8738 content of and then send the Offer Response Block to the 8739 Consumer. 8741 This is illustrated by the diagram below. 8743 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 8745 CONSUMER IOTP MESSAGE MERCHANT 8746 1. Consumer decides 2. Merchant decides which 8747 to trade and sends payment brand protocols , 8748 information that -------------------> curencies and amounts 8749 enables the Merchant Offer Information apply, places them in a 8750 to create an offer (outside scope of Brand List Component in a 8751 to the Merchant, IOTP) TPO Block, and sends to 8752 e.g. using HTML Consumer 8753 | 8754 v 8755 3. IOTP aware application IotpMsg:Trans 8756 started. Consumer selects the <------------------- Ref Block; TPO 8757 payment brand, payment protocol TPO Block 8758 and currency/amount to use, 8759 records selection in a Brand 8760 Selection Component, and sends 8761 back to Merchant 8762 | 8763 v 8764 IotpMsg: Trans 4. Merchant uses selected 8765 Ref Block; TPO --------------------> payment brand, payment 8766 Selection Block TPO Selection protocol, currency/amount and 8767 the offer information to 8768 create an Offer Response Block 8769 containing details about the 8770 IOTP Transaction including 8771 price, etc. optionally signs 8772 it and sends to Consumer 8773 | 8774 v 8775 5. Consumer checks Offer is OK, IotpMsg: Trans 8776 combines components from the TPO Ref Block; 8777 Block, the TPO Selection Block and <---------------- Signature 8778 the Offer Response Block to create Offer Response Block; Offer 8779 the next IOTP Message for the Response Block 8780 Transaction and sends it together 8781 with the Signature Block if present 8782 to the required Trading Role 8783 | 8784 v 8785 CONTINUED 8787 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8789 Figure 21 Brand Dependent Offer Document Exchange 8791 Note, a Consumer identifies a Brand Dependent Offer Document Exchange, 8792 by the absence of an Offer Response Block in the first IOTP Message. 8794 MESSAGE PROCESSING GUIDELINES 8796 On receiving a TPO IOTP Message (see below), the Consumer may either: 8798 o generate and send a TPO Selection IOTP Message back to the 8799 Merchant, or 8801 o indicate failure to continue with the IOTP Transaction by 8802 sending a Cancel Block back to the Merchant containing a Status 8803 Component with a StatusType of Offer, a ProcessState of Failed 8804 and the CompletionCode (see section 6.14.4) set to either: 8805 ConsCancelled or Unspecified. 8807 On receiving a TPO Selection IOTP Message (see below) the Merchant may 8808 either: 8810 o generate and send an Offer Response IOTP Message back to the 8811 Consumer, or 8813 o indicate failure to continue with the IOTP Transaction by 8814 sending a Cancel Block back to the Consumer containing a Status 8815 Component with a StatusType of Offer, a ProcessState of Failed 8816 and the CompletionCode (see section 6.14.4) set to either: 8817 MerchCancelled or Unspecified. 8819 On receiving an Offer Response IOTP Message (see below) the Consumer 8820 may either: 8822 o generate and send the next IOTP Message in the IOTP transaction 8823 and send it to the required Trading Role. This is dependent on 8824 the IOTP Transaction, or 8826 o indicate failure to continue with the IOTP Transaction by 8827 sending a Cancel Block back to the Consumer containing a Status 8828 Component with a StatusType of Offer, a ProcessState of Failed 8829 and the CompletionCode (see section 6.14.4) set to either: 8830 ConsCancelled or Unspecified. 8832 If the Merchant receives an IOTP Message containing a Cancel block, 8833 then the Consumer is likely to go to the CancelNetLocn specified on 8834 the Trading Role Element in the Organisation Component for the 8835 Merchant. 8837 If the Consumer receives an IOTP Message containing a Cancel block, 8838 then the information contained in the IOTP Message should be reported 8839 to the Consumer but no further action taken. 8841 8.1.2.2 Brand Independent Offer Document Exchange 8843 In a Brand Independent Offer Document Exchange the TPO Block and the 8844 Offer Response Block are sent together by the Merchant to the 8845 Consumer, i.e. there is one IOTP Message that contains both a TPO 8846 Block, and an Offer Response Block. 8848 The message flow is illustrated by the diagram below: 8850 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 8852 CONSUMER IOTP MESSAGE MERCHANT 8853 1. Consumer 2. Merchant decides which 8854 decides to payment brand, protocols , 8855 trade and sends --------------------> currencies and amounts apply, 8856 information Offer Information places them in a Brand List 8857 that enables (outside scope of Component in a TPO Block, 8858 the Merchant to IOTP) creates an Offer Response 8859 create an offer Block containing details about 8860 to the the IOTP Transaction including 8861 Merchant, e.g. price, etc, optionally signs 8862 using HTML it and sends to Consumer 8863 | 8864 v 8865 3. IOTP aware application IotpMsg: Trans Ref 8866 started. Consumer selects the <------------- Block; Signature 8867 payment brand and payment TPO & Block; TPO Block; 8868 protocol to use, records Offer Response Offer Response Block 8869 selection in a Brand Selection 8870 Component, checks Offer is OK, 8871 combines the Brand Selection 8872 Component with information from 8873 the TPO Block and Offer Response 8874 Block to create the next IOTP 8875 Message for the Transaction and 8876 sends it together with the 8877 Signature Block if present to 8878 the required Trading Role 8879 | 8880 v 8881 CONTINUED 8883 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8885 Figure 22 Brand Independent Offer Exchange 8887 Note that a Brand Independent Offer Document Exchange always occurs 8888 when only one payment brand, protocol and currency/amount is being 8889 offered to the Consumer by the Merchant. It is also likely to, but 8890 will not necessarily, occur when multiple brands are being offered, 8891 the Payment Handler is the same, and all brands use the same set of 8892 protocols. 8894 Note that the TPO Block and the Offer Response Block can be sent in 8895 separate IOTP messages (see Brand Dependent Offer Document Exchange) 8896 even if the Offer Response Block does not change. However this 8897 increases the number of messages in the transaction and is therefore 8898 likely to increase transaction response times. 8900 IOTP aware applications supporting the Consumer Trading Role must 8901 check for the existence of an Offer Response Block in the first IOTP 8902 Message to determine whether the Offer Document Exchange is brand 8903 dependent or not. 8905 MESSAGE PROCESSING GUIDELINES 8907 On receiving a TPO and Offer Response IOTP Message (see below), the 8908 Consumer may either: 8910 o generate and send the next IOTP Message in the IOTP transaction 8911 and send it to the required Trading Role. This is dependent on 8912 the IOTP Transaction, or 8914 o indicate failure to continue with the IOTP Transaction by 8915 sending a Cancel Block back to the Merchant containing a Status 8916 Component with a StatusType of Offer, a ProcessState of Failed 8917 and the CompletionCode (see section 6.14.1) set to either: 8918 ConsCancelled or Unspecified. 8920 If the Merchant receives an IOTP Message containing a Cancel block, 8921 then the Consumer is likely to go to the CancelNetLocn specified on 8922 the Trading Role Element in the Organisation Component for the 8923 Merchant. 8925 8.1.2.3 TPO IOTP Message 8927 The TPO IOTP Message is only used with a Brand Dependent Offer 8928 Document Exchange. Apart from a Transaction Reference Block (see 8929 section 3.3), this message consists of just a Trading Protocol Options 8930 Block (see section 7.1) which is described below. 8932 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8934 The Trading Protocol Options Block must contain the following Trading 8935 Components: 8937 o one Protocol Options Component which defines the options which 8938 apply to the whole IOTP Transaction. See Section 6.1. 8940 o one Brand List Component (see section 6.6) for each Payment in 8941 the IOTP Transaction that contain one or more payment brands 8942 and protocols which may be selected for use in each payment 8944 o Organisation Components (see section 6.5) with the following 8945 roles: 8946 - Merchant who is making the offer 8947 - Consumer who is carrying out the transaction 8948 - the PaymentHandler(s) for the payment. The "ID" of the Payment 8949 Handler Organisation Component is contained within the PhOrgRef 8950 attribute of the Payment Component 8952 If the IOTP Transaction includes a Delivery then the TPO Block must 8953 also contain: 8955 o Organisation Components with the following roles: 8956 - DeliveryHandler who will be delivering the goods or services 8957 - DelivTo i.e. the person or organisation which is to take delivery 8959 AUTHENTICATION STATUS AND SIGNATURE BLOCKS 8961 If the Offer Document Exchange was preceded by an Authentication 8962 Document Exchange, then the TPO IOTP Message may also contain: 8964 o an Authentication Status Block (see section 7.6), and 8966 o an optional Signature Block (Authentication Status) Signature 8967 Block 8969 See section 8.1.1.4 Authentication Status IOTP Message for more 8970 details. 8972 8.1.2.4 TPO Selection IOTP Message 8974 The TPO Selection IOTP Message is only used with a Brand Dependent 8975 Offer Document Exchange. Apart from a Transaction Reference Block (see 8976 section 3.3), this message consists of just a TPO Selection Block (see 8977 section 7.1) which is described below. 8979 TPO SELECTION BLOCK 8981 The TPO Selection Block (see section 7.2) contains: 8983 o one Brand Selection Component (see section 6.7) for use in a 8984 later Payment Exchange. It contains the results of the consumer 8985 selecting a Payment Brand, Payment Protocol and currency/amount 8986 from the list provided in the Brand List Component. 8988 8.1.2.5 Offer Response IOTP Message 8990 The Offer Response IOTP Message is only used with a Brand Dependent 8991 Offer Document Exchange. Apart from a Transaction Reference Block (see 8992 section 3.3), this message consists of: 8994 o an Offer Response Block (see section 7.1) and 8996 o an optional Signature Block (see section 7.16). 8998 OFFER RESPONSE BLOCK 9000 The Offer Response Block (see section 7.3) contains the following 9001 components: 9003 o one Status Component (see section 6.14) which indicates the 9004 status of the Offer Response. The ProcessState attribute should 9005 be set to CompletedOk 9007 o one Order Component (see section 6.4) which contains details 9008 about the goods and services which are being purchased or the 9009 financial transaction which is taking place 9011 o one or more Payment Component(s) (see section 6.8) for each 9012 payment which is to be made 9014 o zero or one Delivery Components (see section 6.12) containing 9015 details of the delivery to be made if the IOTP Transaction 9016 includes a delivery 9018 o zero or more Trading Role Data Components (see section 6.15) if 9019 required by the Merchant. 9021 SIGNATURE BLOCK (OFFER RESPONSE) 9023 If the Authentication Status Block is being digitally signed then a 9024 Signature Block must be included that contains a Signature Component 9025 (see section 6.17) with Digest Elements for the following XML 9026 elements: 9028 If the Offer Response is being digitally signed then a Signature Block 9029 must be included that contains a Signature Component (see section 9030 6.17) with Digest Elements for the following XML elements: 9032 o the Transaction Reference Block (see section 3.3) for the IOTP 9033 Message that contains information that describes the IOTP 9034 Message and IOTP Transaction 9036 o the Transaction Id Component (see section 3.3.1) which globally 9037 uniquely identifies the IOTP Transaction 9039 o the following components of the TPO Block : 9040 - the Protocol Options Component, and 9041 - the Brand List Component 9042 - all the Organisation Components present 9044 o the following components of the Offer Response Block: 9045 - the Order Component 9046 - all the Payment Components present 9047 - the Delivery Component if present 9048 - any Trading Role Data Components present 9050 8.1.2.6 TPO and Offer Response IOTP Message 9052 The TPO and Offer Response IOTP Message is only used with a Brand 9053 Independent Offer Document Exchange. Apart from a Transaction 9054 Reference Block (see section 3.3), this message consists of: 9056 o a Trading Protocol Options Block (see section 7.1) 9058 o an Offer Response Block (see section 7.1) and 9060 o an optional Signature Block (see section 7.16). 9062 TPO (TRADING PROTOCOL OPTIONS) BLOCK 9064 This is the same as the Trading Protocol Options Block described in 9065 TPO IOTP Message (see section 8.1.2.3). 9067 OFFER RESPONSE BLOCK 9069 This the same as the Offer Response Block in the Offer Response IOTP 9070 Message (see section 8.1.2.5). 9072 AUTHENTICATION STATUS 9074 If the Offer Document Exchange was preceded by an Authentication 9075 Document Exchange, then the TPO and Offer Response IOTP Message may 9076 also contain an Authentication Status Block (see section 7.6). 9078 SIGNATURE BLOCK 9080 This is the same as the Signature Block in the Offer Response IOTP 9081 Message (see section 8.1.2.5) with the addition that: 9083 o if the Offer Document Exchange is Brand Dependent then the 9084 Signature Component in the Signature Block additionally 9085 contains a Digest Element for the Brand Selection Component 9086 contained in the TPO Selection Block 9088 o if the Offer Document Exchange was preceded by an 9089 Authentication Document Exchange then the Signature Component 9090 in the Signature Block additionally contains a Digest Element 9091 for the Authentication Status Block. 9093 8.1.3 Payment Document Exchange 9095 The Payment Document Exchange is a direct implementation of the last 9096 part of a Payment Trading Exchange (see section 2.2.2) after the Brand 9097 has been selected by the Consumer. A Payment Exchange consists of: 9099 o the Consumer requesting that a payment starts by generating 9100 Payment Request IOTP Message using information from previous 9101 IOTP Messages in the Transaction and then sending it to the 9102 Payment Handler 9104 o the Payment Handler and the Consumer then swapping Payment 9105 Exchange IOTP Messages encapsulating payment protocol messages 9106 until the payment is complete, and finally 9108 o the Payment Handler sending a Payment Response IOTP Message to 9109 the Consumer containing a receipt for the payment. 9111 The IOTP Messages which are involved are illustrated by the diagram 9112 below. 9113 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9115 CONSUMER IOTP MESSAGE PAYMENT HANDLER 9116 1. Consumer generates Pay Request 9117 Block encapsulating a payment 9118 protocol message if required and 9119 sends to Payment Handler with the 9120 Signature Block if present 9121 | 9122 v 9123 IotpMsg: Trans 2. Payment Handler processes Pay 9124 Ref Block; -------------> Request Block, checks optional 9125 Signature Block; Payment signature and starts exchanging 9126 ay Request Block Request payment protocol messages, 9127 encapsulated in a Pay Exchange 9128 Block, with the Consumer 9129 | 9130 v 9131 Consumer keeps <- ----->IotpMsg: IotpMsg: Trans 9132 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 9133 xchange Blocks with Block; Pay Payment Exchange Exchange Block 9134 Payment Handler Exchange Block 9135 | 9136 v 9137 4. Eventually payment protocol 9138 messages finish so Payment Handler 9139 creates Pay Receipt Component inside 9140 a Pay Response Block, and an 9141 optional Signature Component inside 9142 the Signature Block, sends to 9143 Consumer and stops 9144 | 9145 v 9146 5. Consumer checks Pay Response is IotpMsg: Trans 9147 OK. Optionally keeps information on <--------------- Ref Block; 9148 OTP Transaction for record keeping Payment Response Signature Block 9149 purposes and either stops or Pay Response 9150 creates the next IOTP Message for Block 9151 the Transaction and sends it 9152 together with the Signature Block 9153 if present to the required Trading 9154 Role 9156 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9157 Figure 23 Payment Document Exchange 9159 8.1.3.1 Message Processing Guidelines 9161 On receiving a Payment Request IOTP Message, the Payment Handler 9162 should check that they are authorised to carry out the Payment (see 9163 section 5 Security Considerations). They may then either: 9165 o generate and send a Payment Exchange IOTP Message back to the 9166 Consumer, if more payment protocol messages need to be 9167 exchanged, or 9169 o generate and send a Payment Response IOTP Message if the 9170 exchange of payment protocol messages is complete, or 9172 o indicate failure to continue with the Payment by sending a 9173 Cancel Block back to the Consumer containing a Status Component 9174 with a StatusType of Payment, a ProcessState of Failed and the 9175 CompletionCode (see section 6.14.4) set to either: 9176 BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, 9177 InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument or 9178 Unspecified. 9180 On receiving a Payment Exchange IOTP Message, the Consumer may either: 9182 o generate and send a Payment Exchange Message back to the 9183 Payment Handler or 9185 o indicate failure to continue with the Payment by sending a 9186 Cancel Block back to the Payment Handler containing a Status 9187 Component with a StatusType of Payment, a ProcessState of 9188 Failed and the CompletionCode (see section 6.14.2) set to 9189 either: ConsCancelled or Unspecified. 9191 On receiving a Payment Exchange IOTP Message, the Payment Handler may 9192 either: 9194 o generate and send a Payment Exchange IOTP Message back to the 9195 Consumer, if more payment protocol messages need to be 9196 exchanged, or 9198 o generate and send a Payment Response IOTP Message if the 9199 exchange of payment protocol messages is complete, or 9201 o indicate failure to continue with the Payment by sending a 9202 Cancel Block back to the Consumer containing a Status Component 9203 with a StatusType of Payment, a ProcessState of Failed and the 9204 CompletionCode (see section 6.14.2) set to either: 9205 PaymtCancelled or Unspecified. 9207 On receiving a Payment Response IOTP Message, the Consumer may either: 9209 o generate and send the next IOTP Message in the IOTP transaction 9210 and send it to the required Trading Role. This is dependent on 9211 the IOTP Transaction, 9213 o stop, since the IOTP Transaction has ended, or 9215 o indicate failure to continue with the IOTP Transaction by 9216 sending a Cancel Block back to the Merchant containing a Status 9217 Component with a StatusType of Payment, a ProcessState of 9218 Failed and the CompletionCode (see section 6.14.1) set to 9219 either: ConsCancelled or Unspecified. 9221 If the Consumer receives an IOTP Message containing a Cancel block, 9222 then the information contained in the IOTP Message should be reported 9223 to the Consumer but no further action taken. 9225 If the Payment Handler receives an IOTP Message containing a Cancel 9226 block, then the Consumer is likely to go to the CancelNetLocn 9227 specified on the Trading Role Element in the Organisation Component 9228 for the Payment Handler from which any further action may take place. 9230 If the Merchant receives an IOTP Message containing a Cancel block, 9231 then the Consumer should have completed the payment but not continuing 9232 with the transaction for some reason. In this case the Consumer is 9233 likely to go to the CancelNetLocn specified on the Trading Role 9234 Element in the Organisation Component for the Merchant from which any 9235 further action may take place. 9237 8.1.3.2 Payment Request IOTP Message 9239 Apart from a Transaction Reference Block (see section 3.3), this 9240 message consists of: 9242 o a Payment Request Block, and 9244 o an optional Signature Block 9246 PAYMENT REQUEST BLOCK 9248 The Payment Request Block (see section 7.7) contains: 9250 o the following components copied from the Offer Response Block 9251 from the preceding Offer Document Exchange: 9252 - the Status Component 9253 - the Payment Component for the payment which is being carried out 9254 - the Organisation Components with the roles of Merchant and for the 9255 PaymentHandler that is being sent the Payment Request Block 9257 o the following component from the TPO Block: 9258 - the Brand List Component for the payment, i.e. the Brand List 9259 referred to by the BrandListRef attribute on the Payment Component 9261 o one Brand Selection Component for the Brand List, i.e. the 9262 Brand Selection Component where BrandListRef attribute points 9263 to the Brand List. This component can be either: 9264 - copied from the TPO Selection Block if the payment was preceded by 9265 a Brand Dependent Offer Document Exchange (see section 8.1.2.1), 9266 or 9267 - created by the Consumer, containing the payment brand, payment 9268 protocol and currency/amount selected from the Brand List, if the 9269 payment was preceded by a Brand Independent Offer Document 9270 Exchange (see section 8.1.2.2) 9272 o an optional Payment Scheme Component (see section 6.9) if 9273 required by the payment method used (see the Payment Method 9274 supplement to determine if this is needed). 9276 o zero or more Trading Role Data Components (see section 6.15). 9278 Note that: 9280 o if there is more than one Payment Components in an Offer 9281 Response Block, then the second payment is the one within the 9282 Offer Response Block that contains a StartAfter attribute (see 9283 section 6.8) that identifies the Payment Component for the 9284 first payment 9286 o the Payment Handler to include is identified by the Brand 9287 Selection Component (see section 6.7) for the payment. Also see 9288 section 5.3.1 Check the Action Request was sent to the Correct 9289 Organisation for an explanation on how Payment Handlers are 9290 identified 9292 o the Brand List Component to include is the one identified by 9293 the BrandListRef attribute of the Payment Component for the 9294 identified payment 9296 o the Brand Selection Component to include from the Offer 9297 Response Block is the one that contains an BrandListRef 9298 attribute (see section 3.5) which identifies the Brand List 9299 Component for the second payment. 9301 SIGNATURE BLOCK (PAYMENT REQUEST) 9303 If the either the preceding Offer Document Exchange included an Offer 9304 Response Signature (see section 8.1.2.5 Offer Response IOTP Message), 9305 or a preceding Payment Exchange included a Payment Response Signature 9306 (see section 8.1.3.4 Payment Response IOTP Message) then they should 9307 both be copied to the Signature Block in the Payment Request IOTP 9308 Message. 9310 8.1.3.3 Payment Exchange IOTP Message 9312 Apart from a Transaction Reference Block (see section 3.3), this 9313 message consists of just a Payment Exchange Block. 9315 PAYMENT EXCHANGE BLOCK 9317 The Payment Exchange Block (see section 7.8) contains: 9319 o one Payment Scheme Component (see section 6.9) which contains 9320 payment method specific data. See the Payment Method supplement 9321 for the payment method being used to determine what this should 9322 contain. 9324 8.1.3.4 Payment Response IOTP Message 9326 Apart from a Transaction Reference Block (see section 3.3), this 9327 message consists of: 9329 o a Payment Response Block, and 9331 o an optional Signature Block 9333 PAYMENT RESPONSE BLOCK 9335 The Payment Response Block (see section 7.9) contains: 9337 o one Payment Receipt Component (see section 6.10) which contains 9338 scheme specific data which can be used to verify the payment 9339 occurred 9341 o one Payment Scheme Component (see section 6.9) if required 9342 which contains payment method specific data. See the Payment 9343 Method supplement for the payment method being used to 9344 determine what this should contain 9346 o an optional Payment Note Component (see section 6.11) 9348 o zero or more Trading Role Data Components (see section 6.15). 9350 SIGNATURE BLOCK (PAYMENT RESPONSE) 9352 If a signed Payment Receipt is being provided, indicated by the 9353 SignedPayReceipt attribute of the Payment Component being set to True, 9354 then the Signature Block should contain a Signature Component which 9355 contains Digest Elements for the following: 9357 o the Transaction Reference Block (see section 3.3) for the IOTP 9358 Message which contains the first usage of the Payment Response 9359 Block, 9361 o the Transaction Id Component (see section 3.3.1) within the 9362 Transaction Reference Block that globally uniquely identifies 9363 the IOTP Transaction, 9365 o the Payment Receipt Component from the Payment Response Block, 9367 o the other Components referenced by the PayReceiptRefs attribute 9368 (if present) of the Payment Receipt Component, 9370 o the Status Component from the Payment Response Block, 9372 o any Trading Role Data Components in the Payment Response Block, 9373 and 9375 o all the Signature Components contained in the Payment Request 9376 Block if present. 9378 8.1.4 Delivery Document Exchange 9380 The Delivery Document Exchange is a direct implementation of a 9381 Delivery Trading Exchange (see section 2.2.3). It consists of: 9383 o the Consumer requesting a Delivery by generating Delivery 9384 Request IOTP Message using information from previous IOTP 9385 Messages in the Transaction and then sending it to the Delivery 9386 Handler 9388 o the Delivery Handler sending a Delivery Response IOTP Message 9389 to the Consumer containing details about the Handler's response 9390 to the request together with an optional signature. 9392 The message flow is illustrated by the diagram below. 9393 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9395 CONSUMER IOTP MESSAGE DELIVERY HANDLER 9396 1. Consumer generates 2. Delivery Handler 9397 Delivery Request checks the Status and 9398 Block and sends it to ---------------------> Order Components in the 9399 the Delivery Handler Delivery Request Delivery Request and 9400 with the Signature the optional 9401 Block if present Signatures, creates a 9402 Delivery Response 9403 Block, sends to 9404 Consumer and stops 9405 | 9406 v 9407 3. Consumer checks Delivery IotpMsg:Trans 9408 Response Block is OK, <-------------------- Ref Block; 9409 optionally keeps information Delivery Response Delivery 9410 on IOTP Transaction for Response Block 9411 record keeping purposes and 9412 stops 9414 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9416 Figure 24 Delivery Document Exchange 9418 8.1.4.1 Message Processing Guidelines 9420 On receiving a Delivery Request IOTP Message, the Delivery Handler 9421 should check that they are authorised to carry out the Delivery (see 9422 section 5 Security Considerations). They may then either: 9424 o generate and send a Delivery Response IOTP Message to the 9425 Consumer, or 9427 o indicate failure to continue with the Delivery by sending a 9428 Cancel Block back to the Consumer containing a Status Component 9429 with a StatusType of Delivery, a ProcessState of Failed and the 9430 CompletionCode (see section 6.14.4) set to either: 9431 DelivCanceled, or Unspecified. 9433 On receiving a Delivery Response IOTP Message, the Consumer should 9434 just stop since the IOTP Transaction is complete. 9436 If the Consumer receives an IOTP Message containing a Cancel block, 9437 then the information contained in the IOTP Message should be reported 9438 to the Consumer but no further action taken. 9440 8.1.4.2 Delivery Request IOTP Message 9442 The Delivery Request IOTP Message consists of: 9444 o a Delivery Request Block, and 9446 o an optional Signature Block 9448 DELIVERY REQUEST BLOCK 9450 The Delivery Request Block (see section 7.10) contains: 9452 o the following components copied from the Offer Response Block: 9453 - the Status Component (see section 6.14) 9454 - the Order Component (see section 6.4) 9455 - the Organisation Component (see section 6.5) with the roles of: 9456 Merchant, DeliveryHandler and DeliverTo 9457 - the Delivery Component (see section 6.12) 9459 o the following Component from the Payment Response Block: 9460 - the Status Component (see section 6.14). 9462 o zero or more Trading Role Data Components (see section 6.15). 9464 SIGNATURE BLOCK (DELIVERY REQUEST) 9466 If the preceding Offer Document Exchange included an Offer Response 9467 Signature or the Payment Document Exchange included a Payment Response 9468 Signature, then they should both be copied to the Signature Block. 9470 8.1.4.3 Delivery Response IOTP Message 9472 The Delivery Response IOTP Message contains a Delivery Response Block 9473 and an options Signature Block. 9475 DELIVERY RESPONSE BLOCK 9477 The Delivery Response Block contains: 9479 o one Delivery Note Component (see section 6.13) which contains 9480 delivery instructions about the delivery of goods or services 9482 SIGNATURE BLOCK (DELIVERY RESPONSE) 9484 The Signature Block should contain one Signature Component that 9485 contains Digest elements that refer to 9487 o the Transaction Id Component (see section 3.3.1) of the IOTP 9488 message that contains the Delivery Response Signature 9490 o the Transaction Reference Block (see section 3.3) of the IOTP 9491 Message that contains the Delivery Response Signature 9493 o the Signature Components contained in the Delivery Request (if 9494 any) 9496 o the Status Component 9498 o the Delivery Note Component 9500 8.1.5 Payment and Delivery Document Exchange 9502 The Payment and Delivery Document Exchange is a combination of the 9503 last part of the Payment Trading Exchange (see section 2.2.2) and a 9504 Delivery Trading Exchange (see section 2.2.3). It consists of: 9506 o the Consumer requesting that a payment starts by generating 9507 Payment Request IOTP Message using information from previous 9508 IOTP Messages in the Transaction and then sending it to the 9509 Payment Handler 9511 o the Payment Handler and the Consumer then swapping Payment 9512 Exchange IOTP Messages encapsulating payment protocol messages 9513 until the payment is complete, and finally 9515 o the Payment Handler sending to the Consumer in one IOTP 9516 Message: 9517 - a Payment Response Block containing a receipt for the payment, and 9518 - a Delivery Response Block containing details of the goods or 9519 services to be delivered 9521 The IOTP Messages which are involved are illustrated by the diagram 9522 below. 9524 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9526 CONSUMER IOTP MESSAGE MERCHANT 9527 1. Consumer generates Pay Request 9528 Block encapsulating a payment 9529 protocol message if required and 9530 sends to Payment Handler with the 9531 Signature Block if present 9532 | 9533 v 9534 IotpMsg: Trans 2. Payment Handler processes Pay 9535 Ref Block; -------------> Request Block, checks optional 9536 Signature Block; Payment signature and starts exchanging 9537 ay Request Block Request payment protocol messages, 9538 encapsulated in a Pay Exchange 9539 Block, with the Consumer 9540 | 9541 v 9542 Consumer keeps <------->IotpMsg: IotpMsg: Trans 9543 on exchanging Pay Trans Ref <-----------------> Ref Block; Pay 9544 Exchange Blocks with Block; Pay Payment Exchange Exchange Block 9545 Payment Handler Exchange Block 9546 | 9547 v 9548 4. Eventually payment protocol 9549 messages finish so Payment Handler 9550 creates Pay Receipt Component inside 9551 a Pay Response Block and an optional 9552 Signature Component, then uses 9553 information from the Offer Response 9554 Block to create a Delivery Response 9555 Block, sends both to Consumer and 9556 stops 9557 | 9558 v 9559 5. Consumer checks Pay Response IotpMsg: Trans 9560 and Delivery Response Blocks are <--------------- Ref Block; 9561 OK, optionally keeps information Payment Response Signature Block 9562 on IOTP Transaction for record & Delivery Pay Response 9563 keeping purposes and stops Response Block; Delivery 9564 Response Block 9566 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9568 Figure 25 Payment and Delivery Document Exchange 9570 The Delivery Response Block and the Payment Response Block may be 9571 combined into the same IOTP Message only if the Payment Handler has 9572 the information available so that she can send the Delivery Response 9573 Block. This is likely to, but will not necessarily, occur when the 9574 Merchant, the Payment Handler and the Delivery Handler Roles are 9575 combined. 9577 The DelivAndPayResp attribute of the Delivery Component (see section 9578 6.12) contained within the Offer Response Block (see section 7.3) is 9579 set to True if the Delivery Response Block and the Payment Response 9580 Block are combined into the same IOTP Message and is set to False if 9581 the Delivery Response Block and the Payment Response Block are sent in 9582 separate IOTP Messages. 9584 8.1.5.1 Message Processing Guidelines 9586 On receiving a Payment Request IOTP Message or a Payment Exchange IOTP 9587 Message, the Payment Handler should carry out the same actions as for 9588 a Payment Document Exchange (see section 8.1.3.1). 9590 On receiving a Payment Exchange IOTP Message, the Consumer should also 9591 carry out the same actions as for a Payment Document Exchange (see 9592 section 8.1.3.1). 9594 On receiving a Payment Response and Delivery Response IOTP Message 9595 then the IOTP Transaction is complete and should take no further 9596 action. 9598 If the Consumer receives an IOTP Message containing a Cancel block, 9599 then the information contained in the IOTP Message should be reported 9600 to the Consumer but no further action taken. 9602 If the Payment Handler receives an IOTP Message containing a Cancel 9603 block, then the Consumer is likely to go to the CancelNetLocn 9604 specified on the Trading Role Element in the Organisation Component 9605 for the Payment Handler from which any further action may take place. 9607 If the Merchant receives an IOTP Message containing a Cancel block, 9608 then the Consumer should have completed the payment but not continuing 9609 with the transaction for some reason. In this case the Consumer is 9610 likely to go to the CancelNetLocn specified on the Trading Role 9611 Element in the Organisation Component for the Merchant from which any 9612 further action may take place. 9614 8.1.5.2 Payment Request IOTP Message 9616 The content of this message is the same as for a Payment Request IOTP 9617 Message in a Payment Document Exchange (see section 8.1.3.2) 9619 8.1.5.3 Payment Exchange IOTP Message 9621 The content of this message is the same as for a Payment Exchange IOTP 9622 Message in a Payment Document Exchange (see section 8.1.3.3). 9624 8.1.5.4 Payment Response and Delivery Response IOTP Message 9626 The content of this message consists of: 9628 o a Payment Response Block, 9630 o an optional Signature Block (Payment Response), and 9632 o a Delivery Response Block. 9634 PAYMENT RESPONSE BLOCK 9636 The content of this block is the same as the Payment Response Block in 9637 the Payment Response IOTP Message associated with a Payment Document 9638 Exchange (see section 8.1.3.4). 9640 SIGNATURE BLOCK (PAYMENT RESPONSE) 9642 The content of this block is the same as the Signature Block (Payment 9643 Response) in the Payment Response IOTP Message associated with a 9644 Payment Document Exchange (see section 8.1.3.4). 9646 DELIVERY RESPONSE BLOCK 9648 The content of this block is the same as the Delivery Response Block 9649 in the Delivery Response IOTP Message associated with a Delivery 9650 Document Exchange (see section 8.1.4.3). 9652 8.1.6 Baseline Authentication IOTP Transaction 9654 A Baseline Authentication IOTP Transaction may occur at any time 9655 between any of the Trading Roles involved in OTP Transactions. This 9656 means it could occur: 9658 o before another IOTP Transaction 9659 o at the same time as another IOTP Transaction 9661 o independently of any other IOTP Transaction. 9663 The Baseline Authentication IOTP Transaction consists of just an 9664 Authentication Document Exchange (see section 8.1.1) as illustrated by 9665 the diagram below. 9666 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9668 START ------------------------------------------------------- 9669 v 9670 ---------------- 9671 | AUTHENTICATION | 9672 ---------------- 9673 | 9674 | 9675 | 9676 | 9677 ------------------- ----------------- | 9678 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9679 | OFFER | | OFFER | | 9680 ------------------- ----------------- | 9681 | 9682 | 9683 | 9684 | 9685 | 9686 --------- -------------- | 9687 | PAYMENT | | PAYMENT WITH | | 9688 | (first) | | DELIVERY | | 9689 --------- -------------- | 9690 | 9691 | 9692 | 9693 ---------- --------- | 9694 | DELIVERY | | PAYMENT | | 9695 | | | {second)| | 9696 ---------- --------- | 9697 v 9698 STOP 9700 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9702 Figure 26 Baseline Authentication IOTP Transaction 9704 Example uses of the Baseline Authentication IOTP Transaction include: 9706 o when the Baseline Authentication IOTP Transaction takes place 9707 as an early part of a session where strong continuity exists. 9708 For example, a Financial Institution could: 9709 - set up a secure channel (e.g. using SSL) with a customer 9710 - authenticate the customer using the Baseline Authentication IOTP 9711 Transaction, and then 9712 - provide the customer with access to account information and other 9713 services with the confidence that they are communicating with a 9714 bona fide customer. 9716 o as a means of providing a Merchant role with Organisation 9717 Components that contain information about Consumer and DelivTo 9718 Trading Roles 9720 o so that a Consumer may authenticate a Payment Handler before 9721 starting a payment. 9723 8.1.7 Baseline Deposit IOTP Transaction 9725 The Baseline Deposit IOTP Transaction supports the deposit of 9726 electronic cash with a Financial Institution. 9728 [Note] The Financial Institution has, in IOTP terminology, a role 9729 of merchant in that a service (i.e. a deposit of electronic 9730 cash) is being offered in return for a fee, for example bank 9731 charges of some kind. The term "Financial Institution" is 9732 used in the diagrams and in the text for clarity. 9733 [Note End] 9735 The Baseline Deposit IOTP Transaction consists of the following 9736 Document Exchanges: 9738 o an optional Authentication Document Exchange (see section 9739 8.1.1) 9741 o an Offer Document Exchange (see section 8.1.2), and 9743 o a Payment Document Exchange (see section 8.1.3). 9745 The way in which these Document Exchanges may be combined together is 9746 illustrated by the diagram below. 9748 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9750 START ----------------------------------------------------- 9751 | v 9752 | ---------------- 9753 | | AUTHENTICATION | 9754 | ---------------- 9755 -------------------------------------- | 9756 | | | 9757 | -------------- | ------------- 9758 v v v v 9759 ------------------- ----------------- 9760 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9761 | OFFER | | OFFER | 9762 ------------------- ----------------- 9763 | | 9764 | | 9765 | | 9766 | ------------------- 9767 v v 9768 --------- -------------- 9769 | PAYMENT | | PAYMENT WITH | 9770 | (first) | | DELIVERY | 9771 --------- -------------- 9772 | 9773 ---------------- 9774 | 9775 ---------- --------- | 9776 | DELIVERY | | PAYMENT | | 9777 | | | {second)| | 9778 ---------- --------- | 9779 | 9780 -----------------> STOP 9782 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9784 Figure 27 Baseline Deposit IOTP Transaction 9786 See section 8.1.12 _Valid Combinations of Document Exchanges_ to 9787 determine which combination of document exchanges apply to a 9788 particular instance of an IOTP Transaction 9790 Note that: 9792 o a Merchant (Financial Institution) may be able to accept a 9793 deposit in several different types of electronic cash although, 9794 since the Consumer role that is depositing the electronic cash 9795 usually knows what type of cash they want to deposit, it is 9796 usually constrained in practice to only one type. However, 9797 there may be several different protocols which may be used for 9798 the same "brand" of electronic cash. In this case a Brand 9799 Dependent Offer may be appropriate to negotiate the protocol to 9800 be used. 9802 o the Merchant (Financial Institution) may use the results of the 9803 authentication to identify not only the consumer but also the 9804 account to which the payment is to be deposited. If no single 9805 account can be identified, then it must be obtained by other 9806 means. For example: 9807 - the consumer could specify the account number prior to the 9808 Baseline Deposit IOTP Transaction starting, or 9809 - the consumer could have been identified earlier, for example using 9810 a Baseline Authentication IOTP Transaction, and an account 9811 selected from a list provided by the Financial Institution. 9813 o The Baseline Deposit IOTP Transaction without an Authentication 9814 Document Exchange might be used: 9815 - if a previous IOTP transaction, for example a Baseline Withdrawal 9816 or a Baseline Authentication, authenticated the consumer, and a 9817 secure channel has been maintained, therefore the authenticity of 9818 the consumer is known 9819 - if authentication is achieved as part of a proprietary payment 9820 protocol and is therefore included in the Payment Document 9821 Exchange 9822 - if authentication of the consumer has been achieved by some other 9823 means outside of the scope of IOTP, for example, by using a pass 9824 phrase, or a proprietary banking software solution. 9826 8.1.8 Baseline Purchase IOTP Transaction 9828 The Baseline Purchase IOTP Transaction supports the purchase of goods 9829 or services using any payment method. It consists of the following 9830 Document Exchanges: 9832 o an optional Authentication Document Exchange (see section 9833 8.1.1) 9835 o an Offer Document Exchange (see section 8.1.2) 9837 o either: 9838 - a Payment Document Exchange (see section 8.1.3) followed by 9839 - a Delivery Document Exchange (see section 8.1.4) 9841 o a Payment Document Exchange only, or 9843 o a combined Payment and Delivery Document Exchange (see section 9844 8.1.5). 9846 The ways in which these Document Exchanges are combined is illustrated 9847 by the diagram below. 9848 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9850 START ----------------------------------------------------- 9851 | v 9852 | ---------------- 9853 | | AUTHENTICATION | 9854 | ---------------- 9855 -------------------------------------- | | 9856 | | | | 9857 | -------------- | ------------- | 9858 v v v v | 9859 ------------------- ----------------- | 9860 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9861 | OFFER | | OFFER | | 9862 ------------------- ----------------- | 9863 | | | | | 9864 | --------------- | | | 9865 | | | | | 9866 | -------------- | -- | | 9867 v v v v | 9868 --------- -------------- | 9869 | PAYMENT | | PAYMENT WITH | | 9870 | (first) | | DELIVERY | | 9871 --------- -------------- | 9872 | | | 9873 ----------------------------- | | 9874 v | | | 9875 ---------- --------- | | | 9876 | DELIVERY | | PAYMENT | | | | 9877 | | | {second)| | | | 9878 ---------- --------- | | | 9879 | | | v 9880 ----------------------------------------------> STOP 9882 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9884 Figure 28 Baseline Purchase IOTP Transaction 9886 See section 8.1.12 Valid Combinations of Document Exchanges to 9887 determine which combination of document exchanges apply to a 9888 particular instance of an IOTP Transaction 9890 8.1.9 Baseline Refund IOTP Transaction 9892 In business terms the refund process typically consists of: 9894 o a request for a refund being made by the Consumer to the 9895 Merchant, typically supported by evidence to demonstrate: 9896 - the original trade took place, for example by providing a receipt 9897 for the original transaction 9898 - using some type of authentication, that the consumer requesting 9899 the refund is the consumer, or a representative of the consumer, 9900 who carried out the original trade 9901 - the reason why the merchant should make the refund 9903 o the merchant agreeing (or not) to the refund. This may involve 9904 some negotiation between the Consumer and the Merchant, and, if 9905 the merchant agrees, 9907 o a refund payment by the Merchant to the Consumer. 9909 The Baseline Refund IOTP Transaction supports a subset of the above, 9910 specifically it supports: 9912 o stand alone authentication of the Consumer using a separate 9913 Baseline Authentication IOTP Transaction (see section 8.1.6) 9915 o a refund payment by the Merchant to the Consumer using the 9916 following two Trading Exchanges: 9917 - an optional Authentication Document Exchange (see section 8.1.1) 9918 - an Offer Document Exchange (see section 8.1.2), and 9919 - a Payment Document Exchange (see section 8.1.3). 9921 The ways in which these Document Exchanges are combined is illustrated 9922 by the diagram below. 9924 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 9926 START ----------------------------------------------------- 9927 | v 9928 | ---------------- 9929 | | AUTHENTICATION | 9930 | ---------------- 9931 -------------------------------------- | 9932 | | | 9933 | -------------- | ------------- 9934 v v v v 9935 ------------------- ----------------- 9936 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9937 | OFFER | | OFFER | 9938 ------------------- ----------------- 9939 | | 9940 | | 9941 | | 9942 | ------------------- 9943 v v 9944 --------- -------------- 9945 | PAYMENT | | PAYMENT WITH | 9946 | (first) | | DELIVERY | 9947 --------- -------------- 9948 | 9949 ---------------- 9950 | 9951 ---------- --------- | 9952 | DELIVERY | | PAYMENT | | 9953 | | | {second)| | 9954 ---------- --------- | 9955 | 9956 -----------------> STOP 9958 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9960 Figure 29 Baseline Refund IOTP Transaction 9962 A Baseline Refund IOTP Transaction without an Authentication Document 9963 Exchange might be used: 9965 o when authentication of the consumer has been achieved by some 9966 other means, for example, the consumer has entered some 9967 previously supplied code in order to identify herself and the 9968 refund to which the code applies. The code could be supplied, 9969 for example on a web page or by e-mail. 9971 o when a previous IOTP transaction, for example a Baseline 9972 Authentication, authenticated the consumer, and a secure 9973 channel has been maintained, therefore the authenticity of the 9974 consumer is known and therefore the previously agreed refund 9975 can be identified. 9977 o when the authentication of the consumer is carried out by the 9978 Payment Handler using a payment scheme authentication method. 9980 8.1.10 Baseline Withdrawal IOTP Transaction 9982 The Baseline Withdrawal IOTP Transaction supports the withdrawal of 9983 electronic cash from a Financial Institution. 9985 [Note] The Financial Institution has, in IOTP terminology, a role 9986 of merchant in that a service (i.e. a withdrawal of 9987 electronic cash) is being offered in return for a fee, for 9988 example bank charges of some kind. The term "Financial 9989 Institution" is used in the diagrams and in the text for 9990 clarity. 9991 [Note End] 9993 The Baseline Withdrawal IOTP Transaction consists of the following 9994 Document Exchanges: 9996 o an optional Authentication Document Exchange (see section 9997 8.1.1) 9999 o an Offer Document Exchange (see section 8.1.2), and 10001 o a Payment Document Exchange (see section 8.1.3). 10003 The way in which these Document Exchanges may be combined together is 10004 illustrated by the diagram below. 10006 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10008 START ----------------------------------------------------- 10009 | v 10010 | ---------------- 10011 | | AUTHENTICATION | 10012 | ---------------- 10013 -------------------------------------- | 10014 | | | 10015 | -------------- | ------------- 10016 v v v v 10017 ------------------- ----------------- 10018 | BRAND INDEPENDENT | | BRAND DEPENDENT | 10019 | OFFER | | OFFER | 10020 ------------------- ----------------- 10021 | | 10022 | | 10023 | | 10024 | ------------------- 10025 v v 10026 --------- -------------- 10027 | PAYMENT | | PAYMENT WITH | 10028 | (first) | | DELIVERY | 10029 --------- -------------- 10030 | 10031 ---------------- 10032 | 10033 ---------- --------- | 10034 | DELIVERY | | PAYMENT | | 10035 | | | {second)| | 10036 ---------- --------- | 10037 | 10038 -----------------> STOP 10040 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10042 Figure 30 Baseline Withdrawal IOTP Transaction 10044 Note that: 10046 o a Merchant (Financial Institution) may be able to offer 10047 withdrawal of several different types of electronic cash. In 10048 practice usually only one form of electronic cash may be 10049 offered. However, there may be several different protocols 10050 which may be used for the same "brand" of electronic cash 10052 o the Merchant (Financial Institution) may use the results of the 10053 authentication to identify not only the consumer but also the 10054 account from which the withdrawal is to be made. If no single 10055 account can be identified, then it must be obtained by other 10056 means. For example: 10057 - the consumer could specify the account number prior to the 10058 Baseline Withdrawal IOTP Transaction starting, or 10059 - the consumer could have been identified earlier, for example using 10060 a Baseline Authentication IOTP Transaction, and an account 10061 selected from a list provided by the Financial Institution. 10063 o a Baseline Withdrawal without an authentication might be used: 10064 - if a previous IOTP transaction, for example a Baseline Deposit or 10065 a Baseline Authentication, authenticated the consumer, and a 10066 secure channel has been maintained, therefore the authenticity of 10067 the consumer is known 10068 - if authentication is achieved as part of a proprietary payment 10069 protocol and is therefore included in the Payment Document 10070 Exchange 10071 - if authentication of the consumer has been achieved by some other 10072 means, for example, by using a pass phrase, or a proprietary 10073 banking software solution. 10075 8.1.11 Baseline Value Exchange IOTP Transaction 10077 The Baseline Value Exchange Transaction uses Payment Document 10078 Exchanges to support the exchange of value in one currency obtained 10079 using one payment method with value in the same or another currency 10080 using the same or another payment method. Examples of its use include: 10082 o electronic cash advance on a credit card. For example the first 10083 payment could be a _dollar SET Payment_ using a credit card 10084 with the second payment being a download of Visa Cash e-cash in 10085 dollars. 10087 o foreign exchange using the same payment method. For example the 10088 payment could be an upload of Mondex value in British Pounds 10089 and the second a download of Mondex value in Euros 10091 o foreign exchange using different payment methods. For example 10092 the first payment could be a SET payment in Canadian Dollars 10093 followed a download of GeldKarte in Deutchmarks. 10095 The Baseline Value Exchange uses the following Document Exchanges: 10097 o an optional Authentication Document Exchange (see section 10098 8.1.1) 10100 o an Offer Document Exchange (see section 8.1.2), which provides 10101 details of what values and currencies will be exchanged, and 10103 o two Payment Document Exchanges (see section 8.1.3) which carry 10104 out the two payments involved. 10106 The way in which these Document Exchanges may be combined together is 10107 illustrated by the diagram below. 10109 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10111 START ----------------------------------------------------- 10112 | v 10113 | ---------------- 10114 | | AUTHENTICATION | 10115 | ---------------- 10116 -------------------------------------- | 10117 | | | 10118 | -------------- | ------------- 10119 v v v v 10120 ------------------- ----------------- 10121 | BRAND INDEPENDENT | | BRAND DEPENDENT | 10122 | OFFER | | OFFER | 10123 ------------------- ----------------- 10124 | | 10125 | | 10126 | | 10127 | ------------------- 10128 v v 10129 --------- -------------- 10130 | PAYMENT | | PAYMENT WITH | 10131 | (first) | | DELIVERY | 10132 --------- -------------- 10133 | 10134 ---- 10135 v 10136 ---------- --------- 10137 | DELIVERY | | PAYMENT | 10138 | | | {second)| 10139 ---------- --------- 10140 | 10141 -----------------------------> STOP 10143 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10145 Figure 31 Baseline Value Exchange IOTP Transaction 10147 The Baseline Value Exchange IOTP Transaction occurs in two basic 10148 forms: 10150 o Brand Dependent Value Exchange. Where the content of the offer, 10151 for example the rate at which one form of value is exchanged 10152 for another, is dependent on the payment brands and protocols 10153 selected by the consumer, and 10155 o Brand Independent Value Exchange. Where the content of the 10156 offer is not dependent on the payment brands and protocols 10157 selected. 10159 [Note] In the above the role is a Merchant even though the 10160 organisation carrying out the Value Exchange may be a Bank 10161 or some other Financial Institution. This is because the 10162 Bank is acting as a merchant in that they are making an 10163 offer which the Consumer can either accept or decline. 10164 [Note End] 10166 The TPO Block and Offer Response Block may only be combined into the 10167 same IOTP Message if the content of the Offer Response Block does not 10168 change as a result of selecting the payment brands and payment 10169 protocols to be used in the Value Exchange. 10171 BASELINE VALUE EXCHANGE SIGNATURES 10173 The use of signatures to ensure the integrity of a Baseline Value 10174 Exchange is illustrated by the diagram below. 10176 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10178 Signature generated IotpMsg (TPO) 10179 by Merchant ensures - Trans Ref Block 10180 integrity of the Offer --------> - - Signature Block 10181 | - TPO Block MERCHANT 10182 | - Offer Response Block 10183 | 10184 Signature generated by | 10185 the Payment Handler of | IotpMsg (Pay Resp 1) 10186 the first payment binds | - Trans Ref Block PAYMENT 10187 Pay Receipt for the first -----> -> - Signature Block ----- HANDLER 10188 payment to the Offer - Pay Response Block 1 | 1 10189 | 10190 Signature generated by | 10191 the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT 10192 the second payment binds - Trans Ref Block | HANDLER 10193 the second payment to the -----> - Signature Block <------ 2 10194 first payment and therefore - Pay Response Block 2 10195 to the Offer 10197 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10199 Figure 32 Baseline Value Exchange Signatures 10201 8.1.12 Valid Combinations of Document Exchanges 10203 The following diagram illustrates the data conditions in the various 10204 IOTP messages which can be used by a Consumer Trading Role to 10205 determine whether the combination of Document Exchanges are valid. 10207 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10209 START 10210 | 10211 v 10212 Auth Request Block in =TRUE 10213 first IOTP Message ? --------------------------------------- 10214 | = FALSE | 10215 v v 10216 Offer Response Block in ---------------- 10217 first IOTP Message ? | AUTHENTICATION | 10218 |=TRUE |=FALSE ---------------- 10219 | | | 10220 | | v 10221 | ---------------------- TPO & Offer Response 10222 ------------- | Blocks in last IOTP Msg 10223 | | |=TRUE |=FALSE 10224 | | | v 10225 | ------------- | ---- TPO Block only i 10226 | | | last IOTP Message 10227 | | | of Authentication 10228 | | | |=TRUE |=FALSE 10229 v v v v | 10230 ------------------- ----------------- | 10231 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 10232 | OFFER | | OFFER | | 10233 ------------------- ----------------- | 10234 | | | 10235 v v | 10236 Offer Response Block contains | 10237 Delivery Component ? | 10238 |=FALSE |=TRUE | 10239 --- v | 10240 | Value of DelivAndPayResp | 10241 | attribute of Delivery Component ? | 10242 | |=FALSE |=TRUE | 10243 | | | | 10244 v v v | 10245 --------- -------------- | 10246 | PAYMENT | | PAYMENT WITH | | 10247 | (first) | | DELIVERY | | 10248 --------- -------------- | 10249 | | | 10250 v | | 10251 Offer and Response Block contains | 10252 Delivery Component ? | 10253 |=TRUE |=FALSE | 10254 | v | 10255 | Two Payment Components | 10256 | present in Offer Response Block? | 10257 | |=TRUE |=FALSE | 10258 v v | | 10259 ---------- --------- | | 10260 | DELIVERY | | PAYMENT | | | 10261 | | | {second)| | | 10262 ---------- --------- | | 10263 | | | v 10264 ----------------------------------------------> STOP 10266 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10268 Figure 33 Valid Combinations of Document Exchanges 10270 1) If first IOTP Message of an IOTP Transaction contains an 10271 Authentication Request then: 10273 a) IOTP Transaction includes an Authentication Document Exchange 10274 (see section 8.1.1). (Note 1) 10276 b) If the last IOTP Message of the Authentication Document 10277 Exchange includes a TPO Block and an Offer Response Block 10278 then: 10280 i) IOTP Transaction includes a Brand Independent Offer 10281 Document Exchange (see section 8.1.2.2). (Note 2) 10283 c) Otherwise, if the last IOTP Message of the Authentication 10284 Exchange includes a TPO Block but NO Offer Response Block, 10285 then: 10287 i) IOTP Transaction includes a Brand Dependent Offer Document 10288 Exchange (see section 8.1.2.1). (Note 2) 10290 d) Otherwise (Authentication Status IOTP Message of the 10291 Authentication Document Exchange contains neither a TPO Block 10292 but nor an Offer Response Block) 10294 i) IOTP Transaction consists of just an Authentication 10295 Document Exchange. (Note 3) 10297 2) Otherwise (no Authentication Request in first IOTP Message): 10299 a) IOTP Transaction does not include an Authentication Document 10300 Exchange (Note 2) 10302 b) If first IOTP Message contains an Offer Response Block, then: 10304 i) the IOTP Transaction contains a Brand Independent Offer 10305 Document Exchange (Note 2) 10307 c) Otherwise (no Offer Response Block in first IOTP Message): 10309 i) the IOTP Transaction includes a Brand Dependent Offer 10310 Document Exchange (Note 2) 10312 3) If an Offer Response Block exists in any IOTP message then: 10314 a) If the Offer Response Block contains a Delivery Component 10315 then: 10317 i) If the DelivAndPayResp attribute of the Delivery Component 10318 is set to True, then: 10320 . the IOTP Transaction consists of a Payment And Delivery 10321 Document Exchange (see section 8.1.5) (Note 4) 10323 ii) otherwise (the DelivAndPayResp attribute of the Delivery 10324 Component is set to False) 10326 . the IOTP Transaction consists of a Payment Document 10327 Exchange (see section 8.1.3) followed by a Delivery 10328 Document Exchange (see section 8.1.4) (Note 4) 10330 b) otherwise (the Offer Response Block does not contain a 10331 Delivery Component) 10333 i) if the Offer Response Block contains just one Payment 10334 Component, then: 10336 . the IOTP Transaction contains just one Payment Document 10337 Exchange (Note 5) 10339 ii) if the Offer Response Block contains two Payment 10340 Components, then: 10342 . the IOTP Transaction contains two Payment Document 10343 Exchanges. The StartAfter attribute of the Payment 10344 Components is used to indicate which payment occurs 10345 first (Note 6) 10347 iii) if the Offer Response Block contains no or more than two 10348 Payment Components, then there is an error 10350 4) Otherwise (no Offer Response Block) there is an error. 10352 The following table indicates the types of IOTP Transactions which can 10353 validly have the conditions indicated above. 10355 Ref IOTP Transaction Validity 10357 1. Any Payment and Authentication IOTP Transaction 10359 2. Any Payment and Authentication IOTP Transaction except Baseline 10360 Authentication 10362 3. Either Baseline Authentication, or a Baseline Purchase, Refund, 10363 Deposit, Withdrawal or Value Exchange with a failed 10364 Authentication 10366 4. Baseline Purchase only 10368 5. Baseline Purchase, Refund, Deposit or Withdrawal 10370 6. Baseline Value Exchange only 10372 8.1.13 Combining Authentication Transactions with other Transactions 10374 In the previous sections an Authentication Document Exchange is shown 10375 preceding an Offer Document Exchange as part of a single IOTP 10376 Transaction with the same OTP Transaction Id. 10378 It is also possible to run a separate Authentication Transaction at 10379 any point, even in parallel with another IOTP Transaction. Typically 10380 this will be used: 10382 o by a Consumer to authenticate a Payment Handler or a Delivery 10383 Handler, or 10385 o by a Payment Handler or Delivery Handler to authenticate a 10386 Consumer. 10388 In outline the basic process consists of: 10390 o the Trading Role that decides it wants to carry out an 10391 authentication of another role suspends the current IOTP 10392 transaction being carried out 10394 o a stand-alone Authentication transaction is then carried out. 10395 This may, at implementer's option, be linked to the original 10396 IOTP Transaction using a Related To Component (see section 10397 3.3.3) in the Transaction Reference Block. 10399 o if the Authentication transaction is successful, then the 10400 original IOTP Transaction is restarted 10402 o if the Authentication fails then the original IOTP Transaction 10403 is cancelled. 10405 For example, a Consumer could: 10407 o authenticate the Payment Handler for a Payment between 10408 receiving an Offer Response from a Merchant and before sending 10409 the Payment Request to that Payment Handler 10411 o authenticate a Delivery Handler for a Delivery between 10412 receiving the Payment Response from a Payment Handler and 10413 before sending the Delivery Request 10415 A Payment Handler could authenticate a Consumer after receiving the 10416 Payment Request and before sending the next Payment related message. 10418 A Delivery Handler could authenticate a Consumer after receiving the 10419 Delivery Request and before sending the Delivery Response. 10421 [Note] Some Payment Methods may carry out an authentication within 10422 the Payment Exchange. In this case the information required 10423 to carry out the authentication will be included in Payment 10424 Scheme Components. 10426 In this instance IOTP aware application will not be aware 10427 that an authentication has occurred since the Payment Scheme 10428 Components that contain authentication data will be 10429 indistinguishable from other Payment Scheme Components. 10430 [Note End] 10432 8.2 Infrastructure Transactions 10434 Infrastructure Transactions are designed to support inquiries on 10435 whether or not a transaction has succeeded or a Trading Role's servers 10436 are operating correctly. There are two types of transaction: 10438 o a Transaction Status Inquiry Transaction which provides 10439 information on the status of an existing or complete IOTP 10440 transaction, and 10442 o Ping Transaction that enables one IOTP aware application to 10443 determine if the IOTP aware application at another Trading Role 10444 is operating and verify whether or not signatures can be 10445 handled. 10447 Each of these is described below 10449 8.2.1 Baseline Transaction Status Inquiry IOTP Transaction 10451 The Baseline IOTP Transaction Status Inquiry provides information on 10452 the status of an existing or complete IOTP transaction. 10454 The Trading Blocks used by the Baseline Transaction Status Inquiry 10455 Transaction are: 10457 o an Inquiry Request Trading Block (see section 7.12), and 10459 o an Inquiry Response Trading Block (see section 7.13). 10461 [Note] Note that: 10463 o Consumer Inquiries on Authentication transaction are not 10464 supported. 10466 o Authentication of Consumers as part of an inquiry is not 10467 supported in the Baseline version of IOTP. 10468 [Note End] 10470 WHICH TRADING ROLES CAN RECEIVE INQUIRY REQUESTS 10472 The Consumer can send a Transaction Status Inquiry Block to the 10473 appropriate Trading Role after the following events have occurred: 10475 o to the Merchant, after sending TPO Selection Block, 10477 o to the Payment Handler, after sending Payment Request Block, 10479 o to the Delivery Handler, after sending Delivery Request Block. 10481 [Note] IOTP does not support sending Inquiry Requests to the 10482 Consumer since the consumer may not be on-line to receive 10483 and process them. 10485 [Note End] 10487 If the Consumer is inquiring on transaction that is not yet complete, 10488 it should send the Inquiry Request Block to the Trading Role to which 10489 it sent the last IOTP message. If the Consumer is inquiring on a 10490 transaction which is complete, there are two alternatives in deciding 10491 the Trading Roles that the Inquiry Request Block should be sent to: 10493 o the Consumer IOTP software can ask the end user to determine 10494 the type of inquiry they want to make, or 10496 o the Consumer IOTP software can send the inquiry request message 10497 to all the Trading Roles that were involved in the IOTP 10498 transaction. 10500 For the second case above, how the Consumer IOTP Aware Application 10501 displays the inquiry response data received from each Trading Role is 10502 up to each implementation. 10504 TRANSACTION STATUS INQUIRY TRANSPORT SESSION 10506 For a Transaction Status Inquiry on an ongoing transaction, the 10507 Consumer shall establish with a Trading Role, a different transport 10508 session from the ongoing transaction. For a Transaction Status Inquiry 10509 on a past transaction, how the IOTP module on the software at the 10510 Trading Role is started upon the receipt of Inquiry Request message is 10511 defined in each Mapping to Transport supplement for IOTP. 10513 TRANSACTION STATUS INQUIRY ERROR HANDLING 10515 Errors in a Transaction Status Inquiry can be categorised into one the 10516 following three cases: 10518 o Business errors (see section 4.2) in the original (inquired) 10519 messages 10521 o Technical errors (see section 4.1) - both IOTP and payment 10522 scheme specific ones - in the original IOTP (inquired) messages 10524 o Technical errors in the message containing the Inquiry Request 10525 Block itself 10527 The following outlines what the software should do in each case 10528 BUSINESS ERRORS IN THE ORIGINAL MESSAGES 10530 Return an Inquiry Response Block containing the Status Component which 10531 was last sent to the Consumer. 10533 TECHNICAL ERRORS IN THE ORIGINAL MESSAGES 10535 Return an Inquiry Response Block containing a Status Component. The 10536 Status Component should contain a ProcessState attribute set to 10537 ProcessError. In this case send back an Error Block indicating where 10538 the error was found in the original message. 10540 TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK 10542 Return an Error message. That is, send back an Error Block containing 10543 the Error Code (see section 6.19.2) which describes the nature of the 10544 error in the Inquiry Request message. 10546 INQUIRY TRANSACTION MESSAGES 10548 The following Figure outlines the Baseline IOTP Transaction Status 10549 Inquiry processes on both Consumer and Service Provider sides. 10551 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10553 CONSUMER IOTP MESSAGE TRADING ROLE 10554 1. The Consumer decides to inquire (Merchant, 10555 on an IOTP transaction by, for Payment Handler, 10556 example, clicking the inquiry button Delivery Handler 10557 of the IOTP Aware Application. This or Financial 10558 will then generate an Inquiry Institution) 10559 Request Block and send it to the 10560 appropriate Trading Role. 10561 | 10562 v 10563 IotpMsg: Trans Ref 2. The Trading Role checks the 10564 Block; Inquiry ----------> transaction status of the transaction 10565 Request Block Inquiry that is being inquired upon by using 10566 Request the Transaction Id Component of the 10567 Transaction Reference Block. He then 10568 generates the appropriate Inquiry 10569 Response Block based on the status of 10570 the transaction and sends the message 10571 back to the Consumer 10572 | 10573 v 10574 3. The IOTP Aware IotpMsg: Trans Ref 10575 Application displays the <---------------- Block; Inquiry 10576 status information to the Inquiry Response Response Block 10577 end user 10578 | 10579 v 10580 STOP 10582 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10584 Figure 34 Baseline Transaction Status Inquiry 10586 The remainder of this sub-section on the Baseline Transaction Status 10587 Inquiry IOTP Transaction defines the contents of each Trading Block. 10589 TRANSACTION REFERENCE BLOCK 10591 The Consumer must use the same Transaction Id Component (see section 10592 3.3.1) as in the inquired transaction. The OtpTransId attribute in 10593 this component serves as the key in querying the transaction logs 10594 maintained at the Trading Role's site. The value of the ID attribute 10595 of the Message Id Component should be different from those of the 10596 inquired transaction (see section 3.4.1). 10598 INQUIRY REQUEST BLOCK 10600 The Inquiry Request Block (see section 7.12) contains the following 10601 components: 10603 o one Inquiry Type Component (see section 6.16). This identifies 10604 whether the inquiry is on an offer, payment, or delivery. 10606 o zero or one Payment Scheme Component (see section 6.9). This is 10607 for encapsulating payment scheme specific inquiry messages for 10608 inquiries on payment. 10610 INQUIRY RESPONSE BLOCK 10612 The Inquiry Response Block (see section 7.13) contains the following 10613 components: 10615 o one Status Component (see section 6.14). This component hold 10616 the status information on the inquired transaction, 10618 o zero or one Payment Scheme Components. These contain for 10619 encapsulated payment scheme specific inquiry messages for 10620 inquiries on payment. 10622 8.2.2 Baseline Ping IOTP Transaction 10624 The purpose of the Baseline IOTP Ping Transaction is to enable IOTP 10625 aware application software to determine if the IOTP aware application 10626 at another Trading Role is operating and verifying whether or not 10627 signatures can be handled. 10629 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 10631 o a Ping Request Block (see section 7.14) 10633 o a Ping Response Block (see section 7.15), and 10634 o a Signature Block (see section 7.16). 10636 PING MESSAGES 10638 The following figure outlines the message flows in the Baseline IOTP 10639 Ping Transaction. 10641 *+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+* 10643 IOTP TRADING ROLE IOTP MESSAGE IOTP TRADING ROLE 10644 1. The IOTP Aware Application in an 10645 IOTP Trading Role decides to check 10646 whether the counterparty IOTP 10647 application is up and running. It 10648 generates a Ping Block and optional 10649 Signature Block and sends them to 10650 the other IOTP Trading Role. 10651 | 10652 v 10653 IotpMsg: Trans Ref --------> 2. The IOTP Trading Role which receives 10654 Block; Ping Ping the Ping Request generates a Ping 10655 Request Block Request Response and sends it back to the 10656 sender of the original Ping Request. 10657 | 10658 v 10659 3. The original sender of the IotpMsg: Trans Ref 10660 Ping Request checks the returned <------------ Block; Ping 10661 Ping Response and takes Ping Response Response Block 10662 appropriate action, if necessary 10663 | 10664 v 10665 STOP 10667 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10669 Figure 35 Baseline Ping Messages 10671 The verification that signatures can be handled is indicated by the 10672 sender of the Ping Request Block including: 10674 o Organisation Components that identify itself and the intended 10675 recipient of the Ping Request Block, and 10677 o a Signature Block that signs data in the Ping Request. 10679 In this way the receiver of the Ping Request: 10681 o knows who is sending the Ping Request and can therefore verify 10682 the Signature on the Request, and 10684 o knows who to generate a signature for on the Ping Response. 10686 Note that a Ping Request: 10688 o does not affect any on-going transaction 10690 o does NOT start an IOTP aware application, unlike other IOTP 10691 transaction messages such as TPO or Transaction Status Inquiry. 10693 All IOTP aware applications must return a Ping Response message to the 10694 sender of a Ping Request message when it is received. 10696 A Baseline IOTP Ping request can also contain an optional Signature 10697 Block. IOTP aware applications can, for example, use the Signature 10698 Block to check the recipient of a Ping Request can successfully 10699 process and check signatures it has received. 10701 For each Baseline Ping IOTP Transaction, each IOTP role shall 10702 establish a different transport session from other IOTP transactions. 10704 Any IOTP Trading Role can send a Ping request to any other IOTP 10705 Trading Role at any time it wants. A Ping message has its own 10706 OtpTransId, which is different from other IOTP transactions. 10708 The remainder of this sub-section on the Baseline Ping IOTP 10709 Transaction defines the contents of each Trading Block. 10711 TRANSACTION REFERENCE BLOCK 10713 The OtpTransId of a Ping transaction should be different from any 10714 other IOTP transaction. 10716 PING REQUEST BLOCK 10718 If the Ping Transaction is anonymous then no Organisation Components 10719 are included in the Ping Request Block (see section 7.7). 10721 If the Ping Transaction is not anonymous then the Ping Request Block 10722 contains Organisation Components for: 10724 o the sender of the Ping Request Block, and 10726 o the verifier of the Signature Component 10727 If Organisation Components are present, then it indicates that the 10728 sender of the Ping Request message has generated a Signature Block. 10729 The signature block must be verified by the Trading Role that receives 10730 the Ping Request Block. 10732 SIGNATURE BLOCK (PING REQUEST) 10734 The Ping Request Signature Block (see section 7.16) contains the 10735 following components: 10737 o one Signature Component (see section 6.17) 10739 o one or more Certificate Components, if required. 10741 PING RESPONSE BLOCK 10743 The Ping Response Block (see section 7.15) contains the following 10744 component: 10746 o the Organisation Component of the sender of the Ping Response 10747 message 10749 If the Ping Transaction is not anonymous then the Ping Response 10750 additionally contains: 10752 o copies of the Organisation Components contained in the Ping 10753 Request Block. 10755 SIGNATURE BLOCK (PING RESPONSE) 10757 The Ping Response Signature Block (see section 7.16) contains the 10758 following components: 10760 o one Signature Component (see section 6.17) 10762 o one or more Certificate Components, if required. 10764 9. Retrieving Logos 10766 This section describes how to retrieve logos for display by IOTP aware 10767 software using the Logo Net Locations attribute contained in the Brand 10768 Element (see section 6.6.1) and the Organisation Component (see 10769 section 6.5). 10771 The full address of a logo is defined as follows: 10772 Logo_address ::= Logo_net_location "/" Logo_size 10773 Logo_color_depth ".GIF" 10775 Where: 10777 o Logo_net_location is obtained from the LogoNetLocn attribute in 10778 the Brand Element (see section 6.6.1) or the Organisation 10779 Component. Note that: 10780 - the content of this attribute is dependent on the Transport 10781 Mechanism (such as HTTP) that is used. See the Transport 10782 Mechanism supplement, 10783 - implementers should check that if the rightmost character of Logo 10784 Net Location is set to right-slash "/" then another, right slash 10785 should not be included when generating the Logo Address, 10787 o Logo_size identifies the size of the logo, 10789 o Logo_color_depth identifies the colour depth of the logo 10791 o "GIF" indicates that the logos are in GIF format 10793 Logo_size and Logo_color_depth are specified by the implementer of the 10794 IOTP software that is retrieving the logo depending on the size and 10795 colour that they want to use. 10797 9.1 Logo Size 10799 There are five standard sizes for logos. The sizes in pixels and the 10800 corresponding values for Logo Size are given in the table below. 10802 Size in Logo Size 10803 Pixels Value 10805 32 x 32 or exsmall 10806 32 x 20 10808 53 x 33 small 10810 103 x 65 medium 10812 180 x 114 large 10814 263 x 166 exlarge 10816 9.2 Logo Color Depth 10818 There are three standard colour depths. The colour depth (including 10819 bits per pixel) and the corresponding value for Logo_Color_Depth are 10820 given in the table below. 10822 Color Depth Logo Color 10823 (bits per pixel) Depth Value 10825 4 (16 colors) 4 10827 8 (256 colors) nothing 10829 24 (16 million colors) 24 10831 Note that if Logo Color Depth is omitted then a logo with the default 10832 colour depth of 256 colours will be retrieved. 10834 9.3 Logo Net Location Examples 10836 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 10838 o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 10839 256 colour logo 10841 o "ftp://logos.xzpay.com/small4.gif" would retrieve a small size 10842 16 colour logo 10844 [Note] Organisations which make logos available for use with IOTP 10845 should always make available "small" and "medium" size logos 10846 and use the GIF format. 10847 [Note End] 10848 10. Brand List Examples 10850 This example contains three examples of the XML for a Brand List 10851 Component. It covers: 10853 o a simple credit card based example 10855 o a credit card based brand list including promotional credit 10856 card brands, and 10858 o a complex electronic cash based brand list 10860 Note that: 10862 o brand lists can be as complex or as simple as required 10864 o all example techniques described in this appendix can be 10865 included in one brand list. 10867 10.1 Simple Credit Card Based Example 10869 This is a simple example involving: 10871 o only major credit card payment brands 10873 o a single price in a single currency 10875 o a single payment handler, and 10877 o a single payment protocol 10879 10883 10888 10889 10894 10895 10900 10901 10904 10905 10908 10912 10913 10915 10.2 Credit Card Brand List Including Promotional Brands 10917 An example of a Credit Card based Brand List follows. It includes: 10919 o two ordinary card association brands and two promotional credit 10920 card brands. The promotional brands consist of one loyalty 10921 based (British Airways MasterCard) which offers additional 10922 loyalty points and one store based (Walmart) which offers a 10923 discount on purchases over a certain amount 10925 o two payment protocols: 10926 - SET (Secure Electronic Transactions) see [SET], and 10927 - SCCD (Secure Channel Credit Debit) see [SCCD]. 10929 10933 10938 10939 10944 10945 10952 10953 10960 10961 10964 10965 238djqw1298erh18dhoire 10966 10967 10968 10971 10972 238djqw1298erh18dhoire 10973 10974 10975 10978 10982 10983 8ueu26e482hd82he82 10984 10985 10986 10990 10991 82hd82he8226e48ueu 10992 10993 10994 10996 10.3 Brand Selection Example 10998 In order to pay by 'British Airways' MasterCard using the example 10999 above using SET and therefore getting double air miles, the Brand 11000 Selection would be: 11002 11007 11009 10.4 Complex Electronic Cash Based Brand List 11011 The following is an fairly complex example which includes: 11013 o payments using either Mondex, GeldKarte, CyberCash or DigiCash 11015 o in currencies including US dollars, British Pounds, Italian 11016 Lira, German Marks and Canadian Dollars 11018 o a discount on the price if the payment is made in Mondex using 11019 British pounds or US dollars, and 11021 o more than one payment handler is used for payments involving 11022 Mondex or CyberCash 11024 o support for more than one version of a CyberCash CyberCoin 11025 payment protocol. 11027 11031 11036 11037 11042 11043 11048 11049 11056 11057 11060 11061 11064 11065 11068 11069 11072 11073 11076 11077 11080 11083 11086 11089 11092 11095 11098 11101 11105 11106 11110 11111 11115 11116 11121 11122 11126 11127 11131 11132 11133 11. Open Trading Protocol Data Type Definition 11135 This section contains the XML DTD for the Internet Open Trading 11136 Protocols. 11138 11204 11226 11230 11236 11237 11240 11241 11248 11249 11257 11258 11265 11271 11272 11277 11282 11283 11284 11292 11293 11294 11301 11302 11303 11308 11309 11310 11320 11321 11323 11332 11333 11340 11341 11348 11349 11356 11357 11367 11368 11370 11376 11377 11387 11388 11394 11395 11401 11402 11412 11413 11416 11423 11424 11428 11429 11433 11434 11438 11439 11440 11448 11449 11450 11456 11457 11458 11464 11465 11466 11470 11471 11472 11480 11481 11491 11492 11493 11499 11500 11501 11512 11513 11514 11519 11520 11521 11527 11528 11529 11538 11539 11547 11553 11554 11555 11558 11559 11560 11563 11564 11566 11569 11570 11571 11574 11575 11576 11579 11580 11581 11584 11585 11587 11590 11591 11592 11595 11596 11598 11601 11602 11604 11607 11608 11609 11612 11613 11614 11617 11618 11619 11624 11625 11626 11629 11630 11631 11638 11639 11640 11643 11644 11645 11648 11654 11655 11658 11664 11665 11668 11678 11679 11684 11685 11689 11691 11692 11696 11697 11700 11701 11707 11708 11711 11716 11719 11723 11724 11728 11729 11733 11734 11736 12. Glossary 11738 This section contains a glossary of some of the terms used within this 11739 specification in alphabetical order. 11741 NAME DESCRIPTION 11743 Authenticator The Organisation which is requesting the 11744 authentication of another Organisation, and 11746 Authenticatee The Organisation being authenticated by an 11747 Authenticator 11749 Business Error See Status Component. 11751 Brand A Brand is the mark which identifies a 11752 particular type of Payment Instrument. A list of 11753 Brands are the payment options which are 11754 presented by the Merchant to the Consumer and 11755 from which the Consumer makes a selection. Each 11756 Brand may have a different Payment Handler. 11757 Examples of Brands include: 11758 o payment association and proprietary Brands, 11759 for example MasterCard, Visa, American 11760 Express, Diners Club, American Express, 11761 Mondex, GeldKarte, CyberCash, etc. 11762 o Promotional Brands (see below). These include: 11763 o store Brands, where the Payment Instrument is 11764 issued to a Consumer by a particular Merchant, 11765 for example Walmart, Sears, or Marks and 11766 Spencer (UK) 11767 o coBrands, for example American Advantage Visa, 11768 where an a company uses their own Brand in 11769 conjunction with, typically, a payment 11770 association Brand. 11772 Consumer The Organisation which is to receive the benefit 11773 of and typically pay for the goods or services. 11775 Customer Care An Organisation that is providing customer care 11776 Provider typically on behalf of a Merchant. Examples of 11777 customer care include, responding to problems 11778 raised by a Consumer arising from an IOTP 11779 Transaction that the Consumer took part in. 11781 NAME DESCRIPTION 11783 Delivery Handler The Organisation that physically delivers the 11784 goods or services to the Consumer on behalf of 11785 the Merchant. 11787 Dual Brand A Dual Brand means that a single Payment 11788 Instrument may be used as if it were two 11789 separate Brands. For example there could be a 11790 single Japanese "UC" MasterCard which can be 11791 used as either a UC card or a regular 11792 MasterCard. The UC card Brand and the MasterCard 11793 Brand could each have their own separate Payment 11794 Handlers. This means that: 11795 o the Merchant treats, for example "UC" and 11796 "MasterCard" as two separate Brands when 11797 offering a list of Brands to the Consumer, 11798 o the Consumer chooses a Brand, for example 11799 either "UC" or "MasterCard, 11800 o the Consumer IOTP aware application determines 11801 which Payment Instrument(s) match the chosen 11802 Brand, and selects, perhaps with user 11803 assistance, the correct Payment Instrument to 11804 use. 11806 Exchange Block An Exchange Block is sent between the two 11807 Trading Roles involved in a Trading Exchange. It 11808 contains one or more Trading Components. 11809 Exchange Blocks are always sent after a Request 11810 Block and before a Response Block in a Trading 11811 Exchange. The content of an Exchange Block is 11812 dependent on the type of Trading Exchange being 11813 carried out. 11815 Error Block An Error Block reports that a Technical Error 11816 was found in an IOTP Message that was previously 11817 received. Typically Technical Errors are caused 11818 by errors in the XML which has been received or 11819 some technical failure of the processing of the 11820 IOTP Message. Frequently the generation or 11821 receipt of an Error Block will result in failure 11822 of the IOTP Transaction. They are distinct from 11823 Business Errors, reported in a Status Component, 11824 which can also cause failure of an IOTP 11825 Transaction. 11827 NAME DESCRIPTION 11829 IOTP Message An IOTP Message is the outermost wrapper for the 11830 document(s) which are sent between Trading Roles 11831 that are taking part in a trade. It is a well 11832 formed XML document. The documents it contains 11833 consist of: 11834 o a Transaction Reference Block to uniquely 11835 identify the IOTP Transaction of which the 11836 IOTP Message is part, 11837 o an optional Signature Block to digitally sign 11838 the Trading Blocks or Trading Components 11839 associated with the IOTP Transaction 11840 o an optional Error Block to report on technical 11841 errors contained in a previously received IOTP 11842 Message, and 11843 o a collection of IOTP Trading Blocks which 11844 carries the data required to carry out an IOTP 11845 Transaction. 11847 IOTP Transaction An instance of an Internet Open Trading Protocol 11848 Transaction consists of a set of IOTP Messages 11849 transferred between Trading Roles. The rules for 11850 what may be contained in the IOTP Messages is 11851 defined by the Transaction Type of IOTP 11852 Transaction. 11854 Document Exchange A Document Exchange consists of a set of IOTP 11855 Messages exchanged between two parties that 11856 implement part or all of two Trading Exchanges 11857 simultaneously in order to minimise the number 11858 of actual OTP Messages which must be sent over 11859 the Internet. 11861 Document Exchanges are combined together in 11862 sequence to implement a particular IOTP 11863 Transaction. 11865 Merchant The Organisation from whom the service or goods 11866 are being obtained, who is legally responsible 11867 for providing the goods or services and receives 11868 the benefit of any payment made 11870 Merchant Customer The Organisation that is involved with customer 11871 Care Provider dispute negotiation and resolution on behalf of 11872 the Merchant 11874 NAME DESCRIPTION 11876 Organisation A company or individual that takes part in a 11877 Trade as a Trading Role. The organisations may 11878 take one or more of the roles involved in the 11879 Trade 11881 Payment Handler The Organisation that physically receives the 11882 payment from the Consumer on behalf of the 11883 Merchant 11885 Payment Instrument A Payment Instrument is the means by which 11886 Consumer pays for goods or services offered by a 11887 Merchant. It can be, for example: 11888 o a credit card such as MasterCard or Visa; 11889 o a debit card such as MasterCard's Maestro; 11890 o a smart card based electronic cash Payment 11891 Instrument such as a Mondex Card, a GeldKarte 11892 card or a Visa Cash card 11893 o a software based electronic payment account 11894 such as a CyberCash or DigiCash account. 11896 All Payment Instruments have a number, typically 11897 an account number, by which the Payment 11898 Instrument can be identified. 11900 NAME DESCRIPTION 11902 Promotional Brand A Promotional Brand means that, if the Consumer 11903 pays with that Brand, then the Consumer will 11904 receive some additional benefit which can be 11905 received in two ways: 11906 o at the time of purchase. For example if a 11907 Consumer pays with a "Walmart MasterCard" at a 11908 Walmart web site, then a 5% discount might 11909 apply, which means the Consumer actually pays 11910 less, 11911 o from their Payment Instrument (card) issuer 11912 when the payment appears on their statement. 11913 For example loyalty points in a frequent flyer 11914 scheme could be awarded based on the total 11915 payments made with the Payment Instrument 11916 since the last statement was issued. 11918 Each Promotional Brand should be identified as a 11919 separate Brand in the list of Brands offered by 11920 the Merchant. For example: "Walmart", "Sears", 11921 "Marks and Spencer" and "American Advantage 11922 Visa", would each be a separate Brand. 11924 Receipt Component A Receipt Component is a record of the 11925 successful completion of a Trading Exchange. 11926 Examples of Receipt Components include: Payment 11927 Receipts, and Delivery Notes. It's content may 11928 dependent on the technology used to perform the 11929 Trading Exchange. For example a Secure 11930 Electronic Transaction (SET) payment receipt 11931 consists of SET payment messages which record 11932 the result of the payment. 11934 NAME DESCRIPTION 11936 Request Block A Request Block is Trading Block that contains a 11937 request for a Trading Exchange to start. The 11938 Trading Components in a Request Block may be 11939 signed by a Signature Block so that their 11940 authenticity may be checked and to determine 11941 that the Trading Exchange being requested is 11942 authorised. Authorisation for a Trading Exchange 11943 to start can be provided by the signatures 11944 contained on Receipt Components contained in 11945 Response Blocks resulting from previously 11946 completed Trading Exchanges. Examples of 11947 Request Blocks are Payment Request and Delivery 11948 Request 11950 Response Block A Response Block is a Trading Block that 11951 indicates that a Trading Exchange is complete. 11952 It is sent by the Trading Role that received a 11953 Request Block to the Trading Role that sent the 11954 Request Block. The Response Block contains a 11955 Status Component that contains information about 11956 the completion of the Trading Exchange, for 11957 example it indicates whether or not the Trading 11958 Exchange completed successfully. For some 11959 Trading Exchanges the Response Block contains a 11960 Receipt Component that forms a record of the 11961 Trading Exchange. Receipt Components may be 11962 digitally signed using a Signature Block to make 11963 completion non-refutable. Examples of Response 11964 Blocks include Offer Response, Payment Response 11965 and Delivery Response. 11967 Signature Block A Signature Block is a Trading Block that 11968 contains one or more digital signatures in the 11969 form of Signature Components. A Signature 11970 Component may digitally sign any Block or 11971 Component in any IOTP Message in the same IOTP 11972 Transaction. 11974 NAME DESCRIPTION 11976 Status Component A Status Component contains information that 11977 describes the state of a Trading Exchange. 11979 Before the Trading Exchange is complete the 11980 Status Component can indicate information about 11981 how the Trading Exchange is progressing. 11983 Once a Trading Exchange is complete the Status 11984 Component can only indicate the success of the 11985 Trading Exchange or that a Business Error has 11986 occurred. 11988 A Business Error indicates that continuation 11989 with the Trading Exchange was not possible 11990 because of some business rule or logic, for 11991 example, "insufficient funds available", rather 11992 than any Technical Error associated with the 11993 content or format of the IOTP Messages in the 11994 IOTP Transaction. 11996 Technical Error See Error Block. 11998 Trading Block A Trading Block consists of one or more Trading 11999 Components. One or more Trading Blocks may be 12000 contained within the IOTP Messages which are 12001 physically sent in the form of [XML] documents 12002 between the different Trading Roles that are 12003 taking part in a trade. Trading Blocks are of 12004 three main types: 12005 o a Request Block, 12006 o an Exchange Block, or a 12007 o a Response Block 12009 Trading Component A Trading Component is a collection of XML 12010 elements and attributes. Trading Components are 12011 the child elements of the Trading Blocks. 12012 Examples of Trading Components are: Offer, Brand 12013 List, Payment Receipt, Delivery [information], 12014 Payment Amount [information] 12016 NAME DESCRIPTION 12018 Trading Exchange A Trading Exchange consists of the exchange, 12019 between two Trading Roles, of a sequence of 12020 documents. The documents may be in the form of 12021 Trading Blocks or they may be transferred by 12022 some other means, for example through entering 12023 data into a web page. Each Trading Exchange 12024 consists of three main parts: 12025 o the sending of a Request Block by one Trading 12026 Role (the initiator) to another Trading Role 12027 (the recipient), 12028 o the optional exchange of one or more Exchange 12029 Blocks between the recipient and the 12030 initiator, until eventually, 12031 o the Trading Role that received the Request 12032 Block sends a Response Block to the initiator. 12034 A Trading Exchange is designed to implement a 12035 useful service of some kind. Examples of Trading 12036 Exchanges/services are: 12037 o Offer, which results in a Consumer receiving 12038 an offer from a Merchant to carry out a 12039 business transaction of some kind, 12040 o Payment, where a Consumer makes a payment to a 12041 Payment Handler, 12042 o Delivery, where a Consumer requests, and 12043 optionally obtains, delivery of goods or 12044 services from a Delivery Handler, and 12045 o Authentication, where any Trading Role may 12046 request and receive information about another 12047 Trading Role. 12049 Transaction A Transaction Reference Block identifies an IOTP 12050 Reference Block Transaction. It contains data that identifies: 12051 o the Transaction Type, 12052 o the IOTP Transaction uniquely, through a 12053 globally unique transaction identifier 12054 o the IOTP Message uniquely within the IOTP 12055 Transaction, through a message identifier 12057 The Transaction Reference Block may also contain 12058 references to other transactions which may or 12059 may not be IOTP Transactions 12061 NAME DESCRIPTION 12063 Trading Role A Trading Role identifies the different ways in 12064 which organisations can participate in a trade. 12065 There are five Trading Roles: Consumer, 12066 Merchant, Payment Handler, Delivery Handler, and 12067 Merchant Customer Care Provider. 12069 Transaction Type A Transaction Type identifies the type an of 12070 IOTP Transaction. Examples of Transaction Type 12071 include: Purchase, Refund, Authentication, 12072 Withdrawal, Deposit (of electronic cash). The 12073 Transaction Type specifies for an IOTP 12074 Transaction: 12075 o the Trading Exchanges which may be included in 12076 the transaction, 12077 o how those Trading Exchanges may be combined to 12078 meet the business needs of the transaction 12079 o which Trading Blocks may be included in the 12080 IOTP Messages that make up the transaction 12081 o Consult this specification for the rules that 12082 apply for each Transaction Type. 12084 13. Copyrights 12086 Copyright (C) The Internet Society (1998). All Rights Reserved. 12088 This document and translations of it may be copied and furnished to 12089 others, and derivative works that comment on or otherwise explain it 12090 or assist in its implementation may be prepared, copied, published and 12091 distributed, in whole or in part, without restriction of any kind, 12092 provided that the above copyright notice and this paragraph are 12093 included on all such copies and derivative works. However, this 12094 document itself may not be modified in any way, such as by removing 12095 the copyright notice or references to the Internet Society or other 12096 Internet organisations, except as needed for the purpose of developing 12097 Internet standards in which case the procedures for copyrights defined 12098 in the Internet Standards process must be followed, or as required to 12099 translate it into languages other than English. 12101 The limited permissions granted above are perpetual and will not be 12102 revoked by the Internet Society or its successors or assigns. 12104 This document and the information contained herein is provided on an 12105 AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 12106 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 12107 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 12108 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 12109 OR FITNESS FOR A PARTICULAR PURPOSE. 12111 14. References 12113 This section contains references to related documents identified in 12114 this specification. 12116 [Base64] Base64 Content-Transfer-Encoding. A method of 12117 transporting binary data defined by MIME. See: RFC 2045: 12118 Multipurpose Internet Mail Extensions (MIME) Part One: 12119 Format of Internet Message Bodies. N. Freed & N. 12120 Borenstein. November 1996. 12122 [DOM-HASH] A method for generating hashes of all or part of an XML 12123 tree based on the DOM of that tree. See 12124 . 12127 [DNS] The Internet Domain Name System which allocates Internet 12128 names to organisations for example "OTP.org", the Domain 12129 Name for IOTP. See RFC 1034: Domain names - concepts and 12130 facilities. P.V. Mockapetris. Nov-01-1987, and RFC 1035: 12131 Domain names - implementation and specification. P.V. 12132 Mockapetris. Nov-01-1987. 12134 [DSA] The Digital Signature Algorithm (DSA) published by the 12135 National Institute of Standards and Technology (NIST) in 12136 the Digital Signature Standard (DSS), which is a part of 12137 the US government's Capstone project. 12139 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm 12140 (ECCDSA). Elliptic curve cryptosystems are analogues of 12141 public-key cryptosystems such as RSA in which modular 12142 multiplication is replaced by the elliptic curve 12143 addition operation. See: V. S. Miller. Use of elliptic 12144 curves in cryptography. In Advances in Cryptology - 12145 Crypto '85, pages 417-426, Springer-Verlag, 1986. 12147 [HMAC] See Message Authentication Using hash Functions: the 12148 HMAC Construction. RSA Cryptobytes, Volume 2, Number 1, 12149 Spring 1996 12151 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up 12152 Language (HTML) is a simple mark-up language used to 12153 create hypertext documents that are platform 12154 independent. See RFC 1866 and the World Wide Web (W3C) 12155 consortium web site at: http://www.w3.org/MarkUp/ 12157 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 12158 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 12159 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 12160 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 12161 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 12162 Lee. January 1997. 12164 [IANA] The Internet Assigned Numbers Authority. The 12165 organisation responsible for co-ordinating the names and 12166 numbers associated with the Internet. See 12167 http://www.iana.org/. 12169 [ISO4217] ISO 4217: Codes for the Representation of Currencies. 12170 Available from ANSI or ISO. 12172 [MD5] R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. 12174 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 12175 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 12177 [OPS] Open Profiling Standard. A proposed standard which 12178 provides a framework with built-in privacy safeguards 12179 for the trusted exchange of profile information between 12180 individuals and web sites. Being developed by Netscape 12181 and Microsoft amongst others. 12183 [RFC822] IETF (Internet Engineering Task Force). RFC 822: The 12184 Standard for the Format of ARPA Internet Messages 12186 . 13 August 1982, David H Crocker. 13 August 1982. 12188 [RFC1738] IETF (Internet Engineering Task Force). RFC 1738: 12189 Uniform Resource Locators (URL), ed. T. Berners-Lee, L. 12190 Masinter, M. McCahill. 1994. 12192 [RFC2434] IETF (Internet Engineering Task Force). RFC 2434. 12193 Guidelines for Writing an IANA Considerations Section in 12194 RFCs. T. Narten and H. Alvestrand 12196 [RSA] RSA is a public-key cryptosystem for both encryption and 12197 authentication supported by RSA Data Security Inc. See: 12198 R. L. Rivest, A. Shamir, and L.M. Adleman. A method for 12199 obtaining digital signatures and public-key 12200 cryptosystems. Communications of the ACM, 21(2): 120- 12201 126, February 1978. 12203 [SCCD] Secure Channel Credit Debit. A method of conducting a 12204 credit or debit card payment where unauthorised access 12205 to account information is prevented through use of 12206 secure channel transport mechanisms such as SSL. An IOTP 12207 supplement describing how SCCD works is under 12208 development. Author. Jonathan Sowler JCP, 12210 [SET] Secure Electronic Transaction Specification, Version 12211 1.0, May 31, 1997. Supports credit and debit card 12212 payments using certificates at the Consumer and Merchant 12213 to help ensure authenticity. 12214 Download from: 12215 . 12217 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute 12218 of Standards and Technology, US Department Of Commerce, 12219 April 1995. Also known as: 59 Fed Reg. 35317 (1994). 12221 [UTC] Universal Time Co-ordinated. A method of defining time 12222 absolutely relative to Greenwich Mean Time (GMT). 12223 Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" 12224 where the "+n" defines the number of hours from GMT. See 12225 ISO DIS8601. 12227 [UTF16] The Unicode Standard, Version 2.0. The Unicode 12228 Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 12229 Proposed Draft Amendment 1 12231 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, 12232 Including Draft Amendment 1: Certificate Extensions 12233 (Version 3 Certificate) 12235 [XML Recommendation for Namespaces in XML, World Wide Web 12236 Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- 12237 xml-names" 12239 [XML] Extensible Mark Up Language. See 12240 http://www.w3.org/TR/PR-xml-971208 for the 8 December 12241 1997 version. 12243 [XMLDSIG] A proposal developed by Richard Brown, GlobeSet 12244 describing an approach to signing XML documents such as 12245 IOTP Messages. See http://www.ietf.org/internet- 12246 drafts/draft-brown-xml-dsig-00.txt and discussion on 12247 IETF Trade WG 12249 15. Author's Address 12251 The author of this document is: 12253 David Burdett 12254 Development Director 12255 Mondex International Ltd 12256 Advanced Technology Division 12257 111 Pine St 12258 San Francisco, 94111 12259 California 12260 USA 12262 Tel: +1 (415) 645 6973 12264 Email: david.burdett@mondex.com 12266 The author of this document appreciates the following contributors to 12267 this protocol (in alphabetic order of company) without which it could 12268 not have been developed. 12270 o Phillip Mullarkey, British Telecom plc 12272 o Andrew Marchewka, Canadian Imperial Bank of Commerce 12274 o Brian Boesch, CyberCash Inc. 12276 o Donald Eastlake 3rd, CyberCash Inc. 12278 o Mark Linehan, International Business Machines 12280 o Richard Brown, GlobeSet Inc. 12282 o Peter Chang, Hewlett Packard 12284 o Masaaki Hiroya, Hitachi Ltd 12286 o Yoshiaki Kawatsura, Hitachi Ltd 12288 o Jonathan Sowler, JCP Computer Services Ltd 12290 o John Wankmueller, MasterCard International 12292 o Steve Fabes, Mondex International Ltd 12293 o Surendra Reddy, Oracle Corporation 12295 o Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) 12297 o Chris Smith, Royal Bank of Canada 12299 o Hans Bernhard-Beykirch, SIZ (IT Development and Coordination 12300 Centre of the German Savings Banks Organisation) 12302 o W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, 12303 formally AT&T Universal Card Services) 12305 o Efrem Lipkin, Sun Microsystems 12307 o Terry Allen, Commerce One (formally Veo Systems) 12309 The author would also like to thank the following organisations for 12310 their support: 12312 o Amino Communications 12314 o DigiCash 12316 o Fujitsu 12318 o General Information Systems 12320 o Globe Id Software 12322 o Hyperion 12324 o InterTrader 12326 o Nobil I T Corp 12328 o Mercantec 12330 o Netscape 12332 o Nippon Telegraph and Telephone Corporation 12334 o Oracle Corporation 12336 o Smart Card Integrations Ltd. 12338 o Spyrus 12339 o Verifone 12341 o Unisource nv 12343 o Wells Fargo Bank 12345 File name: draft-ietf-trade-iotp-v1.0-protocol-03.txt 12346 Expires: 28 August 1999