idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-06.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-06', 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 253 longer pages, the longest (page 198) 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 868 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 11505: '... * 4. Changed REQUIRED to IMPLIED on D...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1024 has weird spacing: '...s to be forwa...' == Line 1580 has weird spacing: '...RespBlk and...' == Line 3527 has weird spacing: '...Request any ...' == Line 3529 has weird spacing: '...esponse any r...' == Line 5213 has weird spacing: '...untInfo bran...' == (8 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 (September 1999) is 8983 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 1673, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'Note' is mentioned on line 11460, but not defined == Missing Reference: 'ISO 4217' is mentioned on line 5057, but not defined == Missing Reference: 'SSL' is mentioned on line 10393, but not defined == Missing Reference: 'DSIG' is mentioned on line 11234, but not defined == Unused Reference: 'Base64' is defined on line 12487, but no explicit reference was found in the text == Unused Reference: 'ECCDSA' is defined on line 12508, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 12526, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 12563, but no explicit reference was found in the text == Unused Reference: 'UTF16' is defined on line 12605, 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: 16 errors (**), 0 flaws (~~), 23 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft. David Burdett 2 Commerce One 3 draft-ietf-trade-iotp-v1.0-protocol-06.txt September 1999 4 Expires: March 2000 6 Internet Open Trading Protocol - IOTP 7 Version 1.0 9 Status of this Memo 11 This document, filename draft-ietf-trade-iotp-v1.0-protocol-06.txt, is 12 the main specification of the Internet Open Trading Protocol version 1.0 13 and is intended to become an Informational RFC. Distribution of this 14 document is unlimited. Comments should be sent to the TRADE working group 15 at . 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months and 24 may be updated, replaced, or obsoleted by other documents at any time. 25 It is inappropriate to use Internet-Drafts as reference material or to 26 cite them other than as "work in progress." 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Discussions of the TRADE working group are archived at 32 http://www.elistx.com/archives/ietf-trade. 34 Abstract 36 The Internet Open Trading Protocol (IOTP) provides an interoperable 37 framework for Internet commerce. It is payment system independent and 38 encapsulates payment systems such as SET, Secure Channel Credit/Debit, 39 Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where 40 such merchant roles as the shopping site, the Payment Handler, the 41 Delivery Handler of goods or services, and the provider of customer 42 support are performed by different parties or by one party. 44 This document obsoletes the previous version of the IOTP specification 45 (draft-ietf-trade-iotp-v1.0-protocol-04.txt.) 47 Table of Contents 49 Status of this Memo ................................................1 51 Abstract ...........................................................1 53 1. Background .....................................................8 54 1.1 Commerce on the Internet, a Different Model .................8 55 1.2 Benefits of IOTP ............................................9 56 1.3 Baseline IOTP ..............................................11 57 1.4 Objectives of Document .....................................11 58 1.5 Scope of Document ..........................................11 59 1.6 Document Structure .........................................12 60 1.7 Intended Readership ........................................13 61 1.7.1 Reading Guidelines ...................................13 63 2. Introduction ..................................................15 64 2.1 Trading Roles ..............................................15 65 2.2 Trading Exchanges ..........................................17 66 2.2.1 Offer Exchange .......................................18 67 2.2.2 Payment Exchange .....................................20 68 2.2.3 Delivery Exchange ....................................22 69 2.2.4 Authentication Exchange ..............................24 70 2.3 Scope of Baseline IOTP .....................................26 72 3. Protocol Structure ............................................29 73 3.1 Overview ...................................................30 74 3.1.1 IOTP Message Structure ...............................30 75 3.1.2 IOTP Transactions ....................................31 76 3.2 IOTP Message ...............................................32 77 3.2.1 XML Document Prolog ..................................33 78 3.3 Transaction Reference Block ................................34 79 3.3.1 Transaction Id Component .............................34 80 3.3.2 Message Id Component .................................36 81 3.3.3 Related To Component .................................37 82 3.4 ID Attributes ..............................................39 83 3.4.1 IOTP Message ID Attribute Definition .................39 84 3.4.2 Block and Component ID Attribute Definitions .........40 85 3.4.3 Example of use of ID Attributes ......................41 86 3.5 Element References .........................................42 87 3.6 Extending IOTP .............................................43 88 3.6.1 Extra XML Elements ...................................44 89 3.6.2 Opaque Embedded Data .................................45 90 3.7 Packaged Content Element ...................................45 91 3.7.1 Packaging HTML .......................................47 92 3.7.2 Packaging XML ........................................48 93 3.8 Identifying Languages ......................................48 94 3.9 Secure and Insecure Net Locations ..........................49 95 3.10 Cancelled Transactions .....................................49 96 3.10.1 Cancelling Transactions ..............................49 97 3.10.2 Handling Cancelled Transactions ......................50 99 4. IOTP Error Handling ...........................................51 100 4.1 Technical Errors ...........................................51 101 4.2 Business Errors ............................................52 102 4.3 Error Depth ................................................52 103 4.3.1 Transport Level ......................................52 104 4.3.2 Message Level ........................................53 105 4.3.3 Block Level ..........................................53 106 4.4 Idempotency, Processing Sequence, and Message Flow .........55 107 4.5 Server Role Processing Sequence ............................56 108 4.5.1 Initiating Transactions ..............................56 109 4.5.2 Processing Input Messages ............................56 110 4.5.3 Cancelling a Transaction .............................62 111 4.5.4 Retransmitting Messages ..............................62 112 4.6 Client Role Processing Sequence ............................63 113 4.6.1 Initiating Transactions ..............................63 114 4.6.2 Processing Input Messages ............................63 115 4.6.3 Cancelling a Transaction .............................65 116 4.6.4 Retransmitting Messages ..............................65 118 5. Security Considerations .......................................66 119 5.1 Determining whether to use digital signatures ..............66 120 5.2 Symmetric and Asymmetric Cryptography ......................67 121 5.3 Data Privacy ...............................................68 122 5.4 Payment Protocol Security ..................................68 124 6. Digital Signatures and IOTP ...................................69 125 6.1 How IOTP uses Digital Signatures ...........................69 126 6.1.1 IOTP Signature Example ...............................71 127 6.1.2 OriginatorInfo and RecipientInfo Elements ............72 128 6.1.3 Using signatures to Prove Actions Complete Successfully73 129 6.2 Checking a Signature is Correctly Calculated ...............73 130 6.3 Checking a Payment or Delivery can occur ...................74 131 6.3.1 Check Request Block sent Correct Organisation ........75 132 6.3.2 Check Correct Components present in Request Block ....78 133 6.3.3 Check an Action is Authorised ........................78 135 7. Trading Components ............................................80 136 7.1 Protocol Options Component .................................81 137 7.2 Authentication Request Component ...........................83 138 7.3 Authentication Response Component ..........................84 139 7.4 Trading Role Information Request Component .................85 140 7.5 Order Component ............................................85 141 7.5.1 Order Description Content ............................86 142 7.5.2 OkFrom and OkTo Timestamps ...........................87 143 7.6 Organisation Component .....................................88 144 7.6.1 Organisation IDs .....................................89 145 7.6.2 Trading Role Element .................................90 146 7.6.3 Contact Information Element ..........................93 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 .............................100 153 7.7.4 Currency Amount Element .............................101 154 7.7.5 Pay Protocol Element ................................102 155 7.8 Brand Selection Component .................................103 156 7.8.1 Brand Selection Brand Info Element ..................105 157 7.8.2 Brand Selection Protocol Amount Info Element ........105 158 7.8.3 Brand Selection Currency Amount Info Element ........106 159 7.9 Payment Component .........................................106 160 7.10 Payment Scheme Component ..................................107 161 7.11 Payment Receipt Component .................................108 162 7.12 Payment Note Component ....................................110 163 7.13 Delivery Component ........................................111 164 7.13.1 Delivery Data Element ...............................112 165 7.14 Consumer Delivery Data Component ..........................114 166 7.15 Delivery Note Component ...................................115 167 7.16 Status Component ..........................................116 168 7.16.1 Offer Completion Codes ..............................118 169 7.16.2 Payment Completion Codes ............................119 170 7.16.3 Delivery Completion Codes ...........................121 171 7.16.4 Authentication Completion Codes .....................123 172 7.16.5 Undefined Completion Codes ..........................124 173 7.16.6 Transaction Inquiry Completion Codes ................125 174 7.17 Trading Role Data Component ...............................125 175 7.17.1 Who Receives a Trading Role Data Component ..........126 176 7.18 Inquiry Type Component ....................................126 177 7.19 Signature Component .......................................127 178 7.19.1 IOTP usage of signature elements and attributes .....128 179 7.19.2 Offer Response Signature Component ..................130 180 7.19.3 Payment Receipt Signature Component .................131 181 7.19.4 Delivery Response Signature Component ...............132 182 7.19.5 Authentication Request Signature Component ..........132 183 7.19.6 Authentication Response Signature Component .........132 184 7.19.7 Inquiry Request Signature Component .................133 185 7.19.8 Inquiry Response Signature Component ................133 186 7.19.9 Ping Request Signature Component ....................133 187 7.19.10 Ping Response Signature Component...................133 188 7.20 Certificate Component .....................................133 189 7.20.1 IOTP usage of signature elements and attributes .....134 190 7.21 Error Component ...........................................134 191 7.21.1 Error Processing Guidelines .........................136 192 7.21.2 Error Codes .........................................137 193 7.21.3 Error Location Element ..............................141 195 8. Trading Blocks ...............................................143 196 8.1 Trading Protocol Options Block ............................145 197 8.2 TPO Selection Block .......................................146 198 8.3 Offer Response Block ......................................146 199 8.4 Authentication Request Block ..............................147 200 8.5 Authentication Response Block .............................149 201 8.6 Authentication Status Block ...............................149 202 8.7 Payment Request Block .....................................150 203 8.8 Payment Exchange Block ....................................151 204 8.9 Payment Response Block ....................................152 205 8.10 Delivery Request Block ....................................153 206 8.11 Delivery Response Block ...................................154 207 8.12 Inquiry Request Trading Block .............................155 208 8.13 Inquiry Response Trading Block ............................155 209 8.14 Ping Request Block ........................................156 210 8.15 Ping Response Block .......................................157 211 8.16 Signature Block ...........................................158 212 8.16.1 Signature Block with Offer Response .................159 213 8.16.2 Signature Block with Payment Request ................159 214 8.16.3 Signature Block with Payment Response ...............159 215 8.16.4 Signature Block with Delivery Request ...............159 216 8.16.5 Signature Block with Delivery Response ..............160 217 8.17 Error Block ...............................................160 218 8.18 Cancel Block ..............................................161 220 9. Internet Open Trading Protocol Transactions ..................162 221 9.1 Authentication and Payment Related IOTP Transactions ......162 222 9.1.1 Authentication Document Exchange ....................164 223 9.1.2 Offer Document Exchange .............................169 224 9.1.3 Payment Document Exchange ...........................176 225 9.1.4 Delivery Document Exchange ..........................181 226 9.1.5 Payment and Delivery Document Exchange ..............183 227 9.1.6 Baseline Authentication IOTP Transaction ............186 228 9.1.7 Baseline Deposit IOTP Transaction ...................187 229 9.1.8 Baseline Purchase IOTP Transaction ..................189 230 9.1.9 Baseline Refund IOTP Transaction ....................190 231 9.1.10 Baseline Withdrawal IOTP Transaction ................192 232 9.1.11 Baseline Value Exchange IOTP Transaction ............194 233 9.1.12 Valid Combinations of Document Exchanges ............196 234 9.1.13 Combining Authentication Transactions with other 235 Transactions ........................................199 236 9.2 Infrastructure Transactions ...............................200 237 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 201 238 9.2.2 Baseline Ping IOTP Transaction ......................205 240 10. Retrieving Logos .............................................209 241 10.1 Logo Size .................................................209 242 10.2 Logo Color Depth ..........................................210 243 10.3 Logo Net Location Examples ................................210 245 11. Brands .......................................................211 246 11.1 Brand Definitions and Brand Selection .....................211 247 11.1.1 Definition of Payment Instrument ....................211 248 11.1.2 Definition of Brand .................................212 249 11.1.3 Definition of Dual Brand ............................212 250 11.1.4 Definition of Promotional Brand .....................213 251 11.1.5 Identifying Promotional Brands ......................213 252 11.2 Brand List Examples .......................................215 253 11.2.1 Simple Credit Card Based Example ....................216 254 11.2.2 Credit Card Brand List Including Promotional Brands .217 255 11.2.3 Brand Selection Example .............................218 256 11.2.4 Complex Electronic Cash Based Brand List ............218 258 12. IANA Considerations ..........................................222 259 12.1 Codes Controlled by IANA ..................................222 260 12.2 Codes not controlled by IANA ..............................227 262 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, for 467 example purchases and refunds. 469 The group that has worked on the IOTP see an extended version being 470 developed over time but feel a need to focus on a limited function but 471 completely usable specification in order that implementers can develop 472 solutions that work now. 474 During this period it is anticipated that there will be no changes to the 475 scope of this specification with the only changes made being limited to 476 corrections where problems are found. Software solutions have been 477 developed based on earlier versions of this specification (for example 478 version 0.9 published in early 1998 and earlier revisions of version 1.0 479 published during 1999) which prove that the IOTP works. 481 1.4 Objectives of Document 483 The objectives of this document are to provide a specification of version 484 1.0 of the Internet Open Trading Protocols which can be used to design 485 and implement systems which support electronic trading on the Internet 486 using the Internet Open Trading Protocols. 488 The purpose of the document is: 490 o to allow potential developers of products based on the protocol to 491 develop software/hardware solutions which use the protocol 493 o to allow the financial services industry to understand a developing 494 electronic commerce trading protocol that encapsulates (without 495 modification) any of the current or developing payment schemes now 496 being used or considered by their merchant customer base 498 1.5 Scope of Document 500 The protocol describes the content, format and sequences of messages that 501 pass among the participants in an electronic trade - consumers, merchants 502 and banks or other financial institutions, and customer care providers. 503 These are required to support the electronic commerce transactions 504 outlined in the objectives above. 506 The protocol is designed to be applicable to any electronic payment 507 scheme since it targets the complete purchase process where the movement 508 of electronic value from the payer to the payee is only one, but 509 important, step of many that may be involved to complete the trade. 511 Payment Scheme which IOTP could support include MasterCard Credit, Visa 512 Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, 513 Proton etc. 515 Each payment scheme contains some message flows which are specific to 516 that scheme. These scheme-specific parts of the protocol are contained in 517 a set of payment scheme supplements to this specification. 519 The document does not prescribe the software and processes that will need 520 to be implemented by each participant. It does describe the framework 521 necessary for trading to take place. 523 This document also does not address any legal or regulatory issues 524 surrounding the implementation of the protocol or the information systems 525 which use them. 527 1.6 Document Structure 529 The document consists of the following sections: 531 o Section 1 - Background: This section gives a brief background on 532 electronic commerce and the benefits IOTP offers. 534 o Section 2 - Introduction: This section describes the various Trading 535 Exchanges and shows how these trading exchanges are used to construct 536 the IOTP Transactions. This section also explains various Trading Roles 537 that would participate in electronic trade. 539 o Section 3 - Protocol Structure: This section summarises how various 540 IOTP transactions are constructed using the Trading Blocks and Trading 541 Components that are the fundamental building blocks for IOTP 542 transactions. All IOTP transaction messages are well formed XML 543 documents. 545 o Section 4 - IOTP Error Handling: This section describes how to process 546 exceptions and errors during the protocol message exchange and trading 547 exchange processing. This section provides a generic overview of the 548 exception handling. This section should be read carefully. 550 o Section 5 - Security Considerations: This section considers from an 551 IETF perspective, how IOTP addresses security. It includes: how to 552 determine whether to use digital signatures with IOTP, how IOTP address 553 data privacy, and how security built into payment protocols relate to 554 IOTP security. 556 o Section 6 - Digital Signatures and IOTP: This section provides an 557 overview of how IOTP uses digital signatures; how to check a signature 558 is correctly calculated and how the various Trading Roles that 559 participate in trade should check signatures when required. 561 o Section 7 - Trading Components: This section defines the XML elements 562 required by Trading Components. 564 o Section 8 - Trading Blocks: This section describes how Trading Blocks 565 are constructed from Trading Components. 567 o Section 9 - Internet Open Trading Protocol Transactions: This section 568 describes all the IOTP Baseline transactions. It refers to Trading 569 Blocks and Trading Components and Signatures. This section doesn't 570 directly link error handling during the protocol exchanges, the reader 571 is advised to understand Error Handling as defined in section before 572 reading this section. 574 o Section 10 - Retrieving Logos: This section describes how IOTP specific 575 logos can be retrieved. 577 o Section 11 - Brands: This section provides: an overview of Brand 578 Definitions and Brand Selection which describe how a Consumer can 579 select a Brand from a list provided by the Merchant; as well as some 580 examples of Brand Lists. 582 o Section 12 - IANA Considerations: This section describes how new values 583 for codes used by IOTP are co-ordinated. 585 o Section 13 - Internet Open Trading Protocol Data Type Definition: This 586 section contains the XML Data Type Definitions for IOTP. 588 o Section 14 - Glossary. This describes all the major terminology used by 589 IOTP. 591 o Section 15 - Copyright information. 593 o Section 16 - A list of the other documents referenced by the IOTP 594 specification. 596 o Section 17 - The Author's Address 598 1.7 Intended Readership 600 Software and hardware developers; development analysts; business and 601 technical planners; industry analysts; merchants; bank and other payment 602 handlers; owners, custodians, and users of payment protocols. 604 1.7.1 Reading Guidelines 606 This IOTP specification is structured primarily in a sequence targeted at 607 people who want to understand the principles of IOTP. However from 608 practical implementation experience by implementers of earlier of 609 versions of the protocol new readers who plan to implement IOTP may 610 prefer to read the document in a different sequence as described below. 612 Review the transport independent parts of the specification: This covers 614 o Section 14 - Glossary 615 o Section 1 - Background 617 o Section 2 - Introduction 619 o Section 3 - Protocol Structure 621 o Section 4 - IOTP Error Handling 623 o Section 5 - Security Considerations 625 o Section 9 - Internet Open Trading Protocol Transactions 627 o Section 11 - Brands 629 o Section 12 - IANA Considerations 631 o Section 10 - Retrieving Logos 633 Review the detailed XML definitions: 635 o Section 8 - Trading Blocks 637 o Section 7 - Trading Components 639 o Section 6 - Digital Signatures and IOTP 641 2. Introduction 643 The Internet Open Trading Protocols (IOTP) define a number of different 644 types of IOTP Transactions: 646 o Purchase. This supports a purchase involving an offer, a payment and 647 optionally a delivery 649 o Refund. This supports the refund of a payment as a result of, 650 typically, an earlier purchase 652 o Value Exchange. This involves two payments which result in the exchange 653 of value from one combination of currency and payment method to another 655 o Authentication. This supports one organisation or individual to check 656 that another organisation or individual are who they appear to be. 658 o Withdrawal. This supports the withdrawal of electronic cash from a 659 financial institution 661 o Deposit. This supports the deposit of electronic cash at a financial 662 institution 664 o Inquiry This supports inquiries on the status of an IOTP transaction 665 which is either in progress or is complete 667 o Ping This supports a simple query which enables one IOTP aware 668 application to determine whether another IOTP application running 669 elsewhere is working or not. 671 These IOTP Transactions are "Baseline" transactions since they have been 672 identified as a minimum useful set of transactions. Later versions of 673 IOTP may include additional types of transactions. 675 Each of the IOTP Transactions above involve: 677 o a number of organisations playing a Trading Role, and 679 o a set of Trading Exchanges. Each Trading Exchange involves the exchange 680 of data, between Trading Roles, in the form of a set of Trading 681 Components. 683 Trading Roles, Trading Exchanges and Trading Components are described 684 below. 686 2.1 Trading Roles 688 The Trading Roles identify the different parts which organisations can 689 take in a trade. The six Trading Roles used within IOTP are illustrated 690 in the diagram below. 692 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 694 Merchant Customer Care Provider resolves ---------- 695 ---------------------------------------------->| Merchant | 696 | Consumer disputes and problems |Cust.Care.| 697 | | Provider | 698 | ---------- 699 | 700 Payment Handler accepts or makes ---------- 701 | ------------------------------------------>| Payment | 702 | | Payment for Merchant | Handler | 703 | | ---------- 704 v v 705 ---------- Consumer makes purchases or obtains ---------- 706 | Consumer |<--------------------------------------->| Merchant | 707 ---------- refund from Merchant ---------- 708 ^ 709 | Delivery Handler supplies goods or ---------- 710 |---------------------------------------------->|Deliverer | 711 services for Merchant ---------- 713 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 715 Figure 1 IOTP Trading Roles 717 The roles are: 719 o Consumer. The person or organisation which is to receive and pay for 720 the goods or services 722 o Merchant. The person or organisation from whom the purchase is being 723 made and who is legally responsible for providing the goods or services 724 and receives the benefit of the payment made 726 o Payment Handler. The entity that physically receives the payment from 727 the Consumer on behalf of the Merchant 729 o Delivery Handler. The entity that physically delivers the goods or 730 services to the Consumer on behalf of the Merchant. 732 o Merchant Customer Care Provider. The entity that is involved with 733 customer dispute negotiation and resolution on behalf of the Merchant 735 Roles may be carried out by the same organisation or different 736 organisations. For example: 738 o in the simplest case one physical organisation (e.g. a merchant) could 739 handle the purchase, accept the payment, deliver the goods and provide 740 merchant customer care 742 o at the other extreme, a merchant could handle the purchase but instruct 743 the consumer to pay a bank or financial institution, request that 744 delivery be made by an overnight courier firm and to contact an 745 organisation which provides 24x7 service if problems arise. 747 Note that in this specification, unless stated to the contrary, when the 748 words Consumer, Merchant, Payment Handler, Delivery Handler or Customer 749 Care Provider are used, they refer to the Trading Role rather than an 750 actual organisation. 752 An individual organisation may take multiple roles. For example a company 753 which is selling goods and services on the Internet could take the role 754 of Merchant when selling goods or services and the role of Consumer when 755 the company is buying goods or services itself. 757 As roles occur in different places there is a need for the organisations 758 involved in the trade to exchange data, i.e. to carry out Trading 759 Exchanges, so that the trade can be completed. 761 2.2 Trading Exchanges 763 The Internet Open Trading Protocols identify four Trading Exchanges which 764 involve the exchange of data between the Trading Roles. The Trading 765 Exchanges are: 767 o Offer. The Offer Exchange results in the Merchant providing the 768 Consumer with the reason why the trade is taking place. It is called an 769 Offer since the Consumer must accept the Offer if a trade is to 770 continue 772 o Payment. The Payment Exchange results in a payment of some kind between 773 the Consumer and the Payment Handler. This may occur in either 774 direction 776 o Delivery. The Delivery Exchange transmits either the on-line goods, or 777 delivery information about physical goods from the Delivery Handler to 778 the Consumer, and 780 o Authentication. The Authentication Exchange can be used by any Trading 781 Role to authenticate another Trading Role to check that they are who 782 they appear to be. 784 IOTP Transactions are composed of various combinations of these Trading 785 Exchanges. For example, an IOTP Purchase transaction includes Offer, 786 Payment, and Delivery Trading Exchanges. As another example, an IOTP 787 Value Exchange transaction is composed of an Offer Trading Exchange and 788 two Payment Trading Exchanges. 790 Trading Exchanges consist of Trading Components that are transmitted 791 between the various Trading Roles. Where possible, the number of round- 792 trip delays in an IOTP Transaction is minimised by packing the Components 793 from several Trading Exchanges into combination IOTP Messages. For 794 example, the IOTP Purchase transaction combines a Delivery Organisation 795 Component with an Offer Response Component in order to avoid an extra 796 Consumer request and response. 798 Each of the IOTP Trading Exchanges is described in more detail below. For 799 clarity of description, these describe the Trading Exchanges as though 800 they were standalone operations. For performance reasons, the Trading 801 Exchanges are intermingled in the actual IOTP Transaction definitions. 803 2.2.1 Offer Exchange 805 The goal of the Offer Exchange is for the Merchant to provide the 806 Consumer with information about the trade so that the Consumer can decide 807 whether to continue with the trade. This is illustrated in the figure 808 below. 810 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 811 Consumer 812 | Merchant 813 STEP | | 814 1. Consumer decides to trade and sends information about the 815 transaction (requests an offer) to the Merchant e.g. using 816 HTML. 818 C --> M Data: Information on what is being purchased (Offer Request) 819 - outside scope of IOTP 821 2. Merchant checks the information provided by the Consumer, 822 creates an Offer optionally signs it and sends it to the 823 Consumer. 825 C <-- M OFFER RESPONSE. Components: Status; Organisation(s) 826 (Consumer, DelivTo, Merchant, Payment Handler, Customer 827 Care); Order; Payment; Delivery; TradingRoleData (optional) 828 Offer Response Signature (optional) that signs other 829 components 831 3. Consumer checks the information from the Merchant and decides 832 whether to continue. 834 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 836 Figure 2 Offer Exchange 838 An Offer Exchange uses the following Trading Components that are passed 839 between the Consumer and the Merchant: 841 o the Status component is used to indicate to other parties that a valid 842 Offer Response has been generated 844 o the Organisation Component contains information which describes the 845 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 850 - the merchant augments this information by providing information about 851 the merchant, the Payment Handler, the customer care provider and, if 852 goods or services are being delivered, the Delivery Handler 854 o the Order Component contains descriptions of the goods or services 855 which will result from the trade if the consumer agrees to the offer. 856 This information is sent by the Merchant to the consumer who should 857 verify it 859 o the Payment Component generated by the Merchant, contains details of 860 how much to pay, the currency and the payment direction, for example 861 the consumer could be asking for a refund. Note that there may be more 862 than one payment in a trade 864 o the Delivery Component, also generated by the Merchant, is used if 865 goods or services are being delivered. This contains information about 866 how delivery will occur, for example by post or using e-mail 868 o the Trading Role Data component contains data the Merchant wants to 869 forward to another Trading Role such as a Payment Handler or Delivery 870 Handler 872 o the "Offer Response" Signature Component, if present, digitally signs 873 all of the above components to ensure their integrity. 875 The exact content of the information provided by the Merchant to the 876 Consumer will vary depending on the type of IOTP Transaction. For 877 example: 879 o low value purchases may not need a signature 881 o the amount to be paid may vary depending on the payment brand and 882 payment protocol used 884 o some offers may not involve the delivery of any goods 886 o a value exchange will involve two payments 888 o a merchant may not offer customer care. 890 Information provided by the consumer to the merchant is provided using a 891 variety of methods, for example, it could be provided: 893 o using [HTML] pages as part of the "shopping experience" of the 894 consumer. 896 o Using the Open Profiling Standard [OPS] which has recently been 897 proposed, 899 o in the form of Organisation Components associated with an 900 authentication of a Consumer by a Merchant 902 o as Order Components in a later version of IOTP. 904 2.2.2 Payment Exchange 906 The goal of the Payment Exchange is for a payment to be made from the 907 Consumer to a Payment Handler or vice versa using a payment brand and 908 payment protocol selected by the Consumer. A secondary goal is to 909 optionally provide the Consumer with a digitally signed Payment Receipt 910 which can be used to link the payment to the reason for the payment as 911 described in the Offer Exchange. 913 Payment Exchanges can work in a variety of ways. The most general case 914 where the trade is dependent on the payment brand and protocol used is 915 illustrated in the diagram below. Simpler payment exchanges are possible. 916 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 917 Consumer Pay Handler 918 | Merchant | 919 STEP | | | 920 1. Consumer decides to trade and sends information about 921 the transaction (requests an offer) to the Merchant 922 e.g. using HTML. 924 C --> M Information on what is being paid for (outside scope 925 of IOTP 927 2. Merchant decides which payment brand, payment 928 protocols and currencies/amounts to offer, places then 929 in a Brand List Component and sends them to the 930 Consumer 932 C <-- M Components: Brand List 934 3. Consumer selects the payment brand, protocol and 935 currency/amount to use, creates a Brand Selection 936 component and sends it to the Merchant 938 C --> M Component: Brand List Selection 940 4. Merchant checks Brand Selection, creates a Payment 941 Amount information, optionally signs it to authorise 942 payment and sends it to the Consumer 944 C <-- M Component: Payment; Organisation(s) (Merchant and 945 Payment Handler); Optional Offer Response Signature 946 that signs other components 948 5. Consumer checks the Payment Amount information and if 949 OK requests that the payment starts by sending 950 information to the Payment Handler 952 C --------> P PAYMENT REQUEST. Components: Status, Payment; 953 Organisations (Merchant and Payment Handler); Trading 954 Role Data (optional); Optional Offer Response 955 Signature that signs other components; Pay Scheme Data 957 6. Payment Handler checks information including optional 958 signature and if OK starts exchanging Pay Scheme Data 959 components for selected payment brand and payment 960 protocol 962 C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data 964 7. Eventually payment protocol messages finish so Payment 965 Handler sends Pay Receipt and optional signature to 966 the Consumer as proof of payment 968 C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt; 969 Payment Note; Trading Role Data (optional); Optional 970 Offer Response Signature; Optional Payment Receipt 971 Signature that binds the payment to the Offer 973 8. Consumer checks Payment Receipt is OK 975 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 977 Figure 3 Payment Exchange 979 A Payment Exchange uses the following Trading Components that are passed 980 between the Consumer, the Merchant and the Payment Handler: 982 o The Brand List Component contains a list of payment brands (for 983 example, MasterCard, Visa, Mondex, GeldKarte), payment protocols (for 984 example SET Version 1.0, Secure Channel Credit Debit (SCCD - the name 985 used for a credit or debit card payment where unauthorised access to 986 account information is prevented through use of secure channel 987 transport mechanisms such as SSL/TLS) as well as currencies/amounts 988 that apply. The Merchant sends the Brand List to the Consumer. The 989 consumer compares the payment brands, protocols and currencies/amounts 990 on offer with those that the Consumer supports and makes a selection. 992 o The Brand Selection Component contains the Consumer's selection. 993 Payment brand, protocol, currency/amount and possibly protocol-specific 994 information is sent back to the Merchant. This information may be used 995 to change information in the Offer Exchange. For example, a merchant 996 could choose to offer a discount to encourage the use of a store card. 998 o the Status component is used to indicate to the Payment Handler that an 999 earlier exchange (e.g. an Offer Exchange) has successfully completed 1000 and by the Payment Handler to indicate the completion status of the 1001 Payment Exchange. 1003 o The Organisation Components are generated by the Merchant. They contain 1004 details of the Merchant and Payment Handler Roles: 1005 - the Merchant role is required so that the Payment Handler can 1006 identify which Merchant initiated the payment. Typically, the result 1007 of the Payment Handler accepting (or making) a payment on behalf of 1008 the Merchant will be a credit or debit transaction to the Merchant's 1009 account held by the Payment Handler. These transactions are outside 1010 the scope of this version of IOTP 1011 - the Payment Handler role is required so that the Payment Handler can 1012 check that it is the correct Payment Handler to be used for the 1013 payment 1015 o The Payment Component contains details of how much to pay, the currency 1016 and the payment direction 1018 o The "Offer Response" Signature Component, if present, digitally signs 1019 all of the above components to ensure their integrity. Note that the 1020 Brand List and Brand Selection Components are not signed until the 1021 payment information is created (step 4 in the diagram) 1023 o the Trading Role Data component contains from other roles (e.g. a 1024 Merchant) that needs to be forwarded to the Payment Handler 1026 o The Payment Scheme Component contains messages from the payment 1027 protocol used in the Trade. For example they could be SET messages, 1028 Mondex messages, GeldKarte Messages or one of the other payment methods 1029 supported by IOTP. The content of the Payment Scheme Component is 1030 defined in the supplements that describe how IOTP works with various 1031 payment protocols. 1033 o The Payment Receipt Component contains a record of the payment. The 1034 content depends upon the payment protocol used. 1036 o The "Payment Receipt" Signature Component provides proof of payment by 1037 digitally signing both the Payment Receipt Component and the Offer 1038 Response Signature. The signature on the offer digitally signs the 1039 Order, Organisation and Delivery Components contained in the Offer. 1040 This signature effectively binds the payment to the offer. 1042 The example of a Payment Exchange above is the most general case. Simpler 1043 cases are also possible. For example, if the amount paid is not dependent 1044 on the payment brand and protocol selected then the payment information 1045 generated by step 3 can be sent to the Consumer at the same time as the 1046 Brand List Component generated by step 1. These and other variations are 1047 described in the Baseline Purchase IOTP Transaction (see section 9.1.8). 1049 2.2.3 Delivery Exchange 1051 The goal of the Delivery Exchange is to cause purchased goods to be 1052 delivered to the consumer either online or via physical delivery. A 1053 second goal is to provide a "delivery note" to the consumer, providing 1054 details about the delivery, such as shipping tracking number. The result 1055 of the delivery may also be signed so that it can be used for customer 1056 care in the case of problems with physical delivery. The message flow is 1057 illustrated in the diagram below. 1059 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1060 CONSUMER DELIVERY 1061 | HANDLER 1062 | Merchant | 1063 STEP | | | 1064 1. Consumer decides to trade and sends information about 1065 what to deliver and who is to take delivery, to the 1066 Merchant e.g. using HTML. 1068 C --> M Information on what is being delivered (outside scope 1069 of IOTP) 1071 2. Merchant checks the information provided by the 1072 Consumer, adds information about how the delivery will 1073 occur, information about the Organisations involved in 1074 the delivery and optionally sings it and sends it to 1075 the Consumer 1077 C <-- M Components: Delivery; Organisations (Delivery Handler, 1078 Deliver To); Order, Optional Offer Response Signature 1080 3. Consumer checks delivery information is OK, obtains 1081 authorisation for the delivery, for example by making 1082 a payment, and sends the delivery information to the 1083 Delivery Handler 1085 C --------> D DELIVERY REQUEST. Components: Status; Delivery, 1086 Organisations: (Merchant, Delivery Handler, DelivTo); 1087 Order, Trading Role Data (optional); Optional Offer 1088 Response Signature, Optional Payment Receipt Signature 1089 (from Payment Exchange) 1091 4. Delivery Handler checks information and authorisation. 1092 Starts or schedules delivery and creates and then 1093 sends a delivery not tot the Consumer which can 1094 optionally be signed. 1096 C <-------- D DELIVERY RESPONSE. Components: Status; Delivery Note, 1097 Trading Role Data (optional); Optional Delivery 1098 Response Signature 1100 5. Consumer checks delivery note is OK and accepts or 1101 waits for delivery as described in the the Delivery 1102 Note. 1104 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1106 Figure 4 Delivery Exchange 1108 A Delivery Exchange uses the following Trading Components that are passed 1109 between the Consumer, the Merchant and the Delivery Handler: 1111 o the Status component is used to indicate to the Delivery Handler that 1112 an earlier exchange (e.g. an Offer Exchange or Payment Exchange) has 1113 successfully completed and by the Delivery Handler to indicate the 1114 completion status of the Delivery Exchange. 1116 o The Organisation Component(s) contain details of the Deliver To, 1117 Delivery Handler and Merchant Roles: 1118 - the Deliver To role indicates where the goods or services are to be 1119 delivered to 1120 - the Delivery Handler role is required so that the Delivery Handler 1121 can check that she is the correct Delivery Handler to do the delivery 1122 - the Merchant role is required so that the Delivery Handler can 1123 identify which Merchant initiated the delivery 1125 o The Order Component, contains information about the goods or services 1126 to be delivered 1128 o The Delivery Component contains information about how delivery will 1129 occur, for example by post or using e-mail. 1131 o The "Offer Response" Signature Component, if present, digitally signs 1132 all of the above components to ensure their integrity. 1134 o The "Payment Receipt" Signature Component provides proof of payment by 1135 digitally signing the Payment Receipt Component and the Offer 1136 Signature. This is used by the Delivery Handler to check that delivery 1137 is authorised 1139 o The Delivery Note Component contains customer care information related 1140 to a physical delivery, or alternatively the actual "electronic goods". 1141 The Consumer's software does not interpret information about a physical 1142 delivery but should have the ability to display the information, both 1143 at the time of the delivery and later if the Consumer selects the Trade 1144 to which this delivery relates from a transaction list 1146 o The "Delivery Response" Signature Component, if present, provides proof 1147 of the results of the Delivery by digitally signing the Delivery Note 1148 and any Offer Response or Payment Response signatures that the Delivery 1149 Handler received. 1151 2.2.4 Authentication Exchange 1153 The goal of the Authentication Exchange is to allow one Organisation, for 1154 example a financial institution, to be able to check that another 1155 Organisation, for example a consumer, is who they appear to be. 1157 An Authentication Exchange involves: 1159 o an Authenticator - the Organisation which is requesting the 1160 authentication, and 1162 o an Authenticatee - the Organisation being authenticated. 1164 This is illustrated in the diagram below. 1166 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1167 Organisation 1 1168 (Authenticatee) 1169 | Organisation 2 1170 | (Authenticator) 1171 STEP | | 1172 1. First Organisation, e.g. a Consumer, takes an action (for 1173 example by pressing a button on an HTML page) which requires 1174 that the Organisation is authenticated 1176 1 --> 2 Need for Authentication (outside scope of IOTP) 1178 2. The second Organisation generates an Authentication Request - 1179 including challenge data, and a list of the algorithms that 1180 may be used for the authentication - and/or a request for the 1181 Organisation information then sends it to the first 1182 Organisation 1184 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, 1185 Trading Role Information Request 1187 3. The first Organisation optionally checks any signature 1188 associated with the Authentication Request then uses the 1189 specified authentication algorithm to generate an 1190 Authentication Response which is sent back to the second 1191 Organisation together with details of any Organisation 1192 information requested 1194 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, 1195 Organisation(s) 1197 4. The Authentication Response is checked against the challenge 1198 data to check that the first Organisation is who they appear 1199 to be and the result recorded in a Status Component which is 1200 then sent back to the first Organisation. 1202 1 <-- 2 AUTHENTICATION STATUS. Component: Status 1204 5. The first Organisation then optionally checks the results 1205 indicated by the Status and any associated signature and 1206 takes the appropriate action or stops. 1208 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1210 Figure 5 Authentication Exchange 1212 An Authentication Exchange uses the following Trading Components that are 1213 passed between the two Organisations: 1215 o the Authentication Request Component that requests an Authentication 1216 and indicates the authentication algorithm and optional challenge data 1217 to be used. 1219 o A Trading Role Information Request Component that requests information 1220 about an Organisation, for example a ship to address. 1222 o The Authentication Response Component which contains the challenge 1223 response generated by the recipient of the Authentication Request 1224 Component. 1226 o Organisation Components that contain the result of the Trading Role 1227 Information Request 1229 o the Status Component which contains the results of the second party's 1230 verification of the Authentication Response. 1232 2.3 Scope of Baseline IOTP 1234 This specification describes the IOTP Transactions which make up Baseline 1235 IOTP. As described in the preface, IOTP will evolve over time. This 1236 section defines the initial conformance criteria for implementations that 1237 claim to "support IOTP." 1239 The main determinant on the scope of an IOTP implementation is the roles 1240 which the solution is designed to support. The roles within IOTP are 1241 described in more detail in section 2.1 Trading Roles. To summarise the 1242 roles are: Merchant, Consumer, Payment Handler, Delivery Handler and 1243 Customer Care Provider. 1245 Payment Handlers who can be of three types: 1247 o those who accept a payment as part of a purchase or make a payment as 1248 part of a refund, 1250 o those who accept value as part of a deposit transaction, or 1252 o those that issue value a withdrawal transaction 1254 The following table defines, for each role, the IOTP Transactions and 1255 Trading Blocks which must be supported for that role. 1257 Merchants 1259 ECash ECash 1260 Store Value Value Consumer Payment Delivery 1261 Issuer Acquirer Handler Handler 1263 TRANSACTIONS 1265 Purchase Must Must 1266 Merchants 1268 ECash ECash 1269 Store Value Value Consumer Payment Delivery 1270 Issuer Acquirer Handler Handler 1272 Refund Must b) 1273 Depends 1275 Authentication May Must May b) 1276 Depends 1278 Value Exchange May Must 1280 Withdrawal Must b) 1281 Depends 1283 Deposit Must b) 1284 Depends 1286 Inquiry Must Must Must May Must Must 1288 Ping Must Must Must May Must Must 1290 TRADING BLOCKS 1292 TPO Must Must Must Must 1294 TPO Selection Must Must Must Must 1296 Auth-Request a) a) a) 1297 Depends Depends Depends 1299 Auth-Reply a) a) a) 1300 Depends Depends Depends 1302 Offer Response Must Must Must Must 1304 Payment Must Must 1305 Request 1307 Payment Must Must 1308 Exchange 1310 Payment Must Must 1311 Response 1313 Delivery Must Must 1314 Request 1316 Delivery Must Must 1317 Response 1318 Merchants 1320 ECash ECash 1321 Store Value Value Consumer Payment Delivery 1322 Issuer Acquirer Handler Handler 1324 Inquiry Must Must Must Must Must Must 1325 Request 1327 Inquiry Must Must Must Must Must Must 1328 Response 1330 Ping Request Must Must Must Must Must Must 1332 Ping Response Must Must Must Must Must Must 1334 Signature Must Must Must Limited Must Must 1336 Error Must Must Must Must Must Must 1338 In the above table: 1340 o "Must" means that a Trading Role must support the Transaction or 1341 Trading Block. 1343 o "May" means that an implementation may support the Transaction or 1344 Trading Block at the option of the developer. 1346 o "Depends" means implementation of the Transaction or Trading Block 1347 depends on one of the following conditions: 1348 - if Baseline Authentication IOTP Transaction is supported; 1349 - if required by a Payment Method as defined in its IOTP Supplement 1350 document. 1352 o "Limited" means the Trading Block must be understood and its content 1353 manipulated but not in every respect. Specifically, on the Signature 1354 Block, Consumers do not have to be able to validate digital signatures. 1356 An IOTP solution must support all the IOTP Transactions and Trading 1357 Blocks required by at least one role (column) as described in the above 1358 table for that solution to be described as "supporting IOTP". 1360 3. Protocol Structure 1362 The previous section provided an introduction which explained: 1364 o Trading Roles which are the different roles which Organisations can 1365 take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler 1366 and Customer Care Provider, and 1368 o Trading Exchanges where each Trading Exchange involves the exchange of 1369 data, between Trading Roles, in the form of a set of Trading 1370 Components. 1372 This section describes: 1374 o how Trading Components are constructed into Trading Blocks and the IOTP 1375 Messages which are physically sent in the form of [XML] documents 1376 between the different Trading Roles, 1378 o how IOTP Messages are exchanged between Trading Roles to create an IOTP 1379 Transaction 1381 o the XML definitions of an IOTP Message including a Transaction 1382 Reference Block - an XML element which identifies an IOTP Transaction 1383 and the IOTP Message within it 1385 o the definitions of the XML ID Attributes which are used to identify 1386 IOTP Messages, Trading Blocks and Trading Components and how these are 1387 referred to using Element References from other XML elements 1389 o how extra XML Elements and new user defined values for existing IOTP 1390 codes can be used when Extending IOTP, 1392 o how IOTP uses the Packaged Content Element to embed data such as 1393 payment protocol messages or detailed order definitions within an IOTP 1394 Message 1396 o how IOTP Identifies Languages so that different languages can be used 1397 within IOTP Messages 1399 o how IOTP handles both Secure and Insecure Net Locations when sending 1400 messages 1402 o how an IOTP Transaction can be cancelled. 1404 3.1 Overview 1406 3.1.1 IOTP Message Structure 1408 The structure of an IOTP Message and its relationship with Trading Blocks 1409 and Trading Components is illustrated in the diagram below. 1411 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1413 IOTP MESSAGE <---------- IOTP Message - an XML Document which is 1414 | transported between the Trading Roles 1415 |-Trans Ref Block <----- Trans Ref Block - contains information which 1416 | | describes the IOTP Transaction and the IOTP 1417 | | Message. 1418 | |-Trans Id Comp. <--- Transaction Id Component - uniquely 1419 | | identifies the IOTP Transaction. The Trans Id 1420 | | Components are the same across all IOTP 1421 | | messages that comprise a single IOTP 1422 | | transaction. 1423 | |-Msg Id Comp. <----- Message Id Component - identifies and 1424 | describes an IOTP Message within an IOTP 1425 | Transaction 1426 |-Signature Block <----- Signature Block (optional) - contains one or 1427 | | more Signature Components and their 1428 | | associated Certificates 1429 | |-Signature Comp. <-- Signature Component - contains digital 1430 | | signatures. Signatures may sign digests of 1431 | | the Trans Ref Block and any Trading Component 1432 | | in any IOTP Message in the same IOTP 1433 | | transaction. 1434 | |-Certificate Comp. < Certificate Component (Optional) Used to check 1435 | the signature. 1436 |-Trading Block <------- Trading Block - an XML Element within an IOTP 1437 | |-Trading Comp. Message that contains a predefined set of 1438 | |-Trading Comp. Trading Components 1439 | |-Trading Comp. 1440 | |-Trading Comp. <--- Trading Components - XML Elements within a 1441 | Trading Block that contain a predefined set 1442 |-Trading Block of XML elements and attributes containing 1443 | |-Trading Comp. information required to support a Trading 1444 | |-Trading Comp. Exchange 1445 | |-Trading Comp. 1446 | |-Trading Comp. 1447 | |-Trading Comp. 1449 *-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1451 Figure 6 IOTP Message Structure 1453 The diagram also introduces the concept of a Transaction Reference Block. 1454 This block contains, amongst other things, a globally unique identifier 1455 for the IOTP Transaction. Also each block and component is given an ID 1456 Attribute (see section 3.4) which is unique within an IOTP Transaction. 1457 Therefore the combination of the ID attribute and the globally unique 1458 identifier in the Transaction Reference Block is sufficient to uniquely 1459 identify any Trading Block or Trading Component. 1461 3.1.2 IOTP Transactions 1463 A predefined set of IOTP Messages exchanged between the Trading Roles 1464 constitute an IOTP Transaction. This is illustrated in the diagram below. 1466 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1468 CONSUMER MERCHANT 1469 Generate first 1470 IOTP Message 1471 --- | 1472 | | v 1473 Process incoming | I | ------------- 1474 IOTP Message & <------------- | | ------------ | IOTP Message | 1475 generate next IOTP | | ------------- 1476 Message | N | 1477 | | | 1478 v | | 1479 ------------- | T | Process incoming 1480 | IOTP Message | -------------- | | -----------> IOTP Message & 1481 ------------- | | generate next 1482 | E | IOTP Message 1483 | | | 1484 | | v 1485 Process incoming | R | ------------- 1486 IOTP Message <------------- | | ------------ | IOTP Message | 1487 generate last IOTP | | ------------- 1488 Message & stop | N | 1489 | | | 1490 v | | 1491 ------------- | E | Process last 1492 | IOTP Message | -------------- | | -------------> incoming IOTP 1493 ------------- | | Message & stop 1494 | | T | | 1495 v | | v 1496 STOP --- STOP 1498 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 1500 Figure 7 An IOTP Transaction 1502 In the above diagram the Internet is shown as the transport mechanism. 1503 This is not necessarily the case. IOTP Messages can be transported using 1504 a variety of transport mechanisms. 1506 The IOTP Transactions (see section 9) in this version of IOTP are 1507 specifically: 1509 o Purchase. This supports a purchase involving an offer, a payment and 1510 optionally a delivery 1512 o Refund. This supports the refund of a payment as a result of, 1513 typically, an earlier purchase 1515 o Value Exchange. This involves two payments which result in the exchange 1516 of value from one combination of currency and payment method to another 1518 o Authentication. This supports the remote authentication of one Trading 1519 Role by another Trading Role using a variety of authentication 1520 algorithms, and the provision of an Organisation Information about the 1521 Trading Role that is being authenticated for use in, for example, the 1522 creation of an offer 1524 o Withdrawal. This supports the withdrawal of electronic cash from a 1525 financial institution 1527 o Deposit. This supports the deposit of electronic cash at a financial 1528 institution 1530 o Inquiry This supports inquiries on the status of an IOTP transaction 1531 which is either in progress or is complete 1533 o Ping This supports a simple query which enables one IOTP aware 1534 application to determine whether another IOTP application running 1535 elsewhere is working or not. 1537 3.2 IOTP Message 1539 As described earlier, IOTP Messages are [XML] documents which are 1540 physically sent between the different Trading Roles that are taking part 1541 in a trade. 1543 The XML definition of an IOTP Message is as follows. 1545 1567 1571 Content: 1573 TransRefBlk This contains information which describes an IOTP 1574 Message within an IOTP Transaction (see section 1575 3.3 immediately below) 1577 AuthReqBlk, These are the Trading Blocks. 1578 AuthRespBlk, 1579 DeliveryReqBlk, The Trading Blocks present within an IOTP Message, 1580 DeliveryRespBlk and the content of a Trading Block itself is 1581 ErrorBlk dependent on the type of IOTP Transaction being 1582 InquiryReqBlk, carried out - see the definition of each 1583 InquiryRespBlk, transaction in section 9 Internet Open Trading 1584 OfferRespBlk, Protocol Transactions. 1585 PayExchBlk, 1586 PayReqBlk, Full definitions of each Trading Block are 1587 PayRespBlk, described in section 8. 1588 PingReqBlk, 1589 PingRespBlk, 1590 SigBlk, 1591 TpoBlk, 1592 TpoSelectionBlk 1594 Attributes: 1596 xmlns:iotp The [XML Namespace] definition for IOTP messages. 1598 3.2.1 XML Document Prolog 1600 The IOTP Message is the root element of the XML document. It therefore 1601 needs to be preceded by an appropriate XML Document Prolog. For example: 1603 1604 1605 1606 ... 1607 1609 3.3 Transaction Reference Block 1611 A Transaction Reference Block contains information which identifies the 1612 IOTP Transaction and IOTP Message. The Transaction Reference Block 1613 contains: 1615 o a Transaction Id Component which globally uniquely identifies the IOTP 1616 Transaction. The Transaction Id Components are the same across all IOTP 1617 messages that comprise a single IOTP transaction, 1619 o a Message Id Component which provides control information about the 1620 IOTP Message as well as uniquely identifying the IOTP Message within an 1621 IOTP Transaction, and 1623 o zero or more Related To Components which link this IOTP Transaction to 1624 either other IOTP Transactions or other events using the identifiers of 1625 those events. 1627 The definition of a Transaction Reference Block is as follows: 1629 1630 1633 Attributes: 1635 ID An identifier which uniquely identifies the 1636 Transaction Reference Block within the IOTP 1637 Transaction (see section 3.4 ID Attributes). 1639 Content: 1641 TransId See 3.3.1 Transaction Id Component immediately 1642 below. 1644 MsgId See 3.3.2 Message Id Component immediately below. 1646 RelatedTo See 3.3.3 Related To Component immediately below. 1648 3.3.1 Transaction Id Component 1650 This contains information which globally uniquely identifies the IOTP 1651 Transaction. Its definition is as follows: 1653 1654 1661 Attributes: 1663 ID An identifier which uniquely identifies the 1664 Transaction Id Component within the IOTP 1665 Transaction. 1667 Version This identifies the version of IOTP, and therefore 1668 the structure of the IOTP Messages, which the IOTP 1669 Transaction is using. 1671 IotpTransId Contains data which uniquely identifies the IOTP 1672 Transaction. It must conform to the rules for 1673 Message Ids in [RFC 822]. 1675 IotpTransTyp This is the type of IOTP Transaction being carried 1676 out. For Baseline IOTP it identifies a "standard" 1677 IOTP Transaction and implies the sequence and 1678 content of the IOTP Messages exchanged between the 1679 Trading Roles. The valid values for Baseline IOTP 1680 are: 1681 o BaselineAuthentication 1682 o BaselineDeposit 1683 o BaselinePurchase 1684 o BaselineRefund 1685 o BaselineWithdrawal 1686 o BaselineValueExchange 1687 o BaselineInquiry 1688 o BaselinePing 1690 Values of IotpTransType are managed under the 1691 procedure described in section 12 IANA 1692 Considerations which also allows user defined 1693 values of IotpTransType to be defined. 1695 In later versions of IOTP, this list will be 1696 extended to support different types of standard 1697 IOTP Transaction. It is also likely to support the 1698 type Dynamic which indicates that the sequence of 1699 steps within the transaction are non-standard. 1701 TransTimeStamp Where the system initiating the IOTP Transaction 1702 has an internal clock, it is set to the time at 1703 which the IOTP Transaction started in [UTC] 1704 format. 1706 The main purpose of this attribute is to provide 1707 an alternative way of identifying a transaction by 1708 specifying the time at which it started. 1710 Some systems, for example, hand held devices may 1711 not be able to generate a time stamp. In this 1712 case this attribute should contain the value "NA" 1713 for Not Available. 1715 3.3.2 Message Id Component 1717 The Message Id Component provides control information about the IOTP 1718 Message as well as uniquely identifying the IOTP Message within an IOTP 1719 Transaction. Its definition is as follows. 1721 1722 1732 Attributes: 1734 ID An identifier which uniquely identifies the 1735 IOTP Message within the IOTP Transaction (see 1736 section 3.4 ID Attributes). Note that if an 1737 IOTP Message is resent then the value of this 1738 attribute remains the same. 1740 RespIotpMsg This contains the ID attribute of the Message 1741 Id Component of the IOTP Message to which this 1742 IOTP Message is a response. In this way all 1743 the IOTP Messages in an IOTP Transaction are 1744 unambiguously linked together. This field is 1745 required on every IOTP Message except the 1746 first IOTP Message in an IOTP Transaction. 1748 SenderTradingRoleRef The Element Reference (see section 3.5) of the 1749 Trading Role which has generated the IOTP 1750 message. It is used to identify the Net 1751 Locations (see section 3.9) of the Trading 1752 Role to which problems Technical Errors (see 1753 section 4.1) with any of Trading Blocks should 1754 be reported. 1756 Xml:lang Defines the language used by attributes or 1757 child elements within this component, unless 1758 overridden by an xml:lang attribute on a child 1759 element. See section 3.8 Identifying 1760 Languages. 1762 LangPrefList Optional list of Language codes that conform 1763 to [XML] Language Identification. It is used 1764 by the sender to indicate, in preference 1765 sequence, the languages that the receiver of 1766 the message ideally should use when generating 1767 a response. There is no obligation on the 1768 receiver to respond using one of the indicated 1769 languages, but using one of the languages is 1770 likely to provide an improved user experience. 1772 CharSetPrefList Optional list of Character Set identifiers 1773 that conform to [XML] Characters. It is used 1774 by the sender to indicate, in preference 1775 sequence, the character sets that the receiver 1776 of the message ideally should use when 1777 generating a response. There is no obligation 1778 on the receiver to respond using one of the 1779 character sets indicated, but using one of the 1780 character sets is likely to provide an 1781 improved user experience. 1783 SoftwareId This contains information which identifies the 1784 software which generated the IOTP Message. Its 1785 purpose is to help resolve interoperability 1786 problems that might occur as a result of 1787 incompatibilities between messages produced by 1788 different software. It is a single text string 1789 in the language defined by xml:lang. It must 1790 contain, as a minimum: 1791 o the name of the software manufacturer 1792 o the name of the software 1793 o the version of the software, and 1794 o the build of the software 1796 TimeStamp Where the device sending the message has an 1797 internal clock, it is set to the time at which 1798 the IOTP Message was created in [UTC] format. 1800 3.3.3 Related To Component 1802 The Related To Component links IOTP Transactions to either other IOTP 1803 Transactions or other events using the identifiers of those events. Its 1804 definition is as follows. 1806 1807 1814 Attributes: 1816 ID An identifier which uniquely identifies the 1817 Related To Component within the IOTP Transaction. 1819 xml:lang Defines the language used by attributes or child 1820 elements within this component, unless overridden 1821 by an xml:lang attribute on a child element. See 1822 section 3.8 Identifying Languages. 1824 RelationshipType Defines the type of the relationship. Valid values 1825 are: 1826 o IotpTransaction. in which case the Packaged 1827 Content Element contains an IotpTransId of 1828 another IOTP Transaction 1829 o Reference in which case the Packaged Content 1830 Element contains the reference of some other, 1831 non-IOTP document. 1833 Values of RelationshipType are controlled under 1834 the procedures defined in section 12 IANA 1835 Considerations which also allows user defined 1836 values to be defined. 1838 Relation The Relation attribute contains a phrase in the 1839 language defined by xml:lang which describes the 1840 nature of the relationship between the IOTP 1841 transaction that contains this component and 1842 another IOTP Transaction or other event. The exact 1843 words to be used are left to the implementers of 1844 the IOTP software. 1846 The purpose of the attribute is to provide the 1847 Trading Roles involved in an IOTP Transaction with 1848 an explanation of the nature of the relationship 1849 between the transactions. 1851 Care should be taken that the words used to in the 1852 Relation attribute indicate the "direction" of the 1853 relationship correctly. For example: one 1854 transaction might be a refund for another earlier 1855 transaction. In this case the transaction which is 1856 a refund should contain in the Relation attribute 1857 words such as "refund for" rather than "refund to" 1858 or just "refund". 1860 RelnKeyWords This attribute contains keywords which could be 1861 used to help identify similar relationships, for 1862 example all refunds. It is anticipated that 1863 recommended keywords will be developed through 1864 examination of actual usage. In this version of 1865 the specification there are no specific 1866 recommendations and the keywords used are at the 1867 discretion of implementers. 1869 Content: 1871 PackagedContent The Packaged Content (see section 3.7) contains 1872 data which identifies the related transaction. Its 1873 format varies depending on the value of the 1874 RelationshipType. 1876 3.4 ID Attributes 1878 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading 1879 Blocks), Trading Components (including the Transaction Id Component and 1880 the Signature Component) and some of their child elements are each given 1881 an XML "ID" attribute which is used to identify an instance of these XML 1882 elements. These identifiers are used so that one element can be 1883 referenced by another. All these attributes are given the attribute name 1884 ID. 1886 The values of each ID attribute are unique within an IOTP transaction 1887 i.e. the set of IOTP Messages which have the same globally unique 1888 Transaction ID Component. Also, once the ID attribute of an element has 1889 been assigned a value it is never changed. This means that whenever an 1890 element is copied, the value of the ID attribute remains the same. 1892 As a result it is possible to use these IDs to refer to and locate the 1893 content of any IOTP Message, Block or Component from any other IOTP 1894 Message, Block or Component in the same IOTP Transaction using Element 1895 References (see section 3.5). 1897 This section defines the rules for setting the values for the ID 1898 attributes of IOTP Messages, Blocks and Components. 1900 3.4.1 IOTP Message ID Attribute Definition 1902 The ID attribute of the Message Id Component of an IOTP Message must be 1903 unique within an IOTP Transaction. It's definition is as follows: 1905 IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix 1906 IotpMsgIdPrefix ::= NameChar (NameChar)* 1907 IotpMsgIdSuffix ::= Digit (Digit)* 1908 IotpMsgIdPrefix Apart from messages which contain an Inquiry 1909 Request Trading Block (see section 8.12), the same 1910 prefix is used for all messages sent by the 1911 Merchant or Consumer role as follows: 1912 o "M" - Merchant 1913 o "C" - Consumer 1915 For messages which contain an Inquiry Request 1916 Trading Block, the prefix is set to "I" for 1917 Inquiry. 1919 The prefix for the other roles in a trade is 1920 contained within the Organisation Component for 1921 the role and are typically set by the Merchant. 1922 The following is recommended as a guideline and 1923 must not be relied upon: 1924 o "P" - First (only) Payment Handler 1925 o "R" - Second Payment Handler 1926 o "D" - Delivery Handler 1927 o "C" - Deliver To 1929 As a guideline, prefixes should be limited to one 1930 character. 1932 NameChar has the same definition as the [XML] 1933 definition of NameChar. 1935 IotpMsgIdSuffix The suffix consists of one or more digits. The 1936 suffix must be unique within a Trading Role within 1937 an IOTP Transaction. The following is recommended 1938 as a guideline and must not be relied upon: 1939 o the first IOTP Message sent by a trading role 1940 is given the suffix "1" 1941 o the second and subsequent IOTP Messages sent 1942 by the same trading role are incremented by one 1943 for each message 1944 o no leading zeroes are included in the suffix 1946 Put more simply the Message Id Component of the 1947 first IOTP Message sent by a Consumer would have 1948 an ID attribute of, "C1", the second "C2", the 1949 third "C3" etc. 1951 Digit has the same definition as the [XML] 1952 definition of Digit. 1954 3.4.2 Block and Component ID Attribute Definitions 1956 The ID Attribute of Blocks and Components must also be unique within an 1957 IOTP Transaction. Their definition is as follows: 1959 BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix 1960 IdSuffix ::= Digit (Digit)* 1962 IotpMsgId_value The ID attribute of the Message ID Component of 1963 the IOTP Message where the Block or Component is 1964 first used. 1966 In IOTP, Trading Components and Trading Blocks are 1967 copied from one IOTP Message to another. The ID 1968 attribute does not change when an existing Trading 1969 Block or Component is copied to another IOTP 1970 Message. 1972 IdSuffix The suffix consists of one or more digits. The 1973 suffix must be unique within the ID attribute of 1974 the Message ID Component used to generate the ID 1975 attribute. The following is recommended as a 1976 guideline and must not be relied upon: 1977 o the first Block or Component sent by a trading 1978 role is given the suffix "1" 1979 o the ID attributes of the second and subsequent 1980 Blocks or Components are incremented by one for 1981 each new Block or Component added to an IOTP 1982 Message 1983 o no leading zeroes are included in the suffix 1985 Put more simply, the first new Block or Component 1986 added to the second IOTP Message sent, for 1987 example, by a consumer would have a an ID 1988 attribute of "C2.1", the second "C2.2", the third 1989 "C2.3" etc. 1991 Digit has the same definition as the [XML] 1992 definition of Digit. 1994 3.4.3 Example of use of ID Attributes 1996 The diagram below illustrates how ID attribute values are used. 1998 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2000 1st IOTP MESSAGE 2nd IOTP MESSAGE 2001 (e.g. from Merchant to (e.g. from Consumer to 2002 Consumer Payment Handler) 2004 IOTP MESSAGE IOTP MESSAGE * 2005 |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* 2006 | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp. 2007 | | Copy Element | | ID=M1.2 2008 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * 2009 | | 2010 |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* 2011 | |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15 2012 | Copy Element | 2013 |-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 * 2014 | |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4 2015 | | Copy Element | 2016 | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5 2017 | | Copy Element | 2018 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * 2019 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * 2020 | 2021 |-Trading Block. ID=M1.9 2022 |-Comp. ID=M1.10 * = new elements 2023 |-Comp. ID=M1.11 2024 |-Comp. ID=M1.12 2025 |-Comp. ID=M1.13 2027 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2029 Figure 8 Example use of ID attributes 2031 3.5 Element References 2033 A Trading Component or one of its child XML elements, may contain an XML 2034 attribute that refers to another Block (i.e. a Transaction Reference 2035 Block or a Trading Block) or Trading Component (including a Transaction 2036 Id and Signature Component). These Element References are used for many 2037 purposes, a few examples include: 2039 o identifying an XML element whose Digest is included in a Signature 2040 Component, 2042 o referring to the Payment Handler Organisation Component which is used 2043 when making a Payment 2045 An Element Reference always contains the value of an ID attribute of a 2046 Block or Component. 2048 Identifying the IOTP Message, Trading Block or Trading Component which is 2049 referred to by an Element Reference, involves finding the XML element 2050 which: 2052 o belongs to the same IOTP Transaction (i.e. the Transaction Id 2053 Components of the IOTP Messages match), and 2055 o where the value of the ID attribute of the element matches the value of 2056 the Element Reference. 2058 [Note] The term "match" in this specification has the same definition 2059 as the [XML] definition of match. 2060 [Note End] 2062 An example of "matching" an Element Reference is illustrated in the 2063 example below. 2065 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2067 1st IOTP MESSAGE 2nd IOTP MESSAGE 2068 (e.g. from Merchant to (e.g. from Consumer to 2069 Consumer Payment Handler) 2071 IOTP MESSAGE IOTP MESSAGE 2072 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1 2073 | |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2 2074 | | must be | | 2075 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 2076 | ^ | 2077 |-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5 2078 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 2079 | AND | 2080 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 2081 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 2082 | | v | 2083 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 2084 | | and El Ref | 2085 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 2086 | | match--------|--> El Ref=M1.5 2087 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 2088 | 2089 |-Trading Block. ID=M1.9 2090 |-Comp. ID=M1.10 2091 |-Comp. ID=M1.11 2092 |-Comp. ID=M1.12 2093 |-Comp. ID=M1.13 2095 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2097 Figure 9 Element References 2099 [Note] Element Reference attributes are defined as "NMTOKEN" rather 2100 than "IDREF" (see [XML]). This is because an IDREF requires 2101 that the XML element referred to is in the same XML Document. 2102 With IOTP this is not necessarily the case. 2103 [Note End] 2105 3.6 Extending IOTP 2107 Baseline IOTP defines a minimum protocol which systems supporting IOTP 2108 must be able to accept. As new versions of IOTP are developed, additional 2109 types of IOTP Transactions will be defined. In addition to this, Baseline 2110 and future versions of IOTP will support user extensions to IOTP through 2111 two mechanisms: 2113 o extra XML elements, and 2115 o new values for existing IOTP codes. 2117 3.6.1 Extra XML Elements 2119 The XML element and attribute names used within IOTP constitute an [XML 2120 Namespace] as identified by the xmlns attribute on the IotpMessage 2121 element. This allows IOTP to support the inclusion of additional XML 2122 elements within IOTP messages through the use of [XML Namespaces]. 2124 Using XML Namespaces, extra XML elements may be included at any level 2125 within an IOTP message including: 2127 o new Trading Blocks 2129 o new Trading Components 2131 o new XML elements within a Trading Component. 2133 The following rules apply: 2135 o any new XML element must be declared according to the rules for [XML 2136 Namespaces] 2138 o new XML elements which are either Trading Blocks or Trading Components 2139 must contain an ID attributes with an attribute name of ID. 2141 In order to make sure that extra XML elements can be processed properly, 2142 IOTP reserves the use of a special attribute, IOTP:Critical, which takes 2143 the values True or False and may appear in extra elements added to an 2144 IOTP message. 2146 The purpose of this attribute is to allow an IOTP aware application to 2147 determine if the IOTP transaction can safely continue. Specifically: 2149 o if an extra XML element has an "IOTP:Critical" attribute with a value 2150 of "True" and an IOTP aware application does not know how to process 2151 the element and its child elements, then the IOTP transaction has a 2152 Technical Error (see section 4.1) and must fail. 2154 o if an extra XML element has an "IOTP:Critical" attribute with a value 2155 of "False" then the IOTP transaction may continue if the IOTP aware 2156 application does not know how to process it. In this case: 2157 - any extra XML elements contained within an XML element defined within 2158 the IOTP namespace, must be included with that element whenever the 2159 IOTP XML element is used or copied by IOTP 2160 - the content of the extra element must be ignored except that it must 2161 be included when it is used in the creation of a digest as part of 2162 the generation of a signature 2164 o if an extra XML element has no "IOTP:Critical" attribute then it must 2165 be treated as if it had an "IOTP:Critical" attribute with a value of 2166 "True" 2168 o if an XML element contains an "IOTP:Critical" attribute, then the value 2169 of that attribute is assumed to apply to all the child elements within 2170 that element 2172 In order to ensure that documents containing "IOTP:Critical" are valid, 2173 it is declared as part of the DTD for the extra element as: 2175 IOTP:Critical (True | False ) 'True' 2177 3.6.2 Opaque Embedded Data 2179 If IOTP is to be extended using Opaque Embedded Data then a Packaged 2180 Content Element (see section 3.7) should be used to encapsulate the data. 2182 3.7 Packaged Content Element 2184 The Packaged Content element supports the concept of an embedded data 2185 stream, transformed to both protect it against misinterpretation by 2186 transporting systems and to ensure XML compatibility. Examples of its use 2187 in IOTP include: 2189 o to encapsulate payment scheme messages, such as SET messages, 2191 o to encapsulate a description of an order, a payment note, or a delivery 2192 note. 2194 In general it is used to encapsulate one or more data streams. 2196 This data stream has three standardised attributes that allow for 2197 identification, decoding and interpretation of the contents. Its 2198 definition is as follows. 2200 2201 2206 Attributes: 2208 Name Optional. Distinguishes between multiple 2209 occurrences of Packaged Content Elements at the 2210 same point in IOTP. For example: 2211 2212 2213 snroasdfnas934k 2214 2215 2216 dvdsjnl5poidsdsflkjnw45 2217 2218 2220 The name attribute may be omitted, for example if 2221 there is only one Packaged Content element. 2223 Content This identifies what type of data is contained 2224 within the Content of the Packaged Content 2225 Element. The valid values for the Content 2226 attribute are as follows: 2227 o PCDATA. The content of the Packaged Content 2228 Element can be treated as PCDATA with no 2229 further processing. 2230 o MIME. The content of the Packaged Content 2231 Element is a complete MIME item. Processing 2232 should include looking for MIME headers inside 2233 the Packaged Content Element. 2234 o MIME:mimetype. The content of the Packaged 2235 Content Element is MIME content, with the 2236 following header "Content-Type: mimetype". 2237 Although it is possible to have MIME:mimetype 2238 with the Transform attribute set to NONE, it is 2239 far more likely to have Transform attribute set 2240 to BASE64. Note that if Transform is NONE is 2241 used, then the entire content must still 2242 conform to PCDATA. Some characters will need to 2243 be encoded either as the XML default entities, 2244 or as numeric character entities. 2245 o XML. The content of the Packaged Content 2246 Element can be treated as an XML document. 2247 Entities and CDATA sections, or Transform set 2248 to BASE64, must be used to ensure that the 2249 Packaged Content Element contents are 2250 legitimate PCDATA. 2252 Values of the Content attribute are controlled 2253 under the procedures defined in section 12 IANA 2254 Considerations which also allows user defined 2255 values to be defined. 2257 Transform This identifies the transformation that has been 2258 done to the data before it was placed in the 2259 content. Valid values are: 2261 o NONE. The PCDATA content of the Packaged 2262 Content Element is the correct representation 2263 of the data. Note that entity expansion must 2264 occur first (i.e. replacement of & and 2265 ) before the data is examined. CDATA 2266 sections may legitimately occur in a Packaged 2267 Content Element where the Transform attribute 2268 is set to NONE. 2269 o BASE64. The PCDATA content of the Packaged 2270 Content Element represents a BASE64 encoding of 2271 the actual content. 2273 Content: 2275 PCDATA This is the actual data which has been embedded. 2276 The format of the data and rules on how to decode 2277 it are contained in the Content and the Transform 2278 attributes 2280 Note that any special details, especially custom attributes, must be 2281 represented at a higher level. 2283 3.7.1 Packaging HTML 2285 The packaged content may contain HTML. In this case the following 2286 conventions are followed: 2288 o references to any documents, images or other things, such as sounds or 2289 web pages, which can affect the recipient's understanding of the data 2290 which is being packaged must refer to other Packaged Elements contained 2291 within the same parent element, e.g. an Order Description 2293 o if more than one Packaged Content element is included within a parent 2294 element in order to meet the previous requirement, then the Name 2295 attribute of the top level Packaged Content from which references to 2296 all other Packaged Elements can be determined, should have a value of 2297 Main 2299 o relative references to other documents, images, etc. from one Packaged 2300 Content element to another are realised by setting the value of the 2301 relative reference to the Name attribute of another Packaged Content 2302 element at the same level and within the same parent element 2304 o no external references that require the reference to be resolved 2305 immediately should be used. As this could make the HTML difficult or 2306 impossible to display completely 2308 o [MIME] is used to encapsulate the data inside each Packaged Element. 2309 This means that the information in the MIME header used to identify the 2310 type of data which has been encapsulated and therefore how it should be 2311 displayed. 2313 If the above conventions are not followed by, for example, including 2314 external references which must be resolved, then the recipient of the 2315 HTML should be informed. 2317 [Note] As an implementation guideline the values of the Name 2318 Attributes allocated to Packaged Content elements should make 2319 it possible to extract each Packaged Content into a directory 2320 and then display the HTML directly 2321 [Note End] 2323 3.7.2 Packaging XML 2325 Support for XML is recommended. When XML needs to be displayed, for 2326 example to display the content of an Order Description to a Consumer, 2327 then implementers should follow the latest recommendations of the World 2328 Wide Web Consortium. 2330 [Note] At the time of writing this specification, standards are under 2331 development that specify XML style sheets that show how XML 2332 documents should be displayed. See: 2333 o "Extensible Stylesheet Language (XSL) Specification" at 2334 http://www.w3.org/TR/WD-xsl, and 2335 o "Associating stylesheets with XML documents" at 2336 http://www.w3.org/TR/xml-stylesheet. 2338 Once these standards become W3C "Recommendations", then it is 2339 anticipated that this specification will be amended if 2340 practical. 2341 [Note End] 2343 3.8 Identifying Languages 2345 IOTP uses [XML] Language Identification to specify which languages are 2346 used within the content and attributes of IOTP Messages. 2348 The following principles have been used in order to determine which XML 2349 elements contain an xml:lang Attributes: 2351 o a mandatory xml:lang attribute is contained on every Trading Component 2352 which contains attributes or content which may need to be displayed or 2353 printed in a particular language 2355 o an optional xml:lang attribute is included on child elements of these 2356 Trading Components. In this case the value of xml:lang, if present, 2357 overrides the value for the Trading Component. 2359 xml:lang attributes which follow these principles are included in the 2360 Trading Components and their child XML elements defined in section 7. 2362 A sender of a message, typically a Consumer can indicate a preference for 2363 a language, and a character set by specifying a list of preferred 2364 languages/character sets in a Message Id Component (see section 3.3.2). 2365 Note that there is no obligation on the receiver of such a message to 2366 respond using one of the listed languages/character sets as they may not 2367 have the technology to be able to do it. It also means that the ability 2368 to handle these lists is not a requirement for conformance to this 2369 specification. However the ability to respond, for example using one of 2370 the stated languages/character sets is likely to provide a better user 2371 experience. 2373 3.9 Secure and Insecure Net Locations 2375 IOTP contains several "Net Locations" which identify places where, 2376 typically, IOTP Messages may be sent. Net Locations come in two types: 2378 o "Secure" Net Locations which are net locations where privacy of data is 2379 secured using, for example, encryption methods such as [SSL/TLS], and 2381 o "Insecure" Net Locations where privacy of data is not assured. 2383 Note that either a Secure Net Location or an Insecure Net Location or 2384 both must be present. 2386 If only one of the two Net Locations is present, then the one present 2387 must be used. 2389 Where both types of net location are present then either may be used 2390 depending on the preference of the sender of the message. 2392 3.10 Cancelled Transactions 2394 Any Trading Role involved in an IOTP transaction may cancel that 2395 transaction at any time. 2397 3.10.1 Cancelling Transactions 2399 IOTP Transactions are cancelled by sending an IOTP message containing 2400 just a Cancel Block with an appropriate Status Component to the other 2401 Trading Role involved in the Trading Exchange. 2403 [Note] The Cancel Block can be sent asynchronously of any other IOTP 2404 Message. Specifically it can be sent either before sending or 2405 after receiving an IOTP Message from the other Trading Role 2406 [Note End] 2408 If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the 2409 interval between sending a "request" block and receiving the matching 2410 "response" block) then the Cancel Block is sent to the same location as 2411 the next IOTP Message in the Trading Exchange would have been sent. 2413 If a Consumer cancels a transaction after a Trading Exchange has 2414 completed (i.e. the "response" block for the Trading Exchange has been 2415 received), but before the IOTP Transaction has finished then the Consumer 2416 sends a Cancel Block with an appropriate Status Component to the net 2417 location identified by the SenderNetLocn or SecureSenderNetLocn contained 2418 in the Protocol Options Component (see section 7.1) contained in the TPO 2419 Block (see section 8.1) for the transaction. This is normally the 2420 Merchant Trading Role. 2422 A Consumer should not send a Cancel Block after the IOTP Transaction has 2423 completed. Cancelling a complete transaction should be treated as a 2424 technical error. 2426 After cancelling the IOTP Transaction, the Consumer should go to the net 2427 location specified by the CancelNetLocn attribute contained in the 2428 Trading Role Element for the Organisation that was sent the Cancel Block. 2430 A non-Consumer Trading Role should only cancel a transaction: 2432 o after a request block has been received and 2434 o before the response block has been sent 2436 If a non-Consumer Trading Role cancels a transaction at any other time it 2437 should be treated by the recipient as an error. 2439 3.10.2 Handling Cancelled Transactions 2441 If a Cancel Block is received by a Consumer at a point in the IOTP 2442 Transaction when cancellation is allowed, then the Consumer should stop 2443 the transaction. 2445 If a Cancel Block is received by a non-Consumer role, then the Trading 2446 Role should anticipate that the Consumer may go to the location specified 2447 by the CancelNetLocn attribute contained in the Trading Role Element for 2448 the Trading Role. 2450 4. IOTP Error Handling 2452 IOTP is designed as a request/response protocol where each message is 2453 composed of a number of Trading Blocks which contain a number of Trading 2454 Components. There are several interrelated considerations in handling 2455 errors, re-transmissions, duplicates, and the like. These factors mean 2456 IOTP aware applications must manage message flows more complex than the 2457 simple request/response model. Also a wide variety of errors can occur in 2458 messages as well as at the transport level or in Trading Blocks or 2459 Components. 2461 This section describes at a high level how IOTP handles errors, retries 2462 and idempotency. It covers: 2464 o the different types of errors which can occur. This is divided into: 2465 - "technical errors" which are independent of the purpose of the IOTP 2466 Message, 2467 - "business errors" which indicate that there is a problem specific to 2468 the process (e.g. payment or delivery) which is being carried out, 2469 and 2471 o the depth of the error which indicates whether the error is at the 2472 transport, message or block/component level 2474 o how the different trading roles should handle the different types of 2475 messages which they may receive. 2477 4.1 Technical Errors 2479 Technical Errors are those which are independent of the meaning of the 2480 message. This means, they can affect any attempt at IOTP communication. 2481 Typically they are handled in a standard fashion with a limited number of 2482 standard options for the user. Specifically these are: 2484 o retrying the transmission, or 2486 o cancelling the transaction. 2488 When communications are operating sufficiently well, a technical error is 2489 indicated by an Error Component (see section 7.21) in an Error Block (see 2490 section 8.17) sent by the party which detected the error in an IOTP 2491 message to the party which sent the erroneous message. 2493 If communications are too poor, a message which was sent may not reach 2494 its destination. In this case a time-out might occur. 2496 The Error Codes associated with Technical Errors are recorded in the 2497 Error Component which lists all the different technical errors which can 2498 be set. 2500 4.2 Business Errors 2502 Business Errors may occur when the IOTP messages are "technically" 2503 correct. They are connected with a particular process, for example, an 2504 offer, payment, delivery or authentication, where each process has a 2505 different set of possible business errors. 2507 For example, "Insufficient funds" is a reasonable payment error but makes 2508 no sense for a delivery while "Back ordered" is a reasonable delivery 2509 error but not meaningful for a payment. Business errors are indicated in 2510 the Status Component (see section 7.16) of a "response block" of the 2511 appropriate type, for example a Payment Response Block or a Delivery 2512 Response Block. This allows whatever additional response related 2513 information is needed to accompany the error indication. 2515 Business errors must usually be presented to the user so that they can 2516 decide what to do next. For example, if the error is insufficient funds 2517 in a Brand Independent Offer (see section 9.1.2.2), the user might wish 2518 to choose a different payment instrument/account of the same brand or a 2519 different brand or payment system. Alternatively, if the IOTP based 2520 implementation allows it and it makes sense for that instrument, the user 2521 might want to put more funds into the instrument/account and try again. 2523 4.3 Error Depth 2525 The three levels at which IOTP errors can occur are the transport level, 2526 the message level, and the block level. Each is described below. 2528 4.3.1 Transport Level 2530 This level of error indicates a fundamental problem in the transport 2531 mechanism over which the IOTP communication is taking place. 2533 All transport level errors are technical errors and are indicated by 2534 either an explicit transport level error indication, such as a "No route 2535 to destination" error from TCP/IP, or by a time out where no response has 2536 been received to a request. 2538 The only reasonable automatic action when faced with transport level 2539 errors is to retry and, after some number of automatic retries, to inform 2540 the user. 2542 The explicit error indications that can be received are transport 2543 dependent and the documentation for the appropriate IOTP Transport 2544 supplement should be consulted for errors and appropriate actions. 2546 Appropriate time outs to use are a function of both the transport being 2547 used and of the payment system if the request encapsulates payment 2548 information. The transport and payment system specific documentation 2549 should be consulted for time out and automatic retry parameters. 2550 Frequently there is no way to directly inform the other party of 2551 transport level errors but they should generally be logged and if 2552 automatic recovery is unsuccessful and there is a human user, the user 2553 should be informed. 2555 4.3.2 Message Level 2557 This level of error indicates a fundamental technical problem with an 2558 entire IOTP message. For example, the XML is not "Well Formed", or the 2559 message is too large for the receiver to handle or there are errors in 2560 the Transaction Reference Block (see section 3.3) so it is not possible 2561 to figure out what transaction the message relates to. 2563 All message level errors are technical errors and are indicated by Error 2564 Components (see section 7.21) sent to the other party. The Error 2565 Component includes a Severity attribute which indicates whether the error 2566 is a Warning and may be ignored, a TransientError which indicates that a 2567 retry may resolve the problem or a HardError in which case the 2568 transaction must fail. 2570 The Technical Errors (see section 7.21.2 Error Codes) that are Message 2571 Level errors are: 2573 o XML not well formed. The document is not well formed XML (see [XML]) 2575 o XML not valid. The document is not valid XML (see [XML]) 2577 o block level technical errors (see section 4.3.3) on the Transaction 2578 Reference Block (see section 3.3) and the Signature Block only. Checks 2579 on these blocks should only be carried out if the XML is valid 2581 Note that checks on the Signature Block include checking, where possible, 2582 that each Signature Component is correctly calculated. If the Signature 2583 is incorrectly calculated then the data that should have been covered by 2584 the signature can not be trusted and must be treated as erroneous. A 2585 description of how to check a signature is correctly calculated is 2586 contained in section 6.2. 2588 4.3.3 Block Level 2590 A Block level error indicates a problem with a block or one of its 2591 components in an IOTP message (apart from Transaction Reference or 2592 Signature Blocks). The message has been transported properly, the overall 2593 message structure and the block/component(s) including the Transaction 2594 Reference and Signature Blocks are meaningful but there is some error 2595 related to one of the other blocks. 2597 Block level errors can be either: 2599 o technical errors, or 2601 o business errors 2602 Technical Errors are further divided into: 2604 o Block Level Attribute and Element Checks, and 2606 o Block and Component Consistency Checks 2608 o Transient Technical Errors 2610 If a technical error occurs related to a block or component, then an 2611 Error Component is generated for return. 2613 4.3.3.1 Block Level Attribute and Element Checks 2615 Block Level Attribute and Element Checks occur only within the same 2616 block. Checks which involve cross-checking against other blocks are 2617 covered by Block and Component Consistency Checks. 2619 The Block Level Attribute & Element checks are: 2621 o checking that each attribute value within each element in a block 2622 conforms to any rules contained within this IOTP specification 2624 o checking that the content of each element conforms to any rules 2625 contained within this IOTP specification 2627 o if the previous checks are OK, then checking the consistency of 2628 attribute values and element content against other attribute values or 2629 element content within any other components in the same block. 2631 4.3.3.2 Block and Component Consistency Checks 2633 Block and Component Consistency Checks consist of: 2635 o checking that the combination of blocks and/or components present in 2636 the IOTP Message are consistent with the rules contained within this 2637 IOTP specification 2639 o checking for consistency between attributes and element content within 2640 the blocks within the same IOTP message. 2642 o checking for consistency between attributes and elements in blocks in 2643 this IOTP message and blocks received in earlier IOTP messages for the 2644 same IOTP transaction 2646 If the block passes the "Block Level Attribute and Element Checks" and 2647 the "Block and Component Consistency Checks" then it is processed either 2648 by the IOTP Aware application or perhaps by some "back-end" system such 2649 as a payment server. 2651 4.3.3.3 Transient Technical Errors 2653 During the processing of the Block some temporary failure may occur that 2654 can potentially be recovered by the other trading role re-transmitting, 2655 at some slightly later time, the original message that they sent. 2657 In this case the other role is informed of the Transient Error by sending 2658 them an Error Component (see section 7.21) with the Severity Attribute 2659 set to TransientError and the MinRetrySecs attribute set to some value 2660 suitable for the Transport Mechanism and/or payment protocol being used 2661 (see appropriate Transport and payment protocol Supplements). 2663 Note that transient technical errors can be generated by any of the 2664 Trading Roles involved in transaction. 2666 4.3.3.4 Block Level Business Errors 2668 If a business error occurs in a process such as a Payment or a Delivery, 2669 then the appropriate type of response block is returned containing a 2670 Status Component (see section 7.16) with the ProcessState attribute set 2671 to Failed and the CompletionCode indicating the nature of the problem. 2673 Some business errors may be "transient" in that the Consumer role may be 2674 able to recover and complete the transaction in some other way. For 2675 example if the Credit Card that a consumer provided had insufficient 2676 funds for a purchase, then the Consumer may recover by using a different 2677 credit card. 2679 Recovery from "transient" business errors is dependent on the 2680 CompletionCode. See the definition of the Status Component for what is 2681 possible. 2683 Note that no Error Component or Error Block is generated for business 2684 errors. 2686 4.4 Idempotency, Processing Sequence, and Message Flow 2688 IOTP messages are actually a combination of blocks and components as 2689 described in 3.1.1 IOTP Message Structure. Especially in future 2690 extensions of IOTP, a rich variety of combinations of such blocks and 2691 components can occur. It is important that the multiple 2692 transmission/receipt of the "same" request for an action that will change 2693 state does not result in that action occurring more than once. This is 2694 called idempotency. For example, a customer paying for an order would 2695 want to pay the full amount only once. Most network transport mechanisms 2696 have some probability of delivering a message more than once or not at 2697 all, perhaps requiring retransmission. On the other hand, a request for 2698 status can reasonably be repeated and should be processed fresh each time 2699 it is received. 2701 Correct implementation of IOTP can be modelled by a particular processing 2702 order as detailed below. Any other method that is indistinguishable in 2703 the messages sent between the parties is equally acceptable. 2705 4.5 Server Role Processing Sequence 2707 "Server roles" are any Trading Role which is not the Consumer role. They 2708 are "Server roles" since they typically receive a request which they must 2709 service and then produce a response. However server roles can also 2710 initiate transactions. More specifically Server Roles must be able to: 2712 o Initiate a transaction (see section 4.5.1). These are divided into: 2713 - payment related transactions and 2714 - infrastructure transactions 2716 o Accept and process a message received from another role (see section 2717 4.5.2). This includes: 2718 - identifying if the message belongs to a transaction that has been 2719 received before 2720 - handling duplicate messages 2721 - generating Transient errors if the servers that process the input 2722 message are too busy to handle it 2723 - processing the message if it is error free, authorised and, if 2724 appropriate, producing a response to send back to the other role 2726 o Cancel a current transaction if requested (see section 4.5.3) 2728 o Re-transmit messages if a response was expected but has not been 2729 received in a reasonable time (see section 4.5.4). 2731 4.5.1 Initiating Transactions 2733 Server Roles may initiate a variety of different types of transaction. 2734 Specifically: 2736 o an Inquiry Transaction (see section 9.2.1) 2738 o a Ping Transaction (see section 9.2.2) 2740 o an Authentication Transaction (see section 9.1.6) 2742 o a Payment Related Transaction such as: 2743 - a Deposit (see section 9.1.7) 2744 - a Purchase (see section 9.1.8) 2745 - a Refund (see section 9.1.9) 2746 - a Withdrawal (see section 9.1.10) 2747 - a Value Exchange (see section 9.1.11) 2749 4.5.2 Processing Input Messages 2751 Processing input messages involves the following: 2753 o checking the structure and identity of the message 2755 o checking for and handling duplicate messages 2756 o processing non-duplicate original messages which includes: 2757 - checking for errors, then if no errors are found 2758 - processing the message to produce an output message if appropriate 2760 Each of these is discussed in more detail below. 2762 4.5.2.1 Checking Structure and Message Identity 2764 It is critical to check that the message is "well formed" XML and that 2765 the transaction identifier (IotpTransId attribute on the TransId 2766 Component) within the IOTP message can be successfully identified since 2767 an IotpTransId will be needed to generate a response. 2769 If the input message is not well formed then generate an Error Component 2770 with a Severity of HardError and ErrorCode of XmlNotWellFrmd. 2772 If the message is well formed but the IotpTransId cannot be identified 2773 then generate an ErrorComponent with: 2775 o a Severity of HardError and an ErrorCode of AttMissing, 2777 o a PackagedContent containing "IotpTransId" - the missing attribute. 2779 Insert the Error Component inside an Error Block with a new TransactionId 2780 component with a new IotpTransId and return it to the sender of the 2781 original message. 2783 4.5.2.2 Checking/Handling Duplicate Messages 2785 If the input message can be identified as potentially a valid input 2786 message then check to see if an "identical" input message has been 2787 received before. Identical means that all blocks, components, elements, 2788 attribute values and element content in the input message are the same. 2790 [Note] The recommended way of checking for identical messages is to 2791 check for equal values of their [DOM-HASH] 2792 [Note End] 2794 If an identical message has been received before then check to see if the 2795 processing of the previous message has completed. 2797 If processing has not completed then generate an Error Component with a 2798 Severity of Transient Error and an Error Code of MsgBeingProc to indicate 2799 the message is being processed and send it back to the sender of the 2800 Input Message requesting that the original message be resent after an 2801 appropriate period of time. 2803 Otherwise, if processing has completed and resulted in an output message 2804 then retrieve the last message that was sent and send it again. 2806 If the message is not a duplicate then it should be processed. 2808 4.5.2.3 Processing Non-Duplicate Message 2810 Once it's been established that the message is not a duplicate, then it 2811 can be processed. This involves: 2813 o checking that a server is available to handle the message, generating a 2814 Transient Error if it is not 2816 o checking the Transaction is Not Already in error or cancelled 2818 o validating the input message. This includes: 2819 - checking for message level errors 2820 - checking for block level errors 2821 - checking any encapsulated data 2823 o checking for errors in the sequence that blocks have been received 2825 o generating error components for any errors that result 2827 o if neither hard errors nor transient errors result, then processing the 2828 message and generating an output message, if required, for return to 2829 the sender of the Input Message 2831 [Note] This approach to handling of duplicate input messages means, 2832 if absolutely "identical" messages are received then 2833 absolutely "identical" messages are returned. This also 2834 applies to Inquiry and Ping transactions when in reality the 2835 state of a transaction or the processing ability of the 2836 servers may have changed. If up-to-date status of transactions 2837 or servers is required, then an IOTP transaction with a new 2838 value for the ID attribute of the MsgId component must be 2839 used. 2840 [Note End] 2842 Each of the above steps is discussed below. 2844 CHECKING A SERVER IS AVAILABLE 2846 The process that is handling the input message should check that the rest 2847 of the system is not so busy that a response in a reasonable time cannot 2848 be produced. 2850 If the server is too busy, then it should generate an Error Component 2851 with a Severity of Transient Error and an Error Code of SystemBusy and 2852 send it back to the sender of the Input Message requesting that the 2853 original message be resent after an appropriate period of time. 2855 [Note] Some servers may occasionally become very busy due to 2856 unexpected increases in workload. This approach allows short 2857 peaks in workloads to be handled by delaying the input of 2858 messages by asking the sender of the message to resubmit 2859 later. 2860 [Note End] 2861 CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED 2863 Check that: 2865 o previous messages received or sent did not contain or result in Hard 2866 Errors, and 2868 o the Transaction has not been cancelled by either the Consumer or the 2869 Server Trading Role 2871 If it has then, ignore the message. A transaction with hard errors or 2872 that has been cancelled, cannot be restarted. 2874 CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS 2876 If the transaction is still OK then check for message level errors. This 2877 involves: 2879 o checking the XML is valid 2881 o checking that the elements, attributes and content of the Transaction 2882 Reference Block are without error and conform to this specification 2884 o checking the digital signature which involves: 2885 - checking that the Signature value is correctly calculated, and 2886 - the hash values in the digests are correctly calculated where the 2887 source of the hash value is available. 2889 Checking for block level errors involves: 2891 o checking within each block (apart from the Transaction Reference Block) 2892 that: 2893 - the attributes, elements and element contents are valid 2894 - the values of the attributes, elements and element contents are 2895 consistent within the block 2897 o checking that the combination of blocks are valid 2899 o checking that the values of the attribute, elements and element 2900 contents are consistent between the blocks in the input message and 2901 blocks in earlier messages either sent or received. This includes 2902 checking that the presence of a block is valid for a particular 2903 transaction type 2905 If the message contains any encapsulated data, then if possible check the 2906 encapsulated data for errors using additional software to check the data 2907 where appropriate. 2909 4.5.2.4 Check for Errors in Block Sequence 2911 Errors in the sequence that blocks arrive depends on the block. Blocks 2912 where checking for sequence is required are: 2914 o Error and Cancel Blocks. If an Error or Cancel Block refers to an IOTP 2915 transaction that is not recognised then it is a Hard Error. Do not 2916 return an error if Error or Cancel Blocks have been received for the 2917 IOTP Transaction before to avoid looping. 2919 o Inquiry Request and Response Blocks. If an Inquiry Request or an 2920 Inquiry Response Block refers to an IOTP transaction that is not 2921 recognised then it is a Hard Error 2923 o Authentication Request Block. If an Authentication Request Block refers 2924 to an IOTP transaction that is recognised it is a Hard Error 2926 o Authentication Response Block. Check as follows: 2927 - if an Authentication Response Block does not refer to an IOTP 2928 transaction that is recognised it is a Hard Error, otherwise 2929 - if the Authentication Response Block doesn't refer to an 2930 Authentication Request that had been previously sent then it is a 2931 Hard Error, otherwise 2932 - if an Authentication Response for the same IOTP transaction has been 2933 received before and the Authentication was successful then it is a 2934 Hard Error. 2936 o Authentication Status Block. Check as follows: 2937 - if an Authentication Status Block does not refer to an IOTP 2938 transaction that is recognised it is a Hard Error, otherwise 2939 - if the Authentication Status Block doesn't refer to an Authentication 2940 Response that had been previously sent then it is a Hard Error, 2941 otherwise 2942 - if an Authentication Status for the same IOTP transaction has been 2943 received before then it is a Warning Error 2945 o TPO Selection Block (Merchant only). Check as follows: 2946 - if the TPO Selection Block doesn't refer to an IOTP Transaction that 2947 is recognised then it is a Hard Error, otherwise 2948 - if the TPO Selection Block refers to an IOTP Transaction where a TPO 2949 Block and Offer Response (in one message) had previously been sent 2950 then it is a Hard Error, otherwise 2951 - if the TPO Selection Block does not refer to an IOTP Transaction 2952 where a TPO Block only (i.e. without an Offer Response) had 2953 previously been sent then it is a Hard Error, otherwise 2954 - if a TPO Selection Block for the same TPO Block has been received 2955 before then it is a Hard Error 2957 o Payment Request Block (Payment Handler only). Check as follows: 2958 - if the Payment Request Block refers to an IOTP Transaction that is 2959 not recognised then its OK, otherwise 2960 - if the Payment Request Block refers to IOTP Transaction that was not 2961 for a Payment then it is a Hard Error, otherwise 2962 - if the previous payment CompletedOk OR failed with a non-recoverable 2963 Completion Code then it is a Hard Error, otherwise 2964 - if the previous payment is still in progress then it is a Hard Error 2966 o Payment Exchange Block (Payment Handler only). Check as follows: 2968 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 2969 that is recognised then it is a Hard Error, otherwise 2970 - if the Payment Exchange doesn't refer to an IOTP Transaction where a 2971 Payment Exchange had previously been sent then it a Hard Error 2973 o Delivery Request (Delivery Handler Only). If the Delivery Request Block 2974 refers to an IOTP Transaction that is recognised by the Server then it 2975 is a Hard Error 2977 If any Error Components have been generated then collect them into an 2978 Error Block for sending to the sender of the Input message. Note that 2979 Error Blocks should be sent back to the sender of the message and to the 2980 ErrorLogNetLocn for the Trading Role of the sender if one is specified. 2982 [Note] The above checking on the sequence of Authentication Responses 2983 and Payment Requests supports the Consumer re-submitting a 2984 repeat action request since the previous one failed, for 2985 example: 2986 o because they did not know the correct response (e.g. a 2987 password) on an authentication or, 2988 o they were unable to pay as there were insufficient funds on 2989 a credit card 2990 [Note End] 2992 PROCESS THE ERROR FREE INPUT MESSAGE 2994 If the input message passes the previous checks then it can be processed 2995 to produce an output message if required. Note that: 2997 o Inquiry Requests on Ping Transactions should be ignored 2999 o if the Input message contains an Error Block with a Transient Error 3000 then wait for the required time then resend the previous message, if a 3001 response to the earlier message has not been received 3003 o if the input message contains a Error Component with a HardError or a 3004 Cancel Block then stop all further processing of the transaction. This 3005 includes suppressing the sending of any messages currently being 3006 generated or responding to any new non-duplicate messages that are 3007 received 3009 o processing of encapsulated messages (e.g. Payment Protocol Messages) 3010 may result in additional transient errors 3012 o a digital signature can only safely be generated once all the blocks 3013 and components have been generated and it is known which elements in 3014 the message need to be signed. 3016 If an output message is generated then it should be saved so that it can 3017 be resent as required if an identical input message is received again. 3018 Note that output messages that contain transient errors are not saved so 3019 that they can be processed afresh when the input message is received 3020 again. 3022 4.5.3 Cancelling a Transaction 3024 This process is used to cancel a transaction running on an IOTP server. 3025 It is initiated by some other process as a result of an external request 3026 from another system or server that is being run by the same Trading Role. 3027 The processing required is as follows: 3029 o if the IotpTransId of the transaction to be cancelled is not 3030 recognised, or complete then fail the request, otherwise 3032 o if the IotpTransId refers to a Ping Transaction then fail the request, 3033 otherwise 3035 o determine which Document Exchange to cancel and generate a Cancel Block 3036 and send it to the other party 3038 [Note] Cancelling a transaction on an IOTP server typically arises 3039 for a business reason. For example a merchant may have 3040 attempted authentication several times without success and as 3041 a result decides to cancel the transaction. Therefore the 3042 process that decides to take this action needs to send a 3043 message from the process/server that made the business 3044 decision to the IOTP server with the instruction that the IOTP 3045 transaction should be cancelled. 3046 [Note End] 3048 4.5.4 Retransmitting Messages 3050 The server should periodically check for transactions where a message is 3051 expected in return but none has been received after a time that is 3052 dependent on factors such as: 3054 o the Transport Mechanism being used; 3056 o the time required to process encapsulated messages (e.g. Payment 3057 messages) and 3059 o whether or not human input is required. 3061 If no message has been received the original message should be resent. 3062 This should occur up to a maximum number of times dependent on the 3063 reliability of the Transport Mechanism being used. 3065 If no response is received after the required time then the Transaction 3066 should be "timed out". In this case, set the process state of the 3067 transaction to Failed, and a completion code of either: 3069 o TimedOutRcvr if the transaction can potentially recovered later, or 3071 o TimedOutNoRcvr if the transaction is non-recoverable 3073 4.6 Client Role Processing Sequence 3075 The "Client role" in IOTP is the Consumer Trading Role. 3077 [Note] A company or Organisation that is a Merchant, for example, may 3078 take on the Trading Role of a Consumer when making purchases 3079 or downloading or withdrawing electronic cash. 3080 [Note End] 3082 More specifically the Consumer Role must be able to: 3084 o Initiate a transaction (see section 4.6.1). These are divided into: 3085 - payment related transactions and 3086 - infrastructure transactions 3088 o Accept and process a message received from another role (see section 3089 4.6.2). This includes: 3090 - identifying if the message belongs to a transaction that has been 3091 received before 3092 - handling duplicate messages 3093 - generating Transient errors if the servers that process the input 3094 message are too busy to handle it 3095 - processing the message if it is error free and, if appropriate, 3096 producing a response to send back to the other role 3098 o Cancel a current transaction if requested, for example by the User (see 3099 section 4.6.3) 3101 o Re-transmit messages if a response was expected but has not been 3102 received in a reasonable time (see section 4.6.4). 3104 4.6.1 Initiating Transactions 3106 The Consumer Role may initiate a number of different types of 3107 transaction. Specifically: 3109 o an Inquiry Transaction (see section 9.2.1) 3111 o a Ping Transaction (see section 9.2.2) 3113 o an Authentication Transaction (see section 9.1.6) 3115 4.6.2 Processing Input Messages 3117 Processing of Input Messages for a Consumer Role is the same as for an 3118 IOTP Server (see section 4.5.2) except in the area of checking for Errors 3119 in Block Sequence (for an IOTP Server see section 4.5.2.4). This is 3120 described below 3122 [Note] The description of the processing for an IOTP Server includes 3123 consideration of multi-threading of input messages and multi- 3124 tasking of requests. For the Consumer Role - particularly if 3125 running on a stand-alone system such as a PC - use of multi- 3126 threading is a decision of the implementer of the consumer 3127 role IOTP solution. 3128 [Note End] 3130 4.6.2.1 Check for Errors in Block Sequence 3132 The handling of the following blocks is the same as for an IOTP Server 3133 (see section 4.5.2.4) except that the Consumer Role is substituted for 3134 IOTP Server Role: 3136 o Error and Cancel Blocks, 3138 o Inquiry Request and Response Blocks, 3140 o Authentication Request, Response and Status Blocks. 3142 For the other blocks a Consumer role might receive, the potential errors 3143 in the sequence that blocks arrive depends on the block. Blocks where 3144 checking for sequence is required are: 3146 o TPO Block. Check as follows: 3147 - if the input message also contains an Authentication Request block 3148 and an Offer Response Block then there is a Hard Error, otherwise 3149 - if the input message also contains an Authentication Request block 3150 and Authentication Status block then there is Hard Error otherwise, 3151 - if the input message also contains an Authentication Request block 3152 and the IOTP Transaction is recognised by the Consumer role's system, 3153 then there is a Hard Error, otherwise 3154 - if the input message also contains an Authentication Status block and 3155 the IOTP Transaction is not recognised by the Consumer role's system 3156 then there is a Hard Error, otherwise 3157 - if input message also contains an Authentication Status Block and the 3158 Authentication Status Block has not been sent after an earlier 3159 Authentication Response message then there is a hard error 3160 - if input message also contains an Offer Response Block and the IOTP 3161 Transaction is recognised by the Consumer role's system then there is 3162 a Hard Error, otherwise 3163 - if the TPO Block occurs on its own and the IOTP Transaction is 3164 recognised by the Consumer role's system then there is a Hard Error 3166 o Offer Response Block. Check as follows: 3167 - if the Offer Response Block is part of a Brand Independent Offer 3168 Exchange (see section 9.1.2.2) then there is no sequence checking as 3169 it is part of the first message received, otherwise 3170 - if the Offer Response Block is not part of an IOTP Transaction that 3171 is recognised by the Consumer role then there is a Hard Error, 3172 otherwise 3173 - if the Offer Response Block does not refer to an IOTP transaction 3174 where a TPO Selection Block was the last message sent then there is a 3175 Hard Error 3177 o Payment Exchange Block. Check as follows: 3179 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 3180 that is recognised by the Consumer role's system then there is a Hard 3181 Error, otherwise 3182 - if the Payment Exchange doesn't refer to an IOTP Transaction where 3183 either a Payment Request or a Payment Exchange block was most 3184 recently sent then there is a Hard Error 3186 o Payment Response Block. Check as follows: 3187 - if the Payment Response Block doesn't refer to an IOTP Transaction 3188 that is recognised by the Consumer role's system then there is a Hard 3189 Error, otherwise 3190 - if the Payment Response doesn't refer to an IOTOP Transaction where 3191 either a Payment Request or a Payment Exchange block was most 3192 recently sent then there is a Hard Error 3194 o Delivery Response Block. Check as follows: 3195 - if the Delivery Response Block doesn't refer to an IOTP Transaction 3196 that is recognised by the Consumer role's system then there is a Hard 3197 Error, otherwise 3198 - If the Delivery Response doesn't refer to an IOTP Transaction where 3199 either a Payment Request or a Payment Exchange block was most 3200 recently sent then there is a Hard Error 3202 4.6.3 Cancelling a Transaction 3204 This process cancels a current transaction on an Consumer role's system 3205 as a result of an external request from the user, or another system or 3206 server in the Consumer's role. The processing is the same as for an IOTP 3207 Server (see section 4.5.3). 3209 4.6.4 Retransmitting Messages 3211 The process of retransmitting messages is the same as for an IOTP Server 3212 (see section 4.5.4). 3214 5. Security Considerations 3216 This section considers, from an IETF perspective how IOTP addresses 3217 security. The next section (see section 6. Digital Signatures and IOTP) 3218 describes how IOTP uses Digital Signatures when these are needed. 3220 This section covers: 3222 o determining whether to use digital signatures 3224 o data privacy, and 3226 o payment protocol security. 3228 5.1 Determining whether to use digital signatures 3230 The use of digital signatures within IOTP are entirely optional. IOTP can 3231 work successfully entirely without the use of digital signatures. 3233 Ultimately it is up to the Merchant, or other trading role, to decide 3234 whether IOTP Messages will include signatures, and for the Consumer to 3235 decide whether carrying out a transaction without signatures is an 3236 acceptable risk. If Merchants discover that transactions without 3237 signatures are not being accepted, then they will either: 3239 o start using signatures, 3241 o find a method of working which does not need signatures, or 3243 o accept a lower volume and value of business. 3245 A non-exhaustive list of the reasons why digital signatures might be used 3246 follows: 3248 o the Merchant (or other trading role) wants to demonstrate that they can 3249 be trusted. If, for example, a merchant generates an Offer Response 3250 Signature (see section 7.19.2) using a certificate from a trusted third 3251 party, known to the Consumer, then the Consumer can check the signature 3252 and certificate and so more reasonably rely on the offer being from the 3253 actual Organisation the Merchant claims to be. In this case signatures 3254 using asymmetric cryptography are likely to be required 3256 o the Merchant, or other Trading Role, want to generate a record of the 3257 transaction that is fit for a particular purpose. For example, with 3258 appropriate trust hierarchies, digital signatures could be checked by 3259 the Consumer to determine: 3260 - if it would be accepted by tax authorities as a valid record of a 3261 transaction, or 3262 - if some warranty, for example from a "Better Business Bureau" or 3263 similar was being provided 3265 o the Payment Handler, or Delivery Handler, needs to know that the 3266 request is unaltered and authorised. For example, in IOTP, details of 3267 how much to pay is sent to the Consumer in the Offer Response and then 3268 forwarded to the Payment Handler in a Payment Request. If the request 3269 is not signed, the Consumer could change the amount due by, for 3270 example, removing a digit. If the Payment Handler has no access to the 3271 original payment information in the Offer Response, then, without 3272 signatures, the Payment Handler cannot be sure that the data has not 3273 been altered. Similarly, if the payment information is not digitally 3274 signed, the Payment Handler cannot be sure who is the Merchant that is 3275 requesting the payment 3277 o a Payment Handler or Delivery Handler wants to provide a non-refutable 3278 record of the completion status of a Payment or Delivery. If a Payment 3279 Response or Delivery Response is signed, then the Consumer can later 3280 use the record of the Payment or Delivery to prove that it occurred. 3281 This could be used, for example, for customer care purposes. 3283 A non-exhaustive list of the reasons why digital signatures might not be 3284 used follows: 3286 o trading roles are combined therefore changes to data made by the 3287 consumer can be detected. One of the reasons for using signatures is so 3288 that one trading role can determine if data has been changed by the 3289 Consumer or some other party. However if the trading roles have access 3290 to the necessary data, then it might be possible to compare, for 3291 example, the payment information in the Payment Request with the 3292 payment information in the Offer Response. Access to the data necessary 3293 could be realised by, for example, the Merchant and Payment Handler 3294 roles being carried out by the same Organisation on the same system, or 3295 the Merchant and Payment Handler roles being carried out on different 3296 systems but the systems can communicate in some way. (Note this type of 3297 communication is outside the current scope of IOTP) 3299 o the processing cost of the cryptography is too high. For example, if a 3300 payment is being made of only a few cents, the cost of carrying out all 3301 the cryptography associated with generating and checking digital 3302 signatures might make the whole transaction uneconomic. Co-locating 3303 trading roles, could help avoid this problem. 3305 5.2 Symmetric and Asymmetric Cryptography 3307 The advantage of using symmetric keys with IOTP is that no Public Key 3308 Infrastructure need be set up and just the Merchant, Payment Handler and 3309 Delivery Handler need to agree the shared secrets to use. 3311 However the disadvantage of symmetric cryptography is that the Consumer 3312 cannot easily check the credentials of the Merchant, Payment Handler, 3313 etc. that they are dealing with. This is likely to reduce, somewhat, the 3314 trust that the Consumer will have carrying out the transaction. 3316 However it should be noted that even if asymmetric cryptography is being 3317 used, the Consumer does not NEED to be provided with any digital 3318 certificates as the integrity of the transaction is determined by, for 3319 example, the Payment Handler checking the Offer Response Signature copied 3320 to the Payment Request. 3322 Note that symmetric, asymmetric or both types of cryptography may be used 3323 in a single transaction. 3325 5.3 Data Privacy 3327 Privacy of information is provided by sending IOTP Messages between the 3328 various Trading Roles using a secure channel such as [SSL/TLS]. Use of a 3329 secure channel within IOTP is optional. 3331 5.4 Payment Protocol Security 3333 IOTP is designed to be completely blind to the payment protocol being 3334 used to effect a payment. From the security perspective, this means that 3335 IOTP neither helps, nor hinders, the achievement of payment security. 3337 If it is necessary to consider payment security from an IOTP perspective, 3338 then this should be included in the payment protocol supplement which 3339 describes how IOTP supports that payment protocol. 3341 However what IOTP is designed to do is to use digital signatures to bind 3342 together the record, contained in a "response" message, of each trading 3343 exchange in a transaction. For example IOTP can bind together: an Offer, 3344 a Payment and a Delivery. 3346 6. Digital Signatures and IOTP 3348 IOTP can work successfully without using any digital signatures although 3349 in an open networking environment it will be less secure - see 5. 3350 Security Considerations for a description of the factors that need to be 3351 considered. 3353 However, this section describes how to use digital signatures in the many 3354 situations when they will be needed. Topics covered are: 3356 o an overview of how IOTP uses digital signatures 3358 o how to check a signature is correctly calculated 3360 o how Payment Handlers and Delivery Handlers check they can carry out 3361 payments or deliveries on behalf of a Merchant. 3363 6.1 How IOTP uses Digital Signatures 3365 In general, signatures when used with IOTP: 3367 o are always treated as IOTP Components (see section 7) 3369 o contain digests of one or more IOTP Components or Trading Blocks, 3370 possibly including other Signature Components, in any IOTP message 3371 within the same IOTP Transaction 3373 o identify: 3374 - which Organisation signed (originated) the signature, and 3375 - which Organisation(s) should process the signature in order to check 3376 that the Action the Organisation should take can occur. 3378 Digital certificates may be associated with digital signatures if 3379 asymmetric cryptography is being used. However if symmetric cryptography 3380 is being used, then the digital certificate will be replaced by some 3381 identifier of the secret key to use. 3383 The way in which Signatures Components digest one or more elements is 3384 illustrated in the figure below. 3386 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3388 IOTP MESSAGE SIGNATURE COMPONENT 3390 IOTP Message Signature Id = P1.3 3391 |-Trans Ref Block digest TransRefBlk |-Manifest 3392 | | ID=P1.1-----------------------------|->|-Digest of P1.1-- 3393 | |-Trans Id Comp digest TransIdComp | | | 3394 | | ID = M1.2----------------------------|->|-Digest of M1.2--| 3395 | |-Msg Id Comp. digest Signature | | | 3396 | | ID = P1 -------------------|->|-Digest of M1.5--| 3397 | | digest element | | | 3398 |-Signatures Block | -----------------|->|-Digest of M1.7--| 3399 | | ID=P1.2 | | digest element | | | 3400 | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| 3401 | |-Signature ID=M1.5---- | | | | | 3402 | |-Signature ID=P1.4 | | Points to | -RecipientInfo* | 3403 | |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 | 3404 | | | | Certs to use | Sig.ValueRef=P1.4 | 3405 | | | | | | | 3406 | | | | | | | 3407 |-Trading Block. ID=P1.5 | | | v | 3408 | |-Comp. ID=M1.7---------- | -Value* ID=P1.4: | 3409 | | | JtvwpMdmSfMbhK<-- 3410 | |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI 3411 | | | J8pxLjoSRfe1o6k 3412 | |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<- 3413 | |-Comp. ID=C1.5 3414 Digital signature of Manifest element 3415 using certificate identified by CertRef 3417 Elements that are digested can be in any IOTP Message 3418 within the same IOTP Transaction 3419 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3421 Figure 10 Signature Digests 3423 [Note] The classic example of one signature signing another in IOTP, 3424 is when an Offer is first signed by a Merchant creating an 3425 "Offer Response" signature, which is then later signed by a 3426 Payment Handler together with a record of the payment creating 3427 a "Payment Receipt" signature. In this way, the payment in an 3428 IOTP Transaction is bound to the Merchant's offer. 3429 [Note End] 3431 Note that one Manifest may be associated with multiple signature "Value" 3432 elements where each Value element contains a digital signature over the 3433 same Manifest, perhaps using the same (or different) signature algorithm 3434 but using a different certificate or shared secret key. Specifically it 3435 will allow the Merchant to agree different shared secrets keys with their 3436 Payment Handler and Delivery Handler. 3438 The detailed definitions of a Signature component are contained in 3439 section 7.19. 3441 The remainder of this section contains: 3443 o an example of how IOTP uses signatures 3445 o how the OriginatorInfo and RecipientInfo elements within a Signature 3446 Component are used to identify the Organisations associated with the 3447 signature 3449 o how IOTP uses signatures to prove actions complete successfully 3451 6.1.1 IOTP Signature Example 3453 An example of how signatures are used is illustrated in the figure below 3454 which shows how the various components and elements in a Baseline 3455 Purchase relate to one another. Refer to this example in the later 3456 description of how signatures are used to check a payment or delivery can 3457 occur (see section 6.3). 3459 [Note] A Baseline Purchase transaction has been used for illustration 3460 purposes. The usage of the elements and attributes is the same 3461 for all types of IOTP Transactions. 3462 [Note End] 3463 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3465 TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK 3466 | (Offer Response) 3467 Brand Selection Organisation<--- |------Signature 3468 Component Component | | Component 3469 | | | -Manifest 3470 |BrandList -Trading Role | | 3471 | Ref Element | Originator |-Orig. 3472 v (Merchant) ------------|--Info 3473 Brand List Ref | 3474 >Component | 3475 | |-Protocol ------> Organisation Recipient |-Recipient 3476 | | Amount Elem | Component <------------------|--Info 3477 | | | | | Refs | 3478 | |Pay|Protocol |Action -Trading Role | 3479 | | | Ref |OrgRef Element | 3480 | | v | (Payment Handler) | 3481 | -PayProtocol-- | 3482 | Elem ->Organisation Recipient |-Recipient 3483 | | Component <--------------------Info 3484 | | | Refs 3485 | | -Trading Role 3486 | | Element 3487 | | (Delivery Handler 3488 | 3489 | OFFER RESPONSE BLOCK 3490 | | 3491 |BrandListRef |ActionOrgRef 3492 | | 3493 --Payment ---Delivery 3494 Component Component 3496 The Manifest element in the Signature Component contains digests of: 3497 the Trans Ref Block (not shown); the Transaction ID Component (not 3498 shown); Organisation Components (Merchant, Payment Handler, Delivery 3499 Handler); the Brand List Component; the Order Component, the Payment 3500 Component the Delivery Component and the Brand Selection Component (if a 3501 Brand Dependent Purchase). 3503 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3505 Figure 11 Example use of Signatures for Baseline Purchase 3507 6.1.2 OriginatorInfo and RecipientInfo Elements 3509 The OriginatorRef attribute of the OriginatorInfo element in the 3510 Signature Component contains an Element Reference (see section 3.5) that 3511 points to the Organisation Component of the Organisation which generated 3512 the Signature. In this example its the Merchant. 3514 Note that the value of the content of the Attribute element with a Type 3515 attribute set to IOTP Signature Type must match the Trading Role of the 3516 Organisation which signed it. If it does not, then it is an error. Valid 3517 combinations are given in the table below. 3519 IOTP Signature Type Valid Trading Role 3521 OfferResponse Merchant 3523 PaymentResponse PaymentHandler 3525 DeliveryResponse DeliveryHandler 3527 AuthenticationRequest any role 3529 AuthenticationResponse any role 3531 PingRequest any role 3533 PingResponse any role 3535 The RecipientRefs attribute of the RecipientInfo element in the Signature 3536 Component contains Element References to the Organisation Components of 3537 the Organisations that should use the signature to verify that: 3539 o they have a pre-existing relationship with the Organisation that 3540 generated the signature, 3542 o the data which is secured by the signature has not been changed, 3544 o the data has been signed correctly, and 3546 o the action they are required to undertake on behalf of the Merchant is 3547 therefore authorised. 3549 Note that if symmetric cryptography is being used then a separate 3550 RecipientInfo and Value elements for each different set of shared secret 3551 keys are likely within the Signature Component. 3553 Alternatively if asymmetric cryptography is being used then the 3554 RecpientRefs attribute of one RecipientInfo element may refer to multiple 3555 Organisation Components if they are all using the same certificates. 3557 6.1.3 Using signatures to Prove Actions Complete Successfully 3559 Proving an action completed successfully, is achieved by signing data on 3560 Response messages. Specifically: 3562 o on the Offer Response, when a Merchant is making an Offer to the 3563 Consumer which can then be sent to either: 3564 - a Payment Handler to prove that the Merchant authorises Payment, or 3565 - a Delivery Handler to prove that Merchant authorises Delivery, 3566 provided other necessary authorisations are complete (see below) 3568 o on the Payment Response, when a Payment Handler is generating a Payment 3569 Receipt which can be sent to either: 3570 - a Delivery Handler, in a Delivery Request Block to authorise Delivery 3571 together with the Offer Response signature, or 3572 - another Payment Handler, in a second Payment Request, to authorise 3573 the second payment in a Value Exchange IOTP Transaction 3575 o Delivery Response, when a Delivery Handler is generating a Delivery 3576 Note. This can be used to prove after the event what the Delivery 3577 Handler said they would do 3579 o Authentication Response. One method of authenticating another party to 3580 a trade is to send an Authentication Request specifying that a Digital 3581 Signature should be used for authentication 3583 o Transaction Status Inquiry. The Inquiry Response Block may be digitally 3584 signed to attest to the authenticity of the response 3586 o Ping. The Ping Response may be digitally signed so that checks can be 3587 made that the signature can be understood. 3589 This proof of an action may, in future versions of IOTP, also be used to 3590 prove after the event that the IOTP transaction occurred. For example to 3591 a Customer Care Provider. 3593 6.2 Checking a Signature is Correctly Calculated 3595 Checking a signature is correctly calculated is part of checking for 3596 Message Level Errors (see section 4.3.2). It is included here so that all 3597 signature and security related considerations are kept together. 3599 Before a Trading Role can check a signature it must identify which of the 3600 potentially multiple Signature elements should be checked. The steps 3601 involved are as follows: 3603 o check that a Signature Block is present and it contains one or more 3604 Signature Components 3606 o identify the Organisation Component which contains an OrgId attribute 3607 for the Organisation which is carrying out the signature check. If no 3608 or more than one Organisation Component is found then it is an error 3610 o use the ID attribute of the Organisation Component to find the 3611 RecipientInfo element that contains a RecipientRefs attribute that 3612 refers to that Organisation Component. Note there may be no signatures 3613 to verify 3615 o check the Signature Component that contains the identified 3616 RecipientInfo element as follows: 3617 - use the SignatureValueRef and the SignatureAlgorithmRef attributes to 3618 identify, respectively: the Value element that contains the signature 3619 to be checked and the Signature Algorithm element that describes the 3620 signature algorithm to be used to verify the Signature, then 3621 - if the Signature Algorithm element indicates that asymmetric 3622 cryptography is being used then use the SignatureCertRef to identify 3623 the Certificate to be used by the signature algorithm 3624 - if Signature Algorithm element indicates that symmetric cryptography 3625 is being used then the content of the RecipientInfo element is used 3626 to identify the correct shared secret key to use 3627 - use the specified signature algorithm to check that the Value Element 3628 correctly signs the Manifest Element 3629 - check that the Digest Elements in the Manifest Element are correctly 3630 calculated where Components or Blocks referenced by the Digest have 3631 been received by the Organisation checking the signature. 3633 6.3 Checking a Payment or Delivery can occur 3635 This section describes the processes required for a Payment Handler or 3636 Delivery Handler to check that a payment or delivery can occur. This may 3637 include checking signatures if this is specified by the Merchant. 3639 In outline the steps are: 3641 o check that the Payment Request or Delivery Request has been sent to the 3642 correct Organisation 3644 o check that correct IOTP components are present in the request, and 3646 o check that the payment or delivery is authorised 3648 For clarity and brevity the following terms or phrases are used in this 3649 section: 3651 o a "Request Block" is used to refer to either a Payment Request Block 3652 (see section 8.7) or a Delivery Request Block (see section 8.10) unless 3653 specified to the contrary 3655 o a "Response Block" is used to refer to either a Payment Response Block 3656 (see section 8.9) or a Delivery Response Block (see section 8.11) 3658 o an "Action" is used to refer to an action which occurs on receipt of a 3659 Request Block. Actions can be either a Payment or a Delivery 3661 o an "Action Organisation", is used to refer to the Payment Handler or 3662 Delivery Handler that carries out an Action 3664 o a "Signer of an Action", is used to refer to the Organisations that 3665 sign data about an Action to authorise the Action, either in whole or 3666 in part 3668 o a "Verifier of an Action", is used to refer to the Organisations that 3669 verify data to determine if they are authorised to carry out the Action 3671 o an ActionOrgRef attribute contains Element References which can be used 3672 to identify the "Action Organisation" that should carry out an Action 3674 6.3.1 Check Request Block sent Correct Organisation 3676 Checking the Request Block was sent to the correct Organisation varies 3677 depending on whether the request refers to a Payment or a Delivery. 3679 6.3.1.1 Payment 3681 In outline a Payment Handler checks if it can accept or make a payment by 3682 identifying the Payment Component in the Payment Request Block it has 3683 received, then using the ID of the Payment Component to track through the 3684 Brand List and Brand Selection Components to identify the Organisation 3685 selected by the Consumer and then checking that this Organisation is 3686 itself. 3688 The way data is accessed to do this is illustrated in the figure below. 3690 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3691 Start 3692 | 3693 v 3694 Brand List<--------------------------+-----------Payment 3695 Component BrandListRef | Component 3696 | | 3697 |-Brand<-------------------------- | 3698 | Element BrandRef | | 3699 | | Brand Selection 3700 | |Protocol Component 3701 | | AmountRefs | | 3702 | v Protocol | | 3703 |-Protocol Amount<---------------- | 3704 | Element---------- AmountRef | 3705 | | | | 3706 | |Currency |Pay | 3707 | | AmountRefs |Protocol | 3708 | v |Ref | 3709 |-Currency Amount | | 3710 | Element<---------|---------------- 3711 | | 3712 -PayProtocol<----- 3713 Element---------------------->Organisation 3714 Action Component 3715 OrgRef | 3716 -Trading Role 3717 Element 3718 (Payment Handler) 3720 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3721 Figure 14 Checking a Payment Handler can carry out a Payment 3723 Figure 12 Checking a Payment Handler can carry out a Payment 3725 The following describes the steps involved and the checks which need to 3726 be made: 3728 o Identify the Payment Component (see section 7.9) in the Payment Request 3729 Block that was received. 3731 o Identify the Brand List and Brand Selection Components for the Payment 3732 Component. This involves: 3733 - identifying the Brand List Component (see section 7.7) where the 3734 value of its ID attribute matches the BrandListRef attribute of the 3735 Payment Component. If no or more than one Brand List Component is 3736 found there is an error. 3737 - identifying the Brand Selection Component (see section 7.8) where the 3738 value of its BrandListRef attribute matches the BrandListRef of the 3739 Payment Component. If no or more than one matching Brand Selection 3740 Component is found there is an error. 3742 o Identify the Brand, Protocol Amount, Pay Protocol and Currency Amount 3743 elements within the Brand List that have been selected by the Consumer 3744 as follows: 3745 - the Brand Element (see section 7.7.1) selected is the element where 3746 the value of its Id attribute matches the value of the BrandRef 3747 attribute in the Brand Selection. If no or more than one matching 3748 Brand Element is found then there is an error. 3749 - the Protocol Amount Element (see section 7.7.3) selected is the 3750 element where the value of its Id attribute matches the value of the 3751 ProtocolAmountRef attribute in the Brand Selection Component. If no 3752 or more than one matching Protocol Amount Element is found there is 3753 an error 3754 - the Pay Protocol Element (see section 7.7.5) selected is the element 3755 where the value of its Id attribute matches the value of the 3756 PayProtocolRef attribute in the identified Protocol Amount Element. 3757 If no or more than one matching Pay Protocol Element is found there 3758 is an error 3759 - the Currency Amount Element (see section 7.7.4) selected is the 3760 element where the value of its Id attribute matches the value of the 3761 CurrencyAmountRef attribute in the Brand Selection Component. If no 3762 or more than one matching Currency Amount element is found there is 3763 an error 3765 o Check the consistency of the references in the Brand List and Brand 3766 Selection Components: 3767 - check that an Element Reference exists in the ProtocolAmountRefs 3768 attribute of the identified Brand Element that matches the Id 3769 attribute of the identified Protocol Amount Element. If no or more 3770 than one matching Element Reference can be found there is an error 3771 - check that the CurrencyAmountRefs attribute of the identified 3772 Protocol Amount element contains an element reference that matches 3773 the Id attribute of the identified Currency Amount element. If no or 3774 more than one matching Element Reference is found there is an error. 3775 - check the consistency of the elements in the Brand List. 3776 Specifically, the selected Brand, Protocol Amount, Pay Protocol and 3777 Currency Amount Elements are all child elements of the identified 3778 Brand List Component. If they are not there is an error. 3780 o Check that the Payment Handler that received the Payment Request Block 3781 is the Payment Handler selected by the Consumer. This involves: 3782 - identifying the Organisation Component for the Payment Handler. This 3783 is the Organisation Component where its ID attribute matches the 3784 ActionOrgRef attribute in the identified Pay Protocol Element. If no 3785 or more than one matching Organisation Component is found there is an 3786 error 3787 - checking the Organisation Component has a Trading Role Element with a 3788 Role attribute of PaymentHandler. If not there is an error 3789 - finally, if the identified Organisation Component is not the same as 3790 the Organisation that received the Payment Request Block, then there 3791 is an error. 3793 6.3.1.2 Delivery 3795 The way data is accessed by a Delivery Handler in order to check that it 3796 may carry out a delivery is illustrated in the figure below. 3798 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3799 Start 3800 | 3801 v 3802 Delivery 3803 Component 3804 | 3805 |ActionOrgRef 3806 | 3807 v 3808 Organisation 3809 Component 3810 | 3811 -Trading Role 3812 Element 3813 (Delivery Handler) 3815 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3817 Figure 13 Checking a Delivery Handler can carry out a Delivery 3819 The steps involved are as follows: 3821 o Identify the Delivery Component in the Delivery Request Block. If there 3822 is no or more than one matching Delivery Component there is an error 3824 o Use the ActionOrgRef attribute of the Delivery Component to identify 3825 the Organisation Component of the Delivery Handler. If there is no or 3826 more than one matching Organisation Component there is an error 3828 o If the Organisation Component for the Delivery Handler does not have a 3829 Trading Role Element with a Role attribute of DeliveryHandler there is 3830 an error 3832 o Finally, if the Organisation that received the Delivery Request Block 3833 does not identify the Organisation Component for the Delivery Handler 3834 as itself, then there is an error. 3836 6.3.2 Check Correct Components present in Request Block 3838 Check that the correct components are present in the Payment Request 3839 Block (see section 8.7) or in the Delivery Request Block (see section 3840 8.10). 3842 If components are missing, there is an error. 3844 6.3.3 Check an Action is Authorised 3846 The previous steps identified the Action Organisation and that all the 3847 necessary components are present. This step checks that the Action 3848 Organisation is authorised to carry out the Action. 3850 In outline the Action Organisation will identifies the Merchant, checks 3851 that it has a pre-existing agreement with the Merchant that allows it 3852 carry out the Action and that any constraints implied by that agreement 3853 are being followed, then, if signatures are required, it checks that they 3854 sign the correct data. 3856 The steps involved are as follows: 3858 o Identify the Merchant. This is the Organisation Component with a 3859 Trading Role Element which has a Role attribute with a value of 3860 Merchant. If no or more than one Trading Role Element is found, there 3861 is an error 3863 o Check the Action Organisation's agreements with the Merchant allows the 3864 Action to be carried out. To do this the Action Organisation must check 3865 that: 3867 - the Merchant is known and a pre-existing agreement exists for the 3868 Action Organisation to be their agent for the payment or delivery 3869 - they are allowed to take part in the type of IOTP transaction that is 3870 occurring. For example a Payment Handler may have agreed to accept 3871 payments as part of a Baseline Purchase, but not make payments as 3872 part of a Baseline Refund 3873 - any constraints in their agreement with the Merchant are being 3874 followed, for example, whether or not an Offer Response signature is 3875 required 3877 o Check the signatures are correct. If signatures are required then they 3878 need to be checked. This involves: 3879 - Identifying the correct signatures to check. This involves the Action 3880 Organisation identifying the Signature Components that contain 3881 references to the Action Organisation (see 6.3.1). Depending on the 3882 IOTP Transaction being carried out (see section 9) either one or two 3883 signatures may be identified 3884 - checking that the Signature Components are correct. This involves 3885 checking that Digest elements exist within the Manifest Element that 3886 refer to the necessary Trading Components (see section 6.3.3.1). 3888 6.3.3.1 Check the Signatures Digests are correct 3890 All Signature Components contained within IOTP Messages must include 3891 Digest elements that refer to: 3893 o the Transaction Id Component (see section 3.3.1) of the IOTP message 3894 that contains the Signature Component. This binds the globally unique 3895 IotpTransId to other components which make up the IOTP Transaction 3897 o the Transaction Reference Block (see section 3.3) of the first IOTP 3898 Message that contained the signature. This binds the IotpTransId with 3899 information about the IOTP Message contained inside the Message Id 3900 Component (see section 3.3.2). 3902 Check that each Signature Component contains Digest elements that refer 3903 to the correct data required. 3905 The Digest elements that need to be present depend on the Trading Role of 3906 the Organisation which generated (signed) the signature: 3908 o if the signer of the signature is a Merchant then: 3909 - Digest elements must be present for all the components in the Request 3910 Block apart from the Brand Selection Component which is optional 3912 o if the signer of the signature is a Payment Handler then Digest 3913 elements must be present for: 3914 - the Signature Component signed by the Merchant, and optionally 3915 - one or more Signature Components signed by the previous Payment 3916 Handler(s) in the Transaction. 3918 7. Trading Components 3920 This section describes the Trading Components used within IOTP. Trading 3921 Components are the child XML elements which occur immediately below a 3922 Trading Block as illustrated in the diagram below. 3924 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3926 IOTP MESSAGE <----------- IOTP Message - an XML Document 3927 | which is transported between the 3928 | Trading Roles 3929 |-Trans Ref Block <----- Trans Ref Block - contains 3930 | | information which describes the 3931 | | IOTP Transaction and the IOTP 3932 Message. 3933 --------> | |-Trans Id Comp. <--- Transaction Id Component - 3934 | | | uniquely identifies the IOTP 3935 | | | Transaction. The Trans Id 3936 | | | Components are the same across 3937 | | | all IOTP messages that comprise 3938 | | | a single IOTP transaction. 3939 | | |-Msg Id Comp. <----- Message Id Component - 3940 | | identifies and describes an IOTP 3941 | | Message within an IOTP 3942 | | Transaction 3943 | |-Signature Block <----- Signature Block (optional) - 3944 | | | contains one or more Signature 3945 | | | Components and their associated 3946 | | | Certificates 3947 | ---> | |-Signature Comp. <-- Signature Component - contains 3948 | | | | digital signatures. Signatures 3949 | | | | may sign digests of the Trans Ref 3950 | | | | Block and any Trading Component 3951 | | | | in any IOTP Message in the same 3952 | | | | IOTP Transaction. 3953 | | | |-Certificate Comp. <- Certificate Component. Used to 3954 | | | check the signature. 3955 Trading |-Trading Block <-------- Trading Block - an XML Element 3956 Components | |-Trading Comp. within an IOTP Message that 3957 | | | |-Trading Comp. contains a predefined set of 3958 | ---> | |-Trading Comp. Trading Components 3959 | | |-Trading Comp. 3960 | | |-Trading Comp. <----- Trading Components - XML 3961 | | Elements within a Trading Block 3962 | |-Trading Block that contain a predefined set of 3963 --------> | |-Trading Comp. XML elements and attributes 3964 | |-Trading Comp. containing information required 3965 | |-Trading Comp. to support a Trading Exchange 3966 | |-Trading Comp. 3967 | |-Trading Comp. 3968 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3969 Figure 14 Trading Components 3971 The Trading Components described in this section are listed below in 3972 approximately the sequence they are likely to be used: 3974 o Protocol Options Component 3976 o Authentication Request Component 3978 o Authentication Response Component 3980 o Trading Role Information Request Component 3982 o Order Component 3984 o Organisation Component 3986 o Brand List Component 3988 o Brand Selection Component 3990 o Payment Component 3992 o Payment Scheme Component 3994 o Payment Receipt Component 3996 o Delivery Component 3998 o Delivery Note Component 4000 o Signature Component 4002 o Certificate Component 4004 o Error Component 4006 Note that the following components are listed in other sections of this 4007 specification: 4009 o Transaction Id Component (see section 3.3.1) 4011 o Message Id Component (see section 3.3.2) 4013 7.1 Protocol Options Component 4015 Protocol options are options which apply to the IOTP Transaction as a 4016 whole. Essentially it provides a short description of the entire 4017 transaction and the net location which the Consumer role should branch to 4018 if the IOTP Transaction is successful. 4020 The definition of a Protocol Options Component is as follows. 4022 4023 4031 Attributes: 4033 ID An identifier which uniquely identifies the 4034 Protocol Options Component within the IOTP 4035 Transaction. 4037 Xml:lang Defines the language used by attributes or child 4038 elements within this component, unless 4039 overridden by an xml:lang attribute on a child 4040 element. See section 3.8 Identifying Languages. 4042 ShortDesc This contains a short description of the IOTP 4043 Transaction in the language defined by xml:lang. 4044 Its purpose is to provide an explanation of what 4045 type of IOTP Transaction is being conducted by 4046 the parties involved. 4048 It is used to facilitate selecting an individual 4049 transaction from a list of similar transactions, 4050 for example from a database of IOTP transactions 4051 which has been stored by a Consumer, Merchant, 4052 etc. 4054 SenderNetLocn This contains the non secured net location of 4055 the sender of the TPO Block in which the 4056 Protocol Options Component is contained. 4058 It is the net location to which the recipient of 4059 the TPO block should send a TPO Selection Block 4060 if required. 4062 The content of this attribute is dependent on 4063 the Transport Mechanism see the Transport 4064 Mechanism Supplement. 4066 SecureSenderNetLocn This contains the secured net location of the 4067 sender of the TPO Block in which the Protocol 4068 Options Component is contained. 4070 The content of this attribute is dependent on 4071 the Transport Mechanism see the Transport 4072 Mechanism Supplement. 4074 SuccessNetLocn This contains the net location that should be 4075 displayed after the IOTP Transaction has 4076 successfully completed. 4078 The content of this attribute is dependent on 4079 the Transport Mechanism see the Transport 4080 Mechanism Supplement. 4082 Either SenderNetLocn, SecureSenderNetLocn or both must be present. 4084 7.2 Authentication Request Component 4086 This Trading Component contains parameter data that is used in an 4087 Authentication of one Trading Role by another. Its definition is as 4088 follows. 4090 4091 4096 If required the Algorithm may use the challenge data, contained in the 4097 Packaged Content elements within the Authentication Request Component in 4098 its calculation. The format of the Packaged Contents are Algorithm 4099 dependent. 4101 Attributes: 4103 ID An identifier which uniquely identifies the 4104 Authentication Request Component within the IOTP 4105 Transaction. 4107 AuthenticationId An identifier specified by the Authenticator 4108 which, if returned by the Organisation that 4109 receives the Authentication Request, will enable 4110 the Authenticator to identify which Authentication 4111 is being referred to. 4113 ContentSoftwareId See section 14. Glossary. 4115 Content: 4117 PackagedContent This contains the challenge data as one or more 4118 Packaged Content (see section 3.7) that is to be 4119 responded to using the Algorithm defined by the 4120 Algorithm element. 4122 Algorithm This contains information which describes the 4123 Algorithm (see 7.19 Signature Components) that 4124 must be used to generate the Authentication 4125 Response. 4127 The Algorithms that may be used are identified by 4128 the Name attribute of the Algorithm element. For 4129 valid values see section 12. IANA Considerations. 4131 7.3 Authentication Response Component 4133 The Authentication Response Component contains the results of an 4134 authentication request. It uses the Algorithm contained in the 4135 Authentication Request Component (see section 7.2) selected from the 4136 Authentication Request Block (see section 8.4). 4138 Depending on the Algorithm selected, the results of applying the 4139 algorithm will either be contained in a Signature Component that signs 4140 both the Authentication Response and potentially other data, or in the 4141 Packaged Content elements within the Authentication Response Component. 4142 Its definition is as follows. 4144 4145 4151 Attributes: 4153 ID An identifier which uniquely identifies the 4154 Authentication Response Component within the 4155 IOTP Transaction. 4157 AuthenticationId The Authentication identifier specified by the 4158 Authenticator that was included in the 4159 Authentication Request Component(see section 4160 7.2). This will enable the Authenticator to 4161 identify the Authentication that is being 4162 referred to. 4164 SelectedAlgorithmRef An Element Reference that identifies the 4165 Algorithm element used to generate the 4166 Authentication Response. 4168 ContentSoftwareId See section 14. Glossary. 4170 Content: 4172 PackagedContent This may contain the response generated as a 4173 result of applying the Algorithm selected from the 4174 Authentication Request Component see section 7.2. 4176 For example, for a payment specific scheme, it may 4177 contain scheme-specific data. Refer to the scheme- 4178 specific supplemental documentation for 4179 definitions of its content. 4181 7.4 Trading Role Information Request Component 4183 This Trading Component contains a list of Trading Roles (see section 2.1) 4184 about which information is being requested. The result of a Trading Role 4185 Request is a set of Organisation Components (see section 7.6) that 4186 describe each of the Trading Roles requested. 4188 Example usage includes: 4190 o a Merchant requesting that a Consumer provides Organisation Components 4191 for the Consumer and DelivTo Trading Roles 4193 o a Consumer requesting from a Merchant, information about the Payment 4194 Handlers and Delivery Handlers that the Merchant uses. 4196 Its definition is as follows. 4198 4199 4203 Attributes: 4205 ID An identifier which uniquely identifies the 4206 Trading Role Information Request Component within 4207 the IOTP Transaction. 4209 TradingRoleList Contains a list of one or more Trading Roles (see 4210 the TradingRole attribute of the Trading Role 4211 Element - section 7.6.2) for which information is 4212 being requested. 4214 7.5 Order Component 4216 An Order Component contains information about an order. Its definition is 4217 as follows. 4219 4220 4230 Attributes: 4232 ID An identifier which uniquely identifies the Order 4233 Component within the IOTP Transaction. 4235 xml:lang Defines the language used by attributes or child 4236 elements within this component, unless overridden 4237 by an xml:lang attribute on a child element. See 4238 section 3.8 Identifying Languages. 4240 OrderIdentifier This is a code, reference number or other 4241 identifier which the creator of the Order may use 4242 to identify the order. It must be unique within an 4243 IOTP Transaction. If it is used in this way, then 4244 it may remove the need to specify any content for 4245 the Order element as the reference can be used to 4246 look up the necessary information in a database. 4248 ShortDesc A short description of the order in the language 4249 defined by xml:lang. It is used to facilitate 4250 selecting an individual order from a list of 4251 orders, for example from a database of orders 4252 which has been stored by a Consumer, Merchant, 4253 etc. 4255 OkFrom The date and time in [UTC] format after which the 4256 offer made by the Merchant lapses. 4258 OkTo The date and time in [UTC] format before which a 4259 Value Acquirer may accept the offer made by the 4260 Merchant is not valid. 4262 ApplicableLaw A phrase in the language defined by xml:lang which 4263 describes the state or country of jurisdiction 4264 which will apply in resolving problems or 4265 disputes. 4267 ContentSoftwareId See section 14. Glossary. 4269 Content: 4271 PackagedContent An optional description of the order information 4272 as one or more Packaged Contents (see section 4273 3.7). 4275 7.5.1 Order Description Content 4277 The Packaged Content element will normally be required, however it may be 4278 omitted where sufficient information about the purchase can be provided 4279 in the ShortDesc attribute. If the full Order Description requires it 4280 several Packaged Content elements may be used. 4282 Although the amount and currency are likely to appear in the Packaged 4283 Content of the Order Description it is the amount and currency contained 4284 in the payment related trading components (Brand List, Brand Selection 4285 and Payment) that is authoritative. This means it is important that the 4286 amount actually being paid (as contained in the payment related trading 4287 components) is prominently displayed to the Consumer. 4289 For interoperability, implementations must support Plain Text, HTML and 4290 XML as a minimum so that it can be easily displayed. 4292 7.5.2 OkFrom and OkTo Timestamps 4294 Note that: 4296 o the OkFrom date may be later than the OkFrom date on the Payment 4297 Component (see section 7.9) associated with this order, and 4299 o similarly, the OkTo date may be earlier that the OkTo date on the 4300 Payment Component (see section 7.9). 4302 [Note] Disclaimer. The following information provided in this note 4303 does not represent formal advice of any of the authors of this 4304 specification. Readers of this specification must form their 4305 own views and seek their own legal counsel on the usefulness 4306 and applicability of this information. 4308 The merchant in the context of Internet commerce with 4309 anonymous consumers initially frames the terms of the offer on 4310 the web page, and in order to obtain the goods or services, 4311 the consumer must accept them. 4313 If there is to be a time-limited offer, it is recommended that 4314 merchants communicate this to the consumer and state in the 4315 order description in a manner which is clear to the consumer 4316 that: 4317 o the offer is time limited 4318 o the OkFrom and OkTo timestamps specify the validity of the 4319 offer 4320 o the clock, e.g. the merchant's clock, that will be used to 4321 determine the validity of the offer 4323 Also note that although the OkFrom and OkTo dates are likely 4324 to appear in the Packaged Content of the Order Description it 4325 is the dates contained in the Order Component that is 4326 authoritative. This means it is important that the OkFrom and 4327 OkTo dates actually being used is prominently displayed to the 4328 Consumer. 4329 [Note End] 4331 7.6 Organisation Component 4333 The Organisation Component provides information about an individual or an 4334 Organisation. This can be used for a variety of purposes. For example: 4336 o to describe the merchant who is selling the goods, 4338 o to identify who made a purchase, 4340 o to identify who will take delivery of goods, 4342 o to provide a customer care contact, 4344 o to describe who will be the Payment Handler. 4346 Note that the Organisation Components which must be present in an IOTP 4347 Message are dependent on the particular transaction being carried out. 4348 Refer to section 9. Internet Open Trading Protocol Transactions, for more 4349 details. 4351 Its definition is as follows. 4353 4355 4363 Attributes: 4365 ID An identifier which uniquely identifies the 4366 Organisation Component within the IOTP 4367 Transaction. 4369 xml:lang Defines the language used by attributes or child 4370 elements within this component, unless overridden 4371 by an xml:lang attribute on a child element. See 4372 section 3.8 Identifying Languages. 4374 OrgId A code which identifies the Organisation described 4375 by the Organisation Component. See 7.6.1 4376 Organisation IDs, below. 4378 LegalName For Organisations which are companies this is 4379 their legal name in the language defined by 4380 xml:lang. It is required for Organisations who 4381 have a Trading Role other than Consumer or 4382 DelivTo. 4384 ShortDesc A short description of the Organisation in the 4385 language defined by xml:lang. It is typically the 4386 name by which the Organisation is commonly known. 4387 For example, if the legal name was "Blue Meadows 4388 Financial Services Inc.". Then its short name 4389 would likely be "Blue Meadows". 4391 It is used to facilitate selecting an individual 4392 Organisation from a list of Organisations, for 4393 example from a database of Organisations involved 4394 in IOTP Transactions which has been stored by a 4395 consumer. 4397 LogoNetLocn The net location which can be used to download the 4398 logo for the Organisation. 4400 See section 10 Retrieving Logos. 4402 The content of this attribute must conform to 4403 [RFC1738]. 4405 Content: 4407 TradingRole See 7.6.2 Trading Role Element below. 4409 ContactInfo See 7.6.3 Contact Information Element below. 4411 PersonName See 7.6.4 Person Name below. 4413 PostalAddress See 7.6.5 Postal Address below. 4415 7.6.1 Organisation IDs 4417 Organisation IDs are used by one IOTP Trading Role to identify another. 4418 In order to avoid confusion, this means that these IDs must be globally 4419 unique. 4421 In principle this is achieved in the following way: 4423 o the Organisation Id for all trading roles, apart from the Consumer 4424 Trading Role, uses a domain name as their globally unique identifier, 4426 o the Organisation Id for a Consumer Trading Role is allocated by one of 4427 the other Trading Roles in an IOTP Transaction and is made unique by 4428 concatenating it with that other roles' Organisation Id, 4430 o once a Consumer is allocated an Organisation Id within an IOTP 4431 Transaction the same Organisation Id is used by all the other trading 4432 roles in that IOTP transaction to identify that Consumer. 4434 Specifically, the content of the Organisation ID is defined as follows: 4436 OrgId ::= NonConsumerOrgId | ConsumerOrgId 4437 NonConsumerOrgId ::= DomainName 4438 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId 4439 ConsumerOrgIdPrefix ::= "Consumer:" 4441 ConsumerOrgId The Organisation ID for a Consumer consists of: 4442 o a standard prefix to identify that the 4443 Organisation Id is for a consumer, followed by 4444 o one or more characters which conform to the 4445 definition of an XML "namechar". See [XML] 4446 specifications, followed by 4447 o the NonConsumerOrgId for the Organisation 4448 which allocated the ConsumerOrgId. It is 4449 normally the Merchant role. 4451 Use of upper and lower case is not significant. 4453 NonConsumerOrgId If the Role is not Consumer then this contains the 4454 Canonical Name for the non-consumer Organisation 4455 being described by the Organisation Component. See 4456 [DNS] optionally followed by additional 4457 characters, if required, to make the 4458 NonConsumerOrgId unique. 4460 Note that a NonConsumerOrgId may not start with 4461 the ConsumerOrgIdPrefix. 4463 Use of upper and lower case is not significant. 4465 Examples of Organisation Ids follow: 4467 o newjerseybooks.com - a merchant Organisation id 4469 o westernbank.co.uk - a Payment Handler Organisation id 4471 o consumer:1000247ABH/newjerseybooks.com - a consumer Organisation id 4472 allocated by a merchant 4474 7.6.2 Trading Role Element 4476 This identifies the Trading Role of an individual or Organisation in the 4477 IOTP Transaction. Note, an Organisation may have more than one Trading 4478 Role and several roles may be present in one Organisation element. Its 4479 definition is as follows: 4481 4482 4490 Attributes: 4492 ID An identifier which uniquely identifies the 4493 Trading Role Element within the IOTP Transaction. 4495 TradingRole The trading role of the Organisation. Valid values 4496 are: 4497 o Consumer. The person or Organisation that is 4498 acting in the role of a consumer in the IOTP 4499 Transaction. 4500 o Merchant. The person or Organisation that is 4501 acting in the role of merchant in the IOTP 4502 Transaction. 4503 o PaymentHandler. The financial institution or 4504 other Organisation which is a Payment Handler 4505 for the IOTP Transaction 4506 o DeliveryHandler. The person or Organisation 4507 that is the delivering the goods or services 4508 for the IOTP Transaction 4509 o DelivTo. The person or Organisation that is 4510 receiving the delivery of goods or services in 4511 the IOTP Transaction 4512 o CustCare. The Organisation and/or individual 4513 who will provide customer care for an IOTP 4514 Transaction. 4516 Values of TradingRole are controlled under the 4517 procedures defined in section 12 IANA 4518 Considerations which also allows user defined 4519 values to be defined. 4521 IotpMsgIdPrefix Contains the prefix which must be used for all 4522 IOTP Messages sent by the Trading Role in this 4523 IOTP Transaction. The values to be used are 4524 defined in 3.4.1 IOTP Message ID Attribute 4525 Definition. 4527 CancelNetLocn This contains the net location of where the 4528 Consumer should go to if the Consumer cancels the 4529 transaction for some reason. It can be used by the 4530 Trading Role to provide a response which is more 4531 tailored to the circumstances of a particular 4532 transaction. 4534 This attribute: 4535 o must not be present when TradingRole is set to 4536 Consumer role or DelivTo, 4537 o must be present when TradingRole is set to 4538 Merchant, PaymentHandler or DeliveryHandler. 4540 The content of this attribute is dependent on the 4541 Transport Mechanism see the Transport Mechanism 4542 Supplement. 4544 ErrorNetLocn This contains the net location that should be 4545 displayed by the Consumer after the Consumer has 4546 either received or generated an Error Block 4547 containing an Error Component with the Severity 4548 attribute set to either: 4549 o HardError, 4550 o Warning but the Consumer decides to not 4551 continue with the transaction 4552 o TransientError and the transaction has 4553 subsequently timed out. 4555 See section 7.21.1 Error Processing Guidelines for 4556 more details. 4558 This attribute: 4559 o must not be present when TradingRole is set to 4560 Consumer or DelivTo, 4561 o must be present when TradingRole is set to 4562 Merchant, PaymentHandler or DeliveryHandler. 4564 The content of this attribute is dependent on the 4565 Transport Mechanism see the Transport Mechanism 4566 Supplement. 4568 ErrorLogNetLocn Optional. This contains the net location that 4569 Consumers should send IOTP Messages that contain 4570 Error Blocks with an Error Component with the 4571 Severity attribute set to either: 4572 o HardError, 4573 o Warning but the Consumer decides to not 4574 continue with the transaction 4575 o TransientError and the transaction has 4576 subsequently timed out. 4578 This attribute: 4579 o must not be present when TradingRole is set to 4580 Consumer role, 4581 o must be present when TradingRole is set to 4582 Merchant, PaymentHandler or DeliveryHandler. 4584 The content of this attribute is dependent on the 4585 Transport Mechanism see the Transport Mechanism 4586 Supplement. 4588 The ErrorLogNetLocn can be used to send error 4589 messages to the software company or some other 4590 Organisation responsible for fixing problems in 4591 the software which sent the incoming message. See 4592 section 7.21.1 Error Processing Guidelines for 4593 more details. 4595 7.6.3 Contact Information Element 4597 This contains information which can be used to contact an Organisation or 4598 an individual. All attributes are optional however at least one item of 4599 contact information should be present. Its definition is as follows. 4601 4602 4609 Attributes: 4611 xml:lang Defines the language used by attributes within 4612 this element. See section 3.8 Identifying 4613 Languages. 4615 Tel A telephone number by which the Organisation may 4616 be contacted. Note that this is a text field and 4617 no validation is carried out on it. 4619 Fax A fax number by which the Organisation may be 4620 contacted. Note that this is a text field and no 4621 validation is carried out on it. 4623 Email An email address by which the Organisation may be 4624 contacted. Note that this field should conform to 4625 the conventions for address specifications 4626 contained in [RFC822]. 4628 NetLocn A location on the Internet by which information 4629 about the Organisation may be obtained that can be 4630 displayed using a web browser. 4632 The content of this attribute must conform to 4633 [RFC1738]. 4635 7.6.4 Person Name Element 4637 This contains the name of an individual person. All fields are optional 4638 however as a minimum either the GivenName or the FamilyName should be 4639 present. Its definition is as follows. 4641 4642 4649 Attributes: 4651 xml:lang Defines the language used by attributes within 4652 this element. See section 3.8 Identifying 4653 Languages. 4655 Title A distinctive name; personal appellation, 4656 hereditary or not, denoting or implying office 4657 (e.g. judge, mayor) or nobility (e.g. duke, 4658 duchess, earl), or used in addressing or referring 4659 to a person (e.g. Mr, Mrs, Miss) 4661 GivenName The primary or main name by which a person is 4662 known amongst and identified by their family, 4663 friends and acquaintances. Otherwise known as 4664 first name or Christian Name. 4666 Initials The first letter of the secondary names (other 4667 than the Given Name) by which a person is known 4668 amongst or identified by their family, friends and 4669 acquaintances. 4671 FamilyName The name by which family of related individuals 4672 are known. It is typically the part of an 4673 individual's name which is passed on by parents to 4674 their children. 4676 7.6.5 Postal Address Element 4678 This contains an address which can be used, for example, for the physical 4679 delivery of goods, services or letters. Its definition is as follows. 4681 4682 4692 Attributes: 4694 xml:lang Defines the language used by attributes within 4695 this element. See section 3.8 Identifying 4696 Languages. 4698 AddressLine1 The first line of a postal address. e.g. "The 4699 Meadows" 4701 AddressLine2 The second line of a postal address. e.g. "Sandy 4702 Lane" 4704 CityOrTown The city of town of the address. e.g. "Carpham" 4706 StateOrRegion The state or region within a country where the 4707 city or town is placed. e.g. "Surrey" 4709 Postal Code The code known as, for example a post code or zip 4710 code, that is typically used by Postal 4711 Organisations to organise postal deliveries into 4712 efficient sequences. e.g. "KT22 1AA" 4714 Country The country for the address. e.g. "UK" 4716 LegalLocation This identifies whether the address is the 4717 Registered Address for the Organisation. At least 4718 one address for the Organisation must have a value 4719 set to True unless the Trading Role is either 4720 Consumer or DeliverTo. 4722 7.7 Brand List Component 4724 Brand List Components are contained within the Trading Protocol Options 4725 Block (see section 8.1) of the IOTP Transaction. They contains lists of: 4727 o payment Brands (see also section 11.1 Brand Definitions and Brand 4728 Selection), 4730 o amounts to be paid in the currencies that are accepted or offered by 4731 the Merchant, 4733 o the payment protocols which can be used to make payments with a Brand, 4734 and 4736 o the net locations of the Payment Handlers which accept payment for a 4737 payment protocol 4739 The definition of a Brand List Component is as follows. 4741 4743 4749 Attributes: 4751 ID An identifier which uniquely identifies the Brand 4752 List Component within the IOTP Transaction. 4754 xml:lang Defines the language used by attributes or child 4755 elements within this component, unless overridden 4756 by an xml:lang attribute on a child element. See 4757 section 3.8 Identifying Languages. 4759 ShortDesc A text description in the language defined by 4760 xml:Lang giving details of the purpose of the 4761 Brand List. This information must be displayed to 4762 the receiver of the Brand List in order to assist 4763 with making the selection. It is of particular 4764 benefit in allowing a Consumer to distinguish the 4765 purpose of a Brand List when an IOTP Transaction 4766 involves more than one payment. 4768 PayDirection Indicates the direction in which the payment for 4769 which a Brand is being selected is to be made. Its 4770 values may be: 4771 o Debit The sender of the Payment Request Block 4772 (e.g. the Consumer) to which this Brand List 4773 relates will make the payment to the Payment 4774 Handler, or 4775 o Credit The sender of the Payment Request Block 4776 to which this Brand List relates will receive a 4777 payment from the Payment Handler. 4779 Content: 4781 Brand This describes a Brand. The sequence of the Brand 4782 elements (see section 7.7.1) within the Brand List 4783 does not indicate any preference. It is 4784 recommended that software which processes this 4785 Brand List presents Brands in a sequence which the 4786 receiver of the Brand List prefers. 4788 ProtocolAmount This links a particular Brand to: 4789 o the currencies and amounts in CurrencyAmount 4790 elements that can be used with the Brand, and 4791 o the Payment Protocols and Payment Handlers, 4792 which can be used with those currencies and 4793 amounts, and a particular Brand 4795 CurrencyAmount This contains a currency code and an amount. 4797 PayProtocol This contains information about a Payment Protocol 4798 and the Payment Handler which may be used with a 4799 particular Brand. 4801 The relationships between the elements which make up the content of the 4802 Brand List is illustrated in the diagram below. 4804 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 4806 Brand List Component 4807 | ProtocolAmountRefs 4808 |-Brand Element----------------------------- 4809 | | | 4810 | - Protocol Brand Element-------- | 4811 | | | 4812 | ProtocolId| | 4813 | | | 4814 |-Protocol Amount Element<----------+------- 4815 | | | | 4816 | | | | 4817 | |CurrencyAmountRefs |Pay | 4818 | | |Protocol | 4819 | v |Ref | 4820 |-Currency Amount Element | | 4821 | Element | | 4822 | | | 4823 -PayProtocolElement<------<-------- 4825 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 4827 Figure 15 Brand List Element Relationships 4829 Examples of complete Brand Lists are contained in section 11.2 Brand List 4830 Examples. 4832 7.7.1 Brand Element 4834 A Brand Element describes a brand that can be used for making a payment. 4835 One or more of these elements is carried in each Brand List Component 4836 that has the PayDirection attribute set to Debit. Exactly one Brand 4837 Element may be carried in a Brand List Component that has the 4838 PayDirection attribute set to Credit. 4840 4841 4851 Attributes: 4853 Id Element identifier, potentially referenced in a 4854 Brand Selection Component contained in a later 4855 Payment Request message and uniquely identifies 4856 the Brand element within the IOTP Transaction. 4858 xml:lang Defines the language used by attributes and 4859 content of this element. See section 3.8 4860 Identifying Languages. 4862 BrandId This contains a unique identifier for the brand 4863 (or promotional brand). It is used to match 4864 against a list of Payment Instruments which the 4865 Consumer holds to determine whether or not the 4866 Consumer can pay using the Brand. 4868 Values of BrandId are managed under the procedure 4869 described in section 12 IANA Considerations. 4871 As values of BrandId are controlled under the 4872 procedures defined in section 12 IANA 4873 Considerations user defined values may be 4874 defined. 4876 BrandName This contains the name of the brand, for example 4877 MasterCard Credit. This is the description of the 4878 Brand which is displayed to the consumer in the 4879 Consumers language defined by xml:lang. For 4880 example it might be "American Airlines Advantage 4881 Visa". Note that this attribute is not used for 4882 matching against the payment instruments held by 4883 the Consumer. 4885 BrandLogoNetLocn The net location which can be used to download 4886 the logo for the Organisation. See section 4887 Retrieving Logos (see section 10). 4889 The content of this attribute must conform to 4890 [RFC1738]. 4892 BrandNarrative This optional attribute is designed to be used by 4893 the Merchant to indicate some special conditions 4894 or benefit which would apply if the Consumer 4895 selected that brand. For example "5% discount", 4896 "free shipping and handling", "free breakage 4897 insurance for 1 year", "double air miles apply", 4898 etc. 4900 ProtocolAmountRefs Identifies the protocols and related currencies 4901 and amounts which can be used with this Brand. 4902 Specified as a list of ID's of Protocol Amount 4903 Elements (see section 7.7.3) contained within the 4904 Brand List. 4906 ContentSoftwareId See section 14. Glossary. 4908 Content: 4910 ProtocolBrand Protocol Brand elements contain brand information 4911 to be used with a specific payment protocol (see 4912 section 7.7.2) 4914 PackagedContent Optional Packaged Content (see section 3.7) 4915 elements containing information about the brand 4916 which may be used by the payment protocol. The 4917 content of this information is defined in the 4918 supplement for a payment protocol which describes 4919 how the payment protocol works with IOTP. 4921 Example Brand Elements are contained in section 11.2 Brand List Examples. 4923 7.7.2 Protocol Brand Element 4925 The Protocol Brand Element contains information that is specific to the 4926 use of a particular Protocol with a Brand. Its definition is as follows. 4928 4929 4933 Attributes: 4935 ProtocolId This must match the value of a ProtocolId 4936 attribute in a Pay Protocol Element (see section 4937 7.7.5). 4939 The values of ProtocolId should be unique within a 4940 Brand Element otherwise there is an error. 4942 ProtocolBrandId This is the Payment Brand Id to be used with a 4943 particular payment protocol. For example, SET and 4944 EMV have their own well defined, yet different, 4945 values for the Brand Id to be used with each 4946 protocol. 4948 The valid values of this attribute are defined in 4949 the supplement for the payment protocol identified 4950 by ProtocolId that describes how the payment 4951 protocol works with IOTP. 4953 Content: 4955 PackagedContent Optional Packaged Content (see section 3.7) 4956 elements containing information about the 4957 protocol/brand which may be used by the payment 4958 protocol. The content of this information is 4959 defined in the supplement for a payment protocol 4960 which describes how the payment protocol works 4961 with IOTP. 4963 7.7.3 Protocol Amount Element 4965 The Protocol Amount element links a Brand to: 4967 o the currencies and amounts in Currency Amount Elements (see section 4968 7.7.4) that can be used with the Brand, and 4970 o the Payment Protocols and Payment Handlers defined in a Pay Protocol 4971 Element (see section 7.7.5), which can be used with those currencies 4972 and amounts. 4974 Its definition is as follows: 4976 4977 4983 Attributes: 4985 Id Element identifier, potentially referenced in a 4986 Brand element; or in a Brand Selection Component 4987 contained in a later Payment Request message 4988 which uniquely identifies the Protocol Amount 4989 element within the IOTP Transaction. 4991 PayProtocolRef Contains an Element Reference (see section 3.5) 4992 that refers to the Pay Protocol Element (see 4993 section 7.7.5) that contains the Payment Protocol 4994 and Payment Handlers that can be used with the 4995 Brand. 4997 CurrencyAmountRefs Contains a list of Element References (see 4998 section 3.5) that refer to the Currency Amount 4999 Element (see section 7.7.4) that describes the 5000 currencies and amounts that can be used with the 5001 Brand. 5003 ContentSoftwareId See section 14. Glossary. 5005 Content: 5007 PackagedContent Optional Packaged Content (see section 3.7) 5008 elements containing information about the protocol 5009 amount which may be used by the payment protocol. 5010 The content of this information is defined in the 5011 supplement for a payment protocol which describes 5012 how the payment protocol works with IOTP. 5014 Examples of Protocol Amount Elements are contained in section 11.2 Brand 5015 List Examples. 5017 7.7.4 Currency Amount Element 5019 A Currency Amount element contains: 5021 o a currency code (and its type), and 5023 o an amount. 5025 One or more of these elements is carried in each Brand List Component. 5026 Its definition is as follows: 5028 5029 5035 Attributes: 5037 Id Element identifier, potentially referenced in a 5038 Brand element; or in a Brand Selection Component 5039 contained in a later Payment Request message which 5040 uniquely identifies the Currency Amount Element 5041 within the IOTP Transaction. 5043 Amount Indicates the amount to be paid in whole and 5044 fractional units of the currency. For example 5045 $245.35 would be expressed "245.35". Note that 5046 values smaller than the smallest denomination are 5047 allowed. For example one tenth of a cent would be 5048 "0.001". 5050 CurrCodeType Indicates the domain of the CurrCode. This 5051 attribute is included so that the currency code 5052 may support non-standard "currencies" such as 5053 frequent flyer points, trading stamps, etc. Its 5054 values may be: 5055 o ISO4217-A (the default) indicates the currency 5056 code is a three character alphabetic currency 5057 code that conforms to [ISO 4217] 5058 o IOTP indicates that values of CurrCode are 5059 managed under the procedure described in 5060 section 12 IANA Considerations 5062 CurrCode A code which identifies the currency to be used in 5063 the payment. The domain of valid currency codes is 5064 defined by CurrCodeType 5066 As values of CurrCodeType are managed under the 5067 procedure described in section 12 IANA 5068 Considerations user defined values of CurrCodeType 5069 may be defined. 5071 Examples of Currency Amount Elements are contained in section 11.2 Brand 5072 List Examples. 5074 7.7.5 Pay Protocol Element 5076 A Pay Protocol element specifies details of a Payment Protocol and the 5077 Payment Handler that can be used with a Brand. One or more of these 5078 elements is carried in each Brand List. 5080 5081 5091 Attributes: 5093 Id Element identifier, potentially referenced in a 5094 Brand element; or in a Brand Selection Component 5095 contained in a later Payment Request message which 5096 uniquely identifies the Pay Protocol element 5097 within the IOTP Transaction. 5099 xml:lang Defines the language used by attributes and 5100 content of this element. See section 3.8 5101 Identifying Languages. 5103 ProtocolId Consists of a protocol name and version. For 5104 example "SETv1.0". 5106 The values of ProtocolId are defined by the 5107 payment scheme/method owners in the document that 5108 describes how to encapsulate a payment protocol 5109 within IOTP. 5111 ProtocolName A narrative description of the payment protocol 5112 and its version in the language identified by 5113 xml:lang. For example "Secure Electronic 5114 Transaction Version 1.0". Its purpose is to help 5115 provide information on the payment protocol being 5116 used if problems arise. 5118 ActionOrgRef An Element Reference (see section 3.5) to the 5119 Organisation Component for the Payment Handler for 5120 the Payment Protocol. 5122 PayReqNetLocn The Net Location indicating where an unsecured 5123 Payment Request message should be sent if this 5124 protocol choice is used. 5126 The content of this attribute is dependent on the 5127 Transport Mechanism (such must conform to 5128 [RFC1738]. 5130 SecPayReqNetLocn The Net Location indicating where a secured 5131 Payment Request message should be sent if this 5132 protocol choice is used. 5134 A secured payment involves the use of a secure 5135 channel such as [SSL/TLS] in order to communicate 5136 with the Payment Handler. 5138 The content of this attribute must conform to 5139 [RFC1738]. See also See section 3.9 Secure and 5140 Insecure Net Locations. 5142 ContentSoftwareId See section 14. Glossary. 5144 Content: 5146 PackagedContent Optional Packaged Content elements (see section 5147 3.7) containing information about the protocol 5148 which is used by the payment protocol. The content 5149 of this information is defined in the supplement 5150 for a payment protocol which describes how the 5151 payment protocol works with IOTP. An example of 5152 its use could be to include a payment protocol 5153 message. 5155 Examples of Pay Protocol Elements are contained in section 11.2 Brand 5156 List Examples. 5158 7.8 Brand Selection Component 5160 A Brand Selection Component identifies the choice of payment brand, 5161 payment protocol and the Payment Handler. This element is used: 5163 o in Payment Request messages within Baseline Purchase and Baseline Value 5164 Exchange IOTP Transactions to identify the brand, protocol and payment 5165 handler for a payment, or 5167 o to, optionally, inform a merchant in a purchase of the payment brand 5168 being used so that the offer and order details can be amended 5169 accordingly. 5171 In Baseline IOTP, the integrity of Brand Selection Components is not 5172 guaranteed. However, modification of Brand Selection Components can only 5173 cause denial of service if the payment protocol itself is secure against 5174 message modification, duplication, and swapping attacks. 5176 The definition of a Brand Selection Component is as follows. 5178 5181 5188 Attributes: 5190 ID An identifier which uniquely identifies the Brand 5191 Selection Component within the IOTP Transaction. 5193 BrandListRef The Element Reference (see section 3.5) of the 5194 Brand List Component from which a Brand is being 5195 selected 5197 BrandRef The Element Reference of a Brand element within 5198 the Brand List Component that is being selected 5199 that is to be used in the payment. 5201 ProtocolAmountRef The Element Reference of a Protocol Amount element 5202 within the Brand List Component which is to be 5203 used when making the payment. 5205 CurrencyAmountRef The Element Reference of a Currency Amount element 5206 within the Brand List Component which is to be 5207 used when making the payment. 5209 Content: 5211 BrandSelBrandInfo, This contains any additional data that 5212 BrandSelProtocolAmountInfo, may be required by a particular payment 5213 BrandSelCurrencyAmountInfo brand or protocol. See sections 7.8.1, 5214 7.8.2, and 7.8.3. 5216 The following rules apply: 5218 o the BrandListRef must contain the ID of a Brand List Component in the 5219 same IOTP Transaction 5221 o every Brand List Component in the Trading Protocol Options Block (see 5222 section 8.1) must be referenced by one and only one Brand Selection 5223 Component 5225 o the BrandRef must refer to the ID of a Brand contained within the Brand 5226 List Component referred to by BrandListRef 5228 o the ProtocolAmountRef must refer to one of the Element IDs listed in 5229 the ProtocolAmountRefs attribute of the Brand element identified by 5230 BrandRef 5232 o the CurrencyAmountRef must refer to one of the Element IDs listed in 5233 the CurrencyAmountRefs attribute of the Protocol Amount Element 5234 identified by ProtocolAmountRef. 5236 An example of a Brand Selection Component is included in 11.2 Brand List 5237 Examples. 5239 7.8.1 Brand Selection Brand Info Element 5241 The Brand Selection Brand Info Element contains any additional data that 5242 may be required by a particular payment brand. See the IOTP payment 5243 method supplement for a description of how and when it used. 5245 5246 5250 Attributes: 5252 ContentSoftwareId See section 14. Glossary. 5254 Content: 5256 PackagedContent Packaged Content elements (see section 3.7) that 5257 contain additional data that may be required by a 5258 particular payment brand. See the payment method 5259 supplement for IOTP for rules on how this is used. 5261 7.8.2 Brand Selection Protocol Amount Info Element 5263 The Brand Selection Protocol Amount Info Element contains any additional 5264 data that is payment protocol specific that may be required by a 5265 particular payment brand or payment protocol. See the IOTP payment method 5266 supplement for a description of how and when it used. 5268 5269 5273 Attributes: 5275 ContentSoftwareId See section 14. Glossary. 5277 Content: 5279 PackagedContent Packaged Content elements (see section 3.7) that 5280 may contain additional data that may be required 5281 by a particular payment brand. See the payment 5282 method supplement for IOTP for rules on how this 5283 is used. 5285 7.8.3 Brand Selection Currency Amount Info Element 5287 The Brand Selection Currency Amount Info Element contains any additional 5288 data that is payment brand and currency specific that may be required by 5289 a particular payment brand. See the IOTP payment method supplement for a 5290 description of how and when it used. 5292 5293 5297 Attributes: 5299 ContentSoftwareId See section 14. Glossary. 5301 Content: 5303 PackagedContent Packaged Content elements (see section 3.7) that 5304 contain additional data relating to the payment 5305 brand and currency. See the payment method 5306 supplement for IOTP for rules on how this is used. 5308 7.9 Payment Component 5310 A Payment Component contains information used to control how a payment is 5311 carried out. Its provides information on: 5313 o the times within which a Payment with a Payment Handler may be started 5315 o a reference to the Brand List (see section 7.7) which identifies the 5316 Brands, protocols, currencies and amounts which can be used to make a 5317 payment 5319 o whether or not a payment receipt will be provided 5321 o whether another payment precedes this payment. 5323 Its definition is as follows. 5325 5326 5334 Attributes: 5336 ID An identifier which uniquely identifies the 5337 Payment Component within the IOTP Transaction. 5339 OkFrom The date and time in [UTC] format after which a 5340 Payment Handler may accept for processing a 5341 Payment Request Block (see section 8.7) containing 5342 the Payment Component. 5344 OkTo The date and time in [UTC] format before which a 5345 Payment Handler may accept for processing a 5346 Payment Request Block containing the Payment 5347 Component. 5349 BrandListRef An Element Reference (see section 3.5) of a Brand 5350 List Component (see section 7.7) within the TPO 5351 Trading Block for the IOTP Transaction. The Brand 5352 List identifies the alternative ways in which the 5353 payment can be made. 5355 SignedPayReceipt Indicates whether or not the Payment Response 5356 Block (see section 8.9) generated by the Payment 5357 Handler for the payment must be digitally signed. 5359 StartAfter Contains Element References (see section 3.5) of 5360 other Payment Components which describe payments 5361 which must be complete before this payment can 5362 start. If no StartAfter attribute is present then 5363 there are no dependencies and the payment can 5364 start immediately 5366 7.10 Payment Scheme Component 5368 A Payment Scheme Component contains payment protocol information for a 5369 specific payment scheme which is transferred between the parties involved 5370 in a payment for example a [SET] message. Its definition is as follows. 5372 5373 5380 Attributes: 5382 ID An identifier which uniquely identifies the 5383 Payment Scheme Component within the IOTP 5384 Transaction. 5386 PaymentRef An Element Reference (see section 3.5) to the 5387 Payment Component (see section 7.9) to which 5388 this Payment Scheme Component relates. It is 5389 required unless the Payment Scheme Component is 5390 part of an Transaction Inquiry Status 5391 Transaction (see section 9.2.1). 5393 ConsumerPaymentId An identifier specified by the Consumer which, 5394 if returned by the Payment Handler in another 5395 Payment Scheme Component or by other means, will 5396 enable the Consumer to identify which payment is 5397 being referred to. 5399 PaymentHandlerPayId An identifier specified by the Payment Handler 5400 which, if returned by the Consumer in another 5401 Payment Scheme Component, or by other means, 5402 will enable the Payment Handler to identify 5403 which payment is being referred to. It is 5404 required on every Payment Scheme Component apart 5405 from the one contained in a Payment Request 5406 Block. 5408 ContentSoftwareId See section 14. Glossary. 5410 Content: 5412 PackagedContent Contains payment scheme protocol information as 5413 Packaged Content elements (see section 3.7). See 5414 the payment scheme supplement for the definition 5415 of its content. 5417 Note that: 5418 o the values of the Name attribute of each 5419 packaged content element are defined by the 5420 Payment Protocol Supplement 5421 o the value of each Name must be unique within a 5422 Payment where a Payment is defined as all 5423 Payment Scheme or Payment Receipt Components 5424 with the same value of the PaymentRef attribute 5426 7.11 Payment Receipt Component 5428 A Payment Receipt is a record of a payment which demonstrates how much 5429 money has been paid or received. It is distinct from a purchase receipt 5430 in that it contains no record of what was being purchased. 5432 Typically the content of a Payment Receipt Component will contain data 5433 which describes: 5435 o the amount paid and its currency 5437 o the date and time of the payment 5439 o internal reference numbers which identify the payment to the payment 5440 system 5442 o potentially digital signatures generated by the payment method which 5443 can be used to prove after the event that the payment occurred. 5445 If the Payment Method being used provides the facility then the Payment 5446 Receipt Component should contain payment protocol messages, or references 5447 to messages, which prove the payment occurred. 5449 The precise definition of the content is Payment Method dependent. Refer 5450 to the supplement for the payment method being used to determine the 5451 rules that apply. 5453 Information contained in the Payment Receipt Component should be 5454 displayed or otherwise made available to the Consumer. 5456 [Note] If the Payment Receipt Component contains Payment Protocol 5457 Messages, then the Messages will need to be processed by 5458 Payment Method software to convert it into a format which can 5459 be understood by the Consumer 5460 [Note End] 5462 The definition of a Payment Receipt Component is as follows. 5464 5465 5471 Attributes: 5473 ID An identifier which uniquely identifies the 5474 Payment Receipt Component within the IOTP 5475 Transaction. 5477 PaymentRef Contains an Element Reference (see section 3.5) 5478 to the Payment Component (see section 7.9) to 5479 which this payment receipt applies 5481 PayReceiptNameRefs Optionally contains a list of the values of the 5482 Name attributes of Packaged Content elements that 5483 together make up the receipt. The Packaged 5484 Content elements are contained either within: 5485 o Payment Scheme Data components exchanged 5486 between the Payment Handler and the Consumer 5487 roles during the Payment, and/or 5488 o the Payment Receipt component itself. 5490 Note that: 5491 o each payment scheme defines in its supplement 5492 the Names of the Packaged Content elements 5493 that must be listed in this attribute (if 5494 any). 5495 o if a Payment Scheme Component contains 5496 Packaged Content elements with a name that 5497 matches a name within PayReceiptNameRefs, then 5498 those Payment Scheme Components must be 5499 referenced by Digests in the Payment Response 5500 signature component (if such a signature is 5501 being used) 5503 The client software should save all the 5504 components referenced so that the payment receipt 5505 can be reconstructed when required. 5507 ContentSoftwareId See section 14. Glossary. 5509 Content: 5511 PackagedContent Optionally contains payment scheme payment receipt 5512 information as Packaged Content elements (see 5513 section 3.7). See the payment scheme supplement 5514 for the definition of its content. 5516 Note that: 5517 o the values of the Name attribute of each 5518 packaged content element are defined by the 5519 Payment Protocol Supplement 5520 o the value of each Name must be unique within a 5521 Payment where a Payment is defined as all 5522 Payment Scheme or Payment Receipt Components, 5523 with the same value of the PaymentRef attribute 5525 Note that either the PayReceiptNameRefs attribute, the PackagedContent 5526 element, or both must be present. 5528 7.12 Payment Note Component 5530 The Payment Note Component contains additional, non payment related, 5531 information which the Payment Handler wants to provide to the Consumer. 5532 For example, if a withdrawal or deposit were being made then it could 5533 contain information on the remaining balance on the account after the 5534 transfer was complete. The information should duplicate information 5535 contained within the Payment Receipt Component. 5537 Information contained in the Payment Note Component should be displayed 5538 or otherwise made available to the Consumer. For interoperability, the 5539 Payment Note Component should support, as a minimum, the content types of 5540 "Plain Text", HTML and XML. Its definition is as follows. 5542 5543 5547 Attributes: 5549 ID An identifier which uniquely identifies the 5550 Payment Receipt Component within the IOTP 5551 Transaction. 5553 ContentSoftwareId See section 14. Glossary. 5555 Content: 5557 PackagedContent Contains additional, non payment related, 5558 information which the Payment Handler wants to 5559 provide to the Consumer as one or more Packaged 5560 Content elements (see section 3.7). 5562 7.13 Delivery Component 5564 The Delivery Element contains information required to deliver goods or 5565 services. Its definition is as follows. 5567 5568 5575 Attributes: 5577 ID An identifier which uniquely identifies the 5578 Delivery Component within the IOTP Transaction. 5580 xml:lang Defines the language used by attributes or child 5581 elements within this component, unless overridden 5582 by an xml:lang attribute on a child element. See 5583 section 3.8 Identifying Languages. 5585 DelivExch Indicates if this IOTP Transaction includes the 5586 messages associated with a Delivery Exchange. 5587 Valid values are: 5588 o True indicates it does include a Delivery 5589 Exchange 5590 o False indicates it does not include a 5591 Delivery Exchange 5593 If set to true then a DeliveryData element must 5594 be present. If set to false it may be absent. 5596 DelivAndPayResp Indicates if the Delivery Response Block (see 5597 section 8.11) and the Payment Response Block (see 5598 section 8.9 ) are combined into one IOTP Message. 5599 Valid values are: 5600 o True indicates both blocks will be in the 5601 same IOTP Message, and 5602 o False indicates each block will be in a 5603 different IOTP Message 5605 DelivAndPayResp should not be true if DelivExch 5606 is False. 5608 In practice combining the Delivery Response Block 5609 and Payment Response Block is only likely to be 5610 practical if the Merchant, the Payment Handler 5611 and the Delivery Handler are the same 5612 Organisation since: 5613 o the Payment Handler must have access to Order 5614 Component information so that they know what 5615 to deliver, and 5616 o the Payment Handler must be able to carry out 5617 the delivery 5619 ActionOrgRef An Element Reference to the Organisation 5620 Component of the Delivery Handler for this 5621 delivery. 5623 Content: 5625 DeliveryData Contains details about how the delivery will be 5626 carried out. See 7.13.1 Delivery Data Element 5627 below. 5629 PackagedContent Contains "user" data defined for the Merchant 5630 which is required by the Delivery Handler as one 5631 or more Packaged Content Elements see section 3.7. 5633 7.13.1 Delivery Data Element 5635 The DeliveryData element contains information about where and how goods 5636 are to be delivered. Its definition is as follows. 5638 5639 5649 Attributes: 5651 xml:lang Defines the language used by attributes within 5652 this component. See section 3.8 Identifying 5653 Languages. 5655 OkFrom The date and time in [UTC] format after which the 5656 Delivery Handler may accept for processing a 5657 Delivery Request Block (see section 8.10). 5659 OkTo The date and time in [UTC] format before which 5660 the Delivery Handler may accept for processing a 5661 Delivery Request Block. 5663 DelivMethod Indicates the method by which goods or services 5664 may be delivered. Valid values are: 5665 o Post the goods will be delivered by post or 5666 courier 5667 o Web the goods will be delivered 5668 electronically in the Delivery Note Component 5669 o Email the goods will be delivered 5670 electronically by e-mail 5672 Values of DelivMethod are managed under the 5673 procedure described in section 12 IANA 5674 Considerations which allows user defined codes to 5675 be defined. 5677 DelivToRef The Element Reference (see section 3.4) of an 5678 Organisation Component within the IOTP 5679 Transaction which has a role of DelivTo. The 5680 information in this block is used to determine 5681 where delivery is to be made. It must be 5682 compatible with DelivMethod. Specifically if the 5683 DelivMethod is: 5684 o Post, then the there must be a Postal Address 5685 Element containing sufficient information for 5686 a postal delivery, 5687 o Web, then there are no specific requirements. 5688 The information will be sent in a web page 5689 back to the Consumer 5690 o Email, then there must be Contact Information 5691 Element with a valid e-mail address 5693 DelivReqNetLocn This contains the Net Location to which an 5694 unsecured Delivery Request Block (see section 5695 8.10) which contains the Delivery Component 5696 should be sent. 5698 The content of this attribute is dependent on the 5699 Transport Mechanism and must conform to 5700 [RFC1738]. 5702 SecDelivReqNetLocn This contains the Net Location to which a secured 5703 Delivery Request Block (see section 8.10) which 5704 contains the Delivery Component should be sent. 5706 A secured delivery request involves the use of a 5707 secure channel such as [SSL/TLS] in order to 5708 communicate with the Payment Handler. 5710 The content of this attribute is dependent on the 5711 Transport Mechanism must conform to [RFC1738]. 5713 See also Section 3.9 Secure and Insecure Net 5714 Locations. 5716 ContentSoftwareId See section 14. Glossary. 5718 Content: 5720 PackagedContent Additional information about the delivery as one 5721 or more Packaged Content elements (see section 5722 3.7) provided to the Delivery Handler by the 5723 merchant. 5725 7.14 Consumer Delivery Data Component 5727 A Consumer Delivery Data Component is used by a Consumer to specify an 5728 identifier that can be used by the Consumer to identify the Delivery. 5730 Its definition is as follows: 5732 5733 5737 Attributes: 5739 ID An identifier which uniquely identifies the 5740 Consumer Delivery Data Component within the IOTP 5741 Transaction. 5743 ConsumerDeliveryId An identifier specified by the Consumer which, if 5744 returned by the Delivery Handler will enable the 5745 Consumer to identify which Delivery is being 5746 referred to. 5748 7.15 Delivery Note Component 5750 A Delivery Note contains delivery instructions about the delivery of 5751 goods or services or potentially the actual Delivery Information itself. 5752 It is information which the person or Organisation receiving the Delivery 5753 Note can use when delivery occurs. 5755 For interoperability, the Delivery Note Component Packaged Content should 5756 support both Plain Text, HTML and XML. 5758 It's definition is as follows. 5760 5761 5767 Attributes: 5769 ID An identifier which uniquely identifies the 5770 Delivery Note Component within the IOTP 5771 Transaction. 5773 xml:lang Defines the language used by attributes or child 5774 elements within this component, unless 5775 overridden by an xml:lang attribute on a child 5776 element. See section 3.8 Identifying Languages. 5778 DelivHandlerDelivId An optional identifier specified by the Delivery 5779 Handler which, if returned by the Consumer in 5780 another Delivery Component, or by other means, 5781 will enable the Delivery Handler to identify 5782 which Delivery is being referred to. It is 5783 required on every Delivery Component apart from 5784 the one contained in a Delivery Request Block. 5786 An example use of this attribute is to contain a 5787 delivery tracking number. 5789 ContentSoftwareId See section 14. Glossary. 5791 Content: 5793 PackagedContent Contains actual delivery note information as one 5794 or more Packaged Content elements (see section 5795 3.7). 5797 [Note] If the content of the Delivery Message is a Mime message then 5798 the Delivery Note may trigger an application which causes the 5799 actual delivery to occur. 5800 [Note End] 5802 7.16 Status Component 5804 A Status Component contains status information about the business success 5805 or failure (see section 4.2) of a process. 5807 Its definition is as follows. 5809 5810 5821 Attributes: 5823 ID An identifier which uniquely identifies the Status 5824 Component within the IOTP Transaction. 5826 xml:lang Defines the language used by attributes within 5827 this component. See section 3.8 Identifying 5828 Languages. 5830 StatusType Indicates the type of Document Exchange which the 5831 Status is reporting on. It may be set to either 5832 Offer, Payment, Delivery, Authentication or 5833 Undefined. 5835 Undefined means that the type of document exchange 5836 could not be identified. This is caused by an 5837 error in the initial input message of the 5838 exchange. 5840 Values of StatusType are managed under the 5841 procedure described in section 12 IANA 5842 Considerations which also allows user defined 5843 values of StatusType to be defined. 5845 ElRef If the StatusType is not set to Undefined then 5846 ElRef contains an Element Reference (see section 5847 3.5) to the Component for which the Status is 5848 being described. It must refer to either: 5849 o an Order Component (see section 7.5), if the 5850 StatusType is Offer, 5851 o a Payment Component (see section 7.9), if the 5852 StatusType is Payment, or 5853 o a Delivery Component (see section 7.13), if 5854 the StatusType is Delivery 5855 o an Authentication Request Component (see 5856 section 7.2) if the StatusType is 5857 Authentication. 5859 ProcessState Contains a State Code which indicates the current 5860 state of the process being carried out. Valid 5861 values for ProcessState are: 5862 o NotYetStarted. A Request Block has been 5863 received but the process has not yet started 5864 o InProgress. Processing of the Request Block 5865 has started but it is not yet complete 5866 o CompletedOk. The processing of the Request 5867 Block has completed successfully without any 5868 errors 5869 o Failed. The processing of the Request Block 5870 has failed because of a Business Error (see 5871 section 4.2) 5872 o ProcessError. This value is only used when the 5873 Status Component is being used in connection 5874 with an Inquiry Request Trading Block (see 5875 section 8.12). It indicates there was a 5876 Technical Error (see section 4.1) in the 5877 Request Block which is being processed or some 5878 internal processing error. 5880 Note that this code reports on the processing of a 5881 Request Block. Further, asynchronous processing 5882 may occur after the Response Block associated with 5883 the Process has been sent. 5885 CompletionCode Indicates how the process completed. Valid values 5886 for the CompletionCode are given below together 5887 with the conditions when it must be present and 5888 indications on when recovery from failures are 5889 possible. 5891 A CompletionCode is a maximum of 14 characters 5892 long. 5894 ProcessReference This optional attribute holds a reference for the 5895 process whose status is being reported. It may 5896 hold the following values: 5897 o when StatusType is set to Offer, it should 5898 contain the OrderIdentifier from the Order 5899 Component 5900 o when StatusType is set to Payment, it should 5901 contain the PaymentHandlerPayId from the 5902 Payment Scheme Data Component 5903 o when StatusType is set to Delivery, it should 5904 contain the DelivHandlerDelivId from the 5905 Delivery Note Component 5906 o when StatusType is set to Authentication, it 5907 should contain the AuthenticationId from the 5908 Authentication Request Component 5910 This attribute should be absent in the Inquiry 5911 Request message when the Consumer has not been 5912 given such a reference number by the IOTP Service 5913 Provider. 5915 This attribute can be used inside an Inquiry 5916 Response Block (see section 8.13) to give the 5917 reference number for a transaction which has 5918 previously been unavailable. 5920 For example, the package tracking number might not 5921 be assigned at the time a delivery response was 5922 received. However, if the Consumer issues a 5923 Baseline Transaction Status Inquiry later, the 5924 Delivery Handler can put the package tracking 5925 number into this attribute in the Inquiry Response 5926 message and send it back to the Consumer. 5928 StatusDesc An optional textual description of the current 5929 status of the process in the language identified 5930 by xml:lang. 5932 7.16.1 Offer Completion Codes 5934 The Completion Code is only required if the ProcessState attribute is set 5935 to Failed. The following table contains the valid values for the 5936 CompletionCode that may be used and indicates whether or not recovery 5937 might be possible. It is recommended that the StatusDesc attribute is 5938 used to provide further explanation where appropriate. 5940 Value Description 5942 AuthError Authentication Error. The check of the 5943 Authentication Response which was carried out has 5944 failed. 5946 Recovery may be possible by the Consumer re- 5947 submitting a new Authentication Response Block with 5948 corrected information. 5950 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 5951 the transaction for some reason. This code is only 5952 valid in a Status Component contained in a Cancel 5953 Block or an Inquiry Response Block. 5955 No recovery possible. 5957 MerchCancelled Offer Cancelled. The Merchant declines to generate 5958 an offer for some reason and cancels the 5959 transaction. This code is only valid in a Status 5960 Component contained in a Cancel Block or an Inquiry 5961 Response Block. 5963 No recovery possible. 5965 Unspecified Unspecified error. There is some unknown problem or 5966 error which does not fall into one of the other 5967 CompletionCodes. 5969 No recovery possible. 5971 TimedOutRcvr Recoverable Time Out. Messages were resent but no 5972 response received. The document exchange has 5973 therefore "Timed Out". This code is only valid on a 5974 Transaction Inquiry. 5976 Recovery is possible if the last message from the 5977 other Trading Role is received again. 5979 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 5980 no response received. The document exchange has 5981 therefore "Timed Out". This code is only valid on a 5982 Transaction Inquiry. 5984 No recovery possible. 5986 7.16.2 Payment Completion Codes 5988 The CompletionCode is only required if the ProcessState attribute is set 5989 to Failed. The following table contains the valid values for the 5990 CompletionCode that may be used and indicates where recovery may be 5991 possible. It is recommended that the StatusDesc attribute is used by 5992 individual payment schemes to provide further explanation where 5993 appropriate. 5995 Value Description 5997 BrandNotSupp Brand not supported. The payment brand is not 5998 supported by the Payment Handler. 6000 See below for recovery options. 6002 CurrNotSupp Currency not supported. The currency in which the 6003 payment is to be made is not supported by either 6004 the Payment Instrument or the Payment Handler. 6006 If the payment is Brand Independent, then the 6007 Consumer may recover by selecting a different 6008 currency, if available, or a different brand. Note 6009 that this may involve a different Payment Handler. 6011 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 6012 the payment for some reason. This code is only 6013 valid in a Status Component contained in a Cancel 6014 Block or an Inquiry Response Block. 6016 Recovery is not possible. 6018 PaymtCancelled Payment Cancelled. The Payment Handler declines to 6019 complete the payment for some reason and cancels 6020 the transaction. This code is only valid in a 6021 Status Component contained in a Cancel Block or an 6022 Inquiry Response Block. 6024 See below for recovery options. 6026 AuthError Authentication Error. The Payment Scheme specific 6027 authentication check which was carried out has 6028 failed. 6030 Recovery may be possible. See the payment scheme 6031 supplement to determine what is allowed. 6033 InsuffFunds Insufficient funds. There are insufficient funds 6034 available for the payment to be made. 6036 See below for recovery options. 6038 InstBrandInvalid Payment Instrument not valid for Brand. A Payment 6039 Instrument is being used which does not correspond 6040 with the Brand selected. For example a Visa credit 6041 card is being used when MasterCard was selected as 6042 the Brand. 6044 See below for recovery options. 6046 InstNotValid Payment instrument not valid for trade. The 6047 Payment Instrument cannot be used for the proposed 6048 type of trade, for some reason. 6050 See below for recovery options. 6052 BadInstrument Bad instrument. There is a problem with the 6053 Payment Instrument being used which means that it 6054 is unable to be used for the payment. 6056 See below for recovery options. 6058 Unspecified Unspecified error. There is some unknown problem 6059 or error which does not fall into one of the other 6060 CompletionCodes. The StatusDesc attribute should 6061 provide the explanation of the cause. 6063 See below for recovery options. 6065 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6066 response received. The document exchange has 6067 therefore "Timed Out". This code is only valid on 6068 a Transaction Inquiry. 6070 Recovery is possible if the last message from the 6071 other Trading Role is received again. 6073 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 6074 no response received. The document exchange has 6075 therefore "Timed Out". This code is only valid on 6076 a Transaction Inquiry. 6078 No recovery possible. 6080 If the Payment is Brand Independent, then recovery may be possible for 6081 some values of the Completion Code, by the Consumer selecting either a 6082 different payment brand or a different payment instrument for the same 6083 brand. Note that this might involve a different Payment Handler. The 6084 codes to which this applies are: BrandNotSupp, PaymtCancelled, 6085 InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and 6086 Unspecified. 6088 Recovery from Payments associated with Brand Dependent purchases is only 6089 possible, if the Brand Selection component sent by the Merchant to the 6090 Consumer does not change. In practice this means that the same Brand, 6091 Protocol Amount and PayProtocol elements must be used. All that can 6092 change is the Payment Instrument. Any other change will invalidate the 6093 Merchant's Offer as a changed selection will invalidate the Offer 6094 Response. 6096 7.16.3 Delivery Completion Codes 6098 The following table contains the valid values for the CompletionCode 6099 attribute for a Delivery. It is recommended that the StatusDesc attribute 6100 is used to provide further explanation where appropriate. 6102 Value Description 6104 BackOrdered Back Ordered. The goods to be delivered are on order 6105 but they have not yet been received. Shipping will be 6106 arranged when they are received. This is only valid 6107 if ProcessState is CompletedOk. 6109 Recovery is not possible. 6111 PermNotAvail Permanently Not Available. The goods are permanently 6112 unavailable and cannot be re-ordered. This is only 6113 valid if ProcessState is Failed. 6115 Recovery is not possible. 6117 TempNotAvail Temporarily Not Available. The goods are temporarily 6118 unavailable and may become available if they can be 6119 ordered. This is only valid if ProcessState is 6120 CompletedOk. 6122 Recovery is not possible. 6124 ShipPending Shipping Pending. The goods are available and are 6125 scheduled for shipping but they have not yet been 6126 shipped. This is only valid if ProcessState is 6127 CompletedOk. 6129 Recovery is not possible. 6131 Shipped Goods Shipped. The goods have been shipped. 6132 Confirmation of delivery is awaited. This is only 6133 valid if ProcessState is CompletedOk. 6135 Recovery is not possible. 6137 ShippedNoConf Shipped - No Delivery Confirmation. The goods have 6138 been shipped but it is not possible to confirm 6139 delivery of the goods. This is only valid if 6140 ProcessState is CompletedOk. 6142 Recovery is not possible. 6144 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 6145 the delivery for some reason. This code is only valid 6146 in a Status Component contained in a Cancel Block or 6147 an Inquiry Response Block. 6149 Recovery is not possible. 6151 DelivCancelled Delivery Cancelled. The Delivery Handler declines to 6152 complete the Delivery for some reason and cancels the 6153 transaction. This code is only valid in a Status 6154 Component contained in a Cancel Block or an Inquiry 6155 Response Block. 6157 Recovery is not possible. 6159 Confirmed Confirmed. All goods have been delivered and 6160 confirmation of their delivery has been received. 6161 This is only valid if ProcessState is CompletedOk. 6163 Recovery is not possible. 6165 Unspecified Unspecified error. There is some unknown problem or 6166 error which does not fall into one of the other 6167 CompletionCodes. The StatusDesc attribute should 6168 provide the explanation of the cause. 6170 Recovery is not possible. 6172 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6173 response received. The document exchange has 6174 therefore "Timed Out". This code is only valid on a 6175 Transaction Inquiry. 6177 Recovery is possible if the last message from the 6178 other Trading Role is received again. 6180 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6181 response received. The document exchange has 6182 therefore "Timed Out". This code is only valid on a 6183 Transaction Inquiry. 6185 No recovery possible. 6187 [Note] Recovery from failed, or partially completed deliveries is not 6188 possible. The Consumer should use the Transaction Status 6189 Inquiry Transaction (see section 9.2.1) to determine up-to- 6190 date information on the current state. 6191 [Note End] 6193 7.16.4 Authentication Completion Codes 6195 The Completion Code is only required if the ProcessState attribute is set 6196 to Failed. The following table contains the valid values for the 6197 CompletionCode that may be used. It is recommended that the StatusDesc 6198 attribute is used to provide further explanation where appropriate. 6200 Value Description 6202 AutEeCancel Authenticatee Cancel. The Organisation being 6203 authenticated declines to be authenticated for some 6204 reason. This could be, for example because the 6205 signature on an Authentication Request was invalid or 6206 the Authenticator was not known or acceptable to the 6207 Authenticatee. 6209 Recovery is not possible. 6211 AutOrCancel Authenticator Cancel. The Organisation requesting 6212 authentication declines to validate the 6213 Authentication Response received for some reason and 6214 cancels the transaction. 6216 Recovery is not possible. 6218 NoAuthReq Authentication Request Not Available. The 6219 Authenticatee does not have the data that must be 6220 provided so that they may be successfully 6221 authenticated. For example a password may have been 6222 forgotten, the Authenticatee has not yet become a 6223 member, or a smart card token is not present. 6225 Recovery is not possible 6227 AuthFailed Authentication Failed. The Authenticator checked the 6228 Authentication Response but the authentication failed 6229 for some reason. For example a password may have been 6230 incorrect. 6232 Recovery may be possible by the Authenticatee re- 6233 sending a revised Authentication Response with 6234 corrected data. 6236 TradRolesIncon Trading Roles Inconsistent. The Trading Roles 6237 contained within the TradingRoleList attribute of the 6238 Trading Role Information Request Component (see 6239 section 7.4) are inconsistent with the Trading Role 6240 which the Authenticatee is taking in the IOTP 6241 Transaction or is able to take. Examples of 6242 inconsistencies include: 6243 o asking a PaymentHandler for DeliveryHandler 6244 information 6245 o asking a Consumer for Merchant information 6247 Recovery may be possible by the Authenticator re- 6248 sending a revised Authentication Request Block with 6249 corrected information. 6251 Unspecified Unspecified error. There is some unknown problem or 6252 error which does not fall into one of the other 6253 CompletionCodes. 6255 Recovery is not possible. 6257 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6258 response received. The document exchange has 6259 therefore "Timed Out". This code is only valid on a 6260 Transaction Inquiry. 6262 Recovery is possible if the last message from the 6263 other Trading Role is received again. 6265 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6266 response received. The document exchange has 6267 therefore "Timed Out". This code is only valid on a 6268 Transaction Inquiry. 6270 No recovery possible. 6272 7.16.5 Undefined Completion Codes 6274 The Completion Code is only required if the ProcessState attribute is set 6275 to Failed. The following table contains the valid values for the 6276 CompletionCode that may be used. It is recommended that the StatusDesc 6277 attribute is used to provide further explanation where appropriate. 6279 Value Description 6281 InMsgHardError Input Message Hard Error. The type of Request Block 6282 could not be identified or was inconsistent. 6283 Therefore no single Document Exchange could be 6284 identified. This will cause a Hard Error in the 6285 transaction 6287 7.16.6 Transaction Inquiry Completion Codes 6289 The Completion Code is only required if the ProcessState attribute is set 6290 to Failed. The following table contains the valid values for the 6291 CompletionCode that may be used. It is recommended that the StatusDesc 6292 attribute is used to provide further explanation where appropriate. 6294 Value Description 6296 UnAuthReq Unauthorised Request. The recipient of the 6297 Transaction Status Request declines to respond to the 6298 request. 6300 7.17 Trading Role Data Component 6302 The Trading Role Data Component contains opaque data which needs to be 6303 communicated between the Trading Roles involved in an IOTP Transaction. 6305 Trading Role Components identify: 6307 o the Organisation that generated the component, and 6309 o the Organisation that is to receive it. 6311 They are first generated and included in a "Response" Block, and then 6312 copied to the appropriate "Request" Block. For example a Payment Handler 6313 might need to inform a Delivery Handler that a credit card payment had 6314 been authorised but not captured. There may also be other information 6315 that the Payment Handler has generated where the format is privately 6316 agreed with the Delivery Handler which needs to be communicated. In 6317 another example a Merchant might need to provide a Payment Handler with 6318 some specific information about a Consumer so that consumer can acquire 6319 double loyalty points with the payment. 6321 Its definition is as follows. 6323 6324 6329 Attributes: 6331 ID An identifier which uniquely identifies the 6332 Trading Role Data Component within the IOTP 6333 Transaction. 6335 OrginatorElRef Contains an element reference to the Organisation 6336 Component of the Organisation that created the 6337 Trading Role Data Component and included it in a 6338 "Response" Block (e.g. an Offer Response or a 6339 Payment Response Block). 6341 DestinationElRefs Contains element references to the Organisation 6342 Components of the Organisations that are to 6343 receive the Trading Role Data Component in a 6344 "Request" Block (e.g. either a Payment Request or 6345 a Delivery Request Block). 6347 Content: 6349 PackagedContent This contains the data which is to be sent between 6350 the various Trading Roles as one or more 6351 PackagedContent elements see section 3.7. 6353 7.17.1 Who Receives a Trading Role Data Component 6355 The rules for deciding what to do with Trading Role Data Components are 6356 described below. 6358 o whenever a Trading Role Data Component is received in a "Response" 6359 block identify the Organisation Components of the Organisations that 6360 are to receive it as identified by the DestinationElRefs attribute. 6362 o whenever a "Request" Block is being sent, check to see if it is being 6363 sent to one of the Organisations identified by the DestinationElRefs 6364 attribute. If it is then include in the "Request" block: 6365 - the Trading Role Data Component as well as, 6366 - the Organisation Component of the Organisation identified by the 6367 OriginatorElRef attribute (if not already present) 6369 7.18 Inquiry Type Component 6371 The Inquiry Type Component contains the information which indicates the 6372 type of process that is being inquired upon. Its definition is as 6373 follows. 6375 6376 6382 Attributes: 6384 ID An identifier which uniquely identifies the 6385 Inquiry Type Component within the IOTP 6386 Transaction. 6388 Type Contains the type of inquiry. Valid values for 6389 Type are: 6390 o Offer. The inquiry is about the status of an 6391 offer and is addressed to the Merchant. 6392 o Payment. The inquiry is about the status of a 6393 payment and is addressed to the Payment 6394 Handler. 6395 o Delivery. The inquiry is about the status of a 6396 delivery and addressed to the Delivery Handler. 6398 ElRef Contains an Element Reference (see section 3.5) to 6399 the component to which this Inquiry Type Component 6400 applies. That is, 6401 o TPO Block when Type is Offer 6402 o Payment Component when Type is Payment 6403 o Delivery Component when Type is Delivery 6405 ProcessReference Optionally contains a reference to the process 6406 being inquired upon. It should be set if the 6407 information is available. For the definition of 6408 the values it may contain, see the 6409 ProcessReference attribute of the Status Component 6410 (see section 7.16). 6412 7.19 Signature Component 6414 [Note] Definitions of the XML structures for signatures and 6415 certificates are described in the document titled "Digital 6416 Signatures for the Internet Open Trading Protocol" by Kent 6417 Davidson and Yoshiaki Kawatsura published at the same time as 6418 this document - see [IOTPDSIG]. 6420 In the future it is anticipated that future versions of IOTP 6421 will adopt a whatever method for digitally signing XML becomes 6422 the standard. 6423 [Note End] 6425 Each Signature Component digitally signs one or more Blocks or Components 6426 including other Signature Components. 6428 The Signature Component: 6430 o contains digests of one or more Blocks or Components in one or more 6431 IOTP Messages within the same IOTP Transaction and places the result in 6432 a Digest Element 6434 o concatenates these Digest elements with other information on the type 6435 of signature, the originator and potential recipients of the signature 6436 and details of the signature algorithms being used and places them in a 6437 Manifest element, and 6439 o signs the Manifest element using the optional certificate identified in 6440 the Certificate element within the Signature Block placing the result 6441 in a Value element within a Signature Component 6443 Note that there may be multiple Value elements that contain signatures of 6444 a Manifest Element. 6446 A Signature Component can be one of four types either: 6448 o an Offer Response Signature, 6450 o a Payment Response Signature, 6452 o a Delivery Response Signature, or 6454 o an Authentication Response Signature. 6456 For a general explanation of signatures see section 6 Digital Signatures. 6458 7.19.1 IOTP usage of signature elements and attributes 6460 Definitions of the elements and attributes are contained in [IOTPDSIG]. 6461 The following contains additional information that describes how these 6462 elements and attributes are used by IOTP. 6464 SIGNATURE ELEMENT 6466 The ID attribute is mandatory. 6468 MANIFEST ELEMENT 6470 The optional LocatorHrefBase attribute contains text which should be 6471 concatenated before the text contained in the LocatorHREF attribute of 6472 all Digest elements within the Manifest. 6474 Its purpose is to reduce the size of LocatorHREF attribute values since 6475 the first part of the LocatorHREF attributes in the same signature are 6476 likely to be the same. 6478 Typically, within IOTP, it will contain all the characters in a 6479 LocatorHref attribute up to the sharp ("#") character (see immediately 6480 below). 6482 ALGORITHM AND PARAMETER ELEMENTS 6484 The algorithm element identifies the algorithms used in generating the 6485 signature. The type of the algorithm is defined by the value of the Type 6486 attribute which indicates if it is to be used as a Digest algorithm, a 6487 Signature algorithm or a Key Agreement algorithm. 6489 The following Digest algorithms must be implemented: 6491 o a [DOM-HASH] algorithm. This is identified by setting the Name 6492 attribute of the Algorithm element to "urn:ibm:dom-hash" 6494 o a [SHA1] algorithm. This is identified by setting the Name attribute of 6495 the Algorithm element to "urn:fips:sha1", and 6497 o a [MD5] algorithm. This is identified by setting the Name attribute of 6498 the Algorithm element to "urn:rsa:md5" 6500 o The following Signature algorithms must be implemented: 6502 o a [DSA] algorithm. This is identified by setting the Name attribute of 6503 the Algorithm element to "urn:us.gov:dsa" 6505 o a [HMAC] algorithm. This is identified by setting the Name attribute of 6506 the Algorithm element to "urn:ibm:hmac" 6508 It is recommended that the following Signature algorithm is also 6509 implemented: 6511 o a [RSA] algorithm. This is identified by setting the Name attribute of 6512 the Algorithm element to "urn:rsa:rsa" 6514 In addition other payment scheme specific algorithms may be used. In this 6515 case the value of the name attribute to use is specified in the payment 6516 scheme supplement for that algorithm. 6518 One algorithm may make use of other algorithms by use of the Parameter 6519 element, for example: 6521 6522 A2 6523 6524 6525 6526 6527 A1 6528 6530 DIGEST ELEMENT 6532 The LocatorHREF attribute identifies the IOTP element which is being 6533 digitally signed. Specifically it consists of: 6535 o the value of the IotpTransId attribute of the Transaction ID Component, 6536 followed by: 6538 o a sharp character, i.e. "#", followed by 6540 o an Element Reference (see section 3.5) to the element within the IOTP 6541 Transaction which is the subject of the digest. 6543 Before analysing the structure of the LocatorHREF attribute, it must be 6544 concatenated with the value of the LocatorHrefBase attribute of the 6545 Manifest element (see immediately above). 6547 ATTRIBUTE ELEMENT 6549 There must be one and only one Attribute Element that contains a Type 6550 attribute with a value of IOTP Signature Type and with content set to 6551 either: OfferResponse, PaymentResponse, DeliveryResponse, 6552 AuthenticationRequest, AuthenticationResponse, PingRequest or 6553 PingResponse; depending on the type of the signature. 6555 Values of the content of the Attribute element are controlled under the 6556 procedures defined in section 12 IANA Considerations which also allows 6557 user defined values to be defined. 6559 The Critical attribute must be set to true. 6561 ORIGINATORINFO ELEMENT 6563 The OriginatorRef attribute of the OriginatorInfo element must always be 6564 present and contain an Element Reference (see section 3.5) to the 6565 Organisation Component of the Organisation that generated the Signature 6566 Component. 6568 RECIPIENTINFO ELEMENT 6570 The RecipientRefs attribute contains a list of Element References (see 6571 section 3.5), that point to the Organisations that might need to validate 6572 the signature. For details see below. 6574 7.19.2 Offer Response Signature Component 6576 The Manifest Element of a signature which has a type of OfferResponse 6577 should contain Digest elements for the following Components: 6579 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6580 that contains the Offer Response Signature 6582 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6583 that contains the Offer Response Signature 6585 o from the TPO Block: 6586 - the Protocol Options Component 6587 - each of the Organisation Components 6588 - each of the Brand List Components 6590 o optionally, all the Brand Selection Components if they were sent to the 6591 Merchant in a TPO Selection Block 6593 o from the Offer Response Block: 6594 - the Order Component 6595 - each of the Payment Components 6596 - the Delivery Component 6597 - each of the Authentication Request Components 6598 - any Trading Role Data Components 6600 The Offer Response Signature should also contain Digest elements for the 6601 components that describe each of the Organisations that may or will need 6602 to verify the signature. This involves: 6604 o if the Merchant has received a TPO Selection Block containing Brand 6605 Selection Components, then generate a Digest element for the Payment 6606 Handler identified by the Brand Selection Component and the Delivery 6607 Handler identified by the Delivery Component. See section 6.3.1 Check 6608 Request Block sent Correct Organisation for a description of how this 6609 can be done. 6611 o if the Merchant is not expecting to receive a TPO Selection Block then 6612 generate a Digest element for the Delivery Handler and all the Payment 6613 Handlers that are involved. 6615 7.19.3 Payment Receipt Signature Component 6617 The Manifest Element of the Payment Receipt Signature Component should 6618 contain Digest Elements for the following Components: 6620 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6621 that contains the Payment Receipt Signature 6623 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6624 that contains the Payment Receipt Signature 6626 o the Offer Response Signature Component 6628 o the Payment Receipt Component 6630 o the Payment Note Component 6632 o the Status Component 6634 o the Brand Selection Component. 6636 o any Trading Role Data Components 6638 7.19.4 Delivery Response Signature Component 6640 The Manifest Element of the Delivery Response Signature Component should 6641 contain Digest Elements for the following Components: 6643 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6644 that contains the Delivery Response Signature 6646 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6647 that contains the Delivery Response Signature 6649 o the Consumer Delivery Data component contained in the preceding 6650 Delivery Request (if any) 6652 o the Signature Components contained in the preceding Delivery Request 6653 (if any) 6655 o the Status Component 6657 o the Delivery Note Component 6659 7.19.5 Authentication Request Signature Component 6661 The Manifest Element of the Authentication Request Signature Component 6662 should contain Digest Elements for the following Components: 6664 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6665 that contains information that describes the IOTP Message and IOTP 6666 Transaction 6668 o the Transaction Id Component (see section 3.3.1) which globally 6669 uniquely identifies the IOTP Transaction 6671 o the following components of the TPO Block : 6672 - the Protocol Options Component 6673 - the Organisation Component 6675 o the following components of the Authentication Request Block: 6676 - the Authentication Request Component(s) (if present) 6677 - the Trading Role Information Request Component (if present) 6679 7.19.6 Authentication Response Signature Component 6681 The Manifest Element of the Authentication Response Signature Component 6682 should contain Digest Elements for the following Components: 6684 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6685 that contains information that describes the IOTP Message and IOTP 6686 Transaction 6688 o the Transaction Id Component (see section 3.3.1) which globally 6689 uniquely identifies the IOTP Transaction 6691 o the following components of the Authentication Request Block: 6692 - the Authentication Request Component that was used in the 6693 Authentication (if present) 6694 - the Trading Role Information Request Component (if present) 6696 o the Organisation Components contained in the Authentication Response 6697 Block 6699 7.19.7 Inquiry Request Signature Component 6701 If the Inquiry Request is being signed (see section 9.2.1) the Manifest 6702 Element of the Inquiry Request Signature Component should contain Digest 6703 elements of the Inquiry Type Component, and if present, the Payment 6704 Scheme Component. 6706 7.19.8 Inquiry Response Signature Component 6708 If the Inquiry Response is being signed (see section 9.2.1) the Manifest 6709 Element of the Inquiry Response Signature Component should contain Digest 6710 elements of the Trading Response Block and the Status Component. 6712 7.19.9 Ping Request Signature Component 6714 If the Ping Request is being singed (see section 9.2.2), the Manifest 6715 Element of the Ping Request Signature Component should contain Digest 6716 elements for all the Organisation Components. 6718 7.19.10 Ping Response Signature Component 6720 If the Ping Response is being singed (see section 9.2.2), the Manifest 6721 Element of the Ping Response Signature Component should contain Digest 6722 elements fir all the Organisation Components. 6724 7.20 Certificate Component 6726 [Note] Definitions of the XML structures for signatures and 6727 certificates are described in the paper "Digital Signatures 6728 for the Internet Open Trading Protocol", see [IOTPDSIG]. 6730 See note at the start of section 7.19 Signature Component for 6731 more details. 6732 [Note End] 6734 A Certificate Component contains a Digital Certificate. They are used 6735 only when required, for example, when asymmetric cryptography is being 6736 used and the recipient of the signature that needs to check has not 6737 already received the Public Key. 6739 The structure of a Certificate Component is defined in [IOTPDSIG]. 6741 7.20.1 IOTP usage of signature elements and attributes 6743 Detailed definitions of the above elements and attributes are contained 6744 in [IOTPDSIG]. The following contains additional information that 6745 describes how these elements and attributes are used by IOTP. 6747 CERTIFICATE COMPONENT 6749 The ID attribute is mandatory. 6751 VALUE ELEMENT 6753 The ID attribute is mandatory. 6755 7.21 Error Component 6757 The Error Component contains information about Technical Errors (see 6758 section 4.1) in an IOTP Message which has been received by one of the 6759 Trading Roles involved in the trade. 6761 For clarity two phrases are defined which are used in the description of 6762 an Error Component: 6764 o message in error. An IOTP message which contains or causes an error of 6765 some kind 6767 o message reporting the error. An IOTP message that contains an Error 6768 Component that describes the error found in a message in error. 6770 The definition of the Error Component is as follows. 6772 6773 6782 Attributes: 6784 ID An identifier which uniquely identifies the Error 6785 Component within the IOTP Transaction. 6787 xml:lang Defines the language used by attributes or child 6788 elements within this component, unless overridden 6789 by an xml:lang attribute on a child element. See 6790 section 3.8 Identifying Languages. 6792 ErrorCode Contains an error code which indicates the nature 6793 of the error in the message in error. Valid values 6794 for the ErrorCode are given in section 7.21.2 6795 Error Codes. 6797 ErrorDesc Contains a narrative description of the error in 6798 the language defined by xml:lang. The content of 6799 this attribute is defined by the vendor/developer 6800 of the software which generated the Error 6801 Component 6803 Severity Indicates the severity of the error. Valid values 6804 are: 6805 o Warning. This indicates that although there is 6806 a message in error the IOTP Transaction can 6807 still continue. 6808 o TransientError. This indicates that the error 6809 in the message in error may be recovered if the 6810 message in error that is referred to by the 6811 ErrorLocation element is resent 6812 o HardError. This indicates that there is an 6813 unrecoverable error in the message in error and 6814 the IOTP Transaction must stop. 6816 MinRetrySecs This attribute should be present if Severity is 6817 set to TransientError. It is the minimum number of 6818 whole seconds which the IOTP aware application 6819 which received the message reporting the error 6820 should wait before re-sending the message in error 6821 identified by the ErrorLocation element. 6823 If Severity is not set to TransientError then the 6824 value of this attribute is ignored. 6826 SwVendorErrorRef This attribute is a reference whose value is set 6827 by the vendor/developer of the software which 6828 generated the Error Component. It should contain 6829 data which enables the vendor to identify the 6830 precise location in their software and the set of 6831 circumstances which caused the software to 6832 generate a message reporting the error. See also 6833 the SoftwareId attribute of the Message Id element 6834 in the Transaction Reference Block (section 3.3). 6836 Content: 6838 ErrorLocation This identifies the IOTP Transaction Id of the 6839 message in error and, where possible, the element 6840 and attribute in the message in error that caused 6841 the Error Component to be generated. 6843 If the Severity of the error is not 6844 TransientError, more than one ErrorLocation may be 6845 specified as appropriate depending on the nature 6846 of the error (see section 7.21.2 Error Codes) and 6847 at the discretion of the vendor/developer of the 6848 IOTP Aware Application. 6850 PackagedContent This contains additional data which can be used to 6851 understand the error. Its content may vary as 6852 appropriate depending on the nature of the error 6853 (see section 7.21.2 Error Codes) and at the 6854 discretion of the vendor/developer of the IOTP 6855 Aware Application. For a definition of 6856 PackagedContent see section 3.7. 6858 7.21.1 Error Processing Guidelines 6860 If there is more than one Error Component in a message reporting the 6861 error, carry out the actions appropriate for the Error Component with the 6862 highest severity. In this context, HardError has a higher severity than 6863 TransientError, which has a higher severity than Warning. 6865 7.21.1.1 Severity - Warning 6867 If an IOTP aware application is generating a message reporting the error 6868 with an Error Component where the Severity attribute is set to Warning, 6869 then if the message reporting the error does not contain another Error 6870 Component with a severity higher than Warning, the IOTP Message must also 6871 include the Trading Blocks and Trading Components that would have been 6872 included if no error was being reported. 6874 If a message reporting the error is received with an Error Component 6875 where Severity is set to Warning, then: 6877 o it is recommended that information about the error is either logged, or 6878 otherwise reported to the user, 6880 o the implementer of the IOTP aware application must either, at their or 6881 the user's discretion: 6882 - continue the IOTP transaction as normal, or 6883 - fail the IOTP transaction by generating a message reporting the error 6884 with an Error Component with Severity set to HardError (see section 6885 7.21.1.3). 6887 If the intention is to continue the IOTP transaction then, if there are 6888 no other Error Components with a higher severity, check that the 6889 necessary Trading Blocks and Trading Components for normal processing of 6890 the transaction to continue are present. If they are not then generate a 6891 message reporting the error with an Error Component with Severity set to 6892 HardError. 6894 7.21.1.2 Severity - Transient Error 6896 If an IOTP Aware Application is generating a message reporting the error 6897 with an Error Component where the Severity attribute is set to 6898 TransientError, then there should be only one Error Component in the 6899 message reporting the error. In addition, the MinRetrySecs attribute 6900 should be present. 6902 If a message reporting the error is received with an Error Component 6903 where Severity is set to TransientError then: 6905 o if the MinRetrySecs attribute is present and a valid number, then use 6906 the MinRetrySecs value given. Otherwise if MinRetrySecs is missing or 6907 is invalid, then: 6908 - generate a message reporting the error containing an Error Component 6909 with a Severity of Warning and send it on the next IOTP message (if 6910 any) to be sent to the Trading Role which sent the message reporting 6911 the error with the invalid MinRetrySecs, and 6912 - use a value for MinRetrySecs which is set by the vendor/developer of 6913 the IOTP Aware Application. 6915 o check that only one ErrorLocation element is contained within the Error 6916 Component and that it refers to an IOTP Message which was sent by the 6917 recipient of the Error Component with a Severity of TransientError. If 6918 more than one ErrorLocation is present then generate a message 6919 reporting the error with a Severity of HardError. 6921 7.21.1.3 Severity - Hard Error 6923 If an IOTP Aware Application is generating a message reporting the error 6924 with an Error Component where the Severity attribute set to HardError, 6925 then there should be only one Error Component in the message reporting 6926 the error. 6928 If a message reporting the error is received with an Error Component 6929 where Severity is set to HardError then terminate the IOTP Transaction. 6931 7.21.2 Error Codes 6933 The following table contains the valid values for the ErrorCode attribute 6934 of the Error Component. The first sentence of the description contains 6935 the text that should be used to describe the error when displayed or 6936 otherwise reported. Individual implementations may translate this into 6937 alternative languages at their discretion. 6939 An Error Code must not be more that 14 characters long. 6941 Value Description 6943 Reserved Reserved. This error is reserved by the 6944 vendor/developer of the software. Contact the 6945 vendor/developer of the software for more information 6947 Value Description 6948 See the SoftwareId attribute of the Message Id 6949 element in the Transaction Reference Block(section 6950 3.3). 6952 XmlNotWellFrmd XML not well formed. The XML document is not well 6953 formed. See [XML] for the meaning of "well formed". 6954 Even if the XML is not well formed, it should still 6955 be scanned to find the Transaction Reference Block so 6956 that a properly formed Error Response may be 6957 generated. 6959 XmlNotValid XML not valid. The XML document is well formed but 6960 the document is not valid. See [XML] for the meaning 6961 of "valid". Specifically: 6962 o the XML document does not comply with the 6963 constraints defined in the IOTP document type 6964 declaration (DTD) (see section 13 Internet Open 6965 Trading Protocol Data Type Definition), and 6966 o the XML document does not comply with the 6967 constraints defined in the document type 6968 declaration of any additional [XML Namespace] that 6969 are declared. 6971 As for XML not well formed, attempts should still be 6972 made to extract the Transaction Reference Block so 6973 that a properly formed Error Response may be 6974 generated. 6976 ElUnexpected Unexpected element. Although the XML document is well 6977 formed and valid, an element is present that is not 6978 expected in the particular context according to the 6979 rules and constraints contained in this 6980 specification. 6982 ElNotSupp Element not supported. Although the document is well 6983 formed and valid, an element is present that: 6984 o is consistent with the rules and constraints 6985 contained in this specification, but 6986 o is not supported by the IOTP Aware Application 6987 which is processing the IOTP Message. 6989 ElMissing Element missing. Although the document is well formed 6990 and valid, an element is missing that should have 6991 been present if the rules and constraints contained 6992 in this specification are followed. 6994 In this case set the PackagedContent of the Error 6995 Component to the type of the missing element. 6997 ElContIllegal Element content illegal. Although the document is 6998 well formed and valid, the element Content contains 6999 values which do not conform to the rules and 7001 Value Description 7002 constraints contained in this specification. 7004 EncapProtErr Encapsulated protocol error. Although the document is 7005 well formed and valid, the PackagedContent of an 7006 element contains data from an encapsulated protocol 7007 which contains errors. 7009 AttUnexpected Unexpected attribute. Although the XML document is 7010 well formed and valid, the presence of the attribute 7011 is not expected in the particular context according 7012 to the rules and constraints contained in this 7013 specification. 7015 AttNotSupp Attribute not supported. Although the XML document is 7016 well formed and valid, and the presence of the 7017 attribute in an element is consistent with the rules 7018 and constraints contained in this specification, it 7019 is not supported by the IOTP Aware Application which 7020 is processing the IOTP Message. 7022 AttMissing Attribute missing. Although the document is well 7023 formed and valid, an attribute is missing that should 7024 have been present if the rules and constraints 7025 contained in this specification are followed. 7027 In this case set the PackagedContent of the Error 7028 Component to the type of the missing attribute. 7030 AttValIllegal Attribute value illegal. The attribute contains a 7031 value which does not conform to the rules and 7032 constraints contained in this specification. 7034 AttValNotRecog Attribute Value Not Recognised. The attribute 7035 contains a value which the IOTP Aware Application 7036 generating the message reporting the error could not 7037 recognise. 7039 MsgTooLarge Message too large. The message is too large to be 7040 processed by the IOTP Aware Application. 7042 ElTooLarge Element too large. The element is too large to be 7043 processed by the IOTP Aware Application 7045 ValueTooSmall Value too small or early. The value of all or part of 7046 the Content of an element or an attribute, although 7047 valid, is too small. 7049 ValueTooLarge Value too large or in the future. The value of all or 7050 part of the Content of an element or an attribute, 7051 although valid, is too large. 7053 ElInconsistent Element Inconsistent. Although the document is well 7054 Value Description 7055 formed and valid, according to the rules and 7056 constraints contained in this specification: 7057 o the content of an element is inconsistent with the 7058 content of other elements or their attributes, or 7059 o the value of an attribute is inconsistent with the 7060 value of one or more other attributes. 7062 In this case create ErrorLocation elements which 7063 identify all the attributes or elements which are 7064 inconsistent. 7066 TransportError Transport Error. This error code is used to indicate 7067 that there is a problem with the Transport Mechanism 7068 which is preventing the message from being received. 7069 It is typically associated with a Transient Error. 7070 Explanation of the Transport Error is contained 7071 within the ErrorDesc attribute. The values which can 7072 be used inside ErrorDesc with a TransportError is 7073 specified in the IOTP supplement for the Transport 7074 mechanism. 7076 MsgBeingProc Message Being Processed. This error code is only used 7077 with a Severity of Transient Error. It indicates that 7078 the previous message, which may be an exchange 7079 message or a request message, is being processed and, 7080 if no response is received by the time indicated by 7081 the MinRetrySecs attribute, then the original message 7082 should be resent. 7084 SystemBusy System Busy. This error code is only used with a 7085 Severity of Transient Error. It indicates that the 7086 server that received a message is currently too busy 7087 to handle the message. If no response is received by 7088 the time indicated by the MinRetrySecs attribute, 7089 then the original message should be resent. 7091 [Note] If the server/system handling the 7092 Transport Mechanism (e.g. HTTP) is busy 7093 then a Transport Specific error message 7094 should be used instead of an IOTP Error 7095 message. This code should be used in 7096 association with IOTP servers/systems or 7097 other servers/systems to which the IOTP 7098 server is connected. 7099 [Note End] 7101 UnknownError Unknown Error. Indicates that the transaction cannot 7102 complete for some reason that is not covered 7103 explicitly by any of the other errors. The ErrorDesc 7104 attribute should be used to indicate the nature of 7105 the problem. 7107 Value Description 7109 This could be used to indicate, for example, an 7110 internal error in a backend server or client process 7111 of some kind. 7113 7.21.3 Error Location Element 7115 An Error Location Element identifies an element and optionally an 7116 attribute in the message in error which is associated with the error. It 7117 contains a reference to the IOTP Message, Trading Block, Trading 7118 Component, element and attribute, which is in error. 7120 7121 7129 Attributes: 7131 ElementType This is the name of the type of the element where 7132 the error is located. For example if the element 7133 was declared as |-Trading Block <--------Trading Block - an XML Element 7206 | | |-Trading Comp. within an IOTP Message that 7207 Trading | |-Trading Comp. contains a predefined set of 7208 Blocks | |-Trading Comp. Trading Components 7209 | | |-Trading Comp. 7210 | | |-Trading Comp. <-----Trading Components - XML Elements 7211 | | within a Trading Block that 7212 ------> |-Trading Block contain a predefined set of XML 7213 | |-Trading Comp. elements and attributes 7214 | |-Trading Comp. containing information required 7215 | |-Trading Comp. to support a Trading Exchange 7216 | |-Trading Comp. 7217 | |-Trading Comp. 7218 | 7219 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 7220 Figure 16 Trading Blocks 7222 Trading Blocks are defined as part of the definition of an IOTP Message 7223 (see section 3.1.1). The definition of an IOTP Message element is 7224 repeated here: 7226 7249 The remainder of this section defines the Trading Blocks in this version 7250 of IOTP. They are: 7252 o Authentication Request Block 7254 o Authentication Response Block 7256 o Authentication Status Block 7258 o Cancel Block 7260 o Delivery Request Block 7262 o Delivery Response Block 7264 o Error Block 7266 o Inquiry Request Block 7268 o Inquiry Response Block 7270 o Offer Response Block 7272 o Payment Exchange Block 7273 o Payment Request Block 7275 o Payment Response Block 7277 o Signature Block 7279 o Trading Protocol Options Block 7281 o TPO Selection Block 7283 The Transaction Reference Block is described in section 3.3. 7285 8.1 Trading Protocol Options Block 7287 The TPO Trading Block contains options which apply to the IOTP 7288 Transaction. The definition of a TPO Trading Block is as follows. 7290 7291 7294 Attributes: 7296 ID An identifier which uniquely identifies the 7297 Trading Protocol Options Block within the IOTP 7298 Transaction (see section 3.4 ID Attributes). 7300 Content: 7302 ProtocolOptions The Protocol Options Component (see section 7303 7.1)defines the options which apply to the whole 7304 IOTP Transaction (see section 9). 7306 BrandList This Brand List Component contains one or more 7307 payment brands and protocols which may be selected 7308 (see section 7.7). 7310 Org The Organisation Components (see section 7.6) 7311 identify the Organisations and their roles in the 7312 IOTP Transaction. The roles and Organisations 7313 which must be present will depend on the 7314 particular type of IOTP Transaction. See the 7315 definition of each transaction in section 9. 7316 Internet Open Trading Protocol Transactions. 7318 The TPO Block should contain: 7320 o the Protocol Options Component 7322 o the Organisation Component with the Trading Role of Merchant 7324 o the Organisation Component with the Trading Role of Consumer 7325 o optionally, the Organisation Component with the Trading Role of 7326 DeliverTo, if there is a Delivery included in the IOTP Transaction 7328 o Brand List Components for each payment in the IOTP Transaction 7330 o Organisation Components for all the Payment Handlers involved 7332 o optionally, Organisation Components for the Delivery Handler (if any) 7333 for the transaction 7335 o additional Organisation Components that the Merchant may want to 7336 include. For example 7337 - a Customer Care Provider 7338 - an Certificate Authority that offers Merchant "Credentials" or some 7339 other warranty on the goods or services being offered. 7341 8.2 TPO Selection Block 7343 The TPO Selection Block contains the results of selections made from the 7344 options contained in the Trading Protocol Options Block (see section 7345 8.1).The definition of a TPO Selection Block is as follows. 7347 7348 7351 Attributes: 7353 ID An identifier which uniquely identifies the TPO 7354 Selection Block within the IOTP Transaction. 7356 Content: 7358 BrandSelection This identifies the choice of payment brand and 7359 payment protocol to be used in a payment within 7360 the IOTP Transaction. There is one Brand Selection 7361 Component (see section 7.8) for each payment to be 7362 made in the IOTP Transaction. 7364 The TPO Selection Block should contain one Brand Selection Component for 7365 each Brand List in the TPO Block. 7367 8.3 Offer Response Block 7369 The Offer Response Block contains details of the goods, services, amount, 7370 delivery instructions or financial transaction which is to take place. 7371 Its definition is as follows. 7373 7376 7379 Attributes: 7381 ID An identifier which uniquely identifies the Offer 7382 Response Block within the IOTP Transaction. 7384 Content: 7386 Status Contains status information about the business 7387 success (see section 4.2) or failure of the 7388 generation of the Offer. Note that in an Offer 7389 Response Block, a ProcessState of NotYetStarted or 7390 InProgress are illegal values. 7392 Order The Order Component contains details about the 7393 goods, services or financial transaction which is 7394 taking place see section 7.5. 7396 The Order Component must be present unless the 7397 ProcessState attribute of the Status Component is 7398 set to Failed. 7400 Payment The Payment Components contain information about 7401 the payments which are to be made see section 7.9. 7403 Delivery The Delivery Component contains details of the 7404 delivery to be made (see section 7.13). 7406 TradingRoleData The Trading Role Data Component contains opaque 7407 data which is needs to be communicated between the 7408 Trading Roles involved in an IOTP Transaction (see 7409 section 7.17). 7411 The Offer Response Block should contain: 7413 o the Order Component for the IOTP Transaction 7415 o Payment Components for each Payment in the IOTP Transaction 7417 o the Delivery Component the IOTP Transaction requires (if any). 7419 8.4 Authentication Request Block 7421 The Authentication Request Block contains the data which is used by one 7422 Trading Role to obtain information about and optionally authenticate 7423 another Trading Role. 7425 In outline it contains: 7427 o information about how the authentication itself will be carried out, 7428 and/or 7430 o a request for additional information about the Organisation being 7431 authenticated. 7433 Its definition is as follows. 7435 7436 7439 Attributes: 7441 ID An identifier which uniquely identifies the 7442 Authentication Request Block within the IOTP 7443 Transaction. 7445 Content: 7447 AuthReq Each Authentication Request (see section 7.2) 7448 component describes an alternative way in which 7449 the recipient of the Authentication Request may 7450 authenticate themselves by generating an 7451 Authentication Response Component (see section 7452 7.3). 7454 If one Authentication Request Component is 7455 present then that Authentication Request 7456 Component should be used. 7458 If more than one Authentication Request Component 7459 is present then the recipient should choose one 7460 of the components based on personal preference of 7461 the recipient or their software. 7463 If no Authentication Request Component is present 7464 it means that the Authentication Request Block is 7465 requesting the return of Organisation Components 7466 as specified in the Trading Role Information 7467 Request Component. 7469 TradingRoleInfoReq The Trading Role Information Request Component 7470 (see section 7.4) contains a list of Trading 7471 Roles about which information is being requested 7473 There must be at least one Component (either an Authentication Request or 7474 a Trading Role Information Request) within the Authentication Block 7475 otherwise it is an error. 7477 8.5 Authentication Response Block 7479 The Authentication Response Block contains the response which results 7480 from processing the Authentication Request Block. Its definition is as 7481 follows. 7483 7484 7487 Attributes: 7489 ID An identifier which uniquely identifies the 7490 Authentication Response Block within the IOTP 7491 Transaction. 7493 Content: 7495 AuthResp The optional Authentication Response Component 7496 which contains the results of processing the 7497 Authentication Request Component - see section 7498 7.3. 7500 Org Optional Organisation Components that contain 7501 information corresponding to the Trading Roles as 7502 requested by the TradingRoleList attribute of the 7503 Trading Role Information Request component. 7505 The components present in the Authentication Response Block must match 7506 the requirement of the corresponding Authentication Request Block 7507 otherwise it is an error. 7509 8.6 Authentication Status Block 7511 The Authentication Status Block indicates the success or failure of the 7512 validation of an Authentication Response Block by an Authenticator. Its 7513 definition is as follows. 7515 7516 7519 Attributes: 7521 ID An identifier which uniquely identifies the 7522 Authentication Status Block within the IOTP 7523 Transaction. 7525 Content: 7527 Status Contains status information about the business 7528 success (see section 4.2) or failure of the 7529 authentication 7531 8.7 Payment Request Block 7533 The Payment Request Block contains information which requests that a 7534 payment is started. Its definition is as follows. 7536 7538 7541 Attributes: 7543 ID An identifier which uniquely identifies the 7544 Payment Request Block within the IOTP Transaction. 7546 Content: 7548 Status Contains the Status Components (see section 7.13) 7549 of the responses of the steps (e.g. an Offer 7550 Response and/or a Payment Response) on which this 7551 step depends. It is used to indicate the success 7552 or failure of those steps. Payment should only 7553 occur if the previous steps were successful. 7555 BrandList The Brand List Component contains a list of one or 7556 more payment brands and protocols which may be 7557 selected (see section 7.7). 7559 BrandSelection This identifies the choice of payment brand, the 7560 payment protocol and the Payment Handler to be 7561 used in a payment within the IOTP Transaction. 7562 There is one Brand Selection Component (see 7563 section 7.8) for each payment to be made in the 7564 IOTP Transaction. 7566 Payment The Payment Components contain information about 7567 the payment which is being made see section 7.9. 7569 PaySchemeData The Payment Scheme Component contains payment 7570 scheme specific data see section 7.10. 7572 Org The Organisation Component contains details of 7573 Organisations involved in the payment (see section 7574 7.6). The Organisations present are dependent on 7575 the IOTP Transaction and the data which is to be 7576 signed. See section 6 Digital Signatures for more 7577 details. 7579 TradingRoleData The Trading Role Data Component contains opaque 7580 data which is needs to be communicated between the 7581 Trading Roles involved in an IOTP Transaction (see 7582 section 7.17). 7584 The Payment Request Block should contain: 7586 o the Organisation Component with a Trading Role of Merchant 7588 o the Organisation Component with the Trading Role of Consumer 7590 o the Payment Component for the Payment 7592 o the Brand List Component for the Payment 7594 o the Brand Selection Component for the Brand List 7596 o the Organisation Component for the Payment Handler of the Payment 7598 o the Organisation Component (if any) for the Organisation which carried 7599 out the previous step, for example another Payment Handler 7601 o the Organisation Component for the Organisation which is to carry out 7602 the next step, if any. This may be, for example, either a Delivery 7603 Handler or a Payment Handler. 7605 o the Organisation Components for any additional Organisations that the 7606 Merchant has included in the Offer Response Block 7608 o an Optional Payment Scheme Data Component, if required by the Payment 7609 Method as defined in the IOTP supplement for the payment method 7611 o any Trading Role Data Components that may be required (see section 7612 7.17.1). 7614 8.8 Payment Exchange Block 7616 The Payment Exchange Block contains payment scheme specific data which is 7617 exchanged between two of the roles in a trade. Its definition is as 7618 follows. 7620 7621 7624 Attributes: 7626 ID An identifier which uniquely identifies the 7627 Payment Exchange Block within the IOTP 7628 Transaction. 7630 Content: 7632 PaySchemeData This Trading Component contains payment scheme 7633 specific data see section 7.10 Payment Scheme 7634 Component. 7636 8.9 Payment Response Block 7638 This Payment Response Block contains a information about the Payment 7639 Status, an optional Payment Receipt, and an optional payment protocol 7640 message. Its definition is as follows. 7642 7644 7647 Attributes: 7649 ID An identifier which uniquely identifies the 7650 Payment Response Block within the IOTP 7651 Transaction. 7653 Content: 7655 Status Contains status information about the business 7656 success (see section 4.2) or failure of the 7657 payment. Note that in a Pay Response Block, a 7658 ProcessState of NotYetStarted or InProgress are 7659 illegal values. 7661 PayReceipt Contains payment scheme specific data which can be 7662 used to verify the payment occurred. See section 7663 7.11 Payment Receipt Component. It must be present 7664 if the ProcessState attribute of the Status 7665 Component is set to CompletedOk. PayReceipt is 7666 optional for other values as specified by the 7667 appropriate Payment Scheme supplement. 7669 PaySchemeData Contains payment scheme specific data see section, 7670 for example a payment protocol message. See 7.10 7671 Payment Scheme Component. 7673 PaymentNote Contains additional, non payment related, 7674 information which the Payment Handler wants to 7675 provide to the Consumer. For example, if a 7676 withdrawal or deposit were being made then it 7677 could contain information on the remaining balance 7678 on the account after the transfer was complete. 7679 See section 7.12 Payment Note Component. 7681 TradingRoleData The Trading Role Data Component contains opaque 7682 data which is needs to be communicated between the 7683 Trading Roles involved in an IOTP Transaction (see 7684 section 7.17). 7686 8.10 Delivery Request Block 7688 The Delivery Request Block contains details of the goods or services 7689 which are to be delivered together with a signature which can be used to 7690 check that delivery is authorised. Its definition is as follows. 7692 7694 7697 Attributes: 7699 ID An identifier which uniquely identifies the 7700 Delivery Request Block within the IOTP 7701 Transaction. 7703 Content: 7705 Status Contains the Status Components (see section 7706 7.13) of the responses of the steps (e.g. a 7707 Payment Response) on which this step is 7708 dependent. It is used to indicate the success 7709 or failure of those steps. Delivery should only 7710 occur if the previous steps were successful. 7712 Order The Order Component contains details about the 7713 goods, services or financial transaction which 7714 is taking place see section 7.5. 7716 The Organisation Components (see section 7.6) 7717 identify the Organisations and their roles in 7718 Org the IOTP Transaction. The roles and 7719 Organisations which must be present will depend 7720 on the particular type of IOTP Transaction. See 7721 the definition of each transaction in section 7722 9. Internet Open Trading Protocol Transactions. 7724 Delivery The Delivery Component contains details of the 7725 delivery to be made (see section 7.13). 7727 ConsumerDeliveryData Optional. Contains an identifier specified by 7728 the Consumer which, if returned by the Delivery 7729 Handler will enable the Consumer to identify 7730 which Delivery is being referred to. 7732 TradingRoleData The Trading Role Data Component contains opaque 7733 data which is needs to be communicated between 7734 the Trading Roles involved in an IOTP 7735 Transaction (see section 7.17). 7737 The Delivery Request Block contains: 7739 o the Organisation Component with a Trading Role of Merchant 7740 o the Organisation Component for the Consumer and DeliverTo Trading Roles 7742 o the Delivery Component for the Delivery 7744 o the Organisation Component for the Delivery Handler. Specifically the 7745 Organisation Component identified by the ActionOrgRef attribute on the 7746 Delivery Component 7748 o the Organisation Component (if any) for the Organisation which carried 7749 out the previous step, for example a Payment Handler 7751 o the Organisation Components for any additional Organisations that the 7752 Merchant has included in the Offer Response Block 7754 o any Trading Role Data Components that may be required (see section 7755 7.17.1). 7757 8.11 Delivery Response Block 7759 The Delivery Response Block contains a Delivery Note containing details 7760 on how the goods will be delivered. Its definition is as follows. Note 7761 that in a Delivery Response Block a Delivery Status Element with a 7762 DeliveryStatusCode of NotYetStarted or InProgress is invalid. 7764 7765 7768 Attributes: 7770 ID An identifier which uniquely identifies the 7771 Delivery Response Block within the IOTP 7772 Transaction. 7774 Content: 7776 Status Contains status information about the business 7777 success (see section 4.2) or failure of the 7778 delivery. Note that in a Delivery Response Block, 7779 a ProcessState of NotYetStarted or InProgress are 7780 illegal values. 7782 DeliveryNote The Delivery Note Component contains details about 7783 how the goods or services will be delivered (see 7784 section 7.15). 7786 8.12 Inquiry Request Trading Block 7788 The Inquiry Request Trading Block contains an Inquiry Type Component and 7789 an optional Payment Scheme Component to contain payment scheme specific 7790 inquiry messages. 7792 7793 7796 Attributes: 7798 ID An identifier which uniquely identifies the 7799 Inquiry Request Trading Block within the IOTP 7800 Transaction. 7802 Content: 7804 InquiryType Inquiry Type Component (see section 7.18) that 7805 contains the type of inquiry. 7807 PaySchemeData Payment Scheme Component (see section 7.10) that 7808 contains payment scheme specific inquiry messages 7809 for inquiries on payments. This is present when 7810 the Type attribute of Inquiry Type Component is 7811 Payment. 7813 8.13 Inquiry Response Trading Block 7815 The Inquiry Response Trading Block contains a Status Component and an 7816 optional Payment Scheme Component to contain payment scheme specific 7817 inquiry messages. Its purpose is to enquire on the current status of an 7818 IOTP transaction at a server. 7820 7821 7826 Attributes: 7828 ID An identifier which uniquely identifies the 7829 Inquiry Response Trading Block within the 7830 IOTP Transaction. 7832 LastReceivedIotpMsgRef Contains an Element Reference (see section 7833 3.5) to the Message Id Component (see section 7834 3.3.2) of the last message this server has 7835 received from the Consumer. If there is no 7836 previously received message from the Consumer 7837 in the pertinent transaction, this attribute 7838 should be contain the value Null. This 7839 attribute exists for debugging purposes. 7841 LastSentIotpMsgRef Contains an Element Reference (see section 7842 3.5) to the Message Id Component (see section 7843 3.3.2) of the last message this server has 7844 sent to the Consumer. If there is no 7845 previously sent message to the Consumer in 7846 the pertinent transaction, this attribute 7847 should contain the value Null. This attribute 7848 exists for debugging purposes. 7850 Content: 7852 Status Contains status information about the business 7853 success (see section 4.2) or failure of a certain 7854 trading exchange (i.e., Offer, Payment, or 7855 Delivery). 7857 PaySchemeData Payment Scheme Component (see section 7.10) that 7858 contains payment scheme specific inquiry messages 7859 for inquiries on payments. This is present when 7860 the Type attribute of StatusType attribute of the 7861 Status Component is set to Payment. 7863 8.14 Ping Request Block 7865 The Ping Request Block is used to determine if a Server is operating and 7866 whether or not cryptography is compatible. 7868 The definition of a Ping Request Block is as follows. 7870 7871 7874 Attributes: 7876 ID An identifier which uniquely identifies the Ping 7877 Request Trading Block within the IOTP Transaction. 7879 Content: 7881 Org Optional Organisation Components (see section 7882 7.6). 7884 If no Organisation Component is present then the 7885 Ping Request is anonymous and simply determines if 7886 the server is operating. 7888 However if Organisation Components are present, 7889 then it indicates that the sender of the Ping 7890 Request wants to verify that digital signatures 7891 can be handled. 7893 In this case the sender includes: 7894 o an Organisation Component that identifies 7895 itself specifying the Trading Role(s) it is 7896 taking in IOTP transactions (Merchant, Payment 7897 Handler, etc) 7898 o an Organisation Component that identifies the 7899 intended recipient of the message. 7901 These are then used to generate a signature over 7902 the Ping Response Block. 7904 8.15 Ping Response Block 7906 The Ping Response Trading Block provides the result of a Ping Request. 7908 It contains an Organisation Component that identifies the sender of the 7909 Ping Response. 7911 If the Ping Request to which this block is a response contained 7912 Organisation Components, then it also contains those Organisation 7913 Components. 7915 7916 7923 Attributes: 7925 ID An identifier which uniquely identifies the Ping 7926 Request Trading Block within the IOTP 7927 Transaction. 7929 PingStatusCode Contains a code which shows the status of the 7930 sender software which processes IOTP messages. 7931 Valid values are: 7932 o Ok. Everything with the service is working 7933 normally, including the signature 7934 verification. 7935 o Busy. Things are working normally but there 7936 may be some delays. 7937 o Down. The server is not functioning fully but 7938 can still provide a Ping response. 7940 SigVerifyStatusCode Contains a code which shows the status of 7941 signature verification. This is present only 7942 when the message containing the Ping Request 7943 Block also contains a Signature Block. Valid 7944 values are: 7945 o Ok. The signature has successfully been 7946 verified and proved compatible. 7947 o NotSupported The receiver of this Ping 7948 Request Block does not support validation of 7949 signatures. 7950 o Fail. Signature verification failed. 7952 Xml:lang Defines the language used in PingStatusDesc. 7953 This is present when PingStatusDesc is present. 7955 PingStatusDesc Contains a short description of the status of 7956 the server which sends this Ping Response Block. 7957 Servers, if their designers want, can use this 7958 attribute to send more refined status 7959 information than PingStatusCode which can be 7960 used for debugging purposes, for example. 7962 Content: 7964 Org These are Organisation Components (see section 7965 7.6). 7967 The Organisation Components of the sender of the 7968 Ping Response is always included in addition to 7969 the Organisation Components sent in the Ping 7970 Request. 7972 [Note] Ping Status Code values do not include a value such as Fail, 7973 since, when the software receiving the Ping Request message is 7974 not working at all, no Ping Response message will be sent 7975 back. 7976 [Note End] 7978 8.16 Signature Block 7980 The Signature Block contains one or more Signature Components and 7981 associated Certificates (if required) which sign data associated with the 7982 IOTP Transaction. For a general discussion and introduction to how IOTP 7983 uses signatures, see section 6 Digital Signatures. The definition of the 7984 Signature Component and certificates is contained in the paper "Digital 7985 Signatures for the Internet Open Trading Protocol", see [IOTPDSIG]. 7986 Descriptions of how these are used by IOTP is contained in sections 7.19 7987 and 7.20. 7989 The definition of a Signature Block is as follows: 7991 7992 7995 Attributes: 7997 ID An identifier which uniquely identifies the 7998 Signature Block within the IOTP Transaction. 8000 Content: 8002 Signature A Signature Component. See section 7.19. 8004 Certificate A Certificate Component. See section 7.20. 8006 The contents of a Signature Block depends on the Trading Block that is 8007 contained in the same IOTP Message as the Signature Block. 8009 8.16.1 Signature Block with Offer Response 8011 A Signature Block which is in the same message as an Offer Response Block 8012 contains just an Offer Response Signature Component (see section 7.19.2). 8014 8.16.2 Signature Block with Payment Request 8016 A Signature Block which is in the same message as a Payment Request Block 8017 contains: 8019 o an Offer Response Signature Component (see section 7.19.2), and 8021 o if the Payment is dependent on an earlier step (as indicated by the 8022 StartAfter attribute on the Payment Component), then the Payment 8023 Receipt Signature Component (see section 7.19.3) generated by the 8024 previous step 8026 8.16.3 Signature Block with Payment Response 8028 A Signature Block which is in the same message as a Payment Response 8029 Block contains just a Payment Receipt Signature Component (see section 8030 7.19.3) generated by the step. 8032 8.16.4 Signature Block with Delivery Request 8034 A Signature Block which is in the same message as a Delivery Request 8035 Block contains: 8037 o an Offer Response Signature Component (see section 7.19.2), and 8039 o the Payment Receipt Signature Component (see section 7.19.3) generated 8040 by the previous step. 8042 8.16.5 Signature Block with Delivery Response 8044 A Signature Block which is in the same message as a Delivery Response 8045 Block contains just a Delivery Response Signature component (see section 8046 7.19.4) generated by the step. 8048 8.17 Error Block 8050 The Error Trading Block contains one or more Error Components (see 8051 section 7.21) which contain information about Technical Errors (see 8052 section 4.1) in an IOTP Message which has been received by one of the 8053 Trading Roles involved in the trade. 8055 For clarity two phrases are defined which are used in the description of 8056 an Error Trading Block: 8058 o message in error. An IOTP message which contains or causes an error of 8059 some kind 8061 o message reporting the error. An IOTP message that contains an Error 8062 Trading Block that describes the error found in a message in error. 8064 An Error Trading Block may be contained in any message reporting the 8065 error. The action which then follows depends on the severity of the 8066 error. See the definition of an Error Component, for an explanation of 8067 the different types of severity and the actions which can then occur. 8069 [Note] Although, an Error Trading Block can report multiple different 8070 errors using multiple Error Components, there is no obligation 8071 on a developer of an IOTP Aware Application to do so. 8072 [Note End] 8074 The structure of an Error Trading Block is as follows. 8076 8077 8080 Attributes: 8082 ID An identifier which uniquely identifies the Error 8083 Trading Block within the IOTP Transaction. 8085 Content: 8087 ErrorComp An Error Components (see section 7.21) that 8088 contains information about an individual Technical 8089 Error. 8091 PaySchemeData An optional Payment Scheme Component (see section 8092 7.10) which contains a Payment Scheme Message. See 8093 the appropriate payment scheme supplement to 8094 determine whether or not this component needs to 8095 be present and for the definition of what it must 8096 contain. 8098 8.18 Cancel Block 8100 The Cancel Block is used by one Trading Role to inform any other that a 8101 transaction has been cancelled. Example usage includes: 8103 o a Consumer Role informing a non-Consumer role that it no longer plans 8104 to continue with the transaction. This will allow the server to close 8105 down the transaction tidily without a waiting for a time-out to occur 8107 o a non-Consumer Role to inform a Consumer role that the Transaction is 8108 being stopped. In this case, the Consumer is then unlikely to re-send 8109 the previous message that was sent in the mistaken understanding that 8110 the original was not received. 8112 Its definition is as follows. 8114 8115 8118 Attributes: 8120 ID An identifier which uniquely identifies the Cancel 8121 Block within the IOTP Transaction. 8123 Content: 8125 Status Contains status information indicating that the 8126 IOTP transaction has been cancelled. 8128 9. Internet Open Trading Protocol Transactions 8130 The Baseline Internet Open Trading Protocol supports three types of 8131 transactions for different purposes. These are 8133 o an Authentication IOTP transaction which supports authentication of one 8134 party in a trade by another and/or requests information about another 8135 Trading Role 8137 o IOTP Transactions that involve one or more payments. Specifically: 8138 - Deposit 8139 - Purchase 8140 - Refund 8141 - Withdrawal, and 8142 - Value Exchange 8144 o IOTP Transactions designed to check the correct function of the IOTP 8145 infrastructure. Specifically: 8146 - Transaction Status Inquiry, and 8147 - Ping 8149 Although the Authentication IOTP Transaction can operate on its own, 8150 authentication can optionally precede any of the "payment" transactions. 8151 Therefore, the rest of this section is divided into two parts covering: 8153 o Authentication and Payment transactions (Authentication, Deposit, 8154 Purchase, Refund, Withdrawal and Value Exchange) 8156 o Infrastructure Transactions (Transaction Status Inquiry and Ping) that 8157 are designed to support inquiries on whether or not a transaction has 8158 succeeded or a Trading Role's servers are operating correctly, and 8160 9.1 Authentication and Payment Related IOTP Transactions 8162 The Authentication and Payment related IOTP Transactions consist of six 8163 Document Exchanges which are then combined in sequence to implement a 8164 specific transaction. 8166 Generally, there is a close, but not exact, correspondence between a 8167 Document Exchange and a Trading Exchange. The main difference is that 8168 some Document Exchanges implement part or all of two Trading Exchanges 8169 simultaneously in order to minimise the number of actual IOTP Messages 8170 which must be sent over the Internet. 8172 The six Document Exchanges are: 8174 o Authentication. This is a direct implementation of the Authentication 8175 Trading Exchange 8177 o Brand Dependent Offer. This is the Offer Trading Exchange combined with 8178 the Brand Selection part of the Payment Trading Exchange. Its purpose 8179 is to provide the Merchant with information on the Brand selected so 8180 that the content of the Offer Response may be adapted accordingly 8182 o Brand Independent Offer. This is also an Offer Trading Exchange. 8183 However, in this instance, the content of the Offer Response does not 8184 depend on the Brand selected. 8186 o Payment. This is a direct implementation of the Payment part of a 8187 Payment Trading Exchange 8189 o Delivery. This is a direct implementation of the Delivery Exchange 8191 o Delivery with Payment. This is an implementation of combined Payment 8192 and Delivery Trading Exchanges 8194 These Document Exchanges are combined together in different sequences to 8195 implement each IOTP Transaction. The way in which they may be combined is 8196 illustrated by the diagram below. 8197 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8199 START ----------------------------------------------------- 8200 | v 8201 | ---------------- 8202 | | AUTHENTICATION | 8203 | ---------------- 8204 -------------------------------------- | | 8205 | | | | 8206 | -------------- | ------------- | 8207 v v v v | 8208 ------------------- ----------------- | 8209 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 8210 | OFFER | | OFFER | | 8211 ------------------- ----------------- | 8212 | | | | | 8213 | --------------- | | | 8214 | | | | | 8215 | -------------- | -- | | 8216 v v v v | 8217 --------- -------------- | 8218 | PAYMENT | | PAYMENT WITH | | 8219 | (first) | | DELIVERY | | 8220 --------- -------------- | 8221 | | | 8222 ----------------------------- | | 8223 v v | | | 8224 ---------- --------- | | | 8225 | DELIVERY | | PAYMENT | | | | 8226 | | | {second)| | | | 8227 ---------- --------- | | | 8228 | | | | v 8229 ----------------------------------------------> STOP 8231 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8233 Figure 17 Payment and Authentication Message Flow Combinations 8235 The combinations of Document Exchanges that are valid depend on the 8236 particular IOTP transaction. 8238 The remainder of this sub-section describes: 8240 o each Document Exchange in more detail including descriptions of the 8241 content of each Trading Block in the Document Exchanges, and 8243 o descriptions of how each IOTP Transaction uses the Document Exchanges 8244 to effect the desired result. 8246 [Note] The descriptions of the Document Exchanges which follow 8247 describe the ways in which various Business Errors (see 8248 section 4.2) are handled. No reference is made however to the 8249 handling of Technical Errors (see section 4.1) in any of the 8250 messages since these are handled the same way irrespective of 8251 the context in which the message is being sent. See section 4 8252 for more details. 8253 [Note End] 8255 9.1.1 Authentication Document Exchange 8257 The Authentication Document Exchange is a direct implementation of the 8258 Authentication Trading Exchange (see section 2.2.4). It involves: 8260 o an Authenticator - the Organisation which is requesting the 8261 authentication, and 8263 o an Authenticatee - the Organisation being authenticated. 8265 The authentication consists of: 8267 o an Authentication Request being sent by the Authenticator to the 8268 Authenticatee, 8270 o an Authentication Response being sent in return by the Authenticatee to 8271 the Authenticator which is then checked, and 8273 o an Authentication Status being sent by the Authenticator to the 8274 Authenticatee to provide an indication of the success or failure of the 8275 authentication. 8277 An Authentication Document Exchange also: 8279 o provides an Authenticatee with an Organisation Component which 8280 describes the Authenticator, and 8282 o optionally provides the Authenticator with Organisation Components 8283 which describe the Authenticatee. 8285 The Authentication Request may also be digitally signed which allows the 8286 Authenticatee to verify the credentials of the Authenticator. 8288 The IOTP Messages which are involved are illustrated by the diagram 8289 below. 8290 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8291 Organisation 1 8292 (Authenticatee) 8293 | Organisation 2 8294 | (Authenticator) 8295 STEP | | 8296 1. First Organisation takes an action (for example by pressing a 8297 button on an HTML page) which requires that the Organisation 8298 is authenticated 8300 1 --> 2 Authentication Need (outside scope of IOTP) 8302 2. The second Organisation generates: an Authentication Request 8303 Block containing one or more Authentication Request 8304 Components and/or a Trading Role Information Request 8305 Component, then sends it to the first Organisation 8307 1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block; 8308 Signature Block (optional); TPO Block; Auth Request Block 8310 3. IOTP aware application started. If a Signature Block is 8311 present, the first Organisation may use this to check the 8312 credentials of the second Organisation. If credentials are 8313 OK, the first Organisation selects an Authentication Request 8314 to use (if present and more than one), then uses the 8315 authentication algorithm selected to generate an 8316 Authentication Response Block. If present, the Trading Role 8317 Information Request Component is used to generate 8318 Organisation Components. Finally a Signature Component is 8319 created if required and all components are then sent back to 8320 the second Organisation for validation. 8322 1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature 8323 Block (optional) ; Auth Response Block 8325 4. The second Organisation checks the Authentication Response 8326 against the data in the Authentication Request Block to check 8327 that the first Organisation is who they appear to be, and 8328 sends an Authentication Status Block to the first 8329 Organisation to indicate the result then stops. 8331 1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature 8332 Block (optional); Auth Response Block 8334 5. The first Organisation checks the authentication Status Block 8335 and optionally keeps information on the IOTP transaction for 8336 record keeping purposes and stops. 8338 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8340 Figure 18 Authentication Document Exchange 8342 9.1.1.1 Message Processing Guidelines 8344 On receiving a TPO & Authentication Request IOTP Message (see below), an 8345 Authenticatee may either: 8347 o generate and send an Authentication Response IOTP Message back to the 8348 Authenticator, or 8350 o indicate failure to comply with the Authentication Request by sending a 8351 Cancel Block back to the Authenticator containing a Status Component 8352 with a StatusType of Authentication a ProcessState of Failed and the 8353 CompletionCode (see section 7.16.4) set to either: AutEeCancel, 8354 NoAuthReq, TradRolesIncon or Unspecified. 8356 On receiving an Authentication Response IOTP Message (see below), an 8357 Authenticator should send in return, an Authentication Status IOTP 8358 Message (see below) containing a Status Block with a Status Component 8359 where the StatusType is set to Authentication, and: 8361 o the ProcessState attribute of the Status Component is set to 8362 CompletedOk which indicates a successful completion, or 8364 o the ProcessState attribute is set to Failed and the CompletionCode 8365 attribute is set to either: AutOrCancel, AuthFailed or Unspecified 8366 which indicates a failed authentication, 8368 On receiving an Authentication Status IOTP Message (see below), the 8369 Authenticatee should check the Status Component in the Status Block. If 8370 this indicates: 8372 o a successful authentication, then the Authenticatee should either: 8373 - continue with the next step in the IOTP Transaction of which the 8374 Authentication Document Exchange is part (if any), or 8375 - indicate a failure to continue with the rest of the IOTP Transaction, 8376 by sending back to the Authenticator a Cancel Block containing a 8377 Status Component with a StatusType of Authentication, a ProcessState 8378 of Failed and the CompletionCode (see section 7.16.4) set to 8379 AutEeCancel. 8381 o a failed authentication, then the failure should be reported to the 8382 Authenticatee and any further processing stopped. 8384 If the Authenticator receives an IOTP Message containing a Cancel block 8385 from a Consumer, then the Authenticatee may go to the CancelNetLocn 8386 specified on the Trading Role Element in the Organisation Component for 8387 the Authenticator contained in the Trading Protocol Options Block. 8389 9.1.1.2 TPO & Authentication Request IOTP Message 8391 Apart from a Transaction Reference Block (see section 3.3), this message 8392 consists of: 8394 o a Trading Protocol Options Block (see section 8.1) 8396 o an Authentication Request Block (see section 8.4), and 8398 o an optional Signature Block (see section 8.16). 8400 Each of these are described below. 8402 TRADING PROTOCOL OPTIONS BLOCK 8404 The Trading Protocol Options Block (see section 8.1) must contain the 8405 following Trading Components: 8407 o one Protocol Options Component (see Section 7.1) which defines the 8408 options which apply to the whole Authentication Document Exchange. 8410 o one Organisation Component (see section 7.6) which describes the 8411 Authenticator. The Trading Role on the Organisation Component should 8412 indicate the role which the Authenticator is taking in the Trade, for 8413 example a Merchant or a Consumer. 8415 AUTHENTICATION REQUEST BLOCK 8417 The Authentication Request Block (see section 8.4) must contain the 8418 following Trading Components: 8420 o one Authentication Request Component (see section 7.2), and 8422 SIGNATURE BLOCK (AUTHENTICATION REQUEST) 8424 If the Authentication Request is being digitally signed then a Signature 8425 Block must be included. It contains Digests of the following XML 8426 elements: 8428 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8429 that contains information that describes the IOTP Message and IOTP 8430 Transaction 8432 o the Transaction Id Component (see section 3.3.1) which globally 8433 uniquely identifies the IOTP Transaction 8435 o the following components of the TPO Block : 8436 - the Protocol Options Component 8437 - the Organisation Component 8439 o the following components of the Authentication Request Block: 8441 - the Authentication Request Component 8442 - the Trading Role Information Request Component 8444 9.1.1.3 Authentication Response IOTP Message 8446 Apart from a Transaction Reference Block (see section 3.3), this message 8447 consists of: 8449 o an Authentication Response Block (see section 8.5), and 8451 o an optional Signature Block (see section 8.16). 8453 Each of these are described below. 8455 AUTHENTICATION RESPONSE BLOCK 8457 The Authentication Response Block must contain the following Trading 8458 Component: 8460 o one Authentication Response Component (see section 7.3) 8462 o one Organisation Component for every Trading Role identified in the 8463 TradingRoleList attribute of the Trading Role Information Request 8464 Component contained in the Authentication Request Block. 8466 SIGNATURE BLOCK (AUTHENTICATION RESPONSE) 8468 If the Algorithm element (see section 12. IANA Considerations) within the 8469 Authentication Request Component contained in the Authentication Request 8470 Block indicates that the Authentication Response should consist of a 8471 digital signature then a Signature Block must be included in the same 8472 IOTP message that contains an Authentication Response Block. The 8473 Signature Component contains Digest Elements for the following XML 8474 elements: 8476 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8477 that contains information that describes the IOTP Message and IOTP 8478 Transaction 8480 o the Transaction Id Component (see section 3.3.1) which globally 8481 uniquely identifies the IOTP Transaction 8483 o the following components of the Authentication Request Block: 8484 - the Authentication Request Component 8485 - the Trading Role Information Request Component 8487 o the Organisation Components contained in the Authentication Response 8488 Block 8490 [Note] It should not be assumed that all trading roles can support 8491 the signing of data. Particularly it should not be assumed 8492 that Consumers support the signing of data. 8493 [Note End] 8495 9.1.1.4 Authentication Status IOTP Message 8497 Apart from a Transaction Reference Block (see section 3.3), this message 8498 consists of: 8500 o an Authentication Status Block (see section 8.5), and 8502 o an optional Signature Block (see section 8.16). 8504 Each of these are described below. 8506 AUTHENTICATION STATUS BLOCK 8508 The Authentication Status Block (see section 8.6) must contain the 8509 following Trading Components: 8511 o one Status Component (see section 7.16) with a ProcessState attribute 8512 set to CompletedOk. 8514 SIGNATURE BLOCK (AUTHENTICATION STATUS) 8516 If the Authentication Status Block is being digitally signed then a 8517 Signature Block must be included that contains a Signature Component with 8518 Digest elements for the following XML elements: 8520 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8521 that contains information that describes the IOTP Message and IOTP 8522 Transaction 8524 o the Transaction Id Component (see section 3.3.1) which globally 8525 uniquely identifies the IOTP Transaction 8527 o the following components of the Authentication Status Block: 8528 - the Status Component (see section 7.16). 8530 [Note] If the Authentication Document Exchange is followed by an 8531 Offer Document Exchange (see section 9.1.2) then the 8532 Authentication Status Block and the Signature Block 8533 (Authentication Status) may be combined with either: 8534 o a TPO IOTP Message (see section 9.1.2.3), or 8535 o a TPO and Offer Response IOTP Message (see section 9.1.2.6) 8536 [Note End] 8538 9.1.2 Offer Document Exchange 8540 The Offer Document Exchange occurs in two basic forms: 8542 o Brand Dependent Offer Exchange. Where the content of the offer, e.g. 8543 the order details, amount, delivery details, etc., are dependent on the 8544 payment brand and protocol selected by the consumer, and 8546 o Brand Independent Offer Exchange. Where the content of the offer is not 8547 dependent on the payment brand and protocol selected. 8549 Each of these types of Offer Document Exchange may be preceded by an 8550 Authentication Document Exchange (see section 9.1.1). 8552 9.1.2.1 Brand Dependent Offer Document Exchange 8554 In a Brand Dependent Offer Document Exchange the TPO Block and the Offer 8555 Response Block are sent separately by the Merchant to the Consumer, i.e.: 8557 o the Brand List Component is sent to the Consumer in a TPO Block, 8559 o the Consumer selects a Payment Brand, Payment Protocol and optionally a 8560 Currency and amount from the Brand List Component 8562 o the Consumer sends the selected brand, protocol and currency/amount 8563 back to the Merchant in a TPO Selection Block, and 8565 o the Merchant uses the information received to define the content of and 8566 then send the Offer Response Block to the Consumer. 8568 This is illustrated by the diagram below. 8569 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8570 Consumer 8571 | Merchant 8572 STEP | | 8573 1. Consumer decides to trade and sends to the Merchant 8574 information (e.g. using HTML) that enables the Merchant to 8575 create an offer, 8577 C --> M Offer information - outside scope of IOTP 8579 2. Merchant decides which payment brand protocols, currencies 8580 and amounts apply, places then in a Brand List Component 8581 inside a TPO Block and sends to Consumer 8583 C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block 8585 3. IOTP aware application started. Consumer selects the payment 8586 brand, payment protocol and currency/amount to use. Records 8587 selection in a Brand Selection Component and sends back to 8588 Merchant. 8590 C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection Block 8592 4. Merchant uses selected payment brand, payment protocol, 8593 currency/amount and the offer information to create an Offer 8594 Response Block containing details about the IOTP Transaction 8595 including price, etc. Optionally signs it and sends to the 8596 Consumer 8598 C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8599 (optional); Offer Response Block 8601 5. Consumer checks the Offer is OK, then combines components 8602 from the TPO Block, the TPO Selection Block and the Offer 8603 Response Block to create the next IOTP Message for the 8604 Transaction and sends it together with the Signature block if 8605 present to the required Trading Role 8607 CONTINUED ... 8609 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8611 Figure 19 Brand Dependent Offer Document Exchange 8613 Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by 8614 the absence of an Offer Response Block in the first IOTP Message. 8616 MESSAGE PROCESSING GUIDELINES 8618 On receiving a TPO IOTP Message (see below), the Consumer may either: 8620 o generate and send a TPO Selection IOTP Message back to the Merchant, or 8622 o indicate failure to continue with the IOTP Transaction by sending a 8623 Cancel Block back to the Merchant containing a Status Component with a 8624 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8625 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8627 On receiving a TPO Selection IOTP Message (see below) the Merchant may 8628 either: 8630 o generate and send an Offer Response IOTP Message back to the Consumer, 8631 or 8633 o indicate failure to continue with the IOTP Transaction by sending a 8634 Cancel Block back to the Consumer containing a Status Component with a 8635 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8636 (see section 7.16.4) set to either: MerchCancelled or Unspecified. 8638 On receiving an Offer Response IOTP Message (see below) the Consumer may 8639 either: 8641 o generate and send the next IOTP Message in the IOTP transaction and 8642 send it to the required Trading Role. This is dependent on the IOTP 8643 Transaction, or 8645 o indicate failure to continue with the IOTP Transaction by sending a 8646 Cancel Block back to the Merchant containing a Status Component with a 8647 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8648 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8650 If the Merchant receives an IOTP Message containing a Cancel block, then 8651 the Consumer is likely to go to the CancelNetLocn specified on the 8652 Trading Role Element in the Organisation Component for the Merchant. 8654 If the Consumer receives an IOTP Message containing a Cancel block, then 8655 the information contained in the IOTP Message should be reported to the 8656 Consumer but no further action taken. 8658 9.1.2.2 Brand Independent Offer Document Exchange 8660 In a Brand Independent Offer Document Exchange the TPO Block and the 8661 Offer Response Block are sent together by the Merchant to the Consumer, 8662 i.e. there is one IOTP Message that contains both a TPO Block, and an 8663 Offer Response Block. 8665 The message flow is illustrated by the diagram below: 8666 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8667 Consumer 8668 | Merchant 8669 STEP | | 8670 1. Consumer decides to trade and sends to the Merchant 8671 information (e.g. using HTML) that enables the Merchant to 8672 create an offer, 8674 C --> M Offer information - outside scope of IOTP 8676 2. Merchant decides which payment brand protocols, currencies 8677 and amounts apply, places then in a Brand List Component 8678 inside a TPO Block, creates an Offer Response containing 8679 details about the IOTP Transaction including price, etc., 8680 optionally signs it and sends to Consumer 8682 C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature 8683 Block; TPO Block; Offer Response Block 8685 3. IOTP aware application started. Consumer selects the payment 8686 brand, payment protocol and currency/amount to use. Records 8687 selection in a Brand Selection Component, checks offer is OK, 8688 combines the Brand Selection Component with information from 8689 the TPO Block and Offer Response Block to create the next 8690 IOTP Message for the Transaction and sends it together with 8691 the Signature Block if present to the required Trading Role. 8693 CONTINUED ... 8695 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8697 Figure 20 Brand Independent Offer Exchange 8699 Note that a Brand Independent Offer Document Exchange always occurs when 8700 only one payment brand, protocol and currency/amount is being offered to 8701 the Consumer by the Merchant. It is also likely to, but will not 8702 necessarily, occur when multiple brands are being offered, the Payment 8703 Handler is the same, and all brands use the same set of protocols. 8705 Note that the TPO Block and the Offer Response Block can be sent in 8706 separate IOTP messages (see Brand Dependent Offer Document Exchange) even 8707 if the Offer Response Block does not change. However this increases the 8708 number of messages in the transaction and is therefore likely to increase 8709 transaction response times. 8711 IOTP aware applications supporting the Consumer Trading Role must check 8712 for the existence of an Offer Response Block in the first IOTP Message to 8713 determine whether the Offer Document Exchange is brand dependent or not. 8715 MESSAGE PROCESSING GUIDELINES 8717 On receiving a TPO and Offer Response IOTP Message (see below), the 8718 Consumer may either: 8720 o generate and send the next IOTP Message in the IOTP transaction and 8721 send it to the required Trading Role. This is dependent on the IOTP 8722 Transaction, or 8724 o indicate failure to continue with the IOTP Transaction by sending a 8725 Cancel Block back to the Merchant containing a Status Component with a 8726 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8727 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 8729 If the Merchant receives an IOTP Message containing a Cancel block, then 8730 the Consumer is likely to go to the CancelNetLocn specified on the 8731 Trading Role Element in the Organisation Component for the Merchant. 8733 9.1.2.3 TPO IOTP Message 8735 The TPO IOTP Message is only used with a Brand Dependent Offer Document 8736 Exchange. Apart from a Transaction Reference Block (see section 3.3), 8737 this message consists of just a Trading Protocol Options Block (see 8738 section 8.1) which is described below. 8740 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8742 The Trading Protocol Options Block (see section 8.1) must contain the 8743 following Trading Components: 8745 o one Protocol Options Component which defines the options which apply to 8746 the whole IOTP Transaction. See Section 7.1. 8748 o one Brand List Component (see section 7.7) for each Payment in the IOTP 8749 Transaction that contain one or more payment brands and protocols which 8750 may be selected for use in each payment 8752 o Organisation Components (see section 7.6) with the following roles: 8753 - Merchant who is making the offer 8754 - Consumer who is carrying out the transaction 8755 - the PaymentHandler(s) for the payment. The "ID" of the Payment 8756 Handler Organisation Component is contained within the PhOrgRef 8757 attribute of the Payment Component 8759 If the IOTP Transaction includes a Delivery then the TPO Block must also 8760 contain: 8762 o Organisation Components with the following roles: 8763 - DeliveryHandler who will be delivering the goods or services 8764 - DelivTo i.e. the person or Organisation which is to take delivery 8766 AUTHENTICATION STATUS AND SIGNATURE BLOCKS 8768 If the Offer Document Exchange was preceded by an Authentication Document 8769 Exchange, then the TPO IOTP Message may also contain: 8771 o an Authentication Status Block (see section 8.6), and 8773 o an optional Signature Block (Authentication Status) Signature Block 8775 See section 9.1.1.4 Authentication Status IOTP Message for more details. 8777 9.1.2.4 TPO Selection IOTP Message 8779 The TPO Selection IOTP Message is only used with a Brand Dependent Offer 8780 Document Exchange. Apart from a Transaction Reference Block (see section 8781 3.3), this message consists of just a TPO Selection Block (see section 8782 8.1) which is described below. 8784 TPO SELECTION BLOCK 8786 The TPO Selection Block (see section 8.2) contains: 8788 o one Brand Selection Component (see section 7.8) for use in a later 8789 Payment Exchange. It contains the results of the consumer selecting a 8790 Payment Brand, Payment Protocol and currency/amount from the list 8791 provided in the Brand List Component. 8793 9.1.2.5 Offer Response IOTP Message 8795 The Offer Response IOTP Message is only used with a Brand Dependent Offer 8796 Document Exchange. Apart from a Transaction Reference Block (see section 8797 3.3), this message consists of: 8799 o an Offer Response Block (see section 8.1) and 8801 o an optional Signature Block (see section 8.16). 8803 OFFER RESPONSE BLOCK 8805 The Offer Response Block (see section 8.3) contains the following 8806 components: 8808 o one Status Component (see section 7.16) which indicates the status of 8809 the Offer Response. The ProcessState attribute should be set to 8810 CompletedOk 8812 o one Order Component (see section 7.5) which contains details about the 8813 goods and services which are being purchased or the financial 8814 transaction which is taking place 8816 o one or more Payment Component(s) (see section 7.9) for each payment 8817 which is to be made 8819 o zero or one Delivery Components (see section 7.13) containing details 8820 of the delivery to be made if the IOTP Transaction includes a delivery 8822 o zero or more Trading Role Data Components (see section 7.17) if 8823 required by the Merchant. 8825 SIGNATURE BLOCK (OFFER RESPONSE) 8827 If the Authentication Status Block is being digitally signed then a 8828 Signature Block must be included that contains a Signature Component (see 8829 section 7.19) with Digest Elements for the following XML elements: 8831 If the Offer Response is being digitally signed then a Signature Block 8832 must be included that contains a Signature Component (see section 7.19) 8833 with Digest Elements for the following XML elements: 8835 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8836 that contains information that describes the IOTP Message and IOTP 8837 Transaction 8839 o the Transaction Id Component (see section 3.3.1) which globally 8840 uniquely identifies the IOTP Transaction 8842 o the following components of the TPO Block : 8843 - the Protocol Options Component, and 8844 - the Brand List Component 8845 - all the Organisation Components present 8847 o the following components of the Offer Response Block: 8848 - the Order Component 8849 - all the Payment Components present 8850 - the Delivery Component if present 8851 - any Trading Role Data Components present 8853 9.1.2.6 TPO and Offer Response IOTP Message 8855 The TPO and Offer Response IOTP Message is only used with a Brand 8856 Independent Offer Document Exchange. Apart from a Transaction Reference 8857 Block (see section 3.3), this message consists of: 8859 o a Trading Protocol Options Block (see section 8.1) 8861 o an Offer Response Block (see section 8.1) and 8863 o an optional Signature Block (see section 8.16). 8865 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8867 This is the same as the Trading Protocol Options Block described in TPO 8868 IOTP Message (see section 9.1.2.3). 8870 OFFER RESPONSE BLOCK 8872 This the same as the Offer Response Block in the Offer Response IOTP 8873 Message (see section 9.1.2.5). 8875 AUTHENTICATION STATUS 8877 If the Offer Document Exchange was preceded by an Authentication Document 8878 Exchange, then the TPO and Offer Response IOTP Message may also contain 8879 an Authentication Status Block (see section 8.6). 8881 SIGNATURE BLOCK 8883 This is the same as the Signature Block in the Offer Response IOTP 8884 Message (see section 9.1.2.5) with the addition that: 8886 o if the Offer Document Exchange is Brand Dependent then the Signature 8887 Component in the Signature Block additionally contains a Digest Element 8888 for the Brand Selection Component contained in the TPO Selection Block 8890 o if the Offer Document Exchange was preceded by an Authentication 8891 Document Exchange then the Signature Component in the Signature Block 8892 additionally contains a Digest Element for the Authentication Status 8893 Block. 8895 9.1.3 Payment Document Exchange 8897 The Payment Document Exchange is a direct implementation of the last part 8898 of a Payment Trading Exchange (see section 2.2.2) after the Brand has 8899 been selected by the Consumer. A Payment Exchange consists of: 8901 o the Consumer requesting that a payment starts by generating Payment 8902 Request IOTP Message using information from previous IOTP Messages in 8903 the Transaction and then sending it to the Payment Handler 8905 o the Payment Handler and the Consumer then swapping Payment Exchange 8906 IOTP Messages encapsulating payment protocol messages until the payment 8907 is complete, and finally 8909 o the Payment Handler sending a Payment Response IOTP Message to the 8910 Consumer containing a receipt for the payment. 8912 The IOTP Messages which are involved are illustrated by the diagram 8913 below. 8914 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8915 Consumer 8916 | Payment 8917 | Handler 8918 STEP | | 8919 1. Consumer generates Pay Request Block encapsulating a payment 8920 protocol message if required and sends to Payment Handler 8921 with the Signature Block if present 8923 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block 8924 (optional); Pay Request Block 8926 2. Payment Handler processes Pay Request Block, checks optional 8927 signature and starts exchanging payment protocol messages 8928 encapsulated in a Pay Exchange Block, with the Consumer 8930 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 8931 Block 8933 3. Consumer and Payment Handler keep on exchanging Payment 8934 Exchange blocks until eventually payment protocol messages 8935 finish so Payment Handler creates a Pay Receipt Component 8936 inside a Pay Response Block, and an optional Signature 8937 Component inside a Signature Block, sends them to the 8938 Consumer and stops. 8940 C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8941 (optional); Pay Response Block 8943 4. Consumer checks Payment Response is OK. Optionally keeps 8944 information on IOTP Transaction for record keeping purposes 8945 and either stops or creates the next IOTP message for the 8946 Transaction and sends it together with the Signature Block, 8947 if present, to the required Trading Role 8949 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8951 Figure 21 Payment Document Exchange 8953 9.1.3.1 Message Processing Guidelines 8955 On receiving a Payment Request IOTP Message, the Payment Handler should 8956 check that they are authorised to carry out the Payment (see section 6 8957 Digital Signatures). They may then either: 8959 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8960 if more payment protocol messages need to be exchanged, or 8962 o generate and send a Payment Response IOTP Message if the exchange of 8963 payment protocol messages is complete, or 8965 o indicate failure to continue with the Payment by sending a Cancel Block 8966 back to the Consumer containing a Status Component with a StatusType of 8967 Payment, a ProcessState of Failed and the CompletionCode (see section 8968 7.16.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, 8969 AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument 8970 or Unspecified. 8972 On receiving a Payment Exchange IOTP Message, the Consumer may either: 8974 o generate and send a Payment Exchange Message back to the Payment 8975 Handler or 8977 o indicate failure to continue with the Payment by sending a Cancel Block 8978 back to the Payment Handler containing a Status Component with a 8979 StatusType of Payment, a ProcessState of Failed and the CompletionCode 8980 (see section 7.16.2) set to either: ConsCancelled or Unspecified. 8982 On receiving a Payment Exchange IOTP Message, the Payment Handler may 8983 either: 8985 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8986 if more payment protocol messages need to be exchanged, or 8988 o generate and send a Payment Response IOTP Message if the exchange of 8989 payment protocol messages is complete, or 8991 o indicate failure to continue with the Payment by sending a Cancel Block 8992 back to the Consumer containing a Status Component with a StatusType of 8993 Payment, a ProcessState of Failed and the CompletionCode (see section 8994 7.16.2) set to either: PaymtCancelled or Unspecified. 8996 On receiving a Payment Response IOTP Message, the Consumer may either: 8998 o generate and send the next IOTP Message in the IOTP transaction and 8999 send it to the required Trading Role. This is dependent on the IOTP 9000 Transaction, 9002 o stop, since the IOTP Transaction has ended, or 9004 o indicate failure to continue with the IOTP Transaction by sending a 9005 Cancel Block back to the Merchant containing a Status Component with a 9006 StatusType of Payment, a ProcessState of Failed and the CompletionCode 9007 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 9009 If the Consumer receives an IOTP Message containing a Cancel block, then 9010 the information contained in the IOTP Message should be reported to the 9011 Consumer but no further action taken. 9013 If the Payment Handler receives an IOTP Message containing a Cancel 9014 block, then the Consumer is likely to go to the CancelNetLocn specified 9015 on the Trading Role Element in the Organisation Component for the Payment 9016 Handler from which any further action may take place. 9018 If the Merchant receives an IOTP Message containing a Cancel block, then 9019 the Consumer should have completed the payment but not continuing with 9020 the transaction for some reason. In this case the Consumer is likely to 9021 go to the CancelNetLocn specified on the Trading Role Element in the 9022 Organisation Component for the Merchant from which any further action may 9023 take place. 9025 9.1.3.2 Payment Request IOTP Message 9027 Apart from a Transaction Reference Block (see section 3.3), this message 9028 consists of: 9030 o a Payment Request Block, and 9031 o an optional Signature Block 9033 PAYMENT REQUEST BLOCK 9035 The Payment Request Block (see section 8.7) contains: 9037 o the following components copied from the Offer Response Block from the 9038 preceding Offer Document Exchange: 9039 - the Status Component 9040 - the Payment Component for the payment which is being carried out 9042 o the following components from the TPO Block: 9043 - the Organisation Components with the roles of Merchant and for the 9044 PaymentHandler that is being sent the Payment Request Block 9045 - the Brand List Component for the payment, i.e. the Brand List 9046 referred to by the BrandListRef attribute on the Payment Component 9048 o one Brand Selection Component for the Brand List, i.e. the Brand 9049 Selection Component where BrandListRef attribute points to the Brand 9050 List. This component can be either: 9051 - copied from the TPO Selection Block if the payment was preceded by a 9052 Brand Dependent Offer Document Exchange (see section 9.1.2.1), or 9053 - created by the Consumer, containing the payment brand, payment 9054 protocol and currency/amount selected from the Brand List, if the 9055 payment was preceded by a Brand Independent Offer Document Exchange 9056 (see section 9.1.2.2) 9058 o an optional Payment Scheme Component (see section 7.10) if required by 9059 the payment method used (see the Payment Method supplement to determine 9060 if this is needed). 9062 o zero or more Trading Role Data Components (see section 7.17). 9064 Note that: 9066 o if there is more than one Payment Components in an Offer Response 9067 Block, then the second payment is the one within the Offer Response 9068 Block that contains a StartAfter attribute (see section 7.9) that 9069 identifies the Payment Component for the first payment 9071 o the Payment Handler to include is identified by the Brand Selection 9072 Component (see section 7.8) for the payment. Also see section 6.3.1 9073 Check Request Block sent Correct Organisation for an explanation on how 9074 Payment Handlers are identified 9076 o the Brand List Component to include is the one identified by the 9077 BrandListRef attribute of the Payment Component for the identified 9078 payment 9080 o the Brand Selection Component to include from the Offer Response Block 9081 is the one that contains an BrandListRef attribute (see section 3.5) 9082 which identifies the Brand List Component for the second payment. 9084 SIGNATURE BLOCK (PAYMENT REQUEST) 9086 If the either the preceding Offer Document Exchange included an Offer 9087 Response Signature (see section 9.1.2.5 Offer Response IOTP Message), or 9088 a preceding Payment Exchange included a Payment Response Signature (see 9089 section 9.1.3.4 Payment Response IOTP Message) then they should both be 9090 copied to the Signature Block in the Payment Request IOTP Message. 9092 9.1.3.3 Payment Exchange IOTP Message 9094 Apart from a Transaction Reference Block (see section 3.3), this message 9095 consists of just a Payment Exchange Block. 9097 PAYMENT EXCHANGE BLOCK 9099 The Payment Exchange Block (see section 8.8) contains: 9101 o one Payment Scheme Component (see section 7.10) which contains payment 9102 method specific data. See the Payment Method supplement for the payment 9103 method being used to determine what this should contain. 9105 9.1.3.4 Payment Response IOTP Message 9107 Apart from a Transaction Reference Block (see section 3.3), this message 9108 consists of: 9110 o a Payment Response Block, and 9112 o an optional Signature Block 9114 PAYMENT RESPONSE BLOCK 9116 The Payment Response Block (see section 8.9) contains: 9118 o one Payment Receipt Component (see section 7.11) which contains scheme 9119 specific data which can be used to verify the payment occurred 9121 o one Payment Scheme Component (see section 7.10) if required which 9122 contains payment method specific data. See the Payment Method 9123 supplement for the payment method being used to determine what this 9124 should contain 9126 o an optional Payment Note Component (see section 7.12) 9128 o zero or more Trading Role Data Components (see section 7.17). 9130 SIGNATURE BLOCK (PAYMENT RESPONSE) 9132 If a signed Payment Receipt is being provided, indicated by the 9133 SignedPayReceipt attribute of the Payment Component being set to True, 9134 then the Signature Block should contain a Signature Component which 9135 contains Digest Elements for the following: 9137 o the Transaction Reference Block (see section 3.3) for the IOTP Message 9138 which contains the first usage of the Payment Response Block, 9140 o the Transaction Id Component (see section 3.3.1) within the Transaction 9141 Reference Block that globally uniquely identifies the IOTP Transaction, 9143 o the Payment Receipt Component from the Payment Response Block, 9145 o the Payment Note Component from the Payment Response Block, 9147 o the other Components referenced by the PayReceiptNameRefs attribute (if 9148 present) of the Payment Receipt Component, 9150 o the Status Component from the Payment Response Block, 9152 o any Trading Role Data Components in the Payment Response Block, and 9154 o all the Signature Components contained in the Payment Request Block if 9155 present. 9157 9.1.4 Delivery Document Exchange 9159 The Delivery Document Exchange is a direct implementation of a Delivery 9160 Trading Exchange (see section 2.2.3). It consists of: 9162 o the Consumer requesting a Delivery by generating Delivery Request IOTP 9163 Message using information from previous IOTP Messages in the 9164 Transaction and then sending it to the Delivery Handler 9166 o the Delivery Handler sending a Delivery Response IOTP Message to the 9167 Consumer containing details about the Handler's response to the request 9168 together with an optional signature. 9170 The message flow is illustrated by the diagram below. 9171 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9172 Consumer 9173 | Delivery 9174 | Handler 9175 STEP | | 9176 1. Consumer generates Delivery Request Block and sends it to the 9177 Delivery Handler with the Signature Block if present 9179 C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9180 Delivery Request Block 9182 2. Delivery Handler checks the Status and Order Components in 9183 the Delivery Request and the optional Signatures, creates a 9184 Delivery Response Block, sends to the Consumer and stops. 9186 C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature Block; 9187 Delivery Response Block 9189 3. Consumer checks Delivery Response Block and optional 9190 Signature Block are OK. Optionally keeps information on IOTP 9191 Transaction for record keeping purposes and stops. 9193 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9195 Figure 22 Delivery Document Exchange 9197 9.1.4.1 Message Processing Guidelines 9199 On receiving a Delivery Request IOTP Message, the Delivery Handler should 9200 check that they are authorised to carry out the Delivery (see section 6 9201 Digital Signatures). They may then either: 9203 o generate and send a Delivery Response IOTP Message to the Consumer, or 9205 o indicate failure to continue with the Delivery by sending a Cancel 9206 Block back to the Consumer containing a Status Component with a 9207 StatusType of Delivery, a ProcessState of Failed and the CompletionCode 9208 (see section 7.16.4) set to either: DelivCanceled, or Unspecified. 9210 On receiving a Delivery Response IOTP Message, the Consumer should just 9211 stop since the IOTP Transaction is complete. 9213 If the Consumer receives an IOTP Message containing a Cancel block, then 9214 the information contained in the IOTP Message should be reported to the 9215 Consumer but no further action taken. 9217 9.1.4.2 Delivery Request IOTP Message 9219 The Delivery Request IOTP Message consists of: 9221 o a Delivery Request Block, and 9223 o an optional Signature Block 9225 DELIVERY REQUEST BLOCK 9227 The Delivery Request Block (see section 8.10) contains: 9229 o the following components copied from the Offer Response Block: 9230 - the Status Component (see section 7.16) 9231 - the Order Component (see section 7.5) 9232 - the Organisation Component (see section 7.6) with the roles of: 9233 Merchant, DeliveryHandler and DeliverTo 9234 - the Delivery Component (see section 7.13) 9236 o the following Component from the Payment Response Block: 9237 - the Status Component (see section 7.16). 9239 o zero or more Trading Role Data Components (see section 7.17). 9241 SIGNATURE BLOCK (DELIVERY REQUEST) 9243 If the preceding Offer Document Exchange included an Offer Response 9244 Signature or the Payment Document Exchange included a Payment Response 9245 Signature, then they should both be copied to the Signature Block. 9247 9.1.4.3 Delivery Response IOTP Message 9249 The Delivery Response IOTP Message contains a Delivery Response Block and 9250 an optional Signature Block. 9252 DELIVERY RESPONSE BLOCK 9254 The Delivery Response Block contains: 9256 o one Delivery Note Component (see section 7.15) which contains delivery 9257 instructions about the delivery of goods or services 9259 SIGNATURE BLOCK (DELIVERY RESPONSE) 9261 The Signature Block should contain one Signature Component that contains 9262 Digest elements that refer to 9264 o the Transaction Id Component (see section 3.3.1) of the IOTP message 9265 that contains the Delivery Response Signature 9267 o the Transaction Reference Block (see section 3.3) of the IOTP Message 9268 that contains the Delivery Response Signature 9270 o the Consumer Delivery Data component contained in the Delivery Request 9271 Block (if any) 9273 o the Signature Components contained in the Delivery Request Block (if 9274 any) 9276 o the Status Component 9278 o the Delivery Note Component 9280 9.1.5 Payment and Delivery Document Exchange 9282 The Payment and Delivery Document Exchange is a combination of the last 9283 part of the Payment Trading Exchange (see section 2.2.2) and a Delivery 9284 Trading Exchange (see section 2.2.3). It consists of: 9286 o the Consumer requesting that a payment starts by generating Payment 9287 Request IOTP Message using information from previous IOTP Messages in 9288 the Transaction and then sending it to the Payment Handler 9290 o the Payment Handler and the Consumer then swapping Payment Exchange 9291 IOTP Messages encapsulating payment protocol messages until the payment 9292 is complete, and finally 9294 o the Payment Handler sending to the Consumer in one IOTP Message: 9295 - a Payment Response Block containing a receipt for the payment, and 9296 - a Delivery Response Block containing details of the goods or services 9297 to be delivered 9299 The IOTP Messages which are involved are illustrated by the diagram 9300 below. 9301 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9302 Consumer 9303 | Payment 9304 | Handler 9305 STEP | | 9306 1. Consumer generates Pay Request Block encapsulating a payment 9307 protocol message if required and sends to Payment Handler 9308 with the Signature Block if present 9310 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9311 Pay Request Block 9313 2. Payment Handler processes Pay Request Block, checks optional 9314 signature and starts exchanging payment protocol messages 9315 encapsulated in a Pay Exchange Block, with the Consumer 9317 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 9318 Block 9320 3. Consumer and Payment Handler keep on exchanging Payment 9321 Exchange blocks until eventually payment protocol messages 9322 finish so Payment Handler creates a Pay Receipt Component 9323 inside a Pay Response Block, and an optional Signature 9324 Component inside a Signature Block, then uses information 9325 from the Offer Response Bock to crteate a Delivery Response 9326 Block and sends both to the Consumer and stops. 9328 C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref 9329 Block; Signature Block; Pay Response Block; Delivery Response 9330 Block 9332 4. Consumer checks Payment Response and Delivery Response Blocks 9333 are OK. Optionally keeps information on IOTP Transaction for 9334 record keeping purposes and either stops or creates the next 9335 IOTP message for the Transaction and sends it together with 9336 the Signature Block, if present, to the required Trading Role 9338 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9340 Figure 23 Payment and Delivery Document Exchange 9342 The Delivery Response Block and the Payment Response Block may be 9343 combined into the same IOTP Message only if the Payment Handler has the 9344 information available so that she can send the Delivery Response Block. 9345 This is likely to, but will not necessarily, occur when the Merchant, the 9346 Payment Handler and the Delivery Handler Roles are combined. 9348 The DelivAndPayResp attribute of the Delivery Component (see section 9349 7.13) contained within the Offer Response Block (see section 8.3) is set 9350 to True if the Delivery Response Block and the Payment Response Block are 9351 combined into the same IOTP Message and is set to False if the Delivery 9352 Response Block and the Payment Response Block are sent in separate IOTP 9353 Messages. 9355 9.1.5.1 Message Processing Guidelines 9357 On receiving a Payment Request IOTP Message or a Payment Exchange IOTP 9358 Message, the Payment Handler should carry out the same actions as for a 9359 Payment Document Exchange (see section 9.1.3.1). 9361 On receiving a Payment Exchange IOTP Message, the Consumer should also 9362 carry out the same actions as for a Payment Document Exchange (see 9363 section 9.1.3.1). 9365 On receiving a Payment Response and Delivery Response IOTP Message then 9366 the IOTP Transaction is complete and should take no further action. 9368 If the Consumer receives an IOTP Message containing a Cancel block, then 9369 the information contained in the IOTP Message should be reported to the 9370 Consumer but no further action taken. 9372 If the Payment Handler receives an IOTP Message containing a Cancel 9373 block, then the Consumer is likely to go to the CancelNetLocn specified 9374 on the Trading Role Element in the Organisation Component for the Payment 9375 Handler from which any further action may take place. 9377 If the Merchant receives an IOTP Message containing a Cancel block, then 9378 the Consumer should have completed the payment but not continuing with 9379 the transaction for some reason. In this case the Consumer is likely to 9380 go to the CancelNetLocn specified on the Trading Role Element in the 9381 Organisation Component for the Merchant from which any further action may 9382 take place. 9384 9.1.5.2 Payment Request IOTP Message 9386 The content of this message is the same as for a Payment Request IOTP 9387 Message in a Payment Document Exchange (see section 9.1.3.2) 9389 9.1.5.3 Payment Exchange IOTP Message 9391 The content of this message is the same as for a Payment Exchange IOTP 9392 Message in a Payment Document Exchange (see section 9.1.3.3). 9394 9.1.5.4 Payment Response and Delivery Response IOTP Message 9396 The content of this message consists of: 9398 o a Payment Response Block, 9400 o an optional Signature Block (Payment Response), and 9401 o a Delivery Response Block. 9403 PAYMENT RESPONSE BLOCK 9405 The content of this block is the same as the Payment Response Block in 9406 the Payment Response IOTP Message associated with a Payment Document 9407 Exchange (see section 9.1.3.4). 9409 SIGNATURE BLOCK (PAYMENT RESPONSE) 9411 The content of this block is the same as the Signature Block (Payment 9412 Response) in the Payment Response IOTP Message associated with a Payment 9413 Document Exchange (see section 9.1.3.4). 9415 DELIVERY RESPONSE BLOCK 9417 The content of this block is the same as the Delivery Response Block in 9418 the Delivery Response IOTP Message associated with a Delivery Document 9419 Exchange (see section 9.1.4.3). 9421 9.1.6 Baseline Authentication IOTP Transaction 9423 A Baseline Authentication IOTP Transaction may occur at any time between 9424 any of the Trading Roles involved in IOTP Transactions. This means it 9425 could occur: 9427 o before another IOTP Transaction 9429 o at the same time as another IOTP Transaction 9431 o independently of any other IOTP Transaction. 9433 The Baseline Authentication IOTP Transaction consists of just an 9434 Authentication Document Exchange (see section 9.1.1) as illustrated by 9435 the diagram below. 9436 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9438 START ------------------------------------------------------- 9439 v 9440 ---------------- 9441 | AUTHENTICATION | 9442 ---------------- 9443 | 9444 | 9445 | 9446 | 9447 ------------------- ----------------- | 9448 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9449 | OFFER | | OFFER | | 9450 ------------------- ----------------- | 9451 | 9452 | 9453 | 9454 | 9455 | 9456 --------- -------------- | 9457 | PAYMENT | | PAYMENT WITH | | 9458 | (first) | | DELIVERY | | 9459 --------- -------------- | 9460 | 9461 | 9462 | 9463 ---------- --------- | 9464 | DELIVERY | | PAYMENT | | 9465 | | | {second)| | 9466 ---------- --------- | 9467 v 9468 STOP 9470 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9472 Figure 24 Baseline Authentication IOTP Transaction 9474 Example uses of the Baseline Authentication IOTP Transaction include: 9476 o when the Baseline Authentication IOTP Transaction takes place as an 9477 early part of a session where strong continuity exists. For example, a 9478 Financial Institution could: 9479 - set up a secure channel (e.g. using [SSL/TLS]) with a customer 9480 - authenticate the customer using the Baseline Authentication IOTP 9481 Transaction, and then 9482 - provide the customer with access to account information and other 9483 services with the confidence that they are communicating with a bona 9484 fide customer. 9486 o as a means of providing a Merchant role with Organisation Components 9487 that contain information about Consumer and DelivTo Trading Roles 9489 o so that a Consumer may authenticate a Payment Handler before starting a 9490 payment. 9492 9.1.7 Baseline Deposit IOTP Transaction 9494 The Baseline Deposit IOTP Transaction supports the deposit of electronic 9495 cash with a Financial Institution. 9497 [Note] The Financial Institution has, in IOTP terminology, a role of 9498 merchant in that a service (i.e. a deposit of electronic cash) 9499 is being offered in return for a fee, for example bank charges 9500 of some kind. The term "Financial Institution" is used in the 9501 diagrams and in the text for clarity. 9502 [Note End] 9504 The Baseline Deposit IOTP Transaction consists of the following Document 9505 Exchanges: 9507 o an optional Authentication Document Exchange (see section 9.1.1) 9509 o an Offer Document Exchange (see section 9.1.2), and 9511 o a Payment Document Exchange (see section 9.1.3). 9513 The way in which these Document Exchanges may be combined together is 9514 illustrated by the diagram below. 9515 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9517 START ----------------------------------------------------- 9518 | v 9519 | ---------------- 9520 | | AUTHENTICATION | 9521 | ---------------- 9522 -------------------------------------- | 9523 | | | 9524 | -------------- | ------------- 9525 v v v v 9526 ------------------- ----------------- 9527 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9528 | OFFER | | OFFER | 9529 ------------------- ----------------- 9530 | | 9531 | | 9532 | | 9533 | ------------------- 9534 v v 9535 --------- -------------- 9536 | PAYMENT | | PAYMENT WITH | 9537 | (first) | | DELIVERY | 9538 --------- -------------- 9539 | 9540 ---------------- 9541 | 9542 ---------- --------- | 9543 | DELIVERY | | PAYMENT | | 9544 | | | {second)| | 9545 ---------- --------- | 9546 | 9547 -----------------> STOP 9549 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9551 Figure 25 Baseline Deposit IOTP Transaction 9553 See section 9.1.12 "Valid Combinations of Document Exchanges" to 9554 determine which combination of document exchanges apply to a particular 9555 instance of an IOTP Transaction 9557 Note that: 9559 o a Merchant (Financial Institution) may be able to accept a deposit in 9560 several different types of electronic cash although, since the Consumer 9561 role that is depositing the electronic cash usually knows what type of 9562 cash they want to deposit, it is usually constrained in practice to 9563 only one type. However, there may be several different protocols which 9564 may be used for the same "brand" of electronic cash. In this case a 9565 Brand Dependent Offer may be appropriate to negotiate the protocol to 9566 be used. 9568 o the Merchant (Financial Institution) may use the results of the 9569 authentication to identify not only the consumer but also the account 9570 to which the payment is to be deposited. If no single account can be 9571 identified, then it must be obtained by other means. For example: 9572 - the consumer could specify the account number prior to the Baseline 9573 Deposit IOTP Transaction starting, or 9574 - the consumer could have been identified earlier, for example using a 9575 Baseline Authentication IOTP Transaction, and an account selected 9576 from a list provided by the Financial Institution. 9578 o The Baseline Deposit IOTP Transaction without an Authentication 9579 Document Exchange might be used: 9580 - if a previous IOTP transaction, for example a Baseline Withdrawal or 9581 a Baseline Authentication, authenticated the consumer, and a secure 9582 channel has been maintained, therefore the authenticity of the 9583 consumer is known 9584 - if authentication is achieved as part of a proprietary payment 9585 protocol and is therefore included in the Payment Document Exchange 9586 - if authentication of the consumer has been achieved by some other 9587 means outside of the scope of IOTP, for example, by using a pass 9588 phrase, or a proprietary banking software solution. 9590 9.1.8 Baseline Purchase IOTP Transaction 9592 The Baseline Purchase IOTP Transaction supports the purchase of goods or 9593 services using any payment method. It consists of the following Document 9594 Exchanges: 9596 o an optional Authentication Document Exchange (see section 9.1.1) 9598 o an Offer Document Exchange (see section 9.1.2) 9600 o either: 9601 - a Payment Document Exchange (see section 9.1.3) followed by 9602 - a Delivery Document Exchange (see section 9.1.4) 9604 o a Payment Document Exchange only, or 9606 o a combined Payment and Delivery Document Exchange (see section 9.1.5). 9608 The ways in which these Document Exchanges are combined is illustrated by 9609 the diagram below. 9610 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9611 START ----------------------------------------------------- 9612 | v 9613 | ---------------- 9614 | | AUTHENTICATION | 9615 | ---------------- 9616 -------------------------------------- | | 9617 | | | | 9618 | -------------- | ------------- | 9619 v v v v | 9620 ------------------- ----------------- | 9621 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9622 | OFFER | | OFFER | | 9623 ------------------- ----------------- | 9624 | | | | | 9625 | --------------- | | | 9626 | | | | | 9627 | -------------- | -- | | 9628 v v v v | 9629 --------- -------------- | 9630 | PAYMENT | | PAYMENT WITH | | 9631 | (first) | | DELIVERY | | 9632 --------- -------------- | 9633 | | | 9634 ----------------------------- | | 9635 v | | | 9636 ---------- --------- | | | 9637 | DELIVERY | | PAYMENT | | | | 9638 | | | {second)| | | | 9639 ---------- --------- | | | 9640 | | | v 9641 ----------------------------------------------> STOP 9643 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9645 Figure 26 Baseline Purchase IOTP Transaction 9647 See section 9.1.12 Valid Combinations of Document Exchanges to determine 9648 which combination of document exchanges apply to a particular instance of 9649 an IOTP Transaction 9651 9.1.9 Baseline Refund IOTP Transaction 9653 In business terms the refund process typically consists of: 9655 o a request for a refund being made by the Consumer to the Merchant, 9656 typically supported by evidence to demonstrate: 9657 - the original trade took place, for example by providing a receipt for 9658 the original transaction 9659 - using some type of authentication, that the consumer requesting the 9660 refund is the consumer, or a representative of the consumer, who 9661 carried out the original trade 9662 - the reason why the merchant should make the refund 9664 o the merchant agreeing (or not) to the refund. This may involve some 9665 negotiation between the Consumer and the Merchant, and, if the merchant 9666 agrees, 9668 o a refund payment by the Merchant to the Consumer. 9670 The Baseline Refund IOTP Transaction supports a subset of the above, 9671 specifically it supports: 9673 o stand alone authentication of the Consumer using a separate Baseline 9674 Authentication IOTP Transaction (see section 9.1.6) 9676 o a refund payment by the Merchant to the Consumer using the following 9677 two Trading Exchanges: 9678 - an optional Authentication Document Exchange (see section 9.1.1) 9679 - an Offer Document Exchange (see section 9.1.2), and 9680 - a Payment Document Exchange (see section 9.1.3). 9682 The ways in which these Document Exchanges are combined is illustrated by 9683 the diagram below. 9684 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9686 START ----------------------------------------------------- 9687 | v 9688 | ---------------- 9689 | | AUTHENTICATION | 9690 | ---------------- 9691 -------------------------------------- | 9692 | | | 9693 | -------------- | ------------- 9694 v v v v 9695 ------------------- ----------------- 9696 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9697 | OFFER | | OFFER | 9698 ------------------- ----------------- 9699 | | 9700 | | 9701 | | 9702 | ------------------- 9703 v v 9704 --------- -------------- 9705 | PAYMENT | | PAYMENT WITH | 9706 | (first) | | DELIVERY | 9707 --------- -------------- 9708 | 9709 ---------------- 9710 | 9711 ---------- --------- | 9712 | DELIVERY | | PAYMENT | | 9713 | | | {second)| | 9714 ---------- --------- | 9715 | 9716 -----------------> STOP 9718 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9720 Figure 27 Baseline Refund IOTP Transaction 9722 A Baseline Refund IOTP Transaction without an Authentication Document 9723 Exchange might be used: 9725 o when authentication of the consumer has been achieved by some other 9726 means, for example, the consumer has entered some previously supplied 9727 code in order to identify herself and the refund to which the code 9728 applies. The code could be supplied, for example on a web page or by e- 9729 mail. 9731 o when a previous IOTP transaction, for example a Baseline 9732 Authentication, authenticated the consumer, and a secure channel has 9733 been maintained, therefore the authenticity of the consumer is known 9734 and therefore the previously agreed refund can be identified. 9736 o when the authentication of the consumer is carried out by the Payment 9737 Handler using a payment scheme authentication algorithm. 9739 9.1.10 Baseline Withdrawal IOTP Transaction 9741 The Baseline Withdrawal IOTP Transaction supports the withdrawal of 9742 electronic cash from a Financial Institution. 9744 [Note] The Financial Institution has, in IOTP terminology, a role of 9745 merchant in that a service (i.e. a withdrawal of electronic 9746 cash) is being offered in return for a fee, for example bank 9747 charges of some kind. The term "Financial Institution" is used 9748 in the diagrams and in the text for clarity. 9749 [Note End] 9751 The Baseline Withdrawal IOTP Transaction consists of the following 9752 Document Exchanges: 9754 o an optional Authentication Document Exchange (see section 9.1.1) 9756 o an Offer Document Exchange (see section 9.1.2), and 9758 o a Payment Document Exchange (see section 9.1.3). 9760 The way in which these Document Exchanges may be combined together is 9761 illustrated by the diagram below. 9762 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9764 START ----------------------------------------------------- 9765 | v 9766 | ---------------- 9767 | | AUTHENTICATION | 9768 | ---------------- 9769 -------------------------------------- | 9770 | | | 9771 | -------------- | ------------- 9772 v v v v 9773 ------------------- ----------------- 9774 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9775 | OFFER | | OFFER | 9776 ------------------- ----------------- 9777 | | 9778 | | 9779 | | 9780 | ------------------- 9781 v v 9782 --------- -------------- 9783 | PAYMENT | | PAYMENT WITH | 9784 | (first) | | DELIVERY | 9785 --------- -------------- 9786 | 9787 ---------------- 9788 | 9789 ---------- --------- | 9790 | DELIVERY | | PAYMENT | | 9791 | | | {second)| | 9792 ---------- --------- | 9793 | 9794 -----------------> STOP 9796 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9798 Figure 28 Baseline Withdrawal IOTP Transaction 9800 Note that: 9802 o a Merchant (Financial Institution) may be able to offer withdrawal of 9803 several different types of electronic cash. In practice usually only 9804 one form of electronic cash may be offered. However, there may be 9805 several different protocols which may be used for the same "brand" of 9806 electronic cash 9808 o the Merchant (Financial Institution) may use the results of the 9809 authentication to identify not only the consumer but also the account 9810 from which the withdrawal is to be made. If no single account can be 9811 identified, then it must be obtained by other means. For example: 9812 - the consumer could specify the account number prior to the Baseline 9813 Withdrawal IOTP Transaction starting, or 9814 - the consumer could have been identified earlier, for example using a 9815 Baseline Authentication IOTP Transaction, and an account selected 9816 from a list provided by the Financial Institution. 9818 o a Baseline Withdrawal without an authentication might be used: 9819 - if a previous IOTP transaction, for example a Baseline Deposit or a 9820 Baseline Authentication, authenticated the consumer, and a secure 9821 channel has been maintained, therefore the authenticity of the 9822 consumer is known 9824 - if authentication is achieved as part of a proprietary payment 9825 protocol and is therefore included in the Payment Document Exchange 9826 - if authentication of the consumer has been achieved by some other 9827 means, for example, by using a pass phrase, or a proprietary banking 9828 software solution. 9830 9.1.11 Baseline Value Exchange IOTP Transaction 9832 The Baseline Value Exchange Transaction uses Payment Document Exchanges 9833 to support the exchange of value in one currency obtained using one 9834 payment method with value in the same or another currency using the same 9835 or another payment method. Examples of its use include: 9837 o electronic cash advance on a credit card. For example the first payment 9838 could be a "dollar SET Payment" using a credit card with the second 9839 payment being a download of Visa Cash e-cash in dollars. 9841 o foreign exchange using the same payment method. For example the payment 9842 could be an upload of Mondex value in British Pounds and the second a 9843 download of Mondex value in Euros 9845 o foreign exchange using different payment methods. For example the first 9846 payment could be a SET payment in Canadian Dollars followed a download 9847 of GeldKarte in Deutchmarks. 9849 The Baseline Value Exchange uses the following Document Exchanges: 9851 o an optional Authentication Document Exchange (see section 9.1.1) 9853 o an Offer Document Exchange (see section 9.1.2), which provides details 9854 of what values and currencies will be exchanged, and 9856 o two Payment Document Exchanges (see section 9.1.3) which carry out the 9857 two payments involved. 9859 The way in which these Document Exchanges may be combined together is 9860 illustrated by the diagram below. 9861 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9863 START ----------------------------------------------------- 9864 | v 9865 | ---------------- 9866 | | AUTHENTICATION | 9867 | ---------------- 9868 -------------------------------------- | 9869 | | | 9870 | -------------- | ------------- 9871 v v v v 9872 ------------------- ----------------- 9873 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9874 | OFFER | | OFFER | 9875 ------------------- ----------------- 9876 | | 9877 | | 9878 | | 9879 | ------------------- 9880 v v 9881 --------- -------------- 9882 | PAYMENT | | PAYMENT WITH | 9883 | (first) | | DELIVERY | 9884 --------- -------------- 9885 | 9886 ---- 9887 v 9888 ---------- --------- 9889 | DELIVERY | | PAYMENT | 9890 | | | {second)| 9891 ---------- --------- 9892 | 9893 -----------------------------> STOP 9895 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9897 Figure 29 Baseline Value Exchange IOTP Transaction 9899 The Baseline Value Exchange IOTP Transaction occurs in two basic forms: 9901 o Brand Dependent Value Exchange. Where the content of the offer, for 9902 example the rate at which one form of value is exchanged for another, 9903 is dependent on the payment brands and protocols selected by the 9904 consumer, and 9906 o Brand Independent Value Exchange. Where the content of the offer is not 9907 dependent on the payment brands and protocols selected. 9909 [Note] In the above the role is a Merchant even though the 9910 Organisation carrying out the Value Exchange may be a Bank or 9911 some other Financial Institution. This is because the Bank is 9912 acting as a merchant in that they are making an offer which 9913 the Consumer can either accept or decline. 9914 [Note End] 9916 The TPO Block and Offer Response Block may only be combined into the same 9917 IOTP Message if the content of the Offer Response Block does not change 9918 as a result of selecting the payment brands and payment protocols to be 9919 used in the Value Exchange. 9921 BASELINE VALUE EXCHANGE SIGNATURES 9923 The use of signatures to ensure the integrity of a Baseline Value 9924 Exchange is illustrated by the diagram below. 9926 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9928 Signature generated IotpMsg (TPO) 9929 by Merchant ensures - Trans Ref Block 9930 integrity of the Offer --------> - - Signature Block 9931 | - TPO Block MERCHANT 9932 | - Offer Response Block 9933 | 9934 Signature generated by | 9935 the Payment Handler of | IotpMsg (Pay Resp 1) 9936 the first payment binds | - Trans Ref Block PAYMENT 9937 Pay Receipt for the first -----> -> - Signature Block ----- HANDLER 9938 payment to the Offer - Pay Response Block 1 | 1 9939 | 9940 Signature generated by | 9941 the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT 9942 the second payment binds - Trans Ref Block | HANDLER 9943 the second payment to the -----> - Signature Block <------ 2 9944 first payment and therefore - Pay Response Block 2 9945 to the Offer 9947 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9949 Figure 30 Baseline Value Exchange Signatures 9951 9.1.12 Valid Combinations of Document Exchanges 9953 The following diagram illustrates the data conditions in the various IOTP 9954 messages which can be used by a Consumer Trading Role to determine 9955 whether the combination of Document Exchanges are valid. 9956 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9958 START 9959 | 9960 v 9961 Auth Request Block in =TRUE 9962 first IOTP Message ? --------------------------------------- 9963 | = FALSE | 9964 v v 9965 Offer Response Block in ---------------- 9966 first IOTP Message ? | AUTHENTICATION | 9967 |=TRUE |=FALSE ---------------- 9968 | | | 9969 | | v 9970 | ---------------------- TPO & Offer Response 9971 ------------- | Blocks in last IOTP Msg 9972 | | |=TRUE |=FALSE 9973 | | | v 9974 | ------------- | ---- TPO Block only if 9975 | | | last IOTP Message 9976 | | | of Authentication 9977 | | | |=TRUE |=FALSE 9978 v v v v | 9979 ------------------- ----------------- | 9980 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9981 | OFFER | | OFFER | | 9982 ------------------- ----------------- | 9983 | | | 9984 v v | 9985 Offer Response Block contains | 9986 Delivery Component ? | 9987 |=FALSE |=TRUE | 9988 --- v | 9989 | Value of DelivAndPayResp | 9990 | attribute of Delivery Component ? | 9991 | |=FALSE |=TRUE | 9992 | | | | 9993 v v v | 9994 --------- -------------- | 9995 | PAYMENT | | PAYMENT WITH | | 9996 | (first) | | DELIVERY | | 9997 --------- -------------- | 9998 | | | 9999 v | | 10000 Offer and Response Block contains -------------->| 10001 Delivery Component ? | 10002 |=TRUE |=FALSE | 10003 | v | 10004 | Two Payment Components | 10005 | present in Offer Response Block? | 10006 | |=TRUE |=FALSE | 10007 v v | | 10008 ---------- --------- | | 10009 | DELIVERY | | PAYMENT | | | 10010 | | | {second)| | | 10011 ---------- --------- | | 10012 | | | v 10013 ----------------------------------------------> STOP 10015 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10017 Figure 31 Valid Combinations of Document Exchanges 10019 1) 10020 If first IOTP Message of an IOTP Transaction contains an Authentication 10021 Request then: 10023 a) IOTP Transaction includes an Authentication Document Exchange (see 10024 section 9.1.1). (Note 1) 10026 b) If the last IOTP Message of the Authentication Document Exchange 10027 includes a TPO Block and an Offer Response Block then: 10029 i) IOTP Transaction includes a Brand Independent Offer Document 10030 Exchange (see section 9.1.2.2). (Note 2) 10032 c) Otherwise, if the last IOTP Message of the Authentication Exchange 10033 includes a TPO Block but NO Offer Response Block, then: 10035 i) IOTP Transaction includes a Brand Dependent Offer Document Exchange 10036 (see section 9.1.2.1). (Note 2) 10038 d) Otherwise (Authentication Status IOTP Message of the Authentication 10039 Document Exchange contains neither a TPO Block but nor an Offer 10040 Response Block) 10042 i) IOTP Transaction consists of just an Authentication Document 10043 Exchange. (Note 3) 10045 2) 10046 Otherwise (no Authentication Request in first IOTP Message): 10048 e) IOTP Transaction does not include an Authentication Document Exchange 10049 (Note 2) 10051 f) If first IOTP Message contains an Offer Response Block, then: 10053 i) the IOTP Transaction contains a Brand Independent Offer Document 10054 Exchange (Note 2) 10056 g) Otherwise (no Offer Response Block in first IOTP Message): 10058 i) the IOTP Transaction includes a Brand Dependent Offer Document 10059 Exchange (Note 2) 10061 3) 10062 If an Offer Response Block exists in any IOTP message then: 10064 h) If the Offer Response Block contains a Delivery Component then: 10066 i) If the DelivAndPayResp attribute of the Delivery Component is set 10067 to True, then: 10069 (1) the IOTP Transaction consists of a Payment And Delivery 10070 Document Exchange (see section 9.1.5) (Note 4) 10072 ii) otherwise (the DelivAndPayResp attribute of the Delivery 10073 Component is set to False) 10075 (1) the IOTP Transaction consists of a Payment Document Exchange 10076 (see section 9.1.3) followed by a Delivery Document Exchange 10077 (see section 9.1.4) (Note 4) 10079 i) otherwise (the Offer Response Block does not contain a Delivery 10080 Component) 10082 i) if the Offer Response Block contains just one Payment Component, 10083 then: 10085 (1) the IOTP Transaction contains just one Payment Document 10086 Exchange (Note 5) 10088 ii) if the Offer Response Block contains two Payment Components, 10089 then: 10091 (1) the IOTP Transaction contains two Payment Document Exchanges. 10092 The StartAfter attribute of the Payment Components is used to 10093 indicate which payment occurs first (Note 6) 10095 iii) if the Offer Response Block contains no or more than two 10096 Payment Components, then there is an error 10098 4) 10099 Otherwise (no Offer Response Block) there is an error. 10101 The following table indicates the types of IOTP Transactions which can 10102 validly have the conditions indicated above. 10104 Note IOTP Transaction Validity 10106 1. Any Payment and Authentication IOTP Transaction 10108 2. Any Payment and Authentication IOTP Transaction except Baseline 10109 Authentication 10111 3. Either Baseline Authentication, or a Baseline Purchase, Refund, 10112 Deposit, Withdrawal or Value Exchange with a failed 10113 Authentication 10115 4. Baseline Purchase only 10117 5. Baseline Purchase, Refund, Deposit or Withdrawal 10119 6. Baseline Value Exchange only 10121 9.1.13 Combining Authentication Transactions with other Transactions 10123 In the previous sections an Authentication Document Exchange is shown 10124 preceding an Offer Document Exchange as part of a single IOTP Transaction 10125 with the same IOTP Transaction Id. 10127 It is also possible to run a separate Authentication Transaction at any 10128 point, even in parallel with another IOTP Transaction. Typically this 10129 will be used: 10131 o by a Consumer to authenticate a Merchant, Payment Handler or a Delivery 10132 Handler, or 10134 o by a Payment Handler or Delivery Handler to authenticate a Consumer. 10136 In outline the basic process consists of: 10138 o the Trading Role that decides it wants to carry out an authentication 10139 of another role suspends the current IOTP transaction being carried out 10141 o a stand-alone Authentication transaction is then carried out. This may, 10142 at implementer's option, be linked to the original IOTP Transaction 10143 using a Related To Component (see section 3.3.3) in the Transaction 10144 Reference Block. 10146 o if the Authentication transaction is successful, then the original IOTP 10147 Transaction is restarted 10149 o if the Authentication fails then the original IOTP Transaction is 10150 cancelled. 10152 For example, a Consumer could: 10154 o authenticate the Payment Handler for a Payment between receiving an 10155 Offer Response from a Merchant and before sending the Payment Request 10156 to that Payment Handler 10158 o authenticate a Delivery Handler for a Delivery between receiving the 10159 Payment Response from a Payment Handler and before sending the Delivery 10160 Request 10162 A Payment Handler could authenticate a Consumer after receiving the 10163 Payment Request and before sending the next Payment related message. 10165 A Delivery Handler could authenticate a Consumer after receiving the 10166 Delivery Request and before sending the Delivery Response. 10168 [Note] Some Payment Methods may carry out an authentication within 10169 the Payment Exchange. In this case the information required to 10170 carry out the authentication will be included in Payment 10171 Scheme Components. 10173 In this instance IOTP aware application will not be aware that 10174 an authentication has occurred since the Payment Scheme 10175 Components that contain authentication request information 10176 will be indistinguishable from other Payment Scheme 10177 Components. 10178 [Note End] 10180 9.2 Infrastructure Transactions 10182 Infrastructure Transactions are designed to support inquiries about 10183 whether or not a transaction has succeeded or a Trading Role's servers 10184 are operating correctly. There are two types of transaction: 10186 o a Transaction Status Inquiry Transaction which provides information on 10187 the status of an existing or complete IOTP transaction, and 10189 o Ping Transaction that enables one IOTP aware application to determine 10190 if the IOTP aware application at another Trading Role is operating and 10191 verify whether or not signatures can be handled. 10193 Each of these is described below 10195 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 10197 The Baseline IOTP Transaction Status Inquiry provides information on the 10198 status of an existing or complete IOTP transaction. 10200 The Trading Blocks used by the Baseline Transaction Status Inquiry 10201 Transaction are: 10203 o an Inquiry Request Trading Block (see section 8.12), 10205 o an Inquiry Response Trading Block (see section 8.13) 10207 o an optional Signature Block (see section 8.16). 10209 The Inquiry IOTP Transaction can be used for a variety of reasons. For 10210 example: 10212 o to help in resuming a suspended transaction to determine the current 10213 state of processing of one of the other roles, 10215 o for a merchant to determine if a payment, delivery, etc. was completed. 10216 For example, a Consumer might claim that payment was made but no signed 10217 IOTP payment receipt was available to prove it. If the Merchant makes 10218 an inquiry of the Payment Handler then the Merchant can determine 10219 whether or not payment was made. 10221 [Note] Inquiries on Baseline Ping IOTP Transactions (see section 10222 9.2.2) are ignored. 10223 [Note End] 10225 MAKING INQUIRIES OF ANOTHER TRADING ROLE 10227 One Trading Role may make an inquiry of any other Trading Role at any 10228 point in time. 10230 IOTP aware software that supports the Consumer Trading Role may not: 10232 o digitally sign a response if requested, since it may not have the 10233 capability, or 10235 o respond to an Inquiry Request at all since it may not be on-line, or 10236 may consider that the request is not reasonable since, for example, the 10237 Request was not digitally signed. 10239 As a guideline: 10241 o the Consumer should send a Transaction Status Inquiry Block to a 10242 Trading Role only after the following events have occurred: 10243 - to the Merchant, after sending a TPO Selection Block, 10244 - to the Payment Handler, after sending a Payment Request Block, 10245 - to the Delivery Handler, after sending a Delivery Request Block, 10247 o other Trading Roles should send a Transaction Status Inquiry Block to 10248 the Consumer only after receiving a message from the Consumer and 10249 before sending the final "Response" message to the Consumer 10251 o there are no restrictions on non-Consumer Trading Roles sending 10252 Inquiries to other trading roles. 10254 TRANSACTION STATUS INQUIRY TRANSPORT SESSION 10256 For a Transaction Status Inquiry on an ongoing transaction a different 10257 transport session from the ongoing transaction is used. For a Transaction 10258 Status Inquiry on a past transaction, how the IOTP module on the software 10259 at the Trading Role is started upon the receipt of Inquiry Request 10260 message is defined in each Mapping to Transport supplement for IOTP. 10262 TRANSACTION STATUS INQUIRY ERROR HANDLING 10264 Errors in a Transaction Status Inquiry can be categorised into one of the 10265 following three cases: 10267 o Business errors (see section 4.2) in the original (inquired) messages 10269 o Technical errors (see section 4.1) - both IOTP and payment scheme 10270 specific ones - in the original IOTP (inquired) messages 10272 o Technical errors in the message containing the Inquiry Request Block 10273 itself 10275 The following outlines what the software should do in each case 10277 BUSINESS ERRORS IN THE ORIGINAL MESSAGES 10279 Return an Inquiry Response Block containing the Status Component which 10280 was last sent to the Consumer Role. 10282 TECHNICAL ERRORS IN THE ORIGINAL MESSAGES 10284 Return an Inquiry Response Block containing a Status Component. The 10285 Status Component should contain a ProcessState attribute set to 10286 ProcessError. In this case send back an Error Block indicating where the 10287 error was found in the original message. 10289 TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK 10291 Return an Error message. That is, send back an Error Block containing the 10292 Error Code (see section 7.21.2) which describes the nature of the error 10293 in the Inquiry Request message. 10295 INQUIRY TRANSACTION MESSAGES 10297 The following Figure outlines the Baseline IOTP Transaction Status 10298 Inquiry process. 10300 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10301 1st Role 10302 | 2nd Role 10303 STEP | | 10304 1. The first role decides to inquire on an IOTP Transaction by, 10305 for example, clicking on the inquiry button of an IOTP Aware 10306 Application. This will then generate an Inquiry Request Block 10307 and send it to the appropriate Trading Role. 10309 1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block 10310 (optional); Inquiry Request Block 10312 2. The Trading Role checks the digital signature (if present). 10313 If the recipient wants to respond, then the Trading Role 10314 checks the transaction status of the transaction that is 10315 being inquired upon by using the IotpTransId in the 10316 Transaction ID Component of the Transaction Reference Block, 10317 then generates the appropriate Inquiry Response Block, sends 10318 the message back to the 1st Role and stops 10320 1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry Response 10321 Block; Signature Block (Optional) 10323 3. First role checks the Inquiry Response Block and optional 10324 signature, takes whatever action is appropriate or perhaps 10325 stops. This may include displaying status information to the 10326 end user. 10328 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10330 Figure 32 Baseline Transaction Status Inquiry 10332 The remainder of this sub-section on the Baseline Transaction Status 10333 Inquiry IOTP Transaction defines the contents of each Trading Block. Note 10334 that the term "original transaction" is the transaction which a trading 10335 role wants to discover some information about. 10337 TRANSACTION REFERENCE BLOCK 10339 A Trading Role making an inquiry must use the identical Transaction Id 10340 Component (see section 3.3.1) that was in the original transaction. The 10341 IotpTransId attribute in this component serves as the key in querying the 10342 transaction logs maintained at the Trading Role's site. The value of the 10343 ID attribute of the Message Id Component should be different from those 10344 of any in the original transaction (see section 3.4.1). 10346 If up-to-date status information is required then the MsgId Component, 10347 and in particular the ID attribute for the MsgId Component must be 10348 different from any other IOTP Message that has been sent by the Trading 10349 Role. This is required because of the way that Idempotency is handled by 10350 IOTP (see section 4.5.2.2 Checking/Handling Duplicate Messages). 10352 INQUIRY REQUEST BLOCK 10354 The Inquiry Request Block (see section 8.12) contains the following 10355 components: 10357 o one Inquiry Type Component (see section 7.18). This identifies whether 10358 the inquiry is on an offer, payment, or delivery. 10360 o zero or one Payment Scheme Components (see section 7.10). This is for 10361 encapsulating payment scheme specific inquiry messages for inquiries on 10362 a payment. 10364 SIGNATURE BLOCK (INQUIRY REQUEST) 10366 If a signature block is present on the message containing the Inquiry 10367 Request Block then it may be checked to determine if the Inquiry Request 10368 is authorised. 10370 If present, the Inquiry Request Signature Block (see section 8.12) 10371 contains the following components: 10373 o one Signature Component (see section 7.19) 10375 o one or more Certificate Components, if required. 10377 Inquiry Response Blocks should only be generated if the Transaction is 10378 authorised. 10380 [Note] Digital signatures on an Inquiry Request is only likely to 10381 occur if the recipient of the request expects the Inquiry 10382 Request to be signed. In this version of IOTP this will 10383 require some kind of pre-existing agreement. This means that: 10384 o Consumers are unlikely to generate requests with signatures, 10385 although it is not an error if they do 10386 o the other trading roles may agree that digital signatures 10387 are required. For example a Payment Handler may require that 10388 an Inquiry Request is digitally signed by the Merchant so 10389 that they can check that the request is valid. 10391 On the other hand if the original transaction to which the 10392 Inquiry relates was carried out over a secure channel (e.g. 10393 [SSL]) then it is probably reasonable to presume that if the 10394 sender of the Inquiry knows the Transaction Id component of 10395 the original message (including for example the timestamp) 10396 then the inquiry is likely to be genuine. 10397 [Note End] 10399 INQUIRY RESPONSE BLOCK 10401 The Inquiry Response Block (see section 8.13) contains the following 10402 components: 10404 o one Status Component (see section 7.16). This component holds the 10405 status information on the inquired transaction, 10407 o zero or one Payment Scheme Components. These contain encapsulated 10408 payment scheme specific inquiry messages for inquiries on payment. 10410 SIGNATURE BLOCK (INQUIRY RESPONSE) 10412 If a signature block is present on the message containing the Inquiry 10413 Response Block then it may be checked by the receiver of the block to 10414 determine if the Inquiry Response is valid. 10416 If present, the Inquiry Response Signature Block (see section 8.13) 10417 contains the following components: 10419 o one Signature Component (see section 7.19) 10421 o one or more Certificate Components, if required. 10423 [Note] Digital signatures on an Inquiry Response is only likely to 10424 occur if the recipient of the response expects the Inquiry 10425 Request to be signed. In this version of IOTP this will 10426 require some kind of pre-existing agreement. This means that: 10427 o Consumers are unlikely to generate responses with 10428 signatures, although it is not an error if they do 10429 o the other trading roles may agree that digital signatures 10430 are required. For example a Merchant may require that an 10431 Inquiry Response is digitally signed by the Payment Handler 10432 so that they can check that the request response is valid. 10433 [Note End] 10435 9.2.2 Baseline Ping IOTP Transaction 10437 The purpose of the Baseline IOTP Ping Transaction is to test basic 10438 connectivity between the Trading Roles that may take part in an IOTP 10439 Transaction. 10441 It enables IOTP aware application software to: 10443 o determine if the IOTP aware application at another Trading Role is 10444 operating, and 10446 o verify whether or not the two trading roles signatures can be 10447 processed. 10449 For example it can be used by a Merchant to determine if a Payment 10450 Handler or Delivery Handler is up and running prior to starting a 10451 Purchase transaction that uses those trading roles. 10453 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 10455 o a Ping Request Block (see section 8.14) 10457 o a Ping Response Block (see section 8.15), and 10459 o a Signature Block (see section 8.16). 10461 PING MESSAGES 10463 The following figure outlines the message flows in the Baseline IOTP Ping 10464 Transaction. 10466 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10467 1st Role 10468 | 2nd Role 10469 STEP | | 10470 1. The IOTP Aware Application in the first Trading Role decides 10471 to check whether the counterparty IOTP application is up and 10472 running. It generates a Ping Request Block and optional 10473 Signature Block and sends them to the second trading role. 10475 1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block 10476 (Optional); Ping Request Block 10478 2. The second Trading Role which receives the Ping Request Block 10479 generates a Ping Response Block and sends it back to the 10480 sender of the original Ping Request with a signature block if 10481 required. 10483 1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block 10484 (Optional); Ping Response Block 10486 3. The first Trading Role checks the Ping Response Block and 10487 takes appropriate action, if necessary 10489 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10491 Figure 33 Baseline Ping Messages 10493 The verification that signatures can be handled is indicated by the 10494 sender of the Ping Request Block including: 10496 o Organisation Components that identify itself and the intended recipient 10497 of the Ping Request Block, and 10499 o a Signature Block that signs data in the Ping Request. 10501 In this way the receiver of the Ping Request: 10503 o knows who is sending the Ping Request and can therefore verify the 10504 Signature on the Request, and 10506 o knows who to generate a signature for on the Ping Response. 10508 Note that a Ping Request: 10510 o does not affect any on-going transaction 10512 o does NOT initiate an IOTP transaction, unlike other IOTP transaction 10513 messages such as TPO or Transaction Status Inquiry. 10515 All IOTP aware applications must return a Ping Response message to the 10516 sender of a Ping Request message when it is received. 10518 A Baseline IOTP Ping request can also contain an optional Signature 10519 Block. IOTP aware applications can, for example, use the Signature Block 10520 to check the recipient of a Ping Request can successfully process and 10521 check signatures it has received. 10523 For each Baseline Ping IOTP Transaction, each IOTP role shall establish a 10524 different transport session from other IOTP transactions. 10526 Any IOTP Trading Role can send a Ping request to any other IOTP Trading 10527 Role at any time it wants. A Ping message has its own IotpTransId, which 10528 is different from other IOTP transactions. 10530 The remainder of this sub-section on the Baseline Ping IOTP Transaction 10531 defines the contents of each Trading Block. 10533 TRANSACTION REFERENCE BLOCK 10535 The IotpTransId of a Ping transaction should be different from any other 10536 IOTP transaction. 10538 PING REQUEST BLOCK 10540 If the Ping Transaction is anonymous then no Organisation Components are 10541 included in the Ping Request Block (see section 8.7). 10543 If the Ping Transaction is not anonymous then the Ping Request Block 10544 contains Organisation Components for: 10546 o the sender of the Ping Request Block, and 10548 o the verifier of the Signature Component 10550 If Organisation Components are present, then it indicates that the sender 10551 of the Ping Request message has generated a Signature Block. The 10552 signature block must be verified by the Trading Role that receives the 10553 Ping Request Block. 10555 SIGNATURE BLOCK (PING REQUEST) 10557 The Ping Request Signature Block (see section 8.16) contains the 10558 following components: 10560 o one Signature Component (see section 7.19) 10562 o one or more Certificate Components, if required. 10564 PING RESPONSE BLOCK 10566 The Ping Response Block (see section 8.15) contains the following 10567 component: 10569 o the Organisation Component of the sender of the Ping Response message 10571 If the Ping Transaction is not anonymous then the Ping Response 10572 additionally contains: 10574 o copies of the Organisation Components contained in the Ping Request 10575 Block. 10577 SIGNATURE BLOCK (PING RESPONSE) 10579 The Ping Response Signature Block (see section 8.16) contains the 10580 following components: 10582 o one Signature Component (see section 7.19) 10584 o one or more Certificate Components, if required. 10586 10. Retrieving Logos 10588 This section describes how to retrieve logos for display by IOTP aware 10589 software using the Logo Net Locations attribute contained in the Brand 10590 Element (see section 7.7.1) and the Organisation Component (see section 10591 7.6). 10593 The full address of a logo is defined as follows: 10594 Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif" 10596 Where: 10598 o Logo_net_location is obtained from the LogoNetLocn attribute in the 10599 Brand Element (see section 7.7.1) or the Organisation Component. Note 10600 that: 10601 - the content of this attribute is dependent on the Transport Mechanism 10602 (such as HTTP) that is used. See the Transport Mechanism supplement, 10603 - implementers should check that if the rightmost character of Logo Net 10604 Location is set to right-slash "/" then another, right slash should 10605 not be included when generating the Logo Address, 10607 o Logo_size identifies the size of the logo, 10609 o Logo_color_depth identifies the colour depth of the logo 10611 o "gif" indicates that the logos are in "gif@ format 10613 Logo_size and Logo_color_depth are specified by the implementer of the 10614 IOTP software that is retrieving the logo depending on the size and 10615 colour that they want to use. 10617 10.1 Logo Size 10619 There are five standard sizes for logos. The sizes in pixels and the 10620 corresponding values for Logo Size are given in the table below. 10622 Size in Logo Size 10623 Pixels Value 10625 32 x 32 or exsmall 10626 32 x 20 10628 53 x 33 small 10630 103 x 65 medium 10632 180 x 114 large 10634 263 x 166 exlarge 10636 10.2 Logo Color Depth 10638 There are three standard colour depths. The colour depth (including bits 10639 per pixel) and the corresponding value for Logo_Color_Depth are given in 10640 the table below. 10642 Color Depth Logo Color 10643 (bits per pixel) Depth Value 10645 4 (16 colors) 4 10647 8 (256 colors) nothing 10649 24 (16 million colors) 24 10651 Note that if Logo Color Depth is omitted then a logo with the default 10652 colour depth of 256 colours will be retrieved. 10654 10.3 Logo Net Location Examples 10656 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 10658 o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 10659 colour logo 10661 o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16 10662 colour logo 10664 [Note] Organisations which make logos available for use with IOTP 10665 should always make available "small" and "medium" size logos 10666 and use the "gif" format. 10667 [Note End] 10669 11. Brands 10671 This section contains: 10673 o a definition of Brands and an outline of Brand Selection using Brand 10674 Lists, and 10676 o some XML examples of Brand Lists 10678 11.1 Brand Definitions and Brand Selection 10680 One of the key features of IOTP is the ability for a merchant to offer a 10681 list of Brands from which a consumer may make a selection. This section 10682 provides an overview of what is involved and provides guidance on how 10683 selection of a brand and associated payment instrument can be carried out 10684 by a Consumer. It covers: 10686 o definitions of Payment Instruments and Brands - what are Payment 10687 Instruments and Brands in an IOTP context. Further categorises Brands 10688 as optionally a "Dual Brand" or a "Promotional Brand", 10690 o identification and selection of Promotional Brands - Promotional Brands 10691 offer a Consumer some additional benefit, for example loyalty points or 10692 a discount. This means that both Consumers and Merchant must be able to 10693 correctly identify that a valid Promotional Brand is being used. 10695 Also see the following sections: 10697 o Brand List Component (section 7.7) which contains definitions of the 10698 XML elements which contain the list of Brands offered by a Merchant to 10699 a Consumer, and 10701 o Brand Selection Component (section 7.8) for details of how a Consumer 10702 records the Brand, currency, amount and payment protocol that was 10703 selected. 10705 11.1.1 Definition of Payment Instrument 10707 A Payment Instrument is the means by which a Consumer pays for goods or 10708 services offered by a Merchant. It can be, for example: 10710 o a credit card such as MasterCard or Visa; 10712 o a debit card such as MasterCard's Maestro; 10714 o a smart card based electronic cash payment instrument such as a Mondex 10715 Card, a GeldKarte card or a Visa Cash card 10717 o a software based electronic payment account such as a CyberCash or 10718 DigiCash account. 10720 Most Payment Instruments have a number, typically an account number, by 10721 which the Payment Instrument can be identified. 10723 11.1.2 Definition of Brand 10725 A Brand is the mark which identifies a particular type of Payment 10726 Instrument. A list of Brands are the payment options which are presented 10727 by the Merchant to the Consumer and from which the Consumer makes a 10728 selection. Each Brand may have a different Payment Handler. Examples of 10729 Brands include: 10731 o payment association and proprietary Brands, for example MasterCard, 10732 Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. 10734 o promotional brands (see below). These include: 10735 - store brands, where the Payment Instrument is issued to a Consumer by 10736 a particular Merchant, for example Walmart, Sears, or Marks and 10737 Spencer (UK) 10738 - cobrands, for example American Advantage Visa, where an Organisation 10739 uses their own brand in conjunction with, typically, a payment 10740 association Brand. 10742 11.1.3 Definition of Dual Brand 10744 A Dual Brand means that a single payment instrument may be used as if it 10745 were two separate Brands. For example there could be a single Japanese 10746 "UC" MasterCard which can be used as either a UC card or a regular 10747 MasterCard. The UC card Brand and the MasterCard Brand could each have 10748 their own separate Payment Handlers. This means that: 10750 o the merchant treats, for example "UC" and "MasterCard" as two separate 10751 Brands when offering a list of Brands to the Consumer, 10753 o the consumer chooses a Brand, for example either "UC" or "MasterCard, 10755 o the consumer IOTP aware application determines which Payment 10756 Instrument(s) match the chosen Brand, and selects, perhaps with user 10757 assistance, the correct Payment Instrument to use. 10759 [Note] Dual Brands need no special treatment by the Merchant and 10760 therefore no explicit reference is made to Dual Brands in the 10761 DTD. This is because, as far as the Merchant is concerned, 10762 each Brand in a Dual Brand is treated as a separate Brand. It 10763 is at the Consumer, that the matching of a Brand to a Dual 10764 Brand Payment Instrument needs to be done. 10765 [Note End] 10767 11.1.4 Definition of Promotional Brand 10769 A Promotional Brand means that, if the Consumer pays with that Brand, 10770 then the Consumer will receive some additional benefit which can be 10771 received in two ways: 10773 o at the time of purchase. For example if a Consumer pays with a "Walmart 10774 MasterCard" at a Walmart web site, then a 5% discount might apply, 10775 which means the consumer actually pays less, 10777 o from their Payment Instrument (card) issuer when the payment appears on 10778 their statement. For example loyalty points in a frequent flyer scheme 10779 could be awarded based on the total payments made with the Payment 10780 Instrument since the last statement was issued. 10782 Note that: 10784 o the first example (obtaining the benefit at the time of purchase), 10785 requires that: 10786 - the Consumer is informed of the benefits which arise if that Brand is 10787 selected 10788 - if the Brand is selected, the Merchant changes the relevant IOTP 10789 Components in the Offer Response to reflect the correct amount to be 10790 paid 10792 o the second (obtaining a benefit through the Payment Instrument issuer) 10793 does not require that the Offer Response is changed 10795 o each Promotional Brand should be identified as a separate Brand in the 10796 list of Brands offered by the Merchant. For example: "Walmart", 10797 "Sears", "Marks and Spencer" and "American Advantage Visa", would each 10798 be a separate Brand. 10800 11.1.5 Identifying Promotional Brands 10802 There are two problems which need to handled in identifying Promotional 10803 Brands: 10805 o how does the Merchant or their Payment Handler positively identify the 10806 promotional brand being used at the time of purchase 10808 o how does the Consumer reliably identify the correct promotional brand 10809 from the Brand List presented by the Merchant 10811 The following is a description of how this could be achieved. 10813 [Note] Please note that the approach described here is a model 10814 approach that solves the problem. Other equivalent methods may 10815 be used. 10816 [Note End] 10818 11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands 10820 Correct identification that the Consumer is paying using a Promotional 10821 Brand is important since a Consumer might fraudulently claim to have a 10822 Promotional Brand that offers a reduced payment amount when in reality 10823 they do not. 10825 Two approaches seem possible: 10827 o use some feature of the Payment Instrument or the payment method to 10828 positively identify the Brand being used. For example, the SET 10829 certificate for the Brand could be used, if one is available, or 10831 o use the Payment Instrument (card) number to look up information about 10832 the Payment Instrument on a Payment Instrument issuer database to 10833 determine if the Payment Instrument is a promotional brand. 10835 Note that: 10837 o the first assumes that SET is available. 10839 o the second is only possible if the Merchant, or alternatively the 10840 Payment Handler, has access to card issuer information. 10842 IOTP does not provide the Merchant with Payment Instrument information 10843 (e.g. a card or account number). This is only sent as part of the 10844 encapsulated payment protocol to a Payment Handler. This means that: 10846 o the Merchant would have to assume that the Payment Instrument selected 10847 was a valid Promotional Brand, or 10849 o the Payment Handler would have to check that the Payment Instrument was 10850 for the valid Promotional Brand and fail the payment if it was not. 10852 A Payment Handler checking that a brand is a valid Promotional Brand is 10853 most likely if the Payment Handler is also the Card Issuer. 10855 11.1.5.2 Consumer Selection of Promotional Brands 10857 Two ways by which a Consumer can correctly select a Promotional Brand 10858 are: 10860 o the Consumer visually matching a logo for the Promotional Brand which 10861 has been provided to the Consumer by the Merchant, 10863 o the Consumer's IOTP aware application matching a code for the 10864 Promotional Brand which the application has registered against a 10865 similar code contained in the list of Brands offered by the Merchant. 10867 In the latter case, the code contained in the Consumer wallet must match 10868 exactly the code in the list offered by the Merchant otherwise no match 10869 will be found. Ways in which the Consumer's IOTP Aware Application could 10870 obtain such a code include: 10872 o the Consumer types the code in directly. This is error prone and not 10873 user friendly, also the consumer needs to be provided with the code. 10874 This approach is not recommended, 10876 o using one of the Brand Identifiers defined by IOTP and pre-loaded into 10877 the Consumers IOTP Aware application or wallet by the developer of the 10878 Wallet, 10880 o using some information contained in the software or other data 10881 associated with the Payment Instrument. This could be: 10882 - a SET certificate for Brands which use this payment method 10883 - a code provided by the payment software which handles the particular 10884 payment method, this could apply to, for example, GeldKarte, Mondex, 10885 CyberCash and DigiCash, 10887 o the consumer making an initial "manual" link between a Promotional 10888 Brand in the list of Brands offered by the Merchant and an individual 10889 Payment Instrument, the first time the promotional brand is used. The 10890 IOTP Aware application would then "remember" the code for the 10891 Promotional Brand for use in future purchases. 10893 11.1.5.3 Consumer Software Brand Id recommendation 10895 New Brand Ids are allocated under IANA procedures (see section 12 IANA 10896 Considerations). Which also contains an initial list of Brand 10897 Identifiers. 10899 It is recommended that implementers of consumer IOTP aware applications 10900 (e.g. software wallets) pre-load their software with the then current set 10901 of Brand Ids and provide a method by which they can be updated. For 10902 example, by going to the software developer's web site. 10904 11.2 Brand List Examples 10906 This example contains three examples of the XML for a Brand List 10907 Component. It covers: 10909 o a simple credit card based example 10911 o a credit card based brand list including promotional credit card 10912 brands, and 10914 o a complex electronic cash based brand list 10916 Note that: 10918 o brand lists can be as complex or as simple as required 10920 o all example techniques described in this appendix can be included in 10921 one brand list. 10923 11.2.1 Simple Credit Card Based Example 10925 This is a simple example involving: 10927 o only major credit card payment brands 10929 o a single price in a single currency 10931 o a single Payment Handler, and 10933 o a single payment protocol 10935 10939 10944 10945 10950 10951 10956 10957 10960 10961 10964 10968 10969 10971 11.2.2 Credit Card Brand List Including Promotional Brands 10973 An example of a Credit Card based Brand List follows. It includes: 10975 o two ordinary card association brands and two promotional credit card 10976 brands. The promotional brands consist of one loyalty based (British 10977 Airways MasterCard) which offers additional loyalty points and one 10978 store based (Walmart) which offers a discount on purchases over a 10979 certain amount 10981 o two payment protocols: 10982 - SET (Secure Electronic Transactions) see [SET], and 10983 - SCCD (Secure Channel Credit Debit) see [SCCD]. 10985 10989 10994 10995 10996 10997 11002 11003 11004 11005 11011 11012 11013 11014 11021 11022 11025 11026 238djqw1298erh18dhoire 11027 11028 11029 11032 11033 238djqw1298erh18dhoire 11034 11035 11036 11039 11043 11044 8ueu26e482hd82he82 11045 11046 11047 11051 11052 82hd82he8226e48ueu 11053 11054 11055 11057 11.2.3 Brand Selection Example 11059 In order to pay by 'British Airways' MasterCard using the example above 11060 using SET and therefore getting double air miles, the Brand Selection 11061 would be: 11063 11068 11070 11.2.4 Complex Electronic Cash Based Brand List 11072 The following is an fairly complex example which includes: 11074 o payments using either Mondex, GeldKarte, CyberCash or DigiCash 11075 o in currencies including US dollars, British Pounds, Italian Lira, 11076 German Marks and Canadian Dollars 11078 o a discount on the price if the payment is made in Mondex using British 11079 pounds or US dollars, and 11081 o more than one Payment Handler is used for payments involving Mondex or 11082 CyberCash 11084 o support for more than one version of a CyberCash CyberCoin payment 11085 protocol. 11087 11091 11096 11097 11102 11103 11108 11109 11116 11117 11120 11121 11124 11125 11128 11129 11132 11133 11136 11137 11140 11143 11146 11149 11152 11155 11158 11161 11165 11166 11170 11171 11175 11176 11180 11181 11185 11186 11190 11191 11193 12. IANA Considerations 11195 This section describes the codes that are controlled by IANA, and also 11196 how new codes can be created for testing purposes that are not controlled 11197 by IANA. 11199 12.1 Codes Controlled by IANA 11201 To help ensure interoperability, there is a need for codes used by IOTP 11202 to be maintained in a controlled environment so that their meaning and 11203 usage are well defined and duplicate codes avoided. [IANA] is the 11204 mechanism to be used for this purpose as described in RFC 2434. 11206 The element types and attributes names to which this procedure applies is 11207 shown in the table below together with the initial values that are valid 11208 for these attributes. 11210 Note that: 11212 o the IETF Trade mailing list's email address is ietf-trade@elistx.com 11214 o "Designated Experts" (see [IANA]) are appointed by the IESG. 11216 Element Type/ Attribute Values 11217 Attribute Name 11219 Algorithm/ "sha1" - indicates that a [SHA1] authentication 11220 Name will apply 11221 (When Algorithm 11222 is a child of an "signature" - indicates that authentication 11223 AuthReq consists of the generation of a digital signature. 11224 Component) 11225 "Pay:ppp" where "ppp" may be set to any valid 11226 value for "iotpbrand" (see below) 11228 With the exception of Algorithms that begin with 11229 "pay:", new values are allocated following review 11230 on the IETF Trade mailing list and by the 11231 Designated Expert. 11233 [Note] The Algorithm element is likely to be 11234 eventually defined within the [DSIG] 11235 name space. It is likely that the 11236 maintenance procedure defined here 11237 may need to vary over time, as the 11238 DSIG proposals become more widely 11239 adopted. 11240 [Note End] 11242 Element Type/ Attribute Values 11243 Attribute Name 11245 Brand/BrandId The following list of initial BrandIds have been 11246 taken from those Organisations that have applied 11247 for SET certificates as at 1st June 1999: 11249 "Amex" - American Express 11251 "Dankort" - Dankort 11253 "JCB" - JCB 11255 "Maestro" - Maestro 11257 "MasterCard" - MasterCard 11259 "NICOS" - NICOS 11261 "VISA" - Visa 11263 In addition the following Brand Id values are 11264 defined: 11266 "Mondex" 11268 "GeldKarte" 11270 New values of BrandId must be announced to the 11271 IETF Trade mailing list and, if there are no 11272 objections within three weeks, are allocated on a 11273 "first come first served" basis. 11275 CurrencyAmount/ Currency codes are dependent on CurrCodeType (see 11276 CurrCode below). 11278 If CurrCodeType is "ISO4217-A" then the currency 11279 code is an alphabetic currency code as defined by 11280 [ISO4217]. 11282 If CurrCodeType is "IOTP" then new values must be 11283 announced to the IETF Trade mailing list and, if 11284 there are no objections within three weeks, are 11285 allocated on a "first come first served" basis. 11287 [Note] The Currency Code Type of IOTP, is 11288 designed to allow the support of 11289 "new" psuedo currencies such as 11290 loyalty or frequent flyer points. At 11291 the time of writing this 11292 specification, no currency codes of 11293 this type have been defined. 11294 [Note End] 11296 Element Type/ Attribute Values 11297 Attribute Name 11299 CurrencyAmount/ "ISO4217-A" 11300 CurrCodeType 11301 "IOTP" 11303 New values of CurrCodeType attribute are allocated 11304 following review on the IETF Trade mailing list 11305 and by the Designated Expert. 11307 DeliveryData/ "Post" 11308 DelivMethod 11309 "Web" 11311 "Email" 11313 New values of Delivery Method attribute are 11314 allocated following review on the IETF Trade 11315 mailing list and by the Designated Expert. This 11316 may require the publication of additional 11317 documentation to describe how the delivery method 11318 is used. 11320 PackagedContent/ "PCDATA" 11321 Content 11322 "MIME" 11324 "MIME:mimetype" (where mimetype must be the same 11325 as content-type as defined by [MIME] ) 11327 "XML" 11329 If the Content attribute is of the form 11330 "MIME"mimetype", then control of new values for 11331 "mimetype" is as defined in [MIME]. 11333 Otherwise, new values of the Content attribute are 11334 allocated following review on the IETF Trade 11335 mailing list and by the Designated Expert. This 11336 may require the publication of additional 11337 documentation to describe how the new attribute is 11338 used within a Packaged Content element. 11340 RelatedTo/ "IotpTransaction" 11341 RelationshipType 11342 "Reference" 11344 New values of the RelationshipType attribute are 11345 allocated following review on the IETF Trade 11346 Working Group mailing list and by the Designated 11347 Expert. This may require the publication of 11348 additional documentation to describe how the 11350 Element Type/ Attribute Values 11351 Attribute Name 11352 delivery method is used. 11354 Status/ Offer 11355 StatusType 11356 Payment 11358 Delivery 11360 Authentication 11362 Unidentified 11364 New values of the Status Type 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 Status, 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 Status Type attribute may be 11375 combined with documents that describe 11376 new Trading Roles and types of 11377 signatures (see below). 11378 [Note End] 11380 TradingRole/ "Consumer" 11381 TradingRole 11382 "Merchant" 11384 "PaymentHandler" 11386 "DeliveryHandler" 11388 "DelivTo" 11390 "CustCare" 11392 New values of the Trading Role attribute are 11393 allocated following: 11394 o publication to the IETF Trade Working Group, 11395 of an RFC describing the Trading Exchange, 11396 Trading Roles and associated components that 11397 relate to the Trading Role, and 11398 o review of the document on the IETF Trade 11399 mailing list and by the Designated Expert. 11401 [Note] The document describing new values 11402 for the Trading Role attribute may be 11404 Element Type/ Attribute Values 11405 Attribute Name 11406 combined with documents that describe 11407 new Status Types (see above) and 11408 types of signatures (see below). 11409 [Note End] 11411 TransId/ "BaselineAuthentication" 11412 IotpTransType 11413 "BaselineDeposit" 11415 "BaselinePurchase" 11417 "BaselineRefund" 11419 "BaselineWithdrawal" 11421 "BaselineValueExchange" 11423 "BaselineInquiry" 11425 "BaselinePing" 11427 New values of the IotpTransType attribute are 11428 allocated following: 11429 o publication to the IETF Trade mailing list, of 11430 an RFC describing the new IOTP Transaction, and 11431 o review of the document on the IETF Trade 11432 Working Group mailing list and by the 11433 Designated Expert. 11435 Attibute/ Content 11436 (see Signature "OfferResponse" 11437 Component) "PaymentResponse" 11439 "DeliveryResponse" 11441 "AuthenticationRequest" 11443 "AuthenticationResponse" 11445 "PingRequest" 11447 "PingResponse" 11449 New values of the code that define the type of a 11450 signature are allocated following: 11451 o publication to the IETF Trade Working Group, 11452 of an RFC describing the Trading Exchange where 11453 the signature is being used, and 11454 o review of the document on the IETF Trade 11455 mailing list and by the Designated Expert. 11457 Element Type/ Attribute Values 11458 Attribute Name 11460 [Note] The document describing new values 11461 for the types of signatures may be 11462 combined with documents that describe 11463 new Status Types and Trading Roles 11464 (see above). 11465 [Note End] 11467 12.2 Codes not controlled by IANA 11469 In addition to the formal development and registration of codes as 11470 described above, there is still a need for developers to experiment using 11471 new IOTP codes. For this reason, "user defined codes" may be used to 11472 identify additional values for the codes contained within this 11473 specification without the need for them to be registered with IANA. 11475 The definition of a user defined code is as follows: 11477 user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)* 11479 NameChar NameChar has the same definition as the [XML] 11480 definition of NameChar 11482 Use of domain names (see [DNS]) to make user defined codes unique is 11483 recommended although this method cannot be relied upon. 11485 13. Internet Open Trading Protocol Data Type Definition 11487 This section contains the XML DTD for the Internet Open Trading 11488 Protocols. 11490 11524 11546 11550 11556 11557 11560 11561 11568 11569 11579 11580 11587 11593 11594 11599 11604 11605 11606 11614 11615 11616 11621 11622 11623 11629 11630 11631 11635 11636 11637 11647 11648 11650 11658 11659 11667 11668 11675 11676 11683 11684 11694 11695 11697 11703 11704 11714 11715 11719 11720 11726 11727 11733 11734 11744 11745 11748 11755 11756 11760 11761 11765 11766 11770 11771 11772 11780 11781 11782 11789 11790 11791 11797 11798 11799 11803 11804 11805 11812 11813 11823 11824 11825 11829 11830 11831 11837 11838 11839 11850 11851 11852 11857 11858 11859 11865 11866 11867 11876 11877 11885 11891 11892 11893 11896 11897 11898 11901 11902 11904 11907 11908 11909 11912 11913 11914 11917 11918 11919 11922 11923 11925 11928 11929 11930 11933 11934 11936 11939 11940 11942 11945 11946 11947 11950 11951 11952 11955 11956 11957 11962 11963 11964 11967 11968 11969 11976 11977 11978 11981 11982 11983 11986 11992 11993 11997 12003 12004 12008 12017 12021 12022 12027 12028 12032 12033 12038 12039 12043 12044 12051 12052 12056 12057 12061 12067 12071 12076 12077 12083 12088 12089 12094 12095 12100 14. Glossary 12102 This section contains a glossary of some of the terms used within this 12103 specification in alphabetical order. 12105 NAME DESCRIPTION 12107 Authenticator The Organisation which is requesting the 12108 authentication of another Organisation, and 12110 Authenticatee The Organisation being authenticated by an 12111 Authenticator 12113 Business Error See Status Component. 12115 Brand A Brand is the mark which identifies a particular 12116 type of Payment Instrument. A list of Brands are 12117 the payment options which are presented by the 12118 Merchant to the Consumer and from which the 12119 Consumer makes a selection. Each Brand may have a 12120 different Payment Handler. Examples of Brands 12121 include: 12122 o payment association and proprietary Brands, 12123 for example MasterCard, Visa, American Express, 12124 Diners Club, American Express, Mondex, 12125 GeldKarte, CyberCash, etc. 12126 o Promotional Brands (see below). These include: 12127 o store Brands, where the Payment Instrument is 12128 issued to a Consumer by a particular Merchant, 12129 for example Walmart, Sears, or Marks and 12130 Spencer (UK) 12131 o coBrands, for example American Advantage Visa, 12132 where an a company uses their own Brand in 12133 conjunction with, typically, a payment 12134 association Brand. 12136 Consumer The Organisation which is to receive the benefit 12137 of and typically pay for the goods or services. 12139 ContentSoftwareId This contains information which identifies the 12140 software which generated the content of the 12141 element. Its purpose is to help resolve 12142 interoperability problems that might occur as a 12143 result of incompatibilities between messages 12144 produced by different software. It is a single 12145 text string in the language defined by xml:lang. 12146 It must contain, as a minimum: 12147 o the name of the software manufacturer 12148 o the name of the software 12149 o the version of the software, and 12150 o the build of the software 12152 NAME DESCRIPTION 12154 It is recommended that this attribute is included 12155 whenever the software which generated the content 12156 cannot be identified from the SoftwareId attribute 12157 on the Message Id Component (see section 3.3.2) 12159 Customer Care An Organisation that is providing customer care 12160 Provider typically on behalf of a Merchant. Examples of 12161 customer care include, responding to problems 12162 raised by a Consumer arising from an IOTP 12163 Transaction that the Consumer took part in. 12165 Delivery Handler The Organisation that directly delivers the goods 12166 or services to the Consumer on behalf of the 12167 Merchant. Delivery can be in the form of either 12168 digital goods (e.g. a [MIME] message), or 12169 physically delivered using the post or a courier. 12171 Document Exchange A Document Exchange consists of a set of IOTP 12172 Messages exchanged between two parties that 12173 implement part or all of two Trading Exchanges 12174 simultaneously in order to minimise the number of 12175 actual IOTP Messages which must be sent over the 12176 Internet. 12178 Document Exchanges are combined together in 12179 sequence to implement a particular IOTP 12180 Transaction. 12182 Dual Brand A Dual Brand means that a single Payment 12183 Instrument may be used as if it were two separate 12184 Brands. For example there could be a single 12185 Japanese "UC" MasterCard which can be used as 12186 either a UC card or a regular MasterCard. The UC 12187 card Brand and the MasterCard Brand could each 12188 have their own separate Payment Handlers. This 12189 means that: 12190 o the Merchant treats, for example "UC" and 12191 "MasterCard" as two separate Brands when 12192 offering a list of Brands to the Consumer, 12193 o the Consumer chooses a Brand, for example 12194 either "UC" or "MasterCard, 12195 o the Consumer IOTP aware application determines 12196 which Payment Instrument(s) match the chosen 12197 Brand, and selects, perhaps with user 12198 assistance, the correct Payment Instrument to 12199 use. 12201 Error Block An Error Block reports that a Technical Error was 12202 found in an IOTP Message that was previously 12203 received. Typically Technical Errors are caused by 12204 errors in the XML which has been received or some 12206 NAME DESCRIPTION 12207 technical failure of the processing of the IOTP 12208 Message. Frequently the generation or receipt of 12209 an Error Block will result in failure of the IOTP 12210 Transaction. They are distinct from Business 12211 Errors, reported in a Status Component, which can 12212 also cause failure of an IOTP Transaction. 12214 Exchange Block An Exchange Block is sent between the two Trading 12215 Roles involved in a Trading Exchange. It contains 12216 one or more Trading Components. Exchange Blocks 12217 are always sent after a Request Block and before a 12218 Response Block in a Trading Exchange. The content 12219 of an Exchange Block is dependent on the type of 12220 Trading Exchange being carried out. 12222 IOTP Message An IOTP Message is the outermost wrapper for the 12223 document(s) which are sent between Trading Roles 12224 that are taking part in a trade. It is a well 12225 formed XML document. The documents it contains 12226 consist of: 12227 o a Transaction Reference Block to uniquely 12228 identify the IOTP Transaction of which the IOTP 12229 Message is part, 12230 o an optional Signature Block to digitally sign 12231 the Trading Blocks or Trading Components 12232 associated with the IOTP Transaction 12233 o an optional Error Block to report on technical 12234 errors contained in a previously received IOTP 12235 Message, and 12236 o a collection of IOTP Trading Blocks which 12237 carries the data required to carry out an IOTP 12238 Transaction. 12240 IOTP Transaction An instance of an Internet Open Trading Protocol 12241 Transaction consists of a set of IOTP Messages 12242 transferred between Trading Roles. The rules for 12243 what may be contained in the IOTP Messages is 12244 defined by the Transaction Type of the IOTP 12245 Transaction. 12247 IOTP Transaction A Transaction Type identifies the type an of IOTP 12248 Type Transaction. Examples of Transaction Type include: 12249 Purchase, Refund, Authentication, Withdrawal, 12250 Deposit (of electronic cash). The Transaction Type 12251 specifies for an IOTP Transaction: 12252 o the Trading Exchanges which may be included in 12253 the transaction, 12254 o how those Trading Exchanges may be combined to 12255 meet the business needs of the transaction 12256 o which Trading Blocks may be included in the 12257 IOTP Messages that make up the transaction 12258 o Consult this specification for the rules that 12260 NAME DESCRIPTION 12261 apply for each Transaction Type. 12263 Merchant The Organisation from whom the service or goods 12264 are being obtained, who is legally responsible for 12265 providing the goods or services and receives the 12266 benefit of any payment made 12268 Merchant Customer The Organisation that is involved with customer 12269 Care Provider dispute negotiation and resolution on behalf of 12270 the Merchant 12272 Organisation A company or individual that takes part in a Trade 12273 as a Trading Role. The Organisations may take one 12274 or more of the roles involved in the Trade 12276 Payment Handler The Organisation that physically receives the 12277 payment from the Consumer on behalf of the 12278 Merchant 12280 Payment A Payment Instrument is the means by which 12281 Instrument Consumer pays for goods or services offered by a 12282 Merchant. It can be, for example: 12283 o a credit card such as MasterCard or Visa; 12284 o a debit card such as MasterCard's Maestro; 12285 o a smart card based electronic cash Payment 12286 Instrument such as a Mondex Card, a GeldKarte 12287 card or a Visa Cash card 12288 o a software based electronic payment account 12289 such as a CyberCash's CyberCoin or DigiCash 12290 account. 12292 All Payment Instruments have a number, typically 12293 an account number, by which the Payment Instrument 12294 can be identified. 12296 Promotional Brand A Promotional Brand means that, if the Consumer 12297 pays with that Brand, then the Consumer will 12298 receive some additional benefit which can be 12299 received in two ways: 12300 o at the time of purchase. For example if a 12301 Consumer pays with a "Walmart MasterCard" at a 12302 Walmart web site, then a 5% discount might 12303 apply, which means the Consumer actually pays 12304 less, 12305 o from their Payment Instrument (card) issuer 12306 when the payment appears on their statement. 12307 For example loyalty points in a frequent flyer 12308 scheme could be awarded based on the total 12309 payments made with the Payment Instrument since 12310 the last statement was issued. 12312 Each Promotional Brand should be identified as a 12314 NAME DESCRIPTION 12315 separate Brand in the list of Brands offered by 12316 the Merchant. 12318 Receipt Component A Receipt Component is a record of the successful 12319 completion of a Trading Exchange. Examples of 12320 Receipt Components include: Payment Receipts, and 12321 Delivery Notes. It's content may dependent on the 12322 technology used to perform the Trading Exchange. 12323 For example a Secure Electronic Transaction (SET) 12324 payment receipt consists of SET payment messages 12325 which record the result of the payment. 12327 Request Block A Request Block is Trading Block that contains a 12328 request for a Trading Exchange to start. The 12329 Trading Components in a Request Block may be 12330 signed by a Signature Block so that their 12331 authenticity may be checked and to determine that 12332 the Trading Exchange being requested is 12333 authorised. Authorisation for a Trading Exchange 12334 to start can be provided by the signatures 12335 contained on Receipt Components contained in 12336 Response Blocks resulting from previously 12337 completed Trading Exchanges. Examples of Request 12338 Blocks are Payment Request and Delivery Request 12340 Response Block A Response Block is a Trading Block that indicates 12341 that a Trading Exchange is complete. It is sent by 12342 the Trading Role that received a Request Block to 12343 the Trading Role that sent the Request Block. The 12344 Response Block contains a Status Component that 12345 contains information about the completion of the 12346 Trading Exchange, for example it indicates whether 12347 or not the Trading Exchange completed 12348 successfully. For some Trading Exchanges the 12349 Response Block contains a Receipt Component that 12350 forms a record of the Trading Exchange. Receipt 12351 Components may be digitally signed using a 12352 Signature Block to make completion non-refutable. 12353 Examples of Response Blocks include Offer 12354 Response, Payment Response and Delivery Response. 12356 Signature Block A Signature Block is a Trading Block that contains 12357 one or more digital signatures in the form of 12358 Signature Components. A Signature Component may 12359 digitally sign any Block or Component in any IOTP 12360 Message in the same IOTP Transaction. 12362 Status Component A Status Component contains information that 12363 describes the state of a Trading Exchange. 12365 Before the Trading Exchange is complete the Status 12366 Component can indicate information about how the 12368 NAME DESCRIPTION 12369 Trading Exchange is progressing. 12371 Once a Trading Exchange is complete the Status 12372 Component can only indicate the success of the 12373 Trading Exchange or that a Business Error has 12374 occurred. 12376 A Business Error indicates that continuation with 12377 the Trading Exchange was not possible because of 12378 some business rule or logic, for example, 12379 "insufficient funds available", rather than any 12380 Technical Error associated with the content or 12381 format of the IOTP Messages in the IOTP 12382 Transaction. 12384 Technical Error See Error Block. 12386 Trading Block A Trading Block consists of one or more Trading 12387 Components. One or more Trading Blocks may be 12388 contained within the IOTP Messages which are 12389 physically sent in the form of [XML] documents 12390 between the different Trading Roles that are 12391 taking part in a trade. Trading Blocks are of 12392 three main types: 12393 o a Request Block, 12394 o an Exchange Block, or a 12395 o a Response Block 12397 Trading Component A Trading Component is a collection of XML 12398 elements and attributes. Trading Components are 12399 the child elements of the Trading Blocks. Examples 12400 of Trading Components are: Offer, Brand List, 12401 Payment Receipt, Delivery [information], Payment 12402 Amount [information] 12404 Trading Exchange A Trading Exchange consists of the exchange, 12405 between two Trading Roles, of a sequence of 12406 documents. The documents may be in the form of 12407 Trading Blocks or they may be transferred by some 12408 other means, for example through entering data 12409 into a web page. Each Trading Exchange consists of 12410 three main parts: 12411 o the sending of a Request Block by one Trading 12412 Role (the initiator) to another Trading Role 12413 (the recipient), 12414 o the optional exchange of one or more Exchange 12415 Blocks between the recipient and the initiator, 12416 until eventually, 12417 o the Trading Role that received the Request 12418 Block sends a Response Block to the initiator. 12420 A Trading Exchange is designed to implement a 12422 NAME DESCRIPTION 12423 useful service of some kind. Examples of Trading 12424 Exchanges/services are: 12425 o Offer, which results in a Consumer receiving 12426 an offer from a Merchant to carry out a 12427 business transaction of some kind, 12428 o Payment, where a Consumer makes a payment to a 12429 Payment Handler, 12430 o Delivery, where a Consumer requests, and 12431 optionally obtains, delivery of goods or 12432 services from a Delivery Handler, and 12433 o Authentication, where any Trading Role may 12434 request and receive information about another 12435 Trading Role. 12437 Trading Role A Trading Role identifies the different ways in 12438 which Organisations can participate in a trade. 12439 There are five Trading Roles: Consumer, Merchant, 12440 Payment Handler, Delivery Handler, and Merchant 12441 Customer Care Provider. 12443 Transaction A Transaction Reference Block identifies an IOTP 12444 Reference Block Transaction. It contains data that identifies: 12445 o the Transaction Type, 12446 o the IOTP Transaction uniquely, through a 12447 globally unique transaction identifier 12448 o the IOTP Message uniquely within the IOTP 12449 Transaction, through a message identifier 12451 The Transaction Reference Block may also contain 12452 references to other transactions which may or may 12453 not be IOTP Transactions 12455 15. Copyrights 12457 Copyright (C) The Internet Society (1998). All Rights Reserved. 12459 This document and translations of it may be copied and furnished to 12460 others, and derivative works that comment on or otherwise explain it or 12461 assist in its implementation may be prepared, copied, published and 12462 distributed, in whole or in part, without restriction of any kind, 12463 provided that the above copyright notice and this paragraph are included 12464 on all such copies and derivative works. However, this document itself 12465 may not be modified in any way, such as by removing the copyright notice 12466 or references to the Internet Society or other Internet organisations, 12467 except as needed for the purpose of developing Internet standards in 12468 which case the procedures for copyrights defined in the Internet 12469 Standards process must be followed, or as required to translate it into 12470 languages other than English. 12472 The limited permissions granted above are perpetual and will not be 12473 revoked by the Internet Society or its successors or assigns. 12475 This document and the information contained herein is provided on an AS 12476 IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 12477 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 12478 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 12479 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 12480 PARTICULAR PURPOSE. 12482 16. References 12484 This section contains references to related documents identified in this 12485 specification. 12487 [Base64] Base64 Content-Transfer-Encoding. A method of 12488 transporting binary data defined by MIME. See: RFC 2045: 12489 Multipurpose Internet Mail Extensions (MIME) Part One: 12490 Format of Internet Message Bodies. N. Freed & N. 12491 Borenstein. November 1996. 12493 [DOM-HASH] A method for generating hashes of all or part of an XML 12494 tree based on the DOM of that tree. See 12495 http://www.ietf.org/internet-drafts/draft-ietf-trade- 12496 hiroshi-dom-hash-*.txt 12498 [DNS] See RFC 1034: Domain names - concepts and facilities. 12499 P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names 12500 - implementation and specification. P.V. Mockapetris. 12501 Nov-01-1987. 12503 [DSA] The Digital Signature Algorithm (DSA) published by the 12504 National Institute of Standards and Technology (NIST) in 12505 the Digital Signature Standard (DSS), which is a part of 12506 the US government's Capstone project. 12508 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm 12509 (ECCDSA). Elliptic curve cryptosystems are analogues of 12510 public-key cryptosystems such as RSA in which modular 12511 multiplication is replaced by the elliptic curve addition 12512 operation. See: V. S. Miller. Use of elliptic curves in 12513 cryptography. In Advances in Cryptology - Crypto '85, 12514 pages 417-426, Springer-Verlag, 1986. 12516 [HMAC] See RFC 2104 HMAC: Keyed-Hashing for Message 12517 Authentication. H. Krawczyk, M. Bellare, R. Canetti. 12518 February 1997 12520 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up 12521 Language (HTML) is a simple mark-up language used to 12522 create hypertext documents that are platform independent. 12523 See RFC 1866 and the World Wide Web (W3C) consortium web 12524 site at: http://www.w3.org/MarkUp/ 12526 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 12527 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 12528 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 12529 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 12530 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 12531 Lee. January 1997. 12533 [IANA] The Internet Assigned Numbers Authority. The organisation 12534 responsible for co-ordinating the names and numbers 12535 associated with the Internet. See http://www.iana.org/. 12537 [ISO4217] ISO 4217: Codes for the Representation of Currencies. 12538 Available from ANSI or ISO. 12540 [IOTPDSIG] A document that describes how data contained in IOTP 12541 messages may be digitally signed. See RFC xxxx 12542 http://www.ietf.org/internet-drafts/draft-ietf-trade- 12543 iotp-v1.0-dsig-*.txt. 12545 [MD5] R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. 12547 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 12548 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 12550 [OPS] Open Profiling Standard. A proposed standard which 12551 provides a framework with built-in privacy safeguards for 12552 the trusted exchange of profile information between 12553 individuals and web sites. Being developed by Netscape 12554 and Microsoft amongst others. 12556 [RFC822] See RFC 822: The Standard for the Format of ARPA Internet 12557 Messages. 13 August 1982, David H Crocker. 13 August 12558 1982. 12560 [RFC1738] See RFC 1738: Uniform Resource Locators (URL), ed. T. 12561 Berners-Lee, L. Masinter, M. McCahill. 1994. 12563 [RFC2434] See RFC 2434. Guidelines for Writing an IANA 12564 Considerations Section in RFCs. T. Narten and H. 12565 Alvestrand 12567 [RSA] RSA is a public-key cryptosystem for both encryption and 12568 authentication supported by RSA Data Security Inc. See: 12569 R. L. Rivest, A. Shamir, and L.M. Adleman. A method for 12570 obtaining digital signatures and public-key 12571 cryptosystems. Communications of the ACM, 21(2): 120-126, 12572 February 1978. 12574 [SCCD] Secure Channel Credit Debit. A method of conducting a 12575 credit or debit card payment where unauthorised access to 12576 account information is prevented through use of secure 12577 channel transport mechanisms such as SSL/TLS. An IOTP 12578 supplement describing how SCCD works is under 12579 development. 12581 [SET] Secure Electronic Transaction Specification, Version 1.0, 12582 May 31, 1997. Supports credit and debit card payments 12583 using certificates at the Consumer and Merchant to help 12584 ensure authenticity. 12585 Download from: . 12587 [SSL/TLS] SSL is a standard developed by Netscape for encrypting 12588 data over IP networks. See 12589 http://home.netscape.com/eng/ssl3/index.html. TLS is the 12590 likely successor to SSL being developed by the IETF. See 12591 http://www.ietf.org/internet-drafts/draft-ietf-tls- 12592 protocol-05.txt 12594 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of 12595 Standards and Technology, US Department Of Commerce, 12596 April 1995. Also known as: 59 Fed Reg. 35317 (1994). See 12597 http://www.itl.nist.gov/div897/pubs/fip180-1.htm 12599 [UTC] Universal Time Co-ordinated. A method of defining time 12600 absolutely relative to Greenwich Mean Time (GMT). 12601 Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" 12602 where the "+n" defines the number of hours from GMT. See 12603 ISO DIS8601. 12605 [UTF16] The Unicode Standard, Version 2.0. The Unicode 12606 Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 12607 Proposed Draft Amendment 1 12609 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, 12610 Including Draft Amendment 1: Certificate Extensions 12611 (Version 3 Certificate) 12613 [XML Recommendation for Namespaces in XML, World Wide Web 12614 Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- 12615 xml-names" 12617 [XML] Extensible Mark Up Language. A W3C recommendation. See 12618 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 12619 February 1998 version. 12621 17. Author's Address 12623 The author of this document is: 12625 David Burdett 12626 Commerce One 12627 1600 Riviera Ave, Suite 200 12628 Walnut Creek 12629 California 94596 12630 USA 12632 Tel: +1 (925) 941 4422 12634 Email: david.burdett@commerceone.com 12636 The author of this document particularly wants to thank Mondex 12637 International Limited (www.mondex.com) for the tremendous support 12638 provided in the formative stages of the development of this 12639 specification. 12641 In addition the author appreciates the following contributors to this 12642 protocol (in alphabetic order of company) without which it could not have 12643 been developed. 12644 - Phillip Mullarkey, British Telecom plc 12645 - Andrew Marchewka, Canadian Imperial Bank of Commerce 12646 - Brian Boesch, CyberCash Inc. 12647 - Tom Arnold, CyberSource 12648 - Terry Allen, Commerce One (formally Veo Systems) 12649 - Richard Brown, GlobeSet Inc. 12650 - Peter Chang, Hewlett Packard 12651 - Masaaki Hiroya, Hitachi Ltd 12652 - Yoshiaki Kawatsura, Hitachi Ltd 12653 - Donald Eastlake 3rd, International Business Machines (formerly 12654 CyberCash Inc). 12655 - Mark Linehan, International Business Machines 12656 - Jonathan Sowler, JCP Computer Services Ltd 12657 - John Wankmueller, MasterCard International 12658 - Steve Fabes, Mondex International Ltd 12659 - Surendra Reddy, Oracle Corporation 12660 - Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) 12661 - Chris Smith, Royal Bank of Canada 12662 - Hans Bernhard-Beykirch, SIZ (IT Development and Coordination Centre 12663 of the German Savings Banks Organisation) 12664 - W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, 12665 formally AT&T Universal Card Services) 12666 - Efrem Lipkin, Sun Microsystems 12667 - Tony Lewis, Visa International 12669 The author would also like to thank the following organisations for their 12670 support: 12671 - Amino Communications 12672 - DigiCash 12673 - Fujitsu 12674 - General Information Systems 12675 - Globe Id Software 12676 - Hyperion 12677 - InterTrader 12678 - Nobil I T Corp 12679 - Mercantec 12680 - Netscape 12681 - Nippon Telegraph and Telephone Corporation 12682 - Oracle Corporation 12683 - Smart Card Integrations Ltd. 12684 - Spyrus 12685 - Verifone 12686 - Unisource nv 12687 - Wells Fargo Bank 12689 File name: draft-ietf-trade-iotp-v1.0-protocol-06.txt 12690 Expires: March 2000