idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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-05', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 252 longer pages, the longest (page 58) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 253 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 858 instances of too long lines in the document, the longest one being 51 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1557 has weird spacing: '...RespBlk and...' == Line 3497 has weird spacing: '...Request any ...' == Line 3499 has weird spacing: '...esponse any r...' == Line 5180 has weird spacing: '...untInfo bran...' == Line 5195 has weird spacing: '... listed in...' == (7 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1999) is 9014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 822' is mentioned on line 1650, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'Note' is mentioned on line 11432, but not defined == Missing Reference: 'ISO 4217' is mentioned on line 5024, but not defined == Missing Reference: 'SSL' is mentioned on line 10365, but not defined == Missing Reference: 'DSIG' is mentioned on line 11206, but not defined == Unused Reference: 'Base64' is defined on line 12452, but no explicit reference was found in the text == Unused Reference: 'ECCDSA' is defined on line 12473, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 12491, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 12528, but no explicit reference was found in the text == Unused Reference: 'UTF16' is defined on line 12570, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DOM-HASH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECCDSA' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'IOTPDSIG' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTC' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTF16' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 15 errors (**), 0 flaws (~~), 23 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft. 2 David Burdett 3 Commerce One 4 draft-ietf-trade-iotp-v1.0-protocol-05.txt August 1999 5 Expires: February 2000 7 Internet Open Trading Protocol - IOTP 8 Version 1.0 10 Status of this Memo 12 This document, filename draft-ietf-trade-iotp-v1.0-protocol-05.txt, is 13 the main specification of the Internet Open Trading Protocol version 1.0 14 and is intended to become an Informational RFC. Distribution of this 15 document is unlimited. Comments should be sent to the TRADE working group 16 at . 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months and 25 may be updated, replaced, or obsoleted by other documents at any time. 26 It is inappropriate to use Internet-Drafts as reference material or to 27 cite them other than as "work in progress." 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 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, Secure Channel Credit/Debit, 40 Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where 41 such merchant roles as the shopping site, the Payment Handler, the 42 Delivery Handler of goods or services, and the provider of customer 43 support are performed by different parties or by one party. 45 This document obsoletes the previous version of the IOTP specification 46 (draft-ietf-trade-iotp-v1.0-protocol-04.txt.) 48 Table of Contents 50 Status of this Memo ................................................1 52 Abstract ...........................................................1 54 1. Background .....................................................8 55 1.1 Commerce on the Internet, a Different Model .................8 56 1.2 Benefits of IOTP ............................................9 57 1.3 Baseline IOTP ..............................................11 58 1.4 Objectives of Document .....................................11 59 1.5 Scope of Document ..........................................11 60 1.6 Document Structure .........................................12 61 1.7 Intended Readership ........................................13 62 1.7.1 Reading Guidelines ...................................13 64 2. Introduction ..................................................15 65 2.1 Trading Roles ..............................................15 66 2.2 Trading Exchanges ..........................................17 67 2.2.1 Offer Exchange .......................................18 68 2.2.2 Payment Exchange .....................................20 69 2.2.3 Delivery Exchange ....................................22 70 2.2.4 Authentication Exchange ..............................24 71 2.3 Scope of Baseline IOTP .....................................26 73 3. Protocol Structure ............................................29 74 3.1 Overview ...................................................30 75 3.1.1 IOTP Message Structure ...............................30 76 3.1.2 IOTP Transactions ....................................31 77 3.2 IOTP Message ...............................................32 78 3.2.1 XML Document Prolog ..................................33 79 3.3 Transaction Reference Block ................................34 80 3.3.1 Transaction Id Component .............................34 81 3.3.2 Message Id Component .................................36 82 3.3.3 Related To Component .................................37 83 3.4 ID Attributes ..............................................39 84 3.4.1 IOTP Message ID Attribute Definition .................39 85 3.4.2 Block and Component ID Attribute Definitions .........40 86 3.4.3 Example of use of ID Attributes ......................41 87 3.5 Element References .........................................42 88 3.6 Extending IOTP .............................................43 89 3.6.1 Extra XML Elements ...................................44 90 3.6.2 Opaque Embedded Data .................................45 91 3.7 Packaged Content Element ...................................45 92 3.7.1 Packaging HTML .......................................47 93 3.7.2 Packaging XML ........................................48 94 3.8 Identifying Languages ......................................48 95 3.9 Secure and Insecure Net Locations ..........................49 96 3.10 Cancelled Transactions .....................................49 97 3.10.1 Cancelling Transactions ..............................49 98 3.10.2 Handling Cancelled Transactions ......................50 100 4. IOTP Error Handling ...........................................51 101 4.1 Technical Errors ...........................................51 102 4.2 Business Errors ............................................52 103 4.3 Error Depth ................................................52 104 4.3.1 Transport Level ......................................52 105 4.3.2 Message Level ........................................53 106 4.3.3 Block Level ..........................................53 107 4.4 Idempotency, Processing Sequence, and Message Flow .........55 108 4.5 Server Role Processing Sequence ............................56 109 4.5.1 Initiating Transactions ..............................56 110 4.5.2 Processing Input Messages ............................56 111 4.5.3 Cancelling a Transaction .............................61 112 4.5.4 Retransmitting Messages ..............................62 113 4.6 Client Role Processing Sequence ............................62 114 4.6.1 Initiating Transactions ..............................63 115 4.6.2 Processing Input Messages ............................63 116 4.6.3 Cancelling a Transaction .............................65 117 4.6.4 Retransmitting Messages ..............................65 119 5. Security Considerations .......................................66 120 5.1 Determining whether to use digital signatures ..............66 121 5.2 Symmetric and Asymmetric Cryptography ......................67 122 5.3 Data Privacy ...............................................68 123 5.4 Payment Protocol Security ..................................68 125 6. Digital Signatures and IOTP ...................................69 126 6.1 How IOTP uses Digital Signatures ...........................69 127 6.1.1 IOTP Signature Example ...............................71 128 6.1.2 OriginatorInfo and RecipientInfo Elements ............72 129 6.1.3 Using signatures to Prove Actions Complete Successfully73 130 6.2 Checking a Signature is Correctly Calculated ...............73 131 6.3 Checking a Payment or Delivery can occur ...................74 132 6.3.1 Check Request Block sent Correct Organisation ........75 133 6.3.2 Check Correct Components present in Request Block ....78 134 6.3.3 Check an Action is Authorised ........................78 136 7. Trading Components ............................................80 137 7.1 Protocol Options Component .................................81 138 7.2 Authentication Request Component ...........................83 139 7.3 Authentication Response Component ..........................84 140 7.4 Trading Role Information Request Component .................85 141 7.5 Order Component ............................................85 142 7.5.1 Order Description Content ............................86 143 7.5.2 OkFrom and OkTo Timestamps ...........................87 144 7.6 Organisation Component .....................................88 145 7.6.2 Trading Role Element .................................90 146 7.6.3 Contact Information Element ..........................92 147 7.6.4 Person Name Element ..................................93 148 7.6.5 Postal Address Element ...............................94 149 7.7 Brand List Component .......................................95 150 7.7.1 Brand Element ........................................97 151 7.7.2 Protocol Brand Element ...............................99 152 7.7.3 Protocol Amount Element ..............................99 153 7.7.4 Currency Amount Element .............................101 154 7.7.5 Pay Protocol Element ................................102 156 7.8 Brand Selection Component .................................103 157 7.8.1 Brand Selection Brand Info Element ..................105 158 7.8.2 Brand Selection Protocol Amount Info Element ........105 159 7.8.3 Brand Selection Currency Amount Info Element ........106 160 7.9 Payment Component .........................................106 161 7.10 Payment Scheme Component ..................................107 162 7.11 Payment Receipt Component .................................108 163 7.12 Payment Note Component ....................................110 164 7.13 Delivery Component ........................................111 165 7.13.1 Delivery Data Element ...............................112 166 7.14 Consumer Delivery Data Component ..........................114 167 7.15 Delivery Note Component ...................................115 168 7.16 Status Component ..........................................116 169 7.16.1 Offer Completion Codes ..............................118 170 7.16.2 Payment Completion Codes ............................119 171 7.16.3 Delivery Completion Codes ...........................121 172 7.16.4 Authentication Completion Codes .....................123 173 7.16.5 Undefined Completion Codes ..........................125 174 7.16.6 Transaction Inquiry Completion Codes ................125 175 7.17 Trading Role Data Component ...............................125 176 7.17.1 Who Receives a Trading Role Data Component ..........126 177 7.18 Inquiry Type Component ....................................126 178 7.19 Signature Component .......................................127 179 7.19.1 IOTP usage of signature elements and attributes .....128 180 7.19.2 Offer Response Signature Component ..................130 181 7.19.3 Payment Receipt Signature Component .................131 182 7.19.4 Delivery Response Signature Component ...............132 183 7.19.5 Authentication Request Signature Component ..........132 184 7.19.6 Authentication Response Signature Component .........132 185 7.19.7 Inquiry Request Signature Component .................133 186 7.19.8 Inquiry Response Signature Component ................133 187 7.19.9 Ping Request Signature Component ....................133 188 7.19.10 Ping Response Signature Component...................133 189 7.20 Certificate Component .....................................133 190 7.20.1 IOTP usage of signature elements and attributes .....134 191 7.21 Error Component ...........................................134 192 7.21.1 Error Processing Guidelines .........................136 193 7.21.2 Error Codes .........................................138 194 7.21.3 Error Location Element ..............................141 196 8. Trading Blocks ...............................................143 197 8.1 Trading Protocol Options Block ............................145 198 8.2 TPO Selection Block .......................................146 199 8.3 Offer Response Block ......................................146 200 8.4 Authentication Request Block ..............................147 201 8.5 Authentication Response Block .............................149 202 8.6 Authentication Status Block ...............................149 203 8.7 Payment Request Block .....................................150 204 8.8 Payment Exchange Block ....................................151 205 8.9 Payment Response Block ....................................152 206 8.10 Delivery Request Block ....................................153 207 8.11 Delivery Response Block ...................................154 208 8.12 Inquiry Request Trading Block .............................155 209 8.13 Inquiry Response Trading Block ............................155 210 8.14 Ping Request Block ........................................156 211 8.15 Ping Response Block .......................................157 212 8.16 Signature Block ...........................................158 213 8.16.1 Signature Block with Offer Response .................159 214 8.16.2 Signature Block with Payment Request ................159 215 8.16.3 Signature Block with Payment Response ...............159 216 8.16.4 Signature Block with Delivery Request ...............159 217 8.16.5 Signature Block with Delivery Response ..............160 218 8.17 Error Block ...............................................160 219 8.18 Cancel Block ..............................................161 221 9. Internet Open Trading Protocol Transactions ..................162 222 9.1 Authentication and Payment Related IOTP Transactions ......162 223 9.1.1 Authentication Document Exchange ....................164 224 9.1.2 Offer Document Exchange .............................169 225 9.1.3 Payment Document Exchange ...........................176 226 9.1.4 Delivery Document Exchange ..........................181 227 9.1.5 Payment and Delivery Document Exchange ..............183 228 9.1.6 Baseline Authentication IOTP Transaction ............186 229 9.1.7 Baseline Deposit IOTP Transaction ...................187 230 9.1.8 Baseline Purchase IOTP Transaction ..................189 231 9.1.9 Baseline Refund IOTP Transaction ....................190 232 9.1.10 Baseline Withdrawal IOTP Transaction ................192 233 9.1.11 Baseline Value Exchange IOTP Transaction ............194 234 9.1.12 Valid Combinations of Document Exchanges ............196 235 9.1.13 Combining Authentication Transactions with other 236 Transactions ........................................199 237 9.2 Infrastructure Transactions ...............................200 238 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 201 239 9.2.2 Baseline Ping IOTP Transaction ......................205 241 10. Retrieving Logos .............................................209 242 10.1 Logo Size .................................................209 243 10.2 Logo Color Depth ..........................................210 244 10.3 Logo Net Location Examples ................................210 246 11. Brands .......................................................211 247 11.1 Brand Definitions and Brand Selection .....................211 248 11.1.1 Definition of Payment Instrument ....................211 249 11.1.2 Definition of Brand .................................212 250 11.1.3 Definition of Dual Brand ............................212 251 11.1.4 Definition of Promotional Brand .....................213 252 11.1.5 Identifying Promotional Brands ......................213 253 11.2 Brand List Examples .......................................215 254 11.2.1 Simple Credit Card Based Example ....................216 255 11.2.2 Credit Card Brand List Including Promotional Brands .217 256 11.2.3 Brand Selection Example .............................218 257 11.2.4 Complex Electronic Cash Based Brand List ............218 259 12. IANA Considerations ..........................................222 260 12.1 Codes Controlled by IANA ..................................222 261 12.2 Codes not controlled by IANA ..............................227 263 13. Internet Open Trading Protocol Data Type Definition ..........228 264 14. Glossary .....................................................241 266 15. Copyrights ...................................................248 268 16. References ...................................................249 270 17. Author's Address .............................................252 272 Table of Figures 274 Figure 1 IOTP Trading Roles 16 275 Figure 2 Offer Exchange 18 276 Figure 3 Payment Exchange 21 277 Figure 4 Delivery Exchange 23 278 Figure 5 Authentication Exchange 25 279 Figure 6 IOTP Message Structure 30 280 Figure 7 An IOTP Transaction 31 281 Figure 8 Example use of ID attributes 42 282 Figure 9 Element References 43 283 Figure 10 Signature Digests 70 284 Figure 11 Example use of Signatures for Baseline Purchase 72 285 Figure 12 Checking a Payment Handler can carry out a Payment 76 286 Figure 13 Checking a Delivery Handler can carry out a Delivery 78 287 Figure 14 Trading Components 81 288 Figure 15 Brand List Element Relationships 97 289 Figure 16 Trading Blocks 144 290 Figure 17 Payment and Authentication Message Flow Combinations 164 291 Figure 18 Authentication Document Exchange 166 292 Figure 19 Brand Dependent Offer Document Exchange 171 293 Figure 20 Brand Independent Offer Exchange 172 294 Figure 21 Payment Document Exchange 177 295 Figure 22 Delivery Document Exchange 182 296 Figure 23 Payment and Delivery Document Exchange 184 297 Figure 24 Baseline Authentication IOTP Transaction 187 298 Figure 25 Baseline Deposit IOTP Transaction 188 299 Figure 26 Baseline Purchase IOTP Transaction 190 300 Figure 27 Baseline Refund IOTP Transaction 192 301 Figure 28 Baseline Withdrawal IOTP Transaction 193 302 Figure 29 Baseline Value Exchange IOTP Transaction 195 303 Figure 30 Baseline Value Exchange Signatures 196 304 Figure 31 Valid Combinations of Document Exchanges 197 305 Figure 32 Baseline Transaction Status Inquiry 203 306 Figure 33 Baseline Ping Messages 206 308 1. Background 310 The Internet Open Trading Protocol (IOTP) provides an interoperable 311 framework for Internet commerce. It is payment system independent and 312 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 313 GeldKarte, etc. IOTP is able to handle cases where such merchant roles as 314 the shopping site, the Payment Handler, the Delivery Handler of goods or 315 services, and the provider of customer support are performed by different 316 parties or by one party. 318 The developers of IOTP seek to provide a virtual capability that safely 319 replicates the real world, the paper based, traditional, understood, 320 accepted methods of trading, buying, selling, value exchanging that has 321 existed for many hundreds of years. The negotiation of who will be the 322 parties to the trade, how it will be conducted, the presentment of an 323 offer, the method of payment, the provision of a payment receipt, the 324 delivery of goods and the receipt of goods. These are events that are 325 taken for granted in the course of real world trade. IOTP has been 326 produced to provide the same for the virtual world, and to prepare and 327 provide for the introduction of new models of trading made possible by 328 the expanding presence of the virtual world. 330 The other fundamental ideal of the IOTP effort is to produce a definition 331 of these trading events in such a way that no matter where produced, two 332 unfamiliar parties using electronic commerce capabilities to buy and sell 333 that conform to the IOTP specifications will be able to complete the 334 business safely and successfully. 336 In summary, IOTP supports: 338 o Familiar trading models 340 o New trading models 342 o Global interoperability 344 The remainder of this section provides background to why IOTP was 345 developed. The specification itself starts in the next chapter. 347 1.1 Commerce on the Internet, a Different Model 349 The growth of the Internet and the advent of electronic commerce are 350 bringing about enormous changes around the world in society, politics and 351 government, and in business. The ways in which trading partners 352 communicate, conduct commerce, are governed have been enriched and 353 changed forever. 355 One of the very fundamental changes about which IOTP is concerned is 356 taking place in the way consumers and merchants trade. Characteristics of 357 trading that have changed markedly include: 359 o Presence: Face-to-face transactions become the exception, not the rule. 360 Already with the rise of mail order and telephone order placement this 361 change has been felt in western commerce. Electronic commerce over the 362 Internet will further expand the scope and volume of transactions 363 conducted without ever seeing the people who are a part of the 364 enterprise with whom one does business. 366 o Authentication: An important part of personal presence is the ability 367 of the parties to use familiar objects and dialogue to confirm they are 368 who they claim to be. The seller displays one or several well known 369 financial logos that declaim his ability to accept widely used credit 370 and debit instruments in the payment part of a purchase. The buyer 371 brings government or financial institution identification that assures 372 the seller she will be paid. People use intangibles such as personal 373 appearance and conduct, location of the store, apparent quality and 374 familiarity with brands of merchandise, and a good clear look in the 375 eye to reinforce formal means of authentication. 377 o Payment Instruments: Despite the enormous size of bank card financial 378 payments associations and their members, most of the world's trade 379 still takes place using the coin of the realm or barter. The present 380 infrastructure of the payments business cannot economically support low 381 value transactions and could not survive under the consequent volumes 382 of transactions if it did accept low value transactions. 384 o Transaction Values: New meaning for low value transactions arises in 385 the Internet where sellers may wish to offer for example, pages of 386 information for fractions of currency that do not exist in the real 387 world. 389 o Delivery: New modes of delivery must be accommodated such as direct 390 electronic delivery. The means by which receipt is confirmed and the 391 execution of payment change dramatically where the goods or services 392 have extremely low delivery cost but may in fact have very high value. 393 Or, maybe the value is not high, but once delivery occurs the value is 394 irretrievably delivered so payment must be final and non-refundable but 395 delivery nonetheless must still be confirmed before payment. 396 Incremental delivery such as listening or viewing time or playing time 397 are other models that operate somewhat differently in the virtual 398 world. 400 1.2 Benefits of IOTP 402 ELECTRONIC COMMERCE SOFTWARE VENDORS 404 Electronic Commerce Software Vendors will be able to develop e-commerce 405 products which are more attractive as they will inter-operate with any 406 other vendors' software. However since IOTP focuses on how these 407 solutions communicate, there is still plenty of opportunity for product 408 differentiation. 410 PAYMENT BRANDS 412 IOTP provides a standard framework for encapsulating payment protocols. 413 This means that it is easier for payment products to be incorporated into 414 IOTP solutions. As a result the payment brands will be more widely 415 distributed and available on a wider variety of platforms. 417 MERCHANTS 419 There are several benefits for Merchants: 421 o they will be able to offer a wider variety of payment brands, 423 o they can be more certain that the customer will have the software 424 needed to complete the purchase 426 o through receiving payment and delivery receipts from their customers, 427 they will be able to provide customer care knowing that they are 428 dealing with the individual or organisation with which they originally 429 traded 431 o new merchants will be able to enter this new (Internet) market-place 432 with new products and services, using the new trading opportunities 433 which IOTP presents 435 BANKS AND FINANCIAL INSTITUTIONS 437 There are also several benefits for Banks and Financial Institutions: 439 o they will be able to provide IOTP support for merchants 441 o they will find new opportunities for IOTP related services: 442 - providing customer care for merchants 443 - fees from processing new payments and deposits 445 o they have an opportunity to build relationships with new types of 446 merchants 448 CUSTOMERS 450 For Customers there are several benefits: 452 o they will have a larger selection of merchants with whom they can trade 454 o there is a more consistent interface when making the purchase 456 o there are ways in which they can get their problems fixed through the 457 merchant (rather than the bank!) 459 o there is a record of their transaction which can be used, for example, 460 to feed into accounting systems or, potentially, to present to the tax 461 authorities 463 1.3 Baseline IOTP 465 This specification is Baseline IOTP. It is a Baseline in that it contains 466 ways of doing trades on the Internet which are the most common. The team 467 working on the IOTP see an extended version of this specification being 468 developed as needs demand but at this stage feel a need to develop a 469 limited function but usable specification in order that technology 470 providers can develop pathway-pilot products that will be placed in the 471 market in order to understand the real "market place" demands and 472 requirements for electronic trading or electronic commerce. 474 Accordingly the IOTP Baseline specification has been produced for 475 pathway-pilot product development, expecting to transact live trades to 476 prove the interoperability of solutions based on this specification. 478 During this period it is anticipated that there will be no changes to the 479 scope of this specification with the only changes made being limited to 480 corrections where problems are found. Software solutions have been 481 developed based on earlier versions of this specification (for example 482 version 0.9 published in early 1998) which prove that the basic concepts 483 work. 485 1.4 Objectives of Document 487 The objectives of this document are to provide a functional specification 488 of version 1.0 of the Internet Open Trading Protocols which can be used 489 to design and implement systems which support electronic trading on the 490 Internet using the Internet Open Trading Protocols. 492 The purpose of the document is: 494 o to allow potential developers of products based on the protocol to 495 start development of software/hardware solutions which use the protocol 497 o to allow the financial services industry to understand a developing 498 electronic commerce trading protocol that encapsulates (without 499 modification) any of the current or developing payment schemes now 500 being used or considered by their merchant customer base 502 1.5 Scope of Document 504 The protocol describes the content, format and sequences of messages that 505 pass among the participants in an electronic trade - consumers, merchants 506 and banks or other financial institutions, and customer care providers. 507 These are required to support the electronic commerce transactions 508 outlined in the objectives above. 510 The protocol is designed to be applicable to any electronic payment 511 scheme since it targets the complete purchase process where the movement 512 of electronic value from the payer to the payee is only one, but 513 important, step of many that may be involved to complete the trade. 515 Payment Scheme which IOTP could support include MasterCard Credit, Visa 516 Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, 517 Proton etc. 519 Each payment scheme contains some message flows which are specific to 520 that scheme. These scheme-specific parts of the protocol are contained in 521 a set of payment scheme supplements to this specification. 523 The document does not prescribe the software and processes that will need 524 to be implemented by each participant. It does describe the framework 525 necessary for trading to take place. 527 This document also does not address any legal or regulatory issues 528 surrounding the implementation of the protocol or the information systems 529 which use them. 531 1.6 Document Structure 533 The document consists of the following sections: 535 o Section 1 - Background: This section gives a brief background on 536 electronic commerce and the benefits IOTP offers. 538 o Section 2 - Introduction: This section describes the various Trading 539 Exchanges and shows how these trading exchanges are used to construct 540 the IOTP Transactions. This section also explains various Trading Roles 541 that would participate in electronic trade. 543 o Section 3 - Protocol Structure: This section summarises how various 544 IOTP transactions are constructed using the Trading Blocks and Trading 545 Components that are the fundamental building blocks for IOTP 546 transactions. All IOTP transaction messages are well formed XML 547 documents. 549 o Section 4 - IOTP Error Handling: This section describes how to process 550 exceptions and errors during the protocol message exchange and trading 551 exchange processing. This section provides a generic overview of the 552 exception handling. This section should be read carefully. 554 o Section 5 - Security Considerations: This section considers from an 555 IETF perspective, how IOTP addresses security. It includes: how to 556 determine whether to use digital signatures with IOTP, how IOTP address 557 data privacy, and how security built into payment protocols relate to 558 IOTP security. 560 o Section 6 - Digital Signatures and IOTP: This section provides an 561 overview of how IOTP uses digital signatures; how to check a signature 562 is correctly calculated and how the various Trading Roles that 563 participate in trade should check signatures when required. 565 o Section 7 - Trading Components: This section defines the XML elements 566 required by Trading Components. 568 o Section 8 - Trading Blocks: This section describes how Trading Blocks 569 are constructed from Trading Components. 571 o Section 9 - Internet Open Trading Protocol Transactions: This section 572 describes all the IOTP Baseline transactions. It refers to Trading 573 Blocks and Trading Components and Signatures. This section doesn't 574 directly link error handling during the protocol exchanges, the reader 575 is advised to understand Error Handling as defined in section before 576 reading this section. 578 o Section 10 - Retrieving Logos: This section describes how IOTP specific 579 logos can be retrieved. 581 o Section 11 - Brands: This section provides: an overview of Brand 582 Definitions and Brand Selection which describe how a Consumer can 583 select a Brand from a list provided by the Merchant; as well as some 584 examples of Brand Lists. 586 o Section 12 - IANA Considerations: This section describes how new values 587 for codes used by IOTP are co-ordinated. 589 o Section 13 - Internet Open Trading Protocol Data Type Definition: This 590 section contains the XML Data Type Definitions for IOTP. 592 o Section 14 - Glossary. This describes all the major terminology used by 593 IOTP. 595 o Section 15 - Copyright information. 597 o Section 16 - A list of the other documents referenced by the IOTP 598 specification. 600 o Section 17 - The Author's Address 602 1.7 Intended Readership 604 Software and hardware developers; development analysts; business and 605 technical planners; industry analysts; merchants; bank and other payment 606 handlers; owners, custodians, and users of payment protocols. 608 1.7.1 Reading Guidelines 610 This IOTP specification is structured primarily in a sequence targeted at 611 people who want to understand the principles of IOTP. However from 612 practical implementation experience by implementers of earlier of 613 versions of the protocol new readers who plan to implement IOTP may 614 prefer to read the document in a different sequence as described below. 616 Review the transport independent parts of the specification: This covers 618 o Section 14 - Glossary 620 o Section 1 - Background 622 o Section 2 - Introduction 624 o Section 3 - Protocol Structure 626 o Section 4 - IOTP Error Handling 628 o Section 5 - Security Considerations 630 o Section 9 - Internet Open Trading Protocol Transactions 632 o Section 11 - Brands 634 o Section 12 - IANA Considerations 636 o Section 10 - Retrieving Logos 638 Review the detailed XML definitions: 640 o Section 8 - Trading Blocks 642 o Section 7 - Trading Components 644 o Section 6 - Digital Signatures and IOTP 646 2. Introduction 648 The Internet Open Trading Protocols (IOTP) define a number of different 649 types of IOTP Transactions: 651 o Purchase. This supports a purchase involving an offer, a payment and 652 optionally a delivery 654 o Refund. This supports the refund of a payment as a result of, 655 typically, an earlier purchase 657 o Value Exchange. This involves two payments which result in the exchange 658 of value from one combination of currency and payment method to another 660 o Authentication. This supports one organisation or individual to check 661 that another organisation or individual are who they appear to be. 663 o Withdrawal. This supports the withdrawal of electronic cash from a 664 financial institution 666 o Deposit. This supports the deposit of electronic cash at a financial 667 institution 669 o Inquiry This supports inquiries on the status of an IOTP transaction 670 which is either in progress or is complete 672 o Ping This supports a simple query which enables one IOTP aware 673 application to determine whether another IOTP application running 674 elsewhere is working or not. 676 These IOTP Transactions are "Baseline" transactions since they have been 677 identified as a minimum useful set of transactions. Later versions of 678 IOTP may include additional types of transactions. 680 Each of the IOTP Transactions above involve: 682 o a number organisations playing a Trading Role, and 684 o a set of Trading Exchanges. Each Trading Exchange involves the exchange 685 of data, between Trading Roles, in the form of a set of Trading 686 Components. 688 Trading Roles, Trading Exchanges and Trading Components are described 689 below. 691 2.1 Trading Roles 693 The Trading Roles identify the different parts which organisations can 694 take in a trade. The six Trading Roles used within IOTP are illustrated 695 in the diagram below. 697 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 699 Merchant Customer Care Provider resolves ---------- 700 ---------------------------------------------->| Merchant | 701 | Consumer disputes and problems |Cust.Care.| 702 | | Provider | 703 | ---------- 704 | 705 Payment Handler accepts or makes ---------- 706 | ------------------------------------------>| Payment | 707 | | Payment for Merchant | Handler | 708 | | ---------- 709 v v 710 ---------- Consumer makes purchases or obtains ---------- 711 | Consumer |<--------------------------------------->| Merchant | 712 ---------- refund from Merchant ---------- 713 ^ 714 | Delivery Handler supplies goods or ---------- 715 |---------------------------------------------->|Deliverer | 716 services for Merchant ---------- 718 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 720 Figure 1 IOTP Trading Roles 722 The roles are: 724 o Consumer. The person or organisation which is to receive and pay for 725 the goods or services 727 o Merchant. The person or organisation from whom the purchase is being 728 made and who is legally responsible for providing the goods or services 729 and receives the benefit of the payment made 731 o Payment Handler. The entity that physically receives the payment from 732 the Consumer on behalf of the Merchant 734 o Delivery Handler. The entity that physically delivers the goods or 735 services to the Consumer on behalf of the Merchant. 737 o Merchant Customer Care Provider. The entity that is involved with 738 customer dispute negotiation and resolution on behalf of the Merchant 740 Roles may be carried out by the same organisation or different 741 organisations. For example: 743 o in the simplest case one physical organisation (e.g. a merchant) could 744 handle the purchase, accept the payment, deliver the goods and provide 745 merchant customer care 747 o at the other extreme, a merchant could handle the purchase but instruct 748 the consumer to pay a bank or financial institution, request that 749 delivery be made by an overnight courier firm and to contact an 750 organisation which provides 24x7 service if problems arise. 752 Note that in this specification, unless stated to the contrary, when the 753 words Consumer, Merchant, Payment Handler, Delivery Handler or Customer 754 Care Provider are used, they refer to the Trading Role rather than an 755 actual organisation. 757 An individual organisation may take multiple roles. For example a company 758 which is selling goods and services on the Internet could take the role 759 of Merchant when selling goods or services and the role of Consumer when 760 the company is buying goods or services itself. 762 As roles occur in different places there is a need for the organisations 763 involved in the trade to exchange data, i.e. to carry out Trading 764 Exchanges, so that the trade can be completed. 766 2.2 Trading Exchanges 768 The Internet Open Trading Protocols identify four Trading Exchanges which 769 involve the exchange of data between the Trading Roles. The Trading 770 Exchanges are: 772 o Offer. The Offer Exchange results in the Merchant providing the 773 Consumer with the reason why the trade is taking place. It is called an 774 Offer since the Consumer must accept the Offer if a trade is to 775 continue 777 o Payment. The Payment Exchange results in a payment of some kind between 778 the Consumer and the Payment Handler. This may occur in either 779 direction 781 o Delivery. The Delivery Exchange transmits either the on-line goods, or 782 delivery information about physical goods from the Delivery Handler to 783 the Consumer, and 785 o Authentication. The Authentication Exchange can be used by any Trading 786 Role to authenticate another Trading Role to check that they are who 787 they appear to be. 789 IOTP Transactions are composed of various combinations of these Trading 790 Exchanges. For example, an IOTP Purchase transaction includes Offer, 791 Payment, and Delivery Trading Exchanges. As another example, an IOTP 792 Value Exchange transaction is composed of an Offer Trading Exchange and 793 two Payment Trading Exchanges. 795 Trading Exchanges consist of Trading Components that are transmitted 796 between the various Trading Roles. Where possible, the number of round- 797 trip delays in an IOTP Transaction is minimised by packing the Components 798 from several Trading Exchanges into combination IOTP Messages. For 799 example, the IOTP Purchase transaction combines a Delivery Organisation 800 Component with an Offer Response Component in order to avoid an extra 801 Consumer request and response. 803 Each of the IOTP Trading Exchanges is described in more detail below. For 804 clarity of description, these describe the Trading Exchanges as though 805 they were standalone operations. For performance reasons, the Trading 806 Exchanges are intermingled in the actual IOTP Transaction definitions. 808 2.2.1 Offer Exchange 810 The goal of the Offer Exchange is for the Merchant to provide the 811 Consumer with information about the trade so that the Consumer can decide 812 whether to continue with the trade. This is illustrated in the figure 813 below. 815 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 816 Consumer 817 | Merchant 818 STEP | | 819 1. Consumer decides to trade and sends information about the 820 transaction (requests an offer) to the Merchant e.g. using 821 HTML. 823 C --> M Data: Information on what is being purchased (Offer Request) 824 - outside scope of IOTP 826 2. Merchant checks the information provided by the Consumer, 827 creates an Offer optionally signs it and sends it to the 828 Consumer. 830 C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer, 831 DeliverTo, Merchant, Payment Handler, Customer Care); Order; 832 Pay Amount; Delivery; Optional Offer Response Signature that 833 signs other components 835 3. Consumer checks the information from the Merchant and decides 836 whether to continue. 838 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 840 Figure 2 Offer Exchange 842 An Offer Exchange uses the following Trading Components that are passed 843 between the Consumer and the Merchant: 845 o the Organisation Component contains information which describes the 846 organisations which are taking a role in the trade: 847 - the consumer provides information, about who the consumer is and, if 848 goods or services are being delivered, where the goods or services 849 are to be delivered to 851 - the merchant augments this information by providing information about 852 the merchant, the Payment Handler, the customer care provider and, if 853 goods or services are being delivered, the Delivery Handler 855 o the Order Component contains descriptions of the goods or services 856 which will result from the trade if the consumer agrees to the offer. 857 This information is sent by the Merchant to the consumer who should 858 verify it 860 o the Payment Component generated by the Merchant, contains details of 861 how much to pay, the currency and the payment direction, for example 862 the consumer could be asking for a refund. Note that there may be more 863 than one payment in a trade 865 o the Delivery Component, also generated by the Merchant, is used if 866 goods or services are being delivered. This contains information about 867 how delivery will occur, for example by post or using e-mail 869 o the "Offer Response" Signature Component, if present, digitally signs 870 all of the above components to ensure their integrity. 872 The exact content of the information provided by the Merchant to the 873 Consumer will vary depending on the type of IOTP Transaction. For 874 example: 876 o low value purchases may not need a signature 878 o the amount to be paid may vary depending on the payment brand and 879 payment protocol used 881 o some offers may not involve the delivery of any goods 883 o a value exchange will involve two payments 885 o a merchant may not offer customer care. 887 Information provided by the consumer to the merchant is provided using a 888 variety of methods, for example, it could be provided: 890 o using [HTML] pages as part of the "shopping experience" of the 891 consumer. 893 o Using the Open Profiling Standard [OPS] which has recently been 894 proposed, 896 o in the form of Organisation Components associated with an 897 authentication of a Consumer by a Merchant 899 o as Order Components in a later version of IOTP. 901 2.2.2 Payment Exchange 903 The goal of the Payment Exchange is for a payment to be made from the 904 Consumer to a Payment Handler or vice versa using a payment brand and 905 payment protocol selected by the Consumer. A secondary goal is to 906 optionally provide the Consumer with a digitally signed Payment Receipt 907 which can be used to link the payment to the reason for the payment as 908 described in the Offer Exchange. 910 Payment Exchanges can work in a variety of ways. The most general case 911 where the trade is dependent on the payment brand and protocol used is 912 illustrated in the diagram below. Simpler payment exchanges are possible. 913 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 914 Consumer Pay Handler 915 | Merchant | 916 STEP | | | 917 1. Consumer decides to trade and sends information about 918 the transaction (requests an offer) to the Merchant 919 e.g. using HTML. 921 C --> M Information on what is being paid for (outside scope 922 of IOTP 924 2. Merchant decides which payment brand, payment 925 protocols and currencies/amounts to offer, places then 926 in a Brand List Component and sends them to the 927 Consumer 929 C <-- M Components: Brand List 931 3. Consumer selects the payment brand, protocol and 932 currency/amount to use, creates a Brand Selection 933 component and sends it to the Merchant 935 C --> M Component: Brand List Selection 937 4. Merchant checks Brand Selection, creates a Payment 938 Amount information, optionally signs it to authorise 939 payment and sends it to the Consumer 941 C <-- M Component: Pay Amount; Organisation(s) (Merchant and 942 Payment Handler); Optional Offer Response Signature 943 that signs other components 945 5. Consumer checks the Payment Amount information and if 946 OK requests that the payment starts by sending 947 information to the Payment Handler 949 C --------> P PAYMENT REQUEST. Components: Pay Amount; Organisations 950 (Merchant and Payment Handler); Optional Offer 951 Response Signature that signs other components; Pay 952 Scheme 954 6. Payment Handler checks information including optional 955 signature and if OK starts exchanging Pay Scheme 956 components for selected payment brand and payment 957 protocol 959 C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme 961 7. Eventually payment protocol messages finish so Payment 962 Handler sends Pay Receipt and optional signature to 963 the Consumer as proof of payment 965 C <-------> P PAYMENT RESPONSE. Components: Pay Receipt; Payment 966 Note; Optional Offer Response Signature; Optional 967 Payment Receipt Signature that binds the payment to 968 the Offer 970 8. Consumer checks Payment Receipt is OK 972 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 974 Figure 3 Payment Exchange 976 A Payment Exchange uses the following Trading Components that are passed 977 between the Consumer, the Merchant and the Payment Handler: 979 o The Brand List Component contains a list of payment brands (for 980 example, MasterCard, Visa, Mondex, GeldKarte), payment protocols (for 981 example SET Version 1.0, Secure Channel Credit Debit (SCCD - the name 982 used for a credit or debit card payment where unauthorised access to 983 account information is prevented through use of secure channel 984 transport mechanisms such as SSL/TLS) as well as currencies/amounts 985 that apply. The Merchant sends the Brand List to the Consumer. The 986 consumer compares the payment brands, protocols and currencies/amounts 987 on offer with those that the Consumer supports and makes a selection. 989 o The Brand Selection Component contains the Consumer's selection. 990 Payment brand, protocol, currency/amount and possibly protocol-specific 991 information is sent back to the Merchant. This information may be used 992 to change information in the Offer Exchange. For example, a merchant 993 could choose to offer a discount to encourage the use of a store card. 995 o The Organisation Components are generated by the Merchant. They contain 996 details of the Merchant and Payment Handler Roles: 997 - the Merchant role is required so that the Payment Handler can 998 identify which Merchant initiated the payment. Typically, the result 999 of the Payment Handler accepting (or making) a payment on behalf of 1000 the Merchant will be a credit or debit transaction to the Merchant's 1001 account held by the Payment Handler. These transactions are outside 1002 the scope of this version of IOTP 1003 - the Payment Handler role is required so that the Payment Handler can 1004 check that it is the correct Payment Handler to be used for the 1005 payment 1007 o The Payment Component contains details of how much to pay, the currency 1008 and the payment direction 1010 o The "Offer Response" Signature Component, if present, digitally signs 1011 all of the above components to ensure their integrity. Note that the 1012 Brand List and Brand Selection Components are not signed until the 1013 payment information is created (step 4 in the diagram) 1015 o The Payment Scheme Component contains messages from the payment 1016 protocol used in the Trade. For example they could be SET messages, 1017 Mondex messages, GeldKarte Messages or one of the other payment methods 1018 supported by IOTP. The content of the Payment Scheme Component is 1019 defined in the supplements that describe how IOTP works with various 1020 payment protocols. 1022 o The Payment Receipt Component contains a record of the payment. The 1023 content depends upon the payment protocol used. 1025 o The "Payment Receipt" Signature Component provides proof of payment by 1026 digitally signing both the Payment Receipt Component and the Offer 1027 Response Signature. The signature on the offer digitally signs the 1028 Order, Organisation and Delivery Components contained in the Offer. 1029 This signature effectively binds the payment to the offer. 1031 The example of a Payment Exchange above is the most general case. Simpler 1032 cases are also possible. For example, if the amount paid is not dependent 1033 on the payment brand and protocol selected then the payment information 1034 generated by step 3 can be sent to the Consumer at the same time as the 1035 Brand List Component generated by step 1. These and other variations are 1036 described in the Baseline Purchase IOTP Transaction (see section 9.1.8). 1038 2.2.3 Delivery Exchange 1040 The goal of the Delivery Exchange is to cause purchased goods to be 1041 delivered to the consumer either online or via physical delivery. A 1042 second goal is to provide a "delivery note" to the consumer, providing 1043 details about the delivery, such as shipping tracking number. The result 1044 of the delivery may also be signed so that it can be used for customer 1045 care in the case of problems with physical delivery. The message flow is 1046 illustrated in the diagram below. 1048 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1049 CONSUMER DELIVERY 1050 | HANDLER 1051 | Merchant | 1052 STEP | | | 1053 1. Consumer decides to trade and sends information about 1054 what to deliver and who is to take delivery, to the 1055 Merchant e.g. using HTML. 1057 C --> M Information on what is being delivered (outside scope 1058 of IOTP) 1060 2. Merchant checks the information provided by the 1061 Consumer, adds information about how the delivery will 1062 occur, information about the organisations involved in 1063 the delivery and optionally sings it and sends it to 1064 the Consumer 1066 C <-- M Components: Delivery; Organisations (Delivery Handler, 1067 Deliver To); Order, Optional Offer Response Signature 1069 3. Consumer checks delivery information is OK, obtains 1070 authorisation for the delivery, for example by making 1071 a payment, and sends the delivery information to the 1072 Delivery Handler 1074 C --------> D DELIVERY REQUEST. Components: Delivery, Organisations: 1075 (Merchant, Delivery Handler, DelivTo); Order, Optional 1076 Offer Response Signature, Optional Payment Receipt 1077 Signature (from Payment Exchange) 1079 4. Delivery Handler checks information and authorisation. 1080 Starts or schedules delivery and creates and then 1081 sends a delivery not tot the Consumer which can 1082 optionally be signed. 1084 C <-------- D DELIVERY RESPONSE. Components: Delivery Note, Optional 1085 Delivery Response Signature 1087 5. Consumer checks delivery note is OK and accepts or 1088 waits for delivery as described in the the Delivery 1089 Note. 1091 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1093 Figure 4 Delivery Exchange 1095 A Delivery Exchange uses the following Trading Components that are passed 1096 between the Consumer, the Merchant and the Delivery Handler: 1098 o The Organisation Component(s) contain details of the Deliver To, 1099 Delivery Handler and Merchant Roles: 1100 - the Deliver To role indicates where the goods or services are to be 1101 delivered to 1102 - the Delivery Handler role is required so that the Delivery Handler 1103 can check that she is the correct Delivery Handler to do the delivery 1104 - the Merchant role is required so that the Delivery Handler can 1105 identify which Merchant initiated the delivery 1107 o The Order Component, contains information about the goods or services 1108 to be delivered 1110 o The Delivery Component contains information about how delivery will 1111 occur, for example by post or using e-mail. 1113 o The "Offer Response" Signature Component, if present, digitally signs 1114 all of the above components to ensure their integrity. 1116 o The "Payment Receipt" Signature Component provides proof of payment by 1117 digitally signing the Payment Receipt Component and the Offer 1118 Signature. This is used by the Delivery Handler to check that delivery 1119 is authorised 1121 o The Delivery Note Component contains customer care information related 1122 to a physical delivery, or alternatively the actual "electronic goods". 1123 The Consumer's software does not interpret information about a physical 1124 delivery but should have the ability to display the information, both 1125 at the time of the delivery and later if the Consumer selects the Trade 1126 to which this delivery relates from a transaction list 1128 o The "Delivery Response" Signature Component, if present, provides proof 1129 of the results of the Delivery by digitally signing the Delivery Note 1130 and any Offer Response or Payment Response signatures that the Delivery 1131 Handler received. 1133 2.2.4 Authentication Exchange 1135 The goal of the Authentication Exchange is to allow one organisation, for 1136 example a financial institution, to be able to check that another 1137 organisation, for example a consumer, is who they appear to be. 1139 An Authentication Exchange involves: 1141 o an Authenticator - the organisation which is requesting the 1142 authentication, and 1144 o an Authenticatee - the organisation being authenticated. 1146 This is illustrated in the diagram below. 1148 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1149 Organisation 1 1150 (Authenticatee) 1151 | Organisation 2 1152 | (Authenticator) 1153 STEP | | 1154 1. First organisation, e.g. a Consumer, takes an action (for 1155 example by pressing a button on an HTML page) which requires 1156 that the organisation is authenticated 1158 1 --> 2 Need for Authentication (outside scope of IOTP) 1160 2. The second organisation generates an Authentication Request - 1161 including challenge data, and a list of the algorithms that 1162 may be used for the authentication - and/or a request for the 1163 Organisation information then sends it to the first 1164 organisation 1166 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, 1167 Trading Role Information Request 1169 3. The first organisation optionally checks any signature 1170 associated with the Authentication Request then uses the 1171 specified authentication algorithm to generate an 1172 Authentication Response which is sent back to the second 1173 organisation together with details of any Organisation 1174 information requested 1176 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, 1177 Organisation(s) 1179 4. The Authentication Response is checked against the challenge 1180 data to check that the first organisation is who they appear 1181 to be and the result recorded in a Status Component which is 1182 then sent back to the first organisation. 1184 1 <-- 2 AUTHENTICATION STATUS. Component: Status 1186 5. The first organisation then optionally checks the results 1187 indicated by the Status and any associated signature and 1188 takes the appropriate action or stops. 1190 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1192 Figure 5 Authentication Exchange 1194 An Authentication Exchange uses the following Trading Components that are 1195 passed between the two organisations: 1197 o the Authentication Request Component that requests an Authentication 1198 and indicates the authentication algorithm and optional challenge data 1199 to be used. 1201 o A Trading Role Information Request Component that requests information 1202 about an Organisation, for example a ship to or billing address. 1204 o The Authentication Response Component which contains the challenge 1205 response generated by the recipient of the Authentication Request 1206 Component. 1208 o Organisation Components that contain the result of the Trading Role 1209 Information Request 1211 o the Status Component which contains the results of the second party's 1212 verification of the Authentication Response. 1214 2.3 Scope of Baseline IOTP 1216 This specification describes the IOTP Transactions which make up Baseline 1217 IOTP. As described in the preface, IOTP will evolve over time. This 1218 section defines the initial conformance criteria for implementations that 1219 claim to "support IOTP." 1221 The main determinant on the scope of an IOTP implementation is the roles 1222 which the solution is designed to support. The roles within IOTP are 1223 described in more detail in section 2.1 Trading Roles. To summarise the 1224 roles are: Merchant, Consumer, Payment Handler, Delivery Handler and 1225 Customer Care Provider. 1227 Payment Handlers who can be of three types: 1229 o those who accept a payment as part of a purchase or make a payment as 1230 part of a refund, 1232 o those who accept value as part of a deposit transaction, or 1234 o those that issue value a withdrawal transaction 1236 The following table defines, for each role, the IOTP Transactions and 1237 Trading Blocks which must be supported for that role. 1239 Merchants 1241 ECash ECash 1242 Store Value Value Consumer Payment Delivery 1243 Issuer Acquirer Handler Handler 1245 TRANSACTIONS 1247 Purchase Must Must 1249 Refund Must b) 1250 Depends 1252 Authentication May Must May b) 1253 Depends 1255 Value Exchange May Must 1257 Withdrawal Must b) 1258 Depends 1260 Deposit Must b) 1261 Depends 1263 Inquiry Must Must Must Must Must Must 1265 Ping Must Must Must Must Must Must 1266 Merchants 1268 ECash ECash 1269 Store Value Value Consumer Payment Delivery 1270 Issuer Acquirer Handler Handler 1272 TRADING BLOCKS 1274 TPO Must Must Must Must 1276 TPO Selection Must Must Must Must 1278 Auth-Request a) a) a) 1279 Depends Depends Depends 1281 Auth-Reply a) a) a) 1282 Depends Depends Depends 1284 Offer Response Must Must Must Must 1286 Payment Must Must 1287 Request 1289 Payment Must Must 1290 Exchange 1292 Payment Must Must 1293 Response 1295 Delivery Must Must 1296 Request 1298 Delivery Must Must 1299 Response 1301 Inquiry Must Must Must Must Must Must 1302 Request 1304 Inquiry Must Must Must Must Must Must 1305 Response 1307 Ping Request Must Must Must Must Must Must 1309 Ping Response Must Must Must Must Must Must 1311 Signature Must Must Must Limited Must Must 1313 Error Must Must Must Must Must Must 1315 In the above table: 1317 o "Must" means that a Trading Role must support the Transaction or 1318 Trading Block. 1320 o "May" means that an implementation may support the Transaction or 1321 Trading Block at the option of the developer. 1323 o "Depends" means implementation of the Transaction or Trading Block 1324 depends on one of the following conditions: 1325 - if Baseline Authentication IOTP Transaction is supported; 1326 - if required by a Payment Method as defined in its IOTP Supplement 1327 document. 1329 o "Limited" means the Trading Block must be understood and its content 1330 manipulated but not in every respect. Specifically, on the Signature 1331 Block, Consumers do not have to be able to validate digital signatures. 1333 An IOTP solution must support all the IOTP Transactions and Trading 1334 Blocks required by at least one role (column) as described in the above 1335 table for that solution to be described as "supporting IOTP". 1337 3. Protocol Structure 1339 The previous section provided an introduction which explained: 1341 o Trading Roles which are the different roles which organisations can 1342 take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler 1343 and Customer Care Provider, and 1345 o Trading Exchanges where each Trading Exchange involves the exchange of 1346 data, between Trading Roles, in the form of a set of Trading 1347 Components. 1349 This section describes: 1351 o how Trading Components are constructed into Trading Blocks and the IOTP 1352 Messages which are physically sent in the form of [XML] documents 1353 between the different Trading Roles, 1355 o how IOTP Messages are exchanged between Trading Roles to create an IOTP 1356 Transaction 1358 o the XML definitions of an IOTP Message including a Transaction 1359 Reference Block - an XML element which identifies an IOTP Transaction 1360 and the IOTP Message within it 1362 o the definitions of the XML ID Attributes which are used to identify 1363 IOTP Messages, Trading Blocks and Trading Components and how these are 1364 referred to using Element References from other XML elements 1366 o how extra XML Elements and new user defined values for existing IOTP 1367 codes can be used when Extending IOTP, 1369 o how IOTP uses the Packaged Content Element to embed data such as 1370 payment protocol messages or detailed order definitions within an IOTP 1371 Message 1373 o how IOTP Identifies Languages so that different languages can be used 1374 within IOTP Messages 1376 o how IOTP handles both Secure and Insecure Net Locations when sending 1377 messages 1379 o how an IOTP Transaction can be cancelled. 1381 3.1 Overview 1383 3.1.1 IOTP Message Structure 1385 The structure of an IOTP Message and its relationship with Trading Blocks 1386 and Trading Components is illustrated in the diagram below. 1388 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1390 IOTP MESSAGE <---------- IOTP Message - an XML Document which is 1391 | transported between the Trading Roles 1392 |-Trans Ref Block <----- Trans Ref Block - contains information which 1393 | | describes the IOTP Transaction and the IOTP 1394 | | Message. 1395 | |-Trans Id Comp. <--- Transaction Id Component - uniquely 1396 | | identifies the IOTP Transaction. The Trans Id 1397 | | Components are the same across all IOTP 1398 | | messages that comprise a single IOTP 1399 | | transaction. 1400 | |-Msg Id Comp. <----- Message Id Component - identifies and 1401 | describes an IOTP Message within an IOTP 1402 | Transaction 1403 |-Signature Block <----- Signature Block (optional) - contains one or 1404 | | more Signature Components and their 1405 | | associated Certificates 1406 | |-Signature Comp. <-- Signature Component - contains digital 1407 | | signatures. Signatures may sign digests of 1408 | | the Trans Ref Block and any Trading Component 1409 | | in any IOTP Message in the same IOTP 1410 | | transaction. 1411 | |-Certificate Comp. < Certificate Component (Optional) Used to check 1412 | the signature. 1413 |-Trading Block <------- Trading Block - an XML Element within an IOTP 1414 | |-Trading Comp. Message that contains a predefined set of 1415 | |-Trading Comp. Trading Components 1416 | |-Trading Comp. 1417 | |-Trading Comp. <--- Trading Components - XML Elements within a 1418 | Trading Block that contain a predefined set 1419 |-Trading Block of XML elements and attributes containing 1420 | |-Trading Comp. information required to support a Trading 1421 | |-Trading Comp. Exchange 1422 | |-Trading Comp. 1423 | |-Trading Comp. 1424 | |-Trading Comp. 1426 *-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1428 Figure 6 IOTP Message Structure 1430 The diagram also introduces the concept of a Transaction Reference Block. 1431 This block contains, amongst other things, a globally unique identifier 1432 for the IOTP Transaction. Also each block and component is given an ID 1433 Attribute (see section 3.4) which is unique within an IOTP Transaction. 1434 Therefore the combination of the ID attribute and the globally unique 1435 identifier in the Transaction Reference Block is sufficient to uniquely 1436 identify any Trading Block or Trading Component. 1438 3.1.2 IOTP Transactions 1440 A predefined set of IOTP Messages exchanged between the Trading Roles 1441 constitute an IOTP Transaction. This is illustrated in the diagram below. 1443 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1445 CONSUMER MERCHANT 1446 Generate first 1447 IOTP Message 1448 --- | 1449 | | v 1450 Process incoming | I | ------------- 1451 IOTP Message & <------------- | | ------------ | IOTP Message | 1452 generate next IOTP | | ------------- 1453 Message | N | 1454 | | | 1455 v | | 1456 ------------- | T | Process incoming 1457 | IOTP Message | -------------- | | -----------> IOTP Message & 1458 ------------- | | generate next 1459 | E | IOTP Message 1460 | | | 1461 | | v 1462 Process incoming | R | ------------- 1463 IOTP Message <------------- | | ------------ | IOTP Message | 1464 generate last IOTP | | ------------- 1465 Message & stop | N | 1466 | | | 1467 v | | 1468 ------------- | E | Process last 1469 | IOTP Message | -------------- | | -------------> incoming IOTP 1470 ------------- | | Message & stop 1471 | | T | | 1472 v | | v 1473 STOP --- STOP 1475 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 1477 Figure 7 An IOTP Transaction 1479 In the above diagram the Internet is shown as the transport mechanism. 1480 This is not necessarily the case. IOTP Messages can be transported using 1481 a variety of transport mechanisms. 1483 The IOTP Transactions (see section 9) in this version of IOTP are 1484 specifically: 1486 o Purchase. This supports a purchase involving an offer, a payment and 1487 optionally a delivery 1489 o Refund. This supports the refund of a payment as a result of, 1490 typically, an earlier purchase 1492 o Value Exchange. This involves two payments which result in the exchange 1493 of value from one combination of currency and payment method to another 1495 o Authentication. This supports the remote authentication of one Trading 1496 Role by another Trading Role using a variety of authentication 1497 algorithms, and the provision of an Organisation Information about the 1498 Trading Role that is being authenticated for use in, for example, the 1499 creation of an offer 1501 o Withdrawal. This supports the withdrawal of electronic cash from a 1502 financial institution 1504 o Deposit. This supports the deposit of electronic cash at a financial 1505 institution 1507 o Inquiry This supports inquiries on the status of an IOTP transaction 1508 which is either in progress or is complete 1510 o Ping This supports a simple query which enables one IOTP aware 1511 application to determine whether another IOTP application running 1512 elsewhere is working or not. 1514 3.2 IOTP Message 1516 As described earlier, IOTP Messages are [XML] documents which are 1517 physically sent between the different Trading Roles that are taking part 1518 in a trade. 1520 The XML definition of an IOTP Message is as follows. 1522 1544 1548 Content: 1550 TransRefBlk This contains information which describes an IOTP 1551 Message within an IOTP Transaction (see section 1552 3.3 immediately below) 1554 AuthReqBlk, These are the Trading Blocks. 1555 AuthRespBlk, 1556 DeliveryReqBlk, The Trading Blocks present within an IOTP Message, 1557 DeliveryRespBlk and the content of a Trading Block itself is 1558 ErrorBlk dependent on the type of IOTP Transaction being 1559 InquiryReqBlk, carried out - see the definition of each 1560 InquiryRespBlk, transaction in section 9 Internet Open Trading 1561 OfferRespBlk, Protocol Transactions. 1562 PayExchBlk, 1563 PayReqBlk, Full definitions of each Trading Block are 1564 PayRespBlk, described in section 8. 1565 PingReqBlk, 1566 PingRespBlk, 1567 SigBlk, 1568 TpoBlk, 1569 TpoSelectionBlk 1571 Attributes: 1573 xmlns:iotp The [XML Namespace] definition for IOTP messages. 1575 3.2.1 XML Document Prolog 1577 The IOTP Message is the root element of the XML document. It therefore 1578 needs to be preceded by an appropriate XML Document Prolog. For example: 1580 1581 1582 1583 ... 1584 1586 3.3 Transaction Reference Block 1588 A Transaction Reference Block contains information which identifies the 1589 IOTP Transaction and IOTP Message. The Transaction Reference Block 1590 contains: 1592 o a Transaction Id Component which globally uniquely identifies the IOTP 1593 Transaction. The Transaction Id Components are the same across all IOTP 1594 messages that comprise a single IOTP transaction, 1596 o a Message Id Component which provides control information about the 1597 IOTP Message as well as uniquely identifying the IOTP Message within an 1598 IOTP Transaction, and 1600 o zero or more Related To Components which link this IOTP Transaction to 1601 either other IOTP Transactions or other events using the identifiers of 1602 those events. 1604 The definition of a Transaction Reference Block is as follows: 1606 1607 1610 Attributes: 1612 ID An identifier which uniquely identifies the 1613 Transaction Reference Block within the IOTP 1614 Transaction (see section 3.4 ID Attributes). 1616 Content: 1618 TransId See 3.3.1 Transaction Id Component immediately 1619 below. 1621 MsgId See 3.3.2 Message Id Component immediately below. 1623 RelatedTo See 3.3.3 Related To Component immediately below. 1625 3.3.1 Transaction Id Component 1627 This contains information which globally uniquely identifies the IOTP 1628 Transaction. Its definition is as follows: 1630 1631 1638 Attributes: 1640 ID An identifier which uniquely identifies the 1641 Transaction Id Component within the IOTP 1642 Transaction. 1644 Version This identifies the version of IOTP, and therefore 1645 the structure of the IOTP Messages, which the IOTP 1646 Transaction is using. 1648 IotpTransId Contains data which uniquely identifies the IOTP 1649 Transaction. It must conform to the rules for 1650 Message Ids in [RFC 822]. 1652 IotpTransTyp This is the type of IOTP Transaction being carried 1653 out. For Baseline IOTP it identifies a "standard" 1654 IOTP Transaction and implies the sequence and 1655 content of the IOTP Messages exchanged between the 1656 Trading Roles. The valid values for Baseline IOTP 1657 are: 1658 o BaselineAuthentication 1659 o BaselineDeposit 1660 o BaselinePurchase 1661 o BaselineRefund 1662 o BaselineWithdrawal 1663 o BaselineValueExchange 1664 o BaselineInquiry 1665 o BaselinePing 1667 Values of IotpTransType are managed under the 1668 procedure described in section 12 IANA 1669 Considerations which also allows user defined 1670 values of IotpTransType to be defined. 1672 In later versions of IOTP, this list will be 1673 extended to support different types of standard 1674 IOTP Transaction. It is also likely to support the 1675 type Dynamic which indicates that the sequence of 1676 steps within the transaction are non-standard. 1678 TransTimeStamp Where the system initiating the IOTP Transaction 1679 has an internal clock, it is set to the time at 1680 which the IOTP Transaction started in [UTC] 1681 format. 1683 The main purpose of this attribute is to provide 1684 an alternative way of identifying a transaction by 1685 specifying the time at which it started. 1687 Some systems, for example, hand held devices may 1688 not be able to generate a time stamp. In this 1689 case this attribute should contain the value "NA" 1690 for Not Available. 1692 3.3.2 Message Id Component 1694 The Message Id Component provides control information about the IOTP 1695 Message as well as uniquely identifying the IOTP Message within an IOTP 1696 Transaction. Its definition is as follows. 1698 1699 1709 Attributes: 1711 ID An identifier which uniquely identifies the 1712 IOTP Message within the IOTP Transaction (see 1713 section 3.4 ID Attributes). Note that if an 1714 IOTP Message is resent then the value of this 1715 attribute remains the same. 1717 RespIotpMsg This contains the ID attribute of the Message 1718 Id Component of the IOTP Message to which this 1719 IOTP Message is a response. In this way all 1720 the IOTP Messages in an IOTP Transaction are 1721 unambiguously linked together. This field is 1722 required on every IOTP Message except the 1723 first IOTP Message in an IOTP Transaction. 1725 SenderTradingRoleRef The Element Reference (see section 3.5) of the 1726 Trading Role which has generated the IOTP 1727 message. It is used to identify the Net 1728 Locations (see section 3.9) of the Trading 1729 Role to which problems Technical Errors (see 1730 section 4.1) with any of Trading Blocks should 1731 be reported. 1733 Xml:lang Defines the language used by attributes or 1734 child elements within this component, unless 1735 overridden by an xml:lang attribute on a child 1736 element. See section 3.8 Identifying 1737 Languages. 1739 LangPrefList Optional list of Language codes that conform 1740 to [XML] Language Identification. It is used 1741 by the sender to indicate, in preference 1742 sequence, the languages that the receiver of 1743 the message ideally should use when generating 1744 a response. There is no obligation on the 1745 receiver to respond using one of the indicated 1746 languages, but using one of the languages is 1747 likely to provide an improved user experience. 1749 CharSetPrefList Optional list of Character Set identifiers 1750 that conform to [XML] Characters. It is used 1751 by the sender to indicate, in preference 1752 sequence, the character sets that the receiver 1753 of the message ideally should use when 1754 generating a response. There is no obligation 1755 on the receiver to respond using one of the 1756 character sets indicated, but using one of the 1757 character sets is likely to provide an 1758 improved user experience. 1760 SoftwareId This contains information which identifies the 1761 software which generated the IOTP Message. Its 1762 purpose is to help resolve interoperability 1763 problems that might occur as a result of 1764 incompatibilities between messages produced by 1765 different software. It is a single text string 1766 in the language defined by xml:lang. It must 1767 contain, as a minimum: 1768 o the name of the software manufacturer 1769 o the name of the software 1770 o the version of the software, and 1771 o the build of the software 1773 TimeStamp Where the device sending the message has an 1774 internal clock, it is set to the time at which 1775 the IOTP Message was created in [UTC] format. 1777 3.3.3 Related To Component 1779 The Related To Component links IOTP Transactions to either other IOTP 1780 Transactions or other events using the identifiers of those events. Its 1781 definition is as follows. 1783 1784 1791 Attributes: 1793 ID An identifier which uniquely identifies the 1794 Related To Component within the IOTP Transaction. 1796 xml:lang Defines the language used by attributes or child 1797 elements within this component, unless overridden 1798 by an xml:lang attribute on a child element. See 1799 section 3.8 Identifying Languages. 1801 RelationshipType Defines the type of the relationship. Valid values 1802 are: 1803 o IotpTransaction. in which case the Packaged 1804 Content Element contains an IotpTransId of 1805 another IOTP Transaction 1806 o Reference in which case the Packaged Content 1807 Element contains the reference of some other, 1808 non-IOTP document. 1810 Values of RelationshipType are controlled under 1811 the procedures defined in section 12 IANA 1812 Considerations which also allows user defined 1813 values to be defined. 1815 Relation The Relation attribute contains a phrase in the 1816 language defined by xml:lang which describes the 1817 nature of the relationship between the IOTP 1818 transaction that contains this component and 1819 another IOTP Transaction or other event. The exact 1820 words to be used are left to the implementers of 1821 the IOTP software. 1823 The purpose of the attribute is to provide the 1824 Trading Roles involved in an IOTP Transaction with 1825 an explanation of the nature of the relationship 1826 between the transactions. 1828 Care should be taken that the words used to in the 1829 Relation attribute indicate the "direction" of the 1830 relationship correctly. For example: one 1831 transaction might be a refund for another earlier 1832 transaction. In this case the transaction which is 1833 a refund should contain in the Relation attribute 1834 words such as "refund for" rather than "refund to" 1835 or just "refund". 1837 RelnKeyWords This attribute contains keywords which could be 1838 used to help identify similar relationships, for 1839 example all refunds. It is anticipated that 1840 recommended keywords will be developed through 1841 examination of actual usage. In this version of 1842 the specification there are no specific 1843 recommendations and the keywords used are at the 1844 discretion of implementers. 1846 Content: 1848 PackagedContent The Packaged Content (see section 3.7) contains 1849 data which identifies the related transaction. Its 1850 format varies depending on the value of the 1851 RelationshipType. 1853 3.4 ID Attributes 1855 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading 1856 Blocks), Trading Components (including the Transaction Id Component and 1857 the Signature Component) and some of their child elements are each given 1858 an XML "ID" attribute which is used to identify an instance of these XML 1859 elements. These identifiers are used so that one element can be 1860 referenced by another. All these attributes are given the attribute name 1861 ID. 1863 The values of each ID attribute are unique within an IOTP transaction 1864 i.e. the set of IOTP Messages which have the same globally unique 1865 Transaction ID Component. Also, once the ID attribute of an element has 1866 been assigned a value it is never changed. This means that whenever an 1867 element is copied, the value of the ID attribute remains the same. 1869 As a result it is possible to use these IDs to refer to and locate the 1870 content of any IOTP Message, Block or Component from any other IOTP 1871 Message, Block or Component in the same IOTP Transaction using Element 1872 References (see section 3.5). 1874 This section defines the rules for setting the values for the ID 1875 attributes of IOTP Messages, Blocks and Components. 1877 3.4.1 IOTP Message ID Attribute Definition 1879 The ID attribute of the Message Id Component of an IOTP Message must be 1880 unique within an IOTP Transaction. It's definition is as follows: 1882 IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix 1883 IotpMsgIdPrefix ::= NameChar (NameChar)* 1884 IotpMsgIdSuffix ::= Digit (Digit)* 1885 IotpMsgIdPrefix Apart from messages which contain an Inquiry 1886 Request Trading Block (see section 8.12), the same 1887 prefix is used for all messages sent by the 1888 Merchant or Consumer role as follows: 1889 o "M" - Merchant 1890 o "C" - Consumer 1892 For messages which contain an Inquiry Request 1893 Trading Block, the prefix is set to "I" for 1894 Inquiry. 1896 The prefix for the other roles in a trade is 1897 contained within the Organisation Component for 1898 the role and are typically set by the Merchant. 1899 The following is recommended as a guideline and 1900 must not be relied upon: 1901 o "P" - First (only) Payment Handler 1902 o "R" - Second Payment Handler 1903 o "D" - Delivery Handler 1904 o "C" - Deliver To 1906 As a guideline, prefixes should be limited to one 1907 character. 1909 NameChar has the same definition as the [XML] 1910 definition of NameChar. 1912 IotpMsgIdSuffix The suffix consists of one or more digits. The 1913 suffix must be unique within a Trading Role within 1914 an IOTP Transaction. The following is recommended 1915 as a guideline and must not be relied upon: 1916 o the first IOTP Message sent by a trading role 1917 is given the suffix "1" 1918 o the second and subsequent IOTP Messages sent 1919 by the same trading role are incremented by one 1920 for each message 1921 o no leading zeroes are included in the suffix 1923 Put more simply the Message Id Component of the 1924 first IOTP Message sent by a Consumer would have 1925 an ID attribute of, "C1", the second "C2", the 1926 third "C3" etc. 1928 Digit has the same definition as the [XML] 1929 definition of Digit. 1931 3.4.2 Block and Component ID Attribute Definitions 1933 The ID Attribute of Blocks and Components must also be unique within an 1934 IOTP Transaction. Their definition is as follows: 1936 BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix 1937 IdSuffix ::= Digit (Digit)* 1939 IotpMsgId_value The ID attribute of the Message ID Component of 1940 the IOTP Message where the Block or Component is 1941 first used. 1943 In IOTP, Trading Components and Trading Blocks are 1944 copied from one IOTP Message to another. The ID 1945 attribute does not change when an existing Trading 1946 Block or Component is copied to another IOTP 1947 Message. 1949 IdSuffix The suffix consists of one or more digits. The 1950 suffix must be unique within the ID attribute of 1951 the Message ID Component used to generate the ID 1952 attribute. The following is recommended as a 1953 guideline and must not be relied upon: 1954 o the first Block or Component sent by a trading 1955 role is given the suffix "1" 1956 o the ID attributes of the second and subsequent 1957 Blocks or Components are incremented by one for 1958 each new Block or Component added to an IOTP 1959 Message 1960 o no leading zeroes are included in the suffix 1962 Put more simply, the first new Block or Component 1963 added to the second IOTP Message sent, for 1964 example, by a consumer would have a an ID 1965 attribute of "C2.1", the second "C2.2", the third 1966 "C2.3" etc. 1968 Digit has the same definition as the [XML] 1969 definition of Digit. 1971 3.4.3 Example of use of ID Attributes 1973 The diagram below illustrates how ID attribute values are used. 1975 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1977 1st IOTP MESSAGE 2nd IOTP MESSAGE 1978 (e.g. from Merchant to (e.g. from Consumer to 1979 Consumer Payment Handler) 1981 IOTP MESSAGE IOTP MESSAGE * 1982 |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* 1983 | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp. 1984 | | Copy Element | | ID=M1.2 1985 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * 1986 | | 1987 |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* 1988 | |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15 1989 | Copy Element | 1990 |-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 * 1991 | |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4 1992 | | Copy Element | 1993 | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5 1994 | | Copy Element | 1995 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * 1996 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * 1997 | 1998 |-Trading Block. ID=M1.9 1999 |-Comp. ID=M1.10 * = new elements 2000 |-Comp. ID=M1.11 2001 |-Comp. ID=M1.12 2002 |-Comp. ID=M1.13 2004 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2006 Figure 8 Example use of ID attributes 2008 3.5 Element References 2010 A Trading Component or one of its child XML elements, may contain an XML 2011 attribute that refers to another Block (i.e. a Transaction Reference 2012 Block or a Trading Block) or Trading Component (including a Transaction 2013 Id and Signature Component). These Element References are used for many 2014 purposes, a few examples include: 2016 o identifying an XML element whose Digest is included in a Signature 2017 Component, 2019 o referring to the Payment Handler Organisation Component which is used 2020 when making a Payment 2022 An Element Reference always contains the value of an ID attribute of a 2023 Block or Component. 2025 Identifying the IOTP Message, Trading Block or Trading Component which is 2026 referred to by an Element Reference, involves finding the XML element 2027 which: 2029 o belongs to the same IOTP Transaction (i.e. the Transaction Id 2030 Components of the IOTP Messages match), and 2032 o where the value of the ID attribute of the element matches the value of 2033 the Element Reference. 2035 [Note] The term "match" in this specification has the same definition 2036 as the [XML] definition of match. 2037 [Note End] 2039 An example of "matching" an Element Reference is illustrated in the 2040 example below. 2042 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2044 1st IOTP MESSAGE 2nd IOTP MESSAGE 2045 (e.g. from Merchant to (e.g. from Consumer to 2046 Consumer Payment Handler) 2048 IOTP MESSAGE IOTP MESSAGE 2049 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1 2050 | |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2 2051 | | must be | | 2052 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 2053 | ^ | 2054 |-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5 2055 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 2056 | AND | 2057 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 2058 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 2059 | | v | 2060 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 2061 | | and El Ref | 2062 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 2063 | | match--------|--> El Ref=M1.5 2064 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 2065 | 2066 |-Trading Block. ID=M1.9 2067 |-Comp. ID=M1.10 2068 |-Comp. ID=M1.11 2069 |-Comp. ID=M1.12 2070 |-Comp. ID=M1.13 2072 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2074 Figure 9 Element References 2076 [Note] Element Reference attributes are defined as "NMTOKEN" rather 2077 than "IDREF" (see [XML]). This is because an IDREF requires 2078 that the XML element referred to is in the same XML Document. 2079 With IOTP this is not necessarily the case. 2080 [Note End] 2082 3.6 Extending IOTP 2084 Baseline IOTP defines a minimum protocol which systems supporting IOTP 2085 must be able to accept. As new versions of IOTP are developed, additional 2086 types of IOTP Transactions will be defined. In addition to this, Baseline 2087 and future versions of IOTP will support user extensions to IOTP through 2088 two mechanisms: 2090 o extra XML elements, and 2092 o new values for existing IOTP codes. 2094 3.6.1 Extra XML Elements 2096 The XML element and attribute names used within IOTP constitute an [XML 2097 Namespace] as identified by the xmlns attribute on the IotpMessage 2098 element. This allows IOTP to support the inclusion of additional XML 2099 elements within IOTP messages through the use of [XML Namespaces]. 2101 Using XML Namespaces, extra XML elements may be included at any level 2102 within an IOTP message including: 2104 o new Trading Blocks 2106 o new Trading Components 2108 o new XML elements within a Trading Component. 2110 The following rules apply: 2112 o any new XML element must be declared according to the rules for [XML 2113 Namespaces] 2115 o new XML elements which are either Trading Blocks or Trading Components 2116 must contain an ID attributes with an attribute name of ID. 2118 In order to make sure that extra XML elements can be processed properly, 2119 IOTP reserves the use of a special attribute, IOTP:Critical, which takes 2120 the values True or False and may appear in extra elements added to an 2121 IOTP message. 2123 The purpose of this attribute is to allow an IOTP aware application to 2124 determine if the IOTP transaction can safely continue. Specifically: 2126 o if an extra XML element has an "IOTP:Critical" attribute with a value 2127 of "True" and an IOTP aware application does not know how to process 2128 the element and its child elements, then the IOTP transaction has a 2129 Technical Error (see section 4.1) and must fail. 2131 o if an extra XML element has an "IOTP:Critical" attribute with a value 2132 of "False" then the IOTP transaction may continue if the IOTP aware 2133 application does not know how to process it. In this case: 2134 - any extra XML elements contained within an XML element defined within 2135 the IOTP namespace, must be included with that element whenever the 2136 IOTP XML element is used or copied by IOTP 2137 - the content of the extra element must be ignored except that it must 2138 be included when it is used in the creation of a digest as part of 2139 the generation of a signature 2141 o if an extra XML element has no "IOTP:Critical" attribute then it must 2142 be treated as if it had an "IOTP:Critical" attribute with a value of 2143 "True" 2145 o if an XML element contains an "IOTP:Critical" attribute, then the value 2146 of that attribute is assumed to apply to all the child elements within 2147 that element 2149 In order to ensure that documents containing "IOTP:Critical" are valid, 2150 it is declared as part of the DTD for the extra element as: 2152 IOTP:Critical (True | False ) 'True' 2154 3.6.2 Opaque Embedded Data 2156 If IOTP is to be extended using Opaque Embedded Data then a Packaged 2157 Content Element (see section 3.7) should be used to encapsulate the data. 2159 3.7 Packaged Content Element 2161 The Packaged Content element supports the concept of an embedded data 2162 stream, transformed to both protect it against misinterpretation by 2163 transporting systems and to ensure XML compatibility. Examples of its use 2164 in IOTP include: 2166 o to encapsulate payment scheme messages, such as SET messages, 2168 o to encapsulate a description of an order, a payment note, or a delivery 2169 note. 2171 In general it is used to encapsulate one or more data streams. 2173 This data stream has three standardised attributes that allow for 2174 identification, decoding and interpretation of the contents. Its 2175 definition is as follows. 2177 2178 2183 Attributes: 2185 Name Optional. Distinguishes between multiple 2186 occurrences of Packaged Content Elements at the 2187 same point in IOTP. For example: 2188 2189 2190 snroasdfnas934k 2191 2192 2193 dvdsjnl5poidsdsflkjnw45 2194 2195 2197 The name attribute may be omitted, for example if 2198 there is only one Packaged Content element. 2200 Content This identifies what type of data is contained 2201 within the Content of the Packaged Content 2202 Element. The valid values for the Content 2203 attribute are as follows: 2204 o PCDATA. The content of the Packaged Content 2205 Element can be treated as PCDATA with no 2206 further processing. 2207 o MIME. The content of the Packaged Content 2208 Element is a complete MIME item. Processing 2209 should include looking for MIME headers inside 2210 the Packaged Content Element. 2211 o MIME:mimetype. The content of the Packaged 2212 Content Element is MIME content, with the 2213 following header "Content-Type: mimetype". 2214 Although it is possible to have MIME:mimetype 2215 with the Transform attribute set to NONE, it is 2216 far more likely to have Transform attribute set 2217 to BASE64. Note that if Transform is NONE is 2218 used, then the entire content must still 2219 conform to PCDATA. Some characters will need to 2220 be encoded either as the XML default entities, 2221 or as numeric character entities. 2222 o XML. The content of the Packaged Content 2223 Element can be treated as an XML document. 2224 Entities and CDATA sections, or Transform set 2225 to BASE64, must be used to ensure that the 2226 Packaged Content Element contents are 2227 legitimate PCDATA. 2229 Values of the Content attribute are controlled 2230 under the procedures defined in section 12 IANA 2231 Considerations which also allows user defined 2232 values to be defined. 2234 Transform This identifies the transformation that has been 2235 done to the data before it was placed in the 2236 content. Valid values are: 2238 o NONE. The PCDATA content of the Packaged 2239 Content Element is the correct representation 2240 of the data. Note that entity expansion must 2241 occur first (i.e. replacement of & and 2242 ) before the data is examined. CDATA 2243 sections may legitimately occur in a Packaged 2244 Content Element where the Transform attribute 2245 is set to NONE. 2246 o BASE64. The PCDATA content of the Packaged 2247 Content Element represents a BASE64 encoding of 2248 the actual content. 2250 Content: 2252 PCDATA This is the actual data which has been embedded. 2253 The format of the data and rules on how to decode 2254 it are contained in the Content and the Transform 2255 attributes 2257 Note that any special details, especially custom attributes, must be 2258 represented at a higher level. 2260 3.7.1 Packaging HTML 2262 The packaged content may contain HTML. In this case the following 2263 conventions are followed: 2265 o references to any documents, images or other things, such as sounds or 2266 web pages, which can affect the recipient's understanding of the data 2267 which is being packaged must refer to other Packaged Elements contained 2268 within the same parent element, e.g. an Order Description 2270 o if more than one Packaged Content element is included within a parent 2271 element in order to meet the previous requirement, then the Name 2272 attribute of the top level Packaged Content from which references to 2273 all other Packaged Elements can be determined, should have a value of 2274 Main 2276 o relative references to other documents, images, etc. from one Packaged 2277 Content element to another are realised by setting the value of the 2278 relative reference to the Name attribute of another Packaged Content 2279 element at the same level and within the same parent element 2281 o no external references that require the reference to be resolved 2282 immediately should be used. As this could make the HTML difficult or 2283 impossible to display completely 2285 o [MIME] is used to encapsulate the data inside each Packaged Element. 2286 This means that the information in the MIME header used to identify the 2287 type of data which has been encapsulated and therefore how it should be 2288 displayed. 2290 If the above conventions are not followed by, for example, including 2291 external references which must be resolved, then the recipient of the 2292 HTML should be informed. 2294 [Note] As an implementation guideline the values of the Name 2295 Attributes allocated to Packaged Content elements should make 2296 it possible to extract each Packaged Content into a directory 2297 and then display the HTML directly 2298 [Note End] 2300 3.7.2 Packaging XML 2302 Support for XML is recommended. When XML needs to be displayed, for 2303 example to display the content of an Order Description to a Consumer, 2304 then implementers should follow the latest recommendations of the World 2305 Wide Web Consortium. 2307 [Note] At the time of writing this specification, standards are under 2308 development that specify XML style sheets that show how XML 2309 documents should be displayed. See: 2310 o "Extensible Stylesheet Language (XSL) Specification" at 2311 http://www.w3.org/TR/WD-xsl, and 2312 o "Associating stylesheets with XML documents" at 2313 http://www.w3.org/TR/xml-stylesheet. 2315 Once these standards become W3C "Recommendations", then it is 2316 anticipated that this specification will be amended if 2317 practical. 2318 [Note End] 2320 3.8 Identifying Languages 2322 IOTP uses [XML] Language Identification to specify which languages are 2323 used within the content and attributes of IOTP Messages. 2325 The following principles have been used in order to determine which XML 2326 elements contain an xml:lang Attributes: 2328 o a mandatory xml:lang attribute is contained on every Trading Component 2329 which contains attributes or content which may need to be displayed or 2330 printed in a particular language 2332 o an optional xml:lang attribute is included on child elements of these 2333 Trading Components. In this case the value of xml:lang, if present, 2334 overrides the value for the Trading Component. 2336 xml:lang attributes which follow these principles are included in the 2337 Trading Components and their child XML elements defined in section 7. 2339 A sender of a message, typically a Consumer can indicate a preference for 2340 a language, and a character set by specifying a list of preferred 2341 languages/character sets in a Message Id Component (see section 3.3.2). 2342 Note that there is no obligation on the receiver of such a message to 2343 respond using one of the listed languages/character sets as they may not 2344 have the technology to be able to do it. It also means that the ability 2345 to handle these lists is not a requirement for conformance to this 2346 specification. However the ability to respond, for example using one of 2347 the stated languages/character sets is likely to provide a better user 2348 experience. 2350 3.9 Secure and Insecure Net Locations 2352 IOTP contains several "Net Locations" which identify places where, 2353 typically, IOTP Messages may be sent. Net Locations come in two types: 2355 o "Secure" Net Locations which are net locations where privacy of data is 2356 secured using, for example, encryption methods such as [SSL/TLS], and 2358 o "Insecure" Net Locations where privacy of data is not assured. 2360 Note that either a Secure Net Location or an Insecure Net Location or 2361 both must be present. 2363 If only one of the two Net Locations is present, then the one present 2364 must be used. 2366 Where both types of net location are present then either may be used 2367 depending on the preference of the sender of the message. 2369 3.10 Cancelled Transactions 2371 Any Trading Role involved in an IOTP transaction may cancel that 2372 transaction at any time. 2374 3.10.1 Cancelling Transactions 2376 IOTP Transactions are cancelled by sending an IOTP message containing 2377 just a Cancel Block with an appropriate Status Component to the other 2378 Trading Role involved in the Trading Exchange. 2380 [Note] The Cancel Block can be sent asynchronously of any other IOTP 2381 Message. Specifically it can be sent either before sending or 2382 after receiving an IOTP Message from the other Trading Role 2383 [Note End] 2385 If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the 2386 interval between sending a "request" block and receiving the matching 2387 "response" block) then the Cancel Block is sent to the same location as 2388 the next IOTP Message in the Trading Exchange would have been sent. 2390 If a Consumer cancels a transaction after a Trading Exchange has 2391 completed (i.e. the "response" block for the Trading Exchange has been 2392 received), but before the IOTP Transaction has finished then the Consumer 2393 sends a Cancel Block with an appropriate Status Component to the net 2394 location identified by the SenderNetLocn or SecureSenderNetLocn contained 2395 in the Protocol Options Component (see section 7.1) contained in the TPO 2396 Block (see section 8.1) for the transaction. This is normally the 2397 Merchant Trading Role. 2399 A Consumer should not send a Cancel Block after the IOTP Transaction has 2400 completed. Cancelling a complete transaction should be treated as a 2401 technical error. 2403 After cancelling the IOTP Transaction, the Consumer should go to the net 2404 location specified by the CancelNetLocn attribute contained in the 2405 Trading Role Element for the organisation that was sent the Cancel Block. 2407 A non-Consumer Trading Role should only cancel a transaction: 2409 o after a request block has been received and 2411 o before the response block has been sent 2413 If a non-Consumer Trading Role cancels a transaction at any other time it 2414 should be treated by the recipient as an error. 2416 3.10.2 Handling Cancelled Transactions 2418 If a Cancel Block is received by a Consumer at a point in the IOTP 2419 Transaction when cancellation is allowed, then the Consumer should stop 2420 the transaction. 2422 If a Cancel Block is received by a non-Consumer role, then the Trading 2423 Role should anticipate that the Consumer may go to the location specified 2424 by the CancelNetLocn attribute contained in the Trading Role Element for 2425 the Trading Role. 2427 4. IOTP Error Handling 2429 IOTP is designed as a request/response protocol where each message is 2430 composed of a number of Trading Blocks which contain a number of Trading 2431 Components. There are several interrelated considerations in handling 2432 errors, re-transmissions, duplicates, and the like. These factors mean 2433 IOTP aware applications must manage message flows more complex than the 2434 simple request/response model. Also a wide variety of errors can occur in 2435 messages as well as at the transport level or in Trading Blocks or 2436 Components. 2438 This section describes at a high level how IOTP handles errors, retries 2439 and idempotency. It covers: 2441 o the different types of errors which can occur. This is divided into: 2442 - "technical errors" which are independent of the purpose of the IOTP 2443 Message, 2444 - "business errors" which indicate that there is a problem specific to 2445 the process (e.g. payment or delivery) which is being carried out, 2446 and 2448 o the depth of the error which indicates whether the error is at the 2449 transport, message or block/component level 2451 o how the different trading roles should handle the different types of 2452 messages which they may receive. 2454 4.1 Technical Errors 2456 Technical Errors are those which are independent of the meaning of the 2457 message. This means, they can affect any attempt at IOTP communication. 2458 Typically they are handled in a standard fashion with a limited number of 2459 standard options for the user. Specifically these are: 2461 o retrying the transmission, or 2463 o cancelling the transaction. 2465 When communications are operating sufficiently well, a technical error is 2466 indicated by an Error Component (see section 7.21) in an Error Block (see 2467 section 8.17) sent by the party which detected the error in an IOTP 2468 message to the party which sent the erroneous message. 2470 If communications are too poor, a message which was sent may not reach 2471 its destination. In this case a time-out might occur. 2473 The Error Codes associated with Technical Errors are recorded in the 2474 Error Component which lists all the different technical errors which can 2475 be set. 2477 4.2 Business Errors 2479 Business Errors may occur when the IOTP messages are "technically" 2480 correct. They are connected with a particular process, for example, an 2481 offer, payment, delivery or authentication, where each process has a 2482 different set of possible business errors. 2484 For example, "Insufficient funds" is a reasonable payment error but makes 2485 no sense for a delivery while "Back ordered" is a reasonable delivery 2486 error but not meaningful for a payment. Business errors are indicated in 2487 the Status Component (see section 7.16) of a "response block" of the 2488 appropriate type, for example a Payment Response Block or a Delivery 2489 Response Block. This allows whatever additional response related 2490 information is needed to accompany the error indication. 2492 Business errors must usually be presented to the user so that they can 2493 decide what to do next. For example, if the error is insufficient funds 2494 in a Brand Independent Offer (see section 9.1.2.2), the user might wish 2495 to choose a different payment instrument/account of the same brand or a 2496 different brand or payment system. Alternatively, if the IOTP based 2497 implementation allows it and it makes sense for that instrument, the user 2498 might want to put more funds into the instrument/account and try again. 2500 4.3 Error Depth 2502 The three levels at which IOTP errors can occur are the transport level, 2503 the message level, and the block level. Each is described below. 2505 4.3.1 Transport Level 2507 This level of error indicates a fundamental problem in the transport 2508 mechanism over which the IOTP communication is taking place. 2510 All transport level errors are technical errors and are indicated by 2511 either an explicit transport level error indication, such as a "No route 2512 to destination" error from TCP/IP, or by a time out where no response has 2513 been received to a request. 2515 The only reasonable automatic action when faced with transport level 2516 errors is to retry and, after some number of automatic retries, to inform 2517 the user. 2519 The explicit error indications that can be received are transport 2520 dependent and the documentation for the appropriate IOTP Transport 2521 supplement should be consulted for errors and appropriate actions. 2523 Appropriate time outs to use are a function of both the transport being 2524 used and of the payment system if the request encapsulates payment 2525 information. The transport and payment system specific documentation 2526 should be consulted for time out and automatic retry parameters. 2527 Frequently there is no way to directly inform the other party of 2528 transport level errors but they should generally be logged and if 2529 automatic recovery is unsuccessful and there is a human user, the user 2530 should be informed. 2532 4.3.2 Message Level 2534 This level of error indicates a fundamental technical problem with an 2535 entire IOTP message. For example, the XML is not "Well Formed", or the 2536 message is too large for the receiver to handle or there are errors in 2537 the Transaction Reference Block (see section 3.3) so it is not possible 2538 to figure out what transaction the message relates to. 2540 All message level errors are technical errors and are indicated by Error 2541 Components (see section 7.21) sent to the other party. The Error 2542 Component includes a Severity attribute which indicates whether the error 2543 is a Warning and may be ignored, a TransientError which indicates that a 2544 retry may resolve the problem or a HardError in which case the 2545 transaction must fail. 2547 The Technical Errors (see section 7.21.2 Error Codes) that are Message 2548 Level errors are: 2550 o XML not well formed. The document is not well formed XML (see [XML]) 2552 o XML not valid. The document is not valid XML (see [XML]) 2554 o block level technical errors (see section 4.3.3) on the Transaction 2555 Reference Block (see section 3.3) and the Signature Block only. Checks 2556 on these blocks should only be carried out if the XML is valid 2558 Note that checks on the Signature Block include checking, where possible, 2559 that each Signature Component is correctly calculated. If the Signature 2560 is incorrectly calculated then the data that should have been covered by 2561 the signature can not be trusted and must be treated as erroneous. A 2562 description of how to check a signature is correctly calculated is 2563 contained in section 6.2. 2565 4.3.3 Block Level 2567 A Block level error indicates a problem with a block or one of its 2568 components in an IOTP message (apart from Transaction Reference or 2569 Signature Blocks). The message has been transported properly, the overall 2570 message structure and the block/component(s) including the Transaction 2571 Reference and Signature Blocks are meaningful but there is some error 2572 related to one of the other blocks. 2574 Block level errors can be either: 2576 o technical errors, or 2578 o business errors 2579 Technical Errors are further divided into: 2581 o Block Level Attribute and Element Checks, and 2583 o Block and Component Consistency Checks 2585 o Transient Technical Errors 2587 If a technical error occurs related to a block or component, then an 2588 Error Component is generated for return. 2590 4.3.3.1 Block Level Attribute and Element Checks 2592 Block Level Attribute and Element Checks occur only within the same 2593 block. Checks which involve cross-checking against other blocks are 2594 covered by Block and Component Consistency Checks. 2596 The Block Level Attribute & Element checks are: 2598 o checking that each attribute value within each element in a block 2599 conforms to any rules contained within this IOTP specification 2601 o checking that the content of each element conforms to any rules 2602 contained within this IOTP specification 2604 o if the previous checks are OK, then checking the consistency of 2605 attribute values and element content against other attribute values or 2606 element content within any other components in the same block. 2608 4.3.3.2 Block and Component Consistency Checks 2610 Block and Component Consistency Checks consist of: 2612 o checking that the combination of blocks and/or components present in 2613 the IOTP Message are consistent with the rules contained within this 2614 IOTP specification 2616 o checking for consistency between attributes and element content within 2617 the blocks within the same IOTP message. 2619 o checking for consistency between attributes and elements in blocks in 2620 this IOTP message and blocks received in earlier IOTP messages for the 2621 same IOTP transaction 2623 If the block passes the "Block Level Attribute and Element Checks" and 2624 the "Block and Component Consistency Checks" then it is processed either 2625 by the IOTP Aware application or perhaps by some "back-end" system such 2626 as a payment server. 2628 4.3.3.3 Transient Technical Errors 2630 During the processing of the Block some temporary failure may occur that 2631 can potentially be recovered by the other trading role re-transmitting, 2632 at some slightly later time, the original message that they sent. 2634 In this case the other role is informed of the Transient Error by sending 2635 them an Error Component (see section 7.21) with the Severity Attribute 2636 set to TransientError and the MinRetrySecs attribute set to some value 2637 suitable for the Transport Mechanism and/or payment protocol being used 2638 (see appropriate Transport and payment protocol Supplements). 2640 Note that transient technical errors can be generated by any of the 2641 Trading Roles involved in transaction. 2643 4.3.3.4 Block Level Business Errors 2645 If a business error occurs in a process such as a Payment or a Delivery, 2646 then the appropriate type of response block is returned containing a 2647 Status Component (see section 7.16) with the ProcessState attribute set 2648 to Failed and the CompletionCode indicating the nature of the problem. 2650 Some business errors may be "transient" in that the Consumer role may be 2651 able to recover and complete the transaction in some other way. For 2652 example if the Credit Card that a consumer provided had insufficient 2653 funds for a purchase, then the Consumer may recover by using a different 2654 credit card. 2656 Recovery from "transient" business errors is dependent on the 2657 CompletionCode. See the definition of the Status Component for what is 2658 possible. 2660 Note that no Error Component or Error Block is generated for business 2661 errors. 2663 4.4 Idempotency, Processing Sequence, and Message Flow 2665 IOTP messages are actually a combination of blocks and components as 2666 described in 3.1.1 IOTP Message Structure. Especially in future 2667 extensions of IOTP, a rich variety of combinations of such blocks and 2668 components can occur. It is important that the multiple 2669 transmission/receipt of the "same" request for an action that will change 2670 state does not result in that action occurring more than once. This is 2671 called idempotency. For example, a customer paying for an order would 2672 want to pay the full amount only once. Most network transport mechanisms 2673 have some probability of delivering a message more than once or not at 2674 all, perhaps requiring retransmission. On the other hand, a request for 2675 status can reasonably be repeated and should be processed fresh each time 2676 it is received. 2678 Correct implementation of IOTP can be modelled by a particular processing 2679 order as detailed below. Any other method that is indistinguishable in 2680 the messages sent between the parties is equally acceptable. 2682 4.5 Server Role Processing Sequence 2684 "Server roles" are any Trading Role which is not the Consumer role. They 2685 are "Server roles" since they typically receive a request which they must 2686 service and then produce a response. However server roles can also 2687 initiate transactions. More specifically Server Roles must be able to: 2689 o Initiate a transaction (see section 4.5.1). These are divided into: 2690 - payment related transactions and 2691 - infrastructure transactions 2693 o Accept and process a message received from another role (see section 2694 4.5.2). This includes: 2695 - identifying if the message belongs to a transaction that has been 2696 received before 2697 - handling duplicate messages 2698 - generating Transient errors if the servers that process the input 2699 message are too busy to handle it 2700 - processing the message if it is error free, authorised and, if 2701 appropriate, producing a response to send back to the other role 2703 o Cancel a current transaction if requested (see section 4.5.3) 2705 o Re-transmit messages if a response was expected but has not been 2706 received in a reasonable time (see section 4.5.4). 2708 4.5.1 Initiating Transactions 2710 Server Roles may initiate a variety of different types of transaction. 2711 Specifically: 2713 o an Inquiry Transaction (see section 9.2.1) 2715 o a Ping Transaction (see section 9.2.2) 2717 o an Authentication Transaction (see section 9.1.6) 2719 o a Payment Related Transaction such as: 2720 - a Deposit (see section 9.1.7) 2721 - a Purchase (see section 9.1.8) 2722 - a Refund (see section 9.1.9) 2723 - a Withdrawal (see section 9.1.10) 2724 - a Value Exchange (see section 9.1.11) 2726 4.5.2 Processing Input Messages 2728 Processing input messages involves the following: 2730 o checking the structure and identity of the message 2732 o checking for and handling duplicate messages 2733 o processing non-duplicate original messages which includes: 2734 - checking for errors, then if no errors are found 2735 - processing the message to produce an output message if appropriate 2737 Each of these is discussed in more detail below. 2739 4.5.2.1 Checking Structure and Message Identity 2741 It is critical to check that the message is "well formed" XML and that 2742 the transaction identifier (IotpTransId attribute on the TransId 2743 Component) within the IOTP message can be successfully identified since 2744 an IotpTransId will be needed to generate a response. 2746 If the input message is not well formed then generate an Error Component 2747 with a Severity of HardError and ErrorCode of XmlNotWellFrmd. 2749 If the message is well formed but the IotpTransId cannot be identified 2750 then generate an ErrorComponent with: 2752 o a Severity of HardError and an ErrorCode of AttMissing, 2754 o a PackagedContent containing "IotpTransId" - the missing attribute. 2756 Insert the Error Component inside an Error Block with a new TransactionId 2757 component with a new IotpTransId and return it to the sender of the 2758 original message. 2760 4.5.2.2 Checking/Handling Duplicate Messages 2762 If the input message can be identified as potentially a valid input 2763 message then check to see if an "identical" input message has been 2764 received before. Identical means that all blocks, components, elements, 2765 attribute values and element content in the input message are the same. 2767 If an identical message has been received before then check to see if the 2768 processing of the previous message has completed. 2770 If processing has not completed then generate an Error Component with a 2771 Severity of Transient Error and an Error Code of MsgBeingProc to 2772 indicate the message is being processed and send it back to the sender 2773 of the Input Message requesting that the original message be resent 2774 after an appropriate period of time. 2776 Otherwise, if processing has completed and resulted in an output message 2777 then retrieve the last message that was sent and send it again. 2779 If the message is not a duplicate then it should be processed. 2781 4.5.2.3 Processing Non-Duplicate Message 2783 Once it's been established that the message is not a duplicate, then it 2784 can be processed. This involves: 2786 o checking that a server is available to handle the message, generating a 2787 Transient Error if it is not 2789 o checking the Transaction is Not Already in error or cancelled 2791 o validating the input message. This includes: 2792 - checking for message level errors 2793 - checking for block level errors 2794 - checking any encapsulated data 2796 o checking for errors in the sequence that blocks have been received 2798 o generating error components for any errors that result 2800 o if neither hard errors nor transient errors result, then processing the 2801 message and generating an output message, if required, for return to 2802 the sender of the Input Message 2804 [Note] This approach to handling of duplicate input messages means, 2805 if absolutely "identical" messages are received then 2806 absolutely "identical" messages are returned. This also 2807 applies to Inquiry and Ping transactions when in reality the 2808 state of a transaction or the processing ability of the 2809 servers may have changed. If up-to-date status of transactions 2810 or servers is required, then an IOTP transaction with a new 2811 IotpTransId must be used. 2812 [Note End] 2814 Each of the above steps is discussed below. 2816 CHECKING A SERVER IS AVAILABLE 2818 The process that is handling the input message should check that the rest 2819 of the system is not so busy that a response in a reasonable time cannot 2820 be produced. 2822 If the server is too busy, then it should generate an Error Component 2823 with a Severity of Transient Error and an Error Code of SystemBusy and 2824 send it back to the sender of the Input Message requesting that the 2825 original message be resent after an appropriate period of time. 2827 [Note] Some servers may occasionally become very busy due to 2828 unexpected increases in workload. This approach allows short 2829 peaks in workloads to be handled by delaying the input of 2830 messages by asking the sender of the message to resubmit 2831 later. 2832 [Note End] 2834 CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED 2836 Check that: 2838 o previous messages received or sent did not contain or result in Hard 2839 Errors, and 2841 o the Transaction has not been cancelled by either the Consumer or the 2842 Server Trading Role 2844 If it has then, ignore the message. A transaction with hard errors or 2845 that has been cancelled, cannot be restarted. 2847 CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS 2849 If the transaction is still OK then check for message level errors. This 2850 involves: 2852 o checking the XML is valid 2854 o checking that the elements, attributes and content of the Transaction 2855 Reference Block are without error and conform to this specification 2857 o checking the digital signature which involves: 2858 - checking that the Signature value is correctly calculated, and 2859 - the hash values in the digests are correctly calculated where the 2860 source of the hash value is available. 2862 Checking for block level errors involves: 2864 o checking within each block (apart from the Transaction Reference Block) 2865 that: 2866 - the attributes, elements and element contents are valid 2867 - the values of the attributes, elements and element contents are 2868 consistent within the block 2870 o checking that the combination of blocks are valid 2872 o checking that the values of the attribute, elements and element 2873 contents are consistent between the blocks in the input message and 2874 blocks in earlier messages either sent or received. This includes 2875 checking that the presence of a block is valid for a particular 2876 transaction type 2878 If the message contains any encapsulated data, then if possible check the 2879 encapsulated data for errors using additional software to check the data 2880 where appropriate. 2882 4.5.2.4 Check for Errors in Block Sequence 2884 Errors in the sequence that blocks arrive depends on the block. Blocks 2885 where checking for sequence is required are: 2887 o Error and Cancel Blocks. If an Error or Cancel Block refers to an IOTP 2888 transaction that is not recognised then it is a Hard Error. Do not 2889 return an error if Error or Cancel Blocks have been received for the 2890 IOTP Transaction before to avoid looping. 2892 o Inquiry Request and Response Blocks. If an Inquiry Request or an 2893 Inquiry Response Block refers to an IOTP transaction that is not 2894 recognised then it is a Hard Error 2896 o Authentication Request Block. If an Authentication Request Block refers 2897 to an IOTP transaction that is recognised it is a Hard Error 2899 o Authentication Response Block. Check as follows: 2900 - if an Authentication Response Block does not refer to an IOTP 2901 transaction that is recognised it is a Hard Error, otherwise 2902 - if the Authentication Response Block doesn't refer to an 2903 Authentication Request that had been previously sent then it is a 2904 Hard Error, otherwise 2905 - if an Authentication Response for the same IOTP transaction has been 2906 received before and the Authentication was successful then it is a 2907 Hard Error. 2909 o Authentication Status Block. Check as follows: 2910 - if an Authentication Status Block does not refer to an IOTP 2911 transaction that is recognised it is a Hard Error, otherwise 2912 - if the Authentication Status Block doesn't refer to an Authentication 2913 Response that had been previously sent then it is a Hard Error, 2914 otherwise 2915 - if an Authentication Status for the same IOTP transaction has been 2916 received before then it is a Warning Error 2918 o TPO Selection Block (Merchant only). Check as follows: 2919 - if the TPO Selection Block doesn't refer to an IOTP Transaction that 2920 is recognised then it is a Hard Error, otherwise 2921 - if the TPO Selection Block refers to an IOTP Transaction where a TPO 2922 Block and Offer Response (in one message) had previously been sent 2923 then it is a Hard Error, otherwise 2924 - if the TPO Selection Block does not refer to an IOTP Transaction 2925 where a TPO Block only (i.e. without an Offer Response) had 2926 previously been sent then it is a Hard Error, otherwise 2927 - if a TPO Selection Block for the same TPO Block has been received 2928 before then it is a Hard Error 2930 o Payment Request Block (Payment Handler only). Check as follows: 2931 - if the Payment Request Block refers to an IOTP Transaction that is 2932 not recognised then its OK, otherwise 2933 - if the Payment Request Block refers to IOTP Transaction that was not 2934 for a Payment then it is a Hard Error, otherwise 2935 - if the previous payment CompletedOk OR failed with a non-recoverable 2936 Completion Code then it is a Hard Error, otherwise 2937 - if the previous payment is still in progress then it is a Hard Error 2939 o Payment Exchange Block (Payment Handler only). Check as follows: 2940 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 2941 that is recognised then it is a Hard Error, otherwise 2942 - if the Payment Exchange doesn't refer to an IOTP Transaction where a 2943 Payment Exchange had previously been sent then it a Hard Error 2945 o Delivery Request (Delivery Handler Only). If the Delivery Request Block 2946 refers to an IOTP Transaction that is recognised by the Server then it 2947 is a Hard Error 2949 If any Error Components have been generated then collect them into an 2950 Error Block for sending to the sender of the Input message. Note that 2951 Error Blocks should be sent back to the sender of the message and to the 2952 ErrorLogNetLocn for the Trading Role of the sender if one is specified. 2954 [Note] The above checking on the sequence of Authentication Responses 2955 and Payment Requests supports the Consumer re-submitting a 2956 repeat action request since the previous one failed, for 2957 example: 2958 o because they did not know the correct response (e.g. a 2959 password) on an authentication or, 2960 o they were unable to pay as there were insufficient funds on 2961 a credit card 2962 [Note End] 2964 PROCESS THE ERROR FREE INPUT MESSAGE 2966 If the input message passes the previous checks then it can be processed 2967 to produce an output message if required. Note that: 2969 o Inquiry Requests on Ping Transactions should be ignored 2971 o if the Input message contains an Error Block with a Transient Error 2972 then wait for the required time then resend the previous message, if a 2973 response to the earlier message has not been received 2975 o if the input message contains a Error Component with a HardError or a 2976 Cancel Block then stop all further processing of the transaction. This 2977 includes suppressing the sending of any messages currently being 2978 generated or responding to any new non-duplicate messages that are 2979 received 2981 o processing of encapsulated messages (e.g. Payment Protocol Messages) 2982 may result in additional transient errors 2984 o a digital signature can only safely be generated once all the blocks 2985 and components have been generated and it is known which elements in 2986 the message need to be signed. 2988 If an output message is generated then it should be saved so that it can 2989 be resent as required if an identical input message is received again. 2990 Note that output messages that contain transient errors are not saved so 2991 that they can be processed afresh when the input message is received 2992 again. 2994 4.5.3 Cancelling a Transaction 2996 This process is used to cancel a transaction running on an IOTP server. 2997 It is initiated by some other process as a result of an external request 2998 from another system or server that is being run by the same Trading Role. 2999 The processing required is as follows: 3001 o if the IotpTransId of the transaction to be cancelled is not 3002 recognised, or complete then fail the request, otherwise 3004 o if the IotpTransId refers to a Ping Transaction then fail the request, 3005 otherwise 3007 o determine which Document Exchange to cancel and generate a Cancel Block 3008 and send it to the other party 3010 [Note] Cancelling a transaction on an IOTP server typically arises 3011 for a business reason. For example a merchant may have 3012 attempted authentication several times without success and as 3013 a result decides to cancel the transaction. Therefore the 3014 process that decides to take this action needs to send a 3015 message from the process/server that made the business 3016 decision to the IOTP server with the instruction that the IOTP 3017 transaction should be cancelled. 3018 [Note End] 3020 4.5.4 Retransmitting Messages 3022 The server should periodically check for transactions where a message is 3023 expected in return but none has been received after a time that is 3024 dependent on factors such as: 3026 o the Transport Mechanism being used; 3028 o the time required to process encapsulated messages (e.g. Payment 3029 messages) and 3031 o whether or not human input is required. 3033 If no message has been received the original message should be resent. 3034 This should occur up to a maximum number of times dependent on the 3035 reliability of the Transport Mechanism being used. 3037 If no response is received after the required time then the Transaction 3038 should be "timed out". In this case, set the process state of the 3039 transaction to Failed, and a completion code of either: 3041 o TimedOutRcvr if the transaction can potentially recovered later, or 3043 o TimedOutNoRcvr if the transaction is non-recoverable 3045 4.6 Client Role Processing Sequence 3047 The "Client role" in IOTP is the Consumer Trading Role. 3049 [Note] A company or organisation that is a Merchant, for example, may 3050 take on the Trading Role of a Consumer when making purchases 3051 or downloading or withdrawing electronic cash. 3053 [Note End] 3055 More specifically the Consumer Role must be able to: 3057 o Initiate a transaction (see section 4.6.1). These are divided into: 3058 - payment related transactions and 3059 - infrastructure transactions 3061 o Accept and process a message received from another role (see section 3062 4.6.2). This includes: 3063 - identifying if the message belongs to a transaction that has been 3064 received before 3065 - handling duplicate messages 3066 - generating Transient errors if the servers that process the input 3067 message are too busy to handle it 3068 - processing the message if it is error free and, if appropriate, 3069 producing a response to send back to the other role 3071 o Cancel a current transaction if requested, for example by the User (see 3072 section 4.6.3) 3074 o Re-transmit messages if a response was expected but has not been 3075 received in a reasonable time (see section 4.6.4). 3077 4.6.1 Initiating Transactions 3079 The Consumer Role may initiate a number of different types of 3080 transaction. Specifically: 3082 o an Inquiry Transaction (see section 9.2.1) 3084 o a Ping Transaction (see section 9.2.2) 3086 o an Authentication Transaction (see section 9.1.6) 3088 4.6.2 Processing Input Messages 3090 Processing of Input Messages for a Consumer Role is the same as for an 3091 IOTP Server (see section 4.5.2) except in the area of checking for Errors 3092 in Block Sequence (for an IOTP Server see section 4.5.2.4). This is 3093 described below 3095 [Note] The description of the processing for an IOTP Server includes 3096 consideration of multi-threading of input messages and multi- 3097 tasking of requests. For the Consumer Role - particularly if 3098 running on a stand-alone system such as a PC - use of multi- 3099 threading is a decision of the implementer of the consumer 3100 role IOTP solution. 3101 [Note End] 3103 4.6.2.1 Check for Errors in Block Sequence 3105 The handling of the following blocks is the same as for an IOTP Server 3106 (see section 4.5.2.4) except that the Consumer Role is substituted for 3107 IOTP Server Role: 3109 o Error and Cancel Blocks, 3111 o Inquiry Request and Response Blocks, 3113 o Authentication Request, Response and Status Blocks. 3115 For the other blocks a Consumer role might receive, the potential errors 3116 in the sequence that blocks arrive depends on the block. Blocks where 3117 checking for sequence is required are: 3119 o TPO Block. Check as follows: 3120 - if the input message also contains an Authentication Request block 3121 and an Offer Response Block then there is a Hard Error, otherwise 3122 - if the input message also contains an Authentication Request block 3123 and Authentication Status block then there is Hard Error otherwise, 3124 - if the input message also contains an Authentication Request block 3125 and the IOTP Transaction is recognised by the Consumer role's system, 3126 then there is a Hard Error, otherwise 3127 - if the input message also contains an Authentication Status block and 3128 the IOTP Transaction is not recognised by the Consumer role's system 3129 then there is a Hard Error, otherwise 3130 - if input message also contains an Authentication Status Block and the 3131 Authentication Status Block has not been sent after an earlier 3132 Authentication Response message then there is a hard error 3133 - if input message also contains an Offer Response Block and the IOTP 3134 Transaction is recognised by the Consumer role's system then there is 3135 a Hard Error, otherwise 3136 - if the TPO Block occurs on its own and the IOTP Transaction is 3137 recognised by the Consumer role's system then there is a Hard Error 3139 o Offer Response Block. Check as follows: 3140 - if the Offer Response Block is not part of an IOTP Transaction that 3141 is recognised by the Consumer role then there is a Hard Error, 3142 otherwise 3143 - if the Offer Response Block does not refer to an IOTP transaction 3144 where a TPO Selection Block was the last message sent then there is a 3145 Hard Error 3147 o Payment Exchange Block. Check as follows: 3148 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 3149 that is recognised by the Consumer role's system then there is a Hard 3150 Error, otherwise 3151 - if the Payment Exchange doesn't refer to an IOTP Transaction where 3152 either a Payment Request or a Payment Exchange block was most 3153 recently sent then there is a Hard Error 3155 o Payment Response Block. Check as follows: 3157 - if the Payment Response Block doesn't refer to an IOTP Transaction 3158 that is recognised by the Consumer role's system then there is a Hard 3159 Error, otherwise 3160 - if the Payment Response doesn't refer to an IOTOP Transaction where 3161 either a Payment Request or a Payment Exchange block was most 3162 recently sent then there is a Hard Error 3164 o Delivery Response Block. Check as follows: 3165 - if the Delivery Response Block doesn't refer to an IOTP Transaction 3166 that is recognised by the Consumer role's system then there is a Hard 3167 Error, otherwise 3168 - If the Delivery Response doesn't refer to an IOTP Transaction where 3169 either a Payment Request or a Payment Exchange block was most 3170 recently sent then there is a Hard Error 3172 4.6.3 Cancelling a Transaction 3174 This process cancels a current transaction on an Consumer role's system 3175 as a result of an external request from the user, or another system or 3176 server in the Consumer's role. The processing is the same as for an IOTP 3177 Server (see section 4.5.3). 3179 4.6.4 Retransmitting Messages 3181 The process of retransmitting messages is the same as for an IOTP Server 3182 (see section 4.5.4). 3184 5. Security Considerations 3186 This section considers, from an IETF perspective how IOTP addresses 3187 security. The next section (see section 6. Digital Signatures and IOTP) 3188 describes how IOTP uses Digital Signatures when these are needed. 3190 This section covers: 3192 o determining whether to use digital signatures 3194 o data privacy, and 3196 o payment protocol security. 3198 5.1 Determining whether to use digital signatures 3200 The use of digital signatures within IOTP are entirely optional. IOTP can 3201 work successfully entirely without the use of digital signatures. 3203 Ultimately it is up to the Merchant, or other trading role, to decide 3204 whether IOTP Messages will include signatures, and for the Consumer to 3205 decide whether carrying out a transaction without signatures is an 3206 acceptable risk. If Merchants discover that transactions without 3207 signatures are not being accepted, then they will either: 3209 o start using signatures, 3211 o find a method of working which does not need signatures, or 3213 o accept a lower volume and value of business. 3215 A non-exhaustive list of the reasons why digital signatures might be used 3216 follows: 3218 o the Merchant (or other trading role) wants to demonstrate that they can 3219 be trusted. If, for example, a merchant generates an Offer Response 3220 Signature (see section 7.19.2) using a certificate from a trusted third 3221 party, known to the Consumer, then the Consumer can check the signature 3222 and certificate and so more reasonably rely on the offer being from the 3223 actual organisation the Merchant claims to be. In this case signatures 3224 using asymmetric cryptography are likely to be required 3226 o the Merchant, or other Trading Role, want to generate a record of the 3227 transaction that is fit for a particular purpose. For example, with 3228 appropriate trust hierarchies, digital signatures could be checked by 3229 the Consumer to determine: 3230 - if it would be accepted by tax authorities as a valid record of a 3231 transaction, or 3232 - if some warranty, for example from a "Better Business Bureau" or 3233 similar was being provided 3235 o the Payment Handler, or Delivery Handler, needs to know that the 3236 request is unaltered and authorised. For example, in IOTP, details of 3237 how much to pay is sent to the Consumer in the Offer Response and then 3238 forwarded to the Payment Handler in a Payment Request. If the request 3239 is not signed, the Consumer could change the amount due by, for 3240 example, removing a digit. If the Payment Handler has no access to the 3241 original payment information in the Offer Response, then, without 3242 signatures, the Payment Handler cannot be sure that the data has not 3243 been altered. Similarly, if the payment information is not digitally 3244 signed, the Payment Handler cannot be sure who is the Merchant that is 3245 requesting the payment 3247 o a Payment Handler or Delivery Handler wants to provide a non-refutable 3248 record of the completion status of a Payment or Delivery. If a Payment 3249 Response or Delivery Response is signed, then the Consumer can later 3250 use the record of the Payment or Delivery to prove that it occurred. 3251 This could be used, for example, for customer care purposes. 3253 A non-exhaustive list of the reasons why digital signatures might not be 3254 used follows: 3256 o trading roles are combined therefore changes to data made by the 3257 consumer can be detected. One of the reasons for using signatures is so 3258 that one trading role can determine if data has been changed by the 3259 Consumer or some other party. However if the trading roles have access 3260 to the necessary data, then it might be possible to compare, for 3261 example, the payment information in the Payment Request with the 3262 payment information in the Offer Response. Access to the data necessary 3263 could be realised by, for example, the Merchant and Payment Handler 3264 roles being carried out by the same organisation on the same system, or 3265 the Merchant and Payment Handler roles being carried out on different 3266 systems but the systems can communicate in some way. (Note this type of 3267 communication is outside the current scope of IOTP) 3269 o the processing cost of the cryptography is too high. For example, if a 3270 payment is being made of only a few cents, the cost of carrying out all 3271 the cryptography associated with generating and checking digital 3272 signatures might make the whole transaction uneconomic. Co-locating 3273 trading roles, could help avoid this problem. 3275 5.2 Symmetric and Asymmetric Cryptography 3277 The advantage of using symmetric keys with IOTP is that no Public Key 3278 Infrastructure need be set up and just the Merchant, Payment Handler and 3279 Delivery Handler need to agree the shared secrets to use. 3281 However the disadvantage of symmetric cryptography is that the Consumer 3282 cannot easily check the credentials of the Merchant, Payment Handler, 3283 etc. that they are dealing with. This is likely to reduce, somewhat, the 3284 trust that the Consumer will have carrying out the transaction. 3286 However it should be noted that even if asymmetric cryptography is being 3287 used, the Consumer does not NEED to be provided with any digital 3288 certificates as the integrity of the transaction is determined by, for 3289 example, the Payment Handler checking the Offer Response Signature copied 3290 to the Payment Request. 3292 Note that symmetric, asymmetric or both types of cryptography may be used 3293 in a single transaction. 3295 5.3 Data Privacy 3297 Privacy of information is provided by sending IOTP Messages between the 3298 various Trading Roles using a secure channel such as [SSL/TLS]. Use of a 3299 secure channel within IOTP is optional. 3301 5.4 Payment Protocol Security 3303 IOTP is designed to be completely blind to the payment protocol being 3304 used to effect a payment. From the security perspective, this means that 3305 IOTP neither helps, nor hinders, the achievement of payment security. 3307 If it is necessary to consider payment security from an IOTP perspective, 3308 then this should be included in the payment protocol supplement which 3309 describes how IOTP supports that payment protocol. 3311 However what IOTP is designed to do is to use digital signatures to bind 3312 together the record, contained in a "response" message, of each trading 3313 exchange in a transaction. For example IOTP can bind together: an Offer, 3314 a Payment and a Delivery. 3316 6. Digital Signatures and IOTP 3318 IOTP can work successfully without using any digital signatures although 3319 in an open networking environment it will be less secure - see 5. 3320 Security Considerations for a description of the factors that need to be 3321 considered. 3323 However, this section describes how to use digital signatures in the many 3324 situations when they will be needed. Topics covered are: 3326 o an overview of how IOTP uses digital signatures 3328 o how to check a signature is correctly calculated 3330 o how Payment Handlers and Delivery Handlers check they can carry out 3331 payments or deliveries on behalf of a Merchant. 3333 6.1 How IOTP uses Digital Signatures 3335 In general, signatures when used with IOTP: 3337 o are always treated as IOTP Components (see section 7) 3339 o contain digests of one or more IOTP Components or Trading Blocks, 3340 possibly including other Signature Components, in any IOTP message 3341 within the same IOTP Transaction 3343 o identify: 3344 - which Organisation signed (originated) the signature, and 3345 - which Organisation(s) should process the signature in order to check 3346 that the Action the Organisation should take can occur. 3348 Digital certificates may be associated with digital signatures if 3349 asymmetric cryptography is being used. However if symmetric cryptography 3350 is being used, then the digital certificate will be replaced by some 3351 identifier of the secret key to use. 3353 The way in which Signatures Components digest one or more elements is 3354 illustrated in the figure below. 3356 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3358 IOTP MESSAGE SIGNATURE COMPONENT 3360 IOTP Message Signature Id = P1.3 3361 |-Trans Ref Block digest TransRefBlk |-Manifest 3362 | | ID=P1.1-----------------------------|->|-Digest of P1.1-- 3363 | |-Trans Id Comp digest TransIdComp | | | 3364 | | ID = M1.2----------------------------|->|-Digest of M1.2--| 3365 | |-Msg Id Comp. digest Signature | | | 3366 | | ID = P1 -------------------|->|-Digest of M1.5--| 3367 | | digest element | | | 3368 |-Signatures Block | -----------------|->|-Digest of M1.7--| 3369 | | ID=P1.2 | | digest element | | | 3370 | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| 3371 | |-Signature ID=M1.5---- | | | | | 3372 | |-Signature ID=P1.4 | | Points to | -RecipientInfo* | 3373 | |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 | 3374 | | | | Certs to use | Sig.ValueRef=P1.4 | 3375 | | | | | | | 3376 | | | | | | | 3377 |-Trading Block. ID=P1.5 | | | v | 3378 | |-Comp. ID=M1.7---------- | -Value* ID=P1.4: | 3379 | | | JtvwpMdmSfMbhK<-- 3380 | |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI 3381 | | | J8pxLjoSRfe1o6k 3382 | |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<- 3383 | |-Comp. ID=C1.5 3384 Digital signature of Manifest element 3385 using certificate identified by CertRef 3387 Elements that are digested can be in any IOTP Message 3388 within the same IOTP Transaction 3389 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3391 Figure 10 Signature Digests 3393 [Note] The classic example of one signature signing another in IOTP, 3394 is when an Offer is first signed by a Merchant creating an 3395 "Offer Response" signature, which is then later signed by a 3396 Payment Handler together with a record of the payment creating 3397 a "Payment Receipt" signature. In this way, the payment in an 3398 IOTP Transaction is bound to the Merchant's offer. 3399 [Note End] 3401 Note that one Manifest may be associated with multiple signature "Value" 3402 elements where each Value element contains a digital signature over the 3403 same Manifest, perhaps using the same (or different) signature algorithm 3404 but using a different certificate or shared secret key. Specifically it 3405 will allow the Merchant to agree different shared secrets keys with their 3406 Payment Handler and Delivery Handler. 3408 The detailed definitions of a Signature component are contained in 3409 section 7.19. 3411 The remainder of this section contains: 3413 o an example of how IOTP uses signatures 3415 o how the OriginatorInfo and RecipientInfo elements within a Signature 3416 Component are used to identify the organisations associated with the 3417 signature 3419 o how IOTP uses signatures to prove actions complete successfully 3421 6.1.1 IOTP Signature Example 3423 An example of how signatures are used is illustrated in the figure below 3424 which shows how the various components and elements in a Baseline 3425 Purchase relate to one another. Refer to this example in the later 3426 description of how signatures are used to check a payment or delivery can 3427 occur (see section 6.3). 3429 [Note] A Baseline Purchase transaction has been used for illustration 3430 purposes. The usage of the elements and attributes is the same 3431 for all types of IOTP Transactions. 3432 [Note End] 3433 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3435 TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK 3436 | (Offer Response) 3437 Brand Selection Organisation<--- |------Signature 3438 Component Component | | Component 3439 | | | -Manifest 3440 |BrandList -Trading Role | | 3441 | Ref Element | Originator |-Orig. 3442 v (Merchant) ------------|--Info 3443 Brand List Ref | 3444 >Component | 3445 | |-Protocol ------> Organisation Recipient |-Recipient 3446 | | Amount Elem | Component <------------------|--Info 3447 | | | | | Refs | 3448 | |Pay|Protocol |Action -Trading Role | 3449 | | | Ref |OrgRef Element | 3450 | | v | (Payment Handler) | 3451 | -PayProtocol-- | 3452 | Elem ->Organisation Recipient |-Recipient 3453 | | Component <--------------------Info 3454 | | | Refs 3455 | | -Trading Role 3456 | | Element 3457 | | (Delivery Handler 3458 | 3459 | OFFER RESPONSE BLOCK 3460 | | 3461 |BrandListRef |ActionOrgRef 3462 | | 3463 --Payment ---Delivery 3464 Component Component 3466 The Manifest element in the Signature Component contains digests of: 3467 the Trans Ref Block (not shown); the Transaction ID Component (not 3468 shown); Organisation Components (Merchant, Payment Handler, Delivery 3469 Handler); the Brand List Component; the Order Component, the Payment 3470 Component the Delivery Component and the Brand Selection Component (if a 3471 Brand Dependent Purchase). 3473 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3475 Figure 11 Example use of Signatures for Baseline Purchase 3477 6.1.2 OriginatorInfo and RecipientInfo Elements 3479 The OriginatorRef attribute of the OriginatorInfo element in the 3480 Signature Component contains an Element Reference (see section 3.5) that 3481 points to the Organisation Component of the Organisation which generated 3482 the Signature. In this example its the Merchant. 3484 Note that the value of the content of the Attribute element with a Type 3485 attribute set to IOTP Signature Type must match the Trading Role of the 3486 Organisation which signed it. If it does not, then it is an error. Valid 3487 combinations are given in the table below. 3489 IOTP Signature Type Valid Trading Role 3491 OfferResponse Merchant 3493 PaymentResponse PaymentHandler 3495 DeliveryResponse DeliveryHandler 3497 AuthenticationRequest any role 3499 AuthenticationResponse any role 3501 PingRequest any role 3503 PingResponse any role 3505 The RecipientRefs attribute of the RecipientInfo element in the Signature 3506 Component contains Element References to the Organisation Components of 3507 the Organisations that should use the signature to verify that: 3509 o they have a pre-existing relationship with the Organisation that 3510 generated the signature, 3512 o the data which is secured by the signature has not been changed, 3514 o the data has been signed correctly, and 3516 o the action they are required to undertake on behalf of the Merchant is 3517 therefore authorised. 3519 Note that if symmetric cryptography is being used then a separate 3520 RecipientInfo and Value elements for each different set of shared secret 3521 keys are likely within the Signature Component. 3523 Alternatively if asymmetric cryptography is being used then the 3524 RecpientRefs attribute of one RecipientInfo element may refer to multiple 3525 Organisation Components if they are all using the same certificates. 3527 6.1.3 Using signatures to Prove Actions Complete Successfully 3529 Proving an action completed successfully, is achieved by signing data on 3530 Response messages. Specifically: 3532 o on the Offer Response, when a Merchant is making an Offer to the 3533 Consumer which can then be sent to either: 3534 - a Payment Handler to prove that the Merchant authorises Payment, or 3535 - a Delivery Handler to prove that Merchant authorises Delivery, 3536 provided other necessary authorisations are complete (see below) 3538 o on the Payment Response, when a Payment Handler is generating a Payment 3539 Receipt which can be sent to either: 3540 - a Delivery Handler, in a Delivery Request Block to authorise Delivery 3541 together with the Offer Response signature, or 3542 - another Payment Handler, in a second Payment Request, to authorise 3543 the second payment in a Value Exchange IOTP Transaction 3545 o Delivery Response, when a Delivery Handler is generating a Delivery 3546 Note. This can be used to prove after the event what the Delivery 3547 Handler said they would do 3549 o Authentication Response. One method of authenticating another party to 3550 a trade is to send an Authentication Request specifying that a Digital 3551 Signature should be used for authentication 3553 o Transaction Status Inquiry. The Inquiry Response Block may be digitally 3554 signed to attest to the authenticity of the response 3556 o Ping. The Ping Response may be digitally signed so that checks can be 3557 made that the signature can be understood. 3559 This proof of an action may, in future versions of IOTP, also be used to 3560 prove after the event that the IOTP transaction occurred. For example to 3561 a Customer Care Provider. 3563 6.2 Checking a Signature is Correctly Calculated 3565 Checking a signature is correctly calculated is part of checking for 3566 Message Level Errors (see section 4.3.2). It is included here so that all 3567 signature and security related considerations are kept together. 3569 Before a Trading Role can check a signature it must identify which of the 3570 potentially multiple Signature elements should be checked. The steps 3571 involved are as follows: 3573 o check that a Signature Block is present and it contains one or more 3574 Signature Components 3576 o identify the Organisation Component which contains an OrgId attribute 3577 for the Organisation which is carrying out the signature check. If no 3578 or more than one Organisation Component is found then it is an error 3580 o use the ID attribute of the Organisation Component to find the 3581 RecipientInfo element that contains a RecipientRefs attribute that 3582 refers to that Organisation Component. Note there may be no signatures 3583 to verify 3585 o check the Signature Component that contains the identified 3586 RecipientInfo element as follows: 3587 - use the SignatureValueRef and the SignatureAlgorithmRef attributes to 3588 identify, respectively: the Value element that contains the signature 3589 to be checked and the Signature Algorithm element that describes the 3590 signature algorithm to be used to verify the Signature, then 3591 - if the Signature Algorithm element indicates that asymmetric 3592 cryptography is being used then use the SignatureCertRef to identify 3593 the Certificate to be used by the signature algorithm 3594 - if Signature Algorithm element indicates that symmetric cryptography 3595 is being used then the content of the RecipientInfo element is used 3596 to identify the correct shared secret key to use 3597 - use the specified signature algorithm to check that the Value Element 3598 correctly signs the Manifest Element 3599 - check that the Digest Elements in the Manifest Element are correctly 3600 calculated where Components or Blocks referenced by the Digest have 3601 been received by the organisation checking the signature. 3603 6.3 Checking a Payment or Delivery can occur 3605 This section describes the processes required for a Payment Handler or 3606 Delivery Handler to check that a payment or delivery can occur. This may 3607 include checking signatures if this is specified by the Merchant. 3609 In outline the steps are: 3611 o check that the Payment Request or Delivery Request has been sent to the 3612 correct organisation 3614 o check that correct IOTP components are present in the request, and 3616 o check that the payment or delivery is authorised 3618 For clarity and brevity the following terms or phrases are used in this 3619 section: 3621 o a "Request Block" is used to refer to either a Payment Request Block 3622 (see section 8.7) or a Delivery Request Block (see section 8.10) unless 3623 specified to the contrary 3625 o a "Response Block" is used to refer to either a Payment Response Block 3626 (see section 8.9) or a Delivery Response Block (see section 8.11) 3628 o an "Action" is used to refer to an action which occurs on receipt of a 3629 Request Block. Actions can be either a Payment or a Delivery 3631 o an "Action Organisation", is used to refer to the Payment Handler or 3632 Delivery Handler that carries out an Action 3634 o a "Signer of an Action", is used to refer to the Organisations that 3635 sign data about an Action to authorise the Action, either in whole or 3636 in part 3638 o a "Verifier of an Action", is used to refer to the Organisations that 3639 verify data to determine if they are authorised to carry out the Action 3641 o an ActionOrgRef attribute contains Element References which can be used 3642 to identify the "Action Organisation" that should carry out an Action 3644 6.3.1 Check Request Block sent Correct Organisation 3646 Checking the Request Block was sent to the correct Organisation varies 3647 depending on whether the request refers to a Payment or a Delivery. 3649 6.3.1.1 Payment 3651 In outline a Payment Handler checks if it can accept or make a payment by 3652 identifying the Payment Component in the Payment Request Block it has 3653 received, then using the ID of the Payment Component to track through the 3654 Brand List and Brand Selection Components to identify the Organisation 3655 selected by the Consumer and then checking that this organisation is 3656 itself. 3658 The way data is accessed to do this is illustrated in the figure below. 3660 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3661 Start 3662 | 3663 v 3664 Brand List<--------------------------+-----------Payment 3665 Component BrandListRef | Component 3666 | | 3667 |-Brand<-------------------------- | 3668 | Element BrandRef | | 3669 | | Brand Selection 3670 | |Protocol Component 3671 | | AmountRefs | | 3672 | v Protocol | | 3673 |-Protocol Amount<---------------- | 3674 | Element---------- AmountRef | 3675 | | | | 3676 | |Currency |Pay | 3677 | | AmountRefs |Protocol | 3678 | v |Ref | 3679 |-Currency Amount | | 3680 | Element<---------|---------------- 3681 | | 3682 -PayProtocol<----- 3683 Element---------------------->Organisation 3684 Action Component 3685 OrgRef | 3686 -Trading Role 3687 Element 3688 (Payment Handler) 3690 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3691 Figure 14 Checking a Payment Handler can carry out a Payment 3693 Figure 12 Checking a Payment Handler can carry out a Payment 3695 The following describes the steps involved and the checks which need to 3696 be made: 3698 o Identify the Payment Component (see section 7.9) in the Payment Request 3699 Block that was received. 3701 o Identify the Brand List and Brand Selection Components for the Payment 3702 Component. This involves: 3703 - identifying the Brand List Component (see section 7.7) where the 3704 value of its ID attribute matches the BrandListRef attribute of the 3705 Payment Component. If no or more than one Brand List Component is 3706 found there is an error. 3707 - identifying the Brand Selection Component (see section 7.8) where the 3708 value of its BrandListRef attribute matches the BrandListRef of the 3709 Payment Component. If no or more than one matching Brand Selection 3710 Component is found there is an error. 3712 o Identify the Brand, Protocol Amount, Pay Protocol and Currency Amount 3713 elements within the Brand List that have been selected by the Consumer 3714 as follows: 3715 - the Brand Element (see section 7.7.1) selected is the element where 3716 the value of its Id attribute matches the value of the BrandRef 3717 attribute in the Brand Selection. If no or more than one matching 3718 Brand Element is found then there is an error. 3719 - the Protocol Amount Element (see section 7.7.3) selected is the 3720 element where the value of its Id attribute matches the value of the 3721 ProtocolAmountRef attribute in the Brand Selection Component. If no 3722 or more than one matching Protocol Amount Element is found there is 3723 an error 3724 - the Pay Protocol Element (see section 7.7.5) selected is the element 3725 where the value of its Id attribute matches the value of the 3726 PayProtocolRef attribute in the identified Protocol Amount Element. 3727 If no or more than one matching Pay Protocol Element is found there 3728 is an error 3729 - the Currency Amount Element (see section 7.7.4) selected is the 3730 element where the value of its Id attribute matches the value of the 3731 CurrencyAmountRef attribute in the Brand Selection Component. If no 3732 or more than one matching Currency Amount element is found there is 3733 an error 3735 o Check the consistency of the references in the Brand List and Brand 3736 Selection Components: 3737 - check that an Element Reference exists in the ProtocolAmountRefs 3738 attribute of the identified Brand Element that matches the Id 3739 attribute of the identified Protocol Amount Element. If no or more 3740 than one matching Element Reference can be found there is an error 3741 - check that the CurrencyAmountRefs attribute of the identified 3742 Protocol Amount element contains an element reference that matches 3743 the Id attribute of the identified Currency Amount element. If no or 3744 more than one matching Element Reference is found there is an error. 3745 - check the consistency of the elements in the Brand List. 3746 Specifically, the selected Brand, Protocol Amount, Pay Protocol and 3747 Currency Amount Elements are all child elements of the identified 3748 Brand List Component. If they are not there is an error. 3750 o Check that the Payment Handler that received the Payment Request Block 3751 is the Payment Handler selected by the Consumer. This involves: 3752 - identifying the Organisation Component for the Payment Handler. This 3753 is the Organisation Component where its ID attribute matches the 3754 ActionOrgRef attribute in the identified Pay Protocol Element. If no 3755 or more than one matching Organisation Component is found there is an 3756 error 3757 - checking the Organisation Component has a Trading Role Element with a 3758 Role attribute of PaymentHandler. If not there is an error 3759 - finally, if the identified Organisation Component is not the same as 3760 the organisation that received the Payment Request Block, then there 3761 is an error. 3763 6.3.1.2 Delivery 3765 The way data is accessed by a Delivery Handler in order to check that it 3766 may carry out a delivery is illustrated in the figure below. 3768 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3769 Start 3770 | 3771 v 3772 Delivery 3773 Component 3774 | 3775 |ActionOrgRef 3776 | 3777 v 3778 Organisation 3779 Component 3780 | 3781 -Trading Role 3782 Element 3783 (Delivery Handler) 3785 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3787 Figure 13 Checking a Delivery Handler can carry out a Delivery 3789 The steps involved are as follows: 3791 o Identify the Delivery Component in the Delivery Request Block. If there 3792 is no or more than one matching Delivery Component there is an error 3794 o Use the ActionOrgRef attribute of the Delivery Component to identify 3795 the Organisation Component of the Delivery Handler. If there is no or 3796 more than one matching Organisation Component there is an error 3798 o If the Organisation Component for the Delivery Handler does not have a 3799 Trading Role Element with a Role attribute of DeliveryHandler there is 3800 an error 3802 o Finally, if the organisation that received the Delivery Request Block 3803 does not identify the Organisation Component for the Delivery Handler 3804 as itself, then there is an error. 3806 6.3.2 Check Correct Components present in Request Block 3808 Check that the correct components are present in the Payment Request 3809 Block (see section 8.7) or in the Delivery Request Block (see section 3810 8.10). 3812 If components are missing, there is an error. 3814 6.3.3 Check an Action is Authorised 3816 The previous steps identified the Action Organisation and that all the 3817 necessary components are present. This step checks that the Action 3818 Organisation is authorised to carry out the Action. 3820 In outline the Action Organisation will identifies the Merchant, checks 3821 that it has a pre-existing agreement with the Merchant that allows it 3822 carry out the Action and that any constraints implied by that agreement 3823 are being followed, then, if signatures are required, it checks that they 3824 sign the correct data. 3826 The steps involved are as follows: 3828 o Identify the Merchant. This is the Organisation Component with a 3829 Trading Role Element which has a Role attribute with a value of 3830 Merchant. If no or more than one Trading Role Element is found, there 3831 is an error 3833 o Check the Action Organisation's agreements with the Merchant allows the 3834 Action to be carried out. To do this the Action Organisation must check 3835 that: 3837 - the Merchant is known and a pre-existing agreement exists for the 3838 Action Organisation to be their agent for the payment or delivery 3839 - they are allowed to take part in the type of IOTP transaction that is 3840 occurring. For example a Payment Handler may have agreed to accept 3841 payments as part of a Baseline Purchase, but not make payments as 3842 part of a Baseline Refund 3843 - any constraints in their agreement with the Merchant are being 3844 followed, for example, whether or not an Offer Response signature is 3845 required 3847 o Check the signatures are correct. If signatures are required then they 3848 need to be checked. This involves: 3849 - Identifying the correct signatures to check. This involves the Action 3850 Organisation identifying the Signature Components that contain 3851 references to the Action Organisation (see 6.3.1). Depending on the 3852 IOTP Transaction being carried out (see section 9) either one or two 3853 signatures may be identified 3854 - checking that the Signature Components are correct. This involves 3855 checking that Digest elements exist within the Manifest Element that 3856 refer to the necessary Trading Components (see section 6.3.3.1). 3858 6.3.3.1 Check the Signatures Digests are correct 3860 All Signature Components contained within IOTP Messages must include 3861 Digest elements that refer to: 3863 o the Transaction Id Component (see section 3.3.1) of the IOTP message 3864 that contains the Signature Component. This binds the globally unique 3865 IotpTransId to other components which make up the IOTP Transaction 3867 o the Transaction Reference Block (see section 3.3) of the first IOTP 3868 Message that contained the signature. This binds the IotpTransId with 3869 information about the IOTP Message contained inside the Message Id 3870 Component (see section 3.3.2). 3872 Check that each Signature Component contains Digest elements that refer 3873 to the correct data required. 3875 The Digest elements that need to be present depend on the Trading Role of 3876 the Organisation which generated (signed) the signature: 3878 o if the signer of the signature is a Merchant then: 3879 - Digest elements must be present for all the components in the Request 3880 Block apart from the Brand Selection Component which is optional 3882 o if the signer of the signature is a Payment Handler then Digest 3883 elements must be present for: 3884 - the Signature Component signed by the Merchant, and optionally 3885 - one or more Signature Components signed by the previous Payment 3886 Handler(s) in the Transaction. 3888 7. Trading Components 3890 This section describes the Trading Components used within IOTP. Trading 3891 Components are the child XML elements which occur immediately below a 3892 Trading Block as illustrated in the diagram below. 3894 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3896 IOTP MESSAGE <----------- IOTP Message - an XML Document 3897 | which is transported between the 3898 | Trading Roles 3899 |-Trans Ref Block <----- Trans Ref Block - contains 3900 | | information which describes the 3901 | | IOTP Transaction and the IOTP 3902 Message. 3903 --------> | |-Trans Id Comp. <--- Transaction Id Component - 3904 | | | uniquely identifies the IOTP 3905 | | | Transaction. The Trans Id 3906 | | | Components are the same across 3907 | | | all IOTP messages that comprise 3908 | | | a single IOTP transaction. 3909 | | |-Msg Id Comp. <----- Message Id Component - 3910 | | identifies and describes an IOTP 3911 | | Message within an IOTP 3912 | | Transaction 3913 | |-Signature Block <----- Signature Block (optional) - 3914 | | | contains one or more Signature 3915 | | | Components and their associated 3916 | | | Certificates 3917 | ---> | |-Signature Comp. <-- Signature Component - contains 3918 | | | | digital signatures. Signatures 3919 | | | | may sign digests of the Trans Ref 3920 | | | | Block and any Trading Component 3921 | | | | in any IOTP Message in the same 3922 | | | | IOTP Transaction. 3923 | | | |-Certificate Comp. <- Certificate Component. Used to 3924 | | | check the signature. 3925 Trading |-Trading Block <-------- Trading Block - an XML Element 3926 Components | |-Trading Comp. within an IOTP Message that 3927 | | | |-Trading Comp. contains a predefined set of 3928 | ---> | |-Trading Comp. Trading Components 3929 | | |-Trading Comp. 3930 | | |-Trading Comp. <----- Trading Components - XML 3931 | | Elements within a Trading Block 3932 | |-Trading Block that contain a predefined set of 3933 --------> | |-Trading Comp. XML elements and attributes 3934 | |-Trading Comp. containing information required 3935 | |-Trading Comp. to support a Trading Exchange 3936 | |-Trading Comp. 3937 | |-Trading Comp. 3938 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3939 Figure 14 Trading Components 3941 The Trading Components described in this section are listed below in 3942 approximately the sequence they are likely to be used: 3944 o Protocol Options Component 3946 o Authentication Request Component 3948 o Authentication Response Component 3950 o Trading Role Information Request Component 3952 o Order Component 3954 o Organisation Component 3956 o Brand List Component 3958 o Brand Selection Component 3960 o Payment Component 3962 o Payment Scheme Component 3964 o Payment Receipt Component 3966 o Delivery Component 3968 o Delivery Note Component 3970 o Signature Component 3972 o Certificate Component 3974 o Error Component 3976 Note that the following components are listed in other sections of this 3977 specification: 3979 o Transaction Id Component (see section 3.3.1) 3981 o Message Id Component (see section 3.3.2) 3983 7.1 Protocol Options Component 3985 Protocol options are options which apply to the IOTP Transaction as a 3986 whole. Essentially it provides a short description of the entire 3987 transaction and the net location which the Consumer role should branch to 3988 if the IOTP Transaction is successful. 3990 The definition of a Protocol Options Component is as follows. 3992 3993 4001 Attributes: 4003 ID An identifier which uniquely identifies the 4004 Protocol Options Component within the IOTP 4005 Transaction. 4007 Xml:lang Defines the language used by attributes or child 4008 elements within this component, unless 4009 overridden by an xml:lang attribute on a child 4010 element. See section 3.8 Identifying Languages. 4012 ShortDesc This contains a short description of the IOTP 4013 Transaction in the language defined by xml:lang. 4014 Its purpose is to provide an explanation of what 4015 type of IOTP Transaction is being conducted by 4016 the parties involved. 4018 It is used to facilitate selecting an individual 4019 transaction from a list of similar transactions, 4020 for example from a database of IOTP transactions 4021 which has been stored by a Consumer, Merchant, 4022 etc. 4024 SenderNetLocn This contains the non secured net location of 4025 the sender of the TPO Block in which the 4026 Protocol Options Component is contained. 4028 It is the net location to which the recipient of 4029 the TPO block should send a TPO Selection Block 4030 if required. 4032 The content of this attribute is dependent on 4033 the Transport Mechanism see the Transport 4034 Mechanism Supplement. 4036 SecureSenderNetLocn This contains the secured net location of the 4037 sender of the TPO Block in which the Protocol 4038 Options Component is contained. 4040 The content of this attribute is dependent on 4041 the Transport Mechanism see the Transport 4042 Mechanism Supplement. 4044 SuccessNetLocn This contains the net location that should be 4045 displayed after the IOTP Transaction has 4046 successfully completed. 4048 The content of this attribute is dependent on 4049 the Transport Mechanism see the Transport 4050 Mechanism Supplement. 4052 Either SenderNetLocn, SecureSenderNetLocn or both must be present. 4054 7.2 Authentication Request Component 4056 This Trading Component contains parameter data that is used in an 4057 Authentication of one Trading Role by another. Its definition is as 4058 follows. 4060 4061 4066 If required the Algorithm may use the challenge data, contained in the 4067 Packaged Content elements within the Authentication Request Component in 4068 its calculation. The format of the Packaged Contents are Algorithm 4069 dependent. 4071 Attributes: 4073 ID An identifier which uniquely identifies the 4074 Authentication Request Component within the IOTP 4075 Transaction. 4077 AuthenticationId An identifier specified by the Authenticator 4078 which, if returned by the Organisation that 4079 receives the Authentication Request, will enable 4080 the Authenticator to identify which Authentication 4081 is being referred to. 4083 ContentSoftwareId See section 14. Glossary. 4085 Content: 4087 PackagedContent This contains the challenge data as one or more 4088 Packaged Content (see section 3.7) that is to be 4089 responded to using the Algorithm defined by the 4090 Algorithm element. 4092 Algorithm This contains information which describes the 4093 Algorithm (see 7.19 Signature Components) that 4094 must be used to generate the Authentication 4095 Response. 4097 The Algorithms that may be used are identified by 4098 the Name attribute of the Algorithm element. For 4099 valid values see section 12. IANA Considerations. 4101 7.3 Authentication Response Component 4103 The Authentication Response Component contains the results of an 4104 authentication request. It uses the Algorithm contained in the 4105 Authentication Request Component (see section 7.2) selected from the 4106 Authentication Request Block (see section 8.4). 4108 Depending on the Algorithm selected, the results of applying the 4109 algorithm will either be contained in a Signature Component that signs 4110 both the Authentication Response and potentially other data, or in the 4111 Packaged Content elements within the Authentication Response Component. 4112 Its definition is as follows. 4114 4115 4121 Attributes: 4123 ID An identifier which uniquely identifies the 4124 Authentication Response Component within the 4125 IOTP Transaction. 4127 AuthenticationId The Authentication identifier specified by the 4128 Authenticator that was included in the 4129 Authentication Request Component(see section 4130 7.2). This will enable the Authenticator to 4131 identify the Authentication that is being 4132 referred to. 4134 SelectedAlgorithmRef An Element Reference that identifies the 4135 Algorithm element used to generate the 4136 Authentication Response. 4138 ContentSoftwareId See section 14. Glossary. 4140 Content: 4142 PackagedContent This may contain the response generated as a 4143 result of applying the Algorithm selected from the 4144 Authentication Request Component see section 7.2. 4146 For example, for a payment specific scheme, it may 4147 contain scheme-specific data. Refer to the scheme- 4148 specific supplemental documentation for 4149 definitions of its content. 4151 7.4 Trading Role Information Request Component 4153 This Trading Component contains a list of Trading Roles (see section 2.1) 4154 about which information is being requested. The result of a Trading Role 4155 Request is a set of Organisation Components (see section 7.6) that 4156 describe each of the Trading Roles requested. 4158 Example usage includes: 4160 o a Merchant requesting that a Consumer provides Organisation Components 4161 for the Consumer and DelivTo Trading Roles 4163 o a Consumer requesting from a Merchant, information about the Payment 4164 Handlers and Delivery Handlers that the Merchant uses. 4166 Its definition is as follows. 4168 4169 4173 Attributes: 4175 ID An identifier which uniquely identifies the 4176 Trading Role Information Request Component within 4177 the IOTP Transaction. 4179 TradingRoleList Contains a list of one or more Trading Roles (see 4180 the TradingRole attribute of the Trading Role 4181 Element - section 7.6.2) for which information is 4182 being requested. 4184 7.5 Order Component 4186 An Order Component contains information about an order. Its definition is 4187 as follows. 4189 4190 4200 Attributes: 4202 ID An identifier which uniquely identifies the Order 4203 Component within the IOTP Transaction. 4205 xml:lang Defines the language used by attributes or child 4206 elements within this component, unless overridden 4207 by an xml:lang attribute on a child element. See 4208 section 3.8 Identifying Languages. 4210 OrderIdentifier This is a code, reference number or other 4211 identifier which the creator of the Order may use 4212 to identify the order. It must be unique within an 4213 IOTP Transaction. If it is used in this way, then 4214 it may remove the need to specify any content for 4215 the Order element as the reference can be used to 4216 look up the necessary information in a database. 4218 ShortDesc A short description of the order in the language 4219 defined by xml:lang. It is used to facilitate 4220 selecting an individual order from a list of 4221 orders, for example from a database of orders 4222 which has been stored by a Consumer, Merchant, 4223 etc. 4225 OkFrom The date and time in [UTC] format after which the 4226 offer made by the Merchant lapses. 4228 OkTo The date and time in [UTC] format before which a 4229 Value Acquirer may accept the offer made by the 4230 Merchant is not valid. 4232 ApplicableLaw A phrase in the language defined by xml:lang which 4233 describes the state or country of jurisdiction 4234 which will apply in resolving problems or 4235 disputes. 4237 ContentSoftwareId See section 14. Glossary. 4239 Content: 4241 PackagedContent An optional description of the order information 4242 as one or more Packaged Contents (see section 4243 3.7). 4245 7.5.1 Order Description Content 4247 The Packaged Content element will normally be required, however it may be 4248 omitted where sufficient information about the purchase can be provided 4249 in the ShortDesc attribute. If the full Order Description requires it 4250 several Packaged Content elements may be used. 4252 Although the amount and currency are likely to appear in the Packaged 4253 Content of the Order Description it is the amount and currency contained 4254 in the payment related trading components (Brand List, Brand Selection 4255 and Payment) that is authoritative. This means it is important that the 4256 amount actually being paid (as contained in the payment related trading 4257 components) is prominently displayed to the Consumer. 4259 For interoperability, implementations must support Plain Text, HTML and 4260 XML as a minimum so that it can be easily displayed. 4262 7.5.2 OkFrom and OkTo Timestamps 4264 Note that: 4266 o the OkFrom date may be later than the OkFrom date on the Payment 4267 Component (see section 7.9) associated with this order, and 4269 o similarly, the OkTo date may be earlier that the OkTo date on the 4270 Payment Component (see section 7.9). 4272 [Note] Disclaimer. The following information provided in this note 4273 does not represent formal advice of any of the authors of this 4274 specification. Readers of this specification must form their 4275 own views and seek their own legal counsel on the usefulness 4276 and applicability of this information. 4278 The merchant in the context of Internet commerce with 4279 anonymous consumers initially frames the terms of the offer on 4280 the web page, and in order to obtain the goods or services, 4281 the consumer must accept them. 4283 If there is to be a time-limited offer, it is recommended that 4284 merchants communicate this to the consumer and state in the 4285 order description in a manner which is clear to the consumer 4286 that: 4287 o the offer is time limited 4288 o the OkFrom and OkTo timestamps specify the validity of the 4289 offer 4290 o the clock, e.g. the merchant's clock, that will be used to 4291 determine the validity of the offer 4293 Also note that although the OkFrom and OkTo dates are likely 4294 to appear in the Packaged Content of the Order Description it 4295 is the dates contained in the Order Component that is 4296 authoritative. This means it is important that the OkFrom and 4297 OkTo dates actually being used is prominently displayed to the 4298 Consumer. 4299 [Note End] 4301 7.6 Organisation Component 4303 The Organisation Component provides information about an individual or an 4304 organisation. This can be used for a variety of purposes. For example: 4306 o to describe the merchant who is selling the goods, 4308 o to identify who made a purchase, 4310 o to identify who will take delivery of goods, 4312 o to provide a customer care contact, 4314 o to describe who will be the Payment Handler. 4316 Note that the Organisation Components which must be present in an IOTP 4317 Message are dependent on the particular transaction being carried out. 4318 Refer to section 9. Internet Open Trading Protocol Transactions, for more 4319 details. 4321 Its definition is as follows. 4323 4325 4333 Attributes: 4335 ID An identifier which uniquely identifies the 4336 Organisation Component within the IOTP 4337 Transaction. 4339 xml:lang Defines the language used by attributes or child 4340 elements within this component, unless overridden 4341 by an xml:lang attribute on a child element. See 4342 section 3.8 Identifying Languages. 4344 OrgId A code which identifies the organisation described 4345 by the Organisation Component. See 7.6.1.1 4346 Organisation IDs, below. 4348 LegalName For organisations which are companies this is 4349 their legal name in the language defined by 4350 xml:lang. It is required for Organisations who 4351 have a Trading Role other than Consumer or 4352 DeliverTo. 4354 ShortDesc A short description of the organisation in the 4355 language defined by xml:lang. It is typically the 4356 name by which the organisation is commonly known. 4357 For example, if the legal name was "Blue Meadows 4358 Financial Services Inc.". Then its short name 4359 would likely be "Blue Meadows". 4361 It is used to facilitate selecting an individual 4362 organisation from a list of organisations, for 4363 example from a database of organisations involved 4364 in IOTP Transactions which has been stored by a 4365 consumer. 4367 LogoNetLocn The net location which can be used to download the 4368 logo for the organisation. 4370 See section 10 Retrieving Logos. 4372 The content of this attribute must conform to 4373 [RFC1738]. 4375 Content: 4377 TradingRole See 7.6.2 Trading Role Element below. 4379 ContactInfo See 7.6.3 Contact Information Element below. 4381 PersonName See 7.6.4 Person Name below. 4383 PostalAddress See 7.6.5 Postal Address below. 4385 7.6.1.1 Organisation IDs 4387 Organisation IDs are used by one IOTP Trading Role to identify another. 4388 In order to avoid confusion, this means that these IDs must be globally 4389 unique. 4391 In principle this is achieved in the following way: 4393 o the Organisation Id for all trading roles, apart from the Consumer 4394 Trading Role, uses a domain name as their globally unique identifier, 4396 o the Organisation Id for a Consumer Trading Role is allocated by one of 4397 the other Trading Roles in an IOTP Transaction and is made unique by 4398 concatenating it with that other roles' Organisation Id, 4400 o once a Consumer is allocated an Organisation Id within an IOTP 4401 Transaction the same Organisation Id is used by all the other trading 4402 roles in that IOTP transaction to identify that Consumer. 4404 Specifically, the content of the Organisation ID is defined as follows: 4406 OrgId ::= NonConsumerOrgId | ConsumerOrgId 4407 NonConsumerOrgId ::= DomainName 4408 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId 4409 ConsumerOrgIdPrefix ::= "Consumer:" 4411 ConsumerOrgId If the Organisation ID for a Consumer consists of: 4412 o a standard prefix to identify that the 4413 Organisation Id is for a consumer, followed by 4414 o one or more characters which conform to the 4415 definition of an XML "namechar". See [XML] 4416 specifications, followed by 4417 o the NonConsumerOrgId for the Organisation 4418 which allocated the ConsumerOrgId. It is 4419 normally the Merchant role. 4421 Use of upper and lower case is significant. 4423 NonConsumerOrgId If the Role is not Consumer then this contains the 4424 Canonical Name for the non-consumer organisation 4425 being described by the Organisation Component. See 4426 [DNS]. 4428 Note that a NonConsumerOrgId may not start with 4429 the ConsumerOrgIdPrefix. 4431 Use of upper and lower case is not significant. 4433 Examples of Organisation Ids follow: 4435 o newjerseybooks.com - a merchant organisation id 4437 o westernbank.co.uk - a Payment Handler organisation id 4439 o consumer:1000247ABH/newjerseybooks.com - a consumer organisation id 4440 allocated by a merchant 4442 7.6.2 Trading Role Element 4444 This identifies the Trading Role of an individual or organisation in the 4445 IOTP Transaction. Note, an organisation may have more than one Trading 4446 Role and several roles may be present in one organisation element. Its 4447 definition is as follows: 4449 4450 4458 Attributes: 4460 ID An identifier which uniquely identifies the 4461 Trading Role Element within the IOTP Transaction. 4463 TradingRole The trading role of the organisation. Valid values 4464 are: 4465 o Consumer. The person or organisation that is 4466 acting in the role of a consumer in the IOTP 4467 Transaction. 4468 o Merchant. The person or organisation that is 4469 acting in the role of merchant in the IOTP 4470 Transaction. 4471 o PaymentHandler. The financial institution or 4472 other organisation which is a Payment Handler 4473 for the IOTP Transaction 4474 o DeliveryHandler. The person or organisation 4475 that is the delivering the goods or services 4476 for the IOTP Transaction 4477 o DelivTo. The person or organisation that is 4478 receiving the delivery of goods or services in 4479 the IOTP Transaction 4480 o CustCare. The organisation and/or individual 4481 who will provide customer care for an IOTP 4482 Transaction. 4484 Values of TradingRole are controlled under the 4485 procedures defined in section 12 IANA 4486 Considerations which also allows user defined 4487 values to be defined. 4489 IotpMsgIdPrefix Contains the prefix which must be used for all 4490 IOTP Messages sent by the Trading Role in this 4491 IOTP Transaction. The values to be used are 4492 defined in 3.4.1 IOTP Message ID Attribute 4493 Definition. 4495 CancelNetLocn This contains the net location of where the 4496 Consumer should go to if the Consumer cancels the 4497 transaction for some reason. It can be used by the 4498 Trading Role to provide a response which is more 4499 tailored to the circumstances of a particular 4500 transaction. 4502 This attribute: 4503 o must not be present when TradingRole is set to 4504 Consumer role or DelivTo, 4505 o must be present when TradingRole is set to 4506 Merchant, PaymentHandler or DeliveryHandler. 4508 The content of this attribute is dependent on the 4509 Transport Mechanism see the Transport Mechanism 4510 Supplement. 4512 ErrorNetLocn This contains the net location that should be 4513 displayed by the Consumer after the Consumer has 4514 either received or generated an Error Block 4515 containing an Error Component with the Severity 4516 attribute set to either: 4517 o HardError, 4518 o Warning but the Consumer decides to not 4519 continue with the transaction 4520 o TransientError and the transaction has 4521 subsequently timed out. 4523 See section 7.21.1 Error Processing Guidelines for 4524 more details. 4526 This attribute: 4527 o must not be present when TradingRole is set to 4528 Consumer or DelivTo, 4529 o must be present when TradingRole is set to 4530 Merchant, PaymentHandler or DeliveryHandler. 4532 The content of this attribute is dependent on the 4533 Transport Mechanism see the Transport Mechanism 4534 Supplement. 4536 ErrorLogNetLocn Optional. This contains the net location that 4537 Consumers should send IOTP Messages that contain 4538 Error Blocks with an Error Component with the 4539 Severity attribute set to either: 4540 o HardError, 4541 o Warning but the Consumer decides to not 4542 continue with the transaction 4543 o TransientError and the transaction has 4544 subsequently timed out. 4546 This attribute: 4547 o must not be present when TradingRole is set to 4548 Consumer role, 4549 o must be present when TradingRole is set to 4550 Merchant, PaymentHandler or DeliveryHandler. 4552 The content of this attribute is dependent on the 4553 Transport Mechanism see the Transport Mechanism 4554 Supplement. 4556 The ErrorLogNetLocn can be used to send error 4557 messages to the software company or some other 4558 organisation responsible for fixing problems in 4559 the software which sent the incoming message. See 4560 section 7.21.1 Error Processing Guidelines for 4561 more details. 4563 7.6.3 Contact Information Element 4565 This contains information which can be used to contact an organisation or 4566 an individual. All attributes are optional however at least one item of 4567 contact information should be present. Its definition is as follows. 4569 4570 4577 Attributes: 4579 xml:lang Defines the language used by attributes within 4580 this element. See section 3.8 Identifying 4581 Languages. 4583 Tel A telephone number by which the organisation may 4584 be contacted. Note that this is a text field and 4585 no validation is carried out on it. 4587 Fax A fax number by which the organisation may be 4588 contacted. Note that this is a text field and no 4589 validation is carried out on it. 4591 Email An email address by which the organisation may be 4592 contacted. Note that this field should conform to 4593 the conventions for address specifications 4594 contained in [RFC822]. 4596 NetLocn A location on the Internet by which information 4597 about the organisation may be obtained that can be 4598 displayed using a web browser. 4600 The content of this attribute must conform to 4601 [RFC1738]. 4603 7.6.4 Person Name Element 4605 This contains the name of an individual person. All fields are optional 4606 however as a minimum either the GivenName or the FamilyName should be 4607 present. Its definition is as follows. 4609 4610 4617 Attributes: 4619 xml:lang Defines the language used by attributes within 4620 this element. See section 3.8 Identifying 4621 Languages. 4623 Title A distinctive name; personal appellation, 4624 hereditary or not, denoting or implying office 4625 (e.g. judge, mayor) or nobility (e.g. duke, 4626 duchess, earl), or used in addressing or referring 4627 to a person (e.g. Mr, Mrs, Miss) 4629 GivenName The primary or main name by which a person is 4630 known amongst and identified by their family, 4631 friends and acquaintances. Otherwise known as 4632 first name or Christian Name. 4634 Initials The first letter of the secondary names (other 4635 than the Given Name) by which a person is known 4636 amongst or identified by their family, friends and 4637 acquaintances. 4639 FamilyName The name by which family of related individuals 4640 are known. It is typically the part of an 4641 individual's name which is passed on by parents to 4642 their children. 4644 7.6.5 Postal Address Element 4646 This contains an address which can be used, for example, for the physical 4647 delivery of goods, services or letters. Its definition is as follows. 4649 4650 4660 Attributes: 4662 xml:lang Defines the language used by attributes within 4663 this element. See section 3.8 Identifying 4664 Languages. 4666 AddressLine1 The first line of a postal address. e.g. "The 4667 Meadows" 4669 AddressLine2 The second line of a postal address. e.g. "Sandy 4670 Lane" 4672 CityOrTown The city of town of the address. e.g. "Carpham" 4673 StateOrRegion The state or region within a country where the 4674 city or town is placed. e.g. "Surrey" 4676 Postal Code The code known as, for example a post code or zip 4677 code, that is typically used by Postal 4678 Organisations to organise postal deliveries into 4679 efficient sequences. e.g. "KT22 1AA" 4681 Country The country for the address. e.g. "UK" 4683 LegalLocation This identifies whether the address is the 4684 Registered Address for the Organisation. At least 4685 one address for the Organisation must have a value 4686 set to True unless the Trading Role is either 4687 Consumer or DeliverTo. 4689 7.7 Brand List Component 4691 Brand List Components are contained within the Trading Protocol Options 4692 Block (see section 8.1) of the IOTP Transaction. They contains lists of: 4694 o payment Brands (see also section 11.1 Brand Definitions and Brand 4695 Selection), 4697 o amounts to be paid in the currencies that are accepted or offered by 4698 the Merchant, 4700 o the payment protocols which can be used to make payments with a Brand, 4701 and 4703 o the net locations of the Payment Handlers which accept payment for a 4704 payment protocol 4706 The definition of a Brand List Component is as follows. 4708 4710 4716 Attributes: 4718 ID An identifier which uniquely identifies the Brand 4719 List Component within the IOTP Transaction. 4721 xml:lang Defines the language used by attributes or child 4722 elements within this component, unless overridden 4723 by an xml:lang attribute on a child element. See 4724 section 3.8 Identifying Languages. 4726 ShortDesc A text description in the language defined by 4727 xml:Lang giving details of the purpose of the 4728 Brand List. This information must be displayed to 4729 the receiver of the Brand List in order to assist 4730 with making the selection. It is of particular 4731 benefit in allowing a Consumer to distinguish the 4732 purpose of a Brand List when an IOTP Transaction 4733 involves more than one payment. 4735 PayDirection Indicates the direction in which the payment for 4736 which a Brand is being selected is to be made. Its 4737 values may be: 4738 o Debit The sender of the Payment Request Block 4739 (e.g. the Consumer) to which this Brand List 4740 relates will make the payment to the Payment 4741 Handler, or 4742 o Credit The sender of the Payment Request Block 4743 to which this Brand List relates will receive a 4744 payment from the Payment Handler. 4746 Content: 4748 Brand This describes a Brand. The sequence of the Brand 4749 elements (see section 7.7.1) within the Brand List 4750 does not indicate any preference. It is 4751 recommended that software which processes this 4752 Brand List presents Brands in a sequence which the 4753 receiver of the Brand List prefers. 4755 ProtocolAmount This links a particular Brand to: 4756 o the currencies and amounts in CurrencyAmount 4757 elements that can be used with the Brand, and 4758 o the Payment Protocols and Payment Handlers, 4759 which can be used with those currencies and 4760 amounts, and a particular Brand 4762 CurrencyAmount This contains a currency code and an amount. 4764 PayProtocol This contains information about a Payment Protocol 4765 and the Payment Handler which may be used with a 4766 particular Brand. 4768 The relationships between the elements which make up the content of the 4769 Brand List is illustrated in the diagram below. 4771 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 4773 Brand List Component 4774 | ProtocolAmountRefs 4775 |-Brand Element----------------------------- 4776 | | | 4777 | - Protocol Brand Element-------- | 4778 | | | 4779 | ProtocolId| | 4780 | | | 4781 |-Protocol Amount Element<----------+------- 4782 | | | | 4783 | | | | 4784 | |CurrencyAmountRefs |Pay | 4785 | | |Protocol | 4786 | v |Ref | 4787 |-Currency Amount Element | | 4788 | Element | | 4789 | | | 4790 -PayProtocolElement<------<-------- 4792 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 4794 Figure 15 Brand List Element Relationships 4796 Examples of complete Brand Lists are contained in section 11.2 Brand List 4797 Examples. 4799 7.7.1 Brand Element 4801 A Brand Element describes a brand that can be used for making a payment. 4802 One or more of these elements is carried in each Brand List Component 4803 that has the PayDirection attribute set to Debit. Exactly one Brand 4804 Element may be carried in a Brand List Component that has the 4805 PayDirection attribute set to Credit. 4807 4808 4818 Attributes: 4820 Id Element identifier, potentially referenced in a 4821 Brand Selection Component contained in a later 4822 Payment Request message and uniquely identifies 4823 the Brand element within the IOTP Transaction. 4825 xml:lang Defines the language used by attributes and 4826 content of this element. See section 3.8 4827 Identifying Languages. 4829 BrandId This contains a unique identifier for the brand 4830 (or promotional brand). It is used to match 4831 against a list of Payment Instruments which the 4832 Consumer holds to determine whether or not the 4833 Consumer can pay using the Brand. 4835 Values of BrandId are managed under the procedure 4836 described in section 12 IANA Considerations. 4838 As values of BrandId are controlled under the 4839 procedures defined in section 12 IANA 4840 Considerations user defined values may be 4841 defined. 4843 BrandName This contains the name of the brand, for example 4844 MasterCard Credit. This is the description of the 4845 Brand which is displayed to the consumer in the 4846 Consumers language defined by xml:lang. For 4847 example it might be "American Airlines Advantage 4848 Visa". Note that this attribute is not used for 4849 matching against the payment instruments held by 4850 the Consumer. 4852 BrandLogoNetLocn The net location which can be used to download 4853 the logo for the organisation. See section 4854 Retrieving Logos (see section 10). 4856 The content of this attribute must conform to 4857 [RFC1738]. 4859 BrandNarrative This optional attribute is designed to be used by 4860 the Merchant to indicate some special conditions 4861 or benefit which would apply if the Consumer 4862 selected that brand. For example "5% discount", 4863 "free shipping and handling", "free breakage 4864 insurance for 1 year", "double air miles apply", 4865 etc. 4867 ProtocolAmountRefs Identifies the protocols and related currencies 4868 and amounts which can be used with this Brand. 4869 Specified as a list of ID's of Protocol Amount 4870 Elements (see section 7.7.3) contained within the 4871 Brand List. 4873 ContentSoftwareId See section 14. Glossary. 4875 Content: 4877 ProtocolBrand Protocol Brand elements contain brand information 4878 to be used with a specific payment protocol (see 4879 section 7.7.2) 4881 PackagedContent Optional Packaged Content (see section 3.7) 4882 elements containing information about the brand 4883 which may be used by the payment protocol. The 4884 content of this information is defined in the 4885 supplement for a payment protocol which describes 4886 how the payment protocol works with IOTP. 4888 Example Brand Elements are contained in section 11.2 Brand List Examples. 4890 7.7.2 Protocol Brand Element 4892 The Protocol Brand Element contains information that is specific to the 4893 use of a particular Protocol with a Brand. Its definition is as follows. 4895 4896 4900 Attributes: 4902 ProtocolId This must match the value of a ProtocolId 4903 attribute in a Pay Protocol Element (see section 4904 7.7.5). 4906 The values of ProtocolId should be unique within a 4907 Brand Element otherwise there is an error. 4909 ProtocolBrandId This is the Payment Brand Id to be used with a 4910 particular payment protocol. For example, SET and 4911 EMV have their own well defined, yet different, 4912 values for the Brand Id to be used with each 4913 protocol. 4915 The valid values of this attribute are defined in 4916 the supplement for the payment protocol identified 4917 by ProtocolId that describes how the payment 4918 protocol works with IOTP. 4920 Content: 4922 PackagedContent Optional Packaged Content (see section 3.7) 4923 elements containing information about the 4924 protocol/brand which may be used by the payment 4925 protocol. The content of this information is 4926 defined in the supplement for a payment protocol 4927 which describes how the payment protocol works 4928 with IOTP. 4930 7.7.3 Protocol Amount Element 4932 The Protocol Amount element links a Brand to: 4934 o the currencies and amounts in Currency Amount Elements (see section 4935 7.7.4) that can be used with the Brand, and 4937 o the Payment Protocols and Payment Handlers defined in a Pay Protocol 4938 Element (see section 7.7.5), which can be used with those currencies 4939 and amounts. 4941 Its definition is as follows: 4943 4944 4950 Attributes: 4952 Id Element identifier, potentially referenced in a 4953 Brand element; or in a Brand Selection Component 4954 contained in a later Payment Request message 4955 which uniquely identifies the Protocol Amount 4956 element within the IOTP Transaction. 4958 PayProtocolRef Contains an Element Reference (see section 3.5) 4959 that refers to the Pay Protocol Element (see 4960 section 7.7.5) that contains the Payment Protocol 4961 and Payment Handlers that can be used with the 4962 Brand. 4964 CurrencyAmountRefs Contains a list of Element References (see 4965 section 3.5) that refer to the Currency Amount 4966 Element (see section 7.7.4) that describes the 4967 currencies and amounts that can be used with the 4968 Brand. 4970 ContentSoftwareId See section 14. Glossary. 4972 Content: 4974 PackagedContent Optional Packaged Content (see section 3.7) 4975 elements containing information about the protocol 4976 amount which may be used by the payment protocol. 4977 The content of this information is defined in the 4978 supplement for a payment protocol which describes 4979 how the payment protocol works with IOTP. 4981 Examples of Protocol Amount Elements are contained in section 11.2 Brand 4982 List Examples. 4984 7.7.4 Currency Amount Element 4986 A Currency Amount element contains: 4988 o a currency code (and its type), and 4990 o an amount. 4992 One or more of these elements is carried in each Brand List Component. 4993 Its definition is as follows: 4995 4996 5002 Attributes: 5004 Id Element identifier, potentially referenced in a 5005 Brand element; or in a Brand Selection Component 5006 contained in a later Payment Request message which 5007 uniquely identifies the Currency Amount Element 5008 within the IOTP Transaction. 5010 Amount Indicates the amount to be paid in whole and 5011 fractional units of the currency. For example 5012 $245.35 would be expressed "245.35". Note that 5013 values smaller than the smallest denomination are 5014 allowed. For example one tenth of a cent would be 5015 "0.001". 5017 CurrCodeType Indicates the domain of the CurrCode. This 5018 attribute is included so that the currency code 5019 may support non-standard "currencies" such as 5020 frequent flyer points, trading stamps, etc. Its 5021 values may be: 5022 o ISO4217-A (the default) indicates the currency 5023 code is a three character alphabetic currency 5024 code that conforms to [ISO 4217] 5025 o IOTP indicates that values of CurrCode are 5026 managed under the procedure described in 5027 section 12 IANA Considerations 5029 CurrCode A code which identifies the currency to be used in 5030 the payment. The domain of valid currency codes is 5031 defined by CurrCodeType 5033 As values of CurrCodeType are managed under the 5034 procedure described in section 12 IANA 5035 Considerations user defined values of CurrCodeType 5036 may be defined. 5038 Examples of Currency Amount Elements are contained in section 11.2 Brand 5039 List Examples. 5041 7.7.5 Pay Protocol Element 5043 A Pay Protocol element specifies details of a Payment Protocol and the 5044 Payment Handler that can be used with a Brand. One or more of these 5045 elements is carried in each Brand List. 5047 5048 5058 Attributes: 5060 Id Element identifier, potentially referenced in a 5061 Brand element; or in a Brand Selection Component 5062 contained in a later Payment Request message which 5063 uniquely identifies the Pay Protocol element 5064 within the IOTP Transaction. 5066 xml:lang Defines the language used by attributes and 5067 content of this element. See section 3.8 5068 Identifying Languages. 5070 ProtocolId Consists of a protocol name and version. For 5071 example "SETv1.0". 5073 The values of ProtocolId are defined by the 5074 payment scheme/method owners in the document that 5075 describes how to encapsulate a payment protocol 5076 within IOTP. 5078 ProtocolName A narrative description of the payment protocol 5079 and its version in the language identified by 5080 xml:lang. For example "Secure Electronic 5081 Transaction Version 1.0". Its purpose is to help 5082 provide information on the payment protocol being 5083 used if problems arise. 5085 ActionOrgRef An Element Reference (see section 3.5) to the 5086 Organisation Component for the Payment Handler for 5087 the Payment Protocol. 5089 PayReqNetLocn The Net Location indicating where an unsecured 5090 Payment Request message should be sent if this 5091 protocol choice is used. 5093 The content of this attribute is dependent on the 5094 Transport Mechanism (such must conform to 5095 [RFC1738]. 5097 SecPayReqNetLocn The Net Location indicating where a secured 5098 Payment Request message should be sent if this 5099 protocol choice is used. 5101 A secured payment involves the use of a secure 5102 channel such as [SSL/TLS] in order to communicate 5103 with the Payment Handler. 5105 The content of this attribute must conform to 5106 [RFC1738]. See also See section 3.9 Secure and 5107 Insecure Net Locations. 5109 ContentSoftwareId See section 14. Glossary. 5111 Content: 5113 PackagedContent Optional Packaged Content elements (see section 5114 3.7) containing information about the protocol 5115 which is used by the payment protocol. The content 5116 of this information is defined in the supplement 5117 for a payment protocol which describes how the 5118 payment protocol works with IOTP. An example of 5119 its use could be to include a payment protocol 5120 message. 5122 Examples of Pay Protocol Elements are contained in section 11.2 Brand 5123 List Examples. 5125 7.8 Brand Selection Component 5127 A Brand Selection Component identifies the choice of payment brand, 5128 payment protocol and the Payment Handler. This element is used: 5130 o in Payment Request messages within Baseline Purchase and Baseline Value 5131 IOTP Transactions to identify the brand, protocol and payment handler 5132 for a payment, or 5134 o to, optionally, inform a merchant in a purchase of the payment brand 5135 being used so that the offer and order details can be amended 5136 accordingly. 5138 In Baseline IOTP, the integrity of Brand Selection Components is not 5139 guaranteed. However, modification of Brand Selection Components can only 5140 cause denial of service if the payment protocol itself is secure against 5141 message modification, duplication, and swapping attacks. 5143 The definition of a Brand Selection Component is as follows. 5145 5148 5155 Attributes: 5157 ID An identifier which uniquely identifies the Brand 5158 Selection Component within the IOTP Transaction. 5160 BrandListRef The Element Reference (see section 3.5) of the 5161 Brand List Component from which a Brand is being 5162 selected 5164 BrandRef The Element Reference of a Brand element within 5165 the Brand List Component that is being selected 5166 that is to be used in the payment. 5168 ProtocolAmountRef The Element Reference of a Protocol Amount element 5169 within the Brand List Component which is to be 5170 used when making the payment. 5172 CurrencyAmountRef The Element Reference of a Currency Amount element 5173 within the Brand List Component which is to be 5174 used when making the payment. 5176 Content: 5178 BrandSelBrandInfo, This contains any additional data that 5179 BrandSelProtocolAmountInfo, may be required by a particular payment 5180 BrandSelCurrencyAmountInfo brand or protocol. See sections 7.8.1, 5181 7.8.2, and 7.8.3. 5183 The following rules apply: 5185 o the BrandListRef must contain the ID of a Brand List Component in the 5186 same IOTP Transaction 5188 o every Brand List Component in the Trading Protocol Options Block (see 5189 section 8.1) must be referenced by one and only one Brand Selection 5190 Component 5192 o the BrandRef must refer to the ID of a Brand contained within the Brand 5193 List Component referred to by BrandListRef 5195 o the ProtocolAmountRef must refer to one of the Element IDs listed in 5196 the ProtocolAmountRefs attribute of the Brand element identified by 5197 BrandRef 5199 o the CurrencyAmountRef must refer to one of the Element IDs listed in 5200 the CurrencyAmountRefs attribute of the Protocol Amount Element 5201 identified by ProtocolAmountRef. 5203 An example of a Brand Selection Component is included in 11.2 Brand List 5204 Examples. 5206 7.8.1 Brand Selection Brand Info Element 5208 The Brand Selection Brand Info Element contains any additional data that 5209 may be required by a particular payment brand. See the IOTP payment 5210 method supplement for a description of how and when it used. 5212 5213 5217 Attributes: 5219 ContentSoftwareId See section 14. Glossary. 5221 Content: 5223 PackagedContent Packaged Content elements (see section 3.7) that 5224 contain additional data that may be required by a 5225 particular payment brand. See the payment method 5226 supplement for IOTP for rules on how this is used. 5228 7.8.2 Brand Selection Protocol Amount Info Element 5230 The Brand Selection Protocol Amount Info Element contains any additional 5231 data that is payment protocol specific that may be required by a 5232 particular payment brand or payment protocol. See the IOTP payment method 5233 supplement for a description of how and when it used. 5235 5236 5240 Attributes: 5242 ContentSoftwareId See section 14. Glossary. 5244 Content: 5246 PackagedContent Packaged Content elements (see section 3.7) that 5247 may contain additional data that may be required 5248 by a particular payment brand. See the payment 5249 method supplement for IOTP for rules on how this 5250 is used. 5252 7.8.3 Brand Selection Currency Amount Info Element 5254 The Brand Selection Currency Amount Info Element contains any additional 5255 data that is payment brand and currency specific that may be required by 5256 a particular payment brand. See the IOTP payment method supplement for a 5257 description of how and when it used. 5259 5260 5264 Attributes: 5266 ContentSoftwareId See section 14. Glossary. 5268 Content: 5270 PackagedContent Packaged Content elements (see section 3.7) that 5271 contain additional data relating to the payment 5272 brand and currency. See the payment method 5273 supplement for IOTP for rules on how this is used. 5275 7.9 Payment Component 5277 A Payment Component contains information used to control how a payment is 5278 carried out. Its provides information on: 5280 o the times within which a Payment with a Payment Handler may be started 5282 o a reference to the Brand List (see section 7.7) which identifies the 5283 Brands, protocols, currencies and amounts which can be used to make a 5284 payment 5286 o whether or not a payment receipt will be provided 5288 o whether another payment precedes this payment. 5290 Its definition is as follows. 5292 5293 5301 Attributes: 5303 ID An identifier which uniquely identifies the 5304 Payment Component within the IOTP Transaction. 5306 OkFrom The date and time in [UTC] format after which a 5307 Payment Handler may accept for processing a 5308 Payment Request Block (see section 8.7) containing 5309 the Payment Component. 5311 OkTo The date and time in [UTC] format before which a 5312 Payment Handler may for processing accept a 5313 Payment Request Block containing the Payment 5314 Component. 5316 BrandListRef An Element Reference (see section 3.5) of a Brand 5317 List Component (see section 7.7) within the TPO 5318 Trading Block for the IOTP Transaction. The Brand 5319 List identifies the alternative ways in which the 5320 payment can be made. 5322 SignedPayReceipt Indicates whether or not the Payment Response 5323 Block (8.9) generated by the Payment Handler for 5324 the payment must be digitally signed. 5326 StartAfter Contains Element References (see section 3.5) of 5327 other Payment Components which describe payments 5328 which must be complete before this payment can 5329 start. If no StartAfter attribute is present then 5330 there are no dependencies and the payment can 5331 start immediately 5333 7.10 Payment Scheme Component 5335 A Payment Scheme Component contains payment protocol information for a 5336 specific payment scheme which is transferred between the parties involved 5337 in a payment for example a [SET] message. Its definition is as follows. 5339 5340 5347 Attributes: 5349 ID An identifier which uniquely identifies the 5350 Payment Scheme Component within the IOTP 5351 Transaction. 5353 PaymentRef An Element Reference (see section 3.5) to the 5354 Payment Component (see section 7.9) to which 5355 this Pay Scheme Data Component relates. It is 5356 required unless the Pay Scheme Data is part of 5357 an Transaction Inquiry Status Transaction (see 5358 section 9.2.1). 5360 ConsumerPaymentId An identifier specified by the Consumer which, 5361 if returned by the Payment Handler in another 5362 Payment Scheme Component or by other means, will 5363 enable the Consumer to identify which payment is 5364 being referred to. 5366 PaymentHandlerPayId An identifier specified by the Payment Handler 5367 which, if returned by the Consumer in another 5368 Payment Scheme Component, or by other means, 5369 will enable the Payment Handler to identify 5370 which payment is being referred to. It is 5371 required on every Payment Scheme Component apart 5372 from the one contained in a Payment Request 5373 Block. 5375 ContentSoftwareId See section 14. Glossary. 5377 Content: 5379 PackagedContent Contains payment scheme protocol information as 5380 Packaged Content elements (see section 3.7). See 5381 the payment scheme supplement for the definition 5382 of its content. 5384 Note that: 5385 o the values of the Name attribute of each 5386 packaged content element are defined by the 5387 Payment Protocol Supplement 5388 o the value of each Name must be unique within a 5389 Payment where a Payment is defined as all 5390 Payment Scheme or Payment Receipt Components 5391 with the same value of the PaymentRef attribute 5393 7.11 Payment Receipt Component 5395 A Payment Receipt is a record of a payment which demonstrates how much 5396 money has been paid or received. It is distinct from a purchase receipt 5397 in that it contains no record of what was being purchased. 5399 Typically the content of a Payment Receipt Component will contain data 5400 which describes: 5402 o the amount paid and its currency 5404 o the date and time of the payment 5406 o internal reference numbers which identify the payment to the payment 5407 system 5409 o potentially digital signatures generated by the payment method which 5410 can be used to prove after the event that the payment occurred. 5412 If the Payment Method being used provides the facility then the Payment 5413 Receipt Component should contain payment protocol messages, or references 5414 to messages, which prove the payment occurred. 5416 The precise definition of the content is Payment Method dependent. Refer 5417 to the supplement for the payment method being used to determine the 5418 rules that apply. 5420 Information contained in the Payment Receipt Component should be 5421 displayed or otherwise made available to the Consumer. 5423 [Note] If the Payment Receipt Component contains Payment Protocol 5424 Messages, then the Messages will need to be processed by 5425 Payment Method software to convert it into a format which can 5426 be understood by the Consumer 5427 [Note End] 5429 The definition of a Payment Receipt Component is as follows. 5431 5432 5438 Attributes: 5440 ID An identifier which uniquely identifies the 5441 Payment Receipt Component within the IOTP 5442 Transaction. 5444 PaymentRef Contains an Element Reference (see section 3.5) 5445 to the Payment Component (see section 7.9) to 5446 which this payment receipt applies 5448 PayReceiptNameRefs Optionally contains a list of the values of the 5449 Name attributes of Packaged Content elements that 5450 together make up the receipt. The Packaged 5451 Content elements are contained either within: 5452 o Payment Scheme Data components exchanged 5453 between the Payment Handler and the Consumer 5454 roles during the Payment, and/or 5455 o the Payment Receipt component itself. 5457 Note that: 5458 o each payment scheme defines in its supplement 5459 the Names of the Packaged Content elements 5460 that must be listed in this attribute (if 5461 any). 5462 o if a Payment Scheme Component contains 5463 Packaged Content elements with a name that 5464 matches a name within PaymentReceiptRefs, then 5465 those Payment Scheme Components must be 5466 referenced by Digests in the Payment Response 5467 signature component (if such a signature is 5468 being used) 5470 The client software should save all the 5471 components referenced so that the payment receipt 5472 can be reconstructed when required. 5474 ContentSoftwareId See section 14. Glossary. 5476 Content: 5478 PackagedContent Optionally contains payment scheme payment receipt 5479 information as Packaged Content elements (see 5480 section 3.7). See the payment scheme supplement 5481 for the definition of its content. 5483 Note that: 5484 o the values of the Name attribute of each 5485 packaged content element are defined by the 5486 Payment Protocol Supplement 5487 o the value of each Name must be unique within a 5488 Payment where a Payment is defined as all 5489 Payment Scheme or Payment Receipt Components, 5490 with the same value of the PaymentRef attribute 5492 Note that either the PayReceiptRefs attribute, the PackagedContent 5493 element, or both must be present. 5495 7.12 Payment Note Component 5497 The Payment Note Component contains additional, non payment related, 5498 information which the Payment Handler wants to provide to the Consumer. 5499 For example, if a withdrawal or deposit were being made then it could 5500 contain information on the remaining balance on the account after the 5501 transfer was complete. The information should duplicate information 5502 contained within the Payment Receipt Component. 5504 Information contained in the Payment Note Component should be displayed 5505 or otherwise made available to the Consumer. For interoperability, the 5506 Payment Note Component should support, as a minimum, the content types of 5507 "Plain Text", HTML and XML. Its definition is as follows. 5509 5510 5514 Attributes: 5516 ID An identifier which uniquely identifies the 5517 Payment Receipt Component within the IOTP 5518 Transaction. 5520 ContentSoftwareId See section 14. Glossary. 5522 Content: 5524 PackagedContent Contains additional, non payment related, 5525 information which the Payment Handler wants to 5526 provide to the Consumer as one or more Packaged 5527 Content elements (see section 3.7). 5529 7.13 Delivery Component 5531 The Delivery Element contains information required to deliver goods or 5532 services. Its definition is as follows. 5534 5535 5542 Attributes: 5544 ID An identifier which uniquely identifies the 5545 Delivery Component within the IOTP Transaction. 5547 xml:lang Defines the language used by attributes or child 5548 elements within this component, unless overridden 5549 by an xml:lang attribute on a child element. See 5550 section 3.8 Identifying Languages. 5552 DelivExch Indicates if this IOTP Transaction includes the 5553 messages associated with a Delivery Exchange. 5554 Valid values are: 5555 o True indicates it does include a Delivery 5556 Exchange 5557 o False indicates it does not include a 5558 Delivery Exchange 5560 If set to true then a DeliveryData element must 5561 be present. If set to false it may be absent. 5563 DelivAndPayResp Indicates if the Delivery Response Block (see 5564 section 8.11) and the Payment Response Block (see 5565 section 8.9 ) are combined into one IOTP Message. 5566 Valid values are: 5567 o True indicates both blocks will be in the 5568 same IOTP Message, and 5569 o False indicates each block will be in a 5570 different IOTP Message 5572 DelivAndPayResp should not be true if DelivExch 5573 is False. 5575 In practice combining the Delivery Response Block 5576 and Payment Response Block is only likely to be 5577 practical if the Merchant, the Payment Handler 5578 and the Delivery Handler are the same 5579 organisation since: 5580 o the Payment Handler must have access to Order 5581 Component information so that they know what 5582 to deliver, and 5583 o the Payment Handler must be able to carry out 5584 the delivery 5586 ActionOrgRef An Element Reference to the Organisation 5587 Component of the Delivery Handler for this 5588 delivery. 5590 Content: 5592 DeliveryData Contains details about how the delivery will be 5593 carried out. See 7.13.1 Delivery Data Element 5594 below. 5596 PackagedContent Contains "user" data defined for the Merchant 5597 which is required by the Delivery Handler as one 5598 or more Packaged Content Elements see section 3.7. 5600 7.13.1 Delivery Data Element 5602 The DeliveryData element contains information about where and how goods 5603 are to be delivered. Its definition is as follows. 5605 5606 5616 Attributes: 5618 xml:lang Defines the language used by attributes within 5619 this component. See section 3.8 Identifying 5620 Languages. 5622 OkFrom The date and time in [UTC] format after which the 5623 Delivery Handler may accept for processing a 5624 Delivery Request Block (see section 8.10). 5626 OkTo The date and time in [UTC] format before which 5627 the Delivery Handler may accept for processing a 5628 Delivery Request Block. 5630 DelivMethod Indicates the method by which goods or services 5631 may be delivered. Valid values are: 5632 o Post the goods will be delivered by post or 5633 courier 5634 o Web the goods will be delivered 5635 electronically in the Delivery Note Component 5636 o Email the goods will be delivered 5637 electronically by e-mail 5639 Values of DelivMethod are managed under the 5640 procedure described in section 12 IANA 5641 Considerations which allows user defined codes to 5642 be defined. 5644 DelivToRef The Element Reference (see section 3.4) of an 5645 Organisation Component within the IOTP 5646 Transaction which has a role of DelivTo. The 5647 information in this block is used to determine 5648 where delivery is to be made. It must be 5649 compatible with DelivMethod. Specifically if the 5650 DelivMethod is: 5651 o Post, then the there must be a Postal Address 5652 Element containing sufficient information for 5653 a postal delivery, 5654 o Web, then there are no specific requirements. 5655 The information will be sent in a web page 5656 back to the Consumer 5657 o Email, then there must be Contact Information 5658 Element with a valid e-mail address 5660 DelivReqNetLocn This contains the Net Location to which an 5661 unsecured Delivery Request Block (see section 5662 8.10) which contains the Delivery Component 5663 should be sent. 5665 The content of this attribute is dependent on the 5666 Transport Mechanism and must conform to 5667 [RFC1738]. 5669 SecDelivReqNetLocn This contains the Net Location to which a secured 5670 Delivery Request Block (see section 8.10) which 5671 contains the Delivery Component should be sent. 5673 A secured delivery request involves the use of a 5674 secure channel such as [SSL/TLS] in order to 5675 communicate with the Payment Handler. 5677 The content of this attribute is dependent on the 5678 Transport Mechanism must conform to [RFC1738]. 5680 See also Section 3.9 Secure and Insecure Net 5681 Locations. 5683 ContentSoftwareId See section 14. Glossary. 5685 Content: 5687 PackagedContent Additional information about the delivery as one 5688 or more Packaged Content elements (see section 5689 3.7) provided to the Delivery Handler by the 5690 merchant. 5692 7.14 Consumer Delivery Data Component 5694 A Consumer Delivery Data Component is used by a Consumer to specify an 5695 identifier that can be used by the Consumer to identify the Delivery. 5697 Its definition is as follows: 5699 5700 5704 Attributes: 5706 ID An identifier which uniquely identifies the 5707 Consumer Delivery Data Component within the IOTP 5708 Transaction. 5710 ConsumerDeliveryId An identifier specified by the Consumer which, if 5711 returned by the Delivery Handler will enable the 5712 Consumer to identify which Delivery is being 5713 referred to. 5715 7.15 Delivery Note Component 5717 A Delivery Note contains delivery instructions about the delivery of 5718 goods or services or potentially the actual Delivery Information itself. 5719 It is information which the person or organisation receiving the Delivery 5720 Note can use when delivery occurs. 5722 For interoperability, the Delivery Note Component Packaged Content should 5723 support both Plain Text, HTML and XML. 5725 5726 5732 Attributes: 5734 ID An identifier which uniquely identifies the 5735 Delivery Note Component within the IOTP 5736 Transaction. 5738 xml:lang Defines the language used by attributes or child 5739 elements within this component, unless 5740 overridden by an xml:lang attribute on a child 5741 element. See section 3.8 Identifying Languages. 5743 DelivHandlerDelivId An optional identifier specified by the Delivery 5744 Handler which, if returned by the Consumer in 5745 another Delivery Component, or by other means, 5746 will enable the Delivery Handler to identify 5747 which Delivery is being referred to. It is 5748 required on every Delivery Component apart from 5749 the one contained in a Delivery Request Block. 5751 An example use of this attribute is to contain a 5752 delivery tracking number. 5754 ContentSoftwareId See section 14. Glossary. 5756 Content: 5758 PackagedContent Contains actual delivery note information as one 5759 or more Packaged Content elements (see section 5760 3.7). 5762 [Note] If the content of the Delivery Message is a Mime message then 5763 the Delivery Note may trigger an application which causes the 5764 actual delivery to occur. 5765 [Note End] 5767 7.16 Status Component 5769 A Status Component contains status information about the business success 5770 or failure (see section 4.2) of a process. 5772 Its definition is as follows. 5774 5775 5786 Attributes: 5788 ID An identifier which uniquely identifies the Status 5789 Component within the IOTP Transaction. 5791 xml:lang Defines the language used by attributes within 5792 this component. See section 3.8 Identifying 5793 Languages. 5795 StatusType Indicates the type of Document Exchange which the 5796 Status is reporting on. It may be set to either 5797 Offer, Payment, Delivery, Authentication or 5798 Undefined. 5800 Undefined means that the type of document exchange 5801 could not be identified. This is caused by an 5802 error in the initial input message of the 5803 exchange. 5805 Values of StatusType are managed under the 5806 procedure described in section 12 IANA 5807 Considerations which also allows user defined 5808 values of StatusType to be defined. 5810 ElRef If the StatusType is not set to Undefined then 5811 ElRef contains an Element Reference (see section 5812 3.5) to the Component for which the Status is 5813 being described. It must refer to either: 5815 o a Order Component (see section 7.5), if the 5816 StatusType is Offer, 5817 o a Payment Component (see section 7.9), if the 5818 StatusType is Payment, or 5819 o a Delivery Component (see section 7.13), if 5820 the StatusType is Delivery 5821 o an Authentication Request Component (see 5822 section 7.2) if the StatusType is 5823 Authentication. 5825 ProcessState Contains a State Code which indicates the current 5826 state of the process being carried out. Valid 5827 values for ProcessState are: 5828 o NotYetStarted. A Request Block has been 5829 received but the process has not yet started 5830 o InProgress. Processing of the Request Block 5831 has started but it is not yet complete 5832 o CompletedOk. The processing of the Request 5833 Block has completed successfully without any 5834 errors 5835 o Failed. The processing of the Request Block 5836 has failed because of a business error (see 5837 section 4.2) 5838 o ProcessError. This value is only used when the 5839 Status Component is being used in connection 5840 with an Inquiry Request Trading Block (see 5841 section 8.12). It indicates there was a 5842 Technical Error (see section 4.1) in the 5843 Request Block which is being processed or some 5844 internal processing error. 5846 Note that this code reports on the processing of a 5847 Request Block. Further, asynchronous processing 5848 may occur after the Response Block associated with 5849 the Process has been sent. 5851 CompletionCode Indicates how the process completed. Valid values 5852 for the CompletionCode are given below together 5853 with the conditions when it must be present and 5854 indications on when recovery from failures are 5855 possible. 5857 A CompletionCode is a maximum of 14 characters 5858 long. 5860 ProcessReference This optional attribute holds a reference for the 5861 process whose status is being reported. It may 5862 hold the following values: 5863 o when StatusType is set to Offer, it should 5864 contain the OrderIdentifier from the Order 5865 Component 5866 o when StatusType is set to Payment, it should 5867 contain the PaymentHandlerPayId from the 5868 Payment Scheme Data Component 5870 o when StatusType is set to Delivery, it should 5871 contain the DelivHandlerDelivId from the 5872 Delivery Note Component 5873 o when StatusType is set to Authentication, it 5874 should contain the AuthenticationId from the 5875 Authentication Request Component 5877 This attribute should be absent in the Inquiry 5878 Request message when the Consumer has not been 5879 given such a reference number by the IOTP Service 5880 Provider. 5882 This attribute can be used in an inside an Inquiry 5883 Response Block (see section 8.13) to give the 5884 reference number for a transaction which has 5885 previously been unavailable. 5887 For example, the package tracking number might not 5888 be assigned at the time a delivery response was 5889 received. However, if the Consumer issues a 5890 Baseline Transaction Status Inquiry later, the 5891 Delivery Handler can put the package tracking 5892 number into this attribute in the Inquiry Response 5893 message and send it back to the Consumer. 5895 StatusDesc An optional textual description of the current 5896 status of the process in the language identified 5897 by xml:lang. 5899 7.16.1 Offer Completion Codes 5901 The Completion Code is only required if the ProcessState attribute is set 5902 to Failed. The following table contains the valid values for the 5903 CompletionCode that may be used and indicates whether or not recovery 5904 might be possible. It is recommended that the StatusDesc attribute is 5905 used to provide further explanation where appropriate. 5907 Value Description 5909 AuthError Authentication Error. The check of the 5910 Authentication Response which was carried out has 5911 failed. 5913 Recovery may be possible by the Consumer re- 5914 submitting a new Authentication Response Block with 5915 corrected information. 5917 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 5918 the transaction for some reason. This code is only 5919 valid in a Status Component contained in a Cancel 5920 Block or an Inquiry Response Block. 5922 No recovery possible. 5924 MerchCancelled Offer Cancelled. The Merchant declines to generate 5925 an offer for some reason and cancels the 5926 transaction. This code is only valid in a Status 5927 Component contained in a Cancel Block or an Inquiry 5928 Response Block. 5930 No recovery possible. 5932 Unspecified Unspecified error. There is some unknown problem or 5933 error which does not fall into one of the other 5934 CompletionCodes. 5936 No recovery possible. 5938 TimedOutRcvr Recoverable Time Out. Messages were resent but no 5939 response received. The document exchange has 5940 therefore "Timed Out". This code is only valid on a 5941 Transaction Inquiry. 5943 Recovery is possible if the last message from the 5944 other Trading Role is received again. 5946 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 5947 no response received. The document exchange has 5948 therefore "Timed Out". This code is only valid on a 5949 Transaction Inquiry. 5951 No recovery possible. 5953 7.16.2 Payment Completion Codes 5955 The CompletionCode is only required if the ProcessState attribute is set 5956 to Failed. The following table contains the valid values for the 5957 CompletionCode that may be used and indicates where recovery may be 5958 possible. It is recommended that the StatusDesc attribute is used by 5959 individual payment schemes to provide further explanation where 5960 appropriate. 5962 Value Description 5964 BrandNotSupp Brand not supported. The payment brand is not 5965 supported by the Payment Handler. 5967 See below for recovery options. 5969 CurrNotSupp Currency not supported. The currency in which the 5970 payment is to be made is not supported by either 5971 the Payment Instrument or the Payment Handler. 5973 If the payment is Brand Independent, then the 5974 Consumer may recover by selecting a different 5975 currency, if available, or a different brand. Note 5976 that this may involve a different Payment Handler. 5978 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 5979 the payment for some reason. This code is only 5980 valid in a Status Component contained in a Cancel 5981 Block or an Inquiry Response Block. 5983 Recovery is not possible. 5985 PaymtCancelled Payment Cancelled. The Payment Handler declines to 5986 complete the payment for some reason and cancels 5987 the transaction. This code is only valid in a 5988 Status Component contained in a Cancel Block or an 5989 Inquiry Response Block. 5991 See below for recovery options. 5993 AuthError Authentication Error. The Payment Scheme specific 5994 authentication check which was carried out has 5995 failed. 5997 Recovery may be possible. See the payment scheme 5998 supplement to determine what is allowed. 6000 InsuffFunds Insufficient funds. There are insufficient funds 6001 available for the payment to be made. 6003 See below for recovery options. 6005 InstBrandInvalid Payment Instrument not valid for Brand. A Payment 6006 Instrument is being used which does not correspond 6007 with the Brand selected. For example a Visa credit 6008 card is being used when MasterCard was selected as 6009 the Brand. 6011 See below for recovery options. 6013 InstNotValid Payment instrument not valid for trade. The 6014 Payment Instrument cannot be used for the proposed 6015 type of trade, for some reason. 6017 See below for recovery options. 6019 BadInstrument Bad instrument. There is a problem with the 6020 Payment Instrument being used which means that it 6021 is unable to be used for the payment. 6023 See below for recovery options. 6025 Unspecified Unspecified error. There is some unknown problem 6026 or error which does not fall into one of the other 6027 CompletionCodes. The StatusDesc attribute should 6028 provide the explanation of the cause. 6030 See below for recovery options. 6032 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6033 response received. The document exchange has 6034 therefore "Timed Out". This code is only valid on 6035 a Transaction Inquiry. 6037 Recovery is possible if the last message from the 6038 other Trading Role is received again. 6040 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 6041 no response received. The document exchange has 6042 therefore "Timed Out". This code is only valid on 6043 a Transaction Inquiry. 6045 No recovery possible. 6047 If the Payment is Brand Independent, then recovery may be possible for 6048 some values of the Completion Code, by the Consumer selecting either a 6049 different payment brand or a different payment instrument for the same 6050 brand. Note that this might involve a different Payment Handler. The 6051 codes to which this applies are: BrandNotSupp, PaymtCancelled, 6052 InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and 6053 Unspecified. 6055 Recovery from Payments associated with Brand Dependent purchases is only 6056 possible, if the Brand Selection component sent by the Merchant to the 6057 Consumer does not change. In practice this means that the same Brand, 6058 Protocol Amount and PayProtocol elements must be used. All that can 6059 change is the Payment Instrument. Any other change will invalidate the 6060 Merchant's Offer as a changed selection will invalidate the Offer 6061 Response. 6063 7.16.3 Delivery Completion Codes 6065 The following table contains the valid values for the CompletionCode 6066 attribute for a Delivery. It is recommended that the StatusDesc attribute 6067 is used to provide further explanation where appropriate. 6069 Value Description 6071 BackOrdered Back Ordered. The goods to be delivered are on order 6072 but they have not yet been received. Shipping will be 6073 arranged when they are received. This is only valid 6074 if ProcessState is CompletedOk. 6076 Recovery is not possible. 6078 PermNotAvail Permanently Not Available. The goods are permanently 6079 unavailable and cannot be re-ordered. This is only 6080 valid if ProcessState is Failed. 6082 Recovery is not possible. 6084 TempNotAvail Temporarily Not Available. The goods are temporarily 6085 unavailable and may become available if they can be 6086 ordered. This is only valid if ProcessState is 6087 CompletedOk. 6089 Recovery is not possible. 6091 ShipPending Shipping Pending. The goods are available and are 6092 scheduled for shipping but they have not yet been 6093 shipped. This is only valid if ProcessState is 6094 CompletedOk. 6096 Recovery is not possible. 6098 Shipped Goods Shipped. The goods have been shipped. 6099 Confirmation of delivery is awaited. This is only 6100 valid if ProcessState is CompletedOk. 6102 Recovery is not possible. 6104 ShippedNoConf Shipped - No Delivery Confirmation. The goods have 6105 been shipped but it is not possible to confirm 6106 delivery of the goods. This is only valid if 6107 ProcessState is CompletedOk. 6109 Recovery is not possible. 6111 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 6112 the delivery for some reason. This code is only valid 6113 in a Status Component contained in a Cancel Block or 6114 an Inquiry Response Block. 6116 Recovery is not possible. 6118 DelivCancelled Delivery Cancelled. The Delivery Handler declines to 6119 complete the Delivery for some reason and cancels the 6120 transaction. This code is only valid in a Status 6121 Component contained in a Cancel Block or an Inquiry 6122 Response Block. 6124 Recovery is not possible. 6126 Confirmed Confirmed. All goods have been delivered and 6127 confirmation of their delivery has been received. 6128 This is only valid if ProcessState is CompletedOk. 6130 Recovery is not possible. 6132 Unspecified Unspecified error. There is some unknown problem or 6133 error which does not fall into one of the other 6134 CompletionCodes. The StatusDesc attribute should 6135 provide the explanation of the cause. 6137 Recovery is not possible. 6139 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6140 response received. The document exchange has 6141 therefore "Timed Out". This code is only valid on a 6142 Transaction Inquiry. 6144 Recovery is possible if the last message from the 6145 other Trading Role is received again. 6147 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6148 response received. The document exchange has 6149 therefore "Timed Out". This code is only valid on a 6150 Transaction Inquiry. 6152 No recovery possible. 6154 [Note] Recovery from failed, or partially completed deliveries is not 6155 possible. The Consumer should use the Transaction Status 6156 Inquiry Transaction (see section 9.2.1) to determine up-to- 6157 date information on the current state. 6158 [Note End] 6160 7.16.4 Authentication Completion Codes 6162 The Completion Code is only required if the ProcessState attribute is set 6163 to Failed. The following table contains the valid values for the 6164 CompletionCode that may be used. It is recommended that the StatusDesc 6165 attribute is used to provide further explanation where appropriate. 6167 Value Description 6169 AutEeCancel Authenticatee Cancel. The organisation being 6170 authenticated declines to be authenticated for some 6171 reason. This could be, for example because the 6172 signature on an Authentication Request was invalid or 6173 the Authenticator was not known or acceptable to the 6174 Authenticatee. 6176 Recovery is not possible. 6178 AutOrCancel Authenticator Cancel. The organisation requesting 6179 authentication declines to validate the 6180 Authentication Response received for some reason and 6181 cancels the transaction. 6183 Recovery is not possible. 6185 NoAuthReq Authentication Request Not Available. The 6186 Authenticatee does not have the data that must be 6187 provided so that they may be successfully 6188 authenticated. For example a password may have been 6189 forgotten, the Authenticatee has not yet become a 6190 member, or a smart card token is not present. 6192 Recovery is not possible 6194 AuthFailed Authentication Failed. The Authenticator checked the 6195 Authentication Response but the authentication failed 6196 for some reason. For example a password may have been 6197 incorrect. 6199 Recovery may be possible by the Authenticatee re- 6200 sending a revised Authentication Response with 6201 corrected data. 6203 TradRolesIncon Trading Roles Inconsistent. The Trading Roles 6204 contained within the TradingRoleList attribute of the 6205 Trading Role Information Request Component (see 6206 section 7.4) are inconsistent with the Trading Role 6207 which the Authenticatee is taking in the IOTP 6208 Transaction or is able to take. Examples of 6209 inconsistencies include: 6210 o asking a PaymentHandler for DeliveryHandler 6211 information 6212 o asking a Consumer for Merchant information 6214 Recovery may be possible by the Authenticator re- 6215 sending a revised Authentication Request Block with 6216 corrected information. 6218 Unspecified Unspecified error. There is some unknown problem or 6219 error which does not fall into one of the other 6220 CompletionCodes. 6222 Recovery is not possible. 6224 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6225 response received. The document exchange has 6226 therefore "Timed Out". This code is only valid on a 6227 Transaction Inquiry. 6229 Recovery is possible if the last message from the 6230 other Trading Role is received again. 6232 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6233 response received. The document exchange has 6234 therefore "Timed Out". This code is only valid on a 6235 Transaction Inquiry. 6237 No recovery possible. 6239 7.16.5 Undefined Completion Codes 6241 The Completion Code is only required if the ProcessState attribute is set 6242 to Failed. The following table contains the valid values for the 6243 CompletionCode that may be used. It is recommended that the StatusDesc 6244 attribute is used to provide further explanation where appropriate. 6246 InMsgHardError The type of Request Block could not be identified or 6247 was inconsistent. Therefore no single Document 6248 Exchange could be identified. This will cause a Hard 6249 Error in the transaction 6251 7.16.6 Transaction Inquiry Completion Codes 6253 The Completion Code is only required if the ProcessState attribute is set 6254 to Failed. The following table contains the valid values for the 6255 CompletionCode that may be used. It is recommended that the StatusDesc 6256 attribute is used to provide further explanation where appropriate. 6258 UnAuthReq The recipient of the Transaction Status Request 6259 declines to respond to the request. 6261 7.17 Trading Role Data Component 6263 The Trading Role Data Component contains opaque data which is needs to be 6264 communicated between the Trading Roles involved in an IOTP Transaction. 6266 Trading Role Components identify: 6268 o the organisation that generated the component, and 6270 o the organisation that is to receive it. 6272 They are first generated and included in a "Response" Block, and then 6273 copied to the appropriate "Request" Block. For example a Payment Handler 6274 might need to inform a Delivery Handler that a credit card payment had 6275 been authorised but not captured. There may also be other information 6276 that the Payment Handler has generated where the format is privately 6277 agreed with the Delivery Handler which needs to be communicated. In 6278 another example a Merchant might need to provide a Payment Handler with 6279 some specific information about a Consumer so that consumer can acquire 6280 double loyalty points with the payment. 6282 Its definition is as follows. 6284 6285 6290 Attributes: 6292 ID An identifier which uniquely identifies the 6293 Trading Role Data Component within the IOTP 6294 Transaction. 6296 OrginatorElRef Contains an element reference to the Organisation 6297 Component of the Organisation that created the 6298 Trading Role Data Component and included it in a 6299 "Response" Block (e.g. an Offer Response or a 6300 Payment Response Block). 6302 DestinationElRefs Contains element references to the Organisation 6303 Components of the Organisations that are to 6304 receive the Trading Role Data Component in a 6305 "Request" Block (e.g. either a Payment Request or 6306 a Delivery Request Block). 6308 Content: 6310 PackagedContent This contains the data which is to be sent between 6311 the various Trading Roles as one or more 6312 PackagedContent elements see section 3.7. 6314 7.17.1 Who Receives a Trading Role Data Component 6316 The rules for deciding what to do with Trading Role Data Components are 6317 described below. 6319 o whenever a Trading Role Data Component is received in a "Response" 6320 block identify the Organisation Components of the Organisations that 6321 are to receive it as identified by the DestinationElRefs attribute. 6323 o whenever a "Request" Block is being sent, check to see if it is being 6324 sent to one of the Organisations identified by the DestinationElRefs 6325 attribute. If it is then include in the "Request" block: 6326 - the Trading Role Data Component as well as, 6327 - the Organisation Component of the Organisation identified by the 6328 OriginatorElRef attribute (if not already present) 6330 7.18 Inquiry Type Component 6332 The Inquiry Component contains the information which indicates the type 6333 of process that is being inquired upon. Its definition is as follows. 6335 6336 6342 Attributes: 6344 ID An identifier which uniquely identifies the 6345 Inquiry Type Component within the IOTP 6346 Transaction. 6348 Type Contains the type of inquiry. Valid values for 6349 Type are: 6350 o Offer. The inquiry is about the status of an 6351 offer and is addressed to the Merchant. 6352 o Payment. The inquiry is about the status of a 6353 payment and is addressed to the Payment 6354 Handler. 6355 o Delivery. The inquiry is about the status of a 6356 delivery and addressed to the Delivery Handler. 6358 ElRef Contains an Element Reference (see section 3.5) to 6359 the component to which this Inquiry Type Component 6360 applies. That is, 6361 o TPO Block when Type is Offer 6362 o Payment Component when Type is Payment 6363 o Delivery Component when Type is Delivery 6365 ProcessReference Optionally contains a reference to the process 6366 being inquired upon. It should be set if the 6367 information is available. For the definition of 6368 the values it may contain, see the 6369 ProcessReference attribute of the Status Component 6370 (see section 7.16). 6372 7.19 Signature Component 6374 [Note] Definitions of the XML structures for signatures and 6375 certificates are described in the document titled "Digital 6376 Signatures for the Internet Open Trading Protocol" by Kent 6377 Davidson and Yoshiaki Kawatsura published at the same time as 6378 this document - see [IOTPDSIG]. 6380 In the future it is anticipated that future versions of IOTP 6381 will adopt a whatever method for digitally signing XML becomes 6382 the standard. 6383 [Note End] 6385 Each Signature Component digitally signs one or more Blocks or Components 6386 including other Signature Components. 6388 The Signature Component: 6390 o contains digests of one or more Blocks or Components in one or more 6391 IOTP Messages within the same IOTP Transaction and places the result in 6392 a Digest Element 6394 o concatenates these Digest elements with other information on the type 6395 of signature, the originator and potential recipients of the signature 6396 and details of the signature algorithms being used and places them in a 6397 Manifest element, and 6399 o signs the Manifest element using the optional certificate identified in 6400 the Certificate element within the Signature Block placing the result 6401 in a Value element within a Signature Component 6403 Note that there may be multiple Value elements that contain signatures of 6404 a Manifest Element. 6406 A Signature Component can be one of four types either: 6408 o an Offer Response Signature, 6410 o a Payment Response Signature, 6412 o a Delivery Response Signature, or 6414 o an Authentication Response Signature. 6416 For a general explanation of signatures see section 6 Digital Signatures. 6418 7.19.1 IOTP usage of signature elements and attributes 6420 Definitions of the elements and attributes are contained in [IOTPDSIG]. 6421 The following contains additional information that describes how these 6422 elements and attributes are used by IOTP. 6424 SIGNATURE ELEMENT 6426 The ID attribute is mandatory. 6428 MANIFEST ELEMENT 6430 The optional LocatorHrefBase attribute contains text which should be 6431 concatenated before the text contained in the LocatorHREF attribute of 6432 all Digest elements within the Manifest. 6434 Its purpose is to reduce the size of LocatorHREF attribute values since 6435 the first part of the LocatorHREF attributes in the same signature are 6436 likely to be the same. 6438 Typically, within IOTP, it will contain all the characters in a 6439 LocatorHref attribute up to the sharp ("#") character (see immediately 6440 below). 6442 ALGORITHM AND PARAMETER ELEMENTS 6444 The algorithm element identifies the algorithms used in generating the 6445 signature. The type of the algorithm is defined by the value of the Type 6446 attribute which indicates if it is to be used as a Digest algorithm, a 6447 Signature algorithm or a Key Agreement algorithm. 6449 The following Digest algorithms must be implemented: 6451 o a [DOM-HASH] algorithm. This is identified by setting the Name 6452 attribute of the Algorithm element to "urn:ibm:dom-hash" 6454 o a [SHA1] algorithm. This is identified by setting the Name attribute of 6455 the Algorithm element to "urn:fips:sha1", and 6457 o a [MD5] algorithm. This is identified by setting the Name attribute of 6458 the Algorithm element to "urn:rsa:md5" 6460 o The following Signature algorithms must be implemented: 6462 o a [DSA] algorithm. This is identified by setting the Name attribute of 6463 the Algorithm element to "urn:us.gov:dsa" 6465 o a [HMAC] algorithm. This is identified by setting the Name attribute of 6466 the Algorithm element to "urn:ibm:hmac" 6468 It is recommended that the following Signature algorithm is also 6469 implemented: 6471 o a [RSA] algorithm. This is identified by setting the Name attribute of 6472 the Algorithm element to "urn:rsa:rsa" 6474 In addition other payment scheme specific algorithms may be used. In this 6475 case the value of the name attribute to use is specified in the payment 6476 scheme supplement for that algorithm. 6478 One algorithm may make use of other algorithms by use of the Parameter 6479 element, for example: 6481 6482 A2 6483 6484 6485 6486 6487 A1 6488 6490 DIGEST ELEMENT 6492 The LocatorHREF attribute identifies the IOTP element which is being 6493 digitally signed. Specifically it consists of: 6495 o the value of the IotpTransId attribute of the Transaction ID Component, 6496 followed by: 6498 o a sharp character, i.e. "#", followed by 6500 o an Element Reference (see section 3.5) to the element within the IOTP 6501 Transaction which is the subject of the digest. 6503 Before analysing the structure of the LocatorHREF attribute, it must be 6504 concatenated with the value of the LocatorHrefBase attribute of the 6505 Manifest element (see immediately above). 6507 ATTRIBUTE ELEMENT 6509 There must be one and only one Attribute Element that contains a Type 6510 attribute with a value of IOTP Signature Type and with content set to 6511 either: OfferResponse, PaymentResponse, DeliveryResponse, 6512 AuthenticationRequest, AuthenticationResponse, PingRequest or 6513 PingResponse; depending on the type of the signature. 6515 Values of the content of the Attribute element are controlled under the 6516 procedures defined in section 12 IANA Considerations which also allows 6517 user defined values to be defined. 6519 The Critical attribute must be set to true. 6521 ORIGINATORINFO ELEMENT 6523 The OriginatorRef attribute of the OriginatorInfo element must always be 6524 present and contain an Element Reference (see section 3.5) to the 6525 Organisation Component of the Organisation that generated the Signature 6526 Component. 6528 RECIPIENTINFO ELEMENT 6530 The RecipientRefs attribute contains a list of Element References (see 6531 section 3.5), that point to the Organisations that might need to validate 6532 the signature. For details see below. 6534 7.19.2 Offer Response Signature Component 6536 The Manifest Element of a signature which has a type of OfferResponse 6537 should contain Digest elements for the following Components: 6539 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6540 that contains the Offer Response Signature 6542 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6543 that contains the Offer Response Signature 6545 o from the TPO Block: 6546 - the Protocol Options Component 6547 - each of the Organisation Components 6548 - each of the Brand List Components 6550 o optionally, all the Brand Selection Components if they were sent to the 6551 Merchant in a TPO Selection Block 6553 o from the Offer Response Block: 6554 - the Order Component 6555 - each of the Payment Components 6556 - the Delivery Component 6557 - each of the Authentication Request Components 6558 - any Trading Role Data Components 6560 The Offer Response Signature should also contain Digest elements for the 6561 components that describe each of the organisations that may or will need 6562 to verify the signature. This involves: 6564 o if the Merchant has received a TPO Selection Block containing Brand 6565 Selection Components, then generate a Digest element for the Payment 6566 Handler identified by the Brand Selection Component and the Delivery 6567 Handler identified by the Delivery Component. See section 6.3.1 Check 6568 Request Block sent Correct Organisation for a description of how this 6569 can be done. 6571 o if the Merchant is not expecting to receive a TPO Selection Block then 6572 generate a Digest element for the Delivery Handler and all the Payment 6573 Handlers that are involved. 6575 7.19.3 Payment Receipt Signature Component 6577 The Manifest Element of the Payment Receipt Signature Component should 6578 contain Digest Elements for the following Components: 6580 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6581 that contains the Payment Receipt Signature 6583 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6584 that contains the Payment Receipt Signature 6586 o the Offer Response Signature Component 6588 o the Payment Receipt Component 6590 o the Payment Note Component 6592 o the Status Component 6594 o the Brand Selection Component. 6596 o any Trading Role Data Components 6598 7.19.4 Delivery Response Signature Component 6600 The Manifest Element of the Delivery Response Signature Component should 6601 contain Digest Elements for the following Components: 6603 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6604 that contains the Delivery Response Signature 6606 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6607 that contains the Delivery Response Signature 6609 o the Consumer Delivery Data component contained in the preceding 6610 Delivery Request (if any) 6612 o the Signature Components contained in the preceding Delivery Request 6613 (if any) 6615 o the Status Component 6617 o the Delivery Note Component 6619 7.19.5 Authentication Request Signature Component 6621 The Manifest Element of the Authentication Request Signature Component 6622 should contain Digest Elements for the following Components: 6624 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6625 that contains information that describes the IOTP Message and IOTP 6626 Transaction 6628 o the Transaction Id Component (see section 3.3.1) which globally 6629 uniquely identifies the IOTP Transaction 6631 o the following components of the TPO Block : 6632 - the Protocol Options Component 6633 - the Organisation Component 6635 o the following components of the Authentication Request Block: 6636 - the Authentication Request Component(s) (if present) 6637 - the Trading Role Information Request Component (if present) 6639 7.19.6 Authentication Response Signature Component 6641 The Manifest Element of the Authentication Response Signature Component 6642 should contain Digest Elements for the following Components: 6644 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6645 that contains information that describes the IOTP Message and IOTP 6646 Transaction 6648 o the Transaction Id Component (see section 3.3.1) which globally 6649 uniquely identifies the IOTP Transaction 6651 o the following components of the Authentication Request Block: 6652 - the Authentication Request Component that was used in the 6653 Authentication (if present) 6654 - the Trading Role Information Request Component (if present) 6656 o the Organisation Components contained in the Authentication Response 6657 Block 6659 7.19.7 Inquiry Request Signature Component 6661 If the Inquiry Request is being signed (see section 9.2.1) the Manifest 6662 Element of the Inquiry Request Signature Component should contain Digest 6663 elements of the Inquiry Type Component, and if present, the Payment 6664 Scheme Component. 6666 7.19.8 Inquiry Response Signature Component 6668 If the Inquiry Response is being signed (see section 9.2.1) the Manifest 6669 Element of the Inquiry Response Signature Component should contain Digest 6670 elements of the Trading Response Block and the Status Component. 6672 7.19.9 Ping Request Signature Component 6674 If the Ping Request is being singed (see section 9.2.2), the Manifest 6675 Element of the Ping Request Signature Component should contain Digest 6676 elements for all the Organisation Components. 6678 7.19.10 Ping Response Signature Component 6680 If the Ping Response is being singed (see section 9.2.2), the Manifest 6681 Element of the Ping Response Signature Component should contain Digest 6682 elements fir all the Organisation Components. 6684 7.20 Certificate Component 6686 [Note] Definitions of the XML structures for signatures and 6687 certificates are described in the paper "Digital Signatures 6688 for the Internet Open Trading Protocol", see [IOTPDSIG]. 6690 See note at the start of section 7.19 Signature Component for 6691 more details. 6692 [Note End] 6694 A Certificate Component contains a Digital Certificate. They are used 6695 only when required, for example, when asymmetric cryptography is being 6696 used and the recipient of the signature that needs to check has not 6697 already received the Public Key. 6699 The structure of a Certificate Component is as follows: 6701 6704 6708 6709 6713 6714 6718 6719 6722 7.20.1 IOTP usage of signature elements and attributes 6724 Detailed definitions of the above elements and attributes are contained 6725 in [IOTPDSIG]. The following contains additional information that 6726 describes how these elements and attributes are used by IOTP. 6728 CERTIFICATE COMPONENT 6730 The ID attribute is mandatory. 6732 VALUE ELEMENT 6734 The ID attribute is mandatory. 6736 7.21 Error Component 6738 The Error Component contains information about Technical Errors (see 6739 section 4.1) in an IOTP Message which has been received by one of the 6740 Trading Roles involved in the trade. 6742 For clarity two phrases are defined which are used in the description of 6743 an Error Component: 6745 o message in error. An IOTP message which contains or causes an error of 6746 some kind 6748 o message reporting the error. An IOTP message that contains an Error 6749 Component that describes the error found in a message in error. 6751 The definition of the Error Component is as follows. 6753 6754 6763 Attributes: 6765 ID An identifier which uniquely identifies the Error 6766 Component within the IOTP Transaction. 6768 xml:lang Defines the language used by attributes or child 6769 elements within this component, unless overridden 6770 by an xml:lang attribute on a child element. See 6771 section 3.8 Identifying Languages. 6773 ErrorCode Contains an error code which indicates the nature 6774 of the error in the message in error. Valid values 6775 for the ErrorCode are given in section 7.21.2 6776 Error Codes. 6778 ErrorDesc Contains a narrative description of the error in 6779 the language defined by xml:lang. The content of 6780 this attribute is defined by the vendor/developer 6781 of the software which generated the Error 6782 Component 6784 Severity Indicates the severity of the error. Valid values 6785 are: 6786 o Warning. This indicates that although there is 6787 a message in error the IOTP Transaction can 6788 still continue. 6789 o TransientError. This indicates that the error 6790 in the message in error may be recovered if the 6791 message in error that is referred to by the 6792 ErrorLocation element is resent 6793 o HardError. This indicates that there is an 6794 unrecoverable error in the message in error and 6795 the IOTP Transaction must stop. 6797 MinRetrySecs This attribute should be present if Severity is 6798 set to TransientError. It is the minimum number of 6799 whole seconds which the IOTP aware application 6800 which received the message reporting the error 6801 should wait before re-sending the message in error 6802 identified by the ErrorLocation element. 6804 If Severity is not set to TransientError then the 6805 value of this attribute is ignored. 6807 SwVendorErrorRef This attribute is a reference whose value is set 6808 by the vendor/developer of the software which 6809 generated the Error Component. It should contain 6810 data which enables the vendor to identify the 6811 precise location in their software and the set of 6812 circumstances which caused the software to 6813 generate a message reporting the error. See also 6814 the SoftwareId attribute of the Message Id element 6815 in the Transaction Reference Block (section 3.3). 6817 Content: 6819 ErrorLocation This identifies the IOTP Transaction Id of the 6820 message in error and, where possible, the element 6821 and attribute in the message in error that caused 6822 the Error Component to be generated. 6824 If the Severity of the error is not 6825 TransientError, more than one ErrorLocation may be 6826 specified as appropriate depending on the nature 6827 of the error (see section 7.21.2 Error Codes) and 6828 at the discretion of the vendor/developer of the 6829 IOTP Aware Application. 6831 PackagedContent This contains additional data which can be used to 6832 understand the error. Its content may vary as 6833 appropriate depending on the nature of the error 6834 (see section 7.21.2 Error Codes) and at the 6835 discretion of the vendor/developer of the IOTP 6836 Aware Application. For a definition of 6837 PackagedContent see section 3.7. 6839 7.21.1 Error Processing Guidelines 6841 If there is more than one Error Component in a message reporting the 6842 error, carry out the actions appropriate for the Error Component with the 6843 highest severity. In this context, HardError has a higher severity than 6844 TransientError, which has a higher severity than Warning. 6846 7.21.1.1 Severity - Warning 6848 If an IOTP aware application is generating a message reporting the error 6849 with an Error Component where the Severity attribute is set to Warning, 6850 then if the message reporting the error does not contain another Error 6851 Component with a severity higher than Warning, the IOTP Message must also 6852 include the Trading Blocks and Trading Components that would have been 6853 included if no error was being reported. 6855 If a message reporting the error is received with an Error Component 6856 where Severity is set to Warning, then: 6858 o it is recommended that information about the error is either logged, or 6859 otherwise reported to the user, 6861 o the implementer of the IOTP aware application must either, at their or 6862 the user's discretion: 6863 - continue the IOTP transaction as normal, or 6864 - fail the IOTP transaction by generating a message reporting the error 6865 with an Error Component with Severity set to HardError (see section 6866 7.21.1.3). 6868 If the intention is to continue the IOTP transaction then, if there are 6869 no other Error Components with a higher severity, check that the 6870 necessary Trading Blocks and Trading Components for normal processing of 6871 the transaction to continue are present. If they are not then generate a 6872 message reporting the error with an Error Component with Severity set to 6873 HardError. 6875 7.21.1.2 Severity - Transient Error 6877 If an IOTP Aware Application is generating a message reporting the error 6878 with an Error Component where the Severity attribute is set to 6879 TransientError, then there should be only one Error Component in the 6880 message reporting the error. In addition, the MinRetrySecs attribute 6881 should be present. 6883 If a message reporting the error is received with an Error Component 6884 where Severity is set to TransientError then: 6886 o if the MinRetrySecs attribute is present and a valid number, then use 6887 the MinRetrySecs value given. Otherwise if MinRetrySecs is missing or 6888 is invalid, then: 6889 - generate a message reporting the error containing an Error Component 6890 with a Severity of Warning and send it on the next IOTP message (if 6891 any) to be sent to the Trading Role which sent the message reporting 6892 the error with the invalid MinRetrySecs, and 6893 - use a value for MinRetrySecs which is set by the vendor/developer of 6894 the IOTP Aware Application. 6896 o check that only one ErrorLocation element is contained within the Error 6897 Component and that it refers to an IOTP Message which was sent by the 6898 recipient of the Error Component with a Severity of TransientError. If 6899 more than one ErrorLocation is present then generate a message 6900 reporting the error with a Severity of HardError. 6902 7.21.1.3 Severity - Hard Error 6904 If an IOTP Aware Application is generating a message reporting the error 6905 with an Error Component where the Severity attribute set to HardError, 6906 then there should be only one Error Component in the message reporting 6907 the error. 6909 If a message reporting the error is received with an Error Component 6910 where Severity is set to HardError then terminate the IOTP Transaction. 6912 7.21.2 Error Codes 6914 The following table contains the valid values for the ErrorCode attribute 6915 of the Error Component. The first sentence of the description contains 6916 the text that should be used to describe the error when displayed or 6917 otherwise reported. Individual implementations may translate this into 6918 alternative languages at their discretion. 6920 An Error Code must not be more that 14 characters long. 6922 Value Description 6924 Reserved Reserved. This error is reserved by the 6925 vendor/developer of the software. Contact the 6926 vendor/developer of the software for more information 6927 See the SoftwareId attribute of the Message Id 6928 element in the Transaction Reference Block(section 6929 3.3). 6931 XmlNotWellFrmd XML not well formed. The XML document is not well 6932 formed. See [XML] for the meaning of "well formed". 6933 Even if the XML is not well formed, it should still 6934 be scanned to find the Transaction Reference Block so 6935 that a properly formed Error Response may be 6936 generated. 6938 XmlNotValid XML not valid. The XML document is well formed but 6939 the document is not valid. See [XML] for the meaning 6940 of "valid". Specifically: 6941 o the XML document does not comply with the 6942 constraints defined in the IOTP document type 6943 declaration (DTD) (see section 13 Internet Open 6944 Trading Protocol Data Type Definition), and 6945 o the XML document does not comply with the 6946 constraints defined in the document type 6947 declaration of any additional [XML Namespace] that 6948 are declared. 6950 As for XML not well formed, attempts should still be 6951 made to extract the Transaction Reference Block so 6952 that a properly formed Error Response may be 6953 generated. 6955 ElUnexpected Unexpected element. Although the XML document is well 6956 formed and valid, an element is present that is not 6957 expected in the particular context according to the 6958 rules and constraints contained in this 6959 specification. 6961 ElNotSupp Element not supported. Although the document is well 6962 formed and valid, an element is present that: 6963 o is consistent with the rules and constraints 6964 contained in this specification, but 6966 Value Description 6967 o is not supported by the IOTP Aware Application 6968 which is processing the IOTP Message. 6970 ElMissing Element missing. Although the document is well formed 6971 and valid, an element is missing that should have 6972 been present if the rules and constraints contained 6973 in this specification are followed. 6975 In this case set the PackagedContent of the Error 6976 Component to the type of the missing element. 6978 ElContIllegal Element content illegal. Although the document is 6979 well formed and valid, the element Content contains 6980 values which do not conform to the rules and 6981 constraints contained in this specification. 6983 EncapProtErr Encapsulated protocol error. Although the document is 6984 well formed and valid, the PackagedContent of an 6985 element contains data from an encapsulated protocol 6986 which contains errors. 6988 AttUnexpected Unexpected attribute. Although the XML document is 6989 well formed and valid, the presence of the attribute 6990 is not expected in the particular context according 6991 to the rules and constraints contained in this 6992 specification. 6994 AttNotSupp Attribute not supported. Although the XML document is 6995 well formed and valid, and the presence of the 6996 attribute in an element is consistent with the rules 6997 and constraints contained in this specification, it 6998 is not supported by the IOTP Aware Application which 6999 is processing the IOTP Message. 7001 AttMissing Attribute missing. Although the document is well 7002 formed and valid, an attribute is missing that should 7003 have been present if the rules and constraints 7004 contained in this specification are followed. 7006 In this case set the PackagedContent of the Error 7007 Component to the type of the missing attribute. 7009 AttValIllegal Attribute value illegal. The attribute contains a 7010 value which does not conform to the rules and 7011 constraints contained in this specification. 7013 AttValNotRecog Attribute Value Not Recognised. The attribute 7014 contains a value which the IOTP Aware Application 7015 generating the message reporting the error could not 7016 recognise even though it should have been able to 7017 since the information had been provided in an earlier 7018 IOTP message. 7020 Value Description 7022 MsgTooLarge Message too large. The message is too large to be 7023 processed by the IOTP Aware Application. 7025 ElTooLarge Element too large. The element is too large to be 7026 processed by the IOTP Aware Application 7028 ValueTooSmall Value too small or early. The value of all or part of 7029 the Content of an element or an attribute, although 7030 valid, is too small. 7032 ValueTooLarge Value too large or in the future. The value of all or 7033 part of the Content of an element or an attribute, 7034 although valid, is too large. 7036 ElInconsistent Element Inconsistent. Although the document is well 7037 formed and valid, according to the rules and 7038 constraints contained in this specification: 7039 o the content of an element is inconsistent with the 7040 content of other elements or their attributes, or 7041 o the value of an attribute is inconsistent with the 7042 value of one or more other attributes. 7044 In this case create ErrorLocation elements which 7045 identify all the attributes or elements which are 7046 inconsistent. 7048 TransportError Transport Error. This error code is used to indicate 7049 that there is a problem with the Transport Mechanism 7050 which is preventing the message from being received. 7051 It is typically associated with a Transient Error. 7052 Explanation of the Transport Error is contained 7053 within the ErrorDesc attribute. The values which can 7054 be used inside ErrorDesc with a TransportError is 7055 specified in the IOTP supplement for the Transport 7056 mechanism. 7058 MsgBeingProc Message Being Processed. This error code is only used 7059 with a Severity of Transient Error. It indicates that 7060 the previous message, which may be an exchange 7061 message or a request message, is being processed and, 7062 if no response is received by the time indicated by 7063 the MinRetrySecs attribute, then the original message 7064 should be resent. 7066 SystemBusy SystemBusy. This error code is only used with a 7067 Severity of Transient Error. It indicates that the 7068 server that received a message is currently too busy 7069 to handle the message. If no response is received by 7070 the time indicated by the MinRetrySecs attribute, 7071 then the original message should be resent. 7073 Value Description 7075 [Note] If the server/system handling the 7076 Transport Mechanism (e.g. HTTP) is busy 7077 then a Transport Specific error message 7078 should be used instead of an IOTP Error 7079 message. This code should be used in 7080 association with IOTP servers/systems or 7081 other servers/systems to which the IOTP 7082 server is connected. 7083 [Note End] 7085 UnknownError Unknown Error. Indicates that the transaction cannot 7086 complete for some reason that is not covered 7087 explicitly by any of the other errors. The ErrorDesc 7088 attribute should be used to indicate the nature of 7089 the problem. 7091 This could be used to indicate, for example, an 7092 internal error in a backend server or client process 7093 of some kind. 7095 7.21.3 Error Location Element 7097 An Error Location Element identifies an element and optionally an 7098 attribute in the message in error which is associated with the error. It 7099 contains a reference to the IOTP Message, Trading Block, Trading 7100 Component, element and attribute, which is in error. 7102 7103 7111 Attributes: 7113 ElementType This is the name of the type of the element where 7114 the error is located. For example if the element 7115 was declared as |-Trading Block <--------Trading Block - an XML Element 7188 | | |-Trading Comp. within an IOTP Message that 7189 Trading | |-Trading Comp. contains a predefined set of 7190 Blocks | |-Trading Comp. Trading Components 7191 | | |-Trading Comp. 7192 | | |-Trading Comp. <-----Trading Components - XML Elements 7193 | | within a Trading Block that 7194 ------> |-Trading Block contain a predefined set of XML 7195 | |-Trading Comp. elements and attributes 7196 | |-Trading Comp. containing information required 7197 | |-Trading Comp. to support a Trading Exchange 7198 | |-Trading Comp. 7199 | |-Trading Comp. 7200 | 7201 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 7202 Figure 16 Trading Blocks 7204 Trading Blocks are defined as part of the definition of an IOTP Message 7205 (see section 3.1.1). The definition of an IOTP Message element is 7206 repeated here: 7208 7231 The remainder of this section defines the Trading Blocks in this version 7232 of IOTP. They are: 7234 o Authentication Request Block 7236 o Authentication Response Block 7238 o Authentication Status Block 7240 o Cancel Block 7242 o Delivery Request Block 7244 o Delivery Response Block 7246 o Error Block 7248 o Inquiry Request Block 7250 o Inquiry Response Block 7252 o Offer Response Block 7254 o Payment Exchange Block 7255 o Payment Request Block 7257 o Payment Response Block 7259 o Signature Block 7261 o Trading Protocol Options Block 7263 o TPO Selection Block 7265 The Transaction Reference Block is described in section 3.3. 7267 8.1 Trading Protocol Options Block 7269 The TPO Trading Block contains options which apply to the IOTP 7270 Transaction. The definition of a TPO Trading Block is as follows. 7272 7273 7276 Attributes: 7278 ID An identifier which uniquely identifies the 7279 Trading Protocol Options Block within the IOTP 7280 Transaction (see section 3.4 ID Attributes). 7282 Content: 7284 ProtocolOptions The Protocol Options Component (see section 7285 7.1)defines the options which apply to the whole 7286 IOTP Transaction (see section 9). 7288 BrandList This Brand List Component contains one or more 7289 payment brands and protocols which may be selected 7290 (see section 7.7). 7292 Org The Organisation Components (see section 7.6) 7293 identify the organisations and their roles in the 7294 IOTP Transaction. The roles and organisations 7295 which must be present will depend on the 7296 particular type of IOTP Transaction. See the 7297 definition of each transaction in section 9. 7298 Internet Open Trading Protocol Transactions. 7300 The TPO Block should contain: 7302 o the Protocol Options Component 7304 o the Organisation Component with the Trading Role of Merchant 7306 o the Organisation Component with the Trading Role of Consumer 7307 o optionally, the Organisation Component with the Trading Role of 7308 DeliverTo, if there is a Delivery included in the IOTP Transaction 7310 o Brand List Components for each payment in the IOTP Transaction 7312 o Organisation Components for all the Payment Handlers involved 7314 o optionally, Organisation Components for the Delivery Handler (if any) 7315 for the transaction 7317 o additional Organisation Components that the Merchant may want to 7318 include. For example 7319 - a Customer Care Provider 7320 - an Certificate Authority that offers Merchant "Credentials" or some 7321 other warranty on the goods or services being offered. 7323 8.2 TPO Selection Block 7325 The TPO Selection Block contains the results of selections made from the 7326 options contained in the Trading Protocol Options Block (see section 7327 8.1).The definition of a TPO Selection Block is as follows. 7329 7330 7333 Attributes: 7335 ID An identifier which uniquely identifies the TPO 7336 Selection Block within the IOTP Transaction. 7338 Content: 7340 BrandSelection This identifies the choice of payment brand and 7341 payment protocol to be used in a payment within 7342 the IOTP Transaction. There is one Brand Selection 7343 Component (see section 7.8) for each payment to be 7344 made in the IOTP Transaction. 7346 The TPO Selection Block should contain one Brand Selection Component for 7347 each Brand List in the TPO Block. 7349 8.3 Offer Response Block 7351 The Offer Response Block contains details of the goods, services, amount, 7352 delivery instructions or financial transaction which is to take place. 7353 Its definition is as follows. 7355 7358 7361 Attributes: 7363 ID An identifier which uniquely identifies the Offer 7364 Response Block within the IOTP Transaction. 7366 Content: 7368 Status Contains status information about the business 7369 success (see section 4.2) or failure of the 7370 generation of the Offer. Note that in an Offer 7371 Response Block, a ProcessState of NotYetStarted or 7372 InProgress are illegal values. 7374 Order The Order Component contains details about the 7375 goods, services or financial transaction which is 7376 taking place see section 7.5. 7378 The Order Component must be present unless the 7379 ProcessState attribute of the Status Component is 7380 set to Failed. 7382 Payment The Payment Components contain information about 7383 the payments which are to be made see section 7.9. 7385 Delivery The Delivery Component contains details of the 7386 delivery to be made (see section 7.13). 7388 TradingRoleData The Trading Role Data Component contains opaque 7389 data which is needs to be communicated between the 7390 Trading Roles involved in an IOTP Transaction (see 7391 section 7.17). 7393 The Offer Response Block should contain: 7395 o the Order Component for the IOTP Transaction 7397 o Payment Components for each Payment in the IOTP Transaction 7399 o the Delivery Component the IOTP Transaction requires (if any). 7401 8.4 Authentication Request Block 7403 The Authentication Request Block contains the data which is used by one 7404 Trading Role to obtain information about and optionally authenticate 7405 another Trading Role. 7407 In outline it contains: 7409 o information about how the authentication itself will be carried out, 7410 and/or 7412 o a request for additional information about the organisation being 7413 authenticated. 7415 Its definition is as follows. 7417 7418 7421 Attributes: 7423 ID An identifier which uniquely identifies the 7424 Authentication Request Block within the IOTP 7425 Transaction. 7427 Content: 7429 AuthReq Each Authentication Request (see section 7.2) 7430 component describes an alternative way in which 7431 the recipient of the Authentication Request may 7432 authenticate themselves by generating an 7433 Authentication Response Component (see section 7434 7.3). 7436 If one Authentication Request Component is 7437 present then that Authentication Request 7438 Component should be used. 7440 If more than one Authentication Request Component 7441 is present then the recipient should choose one 7442 of the components based on personal preference of 7443 the recipient or their software. 7445 If no Authentication Request Component is present 7446 it means that the Authentication Request Block is 7447 requesting the return of Organisation Components 7448 as specified in the Trading Role Information 7449 Request Component. 7451 TradingRoleInfoReq The Trading Role Information Request Component 7452 (see section 7.4) contains a list of Trading 7453 Roles about which information is being requested 7455 There must be at least one Component (either an Authentication Request or 7456 a Trading Role Information Request) within the Authentication Block 7457 otherwise it is an error. 7459 8.5 Authentication Response Block 7461 The Authentication Response Block contains the response which results 7462 from processing the Authentication Request Block. Its definition is as 7463 follows. 7465 7466 7469 Attributes: 7471 ID An identifier which uniquely identifies the 7472 Authentication Response Block within the IOTP 7473 Transaction. 7475 Content: 7477 AuthResp The optional Authentication Response Component 7478 which contains the results of processing the 7479 Authentication Request Component - see section 7480 7.3. 7482 Org Optional Organisation Components that contain 7483 information corresponding to the Trading Roles as 7484 requested by the TradingRoleList attribute of the 7485 Trading Role Information Request component. 7487 The components present in the Authentication Response Block must match 7488 the requirement of the corresponding Authentication Request Block 7489 otherwise it is an error. 7491 8.6 Authentication Status Block 7493 The Authentication Status Block indicates the success or failure of the 7494 validation of an Authentication Response Block by an Authenticator. Its 7495 definition is as follows. 7497 7498 7501 Attributes: 7503 ID An identifier which uniquely identifies the 7504 Authentication Status Block within the IOTP 7505 Transaction. 7507 Content: 7509 Status Contains status information about the business 7510 success (see section 4.2) or failure of the 7511 authentication 7513 8.7 Payment Request Block 7515 The Payment Request Block contains information which requests that a 7516 payment is started. Its definition is as follows. 7518 7520 7523 Attributes: 7525 ID An identifier which uniquely identifies the 7526 Payment Request Block within the IOTP Transaction. 7528 Content: 7530 Status Contains the Status Components (see section 7.13) 7531 of the responses of the steps (e.g. an Offer 7532 Response and/or a Payment Response) on which this 7533 step depends. It is used to indicate the success 7534 or failure of those steps. Payment should only 7535 occur if the previous steps were successful. 7537 BrandList The Brand List Component contains a list of one or 7538 more payment brands and protocols which may be 7539 selected (see section 7.7). 7541 BrandSelection This identifies the choice of payment brand, the 7542 payment protocol and the Payment Handler to be 7543 used in a payment within the IOTP Transaction. 7544 There is one Brand Selection Component (see 7545 section 7.8) for each payment to be made in the 7546 IOTP Transaction. 7548 Payment The Payment Components contain information about 7549 the payment which is being made see section 7.9. 7551 PaySchemeData The Payment Scheme Component contains payment 7552 scheme specific data see section 7.10. 7554 Org The Organisation Component contains details of 7555 organisations involved in the payment (see section 7556 7.6). The Organisations present are dependent on 7557 the IOTP Transaction and the data which is to be 7558 signed. See section 6 Digital Signatures for more 7559 details. 7561 TradingRoleData The Trading Role Data Component contains opaque 7562 data which is needs to be communicated between the 7563 Trading Roles involved in an IOTP Transaction (see 7564 section 7.17). 7566 The Payment Request Block should contain: 7568 o the Organisation Component with a Trading Role of Merchant 7570 o the Organisation Component with the Trading Role of Consumer 7572 o the Payment Component for the Payment 7574 o the Brand List Component for the Payment 7576 o the Brand Selection Component for the Brand List 7578 o the Organisation Component for the Payment Handler of the Payment 7580 o the Organisation Component (if any) for the Organisation which carried 7581 out the previous step, for example another Payment Handler 7583 o the Organisation Component for the organisation which is to carry out 7584 the next step, if any. This may be, for example, either a Delivery 7585 Handler or a Payment Handler. 7587 o the Organisation Components for any additional Organisations that the 7588 Merchant has included in the Offer Response Block 7590 o an Optional Payment Scheme Data Component, if required by the Payment 7591 Method as defined in the IOTP supplement for the payment method 7593 o any Trading Role Data Components that may be required (see section 7594 7.17.1). 7596 8.8 Payment Exchange Block 7598 The Payment Exchange Block contains payment scheme specific data which is 7599 exchanged between two of the roles in a trade. Its definition is as 7600 follows. 7602 7603 7606 Attributes: 7608 ID An identifier which uniquely identifies the 7609 Payment Exchange Block within the IOTP 7610 Transaction. 7612 Content: 7614 PaySchemeData This Trading Component contains payment scheme 7615 specific data see section 7.10 Payment Scheme 7616 Component. 7618 8.9 Payment Response Block 7620 This Payment Response Block contains a information about the Payment 7621 Status, an optional Payment Receipt, and an optional payment protocol 7622 message. Its definition is as follows. 7624 7626 7629 Attributes: 7631 ID An identifier which uniquely identifies the 7632 Payment Response Block within the IOTP 7633 Transaction. 7635 Content: 7637 Status Contains status information about the business 7638 success (see section 4.2) or failure of the 7639 payment. Note that in a Pay Response Block, a 7640 ProcessState of NotYetStarted or InProgress are 7641 illegal values. 7643 PayReceipt Contains payment scheme specific data which can be 7644 used to verify the payment occurred. See section 7645 7.11 Payment Receipt Component. It must be present 7646 if the ProcessState attribute of the Status 7647 Component is set to CompletedOk. PayReceipt is 7648 optional for other values as specified by the 7649 appropriate Payment Scheme supplement. 7651 PaySchemeData Contains payment scheme specific data see section, 7652 for example a payment protocol message. See 7.10 7653 Payment Scheme Component. 7655 PaymentNote Contains additional, non payment related, 7656 information which the Payment Handler wants to 7657 provide to the Consumer. For example, if a 7658 withdrawal or deposit were being made then it 7659 could contain information on the remaining balance 7660 on the account after the transfer was complete. 7661 See section 7.12 Payment Note Component. 7663 TradingRoleData The Trading Role Data Component contains opaque 7664 data which is needs to be communicated between the 7665 Trading Roles involved in an IOTP Transaction (see 7666 section 7.17). 7668 8.10 Delivery Request Block 7670 The Delivery Request Block contains details of the goods or services 7671 which are to be delivered together with a signature which can be used to 7672 check that delivery is authorised. Its definition is as follows. 7674 7676 7679 Attributes: 7681 ID An identifier which uniquely identifies the 7682 Delivery Request Block within the IOTP 7683 Transaction. 7685 Content: 7687 Status Contains the Status Components (see section 7688 7.13) of the responses of the steps (e.g. a 7689 Payment Response) on which this step is 7690 dependent. It is used to indicate the success 7691 or failure of those steps. Delivery should only 7692 occur if the previous steps were successful. 7694 Order The Order Component contains details about the 7695 goods, services or financial transaction which 7696 is taking place see section 7.5. 7698 The Organisation Components (see section 7.6) 7699 identify the organisations and their roles in 7700 Org the IOTP Transaction. The roles and 7701 organisations which must be present will depend 7702 on the particular type of IOTP Transaction. See 7703 the definition of each transaction in section 7704 9. Internet Open Trading Protocol Transactions. 7706 Delivery The Delivery Component contains details of the 7707 delivery to be made (see section 7.13). 7709 ConsumerDeliveryData Optional. Contains an identifier specified by 7710 the Consumer which, if returned by the Delivery 7711 Handler will enable the Consumer to identify 7712 which Delivery is being referred to. 7714 TradingRoleData The Trading Role Data Component contains opaque 7715 data which is needs to be communicated between 7716 the Trading Roles involved in an IOTP 7717 Transaction (see section 7.17). 7719 The Delivery Request Block contains: 7721 o the Organisation Component with a Trading Role of Merchant 7722 o the Organisation Component for the Consumer and DeliverTo Trading Roles 7724 o the Delivery Component for the Delivery 7726 o the Organisation Component for the Delivery Handler. Specifically the 7727 Organisation Component identified by the ActionOrgRef attribute on the 7728 Delivery Component 7730 o the Organisation Component (if any) for the Organisation which carried 7731 out the previous step, for example a Payment Handler 7733 o the Organisation Components for any additional Organisations that the 7734 Merchant has included in the Offer Response Block 7736 o any Trading Role Data Components that may be required (see section 7737 7.17.1). 7739 8.11 Delivery Response Block 7741 The Delivery Response Block contains a Delivery Note containing details 7742 on how the goods will be delivered. Its definition is as follows. Note 7743 that in a Delivery Response Block a Delivery Status Element with a 7744 DeliveryStatusCode of NotYetStarted or InProgress is invalid. 7746 7747 7750 Attributes: 7752 ID An identifier which uniquely identifies the 7753 Delivery Response Block within the IOTP 7754 Transaction. 7756 Content: 7758 Status Contains status information about the business 7759 success (see section 4.2) or failure of the 7760 delivery. Note that in a Delivery Response Block, 7761 a ProcessState of NotYetStarted or InProgress are 7762 illegal values. 7764 DeliveryNote The Delivery Note Component contains details about 7765 how the goods or services will be delivered (see 7766 section 7.15). 7768 8.12 Inquiry Request Trading Block 7770 The Inquiry Request Trading Block contains an Inquiry Type Component and 7771 an optional Payment Scheme Component to contain payment scheme specific 7772 inquiry messages. 7774 7775 7778 Attributes: 7780 ID An identifier which uniquely identifies the 7781 Inquiry Request Trading Block within the IOTP 7782 Transaction. 7784 Content: 7786 InquiryType Inquiry Type Component (see section 7.18) that 7787 contains the type of inquiry. 7789 PaySchemeData Payment Scheme Component (see section 7.10) that 7790 contains payment scheme specific inquiry messages 7791 for inquiries on payments. This is present when 7792 the Type attribute of Inquiry Type Component is 7793 Payment. 7795 8.13 Inquiry Response Trading Block 7797 The Inquiry Response Trading Block contains a Status Component and an 7798 optional Payment Scheme Component to contain payment scheme specific 7799 inquiry messages. Its purpose is to enquire on the current status of an 7800 IOTP transaction at a server. 7802 7803 7808 Attributes: 7810 ID An identifier which uniquely identifies the 7811 Inquiry Response Trading Block within the 7812 IOTP Transaction. 7814 LastReceivedIotpMsgRef Contains an Element Reference (see section 7815 3.5) to the Message Id Component (see section 7816 3.3.2) of the last message this server has 7817 received from the Consumer. If there is no 7818 previously received message from the Consumer 7819 in the pertinent transaction, this attribute 7820 should be contain the value Null. This 7821 attribute exists for debugging purposes. 7823 LastSentIotpMsgRef Contains an Element Reference (see section 7824 3.5) to the Message Id Component (see section 7825 3.3.2) of the last message this server has 7826 sent to the Consumer. If there is no 7827 previously sent message to the Consumer in 7828 the pertinent transaction, this attribute 7829 should contain the value Null. This attribute 7830 exists for debugging purposes. 7832 Content: 7834 Status Contains status information about the business 7835 success (see section 4.2) or failure of a certain 7836 trading exchange (i.e., Offer, Payment, or 7837 Delivery). 7839 PaySchemeData Payment Scheme Component (see section 7.10) that 7840 contains payment scheme specific inquiry messages 7841 for inquiries on payments. This is present when 7842 the Type attribute of StatusType attribute of the 7843 Status Component is set to Payment. 7845 8.14 Ping Request Block 7847 The Ping Request Block is used to determine if a Server is operating and 7848 whether or not cryptography is compatible. 7850 The definition of a Ping Request Block is as follows. 7852 7853 7856 Attributes: 7858 ID An identifier which uniquely identifies the Ping 7859 Request Trading Block within the IOTP Transaction. 7861 Content: 7863 Org Optional Organisation Components (see section 7864 7.6). 7866 If no Organisation Component is present then the 7867 Ping Request is anonymous and simply determines if 7868 the server is operating. 7870 However if Organisation Components are present, 7871 then it indicates that the sender of the Ping 7872 Request wants to verify that digital signatures 7873 can be handled. 7875 In this case the sender includes: 7876 o an Organisation Component that identifies 7877 itself specifying the Trading Role(s) it is 7878 taking in IOTP transactions (Merchant, Payment 7879 Handler, etc) 7880 o an Organisation Component that identifies the 7881 intended recipient of the message. 7883 These are then used to generate a signature over 7884 the Ping Response Block. 7886 8.15 Ping Response Block 7888 The Ping Response Trading Block provides the result of a Ping Request. 7890 It contains an Organisation Component that identifies the sender of the 7891 Ping Response. 7893 If the Ping Request to which this block is a response contained 7894 Organisation Components, then it also contains those Organisation 7895 Components. 7897 7898 7905 Attributes: 7907 ID An identifier which uniquely identifies the Ping 7908 Request Trading Block within the IOTP 7909 Transaction. 7911 PingStatusCode Contains a code which shows the status of the 7912 sender software which processes IOTP messages. 7913 Valid values are: 7914 o Ok. Everything with the service is working 7915 normally, including the signature 7916 verification. 7917 o Busy. Things are working normally but there 7918 may be some delays. 7919 o Down. The server is not functioning fully but 7920 can still provide a Ping response. 7922 SigVerifyStatusCode Contains a code which shows the status of 7923 signature verification. This is present only 7924 when the message containing the Ping Request 7925 Block also contains a Signature Block. Valid 7926 values are: 7927 o Ok. The signature has successfully been 7928 verified and proved compatible. 7929 o NotSupported The receiver of this Ping 7930 Request Block does not support validation of 7931 signatures. 7932 o Fail. Signature verification failed. 7934 Xml:lang Defines the language used in PingStatusDesc. 7935 This is present when PingStatusDesc is present. 7937 PingStatusDesc Contains a short description of the status of 7938 the server which sends this Ping Response Block. 7939 Servers, if their designers want, can use this 7940 attribute to send more refined status 7941 information than PingStatusCode which can be 7942 used for debugging purposes, for example. 7944 Content: 7946 Org These are Organisation Components (see section 7947 7.6). 7949 The Organisation Components of the sender of the 7950 Ping Response is always included in addition to 7951 the Organisation Components sent in the Ping 7952 Request. 7954 [Note] Ping Status Code values do not include a value such as Fail, 7955 since, when the software receiving the Ping Request message is 7956 not working at all, no Ping Response message will be sent 7957 back. 7958 [Note End] 7960 8.16 Signature Block 7962 The Signature Block contains one or more Signature Components and 7963 associated Certificates (if required) which sign data associated with the 7964 IOTP Transaction. For a general discussion and introduction to how IOTP 7965 uses signatures, see section 6 Digital Signatures. The definition of the 7966 Signature Component and certificates is contained in the paper "Digital 7967 Signatures for the Internet Open Trading Protocol", see [IOTPDSIG]. 7968 Descriptions of how these are used by IOTP is contained in sections 7.19 7969 and 7.20. 7971 The definition of a Signature Block is as follows: 7973 7974 7977 Attributes: 7979 ID An identifier which uniquely identifies the 7980 Signature Block within the IOTP Transaction. 7982 Content: 7984 Signature A Signature Component. See section 7.19. 7986 Certificate A Certificate Component. See section 7.20. 7988 The contents of a Signature Block depends on the Trading Block that is 7989 contained in the same IOTP Message as the Signature Block. 7991 8.16.1 Signature Block with Offer Response 7993 A Signature Block which is in the same message as an Offer Response Block 7994 contains just an Offer Response Signature Component (see section 7.19.2). 7996 8.16.2 Signature Block with Payment Request 7998 A Signature Block which is in the same message as a Payment Request Block 7999 contains: 8001 o an Offer Response Signature Component (see section 7.19.2), and 8003 o if the Payment is dependent on an earlier step (as indicated by the 8004 StartAfter attribute on the Payment Component), then the Payment 8005 Receipt Signature Component (see section 7.19.3) generated by the 8006 previous step 8008 8.16.3 Signature Block with Payment Response 8010 A Signature Block which is in the same message as a Payment Response 8011 Block contains just a Payment Receipt Signature Component (see section 8012 7.19.3) generated by the step. 8014 8.16.4 Signature Block with Delivery Request 8016 A Signature Block which is in the same message as a Delivery Request 8017 Block contains: 8019 o an Offer Response Signature Component (see section 7.19.2), and 8021 o the Payment Receipt Signature Component (see section 7.19.3) generated 8022 by the previous step. 8024 8.16.5 Signature Block with Delivery Response 8026 A Signature Block which is in the same message as a Delivery Response 8027 Block contains just a Delivery Response Signature component (see section 8028 7.19.4) generated by the step. 8030 8.17 Error Block 8032 The Error Trading Block contains one or more Error Components (see 8033 section 7.21) which contain information about Technical Errors (see 8034 section 4.1) in an IOTP Message which has been received by one of the 8035 Trading Roles involved in the trade. 8037 For clarity two phrases are defined which are used in the description of 8038 an Error Trading Block: 8040 o message in error. An IOTP message which contains or causes an error of 8041 some kind 8043 o message reporting the error. An IOTP message that contains an Error 8044 Trading Block that describes the error found in a message in error. 8046 An Error Trading Block may be contained in any message reporting the 8047 error. The action which then follows depends on the severity of the 8048 error. See the definition of an Error Component, for an explanation of 8049 the different types of severity and the actions which can then occur. 8051 [Note] Although, an Error Trading Block can report multiple different 8052 errors using multiple Error Components, there is no obligation 8053 on a developer of an IOTP Aware Application to do so. 8054 [Note End] 8056 The structure of an Error Trading Block is as follows. 8058 8059 8062 Attributes: 8064 ID An identifier which uniquely identifies the Error 8065 Trading Block within the IOTP Transaction. 8067 Content: 8069 ErrorComp An Error Components (see section 7.21) that 8070 contains information about an individual Technical 8071 Error. 8073 PaySchemeData An optional Payment Scheme Component (see section 8074 7.10) which contains a Payment Scheme Message. See 8075 the appropriate payment scheme supplement to 8076 determine whether or not this component needs to 8077 be present and for the definition of what it must 8078 contain. 8080 8.18 Cancel Block 8082 The Cancel Block is used by one Trading Role to inform any other that a 8083 transaction has been cancelled. Example usage includes: 8085 o a Consumer Role informing a non-Consumer role that it no longer plans 8086 to continue with the transaction. This will allow the server to close 8087 down the transaction tidily without a waiting for a time-out to occur 8089 o a non-Consumer Role to inform a Consumer role that the Transaction is 8090 being stopped. In this case, the Consumer is then unlikely to re-send 8091 the previous message that was sent in the mistaken understanding that 8092 the original was not received. 8094 Its definition is as follows. 8096 8097 8100 Attributes: 8102 ID An identifier which uniquely identifies the Cancel 8103 Block within the IOTP Transaction. 8105 Content: 8107 Status Contains status information indicating that the 8108 IOTP transaction has been cancelled. 8110 9. Internet Open Trading Protocol Transactions 8112 The Baseline Internet Open Trading Protocol supports three types of 8113 transactions for different purposes. These are 8115 o an Authentication IOTP transaction which supports authentication of one 8116 party in a trade by another and/or requests information about another 8117 Trading Role 8119 o IOTP Transactions that involve one or more payments. Specifically: 8120 - Deposit 8121 - Purchase 8122 - Refund 8123 - Withdrawal, and 8124 - Value Exchange 8126 o IOTP Transactions designed to check the correct function of the IOTP 8127 infrastructure. Specifically: 8128 - Transaction Status Inquiry, and 8129 - Ping 8131 Although the Authentication IOTP Transaction can operate on its own, 8132 authentication can optionally precede any of the "payment" transactions. 8133 Therefore, the rest of this section is divided into two parts covering: 8135 o Authentication and Payment transactions (Authentication, Deposit, 8136 Purchase, Refund, Withdrawal and Value Exchange) 8138 o Infrastructure Transactions (Transaction Status Inquiry and Ping) that 8139 are designed to support inquiries on whether or not a transaction has 8140 succeeded or a Trading Role's servers are operating correctly, and 8142 9.1 Authentication and Payment Related IOTP Transactions 8144 The Authentication and Payment related IOTP Transactions consist of six 8145 Document Exchanges which are then combined in sequence to implement a 8146 specific transaction. 8148 Generally, there is a close, but not exact, correspondence between a 8149 Document Exchange and a Trading Exchange. The main difference is that 8150 some Document Exchanges implement part or all of two Trading Exchanges 8151 simultaneously in order to minimise the number of actual IOTP Messages 8152 which must be sent over the Internet. 8154 The six Document Exchanges are: 8156 o Authentication. This is a direct implementation of the Authentication 8157 Trading Exchange 8159 o Brand Dependent Offer. This is the Offer Trading Exchange combined with 8160 the Brand Selection part of the Payment Trading Exchange. Its purpose 8161 is to provide the Merchant with information on the Brand selected so 8162 that the content of the Offer Response may be adapted accordingly 8164 o Brand Independent Offer. This is also an Offer Trading Exchange. 8165 However, in this instance, the content of the Offer Response does 8166 depend on the Brand selected. 8168 o Payment. This is a direct implementation of the Payment part of a 8169 Payment Trading Exchange 8171 o Delivery. This is a direct implementation of the Delivery Exchange 8173 o Delivery with Payment. This is an implementation of combined Payment 8174 and Delivery Trading Exchanges 8176 These Document Exchanges are combined together in different sequences to 8177 implement each IOTP Transaction. The way in which they may be combined is 8178 illustrated by the diagram below. 8179 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8181 START ----------------------------------------------------- 8182 | v 8183 | ---------------- 8184 | | AUTHENTICATION | 8185 | ---------------- 8186 -------------------------------------- | | 8187 | | | | 8188 | -------------- | ------------- | 8189 v v v v | 8190 ------------------- ----------------- | 8191 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 8192 | OFFER | | OFFER | | 8193 ------------------- ----------------- | 8194 | | | | | 8195 | --------------- | | | 8196 | | | | | 8197 | -------------- | -- | | 8198 v v v v | 8199 --------- -------------- | 8200 | PAYMENT | | PAYMENT WITH | | 8201 | (first) | | DELIVERY | | 8202 --------- -------------- | 8203 | | | 8204 ----------------------------- | | 8205 v v | | | 8206 ---------- --------- | | | 8207 | DELIVERY | | PAYMENT | | | | 8208 | | | {second)| | | | 8209 ---------- --------- | | | 8210 | | | | v 8211 ----------------------------------------------> STOP 8213 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8215 Figure 17 Payment and Authentication Message Flow Combinations 8217 The combinations of Document Exchanges that are valid depend on the 8218 particular IOTP transaction. 8220 The remainder of this sub-section describes: 8222 o each Document Exchange in more detail including descriptions of the 8223 content of each Trading Block in the Document Exchanges, and 8225 o descriptions of how each IOTP Transaction uses the Document Exchanges 8226 to effect the desired result. 8228 [Note] The descriptions of the Document Exchanges which follow 8229 describe the ways in which various Business Errors (see 8230 section 4.2) are handled. No reference is made however to the 8231 handling of Technical Errors (see section 4.1) in any of the 8232 messages since these are handled the same way irrespective of 8233 the context in which the message is being sent. See section 4 8234 for more details. 8235 [Note End] 8237 9.1.1 Authentication Document Exchange 8239 The Authentication Document Exchange is a direct implementation of the 8240 Authentication Trading Exchange (see section 2.2.4). It involves: 8242 o an Authenticator - the organisation which is requesting the 8243 authentication, and 8245 o an Authenticatee - the organisation being authenticated. 8247 The authentication consists of: 8249 o an Authentication Request being sent by the Authenticator to the 8250 Authenticatee, 8252 o an Authentication Response being sent in return by the Authenticatee to 8253 the Authenticator which is then checked, and 8255 o an Authentication Status being sent by the Authenticator to the 8256 Authenticatee to provide an indication of the success or failure of the 8257 authentication. 8259 An Authentication Document Exchange also: 8261 o provides an Authenticatee with an Organisation Component which 8262 describes the Authenticator, and 8264 o optionally provides the Authenticator with Organisation Components 8265 which describe the Authenticatee. 8267 The Authentication Request may also be digitally signed which allows the 8268 Authenticatee to verify the credentials of the Authenticator. 8270 The IOTP Messages which are involved are illustrated by the diagram 8271 below. 8272 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8273 Organisation 1 8274 (Authenticatee) 8275 | Organisation 2 8276 | (Authenticator) 8277 STEP | | 8278 1. First organisation takes an action (for example by pressing a 8279 button on an HTML page) which requires that the organisation 8280 is authenticated 8282 1 --> 2 Authentication Need (outside scope of IOTP) 8284 2. The second organisation generates: an Authentication Request 8285 Block containing one or more Authentication Request 8286 Components and/or a Trading Role Information Request 8287 Component, then sends it to the first organisation 8289 1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block; 8290 Signature Block (optional); TPO Block; Auth Request Block 8292 3. IOTP aware application started. If a Signature Block is 8293 present, the first organisation may use this to check the 8294 credentials of the second organisation. If credentials are 8295 OK, the first organisation selects an Authentication Request 8296 to use (if present and more than one), then uses the 8297 authentication algorithm selected to generate an 8298 Authentication Response Block. If present, the Trading Role 8299 Information Request Component is used to generate 8300 Organisation Components. Finally a Signature Component is 8301 created if required and all components are then sent back to 8302 the second organisation for validation. 8304 1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature 8305 Block (optional) ; Auth Response Block 8307 4. The second organisation checks the Authentication Response 8308 against the data in the Authentication Request Block to check 8309 that the first organisation is who they appear to be, and 8310 sends an Authentication Status Block to the first 8311 Organisation to indicate the result then stops. 8313 1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature 8314 Block (optional); Auth Response Block 8316 5. The first organisation checks the authentication Status Block 8317 and optionally keeps information on the IOTP transaction for 8318 record keeping purposes and stops. 8320 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8322 Figure 18 Authentication Document Exchange 8324 9.1.1.1 Message Processing Guidelines 8326 On receiving a TPO & Authentication Request IOTP Message (see below), an 8327 Authenticatee may either: 8329 o generate and send an Authentication Response IOTP Message back to the 8330 Authenticator, or 8332 o indicate failure to comply with the Authentication Request by sending a 8333 Cancel Block back to the Authenticator containing a Status Component 8334 with a StatusType of Authentication a ProcessState of Failed and the 8335 CompletionCode (see section 7.16.4) set to either: AutEeCancel, 8336 NoAuthReq, TradRolesIncon or Unspecified. 8338 On receiving an Authentication Response IOTP Message (see below), an 8339 Authenticator should send in return, an Authentication Status IOTP 8340 Message (see below) containing a Status Block with a Status Component 8341 where the StatusType is set to Authentication, and: 8343 o the ProcessState attribute of the Status Component is set to 8344 CompletedOk which indicates a successful completion, or 8346 o the ProcessState attribute is set to Failed and the CompletionCode 8347 attribute is set to either: AutOrCancel, AuthFailed or Unspecified 8348 which indicates a failed authentication, 8350 On receiving an Authentication Status IOTP Message (see below), the 8351 Authenticatee should check the Status Component in the Status Block. If 8352 this indicates: 8354 o a successful authentication, then the Authenticatee should either: 8355 - continue with the next step in the IOTP Transaction of which the 8356 Authentication Document Exchange is part (if any), or 8357 - indicate a failure to continue with the rest of the IOTP Transaction, 8358 by sending back to the Authenticator a Cancel Block containing a 8359 Status Component with a StatusType of Authentication, a ProcessState 8360 of Failed and the CompletionCode (see section 7.16.4) set to 8361 AutEeCancel. 8363 o a failed authentication, then the failure should be reported to the 8364 Authenticatee and any further processing stopped. 8366 If the Authenticator receives an IOTP Message containing a Cancel block 8367 from a Consumer, then the Authenticatee may go to the CancelNetLocn 8368 specified on the Trading Role Element in the Organisation Component for 8369 the Authenticator contained in the Trading Protocol Options Block. 8371 9.1.1.2 TPO & Authentication Request IOTP Message 8373 Apart from a Transaction Reference Block (see section 3.3), this message 8374 consists of: 8376 o a Trading Protocol Options Block (see section 8.1) 8378 o an Authentication Request Block (see section 8.4), and 8380 o an optional Signature Block (see section 8.16). 8382 Each of these are described below. 8384 TRADING PROTOCOL OPTIONS BLOCK 8386 The Trading Protocol Options Block (see section 8.1) must contain the 8387 following Trading Components: 8389 o one Protocol Options Component (see Section 7.1) which defines the 8390 options which apply to the whole Authentication Document Exchange. 8392 o one Organisation Component (see section 7.6) which describes the 8393 Authenticator. The Trading Role on the Organisation Component should 8394 indicate the role which the Authenticator is taking in the Trade, for 8395 example a Merchant or a Consumer. 8397 AUTHENTICATION REQUEST BLOCK 8399 The Authentication Request Block (see section 8.4) must contain the 8400 following Trading Components: 8402 o one Authentication Request Component (see section 7.2), and 8404 SIGNATURE BLOCK (AUTHENTICATION REQUEST) 8406 If the Authentication Request is being digitally signed then a Signature 8407 Block must be included. It contains Digests of the following XML 8408 elements: 8410 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8411 that contains information that describes the IOTP Message and IOTP 8412 Transaction 8414 o the Transaction Id Component (see section 3.3.1) which globally 8415 uniquely identifies the IOTP Transaction 8417 o the following components of the TPO Block : 8418 - the Protocol Options Component 8419 - the Organisation Component 8421 o the following components of the Authentication Request Block: 8423 - the Authentication Request Component 8424 - the Trading Role Information Request Component 8426 9.1.1.3 Authentication Response IOTP Message 8428 Apart from a Transaction Reference Block (see section 3.3), this message 8429 consists of: 8431 o an Authentication Response Block (see section 8.5), and 8433 o an optional Signature Block (see section 8.16). 8435 Each of these are described below. 8437 AUTHENTICATION RESPONSE BLOCK 8439 The Authentication Response Block must contain the following Trading 8440 Component: 8442 o one Authentication Response Component (see section 7.3) 8444 o one Organisation Component for every Trading Role identified in the 8445 TradingRoleList attribute of the Trading Role Information Request 8446 Component contained in the Authentication Request Block. 8448 SIGNATURE BLOCK (AUTHENTICATION RESPONSE) 8450 If the Algorithm element (see section 12. IANA Considerations) within the 8451 Authentication Request Component contained in the Authentication Request 8452 Block indicates that the Authentication Response should consist of a 8453 digital signature then a Signature Block must be included in the same 8454 IOTP message that contains an Authentication Response Block. The 8455 Signature Component contains Digest Elements for the following XML 8456 elements: 8458 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8459 that contains information that describes the IOTP Message and IOTP 8460 Transaction 8462 o the Transaction Id Component (see section 3.3.1) which globally 8463 uniquely identifies the IOTP Transaction 8465 o the following components of the Authentication Request Block: 8466 - the Authentication Request Component 8467 - the Trading Role Information Request Component 8469 o the Organisation Components contained in the Authentication Response 8470 Block 8472 [Note] It should not be assumed that all trading roles can support 8473 the signing of data. Particularly it should not be assumed 8474 that Consumers support the signing of data. 8475 [Note End] 8477 9.1.1.4 Authentication Status IOTP Message 8479 Apart from a Transaction Reference Block (see section 3.3), this message 8480 consists of: 8482 o an Authentication Status Block (see section 8.5), and 8484 o an optional Signature Block (see section 8.16). 8486 Each of these are described below. 8488 AUTHENTICATION STATUS BLOCK 8490 The Authentication Status Block (see section 8.6) must contain the 8491 following Trading Components: 8493 o one Status Component (see section 7.16) with a ProcessState attribute 8494 set to CompletedOk. 8496 SIGNATURE BLOCK (AUTHENTICATION STATUS) 8498 If the Authentication Status Block is being digitally signed then a 8499 Signature Block must be included that contains a Signature Component with 8500 Digest elements for the following XML elements: 8502 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8503 that contains information that describes the IOTP Message and IOTP 8504 Transaction 8506 o the Transaction Id Component (see section 3.3.1) which globally 8507 uniquely identifies the IOTP Transaction 8509 o the following components of the Authentication Status Block: 8510 - the Status Component (see section 7.16). 8512 [Note] If the Authentication Document Exchange is followed by an 8513 Offer Document Exchange (see section 9.1.2) then the 8514 Authentication Status Block and the Signature Block 8515 (Authentication Status) may be combined with either: 8516 o a TPO IOTP Message (see section 9.1.2.3), or 8517 o a TPO and Offer Response IOTP Message (see section 9.1.2.6) 8518 [Note End] 8520 9.1.2 Offer Document Exchange 8522 The Offer Document Exchange occurs in two basic forms: 8524 o Brand Dependent Offer Exchange. Where the content of the offer, e.g. 8525 the order details, amount, delivery details, etc., are dependent on the 8526 payment brand and protocol selected by the consumer, and 8528 o Brand Independent Offer Exchange. Where the content of the offer is not 8529 dependent on the payment brand and protocol selected. 8531 Each of these types of Offer Document Exchange may be preceded by an 8532 Authentication Document Exchange (see section 9.1.1). 8534 9.1.2.1 Brand Dependent Offer Document Exchange 8536 In a Brand Dependent Offer Document Exchange the TPO Block and the Offer 8537 Response Block are sent separately by the Merchant to the Consumer, i.e.: 8539 o the Brand List Component is sent to the Consumer in a TPO Block, 8541 o the Consumer selects a Payment Brand, Payment Protocol and optionally a 8542 Currency and amount from the Brand List Component 8544 o the Consumer sends the selected brand, protocol and currency/amount 8545 back to the Merchant in a TPO Selection Block, and 8547 o the Merchant uses the information received to define the content of and 8548 then send the Offer Response Block to the Consumer. 8550 This is illustrated by the diagram below. 8551 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8552 Consumer 8553 | Merchant 8554 STEP | | 8555 1. Consumer decides to trade and sends to the Merchant 8556 information (e.g. using HTML) that enables the Merchant to 8557 create an offer, 8559 C --> M Offer information - outside scope of IOTP 8561 2. Merchant decides which payment brand protocols, currencies 8562 and amounts apply, places then in a Brand List Component 8563 inside a TPO Block and sends to Consumer 8565 C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block 8567 3. IOTP aware application started. Consumer selects the payment 8568 brand, payment protocol and currency/amount to use. Records 8569 selection in a Brand Selection Component and sends back to 8570 Merchant. 8572 C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection Block 8574 4. Merchant uses selected payment brand, payment protocol, 8575 currency/amount and the offer information to create an Offer 8576 Response Block containing details about the IOTP Transaction 8577 including price, etc. Optionally signs it and sends to the 8578 Consumer 8580 C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8581 (optional); Offer Response Block 8583 5. Consumer checks the Offer is OK, then combines components 8584 from the TPO Block, the TPO Selection Block and the Offer 8585 Response Block to create the next IOTP Message for the 8586 Transaction and sends it together with the Signature block if 8587 present to the required Trading Role 8589 CONTINUED ... 8591 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8593 Figure 19 Brand Dependent Offer Document Exchange 8595 Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by 8596 the absence of an Offer Response Block in the first IOTP Message. 8598 MESSAGE PROCESSING GUIDELINES 8600 On receiving a TPO IOTP Message (see below), the Consumer may either: 8602 o generate and send a TPO Selection IOTP Message back to the Merchant, or 8604 o indicate failure to continue with the IOTP Transaction by sending a 8605 Cancel Block back to the Merchant containing a Status Component with a 8606 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8607 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8609 On receiving a TPO Selection IOTP Message (see below) the Merchant may 8610 either: 8612 o generate and send an Offer Response IOTP Message back to the Consumer, 8613 or 8615 o indicate failure to continue with the IOTP Transaction by sending a 8616 Cancel Block back to the Consumer containing a Status Component with a 8617 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8618 (see section 7.16.4) set to either: MerchCancelled or Unspecified. 8620 On receiving an Offer Response IOTP Message (see below) the Consumer may 8621 either: 8623 o generate and send the next IOTP Message in the IOTP transaction and 8624 send it to the required Trading Role. This is dependent on the IOTP 8625 Transaction, or 8627 o indicate failure to continue with the IOTP Transaction by sending a 8628 Cancel Block back to the Consumer containing a Status Component with a 8629 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8630 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8632 If the Merchant receives an IOTP Message containing a Cancel block, then 8633 the Consumer is likely to go to the CancelNetLocn specified on the 8634 Trading Role Element in the Organisation Component for the Merchant. 8636 If the Consumer receives an IOTP Message containing a Cancel block, then 8637 the information contained in the IOTP Message should be reported to the 8638 Consumer but no further action taken. 8640 9.1.2.2 Brand Independent Offer Document Exchange 8642 In a Brand Independent Offer Document Exchange the TPO Block and the 8643 Offer Response Block are sent together by the Merchant to the Consumer, 8644 i.e. there is one IOTP Message that contains both a TPO Block, and an 8645 Offer Response Block. 8647 The message flow is illustrated by the diagram below: 8648 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8649 Consumer 8650 | Merchant 8651 STEP | | 8652 1. Consumer decides to trade and sends to the Merchant 8653 information (e.g. using HTML) that enables the Merchant to 8654 create an offer, 8656 C --> M Offer information - outside scope of IOTP 8658 2. Merchant decides which payment brand protocols, currencies 8659 and amounts apply, places then in a Brand List Component 8660 inside a TPO Block, creates an Offer Response containing 8661 details about the IOTP Transaction including price, etc., 8662 optionally signs it and sends to Consumer 8664 C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature 8665 Block; TPO Block; Offer Response Block 8667 3. IOTP aware application started. Consumer selects the payment 8668 brand, payment protocol and currency/amount to use. Records 8669 selection in a Brand Selection Component, checks offer is OK, 8670 combines the Brand Selection Component with information from 8671 the TPO Block and Offer Response Block to create the next 8672 IOTP Message for the Transaction and sends it together with 8673 the Signature Block if present to the required Trading Role. 8675 CONTINUED ... 8677 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8679 Figure 20 Brand Independent Offer Exchange 8681 Note that a Brand Independent Offer Document Exchange always occurs when 8682 only one payment brand, protocol and currency/amount is being offered to 8683 the Consumer by the Merchant. It is also likely to, but will not 8684 necessarily, occur when multiple brands are being offered, the Payment 8685 Handler is the same, and all brands use the same set of protocols. 8687 Note that the TPO Block and the Offer Response Block can be sent in 8688 separate IOTP messages (see Brand Dependent Offer Document Exchange) even 8689 if the Offer Response Block does not change. However this increases the 8690 number of messages in the transaction and is therefore likely to increase 8691 transaction response times. 8693 IOTP aware applications supporting the Consumer Trading Role must check 8694 for the existence of an Offer Response Block in the first IOTP Message to 8695 determine whether the Offer Document Exchange is brand dependent or not. 8697 MESSAGE PROCESSING GUIDELINES 8699 On receiving a TPO and Offer Response IOTP Message (see below), the 8700 Consumer may either: 8702 o generate and send the next IOTP Message in the IOTP transaction and 8703 send it to the required Trading Role. This is dependent on the IOTP 8704 Transaction, or 8706 o indicate failure to continue with the IOTP Transaction by sending a 8707 Cancel Block back to the Merchant containing a Status Component with a 8708 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8709 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 8711 If the Merchant receives an IOTP Message containing a Cancel block, then 8712 the Consumer is likely to go to the CancelNetLocn specified on the 8713 Trading Role Element in the Organisation Component for the Merchant. 8715 9.1.2.3 TPO IOTP Message 8717 The TPO IOTP Message is only used with a Brand Dependent Offer Document 8718 Exchange. Apart from a Transaction Reference Block (see section 3.3), 8719 this message consists of just a Trading Protocol Options Block (see 8720 section 8.1) which is described below. 8722 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8724 The Trading Protocol Options Block (see section 8.1) must contain the 8725 following Trading Components: 8727 o one Protocol Options Component which defines the options which apply to 8728 the whole IOTP Transaction. See Section 7.1. 8730 o one Brand List Component (see section 7.7) for each Payment in the IOTP 8731 Transaction that contain one or more payment brands and protocols which 8732 may be selected for use in each payment 8734 o Organisation Components (see section 7.6) with the following roles: 8735 - Merchant who is making the offer 8736 - Consumer who is carrying out the transaction 8737 - the PaymentHandler(s) for the payment. The "ID" of the Payment 8738 Handler Organisation Component is contained within the PhOrgRef 8739 attribute of the Payment Component 8741 If the IOTP Transaction includes a Delivery then the TPO Block must also 8742 contain: 8744 o Organisation Components with the following roles: 8745 - DeliveryHandler who will be delivering the goods or services 8746 - DelivTo i.e. the person or organisation which is to take delivery 8748 AUTHENTICATION STATUS AND SIGNATURE BLOCKS 8750 If the Offer Document Exchange was preceded by an Authentication Document 8751 Exchange, then the TPO IOTP Message may also contain: 8753 o an Authentication Status Block (see section 8.6), and 8755 o an optional Signature Block (Authentication Status) Signature Block 8757 See section 9.1.1.4 Authentication Status IOTP Message for more details. 8759 9.1.2.4 TPO Selection IOTP Message 8761 The TPO Selection IOTP Message is only used with a Brand Dependent Offer 8762 Document Exchange. Apart from a Transaction Reference Block (see section 8763 3.3), this message consists of just a TPO Selection Block (see section 8764 8.1) which is described below. 8766 TPO SELECTION BLOCK 8768 The TPO Selection Block (see section 8.2) contains: 8770 o one Brand Selection Component (see section 7.8) for use in a later 8771 Payment Exchange. It contains the results of the consumer selecting a 8772 Payment Brand, Payment Protocol and currency/amount from the list 8773 provided in the Brand List Component. 8775 9.1.2.5 Offer Response IOTP Message 8777 The Offer Response IOTP Message is only used with a Brand Dependent Offer 8778 Document Exchange. Apart from a Transaction Reference Block (see section 8779 3.3), this message consists of: 8781 o an Offer Response Block (see section 8.1) and 8783 o an optional Signature Block (see section 8.16). 8785 OFFER RESPONSE BLOCK 8787 The Offer Response Block (see section 8.3) contains the following 8788 components: 8790 o one Status Component (see section 7.16) which indicates the status of 8791 the Offer Response. The ProcessState attribute should be set to 8792 CompletedOk 8794 o one Order Component (see section 7.5) which contains details about the 8795 goods and services which are being purchased or the financial 8796 transaction which is taking place 8798 o one or more Payment Component(s) (see section 7.9) for each payment 8799 which is to be made 8801 o zero or one Delivery Components (see section 7.13) containing details 8802 of the delivery to be made if the IOTP Transaction includes a delivery 8804 o zero or more Trading Role Data Components (see section 7.17) if 8805 required by the Merchant. 8807 SIGNATURE BLOCK (OFFER RESPONSE) 8809 If the Authentication Status Block is being digitally signed then a 8810 Signature Block must be included that contains a Signature Component (see 8811 section 7.19) with Digest Elements for the following XML elements: 8813 If the Offer Response is being digitally signed then a Signature Block 8814 must be included that contains a Signature Component (see section 7.19) 8815 with Digest Elements for the following XML elements: 8817 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8818 that contains information that describes the IOTP Message and IOTP 8819 Transaction 8821 o the Transaction Id Component (see section 3.3.1) which globally 8822 uniquely identifies the IOTP Transaction 8824 o the following components of the TPO Block : 8825 - the Protocol Options Component, and 8826 - the Brand List Component 8827 - all the Organisation Components present 8829 o the following components of the Offer Response Block: 8830 - the Order Component 8831 - all the Payment Components present 8832 - the Delivery Component if present 8833 - any Trading Role Data Components present 8835 9.1.2.6 TPO and Offer Response IOTP Message 8837 The TPO and Offer Response IOTP Message is only used with a Brand 8838 Independent Offer Document Exchange. Apart from a Transaction Reference 8839 Block (see section 3.3), this message consists of: 8841 o a Trading Protocol Options Block (see section 8.1) 8843 o an Offer Response Block (see section 8.1) and 8845 o an optional Signature Block (see section 8.16). 8847 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8849 This is the same as the Trading Protocol Options Block described in TPO 8850 IOTP Message (see section 9.1.2.3). 8852 OFFER RESPONSE BLOCK 8854 This the same as the Offer Response Block in the Offer Response IOTP 8855 Message (see section 9.1.2.5). 8857 AUTHENTICATION STATUS 8859 If the Offer Document Exchange was preceded by an Authentication Document 8860 Exchange, then the TPO and Offer Response IOTP Message may also contain 8861 an Authentication Status Block (see section 8.6). 8863 SIGNATURE BLOCK 8865 This is the same as the Signature Block in the Offer Response IOTP 8866 Message (see section 9.1.2.5) with the addition that: 8868 o if the Offer Document Exchange is Brand Dependent then the Signature 8869 Component in the Signature Block additionally contains a Digest Element 8870 for the Brand Selection Component contained in the TPO Selection Block 8872 o if the Offer Document Exchange was preceded by an Authentication 8873 Document Exchange then the Signature Component in the Signature Block 8874 additionally contains a Digest Element for the Authentication Status 8875 Block. 8877 9.1.3 Payment Document Exchange 8879 The Payment Document Exchange is a direct implementation of the last part 8880 of a Payment Trading Exchange (see section 2.2.2) after the Brand has 8881 been selected by the Consumer. A Payment Exchange consists of: 8883 o the Consumer requesting that a payment starts by generating Payment 8884 Request IOTP Message using information from previous IOTP Messages in 8885 the Transaction and then sending it to the Payment Handler 8887 o the Payment Handler and the Consumer then swapping Payment Exchange 8888 IOTP Messages encapsulating payment protocol messages until the payment 8889 is complete, and finally 8891 o the Payment Handler sending a Payment Response IOTP Message to the 8892 Consumer containing a receipt for the payment. 8894 The IOTP Messages which are involved are illustrated by the diagram 8895 below. 8896 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8897 Consumer 8898 | Payment 8899 | Handler 8900 STEP | | 8901 1. Consumer generates Pay Request Block encapsulating a payment 8902 protocol message if required and sends to Payment Handler 8903 with the Signature Block if present 8905 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block 8906 (optional); Pay Request Block 8908 2. Payment Handler processes Pay Request Block, checks optional 8909 signature and starts exchanging payment protocol messages 8910 encapsulated in a Pay Exchange Block, with the Consumer 8912 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 8913 Block 8915 3. Consumer and Payment Handler keep on exchanging Payment 8916 Exchange blocks until eventually payment protocol messages 8917 finish so Payment Handler creates a Pay Receipt Component 8918 inside a Pay Response Block, and an optional Signature 8919 Component inside a Signature Block, sends them to the 8920 Consumer and stops. 8922 C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8923 (optional); Pay Response Block 8925 4. Consumer checks Payment Response is OK. Optionally keeps 8926 information on IOTP Transaction for record keeping purposes 8927 and either stops or creates the next IOTP message for the 8928 Transaction and sends it together with the Signature Block, 8929 if present, to the required Trading Role 8931 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8933 Figure 21 Payment Document Exchange 8935 9.1.3.1 Message Processing Guidelines 8937 On receiving a Payment Request IOTP Message, the Payment Handler should 8938 check that they are authorised to carry out the Payment (see section 6 8939 Digital Signatures). They may then either: 8941 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8942 if more payment protocol messages need to be exchanged, or 8944 o generate and send a Payment Response IOTP Message if the exchange of 8945 payment protocol messages is complete, or 8947 o indicate failure to continue with the Payment by sending a Cancel Block 8948 back to the Consumer containing a Status Component with a StatusType of 8949 Payment, a ProcessState of Failed and the CompletionCode (see section 8950 7.16.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, 8951 AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument 8952 or Unspecified. 8954 On receiving a Payment Exchange IOTP Message, the Consumer may either: 8956 o generate and send a Payment Exchange Message back to the Payment 8957 Handler or 8959 o indicate failure to continue with the Payment by sending a Cancel Block 8960 back to the Payment Handler containing a Status Component with a 8961 StatusType of Payment, a ProcessState of Failed and the CompletionCode 8962 (see section 7.16.2) set to either: ConsCancelled or Unspecified. 8964 On receiving a Payment Exchange IOTP Message, the Payment Handler may 8965 either: 8967 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8968 if more payment protocol messages need to be exchanged, or 8970 o generate and send a Payment Response IOTP Message if the exchange of 8971 payment protocol messages is complete, or 8973 o indicate failure to continue with the Payment by sending a Cancel Block 8974 back to the Consumer containing a Status Component with a StatusType of 8975 Payment, a ProcessState of Failed and the CompletionCode (see section 8976 7.16.2) set to either: PaymtCancelled or Unspecified. 8978 On receiving a Payment Response IOTP Message, the Consumer may either: 8980 o generate and send the next IOTP Message in the IOTP transaction and 8981 send it to the required Trading Role. This is dependent on the IOTP 8982 Transaction, 8984 o stop, since the IOTP Transaction has ended, or 8986 o indicate failure to continue with the IOTP Transaction by sending a 8987 Cancel Block back to the Merchant containing a Status Component with a 8988 StatusType of Payment, a ProcessState of Failed and the CompletionCode 8989 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 8991 If the Consumer receives an IOTP Message containing a Cancel block, then 8992 the information contained in the IOTP Message should be reported to the 8993 Consumer but no further action taken. 8995 If the Payment Handler receives an IOTP Message containing a Cancel 8996 block, then the Consumer is likely to go to the CancelNetLocn specified 8997 on the Trading Role Element in the Organisation Component for the Payment 8998 Handler from which any further action may take place. 9000 If the Merchant receives an IOTP Message containing a Cancel block, then 9001 the Consumer should have completed the payment but not continuing with 9002 the transaction for some reason. In this case the Consumer is likely to 9003 go to the CancelNetLocn specified on the Trading Role Element in the 9004 Organisation Component for the Merchant from which any further action may 9005 take place. 9007 9.1.3.2 Payment Request IOTP Message 9009 Apart from a Transaction Reference Block (see section 3.3), this message 9010 consists of: 9012 o a Payment Request Block, and 9013 o an optional Signature Block 9015 PAYMENT REQUEST BLOCK 9017 The Payment Request Block (see section 8.7) contains: 9019 o the following components copied from the Offer Response Block from the 9020 preceding Offer Document Exchange: 9021 - the Status Component 9022 - the Payment Component for the payment which is being carried out 9024 o the following components from the TPO Block: 9025 - the Organisation Components with the roles of Merchant and for the 9026 PaymentHandler that is being sent the Payment Request Block 9027 - the Brand List Component for the payment, i.e. the Brand List 9028 referred to by the BrandListRef attribute on the Payment Component 9030 o one Brand Selection Component for the Brand List, i.e. the Brand 9031 Selection Component where BrandListRef attribute points to the Brand 9032 List. This component can be either: 9033 - copied from the TPO Selection Block if the payment was preceded by a 9034 Brand Dependent Offer Document Exchange (see section 9.1.2.1), or 9035 - created by the Consumer, containing the payment brand, payment 9036 protocol and currency/amount selected from the Brand List, if the 9037 payment was preceded by a Brand Independent Offer Document Exchange 9038 (see section 9.1.2.2) 9040 o an optional Payment Scheme Component (see section 7.10) if required by 9041 the payment method used (see the Payment Method supplement to determine 9042 if this is needed). 9044 o zero or more Trading Role Data Components (see section 7.17). 9046 Note that: 9048 o if there is more than one Payment Components in an Offer Response 9049 Block, then the second payment is the one within the Offer Response 9050 Block that contains a StartAfter attribute (see section 7.9) that 9051 identifies the Payment Component for the first payment 9053 o the Payment Handler to include is identified by the Brand Selection 9054 Component (see section 7.8) for the payment. Also see section 6.3.1 9055 Check Request Block sent Correct Organisation for an explanation on how 9056 Payment Handlers are identified 9058 o the Brand List Component to include is the one identified by the 9059 BrandListRef attribute of the Payment Component for the identified 9060 payment 9062 o the Brand Selection Component to include from the Offer Response Block 9063 is the one that contains an BrandListRef attribute (see section 3.5) 9064 which identifies the Brand List Component for the second payment. 9066 SIGNATURE BLOCK (PAYMENT REQUEST) 9068 If the either the preceding Offer Document Exchange included an Offer 9069 Response Signature (see section 9.1.2.5 Offer Response IOTP Message), or 9070 a preceding Payment Exchange included a Payment Response Signature (see 9071 section 9.1.3.4 Payment Response IOTP Message) then they should both be 9072 copied to the Signature Block in the Payment Request IOTP Message. 9074 9.1.3.3 Payment Exchange IOTP Message 9076 Apart from a Transaction Reference Block (see section 3.3), this message 9077 consists of just a Payment Exchange Block. 9079 PAYMENT EXCHANGE BLOCK 9081 The Payment Exchange Block (see section 8.8) contains: 9083 o one Payment Scheme Component (see section 7.10) which contains payment 9084 method specific data. See the Payment Method supplement for the payment 9085 method being used to determine what this should contain. 9087 9.1.3.4 Payment Response IOTP Message 9089 Apart from a Transaction Reference Block (see section 3.3), this message 9090 consists of: 9092 o a Payment Response Block, and 9094 o an optional Signature Block 9096 PAYMENT RESPONSE BLOCK 9098 The Payment Response Block (see section 8.9) contains: 9100 o one Payment Receipt Component (see section 7.11) which contains scheme 9101 specific data which can be used to verify the payment occurred 9103 o one Payment Scheme Component (see section 7.10) if required which 9104 contains payment method specific data. See the Payment Method 9105 supplement for the payment method being used to determine what this 9106 should contain 9108 o an optional Payment Note Component (see section 7.12) 9110 o zero or more Trading Role Data Components (see section 7.17). 9112 SIGNATURE BLOCK (PAYMENT RESPONSE) 9114 If a signed Payment Receipt is being provided, indicated by the 9115 SignedPayReceipt attribute of the Payment Component being set to True, 9116 then the Signature Block should contain a Signature Component which 9117 contains Digest Elements for the following: 9119 o the Transaction Reference Block (see section 3.3) for the IOTP Message 9120 which contains the first usage of the Payment Response Block, 9122 o the Transaction Id Component (see section 3.3.1) within the Transaction 9123 Reference Block that globally uniquely identifies the IOTP Transaction, 9125 o the Payment Receipt Component from the Payment Response Block, 9127 o the Payment Note Component from the Payment Response Block, 9129 o the other Components referenced by the PayReceiptRefs attribute (if 9130 present) of the Payment Receipt Component, 9132 o the Status Component from the Payment Response Block, 9134 o any Trading Role Data Components in the Payment Response Block, and 9136 o all the Signature Components contained in the Payment Request Block if 9137 present. 9139 9.1.4 Delivery Document Exchange 9141 The Delivery Document Exchange is a direct implementation of a Delivery 9142 Trading Exchange (see section 2.2.3). It consists of: 9144 o the Consumer requesting a Delivery by generating Delivery Request IOTP 9145 Message using information from previous IOTP Messages in the 9146 Transaction and then sending it to the Delivery Handler 9148 o the Delivery Handler sending a Delivery Response IOTP Message to the 9149 Consumer containing details about the Handler's response to the request 9150 together with an optional signature. 9152 The message flow is illustrated by the diagram below. 9153 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9154 Consumer 9155 | Delivery 9156 | Handler 9157 STEP | | 9158 1. Consumer generates Delivery Request Block and sends it to the 9159 Delivery Handler with the Signature Block if present 9161 C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9162 Delivery Request Block 9164 2. Delivery Handler checks the Status and Order Components in 9165 the Delivery Request and the optional Signatures, creates a 9166 Delivery Response Block, sends to the Consumer and stops. 9168 C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature Block; 9169 Delivery Response Block 9171 3. Consumer checks Delivery Response Block and optional 9172 Signature Block are OK. Optionally keeps information on IOTP 9173 Transaction for record keeping purposes and stops. 9175 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9177 Figure 22 Delivery Document Exchange 9179 9.1.4.1 Message Processing Guidelines 9181 On receiving a Delivery Request IOTP Message, the Delivery Handler should 9182 check that they are authorised to carry out the Delivery (see section 6 9183 Digital Signatures). They may then either: 9185 o generate and send a Delivery Response IOTP Message to the Consumer, or 9187 o indicate failure to continue with the Delivery by sending a Cancel 9188 Block back to the Consumer containing a Status Component with a 9189 StatusType of Delivery, a ProcessState of Failed and the CompletionCode 9190 (see section 7.16.4) set to either: DelivCanceled, or Unspecified. 9192 On receiving a Delivery Response IOTP Message, the Consumer should just 9193 stop since the IOTP Transaction is complete. 9195 If the Consumer receives an IOTP Message containing a Cancel block, then 9196 the information contained in the IOTP Message should be reported to the 9197 Consumer but no further action taken. 9199 9.1.4.2 Delivery Request IOTP Message 9201 The Delivery Request IOTP Message consists of: 9203 o a Delivery Request Block, and 9205 o an optional Signature Block 9207 DELIVERY REQUEST BLOCK 9209 The Delivery Request Block (see section 8.10) contains: 9211 o the following components copied from the Offer Response Block: 9212 - the Status Component (see section 7.16) 9213 - the Order Component (see section 7.5) 9214 - the Organisation Component (see section 7.6) with the roles of: 9215 Merchant, DeliveryHandler and DeliverTo 9216 - the Delivery Component (see section 7.13) 9218 o the following Component from the Payment Response Block: 9219 - the Status Component (see section 7.16). 9221 o zero or more Trading Role Data Components (see section 7.17). 9223 SIGNATURE BLOCK (DELIVERY REQUEST) 9225 If the preceding Offer Document Exchange included an Offer Response 9226 Signature or the Payment Document Exchange included a Payment Response 9227 Signature, then they should both be copied to the Signature Block. 9229 9.1.4.3 Delivery Response IOTP Message 9231 The Delivery Response IOTP Message contains a Delivery Response Block and 9232 an options Signature Block. 9234 DELIVERY RESPONSE BLOCK 9236 The Delivery Response Block contains: 9238 o one Delivery Note Component (see section 7.15) which contains delivery 9239 instructions about the delivery of goods or services 9241 SIGNATURE BLOCK (DELIVERY RESPONSE) 9243 The Signature Block should contain one Signature Component that contains 9244 Digest elements that refer to 9246 o the Transaction Id Component (see section 3.3.1) of the IOTP message 9247 that contains the Delivery Response Signature 9249 o the Transaction Reference Block (see section 3.3) of the IOTP Message 9250 that contains the Delivery Response Signature 9252 o the Consumer Delivery Data component contained in the Delivery Request 9253 Block (if any) 9255 o the Signature Components contained in the Delivery Request Block (if 9256 any) 9258 o the Status Component 9260 o the Delivery Note Component 9262 9.1.5 Payment and Delivery Document Exchange 9264 The Payment and Delivery Document Exchange is a combination of the last 9265 part of the Payment Trading Exchange (see section 2.2.2) and a Delivery 9266 Trading Exchange (see section 2.2.3). It consists of: 9268 o the Consumer requesting that a payment starts by generating Payment 9269 Request IOTP Message using information from previous IOTP Messages in 9270 the Transaction and then sending it to the Payment Handler 9272 o the Payment Handler and the Consumer then swapping Payment Exchange 9273 IOTP Messages encapsulating payment protocol messages until the payment 9274 is complete, and finally 9276 o the Payment Handler sending to the Consumer in one IOTP Message: 9277 - a Payment Response Block containing a receipt for the payment, and 9278 - a Delivery Response Block containing details of the goods or services 9279 to be delivered 9281 The IOTP Messages which are involved are illustrated by the diagram 9282 below. 9283 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9284 Consumer 9285 | Payment 9286 | Handler 9287 STEP | | 9288 1. Consumer generates Pay Request Block encapsulating a payment 9289 protocol message if required and sends to Payment Handler 9290 with the Signature Block if present 9292 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9293 Pay Request Block 9295 2. Payment Handler processes Pay Request Block, checks optional 9296 signature and starts exchanging payment protocol messages 9297 encapsulated in a Pay Exchange Block, with the Consumer 9299 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 9300 Block 9302 3. Consumer and Payment Handler keep on exchanging Payment 9303 Exchange blocks until eventually payment protocol messages 9304 finish so Payment Handler creates a Pay Receipt Component 9305 inside a Pay Response Block, and an optional Signature 9306 Component inside a Signature Block, then uses information 9307 from the Offer Response Bock to crteate a Delivery Response 9308 Block and sends both to the Consumer and stops. 9310 C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref 9311 Block; Signature Block; Pay Response Block; Delivery Response 9312 Block 9314 4. Consumer checks Payment Response and Delivery Response Blocks 9315 are OK. Optionally keeps information on IOTP Transaction for 9316 record keeping purposes and either stops or creates the next 9317 IOTP message for the Transaction and sends it together with 9318 the Signature Block, if present, to the required Trading Role 9320 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9322 Figure 23 Payment and Delivery Document Exchange 9324 The Delivery Response Block and the Payment Response Block may be 9325 combined into the same IOTP Message only if the Payment Handler has the 9326 information available so that she can send the Delivery Response Block. 9327 This is likely to, but will not necessarily, occur when the Merchant, the 9328 Payment Handler and the Delivery Handler Roles are combined. 9330 The DelivAndPayResp attribute of the Delivery Component (see section 9331 7.13) contained within the Offer Response Block (see section 8.3) is set 9332 to True if the Delivery Response Block and the Payment Response Block are 9333 combined into the same IOTP Message and is set to False if the Delivery 9334 Response Block and the Payment Response Block are sent in separate IOTP 9335 Messages. 9337 9.1.5.1 Message Processing Guidelines 9339 On receiving a Payment Request IOTP Message or a Payment Exchange IOTP 9340 Message, the Payment Handler should carry out the same actions as for a 9341 Payment Document Exchange (see section 9.1.3.1). 9343 On receiving a Payment Exchange IOTP Message, the Consumer should also 9344 carry out the same actions as for a Payment Document Exchange (see 9345 section 9.1.3.1). 9347 On receiving a Payment Response and Delivery Response IOTP Message then 9348 the IOTP Transaction is complete and should take no further action. 9350 If the Consumer receives an IOTP Message containing a Cancel block, then 9351 the information contained in the IOTP Message should be reported to the 9352 Consumer but no further action taken. 9354 If the Payment Handler receives an IOTP Message containing a Cancel 9355 block, then the Consumer is likely to go to the CancelNetLocn specified 9356 on the Trading Role Element in the Organisation Component for the Payment 9357 Handler from which any further action may take place. 9359 If the Merchant receives an IOTP Message containing a Cancel block, then 9360 the Consumer should have completed the payment but not continuing with 9361 the transaction for some reason. In this case the Consumer is likely to 9362 go to the CancelNetLocn specified on the Trading Role Element in the 9363 Organisation Component for the Merchant from which any further action may 9364 take place. 9366 9.1.5.2 Payment Request IOTP Message 9368 The content of this message is the same as for a Payment Request IOTP 9369 Message in a Payment Document Exchange (see section 9.1.3.2) 9371 9.1.5.3 Payment Exchange IOTP Message 9373 The content of this message is the same as for a Payment Exchange IOTP 9374 Message in a Payment Document Exchange (see section 9.1.3.3). 9376 9.1.5.4 Payment Response and Delivery Response IOTP Message 9378 The content of this message consists of: 9380 o a Payment Response Block, 9382 o an optional Signature Block (Payment Response), and 9383 o a Delivery Response Block. 9385 PAYMENT RESPONSE BLOCK 9387 The content of this block is the same as the Payment Response Block in 9388 the Payment Response IOTP Message associated with a Payment Document 9389 Exchange (see section 9.1.3.4). 9391 SIGNATURE BLOCK (PAYMENT RESPONSE) 9393 The content of this block is the same as the Signature Block (Payment 9394 Response) in the Payment Response IOTP Message associated with a Payment 9395 Document Exchange (see section 9.1.3.4). 9397 DELIVERY RESPONSE BLOCK 9399 The content of this block is the same as the Delivery Response Block in 9400 the Delivery Response IOTP Message associated with a Delivery Document 9401 Exchange (see section 9.1.4.3). 9403 9.1.6 Baseline Authentication IOTP Transaction 9405 A Baseline Authentication IOTP Transaction may occur at any time between 9406 any of the Trading Roles involved in IOTP Transactions. This means it 9407 could occur: 9409 o before another IOTP Transaction 9411 o at the same time as another IOTP Transaction 9413 o independently of any other IOTP Transaction. 9415 The Baseline Authentication IOTP Transaction consists of just an 9416 Authentication Document Exchange (see section 9.1.1) as illustrated by 9417 the diagram below. 9418 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9420 START ------------------------------------------------------- 9421 v 9422 ---------------- 9423 | AUTHENTICATION | 9424 ---------------- 9425 | 9426 | 9427 | 9428 | 9429 ------------------- ----------------- | 9430 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9431 | OFFER | | OFFER | | 9432 ------------------- ----------------- | 9433 | 9434 | 9435 | 9436 | 9437 | 9438 --------- -------------- | 9439 | PAYMENT | | PAYMENT WITH | | 9440 | (first) | | DELIVERY | | 9441 --------- -------------- | 9442 | 9443 | 9444 | 9445 ---------- --------- | 9446 | DELIVERY | | PAYMENT | | 9447 | | | {second)| | 9448 ---------- --------- | 9449 v 9450 STOP 9452 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9454 Figure 24 Baseline Authentication IOTP Transaction 9456 Example uses of the Baseline Authentication IOTP Transaction include: 9458 o when the Baseline Authentication IOTP Transaction takes place as an 9459 early part of a session where strong continuity exists. For example, a 9460 Financial Institution could: 9461 - set up a secure channel (e.g. using [SSL/TLS]) with a customer 9462 - authenticate the customer using the Baseline Authentication IOTP 9463 Transaction, and then 9464 - provide the customer with access to account information and other 9465 services with the confidence that they are communicating with a bona 9466 fide customer. 9468 o as a means of providing a Merchant role with Organisation Components 9469 that contain information about Consumer and DelivTo Trading Roles 9471 o so that a Consumer may authenticate a Payment Handler before starting a 9472 payment. 9474 9.1.7 Baseline Deposit IOTP Transaction 9476 The Baseline Deposit IOTP Transaction supports the deposit of electronic 9477 cash with a Financial Institution. 9479 [Note] The Financial Institution has, in IOTP terminology, a role of 9480 merchant in that a service (i.e. a deposit of electronic cash) 9481 is being offered in return for a fee, for example bank charges 9482 of some kind. The term "Financial Institution" is used in the 9483 diagrams and in the text for clarity. 9484 [Note End] 9486 The Baseline Deposit IOTP Transaction consists of the following Document 9487 Exchanges: 9489 o an optional Authentication Document Exchange (see section 9.1.1) 9491 o an Offer Document Exchange (see section 9.1.2), and 9493 o a Payment Document Exchange (see section 9.1.3). 9495 The way in which these Document Exchanges may be combined together is 9496 illustrated by the diagram below. 9497 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9499 START ----------------------------------------------------- 9500 | v 9501 | ---------------- 9502 | | AUTHENTICATION | 9503 | ---------------- 9504 -------------------------------------- | 9505 | | | 9506 | -------------- | ------------- 9507 v v v v 9508 ------------------- ----------------- 9509 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9510 | OFFER | | OFFER | 9511 ------------------- ----------------- 9512 | | 9513 | | 9514 | | 9515 | ------------------- 9516 v v 9517 --------- -------------- 9518 | PAYMENT | | PAYMENT WITH | 9519 | (first) | | DELIVERY | 9520 --------- -------------- 9521 | 9522 ---------------- 9523 | 9524 ---------- --------- | 9525 | DELIVERY | | PAYMENT | | 9526 | | | {second)| | 9527 ---------- --------- | 9528 | 9529 -----------------> STOP 9531 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9533 Figure 25 Baseline Deposit IOTP Transaction 9535 See section 9.1.12 "Valid Combinations of Document Exchanges" to 9536 determine which combination of document exchanges apply to a particular 9537 instance of an IOTP Transaction 9539 Note that: 9541 o a Merchant (Financial Institution) may be able to accept a deposit in 9542 several different types of electronic cash although, since the Consumer 9543 role that is depositing the electronic cash usually knows what type of 9544 cash they want to deposit, it is usually constrained in practice to 9545 only one type. However, there may be several different protocols which 9546 may be used for the same "brand" of electronic cash. In this case a 9547 Brand Dependent Offer may be appropriate to negotiate the protocol to 9548 be used. 9550 o the Merchant (Financial Institution) may use the results of the 9551 authentication to identify not only the consumer but also the account 9552 to which the payment is to be deposited. If no single account can be 9553 identified, then it must be obtained by other means. For example: 9554 - the consumer could specify the account number prior to the Baseline 9555 Deposit IOTP Transaction starting, or 9556 - the consumer could have been identified earlier, for example using a 9557 Baseline Authentication IOTP Transaction, and an account selected 9558 from a list provided by the Financial Institution. 9560 o The Baseline Deposit IOTP Transaction without an Authentication 9561 Document Exchange might be used: 9562 - if a previous IOTP transaction, for example a Baseline Withdrawal or 9563 a Baseline Authentication, authenticated the consumer, and a secure 9564 channel has been maintained, therefore the authenticity of the 9565 consumer is known 9566 - if authentication is achieved as part of a proprietary payment 9567 protocol and is therefore included in the Payment Document Exchange 9568 - if authentication of the consumer has been achieved by some other 9569 means outside of the scope of IOTP, for example, by using a pass 9570 phrase, or a proprietary banking software solution. 9572 9.1.8 Baseline Purchase IOTP Transaction 9574 The Baseline Purchase IOTP Transaction supports the purchase of goods or 9575 services using any payment method. It consists of the following Document 9576 Exchanges: 9578 o an optional Authentication Document Exchange (see section 9.1.1) 9580 o an Offer Document Exchange (see section 9.1.2) 9582 o either: 9583 - a Payment Document Exchange (see section 9.1.3) followed by 9584 - a Delivery Document Exchange (see section 9.1.4) 9586 o a Payment Document Exchange only, or 9588 o a combined Payment and Delivery Document Exchange (see section 9.1.5). 9590 The ways in which these Document Exchanges are combined is illustrated by 9591 the diagram below. 9592 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9593 START ----------------------------------------------------- 9594 | v 9595 | ---------------- 9596 | | AUTHENTICATION | 9597 | ---------------- 9598 -------------------------------------- | | 9599 | | | | 9600 | -------------- | ------------- | 9601 v v v v | 9602 ------------------- ----------------- | 9603 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9604 | OFFER | | OFFER | | 9605 ------------------- ----------------- | 9606 | | | | | 9607 | --------------- | | | 9608 | | | | | 9609 | -------------- | -- | | 9610 v v v v | 9611 --------- -------------- | 9612 | PAYMENT | | PAYMENT WITH | | 9613 | (first) | | DELIVERY | | 9614 --------- -------------- | 9615 | | | 9616 ----------------------------- | | 9617 v | | | 9618 ---------- --------- | | | 9619 | DELIVERY | | PAYMENT | | | | 9620 | | | {second)| | | | 9621 ---------- --------- | | | 9622 | | | v 9623 ----------------------------------------------> STOP 9625 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9627 Figure 26 Baseline Purchase IOTP Transaction 9629 See section 9.1.12 Valid Combinations of Document Exchanges to determine 9630 which combination of document exchanges apply to a particular instance of 9631 an IOTP Transaction 9633 9.1.9 Baseline Refund IOTP Transaction 9635 In business terms the refund process typically consists of: 9637 o a request for a refund being made by the Consumer to the Merchant, 9638 typically supported by evidence to demonstrate: 9639 - the original trade took place, for example by providing a receipt for 9640 the original transaction 9641 - using some type of authentication, that the consumer requesting the 9642 refund is the consumer, or a representative of the consumer, who 9643 carried out the original trade 9644 - the reason why the merchant should make the refund 9646 o the merchant agreeing (or not) to the refund. This may involve some 9647 negotiation between the Consumer and the Merchant, and, if the merchant 9648 agrees, 9650 o a refund payment by the Merchant to the Consumer. 9652 The Baseline Refund IOTP Transaction supports a subset of the above, 9653 specifically it supports: 9655 o stand alone authentication of the Consumer using a separate Baseline 9656 Authentication IOTP Transaction (see section 9.1.6) 9658 o a refund payment by the Merchant to the Consumer using the following 9659 two Trading Exchanges: 9660 - an optional Authentication Document Exchange (see section 9.1.1) 9661 - an Offer Document Exchange (see section 9.1.2), and 9662 - a Payment Document Exchange (see section 9.1.3). 9664 The ways in which these Document Exchanges are combined is illustrated by 9665 the diagram below. 9666 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9668 START ----------------------------------------------------- 9669 | v 9670 | ---------------- 9671 | | AUTHENTICATION | 9672 | ---------------- 9673 -------------------------------------- | 9674 | | | 9675 | -------------- | ------------- 9676 v v v v 9677 ------------------- ----------------- 9678 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9679 | OFFER | | OFFER | 9680 ------------------- ----------------- 9681 | | 9682 | | 9683 | | 9684 | ------------------- 9685 v v 9686 --------- -------------- 9687 | PAYMENT | | PAYMENT WITH | 9688 | (first) | | DELIVERY | 9689 --------- -------------- 9690 | 9691 ---------------- 9692 | 9693 ---------- --------- | 9694 | DELIVERY | | PAYMENT | | 9695 | | | {second)| | 9696 ---------- --------- | 9697 | 9698 -----------------> STOP 9700 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9702 Figure 27 Baseline Refund IOTP Transaction 9704 A Baseline Refund IOTP Transaction without an Authentication Document 9705 Exchange might be used: 9707 o when authentication of the consumer has been achieved by some other 9708 means, for example, the consumer has entered some previously supplied 9709 code in order to identify herself and the refund to which the code 9710 applies. The code could be supplied, for example on a web page or by e- 9711 mail. 9713 o when a previous IOTP transaction, for example a Baseline 9714 Authentication, authenticated the consumer, and a secure channel has 9715 been maintained, therefore the authenticity of the consumer is known 9716 and therefore the previously agreed refund can be identified. 9718 o when the authentication of the consumer is carried out by the Payment 9719 Handler using a payment scheme authentication algorithm. 9721 9.1.10 Baseline Withdrawal IOTP Transaction 9723 The Baseline Withdrawal IOTP Transaction supports the withdrawal of 9724 electronic cash from a Financial Institution. 9726 [Note] The Financial Institution has, in IOTP terminology, a role of 9727 merchant in that a service (i.e. a withdrawal of electronic 9728 cash) is being offered in return for a fee, for example bank 9729 charges of some kind. The term "Financial Institution" is used 9730 in the diagrams and in the text for clarity. 9731 [Note End] 9733 The Baseline Withdrawal IOTP Transaction consists of the following 9734 Document Exchanges: 9736 o an optional Authentication Document Exchange (see section 9.1.1) 9738 o an Offer Document Exchange (see section 9.1.2), and 9740 o a Payment Document Exchange (see section 9.1.3). 9742 The way in which these Document Exchanges may be combined together is 9743 illustrated by the diagram below. 9744 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9746 START ----------------------------------------------------- 9747 | v 9748 | ---------------- 9749 | | AUTHENTICATION | 9750 | ---------------- 9751 -------------------------------------- | 9752 | | | 9753 | -------------- | ------------- 9754 v v v v 9755 ------------------- ----------------- 9756 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9757 | OFFER | | OFFER | 9758 ------------------- ----------------- 9759 | | 9760 | | 9761 | | 9762 | ------------------- 9763 v v 9764 --------- -------------- 9765 | PAYMENT | | PAYMENT WITH | 9766 | (first) | | DELIVERY | 9767 --------- -------------- 9768 | 9769 ---------------- 9770 | 9771 ---------- --------- | 9772 | DELIVERY | | PAYMENT | | 9773 | | | {second)| | 9774 ---------- --------- | 9775 | 9776 -----------------> STOP 9778 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9780 Figure 28 Baseline Withdrawal IOTP Transaction 9782 Note that: 9784 o a Merchant (Financial Institution) may be able to offer withdrawal of 9785 several different types of electronic cash. In practice usually only 9786 one form of electronic cash may be offered. However, there may be 9787 several different protocols which may be used for the same "brand" of 9788 electronic cash 9790 o the Merchant (Financial Institution) may use the results of the 9791 authentication to identify not only the consumer but also the account 9792 from which the withdrawal is to be made. If no single account can be 9793 identified, then it must be obtained by other means. For example: 9794 - the consumer could specify the account number prior to the Baseline 9795 Withdrawal IOTP Transaction starting, or 9796 - the consumer could have been identified earlier, for example using a 9797 Baseline Authentication IOTP Transaction, and an account selected 9798 from a list provided by the Financial Institution. 9800 o a Baseline Withdrawal without an authentication might be used: 9801 - if a previous IOTP transaction, for example a Baseline Deposit or a 9802 Baseline Authentication, authenticated the consumer, and a secure 9803 channel has been maintained, therefore the authenticity of the 9804 consumer is known 9806 - if authentication is achieved as part of a proprietary payment 9807 protocol and is therefore included in the Payment Document Exchange 9808 - if authentication of the consumer has been achieved by some other 9809 means, for example, by using a pass phrase, or a proprietary banking 9810 software solution. 9812 9.1.11 Baseline Value Exchange IOTP Transaction 9814 The Baseline Value Exchange Transaction uses Payment Document Exchanges 9815 to support the exchange of value in one currency obtained using one 9816 payment method with value in the same or another currency using the same 9817 or another payment method. Examples of its use include: 9819 o electronic cash advance on a credit card. For example the first payment 9820 could be a "dollar SET Payment" using a credit card with the second 9821 payment being a download of Visa Cash e-cash in dollars. 9823 o foreign exchange using the same payment method. For example the payment 9824 could be an upload of Mondex value in British Pounds and the second a 9825 download of Mondex value in Euros 9827 o foreign exchange using different payment methods. For example the first 9828 payment could be a SET payment in Canadian Dollars followed a download 9829 of GeldKarte in Deutchmarks. 9831 The Baseline Value Exchange uses the following Document Exchanges: 9833 o an optional Authentication Document Exchange (see section 9.1.1) 9835 o an Offer Document Exchange (see section 9.1.2), which provides details 9836 of what values and currencies will be exchanged, and 9838 o two Payment Document Exchanges (see section 9.1.3) which carry out the 9839 two payments involved. 9841 The way in which these Document Exchanges may be combined together is 9842 illustrated by the diagram below. 9843 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9845 START ----------------------------------------------------- 9846 | v 9847 | ---------------- 9848 | | AUTHENTICATION | 9849 | ---------------- 9850 -------------------------------------- | 9851 | | | 9852 | -------------- | ------------- 9853 v v v v 9854 ------------------- ----------------- 9855 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9856 | OFFER | | OFFER | 9857 ------------------- ----------------- 9858 | | 9859 | | 9860 | | 9861 | ------------------- 9862 v v 9863 --------- -------------- 9864 | PAYMENT | | PAYMENT WITH | 9865 | (first) | | DELIVERY | 9866 --------- -------------- 9867 | 9868 ---- 9869 v 9870 ---------- --------- 9871 | DELIVERY | | PAYMENT | 9872 | | | {second)| 9873 ---------- --------- 9874 | 9875 -----------------------------> STOP 9877 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9879 Figure 29 Baseline Value Exchange IOTP Transaction 9881 The Baseline Value Exchange IOTP Transaction occurs in two basic forms: 9883 o Brand Dependent Value Exchange. Where the content of the offer, for 9884 example the rate at which one form of value is exchanged for another, 9885 is dependent on the payment brands and protocols selected by the 9886 consumer, and 9888 o Brand Independent Value Exchange. Where the content of the offer is not 9889 dependent on the payment brands and protocols selected. 9891 [Note] In the above the role is a Merchant even though the 9892 organisation carrying out the Value Exchange may be a Bank or 9893 some other Financial Institution. This is because the Bank is 9894 acting as a merchant in that they are making an offer which 9895 the Consumer can either accept or decline. 9896 [Note End] 9898 The TPO Block and Offer Response Block may only be combined into the same 9899 IOTP Message if the content of the Offer Response Block does not change 9900 as a result of selecting the payment brands and payment protocols to be 9901 used in the Value Exchange. 9903 BASELINE VALUE EXCHANGE SIGNATURES 9905 The use of signatures to ensure the integrity of a Baseline Value 9906 Exchange is illustrated by the diagram below. 9908 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9910 Signature generated IotpMsg (TPO) 9911 by Merchant ensures - Trans Ref Block 9912 integrity of the Offer --------> - - Signature Block 9913 | - TPO Block MERCHANT 9914 | - Offer Response Block 9915 | 9916 Signature generated by | 9917 the Payment Handler of | IotpMsg (Pay Resp 1) 9918 the first payment binds | - Trans Ref Block PAYMENT 9919 Pay Receipt for the first -----> -> - Signature Block ----- HANDLER 9920 payment to the Offer - Pay Response Block 1 | 1 9921 | 9922 Signature generated by | 9923 the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT 9924 the second payment binds - Trans Ref Block | HANDLER 9925 the second payment to the -----> - Signature Block <------ 2 9926 first payment and therefore - Pay Response Block 2 9927 to the Offer 9929 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9931 Figure 30 Baseline Value Exchange Signatures 9933 9.1.12 Valid Combinations of Document Exchanges 9935 The following diagram illustrates the data conditions in the various IOTP 9936 messages which can be used by a Consumer Trading Role to determine 9937 whether the combination of Document Exchanges are valid. 9938 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9940 START 9941 | 9942 v 9943 Auth Request Block in =TRUE 9944 first IOTP Message ? --------------------------------------- 9945 | = FALSE | 9946 v v 9947 Offer Response Block in ---------------- 9948 first IOTP Message ? | AUTHENTICATION | 9949 |=TRUE |=FALSE ---------------- 9950 | | | 9951 | | v 9952 | ---------------------- TPO & Offer Response 9953 ------------- | Blocks in last IOTP Msg 9954 | | |=TRUE |=FALSE 9955 | | | v 9956 | ------------- | ---- TPO Block only if 9957 | | | last IOTP Message 9958 | | | of Authentication 9959 | | | |=TRUE |=FALSE 9960 v v v v | 9961 ------------------- ----------------- | 9962 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9963 | OFFER | | OFFER | | 9964 ------------------- ----------------- | 9965 | | | 9966 v v | 9967 Offer Response Block contains | 9968 Delivery Component ? | 9969 |=FALSE |=TRUE | 9970 --- v | 9971 | Value of DelivAndPayResp | 9972 | attribute of Delivery Component ? | 9973 | |=FALSE |=TRUE | 9974 | | | | 9975 v v v | 9976 --------- -------------- | 9977 | PAYMENT | | PAYMENT WITH | | 9978 | (first) | | DELIVERY | | 9979 --------- -------------- | 9980 | | | 9981 v | | 9982 Offer and Response Block contains -------------->| 9983 Delivery Component ? | 9984 |=TRUE |=FALSE | 9985 | v | 9986 | Two Payment Components | 9987 | present in Offer Response Block? | 9988 | |=TRUE |=FALSE | 9989 v v | | 9990 ---------- --------- | | 9991 | DELIVERY | | PAYMENT | | | 9992 | | | {second)| | | 9993 ---------- --------- | | 9994 | | | v 9995 ----------------------------------------------> STOP 9997 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9999 Figure 31 Valid Combinations of Document Exchanges 10001 1) If first IOTP Message of an IOTP Transaction contains an Authentication 10002 Request then: 10004 a) IOTP Transaction includes an Authentication Document Exchange (see 10005 section 9.1.1). (Note 1) 10007 b) If the last IOTP Message of the Authentication Document Exchange 10008 includes a TPO Block and an Offer Response Block then: 10010 i)IOTP Transaction includes a Brand Independent Offer Document 10011 Exchange (see section 9.1.2.2). (Note 2) 10013 c) Otherwise, if the last IOTP Message of the Authentication Exchange 10014 includes a TPO Block but NO Offer Response Block, then: 10016 i)IOTP Transaction includes a Brand Dependent Offer Document Exchange 10017 (see section 9.1.2.1). (Note 2) 10019 d) Otherwise (Authentication Status IOTP Message of the Authentication 10020 Document Exchange contains neither a TPO Block but nor an Offer 10021 Response Block) 10023 i)IOTP Transaction consists of just an Authentication Document 10024 Exchange. (Note 3) 10026 2) Otherwise (no Authentication Request in first IOTP Message): 10028 e) IOTP Transaction does not include an Authentication Document Exchange 10029 (Note 2) 10031 f) If first IOTP Message contains an Offer Response Block, then: 10033 i)the IOTP Transaction contains a Brand Independent Offer Document 10034 Exchange (Note 2) 10036 g) Otherwise (no Offer Response Block in first IOTP Message): 10038 i)the IOTP Transaction includes a Brand Dependent Offer Document 10039 Exchange (Note 2) 10041 3) If an Offer Response Block exists in any IOTP message then: 10043 h) If the Offer Response Block contains a Delivery Component then: 10045 i)If the DelivAndPayResp attribute of the Delivery Component is set 10046 to True, then: 10048 (1)the IOTP Transaction consists of a Payment And Delivery 10049 Document Exchange (see section 9.1.5) (Note 4) 10051 ii)otherwise (the DelivAndPayResp attribute of the Delivery 10052 Component is set to False) 10054 (1)the IOTP Transaction consists of a Payment Document Exchange 10055 (see section 9.1.3) followed by a Delivery Document Exchange 10056 (see section 9.1.4) (Note 4) 10058 i) otherwise (the Offer Response Block does not contain a Delivery 10059 Component) 10061 i)if the Offer Response Block contains just one Payment Component, 10062 then: 10064 (1)the IOTP Transaction contains just one Payment Document 10065 Exchange (Note 5) 10067 ii) if the Offer Response Block contains two Payment Components, 10068 then: 10070 (1)the IOTP Transaction contains two Payment Document Exchanges. 10071 The StartAfter attribute of the Payment Components is used to 10072 indicate which payment occurs first (Note 6) 10074 iii)if the Offer Response Block contains no or more than two 10075 Payment Components, then there is an error 10077 4) Otherwise (no Offer Response Block) there is an error. 10079 The following table indicates the types of IOTP Transactions which can 10080 validly have the conditions indicated above. 10082 Note IOTP Transaction Validity 10084 1. Any Payment and Authentication IOTP Transaction 10086 2. Any Payment and Authentication IOTP Transaction except Baseline 10087 Authentication 10089 3. Either Baseline Authentication, or a Baseline Purchase, Refund, 10090 Deposit, Withdrawal or Value Exchange with a failed 10091 Authentication 10093 4. Baseline Purchase only 10095 5. Baseline Purchase, Refund, Deposit or Withdrawal 10097 6. Baseline Value Exchange only 10099 9.1.13 Combining Authentication Transactions with other Transactions 10101 In the previous sections an Authentication Document Exchange is shown 10102 preceding an Offer Document Exchange as part of a single IOTP Transaction 10103 with the same IOTP Transaction Id. 10105 It is also possible to run a separate Authentication Transaction at any 10106 point, even in parallel with another IOTP Transaction. Typically this 10107 will be used: 10109 o by a Consumer to authenticate a Merchant, Payment Handler or a Delivery 10110 Handler, or 10112 o by a Payment Handler or Delivery Handler to authenticate a Consumer. 10114 In outline the basic process consists of: 10116 o the Trading Role that decides it wants to carry out an authentication 10117 of another role suspends the current IOTP transaction being carried out 10119 o a stand-alone Authentication transaction is then carried out. This may, 10120 at implementer's option, be linked to the original IOTP Transaction 10121 using a Related To Component (see section 3.3.3) in the Transaction 10122 Reference Block. 10124 o if the Authentication transaction is successful, then the original IOTP 10125 Transaction is restarted 10127 o if the Authentication fails then the original IOTP Transaction is 10128 cancelled. 10130 For example, a Consumer could: 10132 o authenticate the Payment Handler for a Payment between receiving an 10133 Offer Response from a Merchant and before sending the Payment Request 10134 to that Payment Handler 10136 o authenticate a Delivery Handler for a Delivery between receiving the 10137 Payment Response from a Payment Handler and before sending the Delivery 10138 Request 10140 A Payment Handler could authenticate a Consumer after receiving the 10141 Payment Request and before sending the next Payment related message. 10143 A Delivery Handler could authenticate a Consumer after receiving the 10144 Delivery Request and before sending the Delivery Response. 10146 [Note] Some Payment Methods may carry out an authentication within 10147 the Payment Exchange. In this case the information required to 10148 carry out the authentication will be included in Payment 10149 Scheme Components. 10151 In this instance IOTP aware application will not be aware that 10152 an authentication has occurred since the Payment Scheme 10153 Components that contain authentication request information 10154 will be indistinguishable from other Payment Scheme 10155 Components. 10156 [Note End] 10158 9.2 Infrastructure Transactions 10160 Infrastructure Transactions are designed to support inquiries about 10161 whether or not a transaction has succeeded or a Trading Role's servers 10162 are operating correctly. There are two types of transaction: 10164 o a Transaction Status Inquiry Transaction which provides information on 10165 the status of an existing or complete IOTP transaction, and 10167 o Ping Transaction that enables one IOTP aware application to determine 10168 if the IOTP aware application at another Trading Role is operating and 10169 verify whether or not signatures can be handled. 10171 Each of these is described below 10173 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 10175 The Baseline IOTP Transaction Status Inquiry provides information on the 10176 status of an existing or complete IOTP transaction. 10178 The Trading Blocks used by the Baseline Transaction Status Inquiry 10179 Transaction are: 10181 o an Inquiry Request Trading Block (see section 8.12), 10183 o an Inquiry Response Trading Block (see section 8.13) 10185 o an optional Signature Block (see section 8.16). 10187 The Inquiry IOTP Transaction can be used for a variety of reasons. For 10188 example: 10190 o to help in resuming a suspended transaction to determine the current 10191 state of processing of one of the other roles, 10193 o for a merchant to determine if a payment, delivery, etc. was completed. 10194 For example, a Consumer might claim that payment was made but no signed 10195 IOTP payment receipt was available to prove it. If the Merchant makes 10196 an inquiry of the Payment Handler then the Merchant can determine 10197 whether or not payment was made. 10199 [Note] Inquiries on Baseline Ping IOTP Transactions (see section 10200 9.2.2) are ignored. 10201 [Note End] 10203 MAKING INQUIRIES OF ANOTHER TRADING ROLE 10205 One Trading Role may make an inquiry of any other Trading Role at any 10206 point in time. 10208 IOTP aware software that supports the Consumer Trading Role may not: 10210 o digitally sign a response if requested, since it may not have the 10211 capability, or 10213 o respond to an Inquiry Request at all since it may not be on-line, or 10214 may consider that the request is not reasonable since, for example, the 10215 Request was not digitally signed. 10217 As a guideline: 10219 o the Consumer should send a Transaction Status Inquiry Block to a 10220 Trading Role only after the following events have occurred: 10221 - to the Merchant, after sending a TPO Selection Block, 10222 - to the Payment Handler, after sending a Payment Request Block, 10223 - to the Delivery Handler, after sending a Delivery Request Block, 10225 o other Trading Roles should send a Transaction Status Inquiry Block to 10226 the Consumer only after receiving a message from the Consumer and 10227 before sending the final "Response" message to the Consumer 10229 o there are no restrictions on non-Consumer Trading Roles sending 10230 Inquiries to other trading roles. 10232 TRANSACTION STATUS INQUIRY TRANSPORT SESSION 10234 For a Transaction Status Inquiry on an ongoing transaction a different 10235 transport session from the ongoing transaction is used. For a Transaction 10236 Status Inquiry on a past transaction, how the IOTP module on the software 10237 at the Trading Role is started upon the receipt of Inquiry Request 10238 message is defined in each Mapping to Transport supplement for IOTP. 10240 TRANSACTION STATUS INQUIRY ERROR HANDLING 10242 Errors in a Transaction Status Inquiry can be categorised into one of the 10243 following three cases: 10245 o Business errors (see section 4.2) in the original (inquired) messages 10247 o Technical errors (see section 4.1) - both IOTP and payment scheme 10248 specific ones - in the original IOTP (inquired) messages 10250 o Technical errors in the message containing the Inquiry Request Block 10251 itself 10253 The following outlines what the software should do in each case 10255 BUSINESS ERRORS IN THE ORIGINAL MESSAGES 10257 Return an Inquiry Response Block containing the Status Component which 10258 was last sent to the Consumer Role. 10260 TECHNICAL ERRORS IN THE ORIGINAL MESSAGES 10262 Return an Inquiry Response Block containing a Status Component. The 10263 Status Component should contain a ProcessState attribute set to 10264 ProcessError. In this case send back an Error Block indicating where the 10265 error was found in the original message. 10267 TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK 10269 Return an Error message. That is, send back an Error Block containing the 10270 Error Code (see section 7.21.2) which describes the nature of the error 10271 in the Inquiry Request message. 10273 INQUIRY TRANSACTION MESSAGES 10275 The following Figure outlines the Baseline IOTP Transaction Status 10276 Inquiry process. 10278 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10279 1st Role 10280 | 2nd Role 10281 STEP | | 10282 1. The first role decides to inquire on an IOTP Transaction by, 10283 for example, clicking on the inquiry button of an IOTP Aware 10284 Application. This will then generate an Inquiry Request Block 10285 and send it to the appropriate Trading Role. 10287 1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block 10288 (optional); Inquiry Request Block 10290 2. The Trading Role checks the digital signature (if present). 10291 If the recipient wants to respond, then the Trading Role 10292 checks the transaction status of the transaction that is 10293 being inquired upon by using the IotpTransId in the 10294 Transaction ID Component of the Transaction Reference Block, 10295 then generates the appropriate Inquiry Response Block, sends 10296 the message back to the 1st Role and stops 10298 1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry Response 10299 Block; Signature Block (Optional) 10301 3. First role checks the Inquiry Response Block and optional 10302 signature, takes whatever action is appropriate or perhaps 10303 stops. This may include displaying status information to the 10304 end user. 10306 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10308 Figure 32 Baseline Transaction Status Inquiry 10310 The remainder of this sub-section on the Baseline Transaction Status 10311 Inquiry IOTP Transaction defines the contents of each Trading Block. Note 10312 that the term "original transaction" is the transaction which a trading 10313 role wants to discover some information about. 10315 TRANSACTION REFERENCE BLOCK 10317 A Trading Role making an inquiry must use the identical Transaction Id 10318 Component (see section 3.3.1) that was in the original transaction. The 10319 IotpTransId attribute in this component serves as the key in querying the 10320 transaction logs maintained at the Trading Role's site. The value of the 10321 ID attribute of the Message Id Component should be different from those 10322 of any in the original transaction (see section 3.4.1). 10324 INQUIRY REQUEST BLOCK 10326 The Inquiry Request Block (see section 8.12) contains the following 10327 components: 10329 o one Inquiry Type Component (see section 7.18). This identifies whether 10330 the inquiry is on an offer, payment, or delivery. 10332 o zero or one Payment Scheme Components (see section 7.10). This is for 10333 encapsulating payment scheme specific inquiry messages for inquiries on 10334 a payment. 10336 SIGNATURE BLOCK (INQUIRY REQUEST) 10338 If a signature block is present on the message containing the Inquiry 10339 Request Block then it may be checked to determine if the Inquiry Request 10340 is authorised. 10342 If present, the Inquiry Request Signature Block (see section 8.12) 10343 contains the following components: 10345 o one Signature Component (see section 7.19) 10347 o one or more Certificate Components, if required. 10349 Inquiry Response Blocks should only be generated if the Transaction is 10350 authorised. 10352 [Note] Digital signatures on an Inquiry Request is only likely to 10353 occur if the recipient of the request expects the Inquiry 10354 Request to be signed. In this version of IOTP this will 10355 require some kind of pre-existing agreement. This means that: 10356 o Consumers are unlikely to generate requests with signatures, 10357 although it is not an error if they do 10358 o the other trading roles may agree that digital signatures 10359 are required. For example a Payment Handler may require that 10360 an Inquiry Request is digitally signed by the Merchant so 10361 that they can check that the request is valid. 10363 On the other hand if the original transaction to which the 10364 Inquiry relates was carried out over a secure channel (e.g. 10365 [SSL]) then it is probably reasonable to presume that if the 10366 sender of the Inquiry knows the Transaction Id component of 10367 the original message (including for example the timestamp) 10368 then the inquiry is likely to be genuine. 10369 [Note End] 10371 INQUIRY RESPONSE BLOCK 10373 The Inquiry Response Block (see section 8.13) contains the following 10374 components: 10376 o one Status Component (see section 7.16). This component holds the 10377 status information on the inquired transaction, 10379 o zero or one Payment Scheme Components. These contain encapsulated 10380 payment scheme specific inquiry messages for inquiries on payment. 10382 SIGNATURE BLOCK (INQUIRY RESPONSE) 10384 If a signature block is present on the message containing the Inquiry 10385 Response Block then it may be checked by the receiver of the block to 10386 determine if the Inquiry Response is valid. 10388 If present, the Inquiry Response Signature Block (see section 8.13) 10389 contains the following components: 10391 o one Signature Component (see section 7.19) 10393 o one or more Certificate Components, if required. 10395 [Note] Digital signatures on an Inquiry Response is only likely to 10396 occur if the recipient of the response expects the Inquiry 10397 Request to be signed. In this version of IOTP this will 10398 require some kind of pre-existing agreement. This means that: 10399 o Consumers are unlikely to generate responses with 10400 signatures, although it is not an error if they do 10401 o the other trading roles may agree that digital signatures 10402 are required. For example a Merchant may require that an 10403 Inquiry Response is digitally signed by the Payment Handler 10404 so that they can check that the request response is valid. 10405 [Note End] 10407 9.2.2 Baseline Ping IOTP Transaction 10409 The purpose of the Baseline IOTP Ping Transaction is to test basic 10410 connectivity between the Trading Roles that may take part in an IOTP 10411 Transaction. 10413 It enables IOTP aware application software to: 10415 o determine if the IOTP aware application at another Trading Role is 10416 operating, and 10418 o verify whether or not the two trading roles signatures can be 10419 processed. 10421 For example it can be used by a Merchant to determine if a Payment 10422 Handler or Delivery Handler is up and running prior to starting a 10423 Purchase transaction that uses those trading roles. 10425 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 10427 o a Ping Request Block (see section 8.14) 10429 o a Ping Response Block (see section 8.15), and 10431 o a Signature Block (see section 8.16). 10433 PING MESSAGES 10435 The following figure outlines the message flows in the Baseline IOTP Ping 10436 Transaction. 10438 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10439 1st Role 10440 | 2nd Role 10441 STEP | | 10442 1. The IOTP Aware Application in the first Trading Role decides 10443 to check whether the counterparty IOTP application is up and 10444 running. It generates a Ping Request Block and optional 10445 Signature Block and sends them to the second trading role. 10447 1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block 10448 (Optional); Ping Request Block 10450 2. The second Trading Role which receives the Ping Request Block 10451 generates a Ping Response Block and sends it back to the 10452 sender of the original Ping Request with a signature block if 10453 required. 10455 1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block 10456 (Optional); Ping Response Block 10458 3. The first Trading Role checks the Ping Response Block and 10459 takes appropriate action, if necessary 10461 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10463 Figure 33 Baseline Ping Messages 10465 The verification that signatures can be handled is indicated by the 10466 sender of the Ping Request Block including: 10468 o Organisation Components that identify itself and the intended recipient 10469 of the Ping Request Block, and 10471 o a Signature Block that signs data in the Ping Request. 10473 In this way the receiver of the Ping Request: 10475 o knows who is sending the Ping Request and can therefore verify the 10476 Signature on the Request, and 10478 o knows who to generate a signature for on the Ping Response. 10480 Note that a Ping Request: 10482 o does not affect any on-going transaction 10484 o does NOT initiate an IOTP transaction, unlike other IOTP transaction 10485 messages such as TPO or Transaction Status Inquiry. 10487 All IOTP aware applications must return a Ping Response message to the 10488 sender of a Ping Request message when it is received. 10490 A Baseline IOTP Ping request can also contain an optional Signature 10491 Block. IOTP aware applications can, for example, use the Signature Block 10492 to check the recipient of a Ping Request can successfully process and 10493 check signatures it has received. 10495 For each Baseline Ping IOTP Transaction, each IOTP role shall establish a 10496 different transport session from other IOTP transactions. 10498 Any IOTP Trading Role can send a Ping request to any other IOTP Trading 10499 Role at any time it wants. A Ping message has its own IotpTransId, which 10500 is different from other IOTP transactions. 10502 The remainder of this sub-section on the Baseline Ping IOTP Transaction 10503 defines the contents of each Trading Block. 10505 TRANSACTION REFERENCE BLOCK 10507 The IotpTransId of a Ping transaction should be different from any other 10508 IOTP transaction. 10510 PING REQUEST BLOCK 10512 If the Ping Transaction is anonymous then no Organisation Components are 10513 included in the Ping Request Block (see section 8.7). 10515 If the Ping Transaction is not anonymous then the Ping Request Block 10516 contains Organisation Components for: 10518 o the sender of the Ping Request Block, and 10520 o the verifier of the Signature Component 10522 If Organisation Components are present, then it indicates that the sender 10523 of the Ping Request message has generated a Signature Block. The 10524 signature block must be verified by the Trading Role that receives the 10525 Ping Request Block. 10527 SIGNATURE BLOCK (PING REQUEST) 10529 The Ping Request Signature Block (see section 8.16) contains the 10530 following components: 10532 o one Signature Component (see section 7.19) 10534 o one or more Certificate Components, if required. 10536 PING RESPONSE BLOCK 10538 The Ping Response Block (see section 8.15) contains the following 10539 component: 10541 o the Organisation Component of the sender of the Ping Response message 10543 If the Ping Transaction is not anonymous then the Ping Response 10544 additionally contains: 10546 o copies of the Organisation Components contained in the Ping Request 10547 Block. 10549 SIGNATURE BLOCK (PING RESPONSE) 10551 The Ping Response Signature Block (see section 8.16) contains the 10552 following components: 10554 o one Signature Component (see section 7.19) 10556 o one or more Certificate Components, if required. 10558 10. Retrieving Logos 10560 This section describes how to retrieve logos for display by IOTP aware 10561 software using the Logo Net Locations attribute contained in the Brand 10562 Element (see section 7.7.1) and the Organisation Component (see section 10563 7.6). 10565 The full address of a logo is defined as follows: 10566 Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif" 10568 Where: 10570 o Logo_net_location is obtained from the LogoNetLocn attribute in the 10571 Brand Element (see section 7.7.1) or the Organisation Component. Note 10572 that: 10573 - the content of this attribute is dependent on the Transport Mechanism 10574 (such as HTTP) that is used. See the Transport Mechanism supplement, 10575 - implementers should check that if the rightmost character of Logo Net 10576 Location is set to right-slash "/" then another, right slash should 10577 not be included when generating the Logo Address, 10579 o Logo_size identifies the size of the logo, 10581 o Logo_color_depth identifies the colour depth of the logo 10583 o "gif" indicates that the logos are in "gif@ format 10585 Logo_size and Logo_color_depth are specified by the implementer of the 10586 IOTP software that is retrieving the logo depending on the size and 10587 colour that they want to use. 10589 10.1 Logo Size 10591 There are five standard sizes for logos. The sizes in pixels and the 10592 corresponding values for Logo Size are given in the table below. 10594 Size in Logo Size 10595 Pixels Value 10597 32 x 32 or exsmall 10598 32 x 20 10600 53 x 33 small 10602 103 x 65 medium 10604 180 x 114 large 10606 263 x 166 exlarge 10608 10.2 Logo Color Depth 10610 There are three standard colour depths. The colour depth (including bits 10611 per pixel) and the corresponding value for Logo_Color_Depth are given in 10612 the table below. 10614 Color Depth Logo Color 10615 (bits per pixel) Depth Value 10617 4 (16 colors) 4 10619 8 (256 colors) nothing 10621 24 (16 million colors) 24 10623 Note that if Logo Color Depth is omitted then a logo with the default 10624 colour depth of 256 colours will be retrieved. 10626 10.3 Logo Net Location Examples 10628 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 10630 o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 10631 colour logo 10633 o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16 10634 colour logo 10636 [Note] Organisations which make logos available for use with IOTP 10637 should always make available "small" and "medium" size logos 10638 and use the "gif" format. 10639 [Note End] 10641 11. Brands 10643 This section contains: 10645 o a definition of Brands and an outline of Brand Selection using Brand 10646 Lists, and 10648 o some XML examples of Brand Lists 10650 11.1 Brand Definitions and Brand Selection 10652 One of the key features of IOTP is the ability for a merchant to offer a 10653 list of Brands from which a consumer may make a selection. This section 10654 provides an overview of what is involved and provides guidance on how 10655 selection of a brand and associated payment instrument can be carried out 10656 by a Consumer. It covers: 10658 o definitions of Payment Instruments and Brands - what are Payment 10659 Instruments and Brands in an IOTP context. Further categorises Brands 10660 as optionally a "Dual Brand" or a "Promotional Brand", 10662 o identification and selection of Promotional Brands - Promotional Brands 10663 offer a Consumer some additional benefit, for example loyalty points or 10664 a discount. This means that both Consumers and Merchant must be able to 10665 correctly identify that a valid Promotional Brand is being used. 10667 Also see the following sections: 10669 o Brand List Component (section 7.7) which contains definitions of the 10670 XML elements which contain the list of Brands offered by a Merchant to 10671 a Consumer, and 10673 o Brand Selection Component (section 7.8) for details of how a Consumer 10674 records the Brand, currency, amount and payment protocol that was 10675 selected. 10677 11.1.1 Definition of Payment Instrument 10679 A Payment Instrument is the means by which a Consumer pays for goods or 10680 services offered by a Merchant. It can be, for example: 10682 o a credit card such as MasterCard or Visa; 10684 o a debit card such as MasterCard's Maestro; 10686 o a smart card based electronic cash payment instrument such as a Mondex 10687 Card, a GeldKarte card or a Visa Cash card 10689 o a software based electronic payment account such as a CyberCash or 10690 DigiCash account. 10692 All Payment Instruments have a number, typically an account number, by 10693 which the Payment Instrument can be identified. 10695 11.1.2 Definition of Brand 10697 A Brand is the mark which identifies a particular type of Payment 10698 Instrument. A list of Brands are the payment options which are presented 10699 by the Merchant to the Consumer and from which the Consumer makes a 10700 selection. Each Brand may have a different Payment Handler. Examples of 10701 Brands include: 10703 o payment association and proprietary Brands, for example MasterCard, 10704 Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. 10706 o promotional brands (see below). These include: 10707 - store brands, where the Payment Instrument is issued to a Consumer by 10708 a particular Merchant, for example Walmart, Sears, or Marks and 10709 Spencer (UK) 10710 - cobrands, for example American Advantage Visa, where an organisation 10711 uses their own brand in conjunction with, typically, a payment 10712 association Brand. 10714 11.1.3 Definition of Dual Brand 10716 A Dual Brand means that a single payment instrument may be used as if it 10717 were two separate Brands. For example there could be a single Japanese 10718 "UC" MasterCard which can be used as either a UC card or a regular 10719 MasterCard. The UC card Brand and the MasterCard Brand could each have 10720 their own separate Payment Handlers. This means that: 10722 o the merchant treats, for example "UC" and "MasterCard" as two separate 10723 Brands when offering a list of Brands to the Consumer, 10725 o the consumer chooses a Brand, for example either "UC" or "MasterCard, 10727 o the consumer IOTP aware application determines which Payment 10728 Instrument(s) match the chosen Brand, and selects, perhaps with user 10729 assistance, the correct Payment Instrument to use. 10731 [Note] Dual Brands need no special treatment by the Merchant and 10732 therefore no explicit reference is made to Dual Brands in the 10733 DTD. This is because, as far as the Merchant is concerned, 10734 each Brand in a Dual Brand is treated as a separate Brand. It 10735 is at the Consumer, that the matching of a Brand to a Dual 10736 Brand Payment Instrument needs to be done. 10737 [Note End] 10739 11.1.4 Definition of Promotional Brand 10741 A Promotional Brand means that, if the Consumer pays with that Brand, 10742 then the Consumer will receive some additional benefit which can be 10743 received in two ways: 10745 o at the time of purchase. For example if a Consumer pays with a "Walmart 10746 MasterCard" at a Walmart web site, then a 5% discount might apply, 10747 which means the consumer actually pays less, 10749 o from their Payment Instrument (card) issuer when the payment appears on 10750 their statement. For example loyalty points in a frequent flyer scheme 10751 could be awarded based on the total payments made with the Payment 10752 Instrument since the last statement was issued. 10754 Note that: 10756 o the first example (obtaining the benefit at the time of purchase), 10757 requires that: 10758 - the Consumer is informed of the benefits which arise if that Brand is 10759 selected 10760 - if the Brand is selected, the Merchant changes the relevant IOTP 10761 Components in the Offer Response to reflect the correct amount to be 10762 paid 10764 o the second (obtaining a benefit through the Payment Instrument issuer) 10765 does not require that the Offer Response is changed 10767 o each Promotional Brand should be identified as a separate Brand in the 10768 list of Brands offered by the Merchant. For example: "Walmart", 10769 "Sears", "Marks and Spencer" and "American Advantage Visa", would each 10770 be a separate Brand. 10772 11.1.5 Identifying Promotional Brands 10774 There are two problems which need to handled in identifying Promotional 10775 Brands: 10777 o how does the Merchant or their Payment Handler positively identify the 10778 promotional brand being used at the time of purchase 10780 o how does the Consumer reliably identify the correct promotional brand 10781 from the Brand List presented by the Merchant 10783 The following is a description of how this could be achieved. 10785 [Note] Please note that the approach described here is a model 10786 approach that solves the problem. Other equivalent methods may 10787 be used. 10788 [Note End] 10790 11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands 10792 Correct identification that the Consumer is paying using a Promotional 10793 Brand is important since a Consumer might fraudulently claim to have a 10794 Promotional Brand that offers a reduced payment amount when in reality 10795 they do not. 10797 Two approaches seem possible: 10799 o use some feature of the Payment Instrument or the payment method to 10800 positively identify the Brand being used. For example, the SET 10801 certificate for the Brand could be used, if one is available, or 10803 o use the Payment Instrument (card) number to look up information about 10804 the Payment Instrument on a Payment Instrument issuer database to 10805 determine if the Payment Instrument is a promotional brand. 10807 Note that: 10809 o the first assumes that SET is available. 10811 o the second is only possible if the Merchant, or alternatively the 10812 Payment Handler, has access to card issuer information. 10814 IOTP does not provide the Merchant with Payment Instrument information 10815 (e.g. a card or account number). This is only sent as part of the 10816 encapsulated payment protocol to a Payment Handler. This means that: 10818 o the Merchant would have to assume that the Payment Instrument selected 10819 was a valid Promotional Brand, or 10821 o the Payment Handler would have to check that the Payment Instrument was 10822 for the valid Promotional Brand and fail the payment if it was not. 10824 A Payment Handler checking that a brand is a valid Promotional Brand is 10825 most likely if the Payment Handler is also the Card Issuer. 10827 11.1.5.2 Consumer Selection of Promotional Brands 10829 Two ways by which a Consumer can correctly select a Promotional Brand 10830 are: 10832 o the Consumer visually matching a logo for the Promotional Brand which 10833 has been provided to the Consumer by the Merchant, 10835 o the Consumer's IOTP aware application matching a code for the 10836 Promotional Brand which the application has registered against a 10837 similar code contained in the list of Brands offered by the Merchant. 10839 In the latter case, the code contained in the Consumer wallet must match 10840 exactly the code in the list offered by the Merchant otherwise no match 10841 will be found. Ways in which the Consumer's IOTP Aware Application could 10842 obtain such a code include: 10844 o the Consumer types the code in directly. This is error prone and not 10845 user friendly, also the consumer needs to be provided with the code. 10846 This approach is not recommended, 10848 o using one of the Brand Identifiers defined by IOTP and pre-loaded into 10849 the Consumers IOTP Aware application or wallet by the developer of the 10850 Wallet, 10852 o using some information contained in the software or other data 10853 associated with the Payment Instrument. This could be: 10854 - a SET certificate for Brands which use this payment method 10855 - a code provided by the payment software which handles the particular 10856 payment method, this could apply to, for example, GeldKarte, Mondex, 10857 CyberCash and DigiCash, 10859 o the consumer making an initial "manual" link between a Promotional 10860 Brand in the list of Brands offered by the Merchant and an individual 10861 Payment Instrument, the first time the promotional brand is used. The 10862 IOTP Aware application would then "remember" the code for the 10863 Promotional Brand for use in future purchases. 10865 11.1.5.3 Consumer Software Brand Id recommendation 10867 New Brand Ids are allocated under IANA procedures (see section 12 IANA 10868 Considerations). Which also contains an initial list of Brand 10869 Identifiers. 10871 It is recommended that implementers of consumer IOTP aware applications 10872 (e.g. software wallets) pre-load their software with the then current set 10873 of Brand Ids and provide a method by which they can be updated. For 10874 example, by going to the software developer's web site. 10876 11.2 Brand List Examples 10878 This example contains three examples of the XML for a Brand List 10879 Component. It covers: 10881 o a simple credit card based example 10883 o a credit card based brand list including promotional credit card 10884 brands, and 10886 o a complex electronic cash based brand list 10888 Note that: 10890 o brand lists can be as complex or as simple as required 10892 o all example techniques described in this appendix can be included in 10893 one brand list. 10895 11.2.1 Simple Credit Card Based Example 10897 This is a simple example involving: 10899 o only major credit card payment brands 10901 o a single price in a single currency 10903 o a single Payment Handler, and 10905 o a single payment protocol 10907 10911 10916 10917 10922 10923 10928 10929 10932 10933 10936 10940 10941 10943 11.2.2 Credit Card Brand List Including Promotional Brands 10945 An example of a Credit Card based Brand List follows. It includes: 10947 o two ordinary card association brands and two promotional credit card 10948 brands. The promotional brands consist of one loyalty based (British 10949 Airways MasterCard) which offers additional loyalty points and one 10950 store based (Walmart) which offers a discount on purchases over a 10951 certain amount 10953 o two payment protocols: 10954 - SET (Secure Electronic Transactions) see [SET], and 10955 - SCCD (Secure Channel Credit Debit) see [SCCD]. 10957 10961 10966 10967 10968 10969 10974 10975 10976 10977 10983 10984 10985 10986 10993 10994 10997 10998 238djqw1298erh18dhoire 10999 11000 11001 11004 11005 238djqw1298erh18dhoire 11006 11007 11008 11011 11015 11016 8ueu26e482hd82he82 11017 11018 11019 11023 11024 82hd82he8226e48ueu 11025 11026 11027 11029 11.2.3 Brand Selection Example 11031 In order to pay by 'British Airways' MasterCard using the example above 11032 using SET and therefore getting double air miles, the Brand Selection 11033 would be: 11035 11040 11042 11.2.4 Complex Electronic Cash Based Brand List 11044 The following is an fairly complex example which includes: 11046 o payments using either Mondex, GeldKarte, CyberCash or DigiCash 11047 o in currencies including US dollars, British Pounds, Italian Lira, 11048 German Marks and Canadian Dollars 11050 o a discount on the price if the payment is made in Mondex using British 11051 pounds or US dollars, and 11053 o more than one Payment Handler is used for payments involving Mondex or 11054 CyberCash 11056 o support for more than one version of a CyberCash CyberCoin payment 11057 protocol. 11059 11063 11068 11069 11074 11075 11080 11081 11088 11089 11092 11093 11096 11097 11100 11101 11104 11105 11108 11109 11112 11115 11118 11121 11124 11127 11130 11133 11137 11138 11142 11143 11147 11148 11152 11153 11157 11158 11162 11163 11165 12. IANA Considerations 11167 This section describes the codes that are controlled by IANA, and also 11168 how new codes can be created for testing purposes that are not controlled 11169 by IANA. 11171 12.1 Codes Controlled by IANA 11173 To help ensure interoperability, there is a need for codes used by IOTP 11174 to be maintained in a controlled environment so that their meaning and 11175 usage are well defined and duplicate codes avoided. [IANA] is the 11176 mechanism to be used for this purpose as described in RFC 2434. 11178 The element types and attributes names to which this procedure applies is 11179 shown in the table below together with the initial values that are valid 11180 for these attributes. 11182 Note that: 11184 o the IETF Trade mailing list's email address is ietf-trade@elistx.com 11186 o "Designated Experts" (see [IANA]) are appointed by the IESG. 11188 Element Type/ Attribute Values 11189 Attribute Name 11191 Algorithm/ "sha1" - indicates that a [SHA1] authentication 11192 Name will apply 11193 (When Algorithm 11194 is a child of an "signature" - indicates that authentication 11195 AuthReq consists of the generation of a digital signature. 11196 Component) 11197 "Pay:ppp" where "ppp" may be set to any valid 11198 value for "iotpbrand" (see below) 11200 With the exception of Algorithms that begin with 11201 "pay:", new values are allocated following review 11202 on the IETF Trade mailing list and by the 11203 Designated Expert. 11205 [Note] The Algorithm element is likely to be 11206 eventually defined within the [DSIG] 11207 name space. It is likely that the 11208 maintenance procedure defined here 11209 may need to vary over time, as the 11210 DSIG proposals become more widely 11211 adopted. 11212 [Note End] 11214 Element Type/ Attribute Values 11215 Attribute Name 11217 Brand/BrandId The following list of initial BrandIds have been 11218 taken from those organisations that have applied 11219 for SET certificates as at 1st June 1999: 11221 "Amex" - American Express 11223 "Dankort" - Dankort 11225 "JCB" - JCB 11227 "Maestro" - Maestro 11229 "MasterCard" - MasterCard 11231 "NICOS" - NICOS 11233 "VISA" - Visa 11235 In addition the following Brand Id values are 11236 defined: 11238 "Mondex" 11240 "GeldKarte" 11242 New values of BrandId must be announced to the 11243 IETF Trade mailing list and, if there are no 11244 objections within three weeks, are allocated on a 11245 "first come first served" basis. 11247 CurrencyAmount/ Currency codes are dependent on CurrCodeType (see 11248 CurrCode below). 11250 If CurrCodeType is "ISO4217-A" then the currency 11251 code is an alphabetic currency code as defined by 11252 [ISO4217]. 11254 If CurrCodeType is "IOTP" then new values must be 11255 announced to the IETF Trade mailing list and, if 11256 there are no objections within three weeks, are 11257 allocated on a "first come first served" basis. 11259 [Note] The Currency Code Type of IOTP, is 11260 designed to allow the support of 11261 "new" psuedo currencies such as 11262 loyalty or frequent flyer points. At 11263 the time of writing this 11264 specification, no currency codes of 11265 this type have been defined. 11266 [Note End] 11268 Element Type/ Attribute Values 11269 Attribute Name 11271 CurrencyAmount/ "ISO4217-A" 11272 CurrCodeType 11273 "IOTP" 11275 New values of CurrCodeType attribute are allocated 11276 following review on the IETF Trade mailing list 11277 and by the Designated Expert. 11279 DeliveryData/ "Post" 11280 DelivMethod 11281 "Web" 11283 "Email" 11285 New values of Delivery Method attribute are 11286 allocated following review on the IETF Trade 11287 mailing list and by the Designated Expert. This 11288 may require the publication of additional 11289 documentation to describe how the delivery method 11290 is used. 11292 PackagedContent/ "PCDATA" 11293 Content 11294 "MIME" 11296 "MIME:mimetype" (where mimetype must be the same 11297 as content-type as defined by [MIME] ) 11299 "XML" 11301 If the Content attribute is of the form 11302 "MIME"mimetype", then control of new values for 11303 "mimetype" is as defined in [MIME]. 11305 Otherwise, new values of the Content attribute are 11306 allocated following review on the IETF Trade 11307 mailing list and by the Designated Expert. This 11308 may require the publication of additional 11309 documentation to describe how the new attribute is 11310 used within a Packaged Content element. 11312 RelatedTo/ "IotpTransaction" 11313 RelationshipType 11314 "Reference" 11316 New values of the RelationshipType attribute are 11317 allocated following review on the IETF Trade 11318 Working Group mailing list and by the Designated 11319 Expert. This may require the publication of 11320 additional documentation to describe how the 11322 Element Type/ Attribute Values 11323 Attribute Name 11324 delivery method is used. 11326 Status/ Offer 11327 StatusType 11328 Payment 11330 Delivery 11332 Authentication 11334 Unidentified 11336 New values of the Status Type attribute are 11337 allocated following: 11338 o publication to the IETF Trade Working Group, 11339 of an RFC describing the Trading Exchange, 11340 Trading Roles and associated components that 11341 relate to the Status, and 11342 o review of the document on the IETF Trade 11343 mailing list and by the Designated Expert. 11345 [Note] The document describing new values 11346 for the Status Type attribute may be 11347 combined with documents that describe 11348 new Trading Roles and types of 11349 signatures (see below). 11350 [Note End] 11352 TradingRole/ "Consumer" 11353 TradingRole 11354 "Merchant" 11356 "PaymentHandler" 11358 "DeliveryHandler" 11360 "DelivTo" 11362 "CustCare" 11364 New values of the Trading Role attribute are 11365 allocated following: 11366 o publication to the IETF Trade Working Group, 11367 of an RFC describing the Trading Exchange, 11368 Trading Roles and associated components that 11369 relate to the Trading Role, and 11370 o review of the document on the IETF Trade 11371 mailing list and by the Designated Expert. 11373 [Note] The document describing new values 11374 for the Trading Role attribute may be 11376 Element Type/ Attribute Values 11377 Attribute Name 11378 combined with documents that describe 11379 new Status Types (see above) and 11380 types of signatures (see below). 11381 [Note End] 11383 TransId/ "BaselineAuthentication" 11384 IotpTransType 11385 "BaselineDeposit" 11387 "BaselinePurchase" 11389 "BaselineRefund" 11391 "BaselineWithdrawal" 11393 "BaselineValueExchange" 11395 "BaselineInquiry" 11397 "BaselinePing" 11399 New values of the IotpTransType attribute are 11400 allocated following: 11401 o publication to the IETF Trade mailing list, of 11402 an RFC describing the new IOTP Transaction, and 11403 o review of the document on the IETF Trade 11404 Working Group mailing list and by the 11405 Designated Expert. 11407 Attibute/ Content 11408 (see Signature "OfferResponse" 11409 Component) "PaymentResponse" 11411 "DeliveryResponse" 11413 "AuthenticationRequest" 11415 "AuthenticationResponse" 11417 "PingRequest" 11419 "PingResponse" 11421 New values of the code that define the type of a 11422 signature are allocated following: 11423 o publication to the IETF Trade Working Group, 11424 of an RFC describing the Trading Exchange where 11425 the signature is being used, and 11426 o review of the document on the IETF Trade 11427 mailing list and by the Designated Expert. 11429 Element Type/ Attribute Values 11430 Attribute Name 11432 [Note] The document describing new values 11433 for the types of signatures may be 11434 combined with documents that describe 11435 new Status Types and Trading Roles 11436 (see above). 11437 [Note End] 11439 12.2 Codes not controlled by IANA 11441 In addition to the formal development and registration of codes as 11442 described above, there is still a need for developers to experiment using 11443 new IOTP codes. For this reason, "user defined codes" may be used to 11444 identify additional values for the codes contained within this 11445 specification without the need for them to be registered with IANA. 11447 The definition of a user defined code is as follows: 11449 user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)* 11451 NameChar NameChar has the same definition as the [XML] 11452 definition of NameChar 11454 Use of domain names (see [DNS]) to make user defined codes unique is 11455 recommended although this method cannot be relied upon. 11457 13. Internet Open Trading Protocol Data Type Definition 11459 This section contains the XML DTD for the Internet Open Trading 11460 Protocols. 11462 11495 11517 11521 11527 11528 11531 11532 11539 11540 11550 11551 11558 11564 11565 11570 11575 11576 11577 11585 11586 11587 11592 11593 11594 11600 11601 11602 11606 11607 11608 11618 11619 11621 11629 11630 11638 11639 11646 11647 11654 11655 11665 11666 11668 11674 11675 11685 11686 11690 11691 11697 11698 11704 11705 11715 11716 11719 11726 11727 11731 11732 11736 11737 11741 11742 11743 11751 11752 11753 11760 11761 11762 11768 11769 11770 11774 11775 11776 11783 11784 11794 11795 11796 11800 11801 11802 11808 11809 11810 11821 11822 11823 11828 11829 11830 11836 11837 11838 11847 11848 11856 11862 11863 11864 11867 11868 11869 11872 11873 11875 11878 11879 11880 11883 11884 11885 11888 11889 11890 11893 11894 11896 11899 11900 11901 11904 11905 11907 11910 11911 11913 11916 11917 11918 11921 11922 11923 11926 11927 11928 11933 11934 11935 11938 11939 11940 11947 11948 11949 11952 11953 11954 11957 11963 11964 11968 11974 11975 11979 11988 11992 11993 11998 11999 12003 12004 12009 12010 12014 12015 12022 12023 12027 12033 12037 12042 12043 12048 12053 12054 12059 12060 12065 14. Glossary 12067 This section contains a glossary of some of the terms used within this 12068 specification in alphabetical order. 12070 NAME DESCRIPTION 12072 Authenticator The Organisation which is requesting the 12073 authentication of another Organisation, and 12075 Authenticatee The Organisation being authenticated by an 12076 Authenticator 12078 Business Error See Status Component. 12080 Brand A Brand is the mark which identifies a particular 12081 type of Payment Instrument. A list of Brands are 12082 the payment options which are presented by the 12083 Merchant to the Consumer and from which the 12084 Consumer makes a selection. Each Brand may have a 12085 different Payment Handler. Examples of Brands 12086 include: 12087 o payment association and proprietary Brands, 12088 for example MasterCard, Visa, American Express, 12089 Diners Club, American Express, Mondex, 12090 GeldKarte, CyberCash, etc. 12091 o Promotional Brands (see below). These include: 12092 o store Brands, where the Payment Instrument is 12093 issued to a Consumer by a particular Merchant, 12094 for example Walmart, Sears, or Marks and 12095 Spencer (UK) 12096 o coBrands, for example American Advantage Visa, 12097 where an a company uses their own Brand in 12098 conjunction with, typically, a payment 12099 association Brand. 12101 Consumer The Organisation which is to receive the benefit 12102 of and typically pay for the goods or services. 12104 ContentSoftwareId This contains information which identifies the 12105 software which generated the content of the 12106 element. Its purpose is to help resolve 12107 interoperability problems that might occur as a 12108 result of incompatibilities between messages 12109 produced by different software. It is a single 12110 text string in the language defined by xml:lang. 12111 It must contain, as a minimum: 12112 o the name of the software manufacturer 12113 o the name of the software 12114 o the version of the software, and 12115 o the build of the software 12117 NAME DESCRIPTION 12119 It is recommended that this attribute is included 12120 whenever the software which generated the content 12121 cannot be identified from the SoftwareId attribute 12122 on the Message Id Component (see section 3.3.2) 12124 Customer Care An Organisation that is providing customer care 12125 Provider typically on behalf of a Merchant. Examples of 12126 customer care include, responding to problems 12127 raised by a Consumer arising from an IOTP 12128 Transaction that the Consumer took part in. 12130 Delivery Handler The Organisation that directly delivers the goods 12131 or services to the Consumer on behalf of the 12132 Merchant. Delivery can be in the form of either 12133 digital goods (e.g. a [MIME] message), or 12134 physically delivered using the post or a courier. 12136 Document Exchange A Document Exchange consists of a set of IOTP 12137 Messages exchanged between two parties that 12138 implement part or all of two Trading Exchanges 12139 simultaneously in order to minimise the number of 12140 actual IOTP Messages which must be sent over the 12141 Internet. 12143 Document Exchanges are combined together in 12144 sequence to implement a particular IOTP 12145 Transaction. 12147 Dual Brand A Dual Brand means that a single Payment 12148 Instrument may be used as if it were two separate 12149 Brands. For example there could be a single 12150 Japanese "UC" MasterCard which can be used as 12151 either a UC card or a regular MasterCard. The UC 12152 card Brand and the MasterCard Brand could each 12153 have their own separate Payment Handlers. This 12154 means that: 12155 o the Merchant treats, for example "UC" and 12156 "MasterCard" as two separate Brands when 12157 offering a list of Brands to the Consumer, 12158 o the Consumer chooses a Brand, for example 12159 either "UC" or "MasterCard, 12160 o the Consumer IOTP aware application determines 12161 which Payment Instrument(s) match the chosen 12162 Brand, and selects, perhaps with user 12163 assistance, the correct Payment Instrument to 12164 use. 12166 Error Block An Error Block reports that a Technical Error was 12167 found in an IOTP Message that was previously 12168 received. Typically Technical Errors are caused by 12169 errors in the XML which has been received or some 12171 NAME DESCRIPTION 12172 technical failure of the processing of the IOTP 12173 Message. Frequently the generation or receipt of 12174 an Error Block will result in failure of the IOTP 12175 Transaction. They are distinct from Business 12176 Errors, reported in a Status Component, which can 12177 also cause failure of an IOTP Transaction. 12179 Exchange Block An Exchange Block is sent between the two Trading 12180 Roles involved in a Trading Exchange. It contains 12181 one or more Trading Components. Exchange Blocks 12182 are always sent after a Request Block and before a 12183 Response Block in a Trading Exchange. The content 12184 of an Exchange Block is dependent on the type of 12185 Trading Exchange being carried out. 12187 IOTP Message An IOTP Message is the outermost wrapper for the 12188 document(s) which are sent between Trading Roles 12189 that are taking part in a trade. It is a well 12190 formed XML document. The documents it contains 12191 consist of: 12192 o a Transaction Reference Block to uniquely 12193 identify the IOTP Transaction of which the IOTP 12194 Message is part, 12195 o an optional Signature Block to digitally sign 12196 the Trading Blocks or Trading Components 12197 associated with the IOTP Transaction 12198 o an optional Error Block to report on technical 12199 errors contained in a previously received IOTP 12200 Message, and 12201 o a collection of IOTP Trading Blocks which 12202 carries the data required to carry out an IOTP 12203 Transaction. 12205 IOTP Transaction An instance of an Internet Open Trading Protocol 12206 Transaction consists of a set of IOTP Messages 12207 transferred between Trading Roles. The rules for 12208 what may be contained in the IOTP Messages is 12209 defined by the Transaction Type of the IOTP 12210 Transaction. 12212 IOTP Transaction A Transaction Type identifies the type an of IOTP 12213 Type Transaction. Examples of Transaction Type include: 12214 Purchase, Refund, Authentication, Withdrawal, 12215 Deposit (of electronic cash). The Transaction Type 12216 specifies for an IOTP Transaction: 12217 o the Trading Exchanges which may be included in 12218 the transaction, 12219 o how those Trading Exchanges may be combined to 12220 meet the business needs of the transaction 12221 o which Trading Blocks may be included in the 12222 IOTP Messages that make up the transaction 12223 o Consult this specification for the rules that 12225 NAME DESCRIPTION 12226 apply for each Transaction Type. 12228 Merchant The Organisation from whom the service or goods 12229 are being obtained, who is legally responsible for 12230 providing the goods or services and receives the 12231 benefit of any payment made 12233 Merchant Customer The Organisation that is involved with customer 12234 Care Provider dispute negotiation and resolution on behalf of 12235 the Merchant 12237 Organisation A company or individual that takes part in a Trade 12238 as a Trading Role. The organisations may take one 12239 or more of the roles involved in the Trade 12241 Payment Handler The Organisation that physically receives the 12242 payment from the Consumer on behalf of the 12243 Merchant 12245 Payment A Payment Instrument is the means by which 12246 Instrument Consumer pays for goods or services offered by a 12247 Merchant. It can be, for example: 12248 o a credit card such as MasterCard or Visa; 12249 o a debit card such as MasterCard's Maestro; 12250 o a smart card based electronic cash Payment 12251 Instrument such as a Mondex Card, a GeldKarte 12252 card or a Visa Cash card 12253 o a software based electronic payment account 12254 such as a CyberCash's CyberCoin or DigiCash 12255 account. 12257 All Payment Instruments have a number, typically 12258 an account number, by which the Payment Instrument 12259 can be identified. 12261 Promotional Brand A Promotional Brand means that, if the Consumer 12262 pays with that Brand, then the Consumer will 12263 receive some additional benefit which can be 12264 received in two ways: 12265 o at the time of purchase. For example if a 12266 Consumer pays with a "Walmart MasterCard" at a 12267 Walmart web site, then a 5% discount might 12268 apply, which means the Consumer actually pays 12269 less, 12270 o from their Payment Instrument (card) issuer 12271 when the payment appears on their statement. 12272 For example loyalty points in a frequent flyer 12273 scheme could be awarded based on the total 12274 payments made with the Payment Instrument since 12275 the last statement was issued. 12277 Each Promotional Brand should be identified as a 12279 NAME DESCRIPTION 12280 separate Brand in the list of Brands offered by 12281 the Merchant. 12283 Receipt Component A Receipt Component is a record of the successful 12284 completion of a Trading Exchange. Examples of 12285 Receipt Components include: Payment Receipts, and 12286 Delivery Notes. It's content may dependent on the 12287 technology used to perform the Trading Exchange. 12288 For example a Secure Electronic Transaction (SET) 12289 payment receipt consists of SET payment messages 12290 which record the result of the payment. 12292 Request Block A Request Block is Trading Block that contains a 12293 request for a Trading Exchange to start. The 12294 Trading Components in a Request Block may be 12295 signed by a Signature Block so that their 12296 authenticity may be checked and to determine that 12297 the Trading Exchange being requested is 12298 authorised. Authorisation for a Trading Exchange 12299 to start can be provided by the signatures 12300 contained on Receipt Components contained in 12301 Response Blocks resulting from previously 12302 completed Trading Exchanges. Examples of Request 12303 Blocks are Payment Request and Delivery Request 12305 Response Block A Response Block is a Trading Block that indicates 12306 that a Trading Exchange is complete. It is sent by 12307 the Trading Role that received a Request Block to 12308 the Trading Role that sent the Request Block. The 12309 Response Block contains a Status Component that 12310 contains information about the completion of the 12311 Trading Exchange, for example it indicates whether 12312 or not the Trading Exchange completed 12313 successfully. For some Trading Exchanges the 12314 Response Block contains a Receipt Component that 12315 forms a record of the Trading Exchange. Receipt 12316 Components may be digitally signed using a 12317 Signature Block to make completion non-refutable. 12318 Examples of Response Blocks include Offer 12319 Response, Payment Response and Delivery Response. 12321 Signature Block A Signature Block is a Trading Block that contains 12322 one or more digital signatures in the form of 12323 Signature Components. A Signature Component may 12324 digitally sign any Block or Component in any IOTP 12325 Message in the same IOTP Transaction. 12327 Status Component A Status Component contains information that 12328 describes the state of a Trading Exchange. 12330 Before the Trading Exchange is complete the Status 12331 Component can indicate information about how the 12333 NAME DESCRIPTION 12334 Trading Exchange is progressing. 12336 Once a Trading Exchange is complete the Status 12337 Component can only indicate the success of the 12338 Trading Exchange or that a Business Error has 12339 occurred. 12341 A Business Error indicates that continuation with 12342 the Trading Exchange was not possible because of 12343 some business rule or logic, for example, 12344 "insufficient funds available", rather than any 12345 Technical Error associated with the content or 12346 format of the IOTP Messages in the IOTP 12347 Transaction. 12349 Technical Error See Error Block. 12351 Trading Block A Trading Block consists of one or more Trading 12352 Components. One or more Trading Blocks may be 12353 contained within the IOTP Messages which are 12354 physically sent in the form of [XML] documents 12355 between the different Trading Roles that are 12356 taking part in a trade. Trading Blocks are of 12357 three main types: 12358 o a Request Block, 12359 o an Exchange Block, or a 12360 o a Response Block 12362 Trading Component A Trading Component is a collection of XML 12363 elements and attributes. Trading Components are 12364 the child elements of the Trading Blocks. Examples 12365 of Trading Components are: Offer, Brand List, 12366 Payment Receipt, Delivery [information], Payment 12367 Amount [information] 12369 Trading Exchange A Trading Exchange consists of the exchange, 12370 between two Trading Roles, of a sequence of 12371 documents. The documents may be in the form of 12372 Trading Blocks or they may be transferred by some 12373 other means, for example through entering data 12374 into a web page. Each Trading Exchange consists of 12375 three main parts: 12376 o the sending of a Request Block by one Trading 12377 Role (the initiator) to another Trading Role 12378 (the recipient), 12379 o the optional exchange of one or more Exchange 12380 Blocks between the recipient and the initiator, 12381 until eventually, 12382 o the Trading Role that received the Request 12383 Block sends a Response Block to the initiator. 12385 A Trading Exchange is designed to implement a 12387 NAME DESCRIPTION 12388 useful service of some kind. Examples of Trading 12389 Exchanges/services are: 12390 o Offer, which results in a Consumer receiving 12391 an offer from a Merchant to carry out a 12392 business transaction of some kind, 12393 o Payment, where a Consumer makes a payment to a 12394 Payment Handler, 12395 o Delivery, where a Consumer requests, and 12396 optionally obtains, delivery of goods or 12397 services from a Delivery Handler, and 12398 o Authentication, where any Trading Role may 12399 request and receive information about another 12400 Trading Role. 12402 Trading Role A Trading Role identifies the different ways in 12403 which organisations can participate in a trade. 12404 There are five Trading Roles: Consumer, Merchant, 12405 Payment Handler, Delivery Handler, and Merchant 12406 Customer Care Provider. 12408 Transaction A Transaction Reference Block identifies an IOTP 12409 Reference Block Transaction. It contains data that identifies: 12410 o the Transaction Type, 12411 o the IOTP Transaction uniquely, through a 12412 globally unique transaction identifier 12413 o the IOTP Message uniquely within the IOTP 12414 Transaction, through a message identifier 12416 The Transaction Reference Block may also contain 12417 references to other transactions which may or may 12418 not be IOTP Transactions 12420 15. Copyrights 12422 Copyright (C) The Internet Society (1998). All Rights Reserved. 12424 This document and translations of it may be copied and furnished to 12425 others, and derivative works that comment on or otherwise explain it or 12426 assist in its implementation may be prepared, copied, published and 12427 distributed, in whole or in part, without restriction of any kind, 12428 provided that the above copyright notice and this paragraph are included 12429 on all such copies and derivative works. However, this document itself 12430 may not be modified in any way, such as by removing the copyright notice 12431 or references to the Internet Society or other Internet organisations, 12432 except as needed for the purpose of developing Internet standards in 12433 which case the procedures for copyrights defined in the Internet 12434 Standards process must be followed, or as required to translate it into 12435 languages other than English. 12437 The limited permissions granted above are perpetual and will not be 12438 revoked by the Internet Society or its successors or assigns. 12440 This document and the information contained herein is provided on an AS 12441 IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 12442 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 12443 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 12444 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 12445 PARTICULAR PURPOSE. 12447 16. References 12449 This section contains references to related documents identified in this 12450 specification. 12452 [Base64] Base64 Content-Transfer-Encoding. A method of 12453 transporting binary data defined by MIME. See: RFC 2045: 12454 Multipurpose Internet Mail Extensions (MIME) Part One: 12455 Format of Internet Message Bodies. N. Freed & N. 12456 Borenstein. November 1996. 12458 [DOM-HASH] A method for generating hashes of all or part of an XML 12459 tree based on the DOM of that tree. See 12460 . 12463 [DNS] See RFC 1034: Domain names - concepts and facilities. 12464 P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names 12465 - implementation and specification. P.V. Mockapetris. 12466 Nov-01-1987. 12468 [DSA] The Digital Signature Algorithm (DSA) published by the 12469 National Institute of Standards and Technology (NIST) in 12470 the Digital Signature Standard (DSS), which is a part of 12471 the US government's Capstone project. 12473 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm 12474 (ECCDSA). Elliptic curve cryptosystems are analogues of 12475 public-key cryptosystems such as RSA in which modular 12476 multiplication is replaced by the elliptic curve addition 12477 operation. See: V. S. Miller. Use of elliptic curves in 12478 cryptography. In Advances in Cryptology - Crypto '85, 12479 pages 417-426, Springer-Verlag, 1986. 12481 [HMAC] See RFC 2104 HMAC: Keyed-Hashing for Message 12482 Authentication. H. Krawczyk, M. Bellare, R. Canetti. 12483 February 1997 12485 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up 12486 Language (HTML) is a simple mark-up language used to 12487 create hypertext documents that are platform independent. 12488 See RFC 1866 and the World Wide Web (W3C) consortium web 12489 site at: http://www.w3.org/MarkUp/ 12491 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 12492 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 12493 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 12494 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 12495 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 12496 Lee. January 1997. 12498 [IANA] The Internet Assigned Numbers Authority. The organisation 12499 responsible for co-ordinating the names and numbers 12500 associated with the Internet. See http://www.iana.org/. 12502 [ISO4217] ISO 4217: Codes for the Representation of Currencies. 12503 Available from ANSI or ISO. 12505 [IOTPDSIG] A document that describes how data contained in IOTP 12506 messages may be digitally signed. See RFC xxxx 12507 http://www.ietf.org/internet-drafts/draft-ietf-trade- 12508 iotp-v1.0-dsig-*.txt. 12510 [MD5] R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. 12512 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 12513 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 12515 [OPS] Open Profiling Standard. A proposed standard which 12516 provides a framework with built-in privacy safeguards for 12517 the trusted exchange of profile information between 12518 individuals and web sites. Being developed by Netscape 12519 and Microsoft amongst others. 12521 [RFC822] See RFC 822: The Standard for the Format of ARPA Internet 12522 Messages. 13 August 1982, David H Crocker. 13 August 12523 1982. 12525 [RFC1738] See RFC 1738: Uniform Resource Locators (URL), ed. T. 12526 Berners-Lee, L. Masinter, M. McCahill. 1994. 12528 [RFC2434] See RFC 2434. Guidelines for Writing an IANA 12529 Considerations Section in RFCs. T. Narten and H. 12530 Alvestrand 12532 [RSA] RSA is a public-key cryptosystem for both encryption and 12533 authentication supported by RSA Data Security Inc. See: 12534 R. L. Rivest, A. Shamir, and L.M. Adleman. A method for 12535 obtaining digital signatures and public-key 12536 cryptosystems. Communications of the ACM, 21(2): 120-126, 12537 February 1978. 12539 [SCCD] Secure Channel Credit Debit. A method of conducting a 12540 credit or debit card payment where unauthorised access to 12541 account information is prevented through use of secure 12542 channel transport mechanisms such as SSL/TLS. An IOTP 12543 supplement describing how SCCD works is under 12544 development. 12546 [SET] Secure Electronic Transaction Specification, Version 1.0, 12547 May 31, 1997. Supports credit and debit card payments 12548 using certificates at the Consumer and Merchant to help 12549 ensure authenticity. 12550 Download from: . 12552 [SSL/TLS] SSL is a standard developed by Netscape for encrypting 12553 data over IP networks. See 12554 http://home.netscape.com/eng/ssl3/index.html. TLS is the 12555 likely successor to SSL being developed by the IETF. See 12556 http://www.ietf.org/internet-drafts/draft-ietf-tls- 12557 protocol-05.txt 12559 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of 12560 Standards and Technology, US Department Of Commerce, 12561 April 1995. Also known as: 59 Fed Reg. 35317 (1994). See 12562 http://www.itl.nist.gov/div897/pubs/fip180-1.htm 12564 [UTC] Universal Time Co-ordinated. A method of defining time 12565 absolutely relative to Greenwich Mean Time (GMT). 12566 Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" 12567 where the "+n" defines the number of hours from GMT. See 12568 ISO DIS8601. 12570 [UTF16] The Unicode Standard, Version 2.0. The Unicode 12571 Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 12572 Proposed Draft Amendment 1 12574 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, 12575 Including Draft Amendment 1: Certificate Extensions 12576 (Version 3 Certificate) 12578 [XML Recommendation for Namespaces in XML, World Wide Web 12579 Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- 12580 xml-names" 12582 [XML] Extensible Mark Up Language. A W3C recommendation. See 12583 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 12584 February 1998 version. 12586 17. Author's Address 12588 The author of this document is: 12590 David Burdett 12591 Commerce One 12592 1600 Riviera Ave, Suite 200 12593 Walnut Creek 12594 California 94596 12595 USA 12597 Tel: +1 (925) 941 4422 12599 Email: david.burdett@commerceone.com 12601 The author of this document particularly wants to thank Mondex 12602 International Limited (www.mondex.com) for the tremendous support 12603 provided in the formative stages of the development of this 12604 specification. 12606 In addition the author appreciates the following contributors to this 12607 protocol (in alphabetic order of company) without which it could not have 12608 been developed. 12609 - Phillip Mullarkey, British Telecom plc 12610 - Andrew Marchewka, Canadian Imperial Bank of Commerce 12611 - Brian Boesch, CyberCash Inc. 12612 - Tom Arnold, CyberSource 12613 - Terry Allen, Commerce One (formally Veo Systems) 12614 - Richard Brown, GlobeSet Inc. 12615 - Peter Chang, Hewlett Packard 12616 - Masaaki Hiroya, Hitachi Ltd 12617 - Yoshiaki Kawatsura, Hitachi Ltd 12618 - Donald Eastlake 3rd, International Business Machines (formerly 12619 CyberCash Inc). 12620 - Mark Linehan, International Business Machines 12621 - Jonathan Sowler, JCP Computer Services Ltd 12622 - John Wankmueller, MasterCard International 12623 - Steve Fabes, Mondex International Ltd 12624 - Surendra Reddy, Oracle Corporation 12625 - Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) 12626 - Chris Smith, Royal Bank of Canada 12627 - Hans Bernhard-Beykirch, SIZ (IT Development and Coordination Centre 12628 of the German Savings Banks Organisation) 12629 - W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, 12630 formally AT&T Universal Card Services) 12631 - Efrem Lipkin, Sun Microsystems 12632 - Tony Lewis, Visa International 12634 The author would also like to thank the following organisations for their 12635 support: 12636 - Amino Communications 12637 - DigiCash 12638 - Fujitsu 12639 - General Information Systems 12640 - Globe Id Software 12641 - Hyperion 12642 - InterTrader 12643 - Nobil I T Corp 12644 - Mercantec 12645 - Netscape 12646 - Nippon Telegraph and Telephone Corporation 12647 - Oracle Corporation 12648 - Smart Card Integrations Ltd. 12649 - Spyrus 12650 - Verifone 12651 - Unisource nv 12652 - Wells Fargo Bank 12654 File name: draft-ietf-trade-iotp-v1.0-protocol-05.txt 12655 Expires: February 2000