idnits 2.17.1 draft-ietf-trade-iotp-v1.0-protocol-07.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-07', 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 240 longer pages, the longest (page 42) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 252 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 862 instances of too long lines in the document, the longest one being 70 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1016 has weird spacing: '...s to be forwa...' == Line 1572 has weird spacing: '...RespBlk and...' == Line 3537 has weird spacing: '...Request any ...' == Line 3539 has weird spacing: '...esponse any r...' == Line 5223 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 (October 1999) is 8931 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 1665, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'Note' is mentioned on line 11469, but not defined == Missing Reference: 'ISO 4217' is mentioned on line 5067, but not defined == Missing Reference: 'SSL' is mentioned on line 10401, but not defined == Missing Reference: 'DSIG' is mentioned on line 11242, but not defined == Unused Reference: 'Base64' is defined on line 12484, but no explicit reference was found in the text == Unused Reference: 'ECCDSA' is defined on line 12505, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 12523, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 12560, but no explicit reference was found in the text == Unused Reference: 'UTF16' is defined on line 12602, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DOM-HASH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECCDSA' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'IOTPDSIG' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTC' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTF16' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 15 errors (**), 0 flaws (~~), 23 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft. David Burdett David Burdett 2 Commerce One 3 draft-ietf-trade-iotp-v1.0-protocol-07.txt October 1999 4 Expires: April 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-07.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 Table of Contents 46 Status of this Memo ................................................1 48 Abstract ...........................................................1 50 1. Background .....................................................7 51 1.1 Commerce on the Internet, a Different Model .................7 52 1.2 Benefits of IOTP ............................................8 53 1.3 Baseline IOTP ..............................................10 54 1.4 Objectives of Document .....................................10 55 1.5 Scope of Document ..........................................10 56 1.6 Document Structure .........................................11 57 1.7 Intended Readership ........................................12 58 1.7.1 Reading Guidelines ...................................12 60 2. Introduction ..................................................14 61 2.1 Trading Roles ..............................................14 62 2.2 Trading Exchanges ..........................................16 63 2.2.1 Offer Exchange .......................................17 64 2.2.2 Payment Exchange .....................................19 65 2.2.3 Delivery Exchange ....................................21 66 2.2.4 Authentication Exchange ..............................23 67 2.3 Scope of Baseline IOTP .....................................25 69 3. Protocol Structure ............................................28 70 3.1 Overview ...................................................29 71 3.1.1 IOTP Message Structure ...............................29 72 3.1.2 IOTP Transactions ....................................30 73 3.2 IOTP Message ...............................................31 74 3.2.1 XML Document Prolog ..................................32 75 3.3 Transaction Reference Block ................................33 76 3.3.1 Transaction Id Component .............................33 77 3.3.2 Message Id Component .................................35 78 3.3.3 Related To Component .................................36 79 3.4 ID Attributes ..............................................38 80 3.4.1 IOTP Message ID Attribute Definition .................38 81 3.4.2 Block and Component ID Attribute Definitions .........40 82 3.4.3 Example of use of ID Attributes ......................40 83 3.5 Element References .........................................41 84 3.6 Extending IOTP .............................................42 85 3.6.1 Extra XML Elements ...................................43 86 3.6.2 Opaque Embedded Data .................................44 87 3.7 Packaged Content Element ...................................44 88 3.7.1 Packaging HTML .......................................46 89 3.7.2 Packaging XML ........................................47 90 3.8 Identifying Languages ......................................47 91 3.9 Secure and Insecure Net Locations ..........................48 92 3.10 Cancelled Transactions .....................................48 93 3.10.1 Cancelling Transactions ..............................48 94 3.10.2 Handling Cancelled Transactions ......................49 96 4. IOTP Error Handling ...........................................50 97 4.1 Technical Errors ...........................................50 98 4.2 Business Errors ............................................51 99 4.3 Error Depth ................................................51 100 4.3.1 Transport Level ......................................51 101 4.3.2 Message Level ........................................52 102 4.3.3 Block Level ..........................................52 103 4.4 Idempotency, Processing Sequence, and Message Flow .........54 104 4.5 Server Role Processing Sequence ............................55 105 4.5.1 Initiating Transactions ..............................55 106 4.5.2 Processing Input Messages ............................55 107 4.5.3 Cancelling a Transaction .............................61 108 4.5.4 Retransmitting Messages ..............................61 109 4.6 Client Role Processing Sequence ............................62 110 4.6.1 Initiating Transactions ..............................62 111 4.6.2 Processing Input Messages ............................63 112 4.6.3 Cancelling a Transaction .............................64 113 4.6.4 Retransmitting Messages ..............................64 115 5. Security Considerations .......................................65 116 5.1 Determining whether to use digital signatures ..............65 117 5.2 Symmetric and Asymmetric Cryptography ......................66 118 5.3 Data Privacy ...............................................67 119 5.4 Payment Protocol Security ..................................67 121 6. Digital Signatures and IOTP ...................................68 122 6.1 How IOTP uses Digital Signatures ...........................68 123 6.1.1 IOTP Signature Example ...............................70 124 6.1.2 OriginatorInfo and RecipientInfo Elements ............71 125 6.1.3 Using signatures to Prove Actions Complete Successfully72 126 6.2 Checking a Signature is Correctly Calculated ...............72 127 6.3 Checking a Payment or Delivery can occur ...................73 128 6.3.1 Check Request Block sent Correct Organisation ........74 129 6.3.2 Check Correct Components present in Request Block ....77 130 6.3.3 Check an Action is Authorised ........................77 132 7. Trading Components ............................................79 133 7.1 Protocol Options Component .................................80 134 7.2 Authentication Request Component ...........................82 135 7.3 Authentication Response Component ..........................83 136 7.4 Trading Role Information Request Component .................84 137 7.5 Order Component ............................................84 138 7.5.1 Order Description Content ............................85 139 7.5.2 OkFrom and OkTo Timestamps ...........................86 140 7.6 Organisation Component .....................................87 141 7.6.1 Organisation IDs .....................................88 142 7.6.2 Trading Role Element .................................89 143 7.6.3 Contact Information Element ..........................92 144 7.6.4 Person Name Element ..................................92 145 7.6.5 Postal Address Element ...............................93 146 7.7 Brand List Component .......................................94 147 7.7.1 Brand Element ........................................96 148 7.7.2 Protocol Brand Element ...............................98 149 7.7.3 Protocol Amount Element ..............................99 150 7.7.4 Currency Amount Element .............................100 151 7.7.5 Pay Protocol Element ................................101 152 7.8 Brand Selection Component .................................102 153 7.8.1 Brand Selection Brand Info Element ..................104 154 7.11 Payment Receipt Component .................................107 155 7.12 Payment Note Component ....................................109 156 7.13 Delivery Component ........................................110 157 7.13.1 Delivery Data Element ...............................111 158 7.14 Consumer Delivery Data Component ..........................113 159 7.15 Delivery Note Component ...................................114 160 7.16 Status Component ..........................................115 161 7.16.1 Offer Completion Codes ..............................117 162 7.16.2 Payment Completion Codes ............................118 163 7.16.3 Delivery Completion Codes ...........................120 164 7.16.4 Authentication Completion Codes .....................122 165 7.16.5 Undefined Completion Codes ..........................123 166 7.16.6 Transaction Inquiry Completion Codes ................124 167 7.17 Trading Role Data Component ...............................124 168 7.17.1 Who Receives a Trading Role Data Component ..........125 169 7.18 Inquiry Type Component ....................................125 170 7.19 Signature Component .......................................126 171 7.19.1 IOTP usage of signature elements and attributes .....127 172 7.19.2 Offer Response Signature Component ..................129 173 7.19.3 Payment Receipt Signature Component .................130 174 7.19.4 Delivery Response Signature Component ...............131 175 7.19.5 Authentication Request Signature Component ..........131 176 7.19.6 Authentication Response Signature Component .........131 177 7.19.7 Inquiry Request Signature Component .................132 178 7.19.8 Inquiry Response Signature Component ................132 179 7.19.9 Ping Request Signature Component ....................132 180 7.19.10 Ping Response Signature Component...................132 181 7.20 Certificate Component .....................................132 182 7.20.1 IOTP usage of signature elements and attributes .....133 183 7.21 Error Component ...........................................133 184 7.21.1 Error Processing Guidelines .........................135 185 7.21.2 Error Codes .........................................136 186 7.21.3 Error Location Element ..............................140 188 8. Trading Blocks ...............................................142 189 8.1 Trading Protocol Options Block ............................144 190 8.2 TPO Selection Block .......................................145 191 8.3 Offer Response Block ......................................145 192 8.4 Authentication Request Block ..............................146 193 8.5 Authentication Response Block .............................148 194 8.6 Authentication Status Block ...............................148 195 8.7 Payment Request Block .....................................149 196 8.8 Payment Exchange Block ....................................150 197 8.9 Payment Response Block ....................................151 198 8.10 Delivery Request Block ....................................152 199 8.11 Delivery Response Block ...................................153 200 8.12 Inquiry Request Trading Block .............................154 201 8.13 Inquiry Response Trading Block ............................154 202 8.14 Ping Request Block ........................................155 203 8.15 Ping Response Block .......................................156 204 8.16 Signature Block ...........................................157 205 8.16.1 Signature Block with Offer Response .................158 206 8.16.2 Signature Block with Payment Request ................158 207 8.16.3 Signature Block with Payment Response ...............158 208 8.16.4 Signature Block with Delivery Request ...............158 209 8.16.5 Signature Block with Delivery Response ..............159 210 8.17 Error Block ...............................................159 211 8.18 Cancel Block ..............................................160 213 9. Internet Open Trading Protocol Transactions ..................161 214 9.1 Authentication and Payment Related IOTP Transactions ......161 215 9.1.1 Authentication Document Exchange ....................163 216 9.1.2 Offer Document Exchange .............................168 217 9.1.3 Payment Document Exchange ...........................175 218 9.1.4 Delivery Document Exchange ..........................180 219 9.1.5 Payment and Delivery Document Exchange ..............182 220 9.1.6 Baseline Authentication IOTP Transaction ............185 221 9.1.7 Baseline Deposit IOTP Transaction ...................186 222 9.1.8 Baseline Purchase IOTP Transaction ..................188 223 9.1.9 Baseline Refund IOTP Transaction ....................189 224 9.1.10 Baseline Withdrawal IOTP Transaction ................191 225 9.1.11 Baseline Value Exchange IOTP Transaction ............193 226 9.1.12 Valid Combinations of Document Exchanges ............195 227 9.1.13 Combining Authentication Transactions with other 228 Transactions ........................................198 229 9.2 Infrastructure Transactions ...............................199 230 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 200 231 9.2.2 Baseline Ping IOTP Transaction ......................204 233 10. Retrieving Logos .............................................208 234 10.1 Logo Size .................................................208 235 10.2 Logo Color Depth ..........................................209 236 10.3 Logo Net Location Examples ................................209 238 11. Brands .......................................................210 239 11.1 Brand Definitions and Brand Selection .....................210 240 11.1.1 Definition of Payment Instrument ....................210 241 11.1.2 Definition of Brand .................................211 242 11.1.3 Definition of Dual Brand ............................211 243 11.1.4 Definition of Promotional Brand .....................212 244 11.1.5 Identifying Promotional Brands ......................212 245 11.2 Brand List Examples .......................................214 246 11.2.1 Simple Credit Card Based Example ....................215 247 11.2.2 Credit Card Brand List Including Promotional Brands..216 248 11.2.3 Brand Selection Example .............................217 249 11.2.4 Complex Electronic Cash Based Brand List ............217 251 12. IANA Considerations ..........................................221 252 12.1 Codes Controlled by IANA ..................................221 253 12.2 Codes not controlled by IANA ..............................226 255 13. Internet Open Trading Protocol Data Type Definition ..........227 257 14. Glossary .....................................................240 258 15. Copyrights ...................................................247 260 16. References ...................................................248 262 17. Author's Address .............................................251 264 Table of Figures 266 Figure 1 IOTP Trading Roles 15 267 Figure 2 Offer Exchange 17 268 Figure 3 Payment Exchange 20 269 Figure 4 Delivery Exchange 22 270 Figure 5 Authentication Exchange 24 271 Figure 6 IOTP Message Structure 29 272 Figure 7 An IOTP Transaction 30 273 Figure 8 Example use of ID attributes 41 274 Figure 9 Element References 42 275 Figure 10 Signature Digests 69 276 Figure 11 Example use of Signatures for Baseline Purchase 71 277 Figure 12 Checking a Payment Handler can carry out a Payment 75 278 Figure 13 Checking a Delivery Handler can carry out a Delivery 77 279 Figure 14 Trading Components 80 280 Figure 15 Brand List Element Relationships 96 281 Figure 16 Trading Blocks 143 282 Figure 17 Payment and Authentication Message Flow Combinations 163 283 Figure 18 Authentication Document Exchange 165 284 Figure 19 Brand Dependent Offer Document Exchange 170 285 Figure 20 Brand Independent Offer Exchange 171 286 Figure 21 Payment Document Exchange 176 287 Figure 22 Delivery Document Exchange 181 288 Figure 23 Payment and Delivery Document Exchange 183 289 Figure 24 Baseline Authentication IOTP Transaction 186 290 Figure 25 Baseline Deposit IOTP Transaction 187 291 Figure 26 Baseline Purchase IOTP Transaction 189 292 Figure 27 Baseline Refund IOTP Transaction 191 293 Figure 28 Baseline Withdrawal IOTP Transaction 192 294 Figure 29 Baseline Value Exchange IOTP Transaction 194 295 Figure 30 Baseline Value Exchange Signatures 195 296 Figure 31 Valid Combinations of Document Exchanges 196 297 Figure 32 Baseline Transaction Status Inquiry 202 298 Figure 33 Baseline Ping Messages 205 300 1. Background 302 The Internet Open Trading Protocol (IOTP) provides an interoperable 303 framework for Internet commerce. It is payment system independent and 304 encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, 305 GeldKarte, etc. IOTP is able to handle cases where such merchant roles as 306 the shopping site, the Payment Handler, the Delivery Handler of goods or 307 services, and the provider of customer support are performed by different 308 parties or by one party. 310 The developers of IOTP seek to provide a virtual capability that safely 311 replicates the real world, the paper based, traditional, understood, 312 accepted methods of trading, buying, selling, value exchanging that has 313 existed for many hundreds of years. The negotiation of who will be the 314 parties to the trade, how it will be conducted, the presentment of an 315 offer, the method of payment, the provision of a payment receipt, the 316 delivery of goods and the receipt of goods. These are events that are 317 taken for granted in the course of real world trade. IOTP has been 318 produced to provide the same for the virtual world, and to prepare and 319 provide for the introduction of new models of trading made possible by 320 the expanding presence of the virtual world. 322 The other fundamental ideal of the IOTP effort is to produce a definition 323 of these trading events in such a way that no matter where produced, two 324 unfamiliar parties using electronic commerce capabilities to buy and sell 325 that conform to the IOTP specifications will be able to complete the 326 business safely and successfully. 328 In summary, IOTP supports: 330 o Familiar trading models 332 o New trading models 334 o Global interoperability 336 The remainder of this section provides background to why IOTP was 337 developed. The specification itself starts in the next chapter. 339 1.1 Commerce on the Internet, a Different Model 341 The growth of the Internet and the advent of electronic commerce are 342 bringing about enormous changes around the world in society, politics and 343 government, and in business. The ways in which trading partners 344 communicate, conduct commerce, are governed have been enriched and 345 changed forever. 347 One of the very fundamental changes about which IOTP is concerned is 348 taking place in the way consumers and merchants trade. Characteristics of 349 trading that have changed markedly include: 351 o Presence: Face-to-face transactions become the exception, not the rule. 352 Already with the rise of mail order and telephone order placement this 353 change has been felt in western commerce. Electronic commerce over the 354 Internet will further expand the scope and volume of transactions 355 conducted without ever seeing the people who are a part of the 356 enterprise with whom one does business. 358 o Authentication: An important part of personal presence is the ability 359 of the parties to use familiar objects and dialogue to confirm they are 360 who they claim to be. The seller displays one or several well known 361 financial logos that declaim his ability to accept widely used credit 362 and debit instruments in the payment part of a purchase. The buyer 363 brings government or financial institution identification that assures 364 the seller she will be paid. People use intangibles such as personal 365 appearance and conduct, location of the store, apparent quality and 366 familiarity with brands of merchandise, and a good clear look in the 367 eye to reinforce formal means of authentication. 369 o Payment Instruments: Despite the enormous size of bank card financial 370 payments associations and their members, most of the world's trade 371 still takes place using the coin of the realm or barter. The present 372 infrastructure of the payments business cannot economically support low 373 value transactions and could not survive under the consequent volumes 374 of transactions if it did accept low value transactions. 376 o Transaction Values: New meaning for low value transactions arises in 377 the Internet where sellers may wish to offer for example, pages of 378 information for fractions of currency that do not exist in the real 379 world. 381 o Delivery: New modes of delivery must be accommodated such as direct 382 electronic delivery. The means by which receipt is confirmed and the 383 execution of payment change dramatically where the goods or services 384 have extremely low delivery cost but may in fact have very high value. 385 Or, maybe the value is not high, but once delivery occurs the value is 386 irretrievably delivered so payment must be final and non-refundable but 387 delivery nonetheless must still be confirmed before payment. 388 Incremental delivery such as listening or viewing time or playing time 389 are other models that operate somewhat differently in the virtual 390 world. 392 1.2 Benefits of IOTP 394 ELECTRONIC COMMERCE SOFTWARE VENDORS 396 Electronic Commerce Software Vendors will be able to develop e-commerce 397 products which are more attractive as they will inter-operate with any 398 other vendors' software. However since IOTP focuses on how these 399 solutions communicate, there is still plenty of opportunity for product 400 differentiation. 402 PAYMENT BRANDS 404 IOTP provides a standard framework for encapsulating payment protocols. 405 This means that it is easier for payment products to be incorporated into 406 IOTP solutions. As a result the payment brands will be more widely 407 distributed and available on a wider variety of platforms. 409 MERCHANTS 411 There are several benefits for Merchants: 413 o they will be able to offer a wider variety of payment brands, 415 o they can be more certain that the customer will have the software 416 needed to complete the purchase 418 o through receiving payment and delivery receipts from their customers, 419 they will be able to provide customer care knowing that they are 420 dealing with the individual or organisation with which they originally 421 traded 423 o new merchants will be able to enter this new (Internet) market-place 424 with new products and services, using the new trading opportunities 425 which IOTP presents 427 BANKS AND FINANCIAL INSTITUTIONS 429 There are also several benefits for Banks and Financial Institutions: 431 o they will be able to provide IOTP support for merchants 433 o they will find new opportunities for IOTP related services: 434 - providing customer care for merchants 435 - fees from processing new payments and deposits 437 o they have an opportunity to build relationships with new types of 438 merchants 440 CUSTOMERS 442 For Customers there are several benefits: 444 o they will have a larger selection of merchants with whom they can trade 446 o there is a more consistent interface when making the purchase 448 o there are ways in which they can get their problems fixed through the 449 merchant (rather than the bank!) 451 o there is a record of their transaction which can be used, for example, 452 to feed into accounting systems or, potentially, to present to the tax 453 authorities 455 1.3 Baseline IOTP 457 This specification is Baseline IOTP. It is a Baseline in that it contains 458 ways of doing trades on the Internet which are the most common, for 459 example purchases and refunds. 461 The group that has worked on the IOTP see an extended version being 462 developed over time but feel a need to focus on a limited function but 463 completely usable specification in order that implementers can develop 464 solutions that work now. 466 During this period it is anticipated that there will be no changes to the 467 scope of this specification with the only changes made being limited to 468 corrections where problems are found. Software solutions have been 469 developed based on earlier versions of this specification (for example 470 version 0.9 published in early 1998 and earlier revisions of version 1.0 471 published during 1999) which prove that the IOTP works. 473 1.4 Objectives of Document 475 The objectives of this document are to provide a specification of version 476 1.0 of the Internet Open Trading Protocols which can be used to design 477 and implement systems which support electronic trading on the Internet 478 using the Internet Open Trading Protocols. 480 The purpose of the document is: 482 o to allow potential developers of products based on the protocol to 483 develop software/hardware solutions which use the protocol 485 o to allow the financial services industry to understand a developing 486 electronic commerce trading protocol that encapsulates (without 487 modification) any of the current or developing payment schemes now 488 being used or considered by their merchant customer base 490 1.5 Scope of Document 492 The protocol describes the content, format and sequences of messages that 493 pass among the participants in an electronic trade - consumers, merchants 494 and banks or other financial institutions, and customer care providers. 495 These are required to support the electronic commerce transactions 496 outlined in the objectives above. 498 The protocol is designed to be applicable to any electronic payment 499 scheme since it targets the complete purchase process where the movement 500 of electronic value from the payer to the payee is only one, but 501 important, step of many that may be involved to complete the trade. 503 Payment Scheme which IOTP could support include MasterCard Credit, Visa 504 Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, 505 Proton etc. 507 Each payment scheme contains some message flows which are specific to 508 that scheme. These scheme-specific parts of the protocol are contained in 509 a set of payment scheme supplements to this specification. 511 The document does not prescribe the software and processes that will need 512 to be implemented by each participant. It does describe the framework 513 necessary for trading to take place. 515 This document also does not address any legal or regulatory issues 516 surrounding the implementation of the protocol or the information systems 517 which use them. 519 1.6 Document Structure 521 The document consists of the following sections: 523 o Section 1 - Background: This section gives a brief background on 524 electronic commerce and the benefits IOTP offers. 526 o Section 2 - Introduction: This section describes the various Trading 527 Exchanges and shows how these trading exchanges are used to construct 528 the IOTP Transactions. This section also explains various Trading Roles 529 that would participate in electronic trade. 531 o Section 3 - Protocol Structure: This section summarises how various 532 IOTP transactions are constructed using the Trading Blocks and Trading 533 Components that are the fundamental building blocks for IOTP 534 transactions. All IOTP transaction messages are well formed XML 535 documents. 537 o Section 4 - IOTP Error Handling: This section describes how to process 538 exceptions and errors during the protocol message exchange and trading 539 exchange processing. This section provides a generic overview of the 540 exception handling. This section should be read carefully. 542 o Section 5 - Security Considerations: This section considers from an 543 IETF perspective, how IOTP addresses security. It includes: how to 544 determine whether to use digital signatures with IOTP, how IOTP address 545 data privacy, and how security built into payment protocols relate to 546 IOTP security. 548 o Section 6 - Digital Signatures and IOTP: This section provides an 549 overview of how IOTP uses digital signatures; how to check a signature 550 is correctly calculated and how the various Trading Roles that 551 participate in trade should check signatures when required. 553 o Section 7 - Trading Components: This section defines the XML elements 554 required by Trading Components. 556 o Section 8 - Trading Blocks: This section describes how Trading Blocks 557 are constructed from Trading Components. 559 o Section 9 - Internet Open Trading Protocol Transactions: This section 560 describes all the IOTP Baseline transactions. It refers to Trading 561 Blocks and Trading Components and Signatures. This section doesn't 562 directly link error handling during the protocol exchanges, the reader 563 is advised to understand Error Handling as defined in section before 564 reading this section. 566 o Section 10 - Retrieving Logos: This section describes how IOTP specific 567 logos can be retrieved. 569 o Section 11 - Brands: This section provides: an overview of Brand 570 Definitions and Brand Selection which describe how a Consumer can 571 select a Brand from a list provided by the Merchant; as well as some 572 examples of Brand Lists. 574 o Section 12 - IANA Considerations: This section describes how new values 575 for codes used by IOTP are co-ordinated. 577 o Section 13 - Internet Open Trading Protocol Data Type Definition: This 578 section contains the XML Data Type Definitions for IOTP. 580 o Section 14 - Glossary. This describes all the major terminology used by 581 IOTP. 583 o Section 15 - Copyright information. 585 o Section 16 - A list of the other documents referenced by the IOTP 586 specification. 588 o Section 17 - The Author's Address 590 1.7 Intended Readership 592 Software and hardware developers; development analysts; business and 593 technical planners; industry analysts; merchants; bank and other payment 594 handlers; owners, custodians, and users of payment protocols. 596 1.7.1 Reading Guidelines 598 This IOTP specification is structured primarily in a sequence targeted at 599 people who want to understand the principles of IOTP. However from 600 practical implementation experience by implementers of earlier of 601 versions of the protocol new readers who plan to implement IOTP may 602 prefer to read the document in a different sequence as described below. 604 Review the transport independent parts of the specification: This covers 606 o Section 14 - Glossary 607 o Section 1 - Background 609 o Section 2 - Introduction 611 o Section 3 - Protocol Structure 613 o Section 4 - IOTP Error Handling 615 o Section 5 - Security Considerations 617 o Section 9 - Internet Open Trading Protocol Transactions 619 o Section 11 - Brands 621 o Section 12 - IANA Considerations 623 o Section 10 - Retrieving Logos 625 Review the detailed XML definitions: 627 o Section 8 - Trading Blocks 629 o Section 7 - Trading Components 631 o Section 6 - Digital Signatures and IOTP 633 2. Introduction 635 The Internet Open Trading Protocols (IOTP) define a number of different 636 types of IOTP Transactions: 638 o Purchase. This supports a purchase involving an offer, a payment and 639 optionally a delivery 641 o Refund. This supports the refund of a payment as a result of, 642 typically, an earlier purchase 644 o Value Exchange. This involves two payments which result in the exchange 645 of value from one combination of currency and payment method to another 647 o Authentication. This supports one organisation or individual to check 648 that another organisation or individual are who they appear to be. 650 o Withdrawal. This supports the withdrawal of electronic cash from a 651 financial institution 653 o Deposit. This supports the deposit of electronic cash at a financial 654 institution 656 o Inquiry This supports inquiries on the status of an IOTP transaction 657 which is either in progress or is complete 659 o Ping This supports a simple query which enables one IOTP aware 660 application to determine whether another IOTP application running 661 elsewhere is working or not. 663 These IOTP Transactions are "Baseline" transactions since they have been 664 identified as a minimum useful set of transactions. Later versions of 665 IOTP may include additional types of transactions. 667 Each of the IOTP Transactions above involve: 669 o a number of organisations playing a Trading Role, and 671 o a set of Trading Exchanges. Each Trading Exchange involves the exchange 672 of data, between Trading Roles, in the form of a set of Trading 673 Components. 675 Trading Roles, Trading Exchanges and Trading Components are described 676 below. 678 2.1 Trading Roles 680 The Trading Roles identify the different parts which organisations can 681 take in a trade. The five Trading Roles used within IOTP are illustrated 682 in the diagram below. 684 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 686 Merchant Customer Care Provider resolves ---------- 687 ---------------------------------------------->| Merchant | 688 | Consumer disputes and problems |Cust.Care.| 689 | | Provider | 690 | ---------- 691 | 692 Payment Handler accepts or makes ---------- 693 | ------------------------------------------>| Payment | 694 | | Payment for Merchant | Handler | 695 | | ---------- 696 v v 697 ---------- Consumer makes purchases or obtains ---------- 698 | Consumer |<--------------------------------------->| Merchant | 699 ---------- refund from Merchant ---------- 700 ^ 701 | Delivery Handler supplies goods or ---------- 702 |---------------------------------------------->|Deliverer | 703 services for Merchant ---------- 705 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 707 Figure 1 IOTP Trading Roles 709 The roles are: 711 o Consumer. The person or organisation which is to receive and pay for 712 the goods or services 714 o Merchant. The person or organisation from whom the purchase is being 715 made and who is legally responsible for providing the goods or services 716 and receives the benefit of the payment made 718 o Payment Handler. The entity that physically receives the payment from 719 the Consumer on behalf of the Merchant 721 o Delivery Handler. The entity that physically delivers the goods or 722 services to the Consumer on behalf of the Merchant. 724 o Merchant Customer Care Provider. The entity that is involved with 725 customer dispute negotiation and resolution on behalf of the Merchant 727 Roles may be carried out by the same organisation or different 728 organisations. For example: 730 o in the simplest case one physical organisation (e.g. a merchant) could 731 handle the purchase, accept the payment, deliver the goods and provide 732 merchant customer care 734 o at the other extreme, a merchant could handle the purchase but instruct 735 the consumer to pay a bank or financial institution, request that 736 delivery be made by an overnight courier firm and to contact an 737 organisation which provides 24x7 service if problems arise. 739 Note that in this specification, unless stated to the contrary, when the 740 words Consumer, Merchant, Payment Handler, Delivery Handler or Customer 741 Care Provider are used, they refer to the Trading Role rather than an 742 actual organisation. 744 An individual organisation may take multiple roles. For example a company 745 which is selling goods and services on the Internet could take the role 746 of Merchant when selling goods or services and the role of Consumer when 747 the company is buying goods or services itself. 749 As roles occur in different places there is a need for the organisations 750 involved in the trade to exchange data, i.e. to carry out Trading 751 Exchanges, so that the trade can be completed. 753 2.2 Trading Exchanges 755 The Internet Open Trading Protocols identify four Trading Exchanges which 756 involve the exchange of data between the Trading Roles. The Trading 757 Exchanges are: 759 o Offer. The Offer Exchange results in the Merchant providing the 760 Consumer with the reason why the trade is taking place. It is called an 761 Offer since the Consumer must accept the Offer if a trade is to 762 continue 764 o Payment. The Payment Exchange results in a payment of some kind between 765 the Consumer and the Payment Handler. This may occur in either 766 direction 768 o Delivery. The Delivery Exchange transmits either the on-line goods, or 769 delivery information about physical goods from the Delivery Handler to 770 the Consumer, and 772 o Authentication. The Authentication Exchange can be used by any Trading 773 Role to authenticate another Trading Role to check that they are who 774 they appear to be. 776 IOTP Transactions are composed of various combinations of these Trading 777 Exchanges. For example, an IOTP Purchase transaction includes Offer, 778 Payment, and Delivery Trading Exchanges. As another example, an IOTP 779 Value Exchange transaction is composed of an Offer Trading Exchange and 780 two Payment Trading Exchanges. 782 Trading Exchanges consist of Trading Components that are transmitted 783 between the various Trading Roles. Where possible, the number of round- 784 trip delays in an IOTP Transaction is minimised by packing the Components 785 from several Trading Exchanges into combination IOTP Messages. For 786 example, the IOTP Purchase transaction combines a Delivery Organisation 787 Component with an Offer Response Component in order to avoid an extra 788 Consumer request and response. 790 Each of the IOTP Trading Exchanges is described in more detail below. For 791 clarity of description, these describe the Trading Exchanges as though 792 they were standalone operations. For performance reasons, the Trading 793 Exchanges are intermingled in the actual IOTP Transaction definitions. 795 2.2.1 Offer Exchange 797 The goal of the Offer Exchange is for the Merchant to provide the 798 Consumer with information about the trade so that the Consumer can decide 799 whether to continue with the trade. This is illustrated in the figure 800 below. 802 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 803 Consumer 804 | Merchant 805 STEP | | 806 1. Consumer decides to trade and sends information about the 807 transaction (requests an offer) to the Merchant e.g. using 808 HTML. 810 C --> M Data: Information on what is being purchased (Offer Request) 811 - outside scope of IOTP 813 2. Merchant checks the information provided by the Consumer, 814 creates an Offer optionally signs it and sends it to the 815 Consumer. 817 C <-- M OFFER RESPONSE. Components: Status; Organisation(s) 818 (Consumer, DelivTo, Merchant, Payment Handler, Customer 819 Care); Order; Payment; Delivery; TradingRoleData (optional) 820 Offer Response Signature (optional) that signs other 821 components 823 3. Consumer checks the information from the Merchant and decides 824 whether to continue. 826 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 828 Figure 2 Offer Exchange 830 An Offer Exchange uses the following Trading Components that are passed 831 between the Consumer and the Merchant: 833 o the Status component is used to indicate to other parties that a valid 834 Offer Response has been generated 836 o the Organisation Component contains information which describes the 837 Organisations which are taking a role in the trade: 839 - the consumer provides information, about who the consumer is and, if 840 goods or services are being delivered, where the goods or services 841 are to be delivered to 842 - the merchant augments this information by providing information about 843 the merchant, the Payment Handler, the customer care provider and, if 844 goods or services are being delivered, the Delivery Handler 846 o the Order Component contains descriptions of the goods or services 847 which will result from the trade if the consumer agrees to the offer. 848 This information is sent by the Merchant to the consumer who should 849 verify it 851 o the Payment Component generated by the Merchant, contains details of 852 how much to pay, the currency and the payment direction, for example 853 the consumer could be asking for a refund. Note that there may be more 854 than one payment in a trade 856 o the Delivery Component, also generated by the Merchant, is used if 857 goods or services are being delivered. This contains information about 858 how delivery will occur, for example by post or using e-mail 860 o the Trading Role Data component contains data the Merchant wants to 861 forward to another Trading Role such as a Payment Handler or Delivery 862 Handler 864 o the "Offer Response" Signature Component, if present, digitally signs 865 all of the above components to ensure their integrity. 867 The exact content of the information provided by the Merchant to the 868 Consumer will vary depending on the type of IOTP Transaction. For 869 example: 871 o low value purchases may not need a signature 873 o the amount to be paid may vary depending on the payment brand and 874 payment protocol used 876 o some offers may not involve the delivery of any goods 878 o a value exchange will involve two payments 880 o a merchant may not offer customer care. 882 Information provided by the consumer to the merchant is provided using a 883 variety of methods, for example, it could be provided: 885 o using [HTML] pages as part of the "shopping experience" of the 886 consumer. 888 o Using the Open Profiling Standard [OPS] which has recently been 889 proposed, 891 o in the form of Organisation Components associated with an 892 authentication of a Consumer by a Merchant 894 o as Order Components in a later version of IOTP. 896 2.2.2 Payment Exchange 898 The goal of the Payment Exchange is for a payment to be made from the 899 Consumer to a Payment Handler or vice versa using a payment brand and 900 payment protocol selected by the Consumer. A secondary goal is to 901 optionally provide the Consumer with a digitally signed Payment Receipt 902 which can be used to link the payment to the reason for the payment as 903 described in the Offer Exchange. 905 Payment Exchanges can work in a variety of ways. The most general case 906 where the trade is dependent on the payment brand and protocol used is 907 illustrated in the diagram below. Simpler payment exchanges are possible. 908 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 909 Consumer Pay Handler 910 | Merchant | 911 STEP | | | 912 1. Consumer decides to trade and sends information about 913 the transaction (requests an offer) to the Merchant 914 e.g. using HTML. 916 C --> M Information on what is being paid for (outside scope 917 of IOTP 919 2. Merchant decides which payment brand, payment 920 protocols and currencies/amounts to offer, places then 921 in a Brand List Component and sends them to the 922 Consumer 924 C <-- M Components: Brand List 926 3. Consumer selects the payment brand, protocol and 927 currency/amount to use, creates a Brand Selection 928 component and sends it to the Merchant 930 C --> M Component: Brand List Selection 932 4. Merchant checks Brand Selection, creates a Payment 933 Amount information, optionally signs it to authorise 934 payment and sends it to the Consumer 936 C <-- M Component: Payment; Organisation(s) (Merchant and 937 Payment Handler); Optional Offer Response Signature 938 that signs other components 940 5. Consumer checks the Payment Amount information and if 941 OK requests that the payment starts by sending 942 information to the Payment Handler 944 C --------> P PAYMENT REQUEST. Components: Status, Payment; 945 Organisations (Merchant and Payment Handler); Trading 946 Role Data (optional); Optional Offer Response 947 Signature that signs other components; Pay Scheme Data 949 6. Payment Handler checks information including optional 950 signature and if OK starts exchanging Pay Scheme Data 951 components for selected payment brand and payment 952 protocol 954 C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data 956 7. Eventually payment protocol messages finish so Payment 957 Handler sends Pay Receipt and optional signature to 958 the Consumer as proof of payment 960 C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt; 961 Payment Note; Trading Role Data (optional); Optional 962 Offer Response Signature; Optional Payment Receipt 963 Signature that binds the payment to the Offer 965 8. Consumer checks Payment Receipt is OK 967 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 969 Figure 3 Payment Exchange 971 A Payment Exchange uses the following Trading Components that are passed 972 between the Consumer, the Merchant and the Payment Handler: 974 o The Brand List Component contains a list of payment brands (for 975 example, MasterCard, Visa, Mondex, GeldKarte), payment protocols (for 976 example SET Version 1.0, Secure Channel Credit Debit (SCCD - the name 977 used for a credit or debit card payment where unauthorised access to 978 account information is prevented through use of secure channel 979 transport mechanisms such as SSL/TLS) as well as currencies/amounts 980 that apply. The Merchant sends the Brand List to the Consumer. The 981 consumer compares the payment brands, protocols and currencies/amounts 982 on offer with those that the Consumer supports and makes a selection. 984 o The Brand Selection Component contains the Consumer's selection. 985 Payment brand, protocol, currency/amount and possibly protocol-specific 986 information is sent back to the Merchant. This information may be used 987 to change information in the Offer Exchange. For example, a merchant 988 could choose to offer a discount to encourage the use of a store card. 990 o the Status component is used to indicate to the Payment Handler that an 991 earlier exchange (e.g. an Offer Exchange) has successfully completed 992 and by the Payment Handler to indicate the completion status of the 993 Payment Exchange. 995 o The Organisation Components are generated by the Merchant. They contain 996 details of the Merchant and Payment Handler Roles: 997 - the Merchant role is required so that the Payment Handler can 998 identify which Merchant initiated the payment. Typically, the result 999 of the Payment Handler accepting (or making) a payment on behalf of 1000 the Merchant will be a credit or debit transaction to the Merchant's 1001 account held by the Payment Handler. These transactions are outside 1002 the scope of this version of IOTP 1003 - the Payment Handler role is required so that the Payment Handler can 1004 check that it is the correct Payment Handler to be used for the 1005 payment 1007 o The Payment Component contains details of how much to pay, the currency 1008 and the payment direction 1010 o The "Offer Response" Signature Component, if present, digitally signs 1011 all of the above components to ensure their integrity. Note that the 1012 Brand List and Brand Selection Components are not signed until the 1013 payment information is created (step 4 in the diagram) 1015 o the Trading Role Data component contains from other roles (e.g. a 1016 Merchant) that needs to be forwarded to the Payment Handler 1018 o The Payment Scheme Component contains messages from the payment 1019 protocol used in the Trade. For example they could be SET messages, 1020 Mondex messages, GeldKarte Messages or one of the other payment methods 1021 supported by IOTP. The content of the Payment Scheme Component is 1022 defined in the supplements that describe how IOTP works with various 1023 payment protocols. 1025 o The Payment Receipt Component contains a record of the payment. The 1026 content depends upon the payment protocol used. 1028 o The "Payment Receipt" Signature Component provides proof of payment by 1029 digitally signing both the Payment Receipt Component and the Offer 1030 Response Signature. The signature on the offer digitally signs the 1031 Order, Organisation and Delivery Components contained in the Offer. 1032 This signature effectively binds the payment to the offer. 1034 The example of a Payment Exchange above is the most general case. Simpler 1035 cases are also possible. For example, if the amount paid is not dependent 1036 on the payment brand and protocol selected then the payment information 1037 generated by step 3 can be sent to the Consumer at the same time as the 1038 Brand List Component generated by step 1. These and other variations are 1039 described in the Baseline Purchase IOTP Transaction (see section 9.1.8). 1041 2.2.3 Delivery Exchange 1043 The goal of the Delivery Exchange is to cause purchased goods to be 1044 delivered to the consumer either online or via physical delivery. A 1045 second goal is to provide a "delivery note" to the consumer, providing 1046 details about the delivery, such as shipping tracking number. The result 1047 of the delivery may also be signed so that it can be used for customer 1048 care in the case of problems with physical delivery. The message flow is 1049 illustrated in the diagram below. 1051 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1052 CONSUMER DELIVERY 1053 | HANDLER 1054 | Merchant | 1055 STEP | | | 1056 1. Consumer decides to trade and sends information about 1057 what to deliver and who is to take delivery, to the 1058 Merchant e.g. using HTML. 1060 C --> M Information on what is being delivered (outside scope 1061 of IOTP) 1063 2. Merchant checks the information provided by the 1064 Consumer, adds information about how the delivery will 1065 occur, information about the Organisations involved in 1066 the delivery and optionally sings it and sends it to 1067 the Consumer 1069 C <-- M Components: Delivery; Organisations (Delivery Handler, 1070 Deliver To); Order, Optional Offer Response Signature 1072 3. Consumer checks delivery information is OK, obtains 1073 authorisation for the delivery, for example by making 1074 a payment, and sends the delivery information to the 1075 Delivery Handler 1077 C --------> D DELIVERY REQUEST. Components: Status; Delivery, 1078 Organisations: (Merchant, Delivery Handler, DelivTo); 1079 Order, Trading Role Data (optional); Optional Offer 1080 Response Signature, Optional Payment Receipt Signature 1081 (from Payment Exchange) 1083 4. Delivery Handler checks information and authorisation. 1084 Starts or schedules delivery and creates and then 1085 sends a delivery not tot the Consumer which can 1086 optionally be signed. 1088 C <-------- D DELIVERY RESPONSE. Components: Status; Delivery Note, 1089 Trading Role Data (optional); Optional Delivery 1090 Response Signature 1092 5. Consumer checks delivery note is OK and accepts or 1093 waits for delivery as described in the the Delivery 1094 Note. 1096 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1098 Figure 4 Delivery Exchange 1100 A Delivery Exchange uses the following Trading Components that are passed 1101 between the Consumer, the Merchant and the Delivery Handler: 1103 o the Status component is used to indicate to the Delivery Handler that 1104 an earlier exchange (e.g. an Offer Exchange or Payment Exchange) has 1105 successfully completed and by the Delivery Handler to indicate the 1106 completion status of the Delivery Exchange. 1108 o The Organisation Component(s) contain details of the Deliver To, 1109 Delivery Handler and Merchant Roles: 1110 - the Deliver To role indicates where the goods or services are to be 1111 delivered to 1112 - the Delivery Handler role is required so that the Delivery Handler 1113 can check that she is the correct Delivery Handler to do the delivery 1114 - the Merchant role is required so that the Delivery Handler can 1115 identify which Merchant initiated the delivery 1117 o The Order Component, contains information about the goods or services 1118 to be delivered 1120 o The Delivery Component contains information about how delivery will 1121 occur, for example by post or using e-mail. 1123 o The "Offer Response" Signature Component, if present, digitally signs 1124 all of the above components to ensure their integrity. 1126 o The "Payment Receipt" Signature Component provides proof of payment by 1127 digitally signing the Payment Receipt Component and the Offer 1128 Signature. This is used by the Delivery Handler to check that delivery 1129 is authorised 1131 o The Delivery Note Component contains customer care information related 1132 to a physical delivery, or alternatively the actual "electronic goods". 1133 The Consumer's software does not interpret information about a physical 1134 delivery but should have the ability to display the information, both 1135 at the time of the delivery and later if the Consumer selects the Trade 1136 to which this delivery relates from a transaction list 1138 o The "Delivery Response" Signature Component, if present, provides proof 1139 of the results of the Delivery by digitally signing the Delivery Note 1140 and any Offer Response or Payment Response signatures that the Delivery 1141 Handler received. 1143 2.2.4 Authentication Exchange 1145 The goal of the Authentication Exchange is to allow one Organisation, for 1146 example a financial institution, to be able to check that another 1147 Organisation, for example a consumer, is who they appear to be. 1149 An Authentication Exchange involves: 1151 o an Authenticator - the Organisation which is requesting the 1152 authentication, and 1154 o an Authenticatee - the Organisation being authenticated. 1156 This is illustrated in the diagram below. 1158 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1159 Organisation 1 1160 (Authenticatee) 1161 | Organisation 2 1162 | (Authenticator) 1163 STEP | | 1164 1. First Organisation, e.g. a Consumer, takes an action (for 1165 example by pressing a button on an HTML page) which requires 1166 that the Organisation is authenticated 1168 1 --> 2 Need for Authentication (outside scope of IOTP) 1170 2. The second Organisation generates an Authentication Request - 1171 including challenge data, and a list of the algorithms that 1172 may be used for the authentication - and/or a request for the 1173 Organisation information then sends it to the first 1174 Organisation 1176 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, 1177 Trading Role Information Request 1179 3. The first Organisation optionally checks any signature 1180 associated with the Authentication Request then uses the 1181 specified authentication algorithm to generate an 1182 Authentication Response which is sent back to the second 1183 Organisation together with details of any Organisation 1184 information requested 1186 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, 1187 Organisation(s) 1189 4. The Authentication Response is checked against the challenge 1190 data to check that the first Organisation is who they appear 1191 to be and the result recorded in a Status Component which is 1192 then sent back to the first Organisation. 1194 1 <-- 2 AUTHENTICATION STATUS. Component: Status 1196 5. The first Organisation then optionally checks the results 1197 indicated by the Status and any associated signature and 1198 takes the appropriate action or stops. 1200 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1202 Figure 5 Authentication Exchange 1204 An Authentication Exchange uses the following Trading Components that are 1205 passed between the two Organisations: 1207 o the Authentication Request Component that requests an Authentication 1208 and indicates the authentication algorithm and optional challenge data 1209 to be used. 1211 o A Trading Role Information Request Component that requests information 1212 about an Organisation, for example a ship to address. 1214 o The Authentication Response Component which contains the challenge 1215 response generated by the recipient of the Authentication Request 1216 Component. 1218 o Organisation Components that contain the result of the Trading Role 1219 Information Request 1221 o the Status Component which contains the results of the second party's 1222 verification of the Authentication Response. 1224 2.3 Scope of Baseline IOTP 1226 This specification describes the IOTP Transactions which make up Baseline 1227 IOTP. As described in the preface, IOTP will evolve over time. This 1228 section defines the initial conformance criteria for implementations that 1229 claim to "support IOTP." 1231 The main determinant on the scope of an IOTP implementation is the roles 1232 which the solution is designed to support. The roles within IOTP are 1233 described in more detail in section 2.1 Trading Roles. To summarise the 1234 roles are: Merchant, Consumer, Payment Handler, Delivery Handler and 1235 Customer Care Provider. 1237 Payment Handlers who can be of three types: 1239 o those who accept a payment as part of a purchase or make a payment as 1240 part of a refund, 1242 o those who accept value as part of a deposit transaction, or 1244 o those that issue value a withdrawal transaction 1246 The following table defines, for each role, the IOTP Transactions and 1247 Trading Blocks which must be supported for that role. 1249 Merchants 1251 ECash ECash 1252 Store Value Value Consumer Payment Delivery 1253 Issuer Acquirer Handler Handler 1255 TRANSACTIONS 1257 Purchase Must Must 1258 Merchants 1260 ECash ECash 1261 Store Value Value Consumer Payment Delivery 1262 Issuer Acquirer Handler Handler 1264 Refund Must b) 1265 Depends 1267 Authentication May Must May b) 1268 Depends 1270 Value Exchange May Must 1272 Withdrawal Must b) 1273 Depends 1275 Deposit Must b) 1276 Depends 1278 Inquiry Must Must Must May Must Must 1280 Ping Must Must Must May Must Must 1282 TRADING BLOCKS 1284 TPO Must Must Must Must 1286 TPO Selection Must Must Must Must 1288 Auth-Request a) a) a) 1289 Depends Depends Depends 1291 Auth-Reply a) a) a) 1292 Depends Depends Depends 1294 Offer Response Must Must Must Must 1296 Payment Must Must 1297 Request 1299 Payment Must Must 1300 Exchange 1302 Payment Must Must 1303 Response 1305 Delivery Must Must 1306 Request 1308 Delivery Must Must 1309 Response 1310 Merchants 1312 ECash ECash 1313 Store Value Value Consumer Payment Delivery 1314 Issuer Acquirer Handler Handler 1316 Inquiry Must Must Must Must Must Must 1317 Request 1319 Inquiry Must Must Must Must Must Must 1320 Response 1322 Ping Request Must Must Must Must Must Must 1324 Ping Response Must Must Must Must Must Must 1326 Signature Must Must Must Limited Must Must 1328 Error Must Must Must Must Must Must 1330 In the above table: 1332 o "Must" means that a Trading Role must support the Transaction or 1333 Trading Block. 1335 o "May" means that an implementation may support the Transaction or 1336 Trading Block at the option of the developer. 1338 o "Depends" means implementation of the Transaction or Trading Block 1339 depends on one of the following conditions: 1340 - if Baseline Authentication IOTP Transaction is supported; 1341 - if required by a Payment Method as defined in its IOTP Supplement 1342 document. 1344 o "Limited" means the Trading Block must be understood and its content 1345 manipulated but not in every respect. Specifically, on the Signature 1346 Block, Consumers do not have to be able to validate digital signatures. 1348 An IOTP solution must support all the IOTP Transactions and Trading 1349 Blocks required by at least one role (column) as described in the above 1350 table for that solution to be described as "supporting IOTP". 1352 3. Protocol Structure 1354 The previous section provided an introduction which explained: 1356 o Trading Roles which are the different roles which Organisations can 1357 take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler 1358 and Customer Care Provider, and 1360 o Trading Exchanges where each Trading Exchange involves the exchange of 1361 data, between Trading Roles, in the form of a set of Trading 1362 Components. 1364 This section describes: 1366 o how Trading Components are constructed into Trading Blocks and the IOTP 1367 Messages which are physically sent in the form of [XML] documents 1368 between the different Trading Roles, 1370 o how IOTP Messages are exchanged between Trading Roles to create an IOTP 1371 Transaction 1373 o the XML definitions of an IOTP Message including a Transaction 1374 Reference Block - an XML element which identifies an IOTP Transaction 1375 and the IOTP Message within it 1377 o the definitions of the XML ID Attributes which are used to identify 1378 IOTP Messages, Trading Blocks and Trading Components and how these are 1379 referred to using Element References from other XML elements 1381 o how extra XML Elements and new user defined values for existing IOTP 1382 codes can be used when Extending IOTP, 1384 o how IOTP uses the Packaged Content Element to embed data such as 1385 payment protocol messages or detailed order definitions within an IOTP 1386 Message 1388 o how IOTP Identifies Languages so that different languages can be used 1389 within IOTP Messages 1391 o how IOTP handles both Secure and Insecure Net Locations when sending 1392 messages 1394 o how an IOTP Transaction can be cancelled. 1396 3.1 Overview 1398 3.1.1 IOTP Message Structure 1400 The structure of an IOTP Message and its relationship with Trading Blocks 1401 and Trading Components is illustrated in the diagram below. 1403 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1405 IOTP MESSAGE <---------- IOTP Message - an XML Document which is 1406 | transported between the Trading Roles 1407 |-Trans Ref Block <----- Trans Ref Block - contains information which 1408 | | describes the IOTP Transaction and the IOTP 1409 | | Message. 1410 | |-Trans Id Comp. <--- Transaction Id Component - uniquely 1411 | | identifies the IOTP Transaction. The Trans Id 1412 | | Components are the same across all IOTP 1413 | | messages that comprise a single IOTP 1414 | | transaction. 1415 | |-Msg Id Comp. <----- Message Id Component - identifies and 1416 | describes an IOTP Message within an IOTP 1417 | Transaction 1418 |-Signature Block <----- Signature Block (optional) - contains one or 1419 | | more Signature Components and their 1420 | | associated Certificates 1421 | |-Signature Comp. <-- Signature Component - contains digital 1422 | | signatures. Signatures may sign digests of 1423 | | the Trans Ref Block and any Trading Component 1424 | | in any IOTP Message in the same IOTP 1425 | | transaction. 1426 | |-Certificate Comp. < Certificate Component (Optional) Used to check 1427 | the signature. 1428 |-Trading Block <------- Trading Block - an XML Element within an IOTP 1429 | |-Trading Comp. Message that contains a predefined set of 1430 | |-Trading Comp. Trading Components 1431 | |-Trading Comp. 1432 | |-Trading Comp. <--- Trading Components - XML Elements within a 1433 | Trading Block that contain a predefined set 1434 |-Trading Block of XML elements and attributes containing 1435 | |-Trading Comp. information required to support a Trading 1436 | |-Trading Comp. Exchange 1437 | |-Trading Comp. 1438 | |-Trading Comp. 1439 | |-Trading Comp. 1441 *-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 1443 Figure 6 IOTP Message Structure 1445 The diagram also introduces the concept of a Transaction Reference Block. 1446 This block contains, amongst other things, a globally unique identifier 1447 for the IOTP Transaction. Also each block and component is given an ID 1448 Attribute (see section 3.4) which is unique within an IOTP Transaction. 1449 Therefore the combination of the ID attribute and the globally unique 1450 identifier in the Transaction Reference Block is sufficient to uniquely 1451 identify any Trading Block or Trading Component. 1453 3.1.2 IOTP Transactions 1455 A predefined set of IOTP Messages exchanged between the Trading Roles 1456 constitute an IOTP Transaction. This is illustrated in the diagram below. 1458 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1460 CONSUMER MERCHANT 1461 Generate first 1462 IOTP Message 1463 --- | 1464 | | v 1465 Process incoming | I | ------------- 1466 IOTP Message & <------------- | | ------------ | IOTP Message | 1467 generate next IOTP | | ------------- 1468 Message | N | 1469 | | | 1470 v | | 1471 ------------- | T | Process incoming 1472 | IOTP Message | -------------- | | -----------> IOTP Message & 1473 ------------- | | generate next 1474 | E | IOTP Message 1475 | | | 1476 | | v 1477 Process incoming | R | ------------- 1478 IOTP Message <------------- | | ------------ | IOTP Message | 1479 generate last IOTP | | ------------- 1480 Message & stop | N | 1481 | | | 1482 v | | 1483 ------------- | E | Process last 1484 | IOTP Message | -------------- | | -------------> incoming IOTP 1485 ------------- | | Message & stop 1486 | | T | | 1487 v | | v 1488 STOP --- STOP 1490 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 1492 Figure 7 An IOTP Transaction 1494 In the above diagram the Internet is shown as the transport mechanism. 1495 This is not necessarily the case. IOTP Messages can be transported using 1496 a variety of transport mechanisms. 1498 The IOTP Transactions (see section 9) in this version of IOTP are 1499 specifically: 1501 o Purchase. This supports a purchase involving an offer, a payment and 1502 optionally a delivery 1504 o Refund. This supports the refund of a payment as a result of, 1505 typically, an earlier purchase 1507 o Value Exchange. This involves two payments which result in the exchange 1508 of value from one combination of currency and payment method to another 1510 o Authentication. This supports the remote authentication of one Trading 1511 Role by another Trading Role using a variety of authentication 1512 algorithms, and the provision of an Organisation Information about the 1513 Trading Role that is being authenticated for use in, for example, the 1514 creation of an offer 1516 o Withdrawal. This supports the withdrawal of electronic cash from a 1517 financial institution 1519 o Deposit. This supports the deposit of electronic cash at a financial 1520 institution 1522 o Inquiry This supports inquiries on the status of an IOTP transaction 1523 which is either in progress or is complete 1525 o Ping This supports a simple query which enables one IOTP aware 1526 application to determine whether another IOTP application running 1527 elsewhere is working or not. 1529 3.2 IOTP Message 1531 As described earlier, IOTP Messages are [XML] documents which are 1532 physically sent between the different Trading Roles that are taking part 1533 in a trade. 1535 The XML definition of an IOTP Message is as follows. 1537 1559 1563 Content: 1565 TransRefBlk This contains information which describes an IOTP 1566 Message within an IOTP Transaction (see section 1567 3.3 immediately below) 1569 AuthReqBlk, These are the Trading Blocks. 1570 AuthRespBlk, 1571 DeliveryReqBlk, The Trading Blocks present within an IOTP Message, 1572 DeliveryRespBlk and the content of a Trading Block itself is 1573 ErrorBlk dependent on the type of IOTP Transaction being 1574 InquiryReqBlk, carried out - see the definition of each 1575 InquiryRespBlk, transaction in section 9 Internet Open Trading 1576 OfferRespBlk, Protocol Transactions. 1577 PayExchBlk, 1578 PayReqBlk, Full definitions of each Trading Block are 1579 PayRespBlk, described in section 8. 1580 PingReqBlk, 1581 PingRespBlk, 1582 SigBlk, 1583 TpoBlk, 1584 TpoSelectionBlk 1586 Attributes: 1588 xmlns The [XML Namespace] definition for IOTP messages. 1590 3.2.1 XML Document Prolog 1592 The IOTP Message is the root element of the XML document. It therefore 1593 needs to be preceded by an appropriate XML Document Prolog. For example: 1595 1596 1597 1598 ... 1599 1601 3.3 Transaction Reference Block 1603 A Transaction Reference Block contains information which identifies the 1604 IOTP Transaction and IOTP Message. The Transaction Reference Block 1605 contains: 1607 o a Transaction Id Component which globally uniquely identifies the IOTP 1608 Transaction. The Transaction Id Components are the same across all IOTP 1609 messages that comprise a single IOTP transaction, 1611 o a Message Id Component which provides control information about the 1612 IOTP Message as well as uniquely identifying the IOTP Message within an 1613 IOTP Transaction, and 1615 o zero or more Related To Components which link this IOTP Transaction to 1616 either other IOTP Transactions or other events using the identifiers of 1617 those events. 1619 The definition of a Transaction Reference Block is as follows: 1621 1622 1625 Attributes: 1627 ID An identifier which uniquely identifies the 1628 Transaction Reference Block within the IOTP 1629 Transaction (see section 3.4 ID Attributes). 1631 Content: 1633 TransId See 3.3.1 Transaction Id Component immediately 1634 below. 1636 MsgId See 3.3.2 Message Id Component immediately below. 1638 RelatedTo See 3.3.3 Related To Component immediately below. 1640 3.3.1 Transaction Id Component 1642 This contains information which globally uniquely identifies the IOTP 1643 Transaction. Its definition is as follows: 1645 1646 1653 Attributes: 1655 ID An identifier which uniquely identifies the 1656 Transaction Id Component within the IOTP 1657 Transaction. 1659 Version This identifies the version of IOTP, and therefore 1660 the structure of the IOTP Messages, which the IOTP 1661 Transaction is using. 1663 IotpTransId Contains data which uniquely identifies the IOTP 1664 Transaction. It must conform to the rules for 1665 Message Ids in [RFC 822]. 1667 IotpTransTyp This is the type of IOTP Transaction being carried 1668 out. For Baseline IOTP it identifies a "standard" 1669 IOTP Transaction and implies the sequence and 1670 content of the IOTP Messages exchanged between the 1671 Trading Roles. The valid values for Baseline IOTP 1672 are: 1673 o BaselineAuthentication 1674 o BaselineDeposit 1675 o BaselinePurchase 1676 o BaselineRefund 1677 o BaselineWithdrawal 1678 o BaselineValueExchange 1679 o BaselineInquiry 1680 o BaselinePing 1682 Values of IotpTransType are managed under the 1683 procedure described in section 12 IANA 1684 Considerations which also allows user defined 1685 values of IotpTransType to be defined. 1687 In later versions of IOTP, this list will be 1688 extended to support different types of standard 1689 IOTP Transaction. It is also likely to support the 1690 type Dynamic which indicates that the sequence of 1691 steps within the transaction are non-standard. 1693 TransTimeStamp Where the system initiating the IOTP Transaction 1694 has an internal clock, it is set to the time at 1695 which the IOTP Transaction started in [UTC] 1696 format. 1698 The main purpose of this attribute is to provide 1699 an alternative way of identifying a transaction by 1700 specifying the time at which it started. 1702 Some systems, for example, hand held devices may 1703 not be able to generate a time stamp. In this 1704 case this attribute should contain the value "NA" 1705 for Not Available. 1707 3.3.2 Message Id Component 1709 The Message Id Component provides control information about the IOTP 1710 Message as well as uniquely identifying the IOTP Message within an IOTP 1711 Transaction. Its definition is as follows. 1713 1714 1724 Attributes: 1726 ID An identifier which uniquely identifies the 1727 IOTP Message within the IOTP Transaction (see 1728 section 3.4 ID Attributes). Note that if an 1729 IOTP Message is resent then the value of this 1730 attribute remains the same. 1732 RespIotpMsg This contains the ID attribute of the Message 1733 Id Component of the IOTP Message to which this 1734 IOTP Message is a response. In this way all 1735 the IOTP Messages in an IOTP Transaction are 1736 unambiguously linked together. This field is 1737 required on every IOTP Message except the 1738 first IOTP Message in an IOTP Transaction. 1740 SenderTradingRoleRef The Element Reference (see section 3.5) of the 1741 Trading Role which has generated the IOTP 1742 message. It is used to identify the Net 1743 Locations (see section 3.9) of the Trading 1744 Role to which problems Technical Errors (see 1745 section 4.1) with any of Trading Blocks should 1746 be reported. 1748 Xml:lang Defines the language used by attributes or 1749 child elements within this component, unless 1750 overridden by an xml:lang attribute on a child 1751 element. See section 3.8 Identifying 1752 Languages. 1754 LangPrefList Optional list of Language codes that conform 1755 to [XML] Language Identification. It is used 1756 by the sender to indicate, in preference 1757 sequence, the languages that the receiver of 1758 the message ideally should use when generating 1759 a response. There is no obligation on the 1760 receiver to respond using one of the indicated 1761 languages, but using one of the languages is 1762 likely to provide an improved user experience. 1764 CharSetPrefList Optional list of Character Set identifiers 1765 that conform to [XML] Characters. It is used 1766 by the sender to indicate, in preference 1767 sequence, the character sets that the receiver 1768 of the message ideally should use when 1769 generating a response. There is no obligation 1770 on the receiver to respond using one of the 1771 character sets indicated, but using one of the 1772 character sets is likely to provide an 1773 improved user experience. 1775 SoftwareId This contains information which identifies the 1776 software which generated the IOTP Message. Its 1777 purpose is to help resolve interoperability 1778 problems that might occur as a result of 1779 incompatibilities between messages produced by 1780 different software. It is a single text string 1781 in the language defined by xml:lang. It must 1782 contain, as a minimum: 1783 o the name of the software manufacturer 1784 o the name of the software 1785 o the version of the software, and 1786 o the build of the software 1788 TimeStamp Where the device sending the message has an 1789 internal clock, it is set to the time at which 1790 the IOTP Message was created in [UTC] format. 1792 3.3.3 Related To Component 1794 The Related To Component links IOTP Transactions to either other IOTP 1795 Transactions or other events using the identifiers of those events. Its 1796 definition is as follows. 1798 1799 1806 Attributes: 1808 ID An identifier which uniquely identifies the 1809 Related To Component within the IOTP Transaction. 1811 xml:lang Defines the language used by attributes or child 1812 elements within this component, unless overridden 1813 by an xml:lang attribute on a child element. See 1814 section 3.8 Identifying Languages. 1816 RelationshipType Defines the type of the relationship. Valid values 1817 are: 1818 o IotpTransaction. in which case the Packaged 1819 Content Element contains an IotpTransId of 1820 another IOTP Transaction 1821 o Reference in which case the Packaged Content 1822 Element contains the reference of some other, 1823 non-IOTP document. 1825 Values of RelationshipType are controlled under 1826 the procedures defined in section 12 IANA 1827 Considerations which also allows user defined 1828 values to be defined. 1830 Relation The Relation attribute contains a phrase in the 1831 language defined by xml:lang which describes the 1832 nature of the relationship between the IOTP 1833 transaction that contains this component and 1834 another IOTP Transaction or other event. The exact 1835 words to be used are left to the implementers of 1836 the IOTP software. 1838 The purpose of the attribute is to provide the 1839 Trading Roles involved in an IOTP Transaction with 1840 an explanation of the nature of the relationship 1841 between the transactions. 1843 Care should be taken that the words used to in the 1844 Relation attribute indicate the "direction" of the 1845 relationship correctly. For example: one 1846 transaction might be a refund for another earlier 1847 transaction. In this case the transaction which is 1848 a refund should contain in the Relation attribute 1849 words such as "refund for" rather than "refund to" 1850 or just "refund". 1852 RelnKeyWords This attribute contains keywords which could be 1853 used to help identify similar relationships, for 1854 example all refunds. It is anticipated that 1855 recommended keywords will be developed through 1856 examination of actual usage. In this version of 1857 the specification there are no specific 1858 recommendations and the keywords used are at the 1859 discretion of implementers. 1861 Content: 1863 PackagedContent The Packaged Content (see section 3.7) contains 1864 data which identifies the related transaction. Its 1865 format varies depending on the value of the 1866 RelationshipType. 1868 3.4 ID Attributes 1870 IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading 1871 Blocks), Trading Components (including the Transaction Id Component and 1872 the Signature Component) and some of their child elements are each given 1873 an XML "ID" attribute which is used to identify an instance of these XML 1874 elements. These identifiers are used so that one element can be 1875 referenced by another. All these attributes are given the attribute name 1876 ID. 1878 The values of each ID attribute are unique within an IOTP transaction 1879 i.e. the set of IOTP Messages which have the same globally unique 1880 Transaction ID Component. Also, once the ID attribute of an element has 1881 been assigned a value it is never changed. This means that whenever an 1882 element is copied, the value of the ID attribute remains the same. 1884 As a result it is possible to use these IDs to refer to and locate the 1885 content of any IOTP Message, Block or Component from any other IOTP 1886 Message, Block or Component in the same IOTP Transaction using Element 1887 References (see section 3.5). 1889 This section defines the rules for setting the values for the ID 1890 attributes of IOTP Messages, Blocks and Components. 1892 3.4.1 IOTP Message ID Attribute Definition 1894 The ID attribute of the Message Id Component of an IOTP Message must be 1895 unique within an IOTP Transaction. It's definition is as follows: 1897 IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix 1898 IotpMsgIdPrefix ::= NameChar (NameChar)* 1899 IotpMsgIdSuffix ::= Digit (Digit)* 1900 IotpMsgIdPrefix Apart from messages which contain: an Inquiry 1901 Request Trading Block, an Inquiry Response Trading 1902 Block, a Ping Request Trading Block or a Ping 1903 Response Trading Block; then the same prefix is 1904 used for all messages sent by the Merchant or 1905 Consumer role as follows: 1906 o "M" - Merchant 1907 o "C" - Consumer 1909 For messages which contain an Inquiry Request 1910 Trading Block or a Ping Request Trading Block, the 1911 prefix is set to "I" for Inquiry. 1913 For messages which contain an Inquiry Response 1914 Trading Block or a Ping Response Trading Block, 1915 the prefix is set to "Q". 1917 The prefix for the other roles in a trade is 1918 contained within the Organisation Component for 1919 the role and are typically set by the Merchant. 1920 The following is recommended as a guideline and 1921 must not be relied upon: 1922 o "P" - First (only) Payment Handler 1923 o "R" - Second Payment Handler 1924 o "D" - Delivery Handler 1925 o "C" - Deliver To 1927 As a guideline, prefixes should be limited to one 1928 character. 1930 NameChar has the same definition as the [XML] 1931 definition of NameChar. 1933 IotpMsgIdSuffix The suffix consists of one or more digits. The 1934 suffix must be unique within a Trading Role within 1935 an IOTP Transaction. The following is recommended 1936 as a guideline and must not be relied upon: 1937 o the first IOTP Message sent by a trading role 1938 is given the suffix "1" 1939 o the second and subsequent IOTP Messages sent 1940 by the same trading role are incremented by one 1941 for each message 1942 o no leading zeroes are included in the suffix 1944 Put more simply the Message Id Component of the 1945 first IOTP Message sent by a Consumer would have 1946 an ID attribute of, "C1", the second "C2", the 1947 third "C3" etc. 1949 Digit has the same definition as the [XML] 1950 definition of Digit. 1952 3.4.2 Block and Component ID Attribute Definitions 1954 The ID Attribute of Blocks and Components must also be unique within an 1955 IOTP Transaction. Their definition is as follows: 1957 BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix 1958 IdSuffix ::= Digit (Digit)* 1960 IotpMsgId_value The ID attribute of the Message ID Component of 1961 the IOTP Message where the Block or Component is 1962 first used. 1964 In IOTP, Trading Components and Trading Blocks are 1965 copied from one IOTP Message to another. The ID 1966 attribute does not change when an existing Trading 1967 Block or Component is copied to another IOTP 1968 Message. 1970 IdSuffix The suffix consists of one or more digits. The 1971 suffix must be unique within the ID attribute of 1972 the Message ID Component used to generate the ID 1973 attribute. The following is recommended as a 1974 guideline and must not be relied upon: 1975 o the first Block or Component sent by a trading 1976 role is given the suffix "1" 1977 o the ID attributes of the second and subsequent 1978 Blocks or Components are incremented by one for 1979 each new Block or Component added to an IOTP 1980 Message 1981 o no leading zeroes are included in the suffix 1983 Put more simply, the first new Block or Component 1984 added to the second IOTP Message sent, for 1985 example, by a consumer would have a an ID 1986 attribute of "C2.1", the second "C2.2", the third 1987 "C2.3" etc. 1989 Digit has the same definition as the [XML] 1990 definition of Digit. 1992 3.4.3 Example of use of ID Attributes 1994 The diagram below illustrates how ID attribute values are used. 1996 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1998 1st IOTP MESSAGE 2nd IOTP MESSAGE 1999 (e.g. from Merchant to (e.g. from Consumer to 2000 Consumer Payment Handler) 2002 IOTP MESSAGE IOTP MESSAGE * 2003 |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* 2004 | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp. 2006 | | Copy Element | | ID=M1.2 2007 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * 2008 | | 2009 |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* 2010 | |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15 2011 | Copy Element | 2012 |-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 * 2013 | |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4 2014 | | Copy Element | 2015 | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5 2016 | | Copy Element | 2017 | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * 2018 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * 2019 | 2020 |-Trading Block. ID=M1.9 2021 |-Comp. ID=M1.10 * = new elements 2022 |-Comp. ID=M1.11 2023 |-Comp. ID=M1.12 2024 |-Comp. ID=M1.13 2026 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2028 Figure 8 Example use of ID attributes 2030 3.5 Element References 2032 A Trading Component or one of its child XML elements, may contain an XML 2033 attribute that refers to another Block (i.e. a Transaction Reference 2034 Block or a Trading Block) or Trading Component (including a Transaction 2035 Id and Signature Component). These Element References are used for many 2036 purposes, a few examples include: 2038 o identifying an XML element whose Digest is included in a Signature 2039 Component, 2041 o referring to the Payment Handler Organisation Component which is used 2042 when making a Payment 2044 An Element Reference always contains the value of an ID attribute of a 2045 Block or Component. 2047 Identifying the IOTP Message, Trading Block or Trading Component which is 2048 referred to by an Element Reference, involves finding the XML element 2049 which: 2051 o belongs to the same IOTP Transaction (i.e. the Transaction Id 2052 Components of the IOTP Messages match), and 2054 o where the value of the ID attribute of the element matches the value of 2055 the Element Reference. 2057 [Note] The term "match" in this specification has the same definition 2058 as the [XML] definition of match. 2059 [Note End] 2061 An example of "matching" an Element Reference is illustrated in the 2062 example below. 2064 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 2066 1st IOTP MESSAGE 2nd IOTP MESSAGE 2067 (e.g. from Merchant to (e.g. from Consumer to 2068 Consumer Payment Handler) 2070 IOTP MESSAGE IOTP MESSAGE 2071 |-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1 2072 | |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2 2073 | | must be | | 2074 | |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1 2075 | ^ | 2076 |-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5 2077 | |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15 2078 | AND | 2079 |-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2 2080 | |-Comp. ID=M1.4 | |-Comp. ID=M1.4 2081 | | v | 2082 | |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5 2083 | | and El Ref | 2084 | |-Comp. ID=M1.6 values must |-Comp. ID=C1.3 2085 | | match--------|--> El Ref=M1.5 2086 | |-Comp. ID=M1.7 |-Comp. ID=C1.4 2087 | 2088 |-Trading Block. ID=M1.9 2089 |-Comp. ID=M1.10 2090 |-Comp. ID=M1.11 2091 |-Comp. ID=M1.12 2092 |-Comp. ID=M1.13 2094 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- 2096 Figure 9 Element References 2098 [Note] Element Reference attributes are defined as "NMTOKEN" rather 2099 than "IDREF" (see [XML]). This is because an IDREF requires 2100 that the XML element referred to is in the same XML Document. 2101 With IOTP this is not necessarily the case. 2102 [Note End] 2104 3.6 Extending IOTP 2106 Baseline IOTP defines a minimum protocol which systems supporting IOTP 2107 must be able to accept. As new versions of IOTP are developed, additional 2108 types of IOTP Transactions will be defined. In addition to this, Baseline 2109 and future versions of IOTP will support user extensions to IOTP through 2110 two mechanisms: 2112 o extra XML elements, and 2114 o new values for existing IOTP codes. 2116 3.6.1 Extra XML Elements 2118 The XML element and attribute names used within IOTP constitute an [XML 2119 Namespace] as identified by the xmlns attribute on the IotpMessage 2120 element. This allows IOTP to support the inclusion of additional XML 2121 elements within IOTP messages through the use of [XML Namespaces]. 2123 Using XML Namespaces, extra XML elements may be included at any level 2124 within an IOTP message including: 2126 o new Trading Blocks 2128 o new Trading Components 2130 o new XML elements within a Trading Component. 2132 The following rules apply: 2134 o any new XML element must be declared according to the rules for [XML 2135 Namespaces] 2137 o new XML elements which are either Trading Blocks or Trading Components 2138 must contain an ID attributes with an attribute name of ID. 2140 In order to make sure that extra XML elements can be processed properly, 2141 IOTP reserves the use of a special attribute, IOTP:Critical, which takes 2142 the values True or False and may appear in extra elements added to an 2143 IOTP message. 2145 The purpose of this attribute is to allow an IOTP aware application to 2146 determine if the IOTP transaction can safely continue. Specifically: 2148 o if an extra XML element has an "IOTP:Critical" attribute with a value 2149 of "True" and an IOTP aware application does not know how to process 2150 the element and its child elements, then the IOTP transaction has a 2151 Technical Error (see section 4.1) and must fail. 2153 o if an extra XML element has an "IOTP:Critical" attribute with a value 2154 of "False" then the IOTP transaction may continue if the IOTP aware 2155 application does not know how to process it. In this case: 2156 - any extra XML elements contained within an XML element defined within 2157 the IOTP namespace, must be included with that element whenever the 2158 IOTP XML element is used or copied by IOTP 2159 - the content of the extra element must be ignored except that it must 2160 be included when it is used in the creation of a digest as part of 2161 the generation of a signature 2163 o if an extra XML element has no "IOTP:Critical" attribute then it must 2164 be treated as if it had an "IOTP:Critical" attribute with a value of 2165 "True" 2167 o if an XML element contains an "IOTP:Critical" attribute, then the value 2168 of that attribute is assumed to apply to all the child elements within 2169 that element 2171 In order to ensure that documents containing "IOTP:Critical" are valid, 2172 it is declared as part of the DTD for the extra element as: 2174 IOTP:Critical (True | False ) 'True' 2176 3.6.2 Opaque Embedded Data 2178 If IOTP is to be extended using Opaque Embedded Data then a Packaged 2179 Content Element (see section 3.7) should be used to encapsulate the data. 2181 3.7 Packaged Content Element 2183 The Packaged Content element supports the concept of an embedded data 2184 stream, transformed to both protect it against misinterpretation by 2185 transporting systems and to ensure XML compatibility. Examples of its use 2186 in IOTP include: 2188 o to encapsulate payment scheme messages, such as SET messages, 2190 o to encapsulate a description of an order, a payment note, or a delivery 2191 note. 2193 In general it is used to encapsulate one or more data streams. 2195 This data stream has three standardised attributes that allow for 2196 identification, decoding and interpretation of the contents. Its 2197 definition is as follows. 2199 2200 2205 Attributes: 2207 Name Optional. Distinguishes between multiple 2208 occurrences of Packaged Content Elements at the 2209 same point in IOTP. For example: 2210 2211 2212 snroasdfnas934k 2213 2214 2215 dvdsjnl5poidsdsflkjnw45 2216 2217 2219 The name attribute may be omitted, for example if 2220 there is only one Packaged Content element. 2222 Content This identifies what type of data is contained 2223 within the Content of the Packaged Content 2224 Element. The valid values for the Content 2225 attribute are as follows: 2226 o PCDATA. The content of the Packaged Content 2227 Element can be treated as PCDATA with no 2228 further processing. 2229 o MIME. The content of the Packaged Content 2230 Element is a complete MIME item. Processing 2231 should include looking for MIME headers inside 2232 the Packaged Content Element. 2233 o MIME:mimetype. The content of the Packaged 2234 Content Element is MIME content, with the 2235 following header "Content-Type: mimetype". 2236 Although it is possible to have MIME:mimetype 2237 with the Transform attribute set to NONE, it is 2238 far more likely to have Transform attribute set 2239 to BASE64. Note that if Transform is NONE is 2240 used, then the entire content must still 2241 conform to PCDATA. Some characters will need to 2242 be encoded either as the XML default entities, 2243 or as numeric character entities. 2244 o XML. The content of the Packaged Content 2245 Element can be treated as an XML document. 2246 Entities and CDATA sections, or Transform set 2247 to BASE64, must be used to ensure that the 2248 Packaged Content Element contents are 2249 legitimate PCDATA. 2251 Values of the Content attribute are controlled 2252 under the procedures defined in section 12 IANA 2253 Considerations which also allows user defined 2254 values to be defined. 2256 Transform This identifies the transformation that has been 2257 done to the data before it was placed in the 2258 content. Valid values are: 2260 o NONE. The PCDATA content of the Packaged 2261 Content Element is the correct representation 2262 of the data. Note that entity expansion must 2263 occur first (i.e. replacement of & and 2264 ) before the data is examined. CDATA 2265 sections may legitimately occur in a Packaged 2266 Content Element where the Transform attribute 2267 is set to NONE. 2268 o BASE64. The PCDATA content of the Packaged 2269 Content Element represents a BASE64 encoding of 2270 the actual content. 2272 Content: 2274 PCDATA This is the actual data which has been embedded. 2275 The format of the data and rules on how to decode 2276 it are contained in the Content and the Transform 2277 attributes 2279 Note that any special details, especially custom attributes, must be 2280 represented at a higher level. 2282 3.7.1 Packaging HTML 2284 The packaged content may contain HTML. In this case the following 2285 conventions are followed: 2287 o references to any documents, images or other things, such as sounds or 2288 web pages, which can affect the recipient's understanding of the data 2289 which is being packaged must refer to other Packaged Elements contained 2290 within the same parent element, e.g. an Order Description 2292 o if more than one Packaged Content element is included within a parent 2293 element in order to meet the previous requirement, then the Name 2294 attribute of the top level Packaged Content from which references to 2295 all other Packaged Elements can be determined, should have a value of 2296 Main 2298 o relative references to other documents, images, etc. from one Packaged 2299 Content element to another are realised by setting the value of the 2300 relative reference to the Name attribute of another Packaged Content 2301 element at the same level and within the same parent element 2303 o no external references that require the reference to be resolved 2304 immediately should be used. As this could make the HTML difficult or 2305 impossible to display completely 2307 o [MIME] is used to encapsulate the data inside each Packaged Element. 2308 This means that the information in the MIME header used to identify the 2309 type of data which has been encapsulated and therefore how it should be 2310 displayed. 2312 If the above conventions are not followed by, for example, including 2313 external references which must be resolved, then the recipient of the 2314 HTML should be informed. 2316 [Note] As an implementation guideline the values of the Name 2317 Attributes allocated to Packaged Content elements should make 2318 it possible to extract each Packaged Content into a directory 2319 and then display the HTML directly 2320 [Note End] 2322 3.7.2 Packaging XML 2324 Support for XML is recommended. When XML needs to be displayed, for 2325 example to display the content of an Order Description to a Consumer, 2326 then implementers should follow the latest recommendations of the World 2327 Wide Web Consortium. 2329 [Note] At the time of writing this specification, standards are under 2330 development that specify XML style sheets that show how XML 2331 documents should be displayed. See: 2332 o "Extensible Stylesheet Language (XSL) Specification" at 2333 http://www.w3.org/TR/WD-xsl, and 2334 o "Associating stylesheets with XML documents" at 2335 http://www.w3.org/TR/xml-stylesheet. 2337 Once these standards become W3C "Recommendations", then it is 2338 anticipated that this specification will be amended if 2339 practical. 2340 [Note End] 2342 3.8 Identifying Languages 2344 IOTP uses [XML] Language Identification to specify which languages are 2345 used within the content and attributes of IOTP Messages. 2347 The following principles have been used in order to determine which XML 2348 elements contain an xml:lang Attributes: 2350 o a mandatory xml:lang attribute is contained on every Trading Component 2351 which contains attributes or content which may need to be displayed or 2352 printed in a particular language 2354 o an optional xml:lang attribute is included on child elements of these 2355 Trading Components. In this case the value of xml:lang, if present, 2356 overrides the value for the Trading Component. 2358 xml:lang attributes which follow these principles are included in the 2359 Trading Components and their child XML elements defined in section 7. 2361 A sender of a message, typically a Consumer can indicate a preference for 2362 a language, and a character set by specifying a list of preferred 2363 languages/character sets in a Message Id Component (see section 3.3.2). 2364 Note that there is no obligation on the receiver of such a message to 2365 respond using one of the listed languages/character sets as they may not 2366 have the technology to be able to do it. It also means that the ability 2367 to handle these lists is not a requirement for conformance to this 2368 specification. However the ability to respond, for example using one of 2369 the stated languages/character sets is likely to provide a better user 2370 experience. 2372 3.9 Secure and Insecure Net Locations 2374 IOTP contains several "Net Locations" which identify places where, 2375 typically, IOTP Messages may be sent. Net Locations come in two types: 2377 o "Secure" Net Locations which are net locations where privacy of data is 2378 secured using, for example, encryption methods such as [SSL/TLS], and 2380 o "Insecure" Net Locations where privacy of data is not assured. 2382 Note that either a Secure Net Location or an Insecure Net Location or 2383 both must be present. 2385 If only one of the two Net Locations is present, then the one present 2386 must be used. 2388 Where both types of net location are present then either may be used 2389 depending on the preference of the sender of the message. 2391 3.10 Cancelled Transactions 2393 Any Trading Role involved in an IOTP transaction may cancel that 2394 transaction at any time. 2396 3.10.1 Cancelling Transactions 2398 IOTP Transactions are cancelled by sending an IOTP message containing 2399 just a Cancel Block with an appropriate Status Component to the other 2400 Trading Role involved in the Trading Exchange. 2402 [Note] The Cancel Block can be sent asynchronously of any other IOTP 2403 Message. Specifically it can be sent either before sending or 2404 after receiving an IOTP Message from the other Trading Role 2405 [Note End] 2407 If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the 2408 interval between sending a "request" block and receiving the matching 2409 "response" block) then the Cancel Block is sent to the same location as 2410 the next IOTP Message in the Trading Exchange would have been sent. 2412 If a Consumer cancels a transaction after a Trading Exchange has 2413 completed (i.e. the "response" block for the Trading Exchange has been 2414 received), but before the IOTP Transaction has finished then the Consumer 2415 sends a Cancel Block with an appropriate Status Component to the net 2416 location identified by the SenderNetLocn or SecureSenderNetLocn contained 2417 in the Protocol Options Component (see section 7.1) contained in the TPO 2418 Block (see section 8.1) for the transaction. This is normally the 2419 Merchant Trading Role. 2421 A Consumer should not send a Cancel Block after the IOTP Transaction has 2422 completed. Cancelling a complete transaction should be treated as a 2423 technical error. 2425 After cancelling the IOTP Transaction, the Consumer should go to the net 2426 location specified by the CancelNetLocn attribute contained in the 2427 Trading Role Element for the Organisation that was sent the Cancel Block. 2429 A non-Consumer Trading Role should only cancel a transaction: 2431 o after a request block has been received and 2433 o before the response block has been sent 2435 If a non-Consumer Trading Role cancels a transaction at any other time it 2436 should be treated by the recipient as an error. 2438 3.10.2 Handling Cancelled Transactions 2440 If a Cancel Block is received by a Consumer at a point in the IOTP 2441 Transaction when cancellation is allowed, then the Consumer should stop 2442 the transaction. 2444 If a Cancel Block is received by a non-Consumer role, then the Trading 2445 Role should anticipate that the Consumer may go to the location specified 2446 by the CancelNetLocn attribute contained in the Trading Role Element for 2447 the Trading Role. 2449 4. IOTP Error Handling 2451 IOTP is designed as a request/response protocol where each message is 2452 composed of a number of Trading Blocks which contain a number of Trading 2453 Components. There are several interrelated considerations in handling 2454 errors, re-transmissions, duplicates, and the like. These factors mean 2455 IOTP aware applications must manage message flows more complex than the 2456 simple request/response model. Also a wide variety of errors can occur in 2457 messages as well as at the transport level or in Trading Blocks or 2458 Components. 2460 This section describes at a high level how IOTP handles errors, retries 2461 and idempotency. It covers: 2463 o the different types of errors which can occur. This is divided into: 2464 - "technical errors" which are independent of the purpose of the IOTP 2465 Message, 2466 - "business errors" which indicate that there is a problem specific to 2467 the process (e.g. payment or delivery) which is being carried out, 2468 and 2470 o the depth of the error which indicates whether the error is at the 2471 transport, message or block/component level 2473 o how the different trading roles should handle the different types of 2474 messages which they may receive. 2476 4.1 Technical Errors 2478 Technical Errors are those which are independent of the meaning of the 2479 message. This means, they can affect any attempt at IOTP communication. 2480 Typically they are handled in a standard fashion with a limited number of 2481 standard options for the user. Specifically these are: 2483 o retrying the transmission, or 2485 o cancelling the transaction. 2487 When communications are operating sufficiently well, a technical error is 2488 indicated by an Error Component (see section 7.21) in an Error Block (see 2489 section 8.17) sent by the party which detected the error in an IOTP 2490 message to the party which sent the erroneous message. 2492 If communications are too poor, a message which was sent may not reach 2493 its destination. In this case a time-out might occur. 2495 The Error Codes associated with Technical Errors are recorded in the 2496 Error Component which lists all the different technical errors which can 2497 be set. 2499 4.2 Business Errors 2501 Business Errors may occur when the IOTP messages are "technically" 2502 correct. They are connected with a particular process, for example, an 2503 offer, payment, delivery or authentication, where each process has a 2504 different set of possible business errors. 2506 For example, "Insufficient funds" is a reasonable payment error but makes 2507 no sense for a delivery while "Back ordered" is a reasonable delivery 2508 error but not meaningful for a payment. Business errors are indicated in 2509 the Status Component (see section 7.16) of a "response block" of the 2510 appropriate type, for example a Payment Response Block or a Delivery 2511 Response Block. This allows whatever additional response related 2512 information is needed to accompany the error indication. 2514 Business errors must usually be presented to the user so that they can 2515 decide what to do next. For example, if the error is insufficient funds 2516 in a Brand Independent Offer (see section 9.1.2.2), the user might wish 2517 to choose a different payment instrument/account of the same brand or a 2518 different brand or payment system. Alternatively, if the IOTP based 2519 implementation allows it and it makes sense for that instrument, the user 2520 might want to put more funds into the instrument/account and try again. 2522 4.3 Error Depth 2524 The three levels at which IOTP errors can occur are the transport level, 2525 the message level, and the block level. Each is described below. 2527 4.3.1 Transport Level 2529 This level of error indicates a fundamental problem in the transport 2530 mechanism over which the IOTP communication is taking place. 2532 All transport level errors are technical errors and are indicated by 2533 either an explicit transport level error indication, such as a "No route 2534 to destination" error from TCP/IP, or by a time out where no response has 2535 been received to a request. 2537 The only reasonable automatic action when faced with transport level 2538 errors is to retry and, after some number of automatic retries, to inform 2539 the user. 2541 The explicit error indications that can be received are transport 2542 dependent and the documentation for the appropriate IOTP Transport 2543 supplement should be consulted for errors and appropriate actions. 2545 Appropriate time outs to use are a function of both the transport being 2546 used and of the payment system if the request encapsulates payment 2547 information. The transport and payment system specific documentation 2548 should be consulted for time out and automatic retry parameters. 2549 Frequently there is no way to directly inform the other party of 2550 transport level errors but they should generally be logged and if 2551 automatic recovery is unsuccessful and there is a human user, the user 2552 should be informed. 2554 4.3.2 Message Level 2556 This level of error indicates a fundamental technical problem with an 2557 entire IOTP message. For example, the XML is not "Well Formed", or the 2558 message is too large for the receiver to handle or there are errors in 2559 the Transaction Reference Block (see section 3.3) so it is not possible 2560 to figure out what transaction the message relates to. 2562 All message level errors are technical errors and are indicated by Error 2563 Components (see section 7.21) sent to the other party. The Error 2564 Component includes a Severity attribute which indicates whether the error 2565 is a Warning and may be ignored, a TransientError which indicates that a 2566 retry may resolve the problem or a HardError in which case the 2567 transaction must fail. 2569 The Technical Errors (see section 7.21.2 Error Codes) that are Message 2570 Level errors are: 2572 o XML not well formed. The document is not well formed XML (see [XML]) 2574 o XML not valid. The document is not valid XML (see [XML]) 2576 o block level technical errors (see section 4.3.3) on the Transaction 2577 Reference Block (see section 3.3) and the Signature Block only. Checks 2578 on these blocks should only be carried out if the XML is valid 2580 Note that checks on the Signature Block include checking, where possible, 2581 that each Signature Component is correctly calculated. If the Signature 2582 is incorrectly calculated then the data that should have been covered by 2583 the signature can not be trusted and must be treated as erroneous. A 2584 description of how to check a signature is correctly calculated is 2585 contained in section 6.2. 2587 4.3.3 Block Level 2589 A Block level error indicates a problem with a block or one of its 2590 components in an IOTP message (apart from Transaction Reference or 2591 Signature Blocks). The message has been transported properly, the overall 2592 message structure and the block/component(s) including the Transaction 2593 Reference and Signature Blocks are meaningful but there is some error 2594 related to one of the other blocks. 2596 Block level errors can be either: 2598 o technical errors, or 2600 o business errors 2601 Technical Errors are further divided into: 2603 o Block Level Attribute and Element Checks, and 2605 o Block and Component Consistency Checks 2607 o Transient Technical Errors 2609 If a technical error occurs related to a block or component, then an 2610 Error Component is generated for return. 2612 4.3.3.1 Block Level Attribute and Element Checks 2614 Block Level Attribute and Element Checks occur only within the same 2615 block. Checks which involve cross-checking against other blocks are 2616 covered by Block and Component Consistency Checks. 2618 The Block Level Attribute & Element checks are: 2620 o checking that each attribute value within each element in a block 2621 conforms to any rules contained within this IOTP specification 2623 o checking that the content of each element conforms to any rules 2624 contained within this IOTP specification 2626 o if the previous checks are OK, then checking the consistency of 2627 attribute values and element content against other attribute values or 2628 element content within any other components in the same block. 2630 4.3.3.2 Block and Component Consistency Checks 2632 Block and Component Consistency Checks consist of: 2634 o checking that the combination of blocks and/or components present in 2635 the IOTP Message are consistent with the rules contained within this 2636 IOTP specification 2638 o checking for consistency between attributes and element content within 2639 the blocks within the same IOTP message. 2641 o checking for consistency between attributes and elements in blocks in 2642 this IOTP message and blocks received in earlier IOTP messages for the 2643 same IOTP transaction 2645 If the block passes the "Block Level Attribute and Element Checks" and 2646 the "Block and Component Consistency Checks" then it is processed either 2647 by the IOTP Aware application or perhaps by some "back-end" system such 2648 as a payment server. 2650 4.3.3.3 Transient Technical Errors 2652 During the processing of the Block some temporary failure may occur that 2653 can potentially be recovered by the other trading role re-transmitting, 2654 at some slightly later time, the original message that they sent. 2656 In this case the other role is informed of the Transient Error by sending 2657 them an Error Component (see section 7.21) with the Severity Attribute 2658 set to TransientError and the MinRetrySecs attribute set to some value 2659 suitable for the Transport Mechanism and/or payment protocol being used 2660 (see appropriate Transport and payment protocol Supplements). 2662 Note that transient technical errors can be generated by any of the 2663 Trading Roles involved in transaction. 2665 4.3.3.4 Block Level Business Errors 2667 If a business error occurs in a process such as a Payment or a Delivery, 2668 then the appropriate type of response block is returned containing a 2669 Status Component (see section 7.16) with the ProcessState attribute set 2670 to Failed and the CompletionCode indicating the nature of the problem. 2672 Some business errors may be "transient" in that the Consumer role may be 2673 able to recover and complete the transaction in some other way. For 2674 example if the Credit Card that a consumer provided had insufficient 2675 funds for a purchase, then the Consumer may recover by using a different 2676 credit card. 2678 Recovery from "transient" business errors is dependent on the 2679 CompletionCode. See the definition of the Status Component for what is 2680 possible. 2682 Note that no Error Component or Error Block is generated for business 2683 errors. 2685 4.4 Idempotency, Processing Sequence, and Message Flow 2687 IOTP messages are actually a combination of blocks and components as 2688 described in 3.1.1 IOTP Message Structure. Especially in future 2689 extensions of IOTP, a rich variety of combinations of such blocks and 2690 components can occur. It is important that the multiple 2691 transmission/receipt of the "same" request for an action that will change 2692 state does not result in that action occurring more than once. This is 2693 called idempotency. For example, a customer paying for an order would 2694 want to pay the full amount only once. Most network transport mechanisms 2695 have some probability of delivering a message more than once or not at 2696 all, perhaps requiring retransmission. On the other hand, a request for 2697 status can reasonably be repeated and should be processed fresh each time 2698 it is received. 2700 Correct implementation of IOTP can be modelled by a particular processing 2701 order as detailed below. Any other method that is indistinguishable in 2702 the messages sent between the parties is equally acceptable. 2704 4.5 Server Role Processing Sequence 2706 "Server roles" are any Trading Role which is not the Consumer role. They 2707 are "Server roles" since they typically receive a request which they must 2708 service and then produce a response. However server roles can also 2709 initiate transactions. More specifically Server Roles must be able to: 2711 o Initiate a transaction (see section 4.5.1). These are divided into: 2712 - payment related transactions and 2713 - infrastructure transactions 2715 o Accept and process a message received from another role (see section 2716 4.5.2). This includes: 2717 - identifying if the message belongs to a transaction that has been 2718 received before 2719 - handling duplicate messages 2720 - generating Transient errors if the servers that process the input 2721 message are too busy to handle it 2722 - processing the message if it is error free, authorised and, if 2723 appropriate, producing a response to send back to the other role 2725 o Cancel a current transaction if requested (see section 4.5.3) 2727 o Re-transmit messages if a response was expected but has not been 2728 received in a reasonable time (see section 4.5.4). 2730 4.5.1 Initiating Transactions 2732 Server Roles may initiate a variety of different types of transaction. 2733 Specifically: 2735 o an Inquiry Transaction (see section 9.2.1) 2737 o a Ping Transaction (see section 9.2.2) 2739 o an Authentication Transaction (see section 9.1.6) 2741 o a Payment Related Transaction such as: 2742 - a Deposit (see section 9.1.7) 2743 - a Purchase (see section 9.1.8) 2744 - a Refund (see section 9.1.9) 2745 - a Withdrawal (see section 9.1.10) 2746 - a Value Exchange (see section 9.1.11) 2748 4.5.2 Processing Input Messages 2750 Processing input messages involves the following: 2752 o checking the structure and identity of the message 2754 o checking for and handling duplicate messages 2755 o processing non-duplicate original messages which includes: 2756 - checking for errors, then if no errors are found 2757 - processing the message to produce an output message if appropriate 2759 Each of these is discussed in more detail below. 2761 4.5.2.1 Checking Structure and Message Identity 2763 It is critical to check that the message is "well formed" XML and that 2764 the transaction identifier (IotpTransId attribute on the TransId 2765 Component) within the IOTP message can be successfully identified since 2766 an IotpTransId will be needed to generate a response. 2768 If the input message is not well formed then generate an Error Component 2769 with a Severity of HardError and ErrorCode of XmlNotWellFrmd. 2771 If the message is well formed but the IotpTransId cannot be identified 2772 then generate an ErrorComponent with: 2774 o a Severity of HardError and an ErrorCode of AttMissing, 2776 o a PackagedContent containing "IotpTransId" - the missing attribute. 2778 Insert the Error Component inside an Error Block with a new TransactionId 2779 component with a new IotpTransId and return it to the sender of the 2780 original message. 2782 4.5.2.2 Checking/Handling Duplicate Messages 2784 If the input message can be identified as potentially a valid input 2785 message then check to see if an "identical" input message has been 2786 received before. Identical means that all blocks, components, elements, 2787 attribute values and element content in the input message are the same. 2789 [Note] The recommended way of checking for identical messages is to 2790 check for equal values of their [DOM-HASH] 2791 [Note End] 2793 If an identical message has been received before then check to see if the 2794 processing of the previous message has completed. 2796 If processing has not completed then generate an Error Component with a 2797 Severity of Transient Error and an Error Code of MsgBeingProc to indicate 2798 the message is being processed and send it back to the sender of the 2799 Input Message requesting that the original message be resent after an 2800 appropriate period of time. 2802 Otherwise, if processing has completed and resulted in an output message 2803 then retrieve the last message that was sent and send it again. 2805 If the message is not a duplicate then it should be processed. 2807 4.5.2.3 Processing Non-Duplicate Message 2809 Once it's been established that the message is not a duplicate, then it 2810 can be processed. This involves: 2812 o checking that a server is available to handle the message, generating a 2813 Transient Error if it is not 2815 o checking the Transaction is Not Already in error or cancelled 2817 o validating the input message. This includes: 2818 - checking for message level errors 2819 - checking for block level errors 2820 - checking any encapsulated data 2822 o checking for errors in the sequence that blocks have been received 2824 o generating error components for any errors that result 2826 o if neither hard errors nor transient errors result, then processing the 2827 message and generating an output message, if required, for return to 2828 the sender of the Input Message 2830 [Note] This approach to handling of duplicate input messages means, 2831 if absolutely "identical" messages are received then 2832 absolutely "identical" messages are returned. This also 2833 applies to Inquiry and Ping transactions when in reality the 2834 state of a transaction or the processing ability of the 2835 servers may have changed. If up-to-date status of transactions 2836 or servers is required, then an IOTP transaction with a new 2837 value for the ID attribute of the MsgId component must be 2838 used. 2839 [Note End] 2841 Each of the above steps is discussed below. 2843 CHECKING A SERVER IS AVAILABLE 2845 The process that is handling the input message should check that the rest 2846 of the system is not so busy that a response in a reasonable time cannot 2847 be produced. 2849 If the server is too busy, then it should generate an Error Component 2850 with a Severity of Transient Error and an Error Code of SystemBusy and 2851 send it back to the sender of the Input Message requesting that the 2852 original message be resent after an appropriate period of time. 2854 [Note] Some servers may occasionally become very busy due to 2855 unexpected increases in workload. This approach allows short 2856 peaks in workloads to be handled by delaying the input of 2857 messages by asking the sender of the message to resubmit 2858 later. 2859 [Note End] 2860 CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED 2862 Check that: 2864 o previous messages received or sent did not contain or result in Hard 2865 Errors, and 2867 o the Transaction has not been cancelled by either the Consumer or the 2868 Server Trading Role 2870 If it has then, ignore the message. A transaction with hard errors or 2871 that has been cancelled, cannot be restarted. 2873 CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS 2875 If the transaction is still OK then check for message level errors. This 2876 involves: 2878 o checking the XML is valid 2880 o checking that the elements, attributes and content of the Transaction 2881 Reference Block are without error and conform to this specification 2883 o checking the digital signature which involves: 2884 - checking that the Signature value is correctly calculated, and 2885 - the hash values in the digests are correctly calculated where the 2886 source of the hash value is available. 2888 Checking for block level errors involves: 2890 o checking within each block (apart from the Transaction Reference Block) 2891 that: 2892 - the attributes, elements and element contents are valid 2893 - the values of the attributes, elements and element contents are 2894 consistent within the block 2896 o checking that the combination of blocks are valid 2898 o checking that the values of the attribute, elements and element 2899 contents are consistent between the blocks in the input message and 2900 blocks in earlier messages either sent or received. This includes 2901 checking that the presence of a block is valid for a particular 2902 transaction type 2904 If the message contains any encapsulated data, then if possible check the 2905 encapsulated data for errors using additional software to check the data 2906 where appropriate. 2908 4.5.2.4 Check for Errors in Block Sequence 2910 [Note] For reasons of brevity, the following explanations of how to 2911 check for errors in Block sequence, the phrase "refers to an 2912 IOTP transaction" is interpreted as "is contained in an IOTP 2913 Message where the Trans Ref Block contains an IotpTransId that 2914 refers to". So, for example, " If an Error or Cancel Block 2915 refers to an IOTP transaction that is not recognised then ..." 2916 should be interpreted as " If an Error or Cancel Block is 2917 contained in an IOTP Message where the Trans Ref Block 2918 contains an IotpTransId that refers to an IOTP transaction 2919 that is not recognised then ... 2920 [Note End] 2922 Errors in the sequence that blocks arrive depends on the block. Blocks 2923 where checking for sequence is required are: 2925 o Error and Cancel Blocks. If an Error or Cancel Block refers to an IOTP 2926 transaction that is not recognised then it is a Hard Error. Do not 2927 return an error if Error or Cancel Blocks have been received for the 2928 IOTP Transaction before to avoid looping. 2930 o Inquiry Request and Response Blocks. If an Inquiry Request or an 2931 Inquiry Response Block refers to an IOTP transaction that is not 2932 recognised then it is a Hard Error 2934 o Authentication Request Block. If an Authentication Request Block refers 2935 to an IOTP transaction that is recognised it is a Hard Error 2937 o Authentication Response Block. Check as follows: 2938 - if an Authentication Response Block does not refer to an IOTP 2939 transaction that is recognised it is a Hard Error, otherwise 2940 - if the Authentication Response Block doesn't refer to an 2941 Authentication Request that had been previously sent then it is a 2942 Hard Error, otherwise 2943 - if an Authentication Response for the same IOTP transaction has been 2944 received before and the Authentication was successful then it is a 2945 Hard Error. 2947 o Authentication Status Block. Check as follows: 2948 - if an Authentication Status Block does not refer to an IOTP 2949 transaction that is recognised it is a Hard Error, otherwise 2950 - if the Authentication Status Block doesn't refer to an Authentication 2951 Response that had been previously sent then it is a Hard Error, 2952 otherwise 2953 - if an Authentication Status for the same IOTP transaction has been 2954 received before then it is a Warning Error 2956 o TPO Selection Block (Merchant only). Check as follows: 2957 - if the TPO Selection Block doesn't refer to an IOTP Transaction that 2958 is recognised then it is a Hard Error, otherwise 2959 - if the TPO Selection Block refers to an IOTP Transaction where a TPO 2960 Block and Offer Response (in one message) had previously been sent 2961 then it is a Hard Error, otherwise 2962 - if the TPO Selection Block does not refer to an IOTP Transaction 2963 where a TPO Block only (i.e. without an Offer Response) had 2964 previously been sent then it is a Hard Error, otherwise 2965 - if a TPO Selection Block for the same TPO Block has been received 2966 before then it is a Hard Error 2968 o Payment Request Block (Payment Handler only). Check as follows: 2969 - if the Payment Request Block refers to an IOTP Transaction that is 2970 not recognised then its OK, otherwise 2971 - if the Payment Request Block refers to IOTP Transaction that was not 2972 for a Payment then it is a Hard Error, otherwise 2973 - if there was a previous payment that failed with a non-recoverable 2974 Completion Code then it is a Hard Error, otherwise 2975 - if a previous payment is still in progress then it is a Hard Error 2977 o Payment Exchange Block (Payment Handler only). Check as follows: 2978 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 2979 that is recognised then it is a Hard Error, otherwise 2980 - if the Payment Exchange doesn't refer to an IOTP Transaction where a 2981 Payment Exchange had previously been sent then it a Hard Error 2983 o Delivery Request (Delivery Handler Only). If the Delivery Request Block 2984 refers to an IOTP Transaction that is recognised by the Server then it 2985 is a Hard Error 2987 If any Error Components have been generated then collect them into an 2988 Error Block for sending to the sender of the Input message. Note that 2989 Error Blocks should be sent back to the sender of the message and to the 2990 ErrorLogNetLocn for the Trading Role of the sender if one is specified. 2992 [Note] The above checking on the sequence of Authentication Responses 2993 and Payment Requests supports the Consumer re-submitting a 2994 repeat action request since the previous one failed, for 2995 example: 2996 o because they did not know the correct response (e.g. a 2997 password) on an authentication or, 2998 o they were unable to pay as there were insufficient funds on 2999 a credit card 3000 [Note End] 3002 PROCESS THE ERROR FREE INPUT MESSAGE 3004 If the input message passes the previous checks then it can be processed 3005 to produce an output message if required. Note that: 3007 o Inquiry Requests on Ping Transactions should be ignored 3009 o if the Input message contains an Error Block with a Transient Error 3010 then wait for the required time then resend the previous message, if a 3011 response to the earlier message has not been received 3013 o if the input message contains a Error Component with a HardError or a 3014 Cancel Block then stop all further processing of the transaction. This 3015 includes suppressing the sending of any messages currently being 3016 generated or responding to any new non-duplicate messages that are 3017 received 3019 o processing of encapsulated messages (e.g. Payment Protocol Messages) 3020 may result in additional transient errors 3022 o a digital signature can only safely be generated once all the blocks 3023 and components have been generated and it is known which elements in 3024 the message need to be signed. 3026 If an output message is generated then it should be saved so that it can 3027 be resent as required if an identical input message is received again. 3028 Note that output messages that contain transient errors are not saved so 3029 that they can be processed afresh when the input message is received 3030 again. 3032 4.5.3 Cancelling a Transaction 3034 This process is used to cancel a transaction running on an IOTP server. 3035 It is initiated by some other process as a result of an external request 3036 from another system or server that is being run by the same Trading Role. 3037 The processing required is as follows: 3039 o if the IotpTransId of the transaction to be cancelled is not 3040 recognised, or complete then fail the request, otherwise 3042 o if the IotpTransId refers to a Ping Transaction then fail the request, 3043 otherwise 3045 o determine which Document Exchange to cancel and generate a Cancel Block 3046 and send it to the other party 3048 [Note] Cancelling a transaction on an IOTP server typically arises 3049 for a business reason. For example a merchant may have 3050 attempted authentication several times without success and as 3051 a result decides to cancel the transaction. Therefore the 3052 process that decides to take this action needs to send a 3053 message from the process/server that made the business 3054 decision to the IOTP server with the instruction that the IOTP 3055 transaction should be cancelled. 3056 [Note End] 3058 4.5.4 Retransmitting Messages 3060 The server should periodically check for transactions where a message is 3061 expected in return but none has been received after a time that is 3062 dependent on factors such as: 3064 o the Transport Mechanism being used; 3066 o the time required to process encapsulated messages (e.g. Payment 3067 messages) and 3069 o whether or not human input is required. 3071 If no message has been received the original message should be resent. 3072 This should occur up to a maximum number of times dependent on the 3073 reliability of the Transport Mechanism being used. 3075 If no response is received after the required time then the Transaction 3076 should be "timed out". In this case, set the process state of the 3077 transaction to Failed, and a completion code of either: 3079 o TimedOutRcvr if the transaction can potentially recovered later, or 3081 o TimedOutNoRcvr if the transaction is non-recoverable 3083 4.6 Client Role Processing Sequence 3085 The "Client role" in IOTP is the Consumer Trading Role. 3087 [Note] A company or Organisation that is a Merchant, for example, may 3088 take on the Trading Role of a Consumer when making purchases 3089 or downloading or withdrawing electronic cash. 3090 [Note End] 3092 More specifically the Consumer Role must be able to: 3094 o Initiate a transaction (see section 4.6.1). These are divided into: 3095 - payment related transactions and 3096 - infrastructure transactions 3098 o Accept and process a message received from another role (see section 3099 4.6.2). This includes: 3100 - identifying if the message belongs to a transaction that has been 3101 received before 3102 - handling duplicate messages 3103 - generating Transient errors if the servers that process the input 3104 message are too busy to handle it 3105 - processing the message if it is error free and, if appropriate, 3106 producing a response to send back to the other role 3108 o Cancel a current transaction if requested, for example by the User (see 3109 section 4.6.3) 3111 o Re-transmit messages if a response was expected but has not been 3112 received in a reasonable time (see section 4.6.4). 3114 4.6.1 Initiating Transactions 3116 The Consumer Role may initiate a number of different types of 3117 transaction. Specifically: 3119 o an Inquiry Transaction (see section 9.2.1) 3121 o a Ping Transaction (see section 9.2.2) 3123 o an Authentication Transaction (see section 9.1.6) 3125 4.6.2 Processing Input Messages 3127 Processing of Input Messages for a Consumer Role is the same as for an 3128 IOTP Server (see section 4.5.2) except in the area of checking for Errors 3129 in Block Sequence (for an IOTP Server see section 4.5.2.4). This is 3130 described below 3132 [Note] The description of the processing for an IOTP Server includes 3133 consideration of multi-threading of input messages and multi- 3134 tasking of requests. For the Consumer Role - particularly if 3135 running on a stand-alone system such as a PC - use of multi- 3136 threading is a decision of the implementer of the consumer 3137 role IOTP solution. 3138 [Note End] 3140 4.6.2.1 Check for Errors in Block Sequence 3142 The handling of the following blocks is the same as for an IOTP Server 3143 (see section 4.5.2.4) except that the Consumer Role is substituted for 3144 IOTP Server Role: 3146 o Error and Cancel Blocks, 3148 o Inquiry Request and Response Blocks, 3150 o Authentication Request, Response and Status Blocks. 3152 For the other blocks a Consumer role might receive, the potential errors 3153 in the sequence that blocks arrive depends on the block. Blocks where 3154 checking for sequence is required are: 3156 o TPO Block. Check as follows: 3157 - if the input message also contains an Authentication Request block 3158 and an Offer Response Block then there is a Hard Error, otherwise 3159 - if the input message also contains an Authentication Request block 3160 and Authentication Status block then there is Hard Error otherwise, 3161 - if the input message also contains an Authentication Request block 3162 and the IOTP Transaction is recognised by the Consumer role's system, 3163 then there is a Hard Error, otherwise 3164 - if the input message also contains an Authentication Status block and 3165 the IOTP Transaction is not recognised by the Consumer role's system 3166 then there is a Hard Error, otherwise 3167 - if input message also contains an Authentication Status Block and the 3168 Authentication Status Block has not been sent after an earlier 3169 Authentication Response message then there is a hard error 3170 - if input message also contains an Offer Response Block and the IOTP 3171 Transaction is recognised by the Consumer role's system then there is 3172 a Hard Error, otherwise 3173 - if the TPO Block occurs on its own and the IOTP Transaction is 3174 recognised by the Consumer role's system then there is a Hard Error 3176 o Offer Response Block. Check as follows: 3177 - if the Offer Response Block is part of a Brand Independent Offer 3178 Exchange (see section 9.1.2.2) then there is no sequence checking as 3179 it is part of the first message received, otherwise 3180 - if the Offer Response Block is not part of an IOTP Transaction that 3181 is recognised by the Consumer role then there is a Hard Error, 3182 otherwise 3183 - if the Offer Response Block does not refer to an IOTP transaction 3184 where a TPO Selection Block was the last message sent then there is a 3185 Hard Error 3187 o Payment Exchange Block. Check as follows: 3188 - if the Payment Exchange Block doesn't refer to an IOTP Transaction 3189 that is recognised by the Consumer role's system then there is a Hard 3190 Error, otherwise 3191 - if the Payment Exchange doesn't refer to an IOTP Transaction where 3192 either a Payment Request or a Payment Exchange block was most 3193 recently sent then there is a Hard Error 3195 o Payment Response Block. Check as follows: 3196 - if the Payment Response Block doesn't refer to an IOTP Transaction 3197 that is recognised by the Consumer role's system then there is a Hard 3198 Error, otherwise 3199 - if the Payment Response doesn't refer to an IOTOP Transaction where 3200 either a Payment Request or a Payment Exchange block was most 3201 recently sent then there is a Hard Error 3203 o Delivery Response Block. Check as follows: 3204 - if the Delivery Response Block doesn't refer to an IOTP Transaction 3205 that is recognised by the Consumer role's system then there is a Hard 3206 Error, otherwise 3207 - If the Delivery Response doesn't refer to an IOTP Transaction where 3208 either a Payment Request or a Payment Exchange block was most 3209 recently sent then there is a Hard Error 3211 4.6.3 Cancelling a Transaction 3213 This process cancels a current transaction on an Consumer role's system 3214 as a result of an external request from the user, or another system or 3215 server in the Consumer's role. The processing is the same as for an IOTP 3216 Server (see section 4.5.3). 3218 4.6.4 Retransmitting Messages 3220 The process of retransmitting messages is the same as for an IOTP Server 3221 (see section 4.5.4). 3223 5. Security Considerations 3225 This section considers, from an IETF perspective how IOTP addresses 3226 security. The next section (see section 6. Digital Signatures and IOTP) 3227 describes how IOTP uses Digital Signatures when these are needed. 3229 This section covers: 3231 o determining whether to use digital signatures 3233 o data privacy, and 3235 o payment protocol security. 3237 5.1 Determining whether to use digital signatures 3239 The use of digital signatures within IOTP are entirely optional. IOTP can 3240 work successfully entirely without the use of digital signatures. 3242 Ultimately it is up to the Merchant, or other trading role, to decide 3243 whether IOTP Messages will include signatures, and for the Consumer to 3244 decide whether carrying out a transaction without signatures is an 3245 acceptable risk. If Merchants discover that transactions without 3246 signatures are not being accepted, then they will either: 3248 o start using signatures, 3250 o find a method of working which does not need signatures, or 3252 o accept a lower volume and value of business. 3254 A non-exhaustive list of the reasons why digital signatures might be used 3255 follows: 3257 o the Merchant (or other trading role) wants to demonstrate that they can 3258 be trusted. If, for example, a merchant generates an Offer Response 3259 Signature (see section 7.19.2) using a certificate from a trusted third 3260 party, known to the Consumer, then the Consumer can check the signature 3261 and certificate and so more reasonably rely on the offer being from the 3262 actual Organisation the Merchant claims to be. In this case signatures 3263 using asymmetric cryptography are likely to be required 3265 o the Merchant, or other Trading Role, want to generate a record of the 3266 transaction that is fit for a particular purpose. For example, with 3267 appropriate trust hierarchies, digital signatures could be checked by 3268 the Consumer to determine: 3269 - if it would be accepted by tax authorities as a valid record of a 3270 transaction, or 3271 - if some warranty, for example from a "Better Business Bureau" or 3272 similar was being provided 3274 o the Payment Handler, or Delivery Handler, needs to know that the 3275 request is unaltered and authorised. For example, in IOTP, details of 3276 how much to pay is sent to the Consumer in the Offer Response and then 3277 forwarded to the Payment Handler in a Payment Request. If the request 3278 is not signed, the Consumer could change the amount due by, for 3279 example, removing a digit. If the Payment Handler has no access to the 3280 original payment information in the Offer Response, then, without 3281 signatures, the Payment Handler cannot be sure that the data has not 3282 been altered. Similarly, if the payment information is not digitally 3283 signed, the Payment Handler cannot be sure who is the Merchant that is 3284 requesting the payment 3286 o a Payment Handler or Delivery Handler wants to provide a non-refutable 3287 record of the completion status of a Payment or Delivery. If a Payment 3288 Response or Delivery Response is signed, then the Consumer can later 3289 use the record of the Payment or Delivery to prove that it occurred. 3290 This could be used, for example, for customer care purposes. 3292 A non-exhaustive list of the reasons why digital signatures might not be 3293 used follows: 3295 o trading roles are combined therefore changes to data made by the 3296 consumer can be detected. One of the reasons for using signatures is so 3297 that one trading role can determine if data has been changed by the 3298 Consumer or some other party. However if the trading roles have access 3299 to the necessary data, then it might be possible to compare, for 3300 example, the payment information in the Payment Request with the 3301 payment information in the Offer Response. Access to the data necessary 3302 could be realised by, for example, the Merchant and Payment Handler 3303 roles being carried out by the same Organisation on the same system, or 3304 the Merchant and Payment Handler roles being carried out on different 3305 systems but the systems can communicate in some way. (Note this type of 3306 communication is outside the current scope of IOTP) 3308 o the processing cost of the cryptography is too high. For example, if a 3309 payment is being made of only a few cents, the cost of carrying out all 3310 the cryptography associated with generating and checking digital 3311 signatures might make the whole transaction uneconomic. Co-locating 3312 trading roles, could help avoid this problem. 3314 5.2 Symmetric and Asymmetric Cryptography 3316 The advantage of using symmetric keys with IOTP is that no Public Key 3317 Infrastructure need be set up and just the Merchant, Payment Handler and 3318 Delivery Handler need to agree the shared secrets to use. 3320 However the disadvantage of symmetric cryptography is that the Consumer 3321 cannot easily check the credentials of the Merchant, Payment Handler, 3322 etc. that they are dealing with. This is likely to reduce, somewhat, the 3323 trust that the Consumer will have carrying out the transaction. 3325 However it should be noted that even if asymmetric cryptography is being 3326 used, the Consumer does not NEED to be provided with any digital 3327 certificates as the integrity of the transaction is determined by, for 3328 example, the Payment Handler checking the Offer Response Signature copied 3329 to the Payment Request. 3331 Note that symmetric, asymmetric or both types of cryptography may be used 3332 in a single transaction. 3334 5.3 Data Privacy 3336 Privacy of information is provided by sending IOTP Messages between the 3337 various Trading Roles using a secure channel such as [SSL/TLS]. Use of a 3338 secure channel within IOTP is optional. 3340 5.4 Payment Protocol Security 3342 IOTP is designed to be completely blind to the payment protocol being 3343 used to effect a payment. From the security perspective, this means that 3344 IOTP neither helps, nor hinders, the achievement of payment security. 3346 If it is necessary to consider payment security from an IOTP perspective, 3347 then this should be included in the payment protocol supplement which 3348 describes how IOTP supports that payment protocol. 3350 However what IOTP is designed to do is to use digital signatures to bind 3351 together the record, contained in a "response" message, of each trading 3352 exchange in a transaction. For example IOTP can bind together: an Offer, 3353 a Payment and a Delivery. 3355 6. Digital Signatures and IOTP 3357 IOTP can work successfully without using any digital signatures although 3358 in an open networking environment it will be less secure - see 5. 3359 Security Considerations for a description of the factors that need to be 3360 considered. 3362 However, this section describes how to use digital signatures in the many 3363 situations when they will be needed. Topics covered are: 3365 o an overview of how IOTP uses digital signatures 3367 o how to check a signature is correctly calculated 3369 o how Payment Handlers and Delivery Handlers check they can carry out 3370 payments or deliveries on behalf of a Merchant. 3372 6.1 How IOTP uses Digital Signatures 3374 In general, signatures when used with IOTP: 3376 o are always treated as IOTP Components (see section 7) 3378 o contain digests of one or more IOTP Components or Trading Blocks, 3379 possibly including other Signature Components, in any IOTP message 3380 within the same IOTP Transaction 3382 o identify: 3383 - which Organisation signed (originated) the signature, and 3384 - which Organisation(s) should process the signature in order to check 3385 that the Action the Organisation should take can occur. 3387 Digital certificates may be associated with digital signatures if 3388 asymmetric cryptography is being used. However if symmetric cryptography 3389 is being used, then the digital certificate will be replaced by some 3390 identifier of the secret key to use. 3392 The way in which Signatures Components digest one or more elements is 3393 illustrated in the figure below. 3395 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3397 IOTP MESSAGE SIGNATURE COMPONENT 3399 IOTP Message Signature Id = P1.3 3400 |-Trans Ref Block digest TransRefBlk |-Manifest 3401 | | ID=P1.1-----------------------------|->|-Digest of P1.1-- 3402 | |-Trans Id Comp digest TransIdComp | | | 3403 | | ID = M1.2----------------------------|->|-Digest of M1.2--| 3404 | |-Msg Id Comp. digest Signature | | | 3405 | | ID = P1 -------------------|->|-Digest of M1.5--| 3406 | | digest element | | | 3407 |-Signatures Block | -----------------|->|-Digest of M1.7--| 3408 | | ID=P1.2 | | digest element | | | 3409 | |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--| 3410 | |-Signature ID=M1.5---- | | | | | 3411 | |-Signature ID=P1.4 | | Points to | -RecipientInfo* | 3412 | |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 | 3413 | | | | Certs to use | Sig.ValueRef=P1.4 | 3414 | | | | | | | 3415 | | | | | | | 3416 |-Trading Block. ID=P1.5 | | | v | 3417 | |-Comp. ID=M1.7---------- | -Value* ID=P1.4: | 3418 | | | JtvwpMdmSfMbhK<-- 3419 | |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI 3420 | | | J8pxLjoSRfe1o6k 3421 | |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<- 3422 | |-Comp. ID=C1.5 3423 Digital signature of Manifest element 3424 using certificate identified by CertRef 3426 Elements that are digested can be in any IOTP Message 3427 within the same IOTP Transaction 3428 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3430 Figure 10 Signature Digests 3432 [Note] The classic example of one signature signing another in IOTP, 3433 is when an Offer is first signed by a Merchant creating an 3434 "Offer Response" signature, which is then later signed by a 3435 Payment Handler together with a record of the payment creating 3436 a "Payment Receipt" signature. In this way, the payment in an 3437 IOTP Transaction is bound to the Merchant's offer. 3438 [Note End] 3440 Note that one Manifest may be associated with multiple signature "Value" 3441 elements where each Value element contains a digital signature over the 3442 same Manifest, perhaps using the same (or different) signature algorithm 3443 but using a different certificate or shared secret key. Specifically it 3444 will allow the Merchant to agree different shared secrets keys with their 3445 Payment Handler and Delivery Handler. 3447 The detailed definitions of a Signature component are contained in 3448 section 7.19. 3450 The remainder of this section contains: 3452 o an example of how IOTP uses signatures 3454 o how the OriginatorInfo and RecipientInfo elements within a Signature 3455 Component are used to identify the Organisations associated with the 3456 signature 3458 o how IOTP uses signatures to prove actions complete successfully 3460 6.1.1 IOTP Signature Example 3462 An example of how signatures are used is illustrated in the figure below 3463 which shows how the various components and elements in a Baseline 3464 Purchase relate to one another. Refer to this example in the later 3465 description of how signatures are used to check a payment or delivery can 3466 occur (see section 6.3). 3468 [Note] A Baseline Purchase transaction has been used for illustration 3469 purposes. The usage of the elements and attributes is the same 3470 for all types of IOTP Transactions. 3471 [Note End] 3473 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3475 TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK 3476 | (Offer Response) 3477 Brand Selection Organisation<--- |------Signature 3478 Component Component | | Component 3479 | | | -Manifest 3480 |BrandList -Trading Role | | 3481 | Ref Element | Originator |-Orig. 3482 v (Merchant) ------------|--Info 3483 Brand List Ref | 3484 >Component | 3485 | |-Protocol ------> Organisation Recipient |-Recipient 3486 | | Amount Elem | Component <------------------|--Info 3487 | | | | | Refs | 3488 | |Pay|Protocol |Action -Trading Role | 3489 | | | Ref |OrgRef Element | 3490 | | v | (Payment Handler) | 3491 | -PayProtocol-- | 3492 | Elem ->Organisation Recipient |-Recipient 3493 | | Component <--------------------Info 3494 | | | Refs 3495 | | -Trading Role 3496 | | Element 3497 | | (Delivery Handler 3498 | 3499 | OFFER RESPONSE BLOCK 3500 | | 3501 |BrandListRef |ActionOrgRef 3502 | | 3503 --Payment ---Delivery 3504 Component Component 3506 The Manifest element in the Signature Component contains digests of: 3507 the Trans Ref Block (not shown); the Transaction ID Component (not 3508 shown); Organisation Components (Merchant, Payment Handler, Delivery 3509 Handler); the Brand List Component; the Order Component, the Payment 3510 Component the Delivery Component and the Brand Selection Component (if a 3511 Brand Dependent Purchase). 3513 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3515 Figure 11 Example use of Signatures for Baseline Purchase 3517 6.1.2 OriginatorInfo and RecipientInfo Elements 3519 The OriginatorRef attribute of the OriginatorInfo element in the 3520 Signature Component contains an Element Reference (see section 3.5) that 3521 points to the Organisation Component of the Organisation which generated 3522 the Signature. In this example its the Merchant. 3524 Note that the value of the content of the Attribute element with a Type 3525 attribute set to IOTP Signature Type must match the Trading Role of the 3526 Organisation which signed it. If it does not, then it is an error. Valid 3527 combinations are given in the table below. 3529 IOTP Signature Type Valid Trading Role 3531 OfferResponse Merchant 3533 PaymentResponse PaymentHandler 3535 DeliveryResponse DeliveryHandler 3537 AuthenticationRequest any role 3539 AuthenticationResponse any role 3541 PingRequest any role 3543 PingResponse any role 3545 The RecipientRefs attribute of the RecipientInfo element in the Signature 3546 Component contains Element References to the Organisation Components of 3547 the Organisations that should use the signature to verify that: 3549 o they have a pre-existing relationship with the Organisation that 3550 generated the signature, 3552 o the data which is secured by the signature has not been changed, 3554 o the data has been signed correctly, and 3556 o the action they are required to undertake on behalf of the Merchant is 3557 therefore authorised. 3559 Note that if symmetric cryptography is being used then a separate 3560 RecipientInfo and Value elements for each different set of shared secret 3561 keys are likely within the Signature Component. 3563 Alternatively if asymmetric cryptography is being used then the 3564 RecpientRefs attribute of one RecipientInfo element may refer to multiple 3565 Organisation Components if they are all using the same certificates. 3567 6.1.3 Using signatures to Prove Actions Complete Successfully 3569 Proving an action completed successfully, is achieved by signing data on 3570 Response messages. Specifically: 3572 o on the Offer Response, when a Merchant is making an Offer to the 3573 Consumer which can then be sent to either: 3574 - a Payment Handler to prove that the Merchant authorises Payment, or 3575 - a Delivery Handler to prove that Merchant authorises Delivery, 3576 provided other necessary authorisations are complete (see below) 3578 o on the Payment Response, when a Payment Handler is generating a Payment 3579 Receipt which can be sent to either: 3580 - a Delivery Handler, in a Delivery Request Block to authorise Delivery 3581 together with the Offer Response signature, or 3582 - another Payment Handler, in a second Payment Request, to authorise 3583 the second payment in a Value Exchange IOTP Transaction 3585 o Delivery Response, when a Delivery Handler is generating a Delivery 3586 Note. This can be used to prove after the event what the Delivery 3587 Handler said they would do 3589 o Authentication Response. One method of authenticating another party to 3590 a trade is to send an Authentication Request specifying that a Digital 3591 Signature should be used for authentication 3593 o Transaction Status Inquiry. The Inquiry Response Block may be digitally 3594 signed to attest to the authenticity of the response 3596 o Ping. The Ping Response may be digitally signed so that checks can be 3597 made that the signature can be understood. 3599 This proof of an action may, in future versions of IOTP, also be used to 3600 prove after the event that the IOTP transaction occurred. For example to 3601 a Customer Care Provider. 3603 6.2 Checking a Signature is Correctly Calculated 3605 Checking a signature is correctly calculated is part of checking for 3606 Message Level Errors (see section 4.3.2). It is included here so that all 3607 signature and security related considerations are kept together. 3609 Before a Trading Role can check a signature it must identify which of the 3610 potentially multiple Signature elements should be checked. The steps 3611 involved are as follows: 3613 o check that a Signature Block is present and it contains one or more 3614 Signature Components 3616 o identify the Organisation Component which contains an OrgId attribute 3617 for the Organisation which is carrying out the signature check. If no 3618 or more than one Organisation Component is found then it is an error 3620 o use the ID attribute of the Organisation Component to find the 3621 RecipientInfo element that contains a RecipientRefs attribute that 3622 refers to that Organisation Component. Note there may be no signatures 3623 to verify 3625 o check the Signature Component that contains the identified 3626 RecipientInfo element as follows: 3627 - use the SignatureValueRef and the SignatureAlgorithmRef attributes to 3628 identify, respectively: the Value element that contains the signature 3629 to be checked and the Signature Algorithm element that describes the 3630 signature algorithm to be used to verify the Signature, then 3631 - if the Signature Algorithm element indicates that asymmetric 3632 cryptography is being used then use the SignatureCertRef to identify 3633 the Certificate to be used by the signature algorithm 3634 - if Signature Algorithm element indicates that symmetric cryptography 3635 is being used then the content of the RecipientInfo element is used 3636 to identify the correct shared secret key to use 3637 - use the specified signature algorithm to check that the Value Element 3638 correctly signs the Manifest Element 3639 - check that the Digest Elements in the Manifest Element are correctly 3640 calculated where Components or Blocks referenced by the Digest have 3641 been received by the Organisation checking the signature. 3643 6.3 Checking a Payment or Delivery can occur 3645 This section describes the processes required for a Payment Handler or 3646 Delivery Handler to check that a payment or delivery can occur. This may 3647 include checking signatures if this is specified by the Merchant. 3649 In outline the steps are: 3651 o check that the Payment Request or Delivery Request has been sent to the 3652 correct Organisation 3654 o check that correct IOTP components are present in the request, and 3656 o check that the payment or delivery is authorised 3658 For clarity and brevity the following terms or phrases are used in this 3659 section: 3661 o a "Request Block" is used to refer to either a Payment Request Block 3662 (see section 8.7) or a Delivery Request Block (see section 8.10) unless 3663 specified to the contrary 3665 o a "Response Block" is used to refer to either a Payment Response Block 3666 (see section 8.9) or a Delivery Response Block (see section 8.11) 3668 o an "Action" is used to refer to an action which occurs on receipt of a 3669 Request Block. Actions can be either a Payment or a Delivery 3671 o an "Action Organisation", is used to refer to the Payment Handler or 3672 Delivery Handler that carries out an Action 3674 o a "Signer of an Action", is used to refer to the Organisations that 3675 sign data about an Action to authorise the Action, either in whole or 3676 in part 3678 o a "Verifier of an Action", is used to refer to the Organisations that 3679 verify data to determine if they are authorised to carry out the Action 3681 o an ActionOrgRef attribute contains Element References which can be used 3682 to identify the "Action Organisation" that should carry out an Action 3684 6.3.1 Check Request Block sent Correct Organisation 3686 Checking the Request Block was sent to the correct Organisation varies 3687 depending on whether the request refers to a Payment or a Delivery. 3689 6.3.1.1 Payment 3691 In outline a Payment Handler checks if it can accept or make a payment by 3692 identifying the Payment Component in the Payment Request Block it has 3693 received, then using the ID of the Payment Component to track through the 3694 Brand List and Brand Selection Components to identify the Organisation 3695 selected by the Consumer and then checking that this Organisation is 3696 itself. 3698 The way data is accessed to do this is illustrated in the figure below. 3700 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3701 Start 3702 | 3703 v 3704 Brand List<--------------------------+-----------Payment 3705 Component BrandListRef | Component 3706 | | 3707 |-Brand<-------------------------- | 3708 | Element BrandRef | | 3709 | | Brand Selection 3710 | |Protocol Component 3711 | | AmountRefs | | 3712 | v Protocol | | 3713 |-Protocol Amount<---------------- | 3714 | Element---------- AmountRef | 3715 | | | | 3716 | |Currency |Pay | 3717 | | AmountRefs |Protocol | 3718 | v |Ref | 3719 |-Currency Amount | | 3720 | Element<---------|---------------- 3721 | | 3722 -PayProtocol<----- 3723 Element---------------------->Organisation 3724 Action Component 3725 OrgRef | 3726 -Trading Role 3727 Element 3728 (Payment Handler) 3730 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3731 Figure 14 Checking a Payment Handler can carry out a Payment 3733 Figure 12 Checking a Payment Handler can carry out a Payment 3735 The following describes the steps involved and the checks which need to 3736 be made: 3738 o Identify the Payment Component (see section 7.9) in the Payment Request 3739 Block that was received. 3741 o Identify the Brand List and Brand Selection Components for the Payment 3742 Component. This involves: 3743 - identifying the Brand List Component (see section 7.7) where the 3744 value of its ID attribute matches the BrandListRef attribute of the 3745 Payment Component. If no or more than one Brand List Component is 3746 found there is an error. 3747 - identifying the Brand Selection Component (see section 7.8) where the 3748 value of its BrandListRef attribute matches the BrandListRef of the 3749 Payment Component. If no or more than one matching Brand Selection 3750 Component is found there is an error. 3752 o Identify the Brand, Protocol Amount, Pay Protocol and Currency Amount 3753 elements within the Brand List that have been selected by the Consumer 3754 as follows: 3755 - the Brand Element (see section 7.7.1) selected is the element where 3756 the value of its Id attribute matches the value of the BrandRef 3757 attribute in the Brand Selection. If no or more than one matching 3758 Brand Element is found then there is an error. 3759 - the Protocol Amount Element (see section 7.7.3) selected is the 3760 element where the value of its Id attribute matches the value of the 3761 ProtocolAmountRef attribute in the Brand Selection Component. If no 3762 or more than one matching Protocol Amount Element is found there is 3763 an error 3764 - the Pay Protocol Element (see section 7.7.5) selected is the element 3765 where the value of its Id attribute matches the value of the 3766 PayProtocolRef attribute in the identified Protocol Amount Element. 3767 If no or more than one matching Pay Protocol Element is found there 3768 is an error 3769 - the Currency Amount Element (see section 7.7.4) selected is the 3770 element where the value of its Id attribute matches the value of the 3771 CurrencyAmountRef attribute in the Brand Selection Component. If no 3772 or more than one matching Currency Amount element is found there is 3773 an error 3775 o Check the consistency of the references in the Brand List and Brand 3776 Selection Components: 3777 - check that an Element Reference exists in the ProtocolAmountRefs 3778 attribute of the identified Brand Element that matches the Id 3779 attribute of the identified Protocol Amount Element. If no or more 3780 than one matching Element Reference can be found there is an error 3781 - check that the CurrencyAmountRefs attribute of the identified 3782 Protocol Amount element contains an element reference that matches 3783 the Id attribute of the identified Currency Amount element. If no or 3784 more than one matching Element Reference is found there is an error. 3785 - check the consistency of the elements in the Brand List. 3786 Specifically, the selected Brand, Protocol Amount, Pay Protocol and 3787 Currency Amount Elements are all child elements of the identified 3788 Brand List Component. If they are not there is an error. 3790 o Check that the Payment Handler that received the Payment Request Block 3791 is the Payment Handler selected by the Consumer. This involves: 3792 - identifying the Organisation Component for the Payment Handler. This 3793 is the Organisation Component where its ID attribute matches the 3794 ActionOrgRef attribute in the identified Pay Protocol Element. If no 3795 or more than one matching Organisation Component is found there is an 3796 error 3797 - checking the Organisation Component has a Trading Role Element with a 3798 Role attribute of PaymentHandler. If not there is an error 3799 - finally, if the identified Organisation Component is not the same as 3800 the Organisation that received the Payment Request Block, then there 3801 is an error. 3803 6.3.1.2 Delivery 3805 The way data is accessed by a Delivery Handler in order to check that it 3806 may carry out a delivery is illustrated in the figure below. 3808 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3809 Start 3810 | 3811 v 3812 Delivery 3813 Component 3814 | 3815 |ActionOrgRef 3816 | 3817 v 3818 Organisation 3819 Component 3820 | 3821 -Trading Role 3822 Element 3823 (Delivery Handler) 3825 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3827 Figure 13 Checking a Delivery Handler can carry out a Delivery 3829 The steps involved are as follows: 3831 o Identify the Delivery Component in the Delivery Request Block. If there 3832 is no or more than one matching Delivery Component there is an error 3834 o Use the ActionOrgRef attribute of the Delivery Component to identify 3835 the Organisation Component of the Delivery Handler. If there is no or 3836 more than one matching Organisation Component there is an error 3838 o If the Organisation Component for the Delivery Handler does not have a 3839 Trading Role Element with a Role attribute of DeliveryHandler there is 3840 an error 3842 o Finally, if the Organisation that received the Delivery Request Block 3843 does not identify the Organisation Component for the Delivery Handler 3844 as itself, then there is an error. 3846 6.3.2 Check Correct Components present in Request Block 3848 Check that the correct components are present in the Payment Request 3849 Block (see section 8.7) or in the Delivery Request Block (see section 3850 8.10). 3852 If components are missing, there is an error. 3854 6.3.3 Check an Action is Authorised 3856 The previous steps identified the Action Organisation and that all the 3857 necessary components are present. This step checks that the Action 3858 Organisation is authorised to carry out the Action. 3860 In outline the Action Organisation will identifies the Merchant, checks 3861 that it has a pre-existing agreement with the Merchant that allows it 3862 carry out the Action and that any constraints implied by that agreement 3863 are being followed, then, if signatures are required, it checks that they 3864 sign the correct data. 3866 The steps involved are as follows: 3868 o Identify the Merchant. This is the Organisation Component with a 3869 Trading Role Element which has a Role attribute with a value of 3870 Merchant. If no or more than one Trading Role Element is found, there 3871 is an error 3873 o Check the Action Organisation's agreements with the Merchant allows the 3874 Action to be carried out. To do this the Action Organisation must check 3875 that: 3877 - the Merchant is known and a pre-existing agreement exists for the 3878 Action Organisation to be their agent for the payment or delivery 3879 - they are allowed to take part in the type of IOTP transaction that is 3880 occurring. For example a Payment Handler may have agreed to accept 3881 payments as part of a Baseline Purchase, but not make payments as 3882 part of a Baseline Refund 3883 - any constraints in their agreement with the Merchant are being 3884 followed, for example, whether or not an Offer Response signature is 3885 required 3887 o Check the signatures are correct. If signatures are required then they 3888 need to be checked. This involves: 3889 - Identifying the correct signatures to check. This involves the Action 3890 Organisation identifying the Signature Components that contain 3891 references to the Action Organisation (see 6.3.1). Depending on the 3892 IOTP Transaction being carried out (see section 9) either one or two 3893 signatures may be identified 3894 - checking that the Signature Components are correct. This involves 3895 checking that Digest elements exist within the Manifest Element that 3896 refer to the necessary Trading Components (see section 6.3.3.1). 3898 6.3.3.1 Check the Signatures Digests are correct 3900 All Signature Components contained within IOTP Messages must include 3901 Digest elements that refer to: 3903 o the Transaction Id Component (see section 3.3.1) of the IOTP message 3904 that contains the Signature Component. This binds the globally unique 3905 IotpTransId to other components which make up the IOTP Transaction 3907 o the Transaction Reference Block (see section 3.3) of the first IOTP 3908 Message that contained the signature. This binds the IotpTransId with 3909 information about the IOTP Message contained inside the Message Id 3910 Component (see section 3.3.2). 3912 Check that each Signature Component contains Digest elements that refer 3913 to the correct data required. 3915 The Digest elements that need to be present depend on the Trading Role of 3916 the Organisation which generated (signed) the signature: 3918 o if the signer of the signature is a Merchant then: 3919 - Digest elements must be present for all the components in the Request 3920 Block apart from the Brand Selection Component which is optional 3922 o if the signer of the signature is a Payment Handler then Digest 3923 elements must be present for: 3924 - the Signature Component signed by the Merchant, and optionally 3925 - one or more Signature Components signed by the previous Payment 3926 Handler(s) in the Transaction. 3928 7. Trading Components 3930 This section describes the Trading Components used within IOTP. Trading 3931 Components are the child XML elements which occur immediately below a 3932 Trading Block as illustrated in the diagram below. 3934 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 3936 IOTP MESSAGE <----------- IOTP Message - an XML Document 3937 | which is transported between the 3938 | Trading Roles 3939 |-Trans Ref Block <----- Trans Ref Block - contains 3940 | | information which describes the 3941 | | IOTP Transaction and the IOTP 3942 Message. 3943 --------> | |-Trans Id Comp. <--- Transaction Id Component - 3944 | | | uniquely identifies the IOTP 3945 | | | Transaction. The Trans Id 3946 | | | Components are the same across 3947 | | | all IOTP messages that comprise 3948 | | | a single IOTP transaction. 3949 | | |-Msg Id Comp. <----- Message Id Component - 3950 | | identifies and describes an IOTP 3951 | | Message within an IOTP 3952 | | Transaction 3953 | |-Signature Block <----- Signature Block (optional) - 3954 | | | contains one or more Signature 3955 | | | Components and their associated 3956 | | | Certificates 3957 | ---> | |-Signature Comp. <-- Signature Component - contains 3958 | | | | digital signatures. Signatures 3959 | | | | may sign digests of the Trans Ref 3960 | | | | Block and any Trading Component 3961 | | | | in any IOTP Message in the same 3962 | | | | IOTP Transaction. 3963 | | | |-Certificate Comp. <- Certificate Component. Used to 3964 | | | check the signature. 3965 Trading |-Trading Block <-------- Trading Block - an XML Element 3966 Components | |-Trading Comp. within an IOTP Message that 3967 | | | |-Trading Comp. contains a predefined set of 3968 | ---> | |-Trading Comp. Trading Components 3969 | | |-Trading Comp. 3970 | | |-Trading Comp. <----- Trading Components - XML 3971 | | Elements within a Trading Block 3972 | |-Trading Block that contain a predefined set of 3973 --------> | |-Trading Comp. XML elements and attributes 3974 | |-Trading Comp. containing information required 3975 | |-Trading Comp. to support a Trading Exchange 3976 | |-Trading Comp. 3977 | |-Trading Comp. 3978 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 3979 Figure 14 Trading Components 3981 The Trading Components described in this section are listed below in 3982 approximately the sequence they are likely to be used: 3984 o Protocol Options Component 3986 o Authentication Request Component 3988 o Authentication Response Component 3990 o Trading Role Information Request Component 3992 o Order Component 3994 o Organisation Component 3996 o Brand List Component 3998 o Brand Selection Component 4000 o Payment Component 4002 o Payment Scheme Component 4004 o Payment Receipt Component 4006 o Delivery Component 4008 o Delivery Note Component 4010 o Signature Component 4012 o Certificate Component 4014 o Error Component 4016 Note that the following components are listed in other sections of this 4017 specification: 4019 o Transaction Id Component (see section 3.3.1) 4021 o Message Id Component (see section 3.3.2) 4023 7.1 Protocol Options Component 4025 Protocol options are options which apply to the IOTP Transaction as a 4026 whole. Essentially it provides a short description of the entire 4027 transaction and the net location which the Consumer role should branch to 4028 if the IOTP Transaction is successful. 4030 The definition of a Protocol Options Component is as follows. 4032 4033 4041 Attributes: 4043 ID An identifier which uniquely identifies the 4044 Protocol Options Component within the IOTP 4045 Transaction. 4047 Xml:lang Defines the language used by attributes or child 4048 elements within this component, unless 4049 overridden by an xml:lang attribute on a child 4050 element. See section 3.8 Identifying Languages. 4052 ShortDesc This contains a short description of the IOTP 4053 Transaction in the language defined by xml:lang. 4054 Its purpose is to provide an explanation of what 4055 type of IOTP Transaction is being conducted by 4056 the parties involved. 4058 It is used to facilitate selecting an individual 4059 transaction from a list of similar transactions, 4060 for example from a database of IOTP transactions 4061 which has been stored by a Consumer, Merchant, 4062 etc. 4064 SenderNetLocn This contains the non secured net location of 4065 the sender of the TPO Block in which the 4066 Protocol Options Component is contained. 4068 It is the net location to which the recipient of 4069 the TPO block should send a TPO Selection Block 4070 if required. 4072 The content of this attribute is dependent on 4073 the Transport Mechanism see the Transport 4074 Mechanism Supplement. 4076 SecureSenderNetLocn This contains the secured net location of the 4077 sender of the TPO Block in which the Protocol 4078 Options Component is contained. 4080 The content of this attribute is dependent on 4081 the Transport Mechanism see the Transport 4082 Mechanism Supplement. 4084 SuccessNetLocn This contains the net location that should be 4085 displayed after the IOTP Transaction has 4086 successfully completed. 4088 The content of this attribute is dependent on 4089 the Transport Mechanism see the Transport 4090 Mechanism Supplement. 4092 Either SenderNetLocn, SecureSenderNetLocn or both must be present. 4094 7.2 Authentication Request Component 4096 This Trading Component contains parameter data that is used in an 4097 Authentication of one Trading Role by another. Its definition is as 4098 follows. 4100 4101 4106 If required the Algorithm may use the challenge data, contained in the 4107 Packaged Content elements within the Authentication Request Component in 4108 its calculation. The format of the Packaged Contents are Algorithm 4109 dependent. 4111 Attributes: 4113 ID An identifier which uniquely identifies the 4114 Authentication Request Component within the IOTP 4115 Transaction. 4117 AuthenticationId An identifier specified by the Authenticator 4118 which, if returned by the Organisation that 4119 receives the Authentication Request, will enable 4120 the Authenticator to identify which Authentication 4121 is being referred to. 4123 ContentSoftwareId See section 14.Glossary 4125 Content: 4127 PackagedContent This contains the challenge data as one or more 4128 Packaged Content (see section 3.7) that is to be 4129 responded to using the Algorithm defined by the 4130 Algorithm element. 4132 Algorithm This contains information which describes the 4133 Algorithm (see 7.19 Signature Components) that 4134 must be used to generate the Authentication 4135 Response. 4137 The Algorithms that may be used are identified by 4138 the Name attribute of the Algorithm element. For 4139 valid values see section 12. IANA Considerations. 4141 7.3 Authentication Response Component 4143 The Authentication Response Component contains the results of an 4144 authentication request. It uses the Algorithm contained in the 4145 Authentication Request Component (see section 7.2) selected from the 4146 Authentication Request Block (see section 8.4). 4148 Depending on the Algorithm selected, the results of applying the 4149 algorithm will either be contained in a Signature Component that signs 4150 both the Authentication Response and potentially other data, or in the 4151 Packaged Content elements within the Authentication Response Component. 4152 Its definition is as follows. 4154 4155 4161 Attributes: 4163 ID An identifier which uniquely identifies the 4164 Authentication Response Component within the 4165 IOTP Transaction. 4167 AuthenticationId The Authentication identifier specified by the 4168 Authenticator that was included in the 4169 Authentication Request Component(see section 4170 7.2). This will enable the Authenticator to 4171 identify the Authentication that is being 4172 referred to. 4174 SelectedAlgorithmRef An Element Reference that identifies the 4175 Algorithm element used to generate the 4176 Authentication Response. 4178 ContentSoftwareId See section 14.Glossary. 4180 Content: 4182 PackagedContent This may contain the response generated as a 4183 result of applying the Algorithm selected from the 4184 Authentication Request Component see section 7.2. 4186 For example, for a payment specific scheme, it may 4187 contain scheme-specific data. Refer to the scheme- 4188 specific supplemental documentation for 4189 definitions of its content. 4191 7.4 Trading Role Information Request Component 4193 This Trading Component contains a list of Trading Roles (see section 2.1) 4194 about which information is being requested. The result of a Trading Role 4195 Request is a set of Organisation Components (see section 7.6) that 4196 describe each of the Trading Roles requested. 4198 Example usage includes: 4200 o a Merchant requesting that a Consumer provides Organisation Components 4201 for the Consumer and DelivTo Trading Roles 4203 o a Consumer requesting from a Merchant, information about the Payment 4204 Handlers and Delivery Handlers that the Merchant uses. 4206 Its definition is as follows. 4208 4209 4213 Attributes: 4215 ID An identifier which uniquely identifies the 4216 Trading Role Information Request Component within 4217 the IOTP Transaction. 4219 TradingRoleList Contains a list of one or more Trading Roles (see 4220 the TradingRole attribute of the Trading Role 4221 Element - section 7.6.2) for which information is 4222 being requested. 4224 7.5 Order Component 4226 An Order Component contains information about an order. Its definition is 4227 as follows. 4229 4230 4240 Attributes: 4242 ID An identifier which uniquely identifies the Order 4243 Component within the IOTP Transaction. 4245 xml:lang Defines the language used by attributes or child 4246 elements within this component, unless overridden 4247 by an xml:lang attribute on a child element. See 4248 section 3.8 Identifying Languages. 4250 OrderIdentifier This is a code, reference number or other 4251 identifier which the creator of the Order may use 4252 to identify the order. It must be unique within an 4253 IOTP Transaction. If it is used in this way, then 4254 it may remove the need to specify any content for 4255 the Order element as the reference can be used to 4256 look up the necessary information in a database. 4258 ShortDesc A short description of the order in the language 4259 defined by xml:lang. It is used to facilitate 4260 selecting an individual order from a list of 4261 orders, for example from a database of orders 4262 which has been stored by a Consumer, Merchant, 4263 etc. 4265 OkFrom The date and time in [UTC] format after which the 4266 offer made by the Merchant lapses. 4268 OkTo The date and time in [UTC] format before which a 4269 Value Acquirer may accept the offer made by the 4270 Merchant is not valid. 4272 ApplicableLaw A phrase in the language defined by xml:lang which 4273 describes the state or country of jurisdiction 4274 which will apply in resolving problems or 4275 disputes. 4277 ContentSoftwareId See section 14.Glossary. 4279 Content: 4281 PackagedContent An optional description of the order information 4282 as one or more Packaged Contents (see section 4283 3.7). 4285 7.5.1 Order Description Content 4287 The Packaged Content element will normally be required, however it may be 4288 omitted where sufficient information about the purchase can be provided 4289 in the ShortDesc attribute. If the full Order Description requires it 4290 several Packaged Content elements may be used. 4292 Although the amount and currency are likely to appear in the Packaged 4293 Content of the Order Description it is the amount and currency contained 4294 in the payment related trading components (Brand List, Brand Selection 4295 and Payment) that is authoritative. This means it is important that the 4296 amount actually being paid (as contained in the payment related trading 4297 components) is prominently displayed to the Consumer. 4299 For interoperability, implementations must support Plain Text, HTML and 4300 XML as a minimum so that it can be easily displayed. 4302 7.5.2 OkFrom and OkTo Timestamps 4304 Note that: 4306 o the OkFrom date may be later than the OkFrom date on the Payment 4307 Component (see section 7.9) associated with this order, and 4309 o similarly, the OkTo date may be earlier that the OkTo date on the 4310 Payment Component (see section 7.9). 4312 [Note] Disclaimer. The following information provided in this note 4313 does not represent formal advice of any of the authors of this 4314 specification. Readers of this specification must form their 4315 own views and seek their own legal counsel on the usefulness 4316 and applicability of this information. 4318 The merchant in the context of Internet commerce with 4319 anonymous consumers initially frames the terms of the offer on 4320 the web page, and in order to obtain the goods or services, 4321 the consumer must accept them. 4323 If there is to be a time-limited offer, it is recommended that 4324 merchants communicate this to the consumer and state in the 4325 order description in a manner which is clear to the consumer 4326 that: 4327 o the offer is time limited 4328 o the OkFrom and OkTo timestamps specify the validity of the 4329 offer 4330 o the clock, e.g. the merchant's clock, that will be used to 4331 determine the validity of the offer 4333 Also note that although the OkFrom and OkTo dates are likely 4334 to appear in the Packaged Content of the Order Description it 4335 is the dates contained in the Order Component that is 4336 authoritative. This means it is important that the OkFrom and 4337 OkTo dates actually being used is prominently displayed to the 4338 Consumer. 4339 [Note End] 4341 7.6 Organisation Component 4343 The Organisation Component provides information about an individual or an 4344 Organisation. This can be used for a variety of purposes. For example: 4346 o to describe the merchant who is selling the goods, 4348 o to identify who made a purchase, 4350 o to identify who will take delivery of goods, 4352 o to provide a customer care contact, 4354 o to describe who will be the Payment Handler. 4356 Note that the Organisation Components which must be present in an IOTP 4357 Message are dependent on the particular transaction being carried out. 4358 Refer to section 9. Internet Open Trading Protocol Transactions, for more 4359 details. 4361 Its definition is as follows. 4363 4365 4373 Attributes: 4375 ID An identifier which uniquely identifies the 4376 Organisation Component within the IOTP 4377 Transaction. 4379 xml:lang Defines the language used by attributes or child 4380 elements within this component, unless overridden 4381 by an xml:lang attribute on a child element. See 4382 section 3.8 Identifying Languages. 4384 OrgId A code which identifies the Organisation described 4385 by the Organisation Component. See 7.6.1 4386 Organisation IDs, below. 4388 LegalName For Organisations which are companies this is 4389 their legal name in the language defined by 4390 xml:lang. It is required for Organisations who 4391 have a Trading Role other than Consumer or 4392 DelivTo. 4394 ShortDesc A short description of the Organisation in the 4395 language defined by xml:lang. It is typically the 4396 name by which the Organisation is commonly known. 4397 For example, if the legal name was "Blue Meadows 4398 Financial Services Inc.". Then its short name 4399 would likely be "Blue Meadows". 4401 It is used to facilitate selecting an individual 4402 Organisation from a list of Organisations, for 4403 example from a database of Organisations involved 4404 in IOTP Transactions which has been stored by a 4405 consumer. 4407 LogoNetLocn The net location which can be used to download the 4408 logo for the Organisation. 4410 See section 10 Retrieving Logos. 4412 The content of this attribute must conform to 4413 [RFC1738]. 4415 Content: 4417 TradingRole See 7.6.2 Trading Role Element below. 4419 ContactInfo See 7.6.3 Contact Information Element below. 4421 PersonName See 7.6.4 Person Name below. 4423 PostalAddress See 7.6.5 Postal Address below. 4425 7.6.1 Organisation IDs 4427 Organisation IDs are used by one IOTP Trading Role to identify another. 4428 In order to avoid confusion, this means that these IDs must be globally 4429 unique. 4431 In principle this is achieved in the following way: 4433 o the Organisation Id for all trading roles, apart from the Consumer 4434 Trading Role, uses a domain name as their globally unique identifier, 4436 o the Organisation Id for a Consumer Trading Role is allocated by one of 4437 the other Trading Roles in an IOTP Transaction and is made unique by 4438 concatenating it with that other roles' Organisation Id, 4440 o once a Consumer is allocated an Organisation Id within an IOTP 4441 Transaction the same Organisation Id is used by all the other trading 4442 roles in that IOTP transaction to identify that Consumer. 4444 Specifically, the content of the Organisation ID is defined as follows: 4446 OrgId ::= NonConsumerOrgId | ConsumerOrgId 4447 NonConsumerOrgId ::= DomainName 4448 ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId 4449 ConsumerOrgIdPrefix ::= "Consumer:" 4451 ConsumerOrgId The Organisation ID for a Consumer consists of: 4452 o a standard prefix to identify that the 4453 Organisation Id is for a consumer, followed by 4454 o one or more characters which conform to the 4455 definition of an XML "namechar". See [XML] 4456 specifications, followed by 4457 o the NonConsumerOrgId for the Organisation 4458 which allocated the ConsumerOrgId. It is 4459 normally the Merchant role. 4461 Use of upper and lower case is not significant. 4463 NonConsumerOrgId If the Role is not Consumer then this contains the 4464 Canonical Name for the non-consumer Organisation 4465 being described by the Organisation Component. See 4466 [DNS] optionally followed by additional 4467 characters, if required, to make the 4468 NonConsumerOrgId unique. 4470 Note that a NonConsumerOrgId may not start with 4471 the ConsumerOrgIdPrefix. 4473 Use of upper and lower case is not significant. 4475 Examples of Organisation Ids follow: 4477 o newjerseybooks.com - a merchant Organisation id 4479 o westernbank.co.uk - a Payment Handler Organisation id 4481 o consumer:1000247ABH/newjerseybooks.com - a consumer Organisation id 4482 allocated by a merchant 4484 7.6.2 Trading Role Element 4486 This identifies the Trading Role of an individual or Organisation in the 4487 IOTP Transaction. Note, an Organisation may have more than one Trading 4488 Role and several roles may be present in one Organisation element. Its 4489 definition is as follows: 4491 4492 4500 Attributes: 4502 ID An identifier which uniquely identifies the 4503 Trading Role Element within the IOTP Transaction. 4505 TradingRole The trading role of the Organisation. Valid values 4506 are: 4507 o Consumer. The person or Organisation that is 4508 acting in the role of a consumer in the IOTP 4509 Transaction. 4510 o Merchant. The person or Organisation that is 4511 acting in the role of merchant in the IOTP 4512 Transaction. 4513 o PaymentHandler. The financial institution or 4514 other Organisation which is a Payment Handler 4515 for the IOTP Transaction 4516 o DeliveryHandler. The person or Organisation 4517 that is the delivering the goods or services 4518 for the IOTP Transaction 4519 o DelivTo. The person or Organisation that is 4520 receiving the delivery of goods or services in 4521 the IOTP Transaction 4522 o CustCare. The Organisation and/or individual 4523 who will provide customer care for an IOTP 4524 Transaction. 4526 Values of TradingRole are controlled under the 4527 procedures defined in section 12 IANA 4528 Considerations which also allows user defined 4529 values to be defined. 4531 IotpMsgIdPrefix Contains the prefix which must be used for all 4532 IOTP Messages sent by the Trading Role in this 4533 IOTP Transaction. The values to be used are 4534 defined in 3.4.1 IOTP Message ID Attribute 4535 Definition. 4537 CancelNetLocn This contains the net location of where the 4538 Consumer should go to if the Consumer cancels the 4539 transaction for some reason. It can be used by the 4540 Trading Role to provide a response which is more 4541 tailored to the circumstances of a particular 4542 transaction. 4544 This attribute: 4545 o must not be present when TradingRole is set to 4546 Consumer role or DelivTo, 4547 o must be present when TradingRole is set to 4548 Merchant, PaymentHandler or DeliveryHandler. 4550 The content of this attribute is dependent on the 4551 Transport Mechanism see the Transport Mechanism 4552 Supplement. 4554 ErrorNetLocn This contains the net location that should be 4555 displayed by the Consumer after the Consumer has 4556 either received or generated an Error Block 4557 containing an Error Component with the Severity 4558 attribute set to either: 4559 o HardError, 4560 o Warning but the Consumer decides to not 4561 continue with the transaction 4562 o TransientError and the transaction has 4563 subsequently timed out. 4565 See section 7.21.1 Error Processing Guidelines for 4566 more details. 4568 This attribute: 4569 o must not be present when TradingRole is set to 4570 Consumer or DelivTo, 4571 o must be present when TradingRole is set to 4572 Merchant, PaymentHandler or DeliveryHandler. 4574 The content of this attribute is dependent on the 4575 Transport Mechanism see the Transport Mechanism 4576 Supplement. 4578 ErrorLogNetLocn Optional. This contains the net location that 4579 Consumers should send IOTP Messages that contain 4580 Error Blocks with an Error Component with the 4581 Severity attribute set to either: 4582 o HardError, 4583 o Warning but the Consumer decides to not 4584 continue with the transaction 4585 o TransientError and the transaction has 4586 subsequently timed out. 4588 This attribute: 4589 o must not be present when TradingRole is set to 4590 Consumer role, 4591 o must be present when TradingRole is set to 4592 Merchant, PaymentHandler or DeliveryHandler. 4594 The content of this attribute is dependent on the 4595 Transport Mechanism see the Transport Mechanism 4596 Supplement. 4598 The ErrorLogNetLocn can be used to send error 4599 messages to the software company or some other 4600 Organisation responsible for fixing problems in 4601 the software which sent the incoming message. See 4602 section 7.21.1 Error Processing Guidelines for 4603 more details. 4605 7.6.3 Contact Information Element 4607 This contains information which can be used to contact an Organisation or 4608 an individual. All attributes are optional however at least one item of 4609 contact information should be present. Its definition is as follows. 4611 4612 4619 Attributes: 4621 xml:lang Defines the language used by attributes within 4622 this element. See section 3.8 Identifying 4623 Languages. 4625 Tel A telephone number by which the Organisation may 4626 be contacted. Note that this is a text field and 4627 no validation is carried out on it. 4629 Fax A fax number by which the Organisation may be 4630 contacted. Note that this is a text field and no 4631 validation is carried out on it. 4633 Email An email address by which the Organisation may be 4634 contacted. Note that this field should conform to 4635 the conventions for address specifications 4636 contained in [RFC822]. 4638 NetLocn A location on the Internet by which information 4639 about the Organisation may be obtained that can be 4640 displayed using a web browser. 4642 The content of this attribute must conform to 4643 [RFC1738]. 4645 7.6.4 Person Name Element 4647 This contains the name of an individual person. All fields are optional 4648 however as a minimum either the GivenName or the FamilyName should be 4649 present. Its definition is as follows. 4651 4652 4659 Attributes: 4661 xml:lang Defines the language used by attributes within 4662 this element. See section 3.8 Identifying 4663 Languages. 4665 Title A distinctive name; personal appellation, 4666 hereditary or not, denoting or implying office 4667 (e.g. judge, mayor) or nobility (e.g. duke, 4668 duchess, earl), or used in addressing or referring 4669 to a person (e.g. Mr, Mrs, Miss) 4671 GivenName The primary or main name by which a person is 4672 known amongst and identified by their family, 4673 friends and acquaintances. Otherwise known as 4674 first name or Christian Name. 4676 Initials The first letter of the secondary names (other 4677 than the Given Name) by which a person is known 4678 amongst or identified by their family, friends and 4679 acquaintances. 4681 FamilyName The name by which family of related individuals 4682 are known. It is typically the part of an 4683 individual's name which is passed on by parents to 4684 their children. 4686 7.6.5 Postal Address Element 4688 This contains an address which can be used, for example, for the physical 4689 delivery of goods, services or letters. Its definition is as follows. 4691 4692 4702 Attributes: 4704 xml:lang Defines the language used by attributes within 4705 this element. See section 3.8 Identifying 4706 Languages. 4708 AddressLine1 The first line of a postal address. e.g. "The 4709 Meadows" 4711 AddressLine2 The second line of a postal address. e.g. "Sandy 4712 Lane" 4714 CityOrTown The city of town of the address. e.g. "Carpham" 4716 StateOrRegion The state or region within a country where the 4717 city or town is placed. e.g. "Surrey" 4719 Postal Code The code known as, for example a post code or zip 4720 code, that is typically used by Postal 4721 Organisations to organise postal deliveries into 4722 efficient sequences. e.g. "KT22 1AA" 4724 Country The country for the address. e.g. "UK" 4726 LegalLocation This identifies whether the address is the 4727 Registered Address for the Organisation. At least 4728 one address for the Organisation must have a value 4729 set to True unless the Trading Role is either 4730 Consumer or DeliverTo. 4732 7.7 Brand List Component 4734 Brand List Components are contained within the Trading Protocol Options 4735 Block (see section 8.1) of the IOTP Transaction. They contains lists of: 4737 o payment Brands (see also section 11.1 Brand Definitions and Brand 4738 Selection), 4740 o amounts to be paid in the currencies that are accepted or offered by 4741 the Merchant, 4743 o the payment protocols which can be used to make payments with a Brand, 4744 and 4746 o the net locations of the Payment Handlers which accept payment for a 4747 payment protocol 4749 The definition of a Brand List Component is as follows. 4751 4753 4759 Attributes: 4761 ID An identifier which uniquely identifies the Brand 4762 List Component within the IOTP Transaction. 4764 xml:lang Defines the language used by attributes or child 4765 elements within this component, unless overridden 4766 by an xml:lang attribute on a child element. See 4767 section 3.8 Identifying Languages. 4769 ShortDesc A text description in the language defined by 4770 xml:Lang giving details of the purpose of the 4771 Brand List. This information must be displayed to 4772 the receiver of the Brand List in order to assist 4773 with making the selection. It is of particular 4774 benefit in allowing a Consumer to distinguish the 4775 purpose of a Brand List when an IOTP Transaction 4776 involves more than one payment. 4778 PayDirection Indicates the direction in which the payment for 4779 which a Brand is being selected is to be made. Its 4780 values may be: 4781 o Debit The sender of the Payment Request Block 4782 (e.g. the Consumer) to which this Brand List 4783 relates will make the payment to the Payment 4784 Handler, or 4785 o Credit The sender of the Payment Request Block 4786 to which this Brand List relates will receive a 4787 payment from the Payment Handler. 4789 Content: 4791 Brand This describes a Brand. The sequence of the Brand 4792 elements (see section 7.7.1) within the Brand List 4793 does not indicate any preference. It is 4794 recommended that software which processes this 4795 Brand List presents Brands in a sequence which the 4796 receiver of the Brand List prefers. 4798 ProtocolAmount This links a particular Brand to: 4799 o the currencies and amounts in CurrencyAmount 4800 elements that can be used with the Brand, and 4801 o the Payment Protocols and Payment Handlers, 4802 which can be used with those currencies and 4803 amounts, and a particular Brand 4805 CurrencyAmount This contains a currency code and an amount. 4807 PayProtocol This contains information about a Payment Protocol 4808 and the Payment Handler which may be used with a 4809 particular Brand. 4811 The relationships between the elements which make up the content of the 4812 Brand List is illustrated in the diagram below. 4814 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 4816 Brand List Component 4817 | ProtocolAmountRefs 4818 |-Brand Element----------------------------- 4819 | | | 4820 | - Protocol Brand Element-------- | 4821 | | | 4822 | ProtocolId| | 4823 | | | 4824 |-Protocol Amount Element<----------+------- 4825 | | | | 4826 | | | | 4827 | |CurrencyAmountRefs |Pay | 4828 | | |Protocol | 4829 | v |Ref | 4830 |-Currency Amount Element | | 4831 | Element | | 4832 | | | 4833 -PayProtocolElement<------<-------- 4835 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 4837 Figure 15 Brand List Element Relationships 4839 Examples of complete Brand Lists are contained in section 11.2 Brand List 4840 Examples. 4842 7.7.1 Brand Element 4844 A Brand Element describes a brand that can be used for making a payment. 4845 One or more of these elements is carried in each Brand List Component 4846 that has the PayDirection attribute set to Debit. Exactly one Brand 4847 Element may be carried in a Brand List Component that has the 4848 PayDirection attribute set to Credit. 4850 4851 4861 Attributes: 4863 Id Element identifier, potentially referenced in a 4864 Brand Selection Component contained in a later 4865 Payment Request message and uniquely identifies 4866 the Brand element within the IOTP Transaction. 4868 xml:lang Defines the language used by attributes and 4869 content of this element. See section 3.8 4870 Identifying Languages. 4872 BrandId This contains a unique identifier for the brand 4873 (or promotional brand). It is used to match 4874 against a list of Payment Instruments which the 4875 Consumer holds to determine whether or not the 4876 Consumer can pay using the Brand. 4878 Values of BrandId are managed under the procedure 4879 described in section 12 IANA Considerations. 4881 As values of BrandId are controlled under the 4882 procedures defined in section 12 IANA 4883 Considerations user defined values may be 4884 defined. 4886 BrandName This contains the name of the brand, for example 4887 MasterCard Credit. This is the description of the 4888 Brand which is displayed to the consumer in the 4889 Consumers language defined by xml:lang. For 4890 example it might be "American Airlines Advantage 4891 Visa". Note that this attribute is not used for 4892 matching against the payment instruments held by 4893 the Consumer. 4895 BrandLogoNetLocn The net location which can be used to download 4896 the logo for the Organisation. See section 4897 Retrieving Logos (see section 10). 4899 The content of this attribute must conform to 4900 [RFC1738]. 4902 BrandNarrative This optional attribute is designed to be used by 4903 the Merchant to indicate some special conditions 4904 or benefit which would apply if the Consumer 4905 selected that brand. For example "5% discount", 4906 "free shipping and handling", "free breakage 4907 insurance for 1 year", "double air miles apply", 4908 etc. 4910 ProtocolAmountRefs Identifies the protocols and related currencies 4911 and amounts which can be used with this Brand. 4912 Specified as a list of ID's of Protocol Amount 4913 Elements (see section 7.7.3) contained within the 4914 Brand List. 4916 ContentSoftwareId See section 14.Glossary. 4918 Content: 4920 ProtocolBrand Protocol Brand elements contain brand information 4921 to be used with a specific payment protocol (see 4922 section 7.7.2) 4924 PackagedContent Optional Packaged Content (see section 3.7) 4925 elements containing information about the brand 4926 which may be used by the payment protocol. The 4927 content of this information is defined in the 4928 supplement for a payment protocol which describes 4929 how the payment protocol works with IOTP. 4931 Example Brand Elements are contained in section 11.2 Brand List Examples. 4933 7.7.2 Protocol Brand Element 4935 The Protocol Brand Element contains information that is specific to the 4936 use of a particular Protocol with a Brand. Its definition is as follows. 4938 4939 4943 Attributes: 4945 ProtocolId This must match the value of a ProtocolId 4946 attribute in a Pay Protocol Element (see section 4947 7.7.5). 4949 The values of ProtocolId should be unique within a 4950 Brand Element otherwise there is an error. 4952 ProtocolBrandId This is the Payment Brand Id to be used with a 4953 particular payment protocol. For example, SET and 4954 EMV have their own well defined, yet different, 4955 values for the Brand Id to be used with each 4956 protocol. 4958 The valid values of this attribute are defined in 4959 the supplement for the payment protocol identified 4960 by ProtocolId that describes how the payment 4961 protocol works with IOTP. 4963 Content: 4965 PackagedContent Optional Packaged Content (see section 3.7) 4966 elements containing information about the 4967 protocol/brand which may be used by the payment 4968 protocol. The content of this information is 4969 defined in the supplement for a payment protocol 4970 which describes how the payment protocol works 4971 with IOTP. 4973 7.7.3 Protocol Amount Element 4975 The Protocol Amount element links a Brand to: 4977 o the currencies and amounts in Currency Amount Elements (see section 4978 7.7.4) that can be used with the Brand, and 4980 o the Payment Protocols and Payment Handlers defined in a Pay Protocol 4981 Element (see section 7.7.5), which can be used with those currencies 4982 and amounts. 4984 Its definition is as follows: 4986 4987 4993 Attributes: 4995 Id Element identifier, potentially referenced in a 4996 Brand element; or in a Brand Selection Component 4997 contained in a later Payment Request message 4998 which uniquely identifies the Protocol Amount 4999 element within the IOTP Transaction. 5001 PayProtocolRef Contains an Element Reference (see section 3.5) 5002 that refers to the Pay Protocol Element (see 5003 section 7.7.5) that contains the Payment Protocol 5004 and Payment Handlers that can be used with the 5005 Brand. 5007 CurrencyAmountRefs Contains a list of Element References (see 5008 section 3.5) that refer to the Currency Amount 5009 Element (see section 7.7.4) that describes the 5010 currencies and amounts that can be used with the 5011 Brand. 5013 ContentSoftwareId See section 14. Glossary. 5015 Content: 5017 PackagedContent Optional Packaged Content (see section 3.7) 5018 elements containing information about the protocol 5019 amount which may be used by the payment protocol. 5020 The content of this information is defined in the 5021 supplement for a payment protocol which describes 5022 how the payment protocol works with IOTP. 5024 Examples of Protocol Amount Elements are contained in section 11.2 Brand 5025 List Examples. 5027 7.7.4 Currency Amount Element 5029 A Currency Amount element contains: 5031 o a currency code (and its type), and 5033 o an amount. 5035 One or more of these elements is carried in each Brand List Component. 5036 Its definition is as follows: 5038 5039 5045 Attributes: 5047 Id Element identifier, potentially referenced in a 5048 Brand element; or in a Brand Selection Component 5049 contained in a later Payment Request message which 5050 uniquely identifies the Currency Amount Element 5051 within the IOTP Transaction. 5053 Amount Indicates the amount to be paid in whole and 5054 fractional units of the currency. For example 5055 $245.35 would be expressed "245.35". Note that 5056 values smaller than the smallest denomination are 5057 allowed. For example one tenth of a cent would be 5058 "0.001". 5060 CurrCodeType Indicates the domain of the CurrCode. This 5061 attribute is included so that the currency code 5062 may support non-standard "currencies" such as 5063 frequent flyer points, trading stamps, etc. Its 5064 values may be: 5065 o ISO4217-A (the default) indicates the currency 5066 code is a three character alphabetic currency 5067 code that conforms to [ISO 4217] 5068 o IOTP indicates that values of CurrCode are 5069 managed under the procedure described in 5070 section 12 IANA Considerations 5072 CurrCode A code which identifies the currency to be used in 5073 the payment. The domain of valid currency codes is 5074 defined by CurrCodeType 5076 As values of CurrCodeType are managed under the 5077 procedure described in section 12 IANA 5078 Considerations user defined values of CurrCodeType 5079 may be defined. 5081 Examples of Currency Amount Elements are contained in section 11.2 Brand 5082 List Examples. 5084 7.7.5 Pay Protocol Element 5086 A Pay Protocol element specifies details of a Payment Protocol and the 5087 Payment Handler that can be used with a Brand. One or more of these 5088 elements is carried in each Brand List. 5090 5091 5101 Attributes: 5103 Id Element identifier, potentially referenced in a 5104 Brand element; or in a Brand Selection Component 5105 contained in a later Payment Request message which 5106 uniquely identifies the Pay Protocol element 5107 within the IOTP Transaction. 5109 xml:lang Defines the language used by attributes and 5110 content of this element. See section 3.8 5111 Identifying Languages. 5113 ProtocolId Consists of a protocol name and version. For 5114 example "SETv1.0". 5116 The values of ProtocolId are defined by the 5117 payment scheme/method owners in the document that 5118 describes how to encapsulate a payment protocol 5119 within IOTP. 5121 ProtocolName A narrative description of the payment protocol 5122 and its version in the language identified by 5123 xml:lang. For example "Secure Electronic 5124 Transaction Version 1.0". Its purpose is to help 5125 provide information on the payment protocol being 5126 used if problems arise. 5128 ActionOrgRef An Element Reference (see section 3.5) to the 5129 Organisation Component for the Payment Handler for 5130 the Payment Protocol. 5132 PayReqNetLocn The Net Location indicating where an unsecured 5133 Payment Request message should be sent if this 5134 protocol choice is used. 5136 The content of this attribute is dependent on the 5137 Transport Mechanism (such must conform to 5138 [RFC1738]. 5140 SecPayReqNetLocn The Net Location indicating where a secured 5141 Payment Request message should be sent if this 5142 protocol choice is used. 5144 A secured payment involves the use of a secure 5145 channel such as [SSL/TLS] in order to communicate 5146 with the Payment Handler. 5148 The content of this attribute must conform to 5149 [RFC1738]. See also See section 3.9 Secure and 5150 Insecure Net Locations. 5152 ContentSoftwareId See section 14. Glossary. 5154 Content: 5156 PackagedContent Optional Packaged Content elements (see section 5157 3.7) containing information about the protocol 5158 which is used by the payment protocol. The content 5159 of this information is defined in the supplement 5160 for a payment protocol which describes how the 5161 payment protocol works with IOTP. An example of 5162 its use could be to include a payment protocol 5163 message. 5165 Examples of Pay Protocol Elements are contained in section 11.2 Brand 5166 List Examples. 5168 7.8 Brand Selection Component 5170 A Brand Selection Component identifies the choice of payment brand, 5171 payment protocol and the Payment Handler. This element is used: 5173 o in Payment Request messages within Baseline Purchase and Baseline Value 5174 Exchange IOTP Transactions to identify the brand, protocol and payment 5175 handler for a payment, or 5177 o to, optionally, inform a merchant in a purchase of the payment brand 5178 being used so that the offer and order details can be amended 5179 accordingly. 5181 In Baseline IOTP, the integrity of Brand Selection Components is not 5182 guaranteed. However, modification of Brand Selection Components can only 5183 cause denial of service if the payment protocol itself is secure against 5184 message modification, duplication, and swapping attacks. 5186 The definition of a Brand Selection Component is as follows. 5188 5191 5198 Attributes: 5200 ID An identifier which uniquely identifies the Brand 5201 Selection Component within the IOTP Transaction. 5203 BrandListRef The Element Reference (see section 3.5) of the 5204 Brand List Component from which a Brand is being 5205 selected 5207 BrandRef The Element Reference of a Brand element within 5208 the Brand List Component that is being selected 5209 that is to be used in the payment. 5211 ProtocolAmountRef The Element Reference of a Protocol Amount element 5212 within the Brand List Component which is to be 5213 used when making the payment. 5215 CurrencyAmountRef The Element Reference of a Currency Amount element 5216 within the Brand List Component which is to be 5217 used when making the payment. 5219 Content: 5221 BrandSelBrandInfo, This contains any additional data that 5222 BrandSelProtocolAmountInfo, may be required by a particular payment 5223 BrandSelCurrencyAmountInfo brand or protocol. See sections 7.8.1, 5224 7.8.2, and 7.8.3. 5226 The following rules apply: 5228 o the BrandListRef must contain the ID of a Brand List Component in the 5229 same IOTP Transaction 5231 o every Brand List Component in the Trading Protocol Options Block (see 5232 section 8.1) must be referenced by one and only one Brand Selection 5233 Component 5235 o the BrandRef must refer to the ID of a Brand contained within the Brand 5236 List Component referred to by BrandListRef 5238 o the ProtocolAmountRef must refer to one of the Element IDs listed in 5239 the ProtocolAmountRefs attribute of the Brand element identified by 5240 BrandRef 5242 o the CurrencyAmountRef must refer to one of the Element IDs listed in 5243 the CurrencyAmountRefs attribute of the Protocol Amount Element 5244 identified by ProtocolAmountRef. 5246 An example of a Brand Selection Component is included in 11.2 Brand List 5247 Examples. 5249 7.8.1 Brand Selection Brand Info Element 5251 The Brand Selection Brand Info Element contains any additional data that 5252 may be required by a particular payment brand. See the IOTP payment 5253 method supplement for a description of how and when it used. 5255 5256 5260 Attributes: 5262 ContentSoftwareId See section 14. Glossary. 5264 Content: 5266 PackagedContent Packaged Content elements (see section 3.7) that 5267 contain additional data that may be required by a 5268 particular payment brand. See the payment method 5269 supplement for IOTP for rules on how this is used. 5271 7.8.2 Brand Selection Protocol Amount Info Element 5273 The Brand Selection Protocol Amount Info Element contains any additional 5274 data that is payment protocol specific that may be required by a 5275 particular payment brand or payment protocol. See the IOTP payment method 5276 supplement for a description of how and when it used. 5278 5279 5283 Attributes: 5285 ContentSoftwareId See section 14. Glossary. 5287 Content: 5289 PackagedContent Packaged Content elements (see section 3.7) that 5290 may contain additional data that may be required 5291 by a particular payment brand. See the payment 5292 method supplement for IOTP for rules on how this 5293 is used. 5295 7.8.3 Brand Selection Currency Amount Info Element 5297 The Brand Selection Currency Amount Info Element contains any additional 5298 data that is payment brand and currency specific that may be required by 5299 a particular payment brand. See the IOTP payment method supplement for a 5300 description of how and when it used. 5302 5303 5307 Attributes: 5309 ContentSoftwareId See section 14. Glossary. 5311 Content: 5313 PackagedContent Packaged Content elements (see section 3.7) that 5314 contain additional data relating to the payment 5315 brand and currency. See the payment method 5316 supplement for IOTP for rules on how this is used. 5318 7.9 Payment Component 5320 A Payment Component contains information used to control how a payment is 5321 carried out. Its provides information on: 5323 o the times within which a Payment with a Payment Handler may be started 5325 o a reference to the Brand List (see section 7.7) which identifies the 5326 Brands, protocols, currencies and amounts which can be used to make a 5327 payment 5329 o whether or not a payment receipt will be provided 5331 o whether another payment precedes this payment. 5333 Its definition is as follows. 5335 5336 5344 Attributes: 5346 ID An identifier which uniquely identifies the 5347 Payment Component within the IOTP Transaction. 5349 OkFrom The date and time in [UTC] format after which a 5350 Payment Handler may accept for processing a 5351 Payment Request Block (see section 8.7) containing 5352 the Payment Component. 5354 OkTo The date and time in [UTC] format before which a 5355 Payment Handler may accept for processing a 5356 Payment Request Block containing the Payment 5357 Component. 5359 BrandListRef An Element Reference (see section 3.5) of a Brand 5360 List Component (see section 7.7) within the TPO 5361 Trading Block for the IOTP Transaction. The Brand 5362 List identifies the alternative ways in which the 5363 payment can be made. 5365 SignedPayReceipt Indicates whether or not the Payment Response 5366 Block (see section 8.9) generated by the Payment 5367 Handler for the payment must be digitally signed. 5369 StartAfter Contains Element References (see section 3.5) of 5370 other Payment Components which describe payments 5371 which must be complete before this payment can 5372 start. If no StartAfter attribute is present then 5373 there are no dependencies and the payment can 5374 start immediately 5376 7.10 Payment Scheme Component 5378 A Payment Scheme Component contains payment protocol information for a 5379 specific payment scheme which is transferred between the parties involved 5380 in a payment for example a [SET] message. Its definition is as follows. 5382 5383 5390 Attributes: 5392 ID An identifier which uniquely identifies the 5393 Payment Scheme Component within the IOTP 5394 Transaction. 5396 PaymentRef An Element Reference (see section 3.5) to the 5397 Payment Component (see section 7.9) to which 5398 this Payment Scheme Component relates. It is 5399 required unless the Payment Scheme Component is 5400 part of an Transaction Inquiry Status 5401 Transaction (see section 9.2.1). 5403 ConsumerPaymentId An identifier specified by the Consumer which, 5404 if returned by the Payment Handler in another 5405 Payment Scheme Component or by other means, will 5406 enable the Consumer to identify which payment is 5407 being referred to. 5409 PaymentHandlerPayId An identifier specified by the Payment Handler 5410 which, if returned by the Consumer in another 5411 Payment Scheme Component, or by other means, 5412 will enable the Payment Handler to identify 5413 which payment is being referred to. It is 5414 required on every Payment Scheme Component apart 5415 from the one contained in a Payment Request 5416 Block. 5418 ContentSoftwareId See section 14. Glossary. 5420 Content: 5422 PackagedContent Contains payment scheme protocol information as 5423 Packaged Content elements (see section 3.7). See 5424 the payment scheme supplement for the definition 5425 of its content. 5427 Note that: 5428 o the values of the Name attribute of each 5429 packaged content element are defined by the 5430 Payment Protocol Supplement 5431 o the value of each Name must be unique within a 5432 Payment where a Payment is defined as all 5433 Payment Scheme or Payment Receipt Components 5434 with the same value of the PaymentRef attribute 5436 7.11 Payment Receipt Component 5438 A Payment Receipt is a record of a payment which demonstrates how much 5439 money has been paid or received. It is distinct from a purchase receipt 5440 in that it contains no record of what was being purchased. 5442 Typically the content of a Payment Receipt Component will contain data 5443 which describes: 5445 o the amount paid and its currency 5447 o the date and time of the payment 5449 o internal reference numbers which identify the payment to the payment 5450 system 5452 o potentially digital signatures generated by the payment method which 5453 can be used to prove after the event that the payment occurred. 5455 If the Payment Method being used provides the facility then the Payment 5456 Receipt Component should contain payment protocol messages, or references 5457 to messages, which prove the payment occurred. 5459 The precise definition of the content is Payment Method dependent. Refer 5460 to the supplement for the payment method being used to determine the 5461 rules that apply. 5463 Information contained in the Payment Receipt Component should be 5464 displayed or otherwise made available to the Consumer. 5466 [Note] If the Payment Receipt Component contains Payment Protocol 5467 Messages, then the Messages will need to be processed by 5468 Payment Method software to convert it into a format which can 5469 be understood by the Consumer 5470 [Note End] 5472 The definition of a Payment Receipt Component is as follows. 5474 5475 5481 Attributes: 5483 ID An identifier which uniquely identifies the 5484 Payment Receipt Component within the IOTP 5485 Transaction. 5487 PaymentRef Contains an Element Reference (see section 3.5) 5488 to the Payment Component (see section 7.9) to 5489 which this payment receipt applies 5491 PayReceiptNameRefs Optionally contains a list of the values of the 5492 Name attributes of Packaged Content elements that 5493 together make up the receipt. The Packaged 5494 Content elements are contained either within: 5495 o Payment Scheme Data components exchanged 5496 between the Payment Handler and the Consumer 5497 roles during the Payment, and/or 5498 o the Payment Receipt component itself. 5500 Note that: 5501 o each payment scheme defines in its supplement 5502 the Names of the Packaged Content elements 5503 that must be listed in this attribute (if 5504 any). 5505 o if a Payment Scheme Component contains 5506 Packaged Content elements with a name that 5507 matches a name within PayReceiptNameRefs, then 5508 those Payment Scheme Components must be 5509 referenced by Digests in the Payment Response 5510 signature component (if such a signature is 5511 being used) 5513 The client software should save all the 5514 components referenced so that the payment receipt 5515 can be reconstructed when required. 5517 ContentSoftwareId See section 14. Glossary. 5519 Content: 5521 PackagedContent Optionally contains payment scheme payment receipt 5522 information as Packaged Content elements (see 5523 section 3.7). See the payment scheme supplement 5524 for the definition of its content. 5526 Note that: 5527 o the values of the Name attribute of each 5528 packaged content element are defined by the 5529 Payment Protocol Supplement 5530 o the value of each Name must be unique within a 5531 Payment where a Payment is defined as all 5532 Payment Scheme or Payment Receipt Components, 5533 with the same value of the PaymentRef attribute 5535 Note that either the PayReceiptNameRefs attribute, the PackagedContent 5536 element, or both must be present. 5538 7.12 Payment Note Component 5540 The Payment Note Component contains additional, non payment related, 5541 information which the Payment Handler wants to provide to the Consumer. 5542 For example, if a withdrawal or deposit were being made then it could 5543 contain information on the remaining balance on the account after the 5544 transfer was complete. The information should duplicate information 5545 contained within the Payment Receipt Component. 5547 Information contained in the Payment Note Component should be displayed 5548 or otherwise made available to the Consumer. For interoperability, the 5549 Payment Note Component should support, as a minimum, the content types of 5550 "Plain Text", HTML and XML. Its definition is as follows. 5552 5553 5557 Attributes: 5559 ID An identifier which uniquely identifies the 5560 Payment Receipt Component within the IOTP 5561 Transaction. 5563 ContentSoftwareId See section 14. Glossary. 5565 Content: 5567 PackagedContent Contains additional, non payment related, 5568 information which the Payment Handler wants to 5569 provide to the Consumer as one or more Packaged 5570 Content elements (see section 3.7). 5572 7.13 Delivery Component 5574 The Delivery Element contains information required to deliver goods or 5575 services. Its definition is as follows. 5577 5578 5585 Attributes: 5587 ID An identifier which uniquely identifies the 5588 Delivery Component within the IOTP Transaction. 5590 xml:lang Defines the language used by attributes or child 5591 elements within this component, unless overridden 5592 by an xml:lang attribute on a child element. See 5593 section 3.8 Identifying Languages. 5595 DelivExch Indicates if this IOTP Transaction includes the 5596 messages associated with a Delivery Exchange. 5597 Valid values are: 5598 o True indicates it does include a Delivery 5599 Exchange 5600 o False indicates it does not include a 5601 Delivery Exchange 5603 If set to true then a DeliveryData element must 5604 be present. If set to false it may be absent. 5606 DelivAndPayResp Indicates if the Delivery Response Block (see 5607 section 8.11) and the Payment Response Block (see 5608 section 8.9 ) are combined into one IOTP Message. 5609 Valid values are: 5610 o True indicates both blocks will be in the 5611 same IOTP Message, and 5612 o False indicates each block will be in a 5613 different IOTP Message 5615 DelivAndPayResp should not be true if DelivExch 5616 is False. 5618 In practice combining the Delivery Response Block 5619 and Payment Response Block is only likely to be 5620 practical if the Merchant, the Payment Handler 5621 and the Delivery Handler are the same 5622 Organisation since: 5623 o the Payment Handler must have access to Order 5624 Component information so that they know what 5625 to deliver, and 5626 o the Payment Handler must be able to carry out 5627 the delivery 5629 ActionOrgRef An Element Reference to the Organisation 5630 Component of the Delivery Handler for this 5631 delivery. 5633 Content: 5635 DeliveryData Contains details about how the delivery will be 5636 carried out. See 7.13.1 Delivery Data Element 5637 below. 5639 PackagedContent Contains "user" data defined for the Merchant 5640 which is required by the Delivery Handler as one 5641 or more Packaged Content Elements see section 3.7. 5643 7.13.1 Delivery Data Element 5645 The DeliveryData element contains information about where and how goods 5646 are to be delivered. Its definition is as follows. 5648 5649 5659 Attributes: 5661 xml:lang Defines the language used by attributes within 5662 this component. See section 3.8 Identifying 5663 Languages. 5665 OkFrom The date and time in [UTC] format after which the 5666 Delivery Handler may accept for processing a 5667 Delivery Request Block (see section 8.10). 5669 OkTo The date and time in [UTC] format before which 5670 the Delivery Handler may accept for processing a 5671 Delivery Request Block. 5673 DelivMethod Indicates the method by which goods or services 5674 may be delivered. Valid values are: 5675 o Post the goods will be delivered by post or 5676 courier 5677 o Web the goods will be delivered 5678 electronically in the Delivery Note Component 5679 o Email the goods will be delivered 5680 electronically by e-mail 5682 Values of DelivMethod are managed under the 5683 procedure described in section 12 IANA 5684 Considerations which allows user defined codes to 5685 be defined. 5687 DelivToRef The Element Reference (see section 3.4) of an 5688 Organisation Component within the IOTP 5689 Transaction which has a role of DelivTo. The 5690 information in this block is used to determine 5691 where delivery is to be made. It must be 5692 compatible with DelivMethod. Specifically if the 5693 DelivMethod is: 5694 o Post, then the there must be a Postal Address 5695 Element containing sufficient information for 5696 a postal delivery, 5697 o Web, then there are no specific requirements. 5698 The information will be sent in a web page 5699 back to the Consumer 5700 o Email, then there must be Contact Information 5701 Element with a valid e-mail address 5703 DelivReqNetLocn This contains the Net Location to which an 5704 unsecured Delivery Request Block (see section 5705 8.10) which contains the Delivery Component 5706 should be sent. 5708 The content of this attribute is dependent on the 5709 Transport Mechanism and must conform to 5710 [RFC1738]. 5712 SecDelivReqNetLocn This contains the Net Location to which a secured 5713 Delivery Request Block (see section 8.10) which 5714 contains the Delivery Component should be sent. 5716 A secured delivery request involves the use of a 5717 secure channel such as [SSL/TLS] in order to 5718 communicate with the Payment Handler. 5720 The content of this attribute is dependent on the 5721 Transport Mechanism must conform to [RFC1738]. 5723 See also Section 3.9 Secure and Insecure Net 5724 Locations. 5726 ContentSoftwareId See section 14. Glossary. 5728 Content: 5730 PackagedContent Additional information about the delivery as one 5731 or more Packaged Content elements (see section 5732 3.7) provided to the Delivery Handler by the 5733 merchant. 5735 7.14 Consumer Delivery Data Component 5737 A Consumer Delivery Data Component is used by a Consumer to specify an 5738 identifier that can be used by the Consumer to identify the Delivery. 5740 Its definition is as follows: 5742 5743 5747 Attributes: 5749 ID An identifier which uniquely identifies the 5750 Consumer Delivery Data Component within the IOTP 5751 Transaction. 5753 ConsumerDeliveryId An identifier specified by the Consumer which, if 5754 returned by the Delivery Handler will enable the 5755 Consumer to identify which Delivery is being 5756 referred to. 5758 7.15 Delivery Note Component 5760 A Delivery Note contains delivery instructions about the delivery of 5761 goods or services or potentially the actual Delivery Information itself. 5762 It is information which the person or Organisation receiving the Delivery 5763 Note can use when delivery occurs. 5765 For interoperability, the Delivery Note Component Packaged Content should 5766 support both Plain Text, HTML and XML. 5768 It's definition is as follows. 5770 5771 5777 Attributes: 5779 ID An identifier which uniquely identifies the 5780 Delivery Note Component within the IOTP 5781 Transaction. 5783 xml:lang Defines the language used by attributes or child 5784 elements within this component, unless 5785 overridden by an xml:lang attribute on a child 5786 element. See section 3.8 Identifying Languages. 5788 DelivHandlerDelivId An optional identifier specified by the Delivery 5789 Handler which, if returned by the Consumer in 5790 another Delivery Component, or by other means, 5791 will enable the Delivery Handler to identify 5792 which Delivery is being referred to. It is 5793 required on every Delivery Component apart from 5794 the one contained in a Delivery Request Block. 5796 An example use of this attribute is to contain a 5797 delivery tracking number. 5799 ContentSoftwareId See section 14. Glossary. 5801 Content: 5803 PackagedContent Contains actual delivery note information as one 5804 or more Packaged Content elements (see section 5805 3.7). 5807 [Note] If the content of the Delivery Message is a Mime message then 5808 the Delivery Note may trigger an application which causes the 5809 actual delivery to occur. 5810 [Note End] 5812 7.16 Status Component 5814 A Status Component contains status information about the business success 5815 or failure (see section 4.2) of a process. 5817 Its definition is as follows. 5819 5820 5831 Attributes: 5833 ID An identifier which uniquely identifies the Status 5834 Component within the IOTP Transaction. 5836 xml:lang Defines the language used by attributes within 5837 this component. See section 3.8 Identifying 5838 Languages. 5840 StatusType Indicates the type of Document Exchange which the 5841 Status is reporting on. It may be set to either 5842 Offer, Payment, Delivery, Authentication or 5843 Undefined. 5845 Undefined means that the type of document exchange 5846 could not be identified. This is caused by an 5847 error in the initial input message of the 5848 exchange. 5850 Values of StatusType are managed under the 5851 procedure described in section 12 IANA 5852 Considerations which also allows user defined 5853 values of StatusType to be defined. 5855 ElRef If the StatusType is not set to Undefined then 5856 ElRef contains an Element Reference (see section 5857 3.5) to the Component for which the Status is 5858 being described. It must refer to either: 5859 o an Order Component (see section 7.5), if the 5860 StatusType is Offer, 5861 o a Payment Component (see section 7.9), if the 5862 StatusType is Payment, or 5863 o a Delivery Component (see section 7.13), if 5864 the StatusType is Delivery 5865 o an Authentication Request Component (see 5866 section 7.2) if the StatusType is 5867 Authentication. 5869 ProcessState Contains a State Code which indicates the current 5870 state of the process being carried out. Valid 5871 values for ProcessState are: 5872 o NotYetStarted. A Request Block has been 5873 received but the process has not yet started 5874 o InProgress. Processing of the Request Block 5875 has started but it is not yet complete 5876 o CompletedOk. The processing of the Request 5877 Block has completed successfully without any 5878 errors 5879 o Failed. The processing of the Request Block 5880 has failed because of a Business Error (see 5881 section 4.2) 5882 o ProcessError. This value is only used when the 5883 Status Component is being used in connection 5884 with an Inquiry Request Trading Block (see 5885 section 8.12). It indicates there was a 5886 Technical Error (see section 4.1) in the 5887 Request Block which is being processed or some 5888 internal processing error. 5890 Note that this code reports on the processing of a 5891 Request Block. Further, asynchronous processing 5892 may occur after the Response Block associated with 5893 the Process has been sent. 5895 CompletionCode Indicates how the process completed. Valid values 5896 for the CompletionCode are given below together 5897 with the conditions when it must be present and 5898 indications on when recovery from failures are 5899 possible. 5901 A CompletionCode is a maximum of 14 characters 5902 long. 5904 ProcessReference This optional attribute holds a reference for the 5905 process whose status is being reported. It may 5906 hold the following values: 5907 o when StatusType is set to Offer, it should 5908 contain the OrderIdentifier from the Order 5909 Component 5910 o when StatusType is set to Payment, it should 5911 contain the PaymentHandlerPayId from the 5912 Payment Scheme Data Component 5913 o when StatusType is set to Delivery, it should 5914 contain the DelivHandlerDelivId from the 5915 Delivery Note Component 5916 o when StatusType is set to Authentication, it 5917 should contain the AuthenticationId from the 5918 Authentication Request Component 5920 This attribute should be absent in the Inquiry 5921 Request message when the Consumer has not been 5922 given such a reference number by the IOTP Service 5923 Provider. 5925 This attribute can be used inside an Inquiry 5926 Response Block (see section 8.13) to give the 5927 reference number for a transaction which has 5928 previously been unavailable. 5930 For example, the package tracking number might not 5931 be assigned at the time a delivery response was 5932 received. However, if the Consumer issues a 5933 Baseline Transaction Status Inquiry later, the 5934 Delivery Handler can put the package tracking 5935 number into this attribute in the Inquiry Response 5936 message and send it back to the Consumer. 5938 StatusDesc An optional textual description of the current 5939 status of the process in the language identified 5940 by xml:lang. 5942 7.16.1 Offer Completion Codes 5944 The Completion Code is only required if the ProcessState attribute is set 5945 to Failed. The following table contains the valid values for the 5946 CompletionCode that may be used and indicates whether or not recovery 5947 might be possible. It is recommended that the StatusDesc attribute is 5948 used to provide further explanation where appropriate. 5950 Value Description 5952 AuthError Authentication Error. The check of the 5953 Authentication Response which was carried out has 5954 failed. 5956 Recovery may be possible by the Consumer re- 5957 submitting a new Authentication Response Block with 5958 corrected information. 5960 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 5961 the transaction for some reason. This code is only 5962 valid in a Status Component contained in a Cancel 5963 Block or an Inquiry Response Block. 5965 No recovery possible. 5967 MerchCancelled Offer Cancelled. The Merchant declines to generate 5968 an offer for some reason and cancels the 5969 transaction. This code is only valid in a Status 5970 Component contained in a Cancel Block or an Inquiry 5971 Response Block. 5973 No recovery possible. 5975 Unspecified Unspecified error. There is some unknown problem or 5976 error which does not fall into one of the other 5977 CompletionCodes. 5979 No recovery possible. 5981 TimedOutRcvr Recoverable Time Out. Messages were resent but no 5982 response received. The document exchange has 5983 therefore "Timed Out". This code is only valid on a 5984 Transaction Inquiry. 5986 Recovery is possible if the last message from the 5987 other Trading Role is received again. 5989 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 5990 no response received. The document exchange has 5991 therefore "Timed Out". This code is only valid on a 5992 Transaction Inquiry. 5994 No recovery possible. 5996 7.16.2 Payment Completion Codes 5998 The CompletionCode is only required if the ProcessState attribute is set 5999 to Failed. The following table contains the valid values for the 6000 CompletionCode that may be used and indicates where recovery may be 6001 possible. It is recommended that the StatusDesc attribute is used by 6002 individual payment schemes to provide further explanation where 6003 appropriate. 6005 Value Description 6007 BrandNotSupp Brand not supported. The payment brand is not 6008 supported by the Payment Handler. 6010 See below for recovery options. 6012 CurrNotSupp Currency not supported. The currency in which the 6013 payment is to be made is not supported by either 6014 the Payment Instrument or the Payment Handler. 6016 If the payment is Brand Independent, then the 6017 Consumer may recover by selecting a different 6018 currency, if available, or a different brand. Note 6019 that this may involve a different Payment Handler. 6021 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 6022 the payment for some reason. This code is only 6023 valid in a Status Component contained in a Cancel 6024 Block or an Inquiry Response Block. 6026 Recovery is not possible. 6028 PaymtCancelled Payment Cancelled. The Payment Handler declines to 6029 complete the payment for some reason and cancels 6030 the transaction. This code is only valid in a 6031 Status Component contained in a Cancel Block or an 6032 Inquiry Response Block. 6034 See below for recovery options. 6036 AuthError Authentication Error. The Payment Scheme specific 6037 authentication check which was carried out has 6038 failed. 6040 Recovery may be possible. See the payment scheme 6041 supplement to determine what is allowed. 6043 InsuffFunds Insufficient funds. There are insufficient funds 6044 available for the payment to be made. 6046 See below for recovery options. 6048 InstBrandInvalid Payment Instrument not valid for Brand. A Payment 6049 Instrument is being used which does not correspond 6050 with the Brand selected. For example a Visa credit 6051 card is being used when MasterCard was selected as 6052 the Brand. 6054 See below for recovery options. 6056 InstNotValid Payment instrument not valid for trade. The 6057 Payment Instrument cannot be used for the proposed 6058 type of trade, for some reason. 6060 See below for recovery options. 6062 BadInstrument Bad instrument. There is a problem with the 6063 Payment Instrument being used which means that it 6064 is unable to be used for the payment. 6066 See below for recovery options. 6068 Unspecified Unspecified error. There is some unknown problem 6069 or error which does not fall into one of the other 6070 CompletionCodes. The StatusDesc attribute should 6071 provide the explanation of the cause. 6073 See below for recovery options. 6075 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6076 response received. The document exchange has 6077 therefore "Timed Out". This code is only valid on 6078 a Transaction Inquiry. 6080 Recovery is possible if the last message from the 6081 other Trading Role is received again. 6083 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but 6084 no response received. The document exchange has 6085 therefore "Timed Out". This code is only valid on 6086 a Transaction Inquiry. 6088 No recovery possible. 6090 If the Payment is Brand Independent, then recovery may be possible for 6091 some values of the Completion Code, by the Consumer selecting either a 6092 different payment brand or a different payment instrument for the same 6093 brand. Note that this might involve a different Payment Handler. The 6094 codes to which this applies are: BrandNotSupp, PaymtCancelled, 6095 InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and 6096 Unspecified. 6098 Recovery from Payments associated with Brand Dependent purchases is only 6099 possible, if the Brand Selection component sent by the Merchant to the 6100 Consumer does not change. In practice this means that the same Brand, 6101 Protocol Amount and PayProtocol elements must be used. All that can 6102 change is the Payment Instrument. Any other change will invalidate the 6103 Merchant's Offer as a changed selection will invalidate the Offer 6104 Response. 6106 7.16.3 Delivery Completion Codes 6108 The following table contains the valid values for the CompletionCode 6109 attribute for a Delivery. It is recommended that the StatusDesc attribute 6110 is used to provide further explanation where appropriate. 6112 Value Description 6114 BackOrdered Back Ordered. The goods to be delivered are on order 6115 but they have not yet been received. Shipping will be 6116 arranged when they are received. This is only valid 6117 if ProcessState is CompletedOk. 6119 Recovery is not possible. 6121 PermNotAvail Permanently Not Available. The goods are permanently 6122 unavailable and cannot be re-ordered. This is only 6123 valid if ProcessState is Failed. 6125 Recovery is not possible. 6127 TempNotAvail Temporarily Not Available. The goods are temporarily 6128 unavailable and may become available if they can be 6129 ordered. This is only valid if ProcessState is 6130 CompletedOk. 6132 Recovery is not possible. 6134 ShipPending Shipping Pending. The goods are available and are 6135 scheduled for shipping but they have not yet been 6136 shipped. This is only valid if ProcessState is 6137 CompletedOk. 6139 Recovery is not possible. 6141 Shipped Goods Shipped. The goods have been shipped. 6142 Confirmation of delivery is awaited. This is only 6143 valid if ProcessState is CompletedOk. 6145 Recovery is not possible. 6147 ShippedNoConf Shipped - No Delivery Confirmation. The goods have 6148 been shipped but it is not possible to confirm 6149 delivery of the goods. This is only valid if 6150 ProcessState is CompletedOk. 6152 Recovery is not possible. 6154 ConsCancelled Consumer Cancelled. The Consumer decides to cancel 6155 the delivery for some reason. This code is only valid 6156 in a Status Component contained in a Cancel Block or 6157 an Inquiry Response Block. 6159 Recovery is not possible. 6161 DelivCancelled Delivery Cancelled. The Delivery Handler declines to 6162 complete the Delivery for some reason and cancels the 6163 transaction. This code is only valid in a Status 6164 Component contained in a Cancel Block or an Inquiry 6165 Response Block. 6167 Recovery is not possible. 6169 Confirmed Confirmed. All goods have been delivered and 6170 confirmation of their delivery has been received. 6171 This is only valid if ProcessState is CompletedOk. 6173 Recovery is not possible. 6175 Unspecified Unspecified error. There is some unknown problem or 6176 error which does not fall into one of the other 6177 CompletionCodes. The StatusDesc attribute should 6178 provide the explanation of the cause. 6180 Recovery is not possible. 6182 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6183 response received. The document exchange has 6184 therefore "Timed Out". This code is only valid on a 6185 Transaction Inquiry. 6187 Recovery is possible if the last message from the 6188 other Trading Role is received again. 6190 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6191 response received. The document exchange has 6192 therefore "Timed Out". This code is only valid on a 6193 Transaction Inquiry. 6195 No recovery possible. 6197 [Note] Recovery from failed, or partially completed deliveries is not 6198 possible. The Consumer should use the Transaction Status 6199 Inquiry Transaction (see section 9.2.1) to determine up-to- 6200 date information on the current state. 6201 [Note End] 6203 7.16.4 Authentication Completion Codes 6205 The Completion Code is only required if the ProcessState attribute is set 6206 to Failed. The following table contains the valid values for the 6207 CompletionCode that may be used. It is recommended that the StatusDesc 6208 attribute is used to provide further explanation where appropriate. 6210 Value Description 6212 AutEeCancel Authenticatee Cancel. The Organisation being 6213 authenticated declines to be authenticated for some 6214 reason. This could be, for example because the 6215 signature on an Authentication Request was invalid or 6216 the Authenticator was not known or acceptable to the 6217 Authenticatee. 6219 Recovery is not possible. 6221 AutOrCancel Authenticator Cancel. The Organisation requesting 6222 authentication declines to validate the 6223 Authentication Response received for some reason and 6224 cancels the transaction. 6226 Recovery is not possible. 6228 NoAuthReq Authentication Request Not Available. The 6229 Authenticatee does not have the data that must be 6230 provided so that they may be successfully 6231 authenticated. For example a password may have been 6232 forgotten, the Authenticatee has not yet become a 6233 member, or a smart card token is not present. 6235 Recovery is not possible 6237 AuthFailed Authentication Failed. The Authenticator checked the 6238 Authentication Response but the authentication failed 6239 for some reason. For example a password may have been 6240 incorrect. 6242 Recovery may be possible by the Authenticatee re- 6243 sending a revised Authentication Response with 6244 corrected data. 6246 TradRolesIncon Trading Roles Inconsistent. The Trading Roles 6247 contained within the TradingRoleList attribute of the 6248 Trading Role Information Request Component (see 6249 section 7.4) are inconsistent with the Trading Role 6250 which the Authenticatee is taking in the IOTP 6251 Transaction or is able to take. Examples of 6252 inconsistencies include: 6253 o asking a PaymentHandler for DeliveryHandler 6254 information 6255 o asking a Consumer for Merchant information 6257 Recovery may be possible by the Authenticator re- 6258 sending a revised Authentication Request Block with 6259 corrected information. 6261 Unspecified Unspecified error. There is some unknown problem or 6262 error which does not fall into one of the other 6263 CompletionCodes. 6265 Recovery is not possible. 6267 TimedOutRcvr Recoverable Time Out. Messages were resent but no 6268 response received. The document exchange has 6269 therefore "Timed Out". This code is only valid on a 6270 Transaction Inquiry. 6272 Recovery is possible if the last message from the 6273 other Trading Role is received again. 6275 TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no 6276 response received. The document exchange has 6277 therefore "Timed Out". This code is only valid on a 6278 Transaction Inquiry. 6280 No recovery possible. 6282 7.16.5 Undefined Completion Codes 6284 The Completion Code is only required if the ProcessState attribute is set 6285 to Failed. The following table contains the valid values for the 6286 CompletionCode that may be used. It is recommended that the StatusDesc 6287 attribute is used to provide further explanation where appropriate. 6289 Value Description 6291 InMsgHardError Input Message Hard Error. The type of Request Block 6292 could not be identified or was inconsistent. 6293 Therefore no single Document Exchange could be 6294 identified. This will cause a Hard Error in the 6295 transaction 6297 7.16.6 Transaction Inquiry Completion Codes 6299 The Completion Code is only required if the ProcessState attribute is set 6300 to Failed. The following table contains the valid values for the 6301 CompletionCode that may be used. It is recommended that the StatusDesc 6302 attribute is used to provide further explanation where appropriate. 6304 Value Description 6306 UnAuthReq Unauthorised Request. The recipient of the 6307 Transaction Status Request declines to respond to the 6308 request. 6310 7.17 Trading Role Data Component 6312 The Trading Role Data Component contains opaque data which needs to be 6313 communicated between the Trading Roles involved in an IOTP Transaction. 6315 Trading Role Components identify: 6317 o the Organisation that generated the component, and 6319 o the Organisation that is to receive it. 6321 They are first generated and included in a "Response" Block, and then 6322 copied to the appropriate "Request" Block. For example a Payment Handler 6323 might need to inform a Delivery Handler that a credit card payment had 6324 been authorised but not captured. There may also be other information 6325 that the Payment Handler has generated where the format is privately 6326 agreed with the Delivery Handler which needs to be communicated. In 6327 another example a Merchant might need to provide a Payment Handler with 6328 some specific information about a Consumer so that consumer can acquire 6329 double loyalty points with the payment. 6331 Its definition is as follows. 6333 6334 6339 Attributes: 6341 ID An identifier which uniquely identifies the 6342 Trading Role Data Component within the IOTP 6343 Transaction. 6345 OrginatorElRef Contains an element reference to the Organisation 6346 Component of the Organisation that created the 6347 Trading Role Data Component and included it in a 6348 "Response" Block (e.g. an Offer Response or a 6349 Payment Response Block). 6351 DestinationElRefs Contains element references to the Organisation 6352 Components of the Organisations that are to 6353 receive the Trading Role Data Component in a 6354 "Request" Block (e.g. either a Payment Request or 6355 a Delivery Request Block). 6357 Content: 6359 PackagedContent This contains the data which is to be sent between 6360 the various Trading Roles as one or more 6361 PackagedContent elements see section 3.7. 6363 7.17.1 Who Receives a Trading Role Data Component 6365 The rules for deciding what to do with Trading Role Data Components are 6366 described below. 6368 o whenever a Trading Role Data Component is received in a "Response" 6369 block identify the Organisation Components of the Organisations that 6370 are to receive it as identified by the DestinationElRefs attribute. 6372 o whenever a "Request" Block is being sent, check to see if it is being 6373 sent to one of the Organisations identified by the DestinationElRefs 6374 attribute. If it is then include in the "Request" block: 6375 - the Trading Role Data Component as well as, 6376 - the Organisation Component of the Organisation identified by the 6377 OriginatorElRef attribute (if not already present) 6379 7.18 Inquiry Type Component 6381 The Inquiry Type Component contains the information which indicates the 6382 type of process that is being inquired upon. Its definition is as 6383 follows. 6385 6386 6392 Attributes: 6394 ID An identifier which uniquely identifies the 6395 Inquiry Type Component within the IOTP 6396 Transaction. 6398 Type Contains the type of inquiry. Valid values for 6399 Type are: 6400 o Offer. The inquiry is about the status of an 6401 offer and is addressed to the Merchant. 6402 o Payment. The inquiry is about the status of a 6403 payment and is addressed to the Payment 6404 Handler. 6405 o Delivery. The inquiry is about the status of a 6406 delivery and addressed to the Delivery Handler. 6408 ElRef Contains an Element Reference (see section 3.5) to 6409 the component to which this Inquiry Type Component 6410 applies. That is, 6411 o TPO Block when Type is Offer 6412 o Payment Component when Type is Payment 6413 o Delivery Component when Type is Delivery 6415 ProcessReference Optionally contains a reference to the process 6416 being inquired upon. It should be set if the 6417 information is available. For the definition of 6418 the values it may contain, see the 6419 ProcessReference attribute of the Status Component 6420 (see section 7.16). 6422 7.19 Signature Component 6424 [Note] Definitions of the XML structures for signatures and 6425 certificates are described in the document titled "Digital 6426 Signatures for the Internet Open Trading Protocol" by Kent 6427 Davidson and Yoshiaki Kawatsura published at the same time as 6428 this document - see [IOTPDSIG]. 6430 In the future it is anticipated that future versions of IOTP 6431 will adopt a whatever method for digitally signing XML becomes 6432 the standard. 6433 [Note End] 6435 Each Signature Component digitally signs one or more Blocks or Components 6436 including other Signature Components. 6438 The Signature Component: 6440 o contains digests of one or more Blocks or Components in one or more 6441 IOTP Messages within the same IOTP Transaction and places the result in 6442 a Digest Element 6444 o concatenates these Digest elements with other information on the type 6445 of signature, the originator and potential recipients of the signature 6446 and details of the signature algorithms being used and places them in a 6447 Manifest element, and 6449 o signs the Manifest element using the optional certificate identified in 6450 the Certificate element within the Signature Block placing the result 6451 in a Value element within a Signature Component 6453 Note that there may be multiple Value elements that contain signatures of 6454 a Manifest Element. 6456 A Signature Component can be one of four types either: 6458 o an Offer Response Signature, 6460 o a Payment Response Signature, 6462 o a Delivery Response Signature, or 6464 o an Authentication Response Signature. 6466 For a general explanation of signatures see section 6 Digital Signatures. 6468 7.19.1 IOTP usage of signature elements and attributes 6470 Definitions of the elements and attributes are contained in [IOTPDSIG]. 6471 The following contains additional information that describes how these 6472 elements and attributes are used by IOTP. 6474 SIGNATURE ELEMENT 6476 The ID attribute is mandatory. 6478 MANIFEST ELEMENT 6480 The optional LocatorHrefBase attribute contains text which should be 6481 concatenated before the text contained in the LocatorHREF attribute of 6482 all Digest elements within the Manifest. 6484 Its purpose is to reduce the size of LocatorHREF attribute values since 6485 the first part of the LocatorHREF attributes in the same signature are 6486 likely to be the same. 6488 Typically, within IOTP, it will contain all the characters in a 6489 LocatorHref attribute up to the sharp ("#") character (see immediately 6490 below). 6492 ALGORITHM AND PARAMETER ELEMENTS 6494 The algorithm element identifies the algorithms used in generating the 6495 signature. The type of the algorithm is defined by the value of the Type 6496 attribute which indicates if it is to be used as a Digest algorithm, a 6497 Signature algorithm or a Key Agreement algorithm. 6499 The following Digest algorithms must be implemented: 6501 o a [DOM-HASH] algorithm. This is identified by setting the Name 6502 attribute of the Algorithm element to "urn:ibm:dom-hash" 6504 o a [SHA1] algorithm. This is identified by setting the Name attribute of 6505 the Algorithm element to "urn:fips:sha1", and 6507 o a [MD5] algorithm. This is identified by setting the Name attribute of 6508 the Algorithm element to "urn:rsa:md5" 6510 o The following Signature algorithms must be implemented: 6512 o a [DSA] algorithm. This is identified by setting the Name attribute of 6513 the Algorithm element to "urn:us.gov:dsa" 6515 o a [HMAC] algorithm. This is identified by setting the Name attribute of 6516 the Algorithm element to "urn:ibm:hmac" 6518 It is recommended that the following Signature algorithm is also 6519 implemented: 6521 o a [RSA] algorithm. This is identified by setting the Name attribute of 6522 the Algorithm element to "urn:rsa:rsa" 6524 In addition other payment scheme specific algorithms may be used. In this 6525 case the value of the name attribute to use is specified in the payment 6526 scheme supplement for that algorithm. 6528 One algorithm may make use of other algorithms by use of the Parameter 6529 element, for example: 6531 6532 A2 6533 6534 6535 6536 6537 A1 6538 6540 DIGEST ELEMENT 6542 The LocatorHREF attribute identifies the IOTP element which is being 6543 digitally signed. Specifically it consists of: 6545 o the value of the IotpTransId attribute of the Transaction ID Component, 6546 followed by: 6548 o a sharp character, i.e. "#", followed by 6550 o an Element Reference (see section 3.5) to the element within the IOTP 6551 Transaction which is the subject of the digest. 6553 Before analysing the structure of the LocatorHREF attribute, it must be 6554 concatenated with the value of the LocatorHrefBase attribute of the 6555 Manifest element (see immediately above). 6557 ATTRIBUTE ELEMENT 6559 There must be one and only one Attribute Element that contains a Type 6560 attribute with a value of IOTP Signature Type and with content set to 6561 either: OfferResponse, PaymentResponse, DeliveryResponse, 6562 AuthenticationRequest, AuthenticationResponse, PingRequest or 6563 PingResponse; depending on the type of the signature. 6565 Values of the content of the Attribute element are controlled under the 6566 procedures defined in section 12 IANA Considerations which also allows 6567 user defined values to be defined. 6569 The Critical attribute must be set to true. 6571 ORIGINATORINFO ELEMENT 6573 The OriginatorRef attribute of the OriginatorInfo element must always be 6574 present and contain an Element Reference (see section 3.5) to the 6575 Organisation Component of the Organisation that generated the Signature 6576 Component. 6578 RECIPIENTINFO ELEMENT 6580 The RecipientRefs attribute contains a list of Element References (see 6581 section 3.5), that point to the Organisations that might need to validate 6582 the signature. For details see below. 6584 7.19.2 Offer Response Signature Component 6586 The Manifest Element of a signature which has a type of OfferResponse 6587 should contain Digest elements for the following Components: 6589 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6590 that contains the Offer Response Signature 6592 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6593 that contains the Offer Response Signature 6595 o from the TPO Block: 6596 - the Protocol Options Component 6597 - each of the Organisation Components 6598 - each of the Brand List Components 6600 o optionally, all the Brand Selection Components if they were sent to the 6601 Merchant in a TPO Selection Block 6603 o from the Offer Response Block: 6604 - the Order Component 6605 - each of the Payment Components 6606 - the Delivery Component 6607 - each of the Authentication Request Components 6608 - any Trading Role Data Components 6610 The Offer Response Signature should also contain Digest elements for the 6611 components that describe each of the Organisations that may or will need 6612 to verify the signature. This involves: 6614 o if the Merchant has received a TPO Selection Block containing Brand 6615 Selection Components, then generate a Digest element for the Payment 6616 Handler identified by the Brand Selection Component and the Delivery 6617 Handler identified by the Delivery Component. See section 6.3.1 Check 6618 Request Block sent Correct Organisation for a description of how this 6619 can be done. 6621 o if the Merchant is not expecting to receive a TPO Selection Block then 6622 generate a Digest element for the Delivery Handler and all the Payment 6623 Handlers that are involved. 6625 7.19.3 Payment Receipt Signature Component 6627 The Manifest Element of the Payment Receipt Signature Component should 6628 contain Digest Elements for the following Components: 6630 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6631 that contains the Payment Receipt Signature 6633 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6634 that contains the Payment Receipt Signature 6636 o the Offer Response Signature Component 6638 o the Payment Receipt Component 6640 o the Payment Note Component 6642 o the Status Component 6644 o the Brand Selection Component. 6646 o any Trading Role Data Components 6648 7.19.4 Delivery Response Signature Component 6650 The Manifest Element of the Delivery Response Signature Component should 6651 contain Digest Elements for the following Components: 6653 o the Transaction Id Component (see section 3.3.1) of the IOTP message 6654 that contains the Delivery Response Signature 6656 o the Transaction Reference Block (see section 3.3) of the IOTP Message 6657 that contains the Delivery Response Signature 6659 o the Consumer Delivery Data component contained in the preceding 6660 Delivery Request (if any) 6662 o the Signature Components contained in the preceding Delivery Request 6663 (if any) 6665 o the Status Component 6667 o the Delivery Note Component 6669 7.19.5 Authentication Request Signature Component 6671 The Manifest Element of the Authentication Request Signature Component 6672 should contain Digest Elements for the following Components: 6674 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6675 that contains information that describes the IOTP Message and IOTP 6676 Transaction 6678 o the Transaction Id Component (see section 3.3.1) which globally 6679 uniquely identifies the IOTP Transaction 6681 o the following components of the TPO Block : 6682 - the Protocol Options Component 6683 - the Organisation Component 6685 o the following components of the Authentication Request Block: 6686 - the Authentication Request Component(s) (if present) 6687 - the Trading Role Information Request Component (if present) 6689 7.19.6 Authentication Response Signature Component 6691 The Manifest Element of the Authentication Response Signature Component 6692 should contain Digest Elements for the following Components: 6694 o the Transaction Reference Block (see section 3.3) for the IOTP Message 6695 that contains information that describes the IOTP Message and IOTP 6696 Transaction 6698 o the Transaction Id Component (see section 3.3.1) which globally 6699 uniquely identifies the IOTP Transaction 6701 o the following components of the Authentication Request Block: 6702 - the Authentication Request Component that was used in the 6703 Authentication (if present) 6704 - the Trading Role Information Request Component (if present) 6706 o the Organisation Components contained in the Authentication Response 6707 Block 6709 7.19.7 Inquiry Request Signature Component 6711 If the Inquiry Request is being signed (see section 9.2.1) the Manifest 6712 Element of the Inquiry Request Signature Component should contain Digest 6713 elements of the Inquiry Type Component, and if present, the Payment 6714 Scheme Component. 6716 7.19.8 Inquiry Response Signature Component 6718 If the Inquiry Response is being signed (see section 9.2.1) the Manifest 6719 Element of the Inquiry Response Signature Component should contain Digest 6720 elements of the Trading Response Block and the Status Component. 6722 7.19.9 Ping Request Signature Component 6724 If the Ping Request is being singed (see section 9.2.2), the Manifest 6725 Element of the Ping Request Signature Component should contain Digest 6726 elements for all the Organisation Components. 6728 7.19.10 Ping Response Signature Component 6730 If the Ping Response is being singed (see section 9.2.2), the Manifest 6731 Element of the Ping Response Signature Component should contain Digest 6732 elements fir all the Organisation Components. 6734 7.20 Certificate Component 6736 [Note] Definitions of the XML structures for signatures and 6737 certificates are described in the paper "Digital Signatures 6738 for the Internet Open Trading Protocol", see [IOTPDSIG]. 6740 See note at the start of section 7.19 Signature Component for 6741 more details. 6742 [Note End] 6744 A Certificate Component contains a Digital Certificate. They are used 6745 only when required, for example, when asymmetric cryptography is being 6746 used and the recipient of the signature that needs to check has not 6747 already received the Public Key. 6749 The structure of a Certificate Component is defined in [IOTPDSIG]. 6751 7.20.1 IOTP usage of signature elements and attributes 6753 Detailed definitions of the above elements and attributes are contained 6754 in [IOTPDSIG]. The following contains additional information that 6755 describes how these elements and attributes are used by IOTP. 6757 CERTIFICATE COMPONENT 6759 The ID attribute is mandatory. 6761 VALUE ELEMENT 6763 The ID attribute is mandatory. 6765 7.21 Error Component 6767 The Error Component contains information about Technical Errors (see 6768 section 4.1) in an IOTP Message which has been received by one of the 6769 Trading Roles involved in the trade. 6771 For clarity two phrases are defined which are used in the description of 6772 an Error Component: 6774 o message in error. An IOTP message which contains or causes an error of 6775 some kind 6777 o message reporting the error. An IOTP message that contains an Error 6778 Component that describes the error found in a message in error. 6780 The definition of the Error Component is as follows. 6782 6783 6792 Attributes: 6794 ID An identifier which uniquely identifies the Error 6795 Component within the IOTP Transaction. 6797 xml:lang Defines the language used by attributes or child 6798 elements within this component, unless overridden 6799 by an xml:lang attribute on a child element. See 6800 section 3.8 Identifying Languages. 6802 ErrorCode Contains an error code which indicates the nature 6803 of the error in the message in error. Valid values 6804 for the ErrorCode are given in section 7.21.2 6805 Error Codes. 6807 ErrorDesc Contains a narrative description of the error in 6808 the language defined by xml:lang. The content of 6809 this attribute is defined by the vendor/developer 6810 of the software which generated the Error 6811 Component 6813 Severity Indicates the severity of the error. Valid values 6814 are: 6815 o Warning. This indicates that although there is 6816 a message in error the IOTP Transaction can 6817 still continue. 6818 o TransientError. This indicates that the error 6819 in the message in error may be recovered if the 6820 message in error that is referred to by the 6821 ErrorLocation element is resent 6822 o HardError. This indicates that there is an 6823 unrecoverable error in the message in error and 6824 the IOTP Transaction must stop. 6826 MinRetrySecs This attribute should be present if Severity is 6827 set to TransientError. It is the minimum number of 6828 whole seconds which the IOTP aware application 6829 which received the message reporting the error 6830 should wait before re-sending the message in error 6831 identified by the ErrorLocation element. 6833 If Severity is not set to TransientError then the 6834 value of this attribute is ignored. 6836 SwVendorErrorRef This attribute is a reference whose value is set 6837 by the vendor/developer of the software which 6838 generated the Error Component. It should contain 6839 data which enables the vendor to identify the 6840 precise location in their software and the set of 6841 circumstances which caused the software to 6842 generate a message reporting the error. See also 6843 the SoftwareId attribute of the Message Id element 6844 in the Transaction Reference Block (section 3.3). 6846 Content: 6848 ErrorLocation This identifies the IOTP Transaction Id of the 6849 message in error and, where possible, the element 6850 and attribute in the message in error that caused 6851 the Error Component to be generated. 6853 If the Severity of the error is not 6854 TransientError, more than one ErrorLocation may be 6855 specified as appropriate depending on the nature 6856 of the error (see section 7.21.2 Error Codes) and 6857 at the discretion of the vendor/developer of the 6858 IOTP Aware Application. 6860 PackagedContent This contains additional data which can be used to 6861 understand the error. Its content may vary as 6862 appropriate depending on the nature of the error 6863 (see section 7.21.2 Error Codes) and at the 6864 discretion of the vendor/developer of the IOTP 6865 Aware Application. For a definition of 6866 PackagedContent see section 3.7. 6868 7.21.1 Error Processing Guidelines 6870 If there is more than one Error Component in a message reporting the 6871 error, carry out the actions appropriate for the Error Component with the 6872 highest severity. In this context, HardError has a higher severity than 6873 TransientError, which has a higher severity than Warning. 6875 7.21.1.1 Severity - Warning 6877 If an IOTP aware application is generating a message reporting the error 6878 with an Error Component where the Severity attribute is set to Warning, 6879 then if the message reporting the error does not contain another Error 6880 Component with a severity higher than Warning, the IOTP Message must also 6881 include the Trading Blocks and Trading Components that would have been 6882 included if no error was being reported. 6884 If a message reporting the error is received with an Error Component 6885 where Severity is set to Warning, then: 6887 o it is recommended that information about the error is either logged, or 6888 otherwise reported to the user, 6890 o the implementer of the IOTP aware application must either, at their or 6891 the user's discretion: 6892 - continue the IOTP transaction as normal, or 6893 - fail the IOTP transaction by generating a message reporting the error 6894 with an Error Component with Severity set to HardError (see section 6895 7.21.1.3). 6897 If the intention is to continue the IOTP transaction then, if there are 6898 no other Error Components with a higher severity, check that the 6899 necessary Trading Blocks and Trading Components for normal processing of 6900 the transaction to continue are present. If they are not then generate a 6901 message reporting the error with an Error Component with Severity set to 6902 HardError. 6904 7.21.1.2 Severity - Transient Error 6906 If an IOTP Aware Application is generating a message reporting the error 6907 with an Error Component where the Severity attribute is set to 6908 TransientError, then there should be only one Error Component in the 6909 message reporting the error. In addition, the MinRetrySecs attribute 6910 should be present. 6912 If a message reporting the error is received with an Error Component 6913 where Severity is set to TransientError then: 6915 o if the MinRetrySecs attribute is present and a valid number, then use 6916 the MinRetrySecs value given. Otherwise if MinRetrySecs is missing or 6917 is invalid, then: 6918 - generate a message reporting the error containing an Error Component 6919 with a Severity of Warning and send it on the next IOTP message (if 6920 any) to be sent to the Trading Role which sent the message reporting 6921 the error with the invalid MinRetrySecs, and 6922 - use a value for MinRetrySecs which is set by the vendor/developer of 6923 the IOTP Aware Application. 6925 o check that only one ErrorLocation element is contained within the Error 6926 Component and that it refers to an IOTP Message which was sent by the 6927 recipient of the Error Component with a Severity of TransientError. If 6928 more than one ErrorLocation is present then generate a message 6929 reporting the error with a Severity of HardError. 6931 7.21.1.3 Severity - Hard Error 6933 If an IOTP Aware Application is generating a message reporting the error 6934 with an Error Component where the Severity attribute set to HardError, 6935 then there should be only one Error Component in the message reporting 6936 the error. 6938 If a message reporting the error is received with an Error Component 6939 where Severity is set to HardError then terminate the IOTP Transaction. 6941 7.21.2 Error Codes 6943 The following table contains the valid values for the ErrorCode attribute 6944 of the Error Component. The first sentence of the description contains 6945 the text that should be used to describe the error when displayed or 6946 otherwise reported. Individual implementations may translate this into 6947 alternative languages at their discretion. 6949 An Error Code must not be more that 14 characters long. 6951 Value Description 6953 Reserved Reserved. This error is reserved by the 6954 vendor/developer of the software. Contact the 6955 vendor/developer of the software for more information 6957 Value Description 6958 See the SoftwareId attribute of the Message Id 6959 element in the Transaction Reference Block(section 6960 3.3). 6962 XmlNotWellFrmd XML not well formed. The XML document is not well 6963 formed. See [XML] for the meaning of "well formed". 6964 Even if the XML is not well formed, it should still 6965 be scanned to find the Transaction Reference Block so 6966 that a properly formed Error Response may be 6967 generated. 6969 XmlNotValid XML not valid. The XML document is well formed but 6970 the document is not valid. See [XML] for the meaning 6971 of "valid". Specifically: 6972 o the XML document does not comply with the 6973 constraints defined in the IOTP document type 6974 declaration (DTD) (see section 13 Internet Open 6975 Trading Protocol Data Type Definition), and 6976 o the XML document does not comply with the 6977 constraints defined in the document type 6978 declaration of any additional [XML Namespace] that 6979 are declared. 6981 As for XML not well formed, attempts should still be 6982 made to extract the Transaction Reference Block so 6983 that a properly formed Error Response may be 6984 generated. 6986 ElUnexpected Unexpected element. Although the XML document is well 6987 formed and valid, an element is present that is not 6988 expected in the particular context according to the 6989 rules and constraints contained in this 6990 specification. 6992 ElNotSupp Element not supported. Although the document is well 6993 formed and valid, an element is present that: 6994 o is consistent with the rules and constraints 6995 contained in this specification, but 6996 o is not supported by the IOTP Aware Application 6997 which is processing the IOTP Message. 6999 ElMissing Element missing. Although the document is well formed 7000 and valid, an element is missing that should have 7001 been present if the rules and constraints contained 7002 in this specification are followed. 7004 In this case set the PackagedContent of the Error 7005 Component to the type of the missing element. 7007 ElContIllegal Element content illegal. Although the document is 7008 well formed and valid, the element Content contains 7009 values which do not conform to the rules and 7011 Value Description 7012 constraints contained in this specification. 7014 EncapProtErr Encapsulated protocol error. Although the document is 7015 well formed and valid, the PackagedContent of an 7016 element contains data from an encapsulated protocol 7017 which contains errors. 7019 AttUnexpected Unexpected attribute. Although the XML document is 7020 well formed and valid, the presence of the attribute 7021 is not expected in the particular context according 7022 to the rules and constraints contained in this 7023 specification. 7025 AttNotSupp Attribute not supported. Although the XML document is 7026 well formed and valid, and the presence of the 7027 attribute in an element is consistent with the rules 7028 and constraints contained in this specification, it 7029 is not supported by the IOTP Aware Application which 7030 is processing the IOTP Message. 7032 AttMissing Attribute missing. Although the document is well 7033 formed and valid, an attribute is missing that should 7034 have been present if the rules and constraints 7035 contained in this specification are followed. 7037 In this case set the PackagedContent of the Error 7038 Component to the type of the missing attribute. 7040 AttValIllegal Attribute value illegal. The attribute contains a 7041 value which does not conform to the rules and 7042 constraints contained in this specification. 7044 AttValNotRecog Attribute Value Not Recognised. The attribute 7045 contains a value which the IOTP Aware Application 7046 generating the message reporting the error could not 7047 recognise. 7049 MsgTooLarge Message too large. The message is too large to be 7050 processed by the IOTP Aware Application. 7052 ElTooLarge Element too large. The element is too large to be 7053 processed by the IOTP Aware Application 7055 ValueTooSmall Value too small or early. The value of all or part of 7056 the Content of an element or an attribute, although 7057 valid, is too small. 7059 ValueTooLarge Value too large or in the future. The value of all or 7060 part of the Content of an element or an attribute, 7061 although valid, is too large. 7063 ElInconsistent Element Inconsistent. Although the document is well 7064 Value Description 7065 formed and valid, according to the rules and 7066 constraints contained in this specification: 7067 o the content of an element is inconsistent with the 7068 content of other elements or their attributes, or 7069 o the value of an attribute is inconsistent with the 7070 value of one or more other attributes. 7072 In this case create ErrorLocation elements which 7073 identify all the attributes or elements which are 7074 inconsistent. 7076 TransportError Transport Error. This error code is used to indicate 7077 that there is a problem with the Transport Mechanism 7078 which is preventing the message from being received. 7079 It is typically associated with a Transient Error. 7080 Explanation of the Transport Error is contained 7081 within the ErrorDesc attribute. The values which can 7082 be used inside ErrorDesc with a TransportError is 7083 specified in the IOTP supplement for the Transport 7084 mechanism. 7086 MsgBeingProc Message Being Processed. This error code is only used 7087 with a Severity of Transient Error. It indicates that 7088 the previous message, which may be an exchange 7089 message or a request message, is being processed and, 7090 if no response is received by the time indicated by 7091 the MinRetrySecs attribute, then the original message 7092 should be resent. 7094 SystemBusy System Busy. This error code is only used with a 7095 Severity of Transient Error. It indicates that the 7096 server that received a message is currently too busy 7097 to handle the message. If no response is received by 7098 the time indicated by the MinRetrySecs attribute, 7099 then the original message should be resent. 7101 [Note] If the server/system handling the 7102 Transport Mechanism (e.g. HTTP) is busy 7103 then a Transport Specific error message 7104 should be used instead of an IOTP Error 7105 message. This code should be used in 7106 association with IOTP servers/systems or 7107 other servers/systems to which the IOTP 7108 server is connected. 7109 [Note End] 7111 UnknownError Unknown Error. Indicates that the transaction cannot 7112 complete for some reason that is not covered 7113 explicitly by any of the other errors. The ErrorDesc 7114 attribute should be used to indicate the nature of 7115 the problem. 7117 Value Description 7119 This could be used to indicate, for example, an 7120 internal error in a backend server or client process 7121 of some kind. 7123 7.21.3 Error Location Element 7125 An Error Location Element identifies an element and optionally an 7126 attribute in the message in error which is associated with the error. It 7127 contains a reference to the IOTP Message, Trading Block, Trading 7128 Component, element and attribute, which is in error. 7130 7131 7139 Attributes: 7141 ElementType This is the name of the type of the element where 7142 the error is located. For example if the element 7143 was declared as |-Trading Block <--------Trading Block - an XML Element 7216 | | |-Trading Comp. within an IOTP Message that 7217 Trading | |-Trading Comp. contains a predefined set of 7218 Blocks | |-Trading Comp. Trading Components 7219 | | |-Trading Comp. 7220 | | |-Trading Comp. <-----Trading Components - XML Elements 7221 | | within a Trading Block that 7222 ------> |-Trading Block contain a predefined set of XML 7223 | |-Trading Comp. elements and attributes 7224 | |-Trading Comp. containing information required 7225 | |-Trading Comp. to support a Trading Exchange 7226 | |-Trading Comp. 7227 | |-Trading Comp. 7228 | 7229 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 7230 Figure 16 Trading Blocks 7232 Trading Blocks are defined as part of the definition of an IOTP Message 7233 (see section 3.1.1). The definition of an IOTP Message element is 7234 repeated here: 7236 7259 The remainder of this section defines the Trading Blocks in this version 7260 of IOTP. They are: 7262 o Authentication Request Block 7264 o Authentication Response Block 7266 o Authentication Status Block 7268 o Cancel Block 7270 o Delivery Request Block 7272 o Delivery Response Block 7274 o Error Block 7276 o Inquiry Request Block 7278 o Inquiry Response Block 7280 o Offer Response Block 7282 o Payment Exchange Block 7283 o Payment Request Block 7285 o Payment Response Block 7287 o Signature Block 7289 o Trading Protocol Options Block 7291 o TPO Selection Block 7293 The Transaction Reference Block is described in section 3.3. 7295 8.1 Trading Protocol Options Block 7297 The TPO Trading Block contains options which apply to the IOTP 7298 Transaction. The definition of a TPO Trading Block is as follows. 7300 7301 7304 Attributes: 7306 ID An identifier which uniquely identifies the 7307 Trading Protocol Options Block within the IOTP 7308 Transaction (see section 3.4 ID Attributes). 7310 Content: 7312 ProtocolOptions The Protocol Options Component (see section 7313 7.1)defines the options which apply to the whole 7314 IOTP Transaction (see section 9). 7316 BrandList This Brand List Component contains one or more 7317 payment brands and protocols which may be selected 7318 (see section 7.7). 7320 Org The Organisation Components (see section 7.6) 7321 identify the Organisations and their roles in the 7322 IOTP Transaction. The roles and Organisations 7323 which must be present will depend on the 7324 particular type of IOTP Transaction. See the 7325 definition of each transaction in section 9. 7326 Internet Open Trading Protocol Transactions. 7328 The TPO Block should contain: 7330 o the Protocol Options Component 7332 o the Organisation Component with the Trading Role of Merchant 7334 o the Organisation Component with the Trading Role of Consumer 7335 o optionally, the Organisation Component with the Trading Role of 7336 DeliverTo, if there is a Delivery included in the IOTP Transaction 7338 o Brand List Components for each payment in the IOTP Transaction 7340 o Organisation Components for all the Payment Handlers involved 7342 o optionally, Organisation Components for the Delivery Handler (if any) 7343 for the transaction 7345 o additional Organisation Components that the Merchant may want to 7346 include. For example 7347 - a Customer Care Provider 7348 - an Certificate Authority that offers Merchant "Credentials" or some 7349 other warranty on the goods or services being offered. 7351 8.2 TPO Selection Block 7353 The TPO Selection Block contains the results of selections made from the 7354 options contained in the Trading Protocol Options Block (see section 7355 8.1).The definition of a TPO Selection Block is as follows. 7357 7358 7361 Attributes: 7363 ID An identifier which uniquely identifies the TPO 7364 Selection Block within the IOTP Transaction. 7366 Content: 7368 BrandSelection This identifies the choice of payment brand and 7369 payment protocol to be used in a payment within 7370 the IOTP Transaction. There is one Brand Selection 7371 Component (see section 7.8) for each payment to be 7372 made in the IOTP Transaction. 7374 The TPO Selection Block should contain one Brand Selection Component for 7375 each Brand List in the TPO Block. 7377 8.3 Offer Response Block 7379 The Offer Response Block contains details of the goods, services, amount, 7380 delivery instructions or financial transaction which is to take place. 7381 Its definition is as follows. 7383 7386 7389 Attributes: 7391 ID An identifier which uniquely identifies the Offer 7392 Response Block within the IOTP Transaction. 7394 Content: 7396 Status Contains status information about the business 7397 success (see section 4.2) or failure of the 7398 generation of the Offer. Note that in an Offer 7399 Response Block, a ProcessState of NotYetStarted or 7400 InProgress are illegal values. 7402 Order The Order Component contains details about the 7403 goods, services or financial transaction which is 7404 taking place see section 7.5. 7406 The Order Component must be present unless the 7407 ProcessState attribute of the Status Component is 7408 set to Failed. 7410 Payment The Payment Components contain information about 7411 the payments which are to be made see section 7.9. 7413 Delivery The Delivery Component contains details of the 7414 delivery to be made (see section 7.13). 7416 TradingRoleData The Trading Role Data Component contains opaque 7417 data which is needs to be communicated between the 7418 Trading Roles involved in an IOTP Transaction (see 7419 section 7.17). 7421 The Offer Response Block should contain: 7423 o the Order Component for the IOTP Transaction 7425 o Payment Components for each Payment in the IOTP Transaction 7427 o the Delivery Component the IOTP Transaction requires (if any). 7429 8.4 Authentication Request Block 7431 The Authentication Request Block contains the data which is used by one 7432 Trading Role to obtain information about and optionally authenticate 7433 another Trading Role. 7435 In outline it contains: 7437 o information about how the authentication itself will be carried out, 7438 and/or 7440 o a request for additional information about the Organisation being 7441 authenticated. 7443 Its definition is as follows. 7445 7446 7449 Attributes: 7451 ID An identifier which uniquely identifies the 7452 Authentication Request Block within the IOTP 7453 Transaction. 7455 Content: 7457 AuthReq Each Authentication Request (see section 7.2) 7458 component describes an alternative way in which 7459 the recipient of the Authentication Request may 7460 authenticate themselves by generating an 7461 Authentication Response Component (see section 7462 7.3). 7464 If one Authentication Request Component is 7465 present then that Authentication Request 7466 Component should be used. 7468 If more than one Authentication Request Component 7469 is present then the recipient should choose one 7470 of the components based on personal preference of 7471 the recipient or their software. 7473 If no Authentication Request Component is present 7474 it means that the Authentication Request Block is 7475 requesting the return of Organisation Components 7476 as specified in the Trading Role Information 7477 Request Component. 7479 TradingRoleInfoReq The Trading Role Information Request Component 7480 (see section 7.4) contains a list of Trading 7481 Roles about which information is being requested 7483 There must be at least one Component (either an Authentication Request or 7484 a Trading Role Information Request) within the Authentication Block 7485 otherwise it is an error. 7487 8.5 Authentication Response Block 7489 The Authentication Response Block contains the response which results 7490 from processing the Authentication Request Block. Its definition is as 7491 follows. 7493 7494 7497 Attributes: 7499 ID An identifier which uniquely identifies the 7500 Authentication Response Block within the IOTP 7501 Transaction. 7503 Content: 7505 AuthResp The optional Authentication Response Component 7506 which contains the results of processing the 7507 Authentication Request Component - see section 7508 7.3. 7510 Org Optional Organisation Components that contain 7511 information corresponding to the Trading Roles as 7512 requested by the TradingRoleList attribute of the 7513 Trading Role Information Request component. 7515 The components present in the Authentication Response Block must match 7516 the requirement of the corresponding Authentication Request Block 7517 otherwise it is an error. 7519 8.6 Authentication Status Block 7521 The Authentication Status Block indicates the success or failure of the 7522 validation of an Authentication Response Block by an Authenticator. Its 7523 definition is as follows. 7525 7526 7529 Attributes: 7531 ID An identifier which uniquely identifies the 7532 Authentication Status Block within the IOTP 7533 Transaction. 7535 Content: 7537 Status Contains status information about the business 7538 success (see section 4.2) or failure of the 7539 authentication 7541 8.7 Payment Request Block 7543 The Payment Request Block contains information which requests that a 7544 payment is started. Its definition is as follows. 7546 7548 7551 Attributes: 7553 ID An identifier which uniquely identifies the 7554 Payment Request Block within the IOTP Transaction. 7556 Content: 7558 Status Contains the Status Components (see section 7.13) 7559 of the responses of the steps (e.g. an Offer 7560 Response and/or a Payment Response) on which this 7561 step depends. It is used to indicate the success 7562 or failure of those steps. Payment should only 7563 occur if the previous steps were successful. 7565 BrandList The Brand List Component contains a list of one or 7566 more payment brands and protocols which may be 7567 selected (see section 7.7). 7569 BrandSelection This identifies the choice of payment brand, the 7570 payment protocol and the Payment Handler to be 7571 used in a payment within the IOTP Transaction. 7572 There is one Brand Selection Component (see 7573 section 7.8) for each payment to be made in the 7574 IOTP Transaction. 7576 Payment The Payment Components contain information about 7577 the payment which is being made see section 7.9. 7579 PaySchemeData The Payment Scheme Component contains payment 7580 scheme specific data see section 7.10. 7582 Org The Organisation Component contains details of 7583 Organisations involved in the payment (see section 7584 7.6). The Organisations present are dependent on 7585 the IOTP Transaction and the data which is to be 7586 signed. See section 6 Digital Signatures for more 7587 details. 7589 TradingRoleData The Trading Role Data Component contains opaque 7590 data which is needs to be communicated between the 7591 Trading Roles involved in an IOTP Transaction (see 7592 section 7.17). 7594 The Payment Request Block should contain: 7596 o the Organisation Component with a Trading Role of Merchant 7598 o the Organisation Component with the Trading Role of Consumer 7600 o the Payment Component for the Payment 7602 o the Brand List Component for the Payment 7604 o the Brand Selection Component for the Brand List 7606 o the Organisation Component for the Payment Handler of the Payment 7608 o the Organisation Component (if any) for the Organisation which carried 7609 out the previous step, for example another Payment Handler 7611 o the Organisation Component for the Organisation which is to carry out 7612 the next step, if any. This may be, for example, either a Delivery 7613 Handler or a Payment Handler. 7615 o the Organisation Components for any additional Organisations that the 7616 Merchant has included in the Offer Response Block 7618 o an Optional Payment Scheme Data Component, if required by the Payment 7619 Method as defined in the IOTP supplement for the payment method 7621 o any Trading Role Data Components that may be required (see section 7622 7.17.1). 7624 8.8 Payment Exchange Block 7626 The Payment Exchange Block contains payment scheme specific data which is 7627 exchanged between two of the roles in a trade. Its definition is as 7628 follows. 7630 7631 7634 Attributes: 7636 ID An identifier which uniquely identifies the 7637 Payment Exchange Block within the IOTP 7638 Transaction. 7640 Content: 7642 PaySchemeData This Trading Component contains payment scheme 7643 specific data see section 7.10 Payment Scheme 7644 Component. 7646 8.9 Payment Response Block 7648 This Payment Response Block contains a information about the Payment 7649 Status, an optional Payment Receipt, and an optional payment protocol 7650 message. Its definition is as follows. 7652 7654 7657 Attributes: 7659 ID An identifier which uniquely identifies the 7660 Payment Response Block within the IOTP 7661 Transaction. 7663 Content: 7665 Status Contains status information about the business 7666 success (see section 4.2) or failure of the 7667 payment. Note that in a Pay Response Block, a 7668 ProcessState of NotYetStarted or InProgress are 7669 illegal values. 7671 PayReceipt Contains payment scheme specific data which can be 7672 used to verify the payment occurred. See section 7673 7.11 Payment Receipt Component. It must be present 7674 if the ProcessState attribute of the Status 7675 Component is set to CompletedOk. PayReceipt is 7676 optional for other values as specified by the 7677 appropriate Payment Scheme supplement. 7679 PaySchemeData Contains payment scheme specific data see section, 7680 for example a payment protocol message. See 7.10 7681 Payment Scheme Component. 7683 PaymentNote Contains additional, non payment related, 7684 information which the Payment Handler wants to 7685 provide to the Consumer. For example, if a 7686 withdrawal or deposit were being made then it 7687 could contain information on the remaining balance 7688 on the account after the transfer was complete. 7689 See section 7.12 Payment Note Component. 7691 TradingRoleData The Trading Role Data Component contains opaque 7692 data which is needs to be communicated between the 7693 Trading Roles involved in an IOTP Transaction (see 7694 section 7.17). 7696 8.10 Delivery Request Block 7698 The Delivery Request Block contains details of the goods or services 7699 which are to be delivered together with a signature which can be used to 7700 check that delivery is authorised. Its definition is as follows. 7702 7704 7707 Attributes: 7709 ID An identifier which uniquely identifies the 7710 Delivery Request Block within the IOTP 7711 Transaction. 7713 Content: 7715 Status Contains the Status Components (see section 7716 7.13) of the responses of the steps (e.g. a 7717 Payment Response) on which this step is 7718 dependent. It is used to indicate the success 7719 or failure of those steps. Delivery should only 7720 occur if the previous steps were successful. 7722 Order The Order Component contains details about the 7723 goods, services or financial transaction which 7724 is taking place see section 7.5. 7726 The Organisation Components (see section 7.6) 7727 identify the Organisations and their roles in 7728 Org the IOTP Transaction. The roles and 7729 Organisations which must be present will depend 7730 on the particular type of IOTP Transaction. See 7731 the definition of each transaction in section 7732 9. Internet Open Trading Protocol Transactions. 7734 Delivery The Delivery Component contains details of the 7735 delivery to be made (see section 7.13). 7737 ConsumerDeliveryData Optional. Contains an identifier specified by 7738 the Consumer which, if returned by the Delivery 7739 Handler will enable the Consumer to identify 7740 which Delivery is being referred to. 7742 TradingRoleData The Trading Role Data Component contains opaque 7743 data which is needs to be communicated between 7744 the Trading Roles involved in an IOTP 7745 Transaction (see section 7.17). 7747 The Delivery Request Block contains: 7749 o the Organisation Component with a Trading Role of Merchant 7750 o the Organisation Component for the Consumer and DeliverTo Trading Roles 7752 o the Delivery Component for the Delivery 7754 o the Organisation Component for the Delivery Handler. Specifically the 7755 Organisation Component identified by the ActionOrgRef attribute on the 7756 Delivery Component 7758 o the Organisation Component (if any) for the Organisation which carried 7759 out the previous step, for example a Payment Handler 7761 o the Organisation Components for any additional Organisations that the 7762 Merchant has included in the Offer Response Block 7764 o any Trading Role Data Components that may be required (see section 7765 7.17.1). 7767 8.11 Delivery Response Block 7769 The Delivery Response Block contains a Delivery Note containing details 7770 on how the goods will be delivered. Its definition is as follows. Note 7771 that in a Delivery Response Block a Delivery Status Element with a 7772 DeliveryStatusCode of NotYetStarted or InProgress is invalid. 7774 7775 7778 Attributes: 7780 ID An identifier which uniquely identifies the 7781 Delivery Response Block within the IOTP 7782 Transaction. 7784 Content: 7786 Status Contains status information about the business 7787 success (see section 4.2) or failure of the 7788 delivery. Note that in a Delivery Response Block, 7789 a ProcessState of NotYetStarted or InProgress are 7790 illegal values. 7792 DeliveryNote The Delivery Note Component contains details about 7793 how the goods or services will be delivered (see 7794 section 7.15). 7796 8.12 Inquiry Request Trading Block 7798 The Inquiry Request Trading Block contains an Inquiry Type Component and 7799 an optional Payment Scheme Component to contain payment scheme specific 7800 inquiry messages. 7802 7803 7806 Attributes: 7808 ID An identifier which uniquely identifies the 7809 Inquiry Request Trading Block within the IOTP 7810 Transaction. 7812 Content: 7814 InquiryType Inquiry Type Component (see section 7.18) that 7815 contains the type of inquiry. 7817 PaySchemeData Payment Scheme Component (see section 7.10) that 7818 contains payment scheme specific inquiry messages 7819 for inquiries on payments. This is present when 7820 the Type attribute of Inquiry Type Component is 7821 Payment. 7823 8.13 Inquiry Response Trading Block 7825 The Inquiry Response Trading Block contains a Status Component and an 7826 optional Payment Scheme Component to contain payment scheme specific 7827 inquiry messages. Its purpose is to enquire on the current status of an 7828 IOTP transaction at a server. 7830 7831 7836 Attributes: 7838 ID An identifier which uniquely identifies the 7839 Inquiry Response Trading Block within the 7840 IOTP Transaction. 7842 LastReceivedIotpMsgRef Contains an Element Reference (see section 7843 3.5) to the Message Id Component (see section 7844 3.3.2) of the last message this server has 7845 received from the Consumer. If there is no 7846 previously received message from the Consumer 7847 in the pertinent transaction, this attribute 7848 should be contain the value Null. This 7849 attribute exists for debugging purposes. 7851 LastSentIotpMsgRef Contains an Element Reference (see section 7852 3.5) to the Message Id Component (see section 7853 3.3.2) of the last message this server has 7854 sent to the Consumer. If there is no 7855 previously sent message to the Consumer in 7856 the pertinent transaction, this attribute 7857 should contain the value Null. This attribute 7858 exists for debugging purposes. 7860 Content: 7862 Status Contains status information about the business 7863 success (see section 4.2) or failure of a certain 7864 trading exchange (i.e., Offer, Payment, or 7865 Delivery). 7867 PaySchemeData Payment Scheme Component (see section 7.10) that 7868 contains payment scheme specific inquiry messages 7869 for inquiries on payments. This is present when 7870 the Type attribute of StatusType attribute of the 7871 Status Component is set to Payment. 7873 8.14 Ping Request Block 7875 The Ping Request Block is used to determine if a Server is operating and 7876 whether or not cryptography is compatible. 7878 The definition of a Ping Request Block is as follows. 7880 7881 7884 Attributes: 7886 ID An identifier which uniquely identifies the Ping 7887 Request Trading Block within the IOTP Transaction. 7889 Content: 7891 Org Optional Organisation Components (see section 7892 7.6). 7894 If no Organisation Component is present then the 7895 Ping Request is anonymous and simply determines if 7896 the server is operating. 7898 However if Organisation Components are present, 7899 then it indicates that the sender of the Ping 7900 Request wants to verify that digital signatures 7901 can be handled. 7903 In this case the sender includes: 7904 o an Organisation Component that identifies 7905 itself specifying the Trading Role(s) it is 7906 taking in IOTP transactions (Merchant, Payment 7907 Handler, etc) 7908 o an Organisation Component that identifies the 7909 intended recipient of the message. 7911 These are then used to generate a signature over 7912 the Ping Response Block. 7914 8.15 Ping Response Block 7916 The Ping Response Trading Block provides the result of a Ping Request. 7918 It contains an Organisation Component that identifies the sender of the 7919 Ping Response. 7921 If the Ping Request to which this block is a response contained 7922 Organisation Components, then it also contains those Organisation 7923 Components. 7925 7926 7933 Attributes: 7935 ID An identifier which uniquely identifies the Ping 7936 Request Trading Block within the IOTP 7937 Transaction. 7939 PingStatusCode Contains a code which shows the status of the 7940 sender software which processes IOTP messages. 7941 Valid values are: 7942 o Ok. Everything with the service is working 7943 normally, including the signature 7944 verification. 7945 o Busy. Things are working normally but there 7946 may be some delays. 7947 o Down. The server is not functioning fully but 7948 can still provide a Ping response. 7950 SigVerifyStatusCode Contains a code which shows the status of 7951 signature verification. This is present only 7952 when the message containing the Ping Request 7953 Block also contains a Signature Block. Valid 7954 values are: 7955 o Ok. The signature has successfully been 7956 verified and proved compatible. 7957 o NotSupported The receiver of this Ping 7958 Request Block does not support validation of 7959 signatures. 7960 o Fail. Signature verification failed. 7962 Xml:lang Defines the language used in PingStatusDesc. 7963 This is present when PingStatusDesc is present. 7965 PingStatusDesc Contains a short description of the status of 7966 the server which sends this Ping Response Block. 7967 Servers, if their designers want, can use this 7968 attribute to send more refined status 7969 information than PingStatusCode which can be 7970 used for debugging purposes, for example. 7972 Content: 7974 Org These are Organisation Components (see section 7975 7.6). 7977 The Organisation Components of the sender of the 7978 Ping Response is always included in addition to 7979 the Organisation Components sent in the Ping 7980 Request. 7982 [Note] Ping Status Code values do not include a value such as Fail, 7983 since, when the software receiving the Ping Request message is 7984 not working at all, no Ping Response message will be sent 7985 back. 7986 [Note End] 7988 8.16 Signature Block 7990 The Signature Block contains one or more Signature Components and 7991 associated Certificates (if required) which sign data associated with the 7992 IOTP Transaction. For a general discussion and introduction to how IOTP 7993 uses signatures, see section 6 Digital Signatures. The definition of the 7994 Signature Component and certificates is contained in the paper "Digital 7995 Signatures for the Internet Open Trading Protocol", see [IOTPDSIG]. 7996 Descriptions of how these are used by IOTP is contained in sections 7.19 7997 and 7.20. 7999 The definition of a Signature Block is as follows: 8001 8002 8005 Attributes: 8007 ID An identifier which uniquely identifies the 8008 Signature Block within the IOTP Transaction. 8010 Content: 8012 Signature A Signature Component. See section 7.19. 8014 Certificate A Certificate Component. See section 7.20. 8016 The contents of a Signature Block depends on the Trading Block that is 8017 contained in the same IOTP Message as the Signature Block. 8019 8.16.1 Signature Block with Offer Response 8021 A Signature Block which is in the same message as an Offer Response Block 8022 contains just an Offer Response Signature Component (see section 7.19.2). 8024 8.16.2 Signature Block with Payment Request 8026 A Signature Block which is in the same message as a Payment Request Block 8027 contains: 8029 o an Offer Response Signature Component (see section 7.19.2), and 8031 o if the Payment is dependent on an earlier step (as indicated by the 8032 StartAfter attribute on the Payment Component), then the Payment 8033 Receipt Signature Component (see section 7.19.3) generated by the 8034 previous step 8036 8.16.3 Signature Block with Payment Response 8038 A Signature Block which is in the same message as a Payment Response 8039 Block contains just a Payment Receipt Signature Component (see section 8040 7.19.3) generated by the step. 8042 8.16.4 Signature Block with Delivery Request 8044 A Signature Block which is in the same message as a Delivery Request 8045 Block contains: 8047 o an Offer Response Signature Component (see section 7.19.2), and 8049 o the Payment Receipt Signature Component (see section 7.19.3) generated 8050 by the previous step. 8052 8.16.5 Signature Block with Delivery Response 8054 A Signature Block which is in the same message as a Delivery Response 8055 Block contains just a Delivery Response Signature component (see section 8056 7.19.4) generated by the step. 8058 8.17 Error Block 8060 The Error Trading Block contains one or more Error Components (see 8061 section 7.21) which contain information about Technical Errors (see 8062 section 4.1) in an IOTP Message which has been received by one of the 8063 Trading Roles involved in the trade. 8065 For clarity two phrases are defined which are used in the description of 8066 an Error Trading Block: 8068 o message in error. An IOTP message which contains or causes an error of 8069 some kind 8071 o message reporting the error. An IOTP message that contains an Error 8072 Trading Block that describes the error found in a message in error. 8074 An Error Trading Block may be contained in any message reporting the 8075 error. The action which then follows depends on the severity of the 8076 error. See the definition of an Error Component, for an explanation of 8077 the different types of severity and the actions which can then occur. 8079 [Note] Although, an Error Trading Block can report multiple different 8080 errors using multiple Error Components, there is no obligation 8081 on a developer of an IOTP Aware Application to do so. 8082 [Note End] 8084 The structure of an Error Trading Block is as follows. 8086 8087 8090 Attributes: 8092 ID An identifier which uniquely identifies the Error 8093 Trading Block within the IOTP Transaction. 8095 Content: 8097 ErrorComp An Error Components (see section 7.21) that 8098 contains information about an individual Technical 8099 Error. 8101 PaySchemeData An optional Payment Scheme Component (see section 8102 7.10) which contains a Payment Scheme Message. See 8103 the appropriate payment scheme supplement to 8104 determine whether or not this component needs to 8105 be present and for the definition of what it must 8106 contain. 8108 8.18 Cancel Block 8110 The Cancel Block is used by one Trading Role to inform any other that a 8111 transaction has been cancelled. Example usage includes: 8113 o a Consumer Role informing a non-Consumer role that it no longer plans 8114 to continue with the transaction. This will allow the server to close 8115 down the transaction tidily without a waiting for a time-out to occur 8117 o a non-Consumer Role to inform a Consumer role that the Transaction is 8118 being stopped. In this case, the Consumer is then unlikely to re-send 8119 the previous message that was sent in the mistaken understanding that 8120 the original was not received. 8122 Its definition is as follows. 8124 8125 8128 Attributes: 8130 ID An identifier which uniquely identifies the Cancel 8131 Block within the IOTP Transaction. 8133 Content: 8135 Status Contains status information indicating that the 8136 IOTP transaction has been cancelled. 8138 9. Internet Open Trading Protocol Transactions 8140 The Baseline Internet Open Trading Protocol supports three types of 8141 transactions for different purposes. These are 8143 o an Authentication IOTP transaction which supports authentication of one 8144 party in a trade by another and/or requests information about another 8145 Trading Role 8147 o IOTP Transactions that involve one or more payments. Specifically: 8148 - Deposit 8149 - Purchase 8150 - Refund 8151 - Withdrawal, and 8152 - Value Exchange 8154 o IOTP Transactions designed to check the correct function of the IOTP 8155 infrastructure. Specifically: 8156 - Transaction Status Inquiry, and 8157 - Ping 8159 Although the Authentication IOTP Transaction can operate on its own, 8160 authentication can optionally precede any of the "payment" transactions. 8161 Therefore, the rest of this section is divided into two parts covering: 8163 o Authentication and Payment transactions (Authentication, Deposit, 8164 Purchase, Refund, Withdrawal and Value Exchange) 8166 o Infrastructure Transactions (Transaction Status Inquiry and Ping) that 8167 are designed to support inquiries on whether or not a transaction has 8168 succeeded or a Trading Role's servers are operating correctly, and 8170 9.1 Authentication and Payment Related IOTP Transactions 8172 The Authentication and Payment related IOTP Transactions consist of six 8173 Document Exchanges which are then combined in sequence to implement a 8174 specific transaction. 8176 Generally, there is a close, but not exact, correspondence between a 8177 Document Exchange and a Trading Exchange. The main difference is that 8178 some Document Exchanges implement part or all of two Trading Exchanges 8179 simultaneously in order to minimise the number of actual IOTP Messages 8180 which must be sent over the Internet. 8182 The six Document Exchanges are: 8184 o Authentication. This is a direct implementation of the Authentication 8185 Trading Exchange 8187 o Brand Dependent Offer. This is the Offer Trading Exchange combined with 8188 the Brand Selection part of the Payment Trading Exchange. Its purpose 8189 is to provide the Merchant with information on the Brand selected so 8190 that the content of the Offer Response may be adapted accordingly 8192 o Brand Independent Offer. This is also an Offer Trading Exchange. 8193 However, in this instance, the content of the Offer Response does not 8194 depend on the Brand selected. 8196 o Payment. This is a direct implementation of the Payment part of a 8197 Payment Trading Exchange 8199 o Delivery. This is a direct implementation of the Delivery Exchange 8201 o Delivery with Payment. This is an implementation of combined Payment 8202 and Delivery Trading Exchanges 8204 These Document Exchanges are combined together in different sequences to 8205 implement each IOTP Transaction. The way in which they may be combined is 8206 illustrated by the diagram below. 8207 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8209 START ----------------------------------------------------- 8210 | v 8211 | ---------------- 8212 | | AUTHENTICATION | 8213 | ---------------- 8214 -------------------------------------- | | 8215 | | | | 8216 | -------------- | ------------- | 8217 v v v v | 8218 ------------------- ----------------- | 8219 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 8220 | OFFER | | OFFER | | 8221 ------------------- ----------------- | 8222 | | | | | 8223 | --------------- | | | 8224 | | | | | 8225 | -------------- | -- | | 8226 v v v v | 8227 --------- -------------- | 8228 | PAYMENT | | PAYMENT WITH | | 8229 | (first) | | DELIVERY | | 8230 --------- -------------- | 8231 | | | 8232 ----------------------------- | | 8233 v v | | | 8234 ---------- --------- | | | 8235 | DELIVERY | | PAYMENT | | | | 8236 | | | {second)| | | | 8237 ---------- --------- | | | 8238 | | | | v 8239 ----------------------------------------------> STOP 8241 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8243 Figure 17 Payment and Authentication Message Flow Combinations 8245 The combinations of Document Exchanges that are valid depend on the 8246 particular IOTP transaction. 8248 The remainder of this sub-section describes: 8250 o each Document Exchange in more detail including descriptions of the 8251 content of each Trading Block in the Document Exchanges, and 8253 o descriptions of how each IOTP Transaction uses the Document Exchanges 8254 to effect the desired result. 8256 [Note] The descriptions of the Document Exchanges which follow 8257 describe the ways in which various Business Errors (see 8258 section 4.2) are handled. No reference is made however to the 8259 handling of Technical Errors (see section 4.1) in any of the 8260 messages since these are handled the same way irrespective of 8261 the context in which the message is being sent. See section 4 8262 for more details. 8263 [Note End] 8265 9.1.1 Authentication Document Exchange 8267 The Authentication Document Exchange is a direct implementation of the 8268 Authentication Trading Exchange (see section 2.2.4). It involves: 8270 o an Authenticator - the Organisation which is requesting the 8271 authentication, and 8273 o an Authenticatee - the Organisation being authenticated. 8275 The authentication consists of: 8277 o an Authentication Request being sent by the Authenticator to the 8278 Authenticatee, 8280 o an Authentication Response being sent in return by the Authenticatee to 8281 the Authenticator which is then checked, and 8283 o an Authentication Status being sent by the Authenticator to the 8284 Authenticatee to provide an indication of the success or failure of the 8285 authentication. 8287 An Authentication Document Exchange also: 8289 o provides an Authenticatee with an Organisation Component which 8290 describes the Authenticator, and 8292 o optionally provides the Authenticator with Organisation Components 8293 which describe the Authenticatee. 8295 The Authentication Request may also be digitally signed which allows the 8296 Authenticatee to verify the credentials of the Authenticator. 8298 The IOTP Messages which are involved are illustrated by the diagram 8299 below. 8300 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8301 Organisation 1 8302 (Authenticatee) 8303 | Organisation 2 8304 | (Authenticator) 8305 STEP | | 8306 1. First Organisation takes an action (for example by pressing a 8307 button on an HTML page) which requires that the Organisation 8308 is authenticated 8310 1 --> 2 Authentication Need (outside scope of IOTP) 8312 2. The second Organisation generates: an Authentication Request 8313 Block containing one or more Authentication Request 8314 Components and/or a Trading Role Information Request 8315 Component, then sends it to the first Organisation 8317 1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block; 8318 Signature Block (optional); TPO Block; Auth Request Block 8320 3. IOTP aware application started. If a Signature Block is 8321 present, the first Organisation may use this to check the 8322 credentials of the second Organisation. If credentials are 8323 OK, the first Organisation selects an Authentication Request 8324 to use (if present and more than one), then uses the 8325 authentication algorithm selected to generate an 8326 Authentication Response Block. If present, the Trading Role 8327 Information Request Component is used to generate 8328 Organisation Components. Finally a Signature Component is 8329 created if required and all components are then sent back to 8330 the second Organisation for validation. 8332 1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature 8333 Block (optional) ; Auth Response Block 8335 4. The second Organisation checks the Authentication Response 8336 against the data in the Authentication Request Block to check 8337 that the first Organisation is who they appear to be, and 8338 sends an Authentication Status Block to the first 8339 Organisation to indicate the result then stops. 8341 1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature 8342 Block (optional); Auth Response Block 8344 5. The first Organisation checks the authentication Status Block 8345 and optionally keeps information on the IOTP transaction for 8346 record keeping purposes and stops. 8348 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8350 Figure 18 Authentication Document Exchange 8352 9.1.1.1 Message Processing Guidelines 8354 On receiving a TPO & Authentication Request IOTP Message (see below), an 8355 Authenticatee may either: 8357 o generate and send an Authentication Response IOTP Message back to the 8358 Authenticator, or 8360 o indicate failure to comply with the Authentication Request by sending a 8361 Cancel Block back to the Authenticator containing a Status Component 8362 with a StatusType of Authentication a ProcessState of Failed and the 8363 CompletionCode (see section 7.16.4) set to either: AutEeCancel, 8364 NoAuthReq, TradRolesIncon or Unspecified. 8366 On receiving an Authentication Response IOTP Message (see below), an 8367 Authenticator should send in return, an Authentication Status IOTP 8368 Message (see below) containing a Status Block with a Status Component 8369 where the StatusType is set to Authentication, and: 8371 o the ProcessState attribute of the Status Component is set to 8372 CompletedOk which indicates a successful completion, or 8374 o the ProcessState attribute is set to Failed and the CompletionCode 8375 attribute is set to either: AutOrCancel, AuthFailed or Unspecified 8376 which indicates a failed authentication, 8378 On receiving an Authentication Status IOTP Message (see below), the 8379 Authenticatee should check the Status Component in the Status Block. If 8380 this indicates: 8382 o a successful authentication, then the Authenticatee should either: 8383 - continue with the next step in the IOTP Transaction of which the 8384 Authentication Document Exchange is part (if any), or 8385 - indicate a failure to continue with the rest of the IOTP Transaction, 8386 by sending back to the Authenticator a Cancel Block containing a 8387 Status Component with a StatusType of Authentication, a ProcessState 8388 of Failed and the CompletionCode (see section 7.16.4) set to 8389 AutEeCancel. 8391 o a failed authentication, then the failure should be reported to the 8392 Authenticatee and any further processing stopped. 8394 If the Authenticator receives an IOTP Message containing a Cancel block 8395 from a Consumer, then the Authenticatee may go to the CancelNetLocn 8396 specified on the Trading Role Element in the Organisation Component for 8397 the Authenticator contained in the Trading Protocol Options Block. 8399 9.1.1.2 TPO & Authentication Request IOTP Message 8401 Apart from a Transaction Reference Block (see section 3.3), this message 8402 consists of: 8404 o a Trading Protocol Options Block (see section 8.1) 8406 o an Authentication Request Block (see section 8.4), and 8408 o an optional Signature Block (see section 8.16). 8410 Each of these are described below. 8412 TRADING PROTOCOL OPTIONS BLOCK 8414 The Trading Protocol Options Block (see section 8.1) must contain the 8415 following Trading Components: 8417 o one Protocol Options Component (see Section 7.1) which defines the 8418 options which apply to the whole Authentication Document Exchange. 8420 o one Organisation Component (see section 7.6) which describes the 8421 Authenticator. The Trading Role on the Organisation Component should 8422 indicate the role which the Authenticator is taking in the Trade, for 8423 example a Merchant or a Consumer. 8425 AUTHENTICATION REQUEST BLOCK 8427 The Authentication Request Block (see section 8.4) must contain the 8428 following Trading Components: 8430 o one Authentication Request Component (see section 7.2), and 8432 SIGNATURE BLOCK (AUTHENTICATION REQUEST) 8434 If the Authentication Request is being digitally signed then a Signature 8435 Block must be included. It contains Digests of the following XML 8436 elements: 8438 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8439 that contains information that describes the IOTP Message and IOTP 8440 Transaction 8442 o the Transaction Id Component (see section 3.3.1) which globally 8443 uniquely identifies the IOTP Transaction 8445 o the following components of the TPO Block : 8446 - the Protocol Options Component 8447 - the Organisation Component 8449 o the following components of the Authentication Request Block: 8451 - the Authentication Request Component 8452 - the Trading Role Information Request Component 8454 9.1.1.3 Authentication Response IOTP Message 8456 Apart from a Transaction Reference Block (see section 3.3), this message 8457 consists of: 8459 o an Authentication Response Block (see section 8.5), and 8461 o an optional Signature Block (see section 8.16). 8463 Each of these are described below. 8465 AUTHENTICATION RESPONSE BLOCK 8467 The Authentication Response Block must contain the following Trading 8468 Component: 8470 o one Authentication Response Component (see section 7.3) 8472 o one Organisation Component for every Trading Role identified in the 8473 TradingRoleList attribute of the Trading Role Information Request 8474 Component contained in the Authentication Request Block. 8476 SIGNATURE BLOCK (AUTHENTICATION RESPONSE) 8478 If the Algorithm element (see section 12. IANA Considerations) within the 8479 Authentication Request Component contained in the Authentication Request 8480 Block indicates that the Authentication Response should consist of a 8481 digital signature then a Signature Block must be included in the same 8482 IOTP message that contains an Authentication Response Block. The 8483 Signature Component contains Digest Elements for the following XML 8484 elements: 8486 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8487 that contains information that describes the IOTP Message and IOTP 8488 Transaction 8490 o the Transaction Id Component (see section 3.3.1) which globally 8491 uniquely identifies the IOTP Transaction 8493 o the following components of the Authentication Request Block: 8494 - the Authentication Request Component 8495 - the Trading Role Information Request Component 8497 o the Organisation Components contained in the Authentication Response 8498 Block 8500 [Note] It should not be assumed that all trading roles can support 8501 the signing of data. Particularly it should not be assumed 8502 that Consumers support the signing of data. 8503 [Note End] 8505 9.1.1.4 Authentication Status IOTP Message 8507 Apart from a Transaction Reference Block (see section 3.3), this message 8508 consists of: 8510 o an Authentication Status Block (see section 8.5), and 8512 o an optional Signature Block (see section 8.16). 8514 Each of these are described below. 8516 AUTHENTICATION STATUS BLOCK 8518 The Authentication Status Block (see section 8.6) must contain the 8519 following Trading Components: 8521 o one Status Component (see section 7.16) with a ProcessState attribute 8522 set to CompletedOk. 8524 SIGNATURE BLOCK (AUTHENTICATION STATUS) 8526 If the Authentication Status Block is being digitally signed then a 8527 Signature Block must be included that contains a Signature Component with 8528 Digest elements for the following XML elements: 8530 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8531 that contains information that describes the IOTP Message and IOTP 8532 Transaction 8534 o the Transaction Id Component (see section 3.3.1) which globally 8535 uniquely identifies the IOTP Transaction 8537 o the following components of the Authentication Status Block: 8538 - the Status Component (see section 7.16). 8540 [Note] If the Authentication Document Exchange is followed by an 8541 Offer Document Exchange (see section 9.1.2) then the 8542 Authentication Status Block and the Signature Block 8543 (Authentication Status) may be combined with either: 8544 o a TPO IOTP Message (see section 9.1.2.3), or 8545 o a TPO and Offer Response IOTP Message (see section 9.1.2.6) 8546 [Note End] 8548 9.1.2 Offer Document Exchange 8550 The Offer Document Exchange occurs in two basic forms: 8552 o Brand Dependent Offer Exchange. Where the content of the offer, e.g. 8553 the order details, amount, delivery details, etc., are dependent on the 8554 payment brand and protocol selected by the consumer, and 8556 o Brand Independent Offer Exchange. Where the content of the offer is not 8557 dependent on the payment brand and protocol selected. 8559 Each of these types of Offer Document Exchange may be preceded by an 8560 Authentication Document Exchange (see section 9.1.1). 8562 9.1.2.1 Brand Dependent Offer Document Exchange 8564 In a Brand Dependent Offer Document Exchange the TPO Block and the Offer 8565 Response Block are sent separately by the Merchant to the Consumer, i.e.: 8567 o the Brand List Component is sent to the Consumer in a TPO Block, 8569 o the Consumer selects a Payment Brand, Payment Protocol and optionally a 8570 Currency and amount from the Brand List Component 8572 o the Consumer sends the selected brand, protocol and currency/amount 8573 back to the Merchant in a TPO Selection Block, and 8575 o the Merchant uses the information received to define the content of and 8576 then send the Offer Response Block to the Consumer. 8578 This is illustrated by the diagram below. 8579 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8580 Consumer 8581 | Merchant 8582 STEP | | 8583 1. Consumer decides to trade and sends to the Merchant 8584 information (e.g. using HTML) that enables the Merchant to 8585 create an offer, 8587 C --> M Offer information - outside scope of IOTP 8589 2. Merchant decides which payment brand protocols, currencies 8590 and amounts apply, places then in a Brand List Component 8591 inside a TPO Block and sends to Consumer 8593 C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block 8595 3. IOTP aware application started. Consumer selects the payment 8596 brand, payment protocol and currency/amount to use. Records 8597 selection in a Brand Selection Component and sends back to 8598 Merchant. 8600 C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection Block 8602 4. Merchant uses selected payment brand, payment protocol, 8603 currency/amount and the offer information to create an Offer 8604 Response Block containing details about the IOTP Transaction 8605 including price, etc. Optionally signs it and sends to the 8606 Consumer 8608 C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8609 (optional); Offer Response Block 8611 5. Consumer checks the Offer is OK, then combines components 8612 from the TPO Block, the TPO Selection Block and the Offer 8613 Response Block to create the next IOTP Message for the 8614 Transaction and sends it together with the Signature block if 8615 present to the required Trading Role 8617 CONTINUED ... 8619 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8621 Figure 19 Brand Dependent Offer Document Exchange 8623 Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by 8624 the absence of an Offer Response Block in the first IOTP Message. 8626 MESSAGE PROCESSING GUIDELINES 8628 On receiving a TPO IOTP Message (see below), the Consumer may either: 8630 o generate and send a TPO Selection IOTP Message back to the Merchant, or 8632 o indicate failure to continue with the IOTP Transaction by sending a 8633 Cancel Block back to the Merchant containing a Status Component with a 8634 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8635 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8637 On receiving a TPO Selection IOTP Message (see below) the Merchant may 8638 either: 8640 o generate and send an Offer Response IOTP Message back to the Consumer, 8641 or 8643 o indicate failure to continue with the IOTP Transaction by sending a 8644 Cancel Block back to the Consumer containing a Status Component with a 8645 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8646 (see section 7.16.4) set to either: MerchCancelled or Unspecified. 8648 On receiving an Offer Response IOTP Message (see below) the Consumer may 8649 either: 8651 o generate and send the next IOTP Message in the IOTP transaction and 8652 send it to the required Trading Role. This is dependent on the IOTP 8653 Transaction, or 8655 o indicate failure to continue with the IOTP Transaction by sending a 8656 Cancel Block back to the Merchant containing a Status Component with a 8657 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8658 (see section 7.16.4) set to either: ConsCancelled or Unspecified. 8660 If the Merchant receives an IOTP Message containing a Cancel block, then 8661 the Consumer is likely to go to the CancelNetLocn specified on the 8662 Trading Role Element in the Organisation Component for the Merchant. 8664 If the Consumer receives an IOTP Message containing a Cancel block, then 8665 the information contained in the IOTP Message should be reported to the 8666 Consumer but no further action taken. 8668 9.1.2.2 Brand Independent Offer Document Exchange 8670 In a Brand Independent Offer Document Exchange the TPO Block and the 8671 Offer Response Block are sent together by the Merchant to the Consumer, 8672 i.e. there is one IOTP Message that contains both a TPO Block, and an 8673 Offer Response Block. 8675 The message flow is illustrated by the diagram below: 8676 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8677 Consumer 8678 | Merchant 8679 STEP | | 8680 1. Consumer decides to trade and sends to the Merchant 8681 information (e.g. using HTML) that enables the Merchant to 8682 create an offer, 8684 C --> M Offer information - outside scope of IOTP 8686 2. Merchant decides which payment brand protocols, currencies 8687 and amounts apply, places then in a Brand List Component 8688 inside a TPO Block, creates an Offer Response containing 8689 details about the IOTP Transaction including price, etc., 8690 optionally signs it and sends to Consumer 8692 C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature 8693 Block; TPO Block; Offer Response Block 8695 3. IOTP aware application started. Consumer selects the payment 8696 brand, payment protocol and currency/amount to use. Records 8697 selection in a Brand Selection Component, checks offer is OK, 8698 combines the Brand Selection Component with information from 8699 the TPO Block and Offer Response Block to create the next 8700 IOTP Message for the Transaction and sends it together with 8701 the Signature Block if present to the required Trading Role. 8703 CONTINUED ... 8705 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8707 Figure 20 Brand Independent Offer Exchange 8709 Note that a Brand Independent Offer Document Exchange always occurs when 8710 only one payment brand, protocol and currency/amount is being offered to 8711 the Consumer by the Merchant. It is also likely to, but will not 8712 necessarily, occur when multiple brands are being offered, the Payment 8713 Handler is the same, and all brands use the same set of protocols. 8715 Note that the TPO Block and the Offer Response Block can be sent in 8716 separate IOTP messages (see Brand Dependent Offer Document Exchange) even 8717 if the Offer Response Block does not change. However this increases the 8718 number of messages in the transaction and is therefore likely to increase 8719 transaction response times. 8721 IOTP aware applications supporting the Consumer Trading Role must check 8722 for the existence of an Offer Response Block in the first IOTP Message to 8723 determine whether the Offer Document Exchange is brand dependent or not. 8725 MESSAGE PROCESSING GUIDELINES 8727 On receiving a TPO and Offer Response IOTP Message (see below), the 8728 Consumer may either: 8730 o generate and send the next IOTP Message in the IOTP transaction and 8731 send it to the required Trading Role. This is dependent on the IOTP 8732 Transaction, or 8734 o indicate failure to continue with the IOTP Transaction by sending a 8735 Cancel Block back to the Merchant containing a Status Component with a 8736 StatusType of Offer, a ProcessState of Failed and the CompletionCode 8737 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 8739 If the Merchant receives an IOTP Message containing a Cancel block, then 8740 the Consumer is likely to go to the CancelNetLocn specified on the 8741 Trading Role Element in the Organisation Component for the Merchant. 8743 9.1.2.3 TPO IOTP Message 8745 The TPO IOTP Message is only used with a Brand Dependent Offer Document 8746 Exchange. Apart from a Transaction Reference Block (see section 3.3), 8747 this message consists of just a Trading Protocol Options Block (see 8748 section 8.1) which is described below. 8750 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8752 The Trading Protocol Options Block (see section 8.1) must contain the 8753 following Trading Components: 8755 o one Protocol Options Component which defines the options which apply to 8756 the whole IOTP Transaction. See Section 7.1. 8758 o one Brand List Component (see section 7.7) for each Payment in the IOTP 8759 Transaction that contain one or more payment brands and protocols which 8760 may be selected for use in each payment 8762 o Organisation Components (see section 7.6) with the following roles: 8763 - Merchant who is making the offer 8764 - Consumer who is carrying out the transaction 8765 - the PaymentHandler(s) for the payment. The "ID" of the Payment 8766 Handler Organisation Component is contained within the PhOrgRef 8767 attribute of the Payment Component 8769 If the IOTP Transaction includes a Delivery then the TPO Block must also 8770 contain: 8772 o Organisation Components with the following roles: 8773 - DeliveryHandler who will be delivering the goods or services 8774 - DelivTo i.e. the person or Organisation which is to take delivery 8776 AUTHENTICATION STATUS AND SIGNATURE BLOCKS 8778 If the Offer Document Exchange was preceded by an Authentication Document 8779 Exchange, then the TPO IOTP Message may also contain: 8781 o an Authentication Status Block (see section 8.6), and 8783 o an optional Signature Block (Authentication Status) Signature Block 8785 See section 9.1.1.4 Authentication Status IOTP Message for more details. 8787 9.1.2.4 TPO Selection IOTP Message 8789 The TPO Selection IOTP Message is only used with a Brand Dependent Offer 8790 Document Exchange. Apart from a Transaction Reference Block (see section 8791 3.3), this message consists of just a TPO Selection Block (see section 8792 8.1) which is described below. 8794 TPO SELECTION BLOCK 8796 The TPO Selection Block (see section 8.2) contains: 8798 o one Brand Selection Component (see section 7.8) for use in a later 8799 Payment Exchange. It contains the results of the consumer selecting a 8800 Payment Brand, Payment Protocol and currency/amount from the list 8801 provided in the Brand List Component. 8803 9.1.2.5 Offer Response IOTP Message 8805 The Offer Response IOTP Message is only used with a Brand Dependent Offer 8806 Document Exchange. Apart from a Transaction Reference Block (see section 8807 3.3), this message consists of: 8809 o an Offer Response Block (see section 8.1) and 8811 o an optional Signature Block (see section 8.16). 8813 OFFER RESPONSE BLOCK 8815 The Offer Response Block (see section 8.3) contains the following 8816 components: 8818 o one Status Component (see section 7.16) which indicates the status of 8819 the Offer Response. The ProcessState attribute should be set to 8820 CompletedOk 8822 o one Order Component (see section 7.5) which contains details about the 8823 goods and services which are being purchased or the financial 8824 transaction which is taking place 8826 o one or more Payment Component(s) (see section 7.9) for each payment 8827 which is to be made 8829 o zero or one Delivery Components (see section 7.13) containing details 8830 of the delivery to be made if the IOTP Transaction includes a delivery 8832 o zero or more Trading Role Data Components (see section 7.17) if 8833 required by the Merchant. 8835 SIGNATURE BLOCK (OFFER RESPONSE) 8837 If the Authentication Status Block is being digitally signed then a 8838 Signature Block must be included that contains a Signature Component (see 8839 section 7.19) with Digest Elements for the following XML elements: 8841 If the Offer Response is being digitally signed then a Signature Block 8842 must be included that contains a Signature Component (see section 7.19) 8843 with Digest Elements for the following XML elements: 8845 o the Transaction Reference Block (see section 3.3) for the IOTP Message 8846 that contains information that describes the IOTP Message and IOTP 8847 Transaction 8849 o the Transaction Id Component (see section 3.3.1) which globally 8850 uniquely identifies the IOTP Transaction 8852 o the following components of the TPO Block : 8853 - the Protocol Options Component, and 8854 - the Brand List Component 8855 - all the Organisation Components present 8857 o the following components of the Offer Response Block: 8858 - the Order Component 8859 - all the Payment Components present 8860 - the Delivery Component if present 8861 - any Trading Role Data Components present 8863 9.1.2.6 TPO and Offer Response IOTP Message 8865 The TPO and Offer Response IOTP Message is only used with a Brand 8866 Independent Offer Document Exchange. Apart from a Transaction Reference 8867 Block (see section 3.3), this message consists of: 8869 o a Trading Protocol Options Block (see section 8.1) 8871 o an Offer Response Block (see section 8.1) and 8873 o an optional Signature Block (see section 8.16). 8875 TPO (TRADING PROTOCOL OPTIONS) BLOCK 8877 This is the same as the Trading Protocol Options Block described in TPO 8878 IOTP Message (see section 9.1.2.3). 8880 OFFER RESPONSE BLOCK 8882 This the same as the Offer Response Block in the Offer Response IOTP 8883 Message (see section 9.1.2.5). 8885 AUTHENTICATION STATUS 8887 If the Offer Document Exchange was preceded by an Authentication Document 8888 Exchange, then the TPO and Offer Response IOTP Message may also contain 8889 an Authentication Status Block (see section 8.6). 8891 SIGNATURE BLOCK 8893 This is the same as the Signature Block in the Offer Response IOTP 8894 Message (see section 9.1.2.5) with the addition that: 8896 o if the Offer Document Exchange is Brand Dependent then the Signature 8897 Component in the Signature Block additionally contains a Digest Element 8898 for the Brand Selection Component contained in the TPO Selection Block 8900 o if the Offer Document Exchange was preceded by an Authentication 8901 Document Exchange then the Signature Component in the Signature Block 8902 additionally contains a Digest Element for the Authentication Status 8903 Block. 8905 9.1.3 Payment Document Exchange 8907 The Payment Document Exchange is a direct implementation of the last part 8908 of a Payment Trading Exchange (see section 2.2.2) after the Brand has 8909 been selected by the Consumer. A Payment Exchange consists of: 8911 o the Consumer requesting that a payment starts by generating Payment 8912 Request IOTP Message using information from previous IOTP Messages in 8913 the Transaction and then sending it to the Payment Handler 8915 o the Payment Handler and the Consumer then swapping Payment Exchange 8916 IOTP Messages encapsulating payment protocol messages until the payment 8917 is complete, and finally 8919 o the Payment Handler sending a Payment Response IOTP Message to the 8920 Consumer containing a receipt for the payment. 8922 The IOTP Messages which are involved are illustrated by the diagram 8923 below. 8924 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 8925 Consumer 8926 | Payment 8927 | Handler 8928 STEP | | 8929 1. Consumer generates Pay Request Block encapsulating a payment 8930 protocol message if required and sends to Payment Handler 8931 with the Signature Block if present 8933 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block 8934 (optional); Pay Request Block 8936 2. Payment Handler processes Pay Request Block, checks optional 8937 signature and starts exchanging payment protocol messages 8938 encapsulated in a Pay Exchange Block, with the Consumer 8940 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 8941 Block 8943 3. Consumer and Payment Handler keep on exchanging Payment 8944 Exchange blocks until eventually payment protocol messages 8945 finish so Payment Handler creates a Pay Receipt Component 8946 inside a Pay Response Block, and an optional Signature 8947 Component inside a Signature Block, sends them to the 8948 Consumer and stops. 8950 C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature Block 8951 (optional); Pay Response Block 8953 4. Consumer checks Payment Response is OK. Optionally keeps 8954 information on IOTP Transaction for record keeping purposes 8955 and either stops or creates the next IOTP message for the 8956 Transaction and sends it together with the Signature Block, 8957 if present, to the required Trading Role 8959 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 8961 Figure 21 Payment Document Exchange 8963 9.1.3.1 Message Processing Guidelines 8965 On receiving a Payment Request IOTP Message, the Payment Handler should 8966 check that they are authorised to carry out the Payment (see section 6 8967 Digital Signatures). They may then either: 8969 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8970 if more payment protocol messages need to be exchanged, or 8972 o generate and send a Payment Response IOTP Message if the exchange of 8973 payment protocol messages is complete, or 8975 o indicate failure to continue with the Payment by sending a Cancel Block 8976 back to the Consumer containing a Status Component with a StatusType of 8977 Payment, a ProcessState of Failed and the CompletionCode (see section 8978 7.16.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, 8979 AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument 8980 or Unspecified. 8982 On receiving a Payment Exchange IOTP Message, the Consumer may either: 8984 o generate and send a Payment Exchange Message back to the Payment 8985 Handler or 8987 o indicate failure to continue with the Payment by sending a Cancel Block 8988 back to the Payment Handler containing a Status Component with a 8989 StatusType of Payment, a ProcessState of Failed and the CompletionCode 8990 (see section 7.16.2) set to either: ConsCancelled or Unspecified. 8992 On receiving a Payment Exchange IOTP Message, the Payment Handler may 8993 either: 8995 o generate and send a Payment Exchange IOTP Message back to the Consumer, 8996 if more payment protocol messages need to be exchanged, or 8998 o generate and send a Payment Response IOTP Message if the exchange of 8999 payment protocol messages is complete, or 9001 o indicate failure to continue with the Payment by sending a Cancel Block 9002 back to the Consumer containing a Status Component with a StatusType of 9003 Payment, a ProcessState of Failed and the CompletionCode (see section 9004 7.16.2) set to either: PaymtCancelled or Unspecified. 9006 On receiving a Payment Response IOTP Message, the Consumer may either: 9008 o generate and send the next IOTP Message in the IOTP transaction and 9009 send it to the required Trading Role. This is dependent on the IOTP 9010 Transaction, 9012 o stop, since the IOTP Transaction has ended, or 9014 o indicate failure to continue with the IOTP Transaction by sending a 9015 Cancel Block back to the Merchant containing a Status Component with a 9016 StatusType of Payment, a ProcessState of Failed and the CompletionCode 9017 (see section 7.16.1) set to either: ConsCancelled or Unspecified. 9019 If the Consumer receives an IOTP Message containing a Cancel block, then 9020 the information contained in the IOTP Message should be reported to the 9021 Consumer but no further action taken. 9023 If the Payment Handler receives an IOTP Message containing a Cancel 9024 block, then the Consumer is likely to go to the CancelNetLocn specified 9025 on the Trading Role Element in the Organisation Component for the Payment 9026 Handler from which any further action may take place. 9028 If the Merchant receives an IOTP Message containing a Cancel block, then 9029 the Consumer should have completed the payment but not continuing with 9030 the transaction for some reason. In this case the Consumer is likely to 9031 go to the CancelNetLocn specified on the Trading Role Element in the 9032 Organisation Component for the Merchant from which any further action may 9033 take place. 9035 9.1.3.2 Payment Request IOTP Message 9037 Apart from a Transaction Reference Block (see section 3.3), this message 9038 consists of: 9040 o a Payment Request Block, and 9041 o an optional Signature Block 9043 PAYMENT REQUEST BLOCK 9045 The Payment Request Block (see section 8.7) contains: 9047 o the following components copied from the Offer Response Block from the 9048 preceding Offer Document Exchange: 9049 - the Status Component 9050 - the Payment Component for the payment which is being carried out 9052 o the following components from the TPO Block: 9053 - the Organisation Components with the roles of Merchant and for the 9054 PaymentHandler that is being sent the Payment Request Block 9055 - the Brand List Component for the payment, i.e. the Brand List 9056 referred to by the BrandListRef attribute on the Payment Component 9058 o one Brand Selection Component for the Brand List, i.e. the Brand 9059 Selection Component where BrandListRef attribute points to the Brand 9060 List. This component can be either: 9061 - copied from the TPO Selection Block if the payment was preceded by a 9062 Brand Dependent Offer Document Exchange (see section 9.1.2.1), or 9063 - created by the Consumer, containing the payment brand, payment 9064 protocol and currency/amount selected from the Brand List, if the 9065 payment was preceded by a Brand Independent Offer Document Exchange 9066 (see section 9.1.2.2) 9068 o an optional Payment Scheme Component (see section 7.10) if required by 9069 the payment method used (see the Payment Method supplement to determine 9070 if this is needed). 9072 o zero or more Trading Role Data Components (see section 7.17). 9074 Note that: 9076 o if there is more than one Payment Components in an Offer Response 9077 Block, then the second payment is the one within the Offer Response 9078 Block that contains a StartAfter attribute (see section 7.9) that 9079 identifies the Payment Component for the first payment 9081 o the Payment Handler to include is identified by the Brand Selection 9082 Component (see section 7.8) for the payment. Also see section 6.3.1 9083 Check Request Block sent Correct Organisation for an explanation on how 9084 Payment Handlers are identified 9086 o the Brand List Component to include is the one identified by the 9087 BrandListRef attribute of the Payment Component for the identified 9088 payment 9090 o the Brand Selection Component to include from the Offer Response Block 9091 is the one that contains an BrandListRef attribute (see section 3.5) 9092 which identifies the Brand List Component for the second payment. 9094 SIGNATURE BLOCK (PAYMENT REQUEST) 9096 If the either the preceding Offer Document Exchange included an Offer 9097 Response Signature (see section 9.1.2.5 Offer Response IOTP Message), or 9098 a preceding Payment Exchange included a Payment Response Signature (see 9099 section 9.1.3.4 Payment Response IOTP Message) then they should both be 9100 copied to the Signature Block in the Payment Request IOTP Message. 9102 9.1.3.3 Payment Exchange IOTP Message 9104 Apart from a Transaction Reference Block (see section 3.3), this message 9105 consists of just a Payment Exchange Block. 9107 PAYMENT EXCHANGE BLOCK 9109 The Payment Exchange Block (see section 8.8) contains: 9111 o one Payment Scheme Component (see section 7.10) which contains payment 9112 method specific data. See the Payment Method supplement for the payment 9113 method being used to determine what this should contain. 9115 9.1.3.4 Payment Response IOTP Message 9117 Apart from a Transaction Reference Block (see section 3.3), this message 9118 consists of: 9120 o a Payment Response Block, and 9122 o an optional Signature Block 9124 PAYMENT RESPONSE BLOCK 9126 The Payment Response Block (see section 8.9) contains: 9128 o one Payment Receipt Component (see section 7.11) which contains scheme 9129 specific data which can be used to verify the payment occurred 9131 o one Payment Scheme Component (see section 7.10) if required which 9132 contains payment method specific data. See the Payment Method 9133 supplement for the payment method being used to determine what this 9134 should contain 9136 o an optional Payment Note Component (see section 7.12) 9138 o zero or more Trading Role Data Components (see section 7.17). 9140 SIGNATURE BLOCK (PAYMENT RESPONSE) 9142 If a signed Payment Receipt is being provided, indicated by the 9143 SignedPayReceipt attribute of the Payment Component being set to True, 9144 then the Signature Block should contain a Signature Component which 9145 contains Digest Elements for the following: 9147 o the Transaction Reference Block (see section 3.3) for the IOTP Message 9148 which contains the first usage of the Payment Response Block, 9150 o the Transaction Id Component (see section 3.3.1) within the Transaction 9151 Reference Block that globally uniquely identifies the IOTP Transaction, 9153 o the Payment Receipt Component from the Payment Response Block, 9155 o the Payment Note Component from the Payment Response Block, 9157 o the other Components referenced by the PayReceiptNameRefs attribute (if 9158 present) of the Payment Receipt Component, 9160 o the Status Component from the Payment Response Block, 9162 o any Trading Role Data Components in the Payment Response Block, and 9164 o all the Signature Components contained in the Payment Request Block if 9165 present. 9167 9.1.4 Delivery Document Exchange 9169 The Delivery Document Exchange is a direct implementation of a Delivery 9170 Trading Exchange (see section 2.2.3). It consists of: 9172 o the Consumer requesting a Delivery by generating Delivery Request IOTP 9173 Message using information from previous IOTP Messages in the 9174 Transaction and then sending it to the Delivery Handler 9176 o the Delivery Handler sending a Delivery Response IOTP Message to the 9177 Consumer containing details about the Handler's response to the request 9178 together with an optional signature. 9180 The message flow is illustrated by the diagram below. 9181 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9182 Consumer 9183 | Delivery 9184 | Handler 9185 STEP | | 9186 1. Consumer generates Delivery Request Block and sends it to the 9187 Delivery Handler with the Signature Block if present 9189 C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9190 Delivery Request Block 9192 2. Delivery Handler checks the Status and Order Components in 9193 the Delivery Request and the optional Signatures, creates a 9194 Delivery Response Block, sends to the Consumer and stops. 9196 C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature Block; 9197 Delivery Response Block 9199 3. Consumer checks Delivery Response Block and optional 9200 Signature Block are OK. Optionally keeps information on IOTP 9201 Transaction for record keeping purposes and stops. 9203 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9205 Figure 22 Delivery Document Exchange 9207 9.1.4.1 Message Processing Guidelines 9209 On receiving a Delivery Request IOTP Message, the Delivery Handler should 9210 check that they are authorised to carry out the Delivery (see section 6 9211 Digital Signatures). They may then either: 9213 o generate and send a Delivery Response IOTP Message to the Consumer, or 9215 o indicate failure to continue with the Delivery by sending a Cancel 9216 Block back to the Consumer containing a Status Component with a 9217 StatusType of Delivery, a ProcessState of Failed and the CompletionCode 9218 (see section 7.16.4) set to either: DelivCanceled, or Unspecified. 9220 On receiving a Delivery Response IOTP Message, the Consumer should just 9221 stop since the IOTP Transaction is complete. 9223 If the Consumer receives an IOTP Message containing a Cancel block, then 9224 the information contained in the IOTP Message should be reported to the 9225 Consumer but no further action taken. 9227 9.1.4.2 Delivery Request IOTP Message 9229 The Delivery Request IOTP Message consists of: 9231 o a Delivery Request Block, and 9233 o an optional Signature Block 9235 DELIVERY REQUEST BLOCK 9237 The Delivery Request Block (see section 8.10) contains: 9239 o the following components copied from the Offer Response Block: 9240 - the Status Component (see section 7.16) 9241 - the Order Component (see section 7.5) 9242 - the Organisation Component (see section 7.6) with the roles of: 9243 Merchant, DeliveryHandler and DeliverTo 9244 - the Delivery Component (see section 7.13) 9246 o the following Component from the Payment Response Block: 9247 - the Status Component (see section 7.16). 9249 o zero or more Trading Role Data Components (see section 7.17). 9251 SIGNATURE BLOCK (DELIVERY REQUEST) 9253 If the preceding Offer Document Exchange included an Offer Response 9254 Signature or the Payment Document Exchange included a Payment Response 9255 Signature, then they should both be copied to the Signature Block. 9257 9.1.4.3 Delivery Response IOTP Message 9259 The Delivery Response IOTP Message contains a Delivery Response Block and 9260 an optional Signature Block. 9262 DELIVERY RESPONSE BLOCK 9264 The Delivery Response Block contains: 9266 o one Delivery Note Component (see section 7.15) which contains delivery 9267 instructions about the delivery of goods or services 9269 SIGNATURE BLOCK (DELIVERY RESPONSE) 9271 The Signature Block should contain one Signature Component that contains 9272 Digest elements that refer to 9274 o the Transaction Id Component (see section 3.3.1) of the IOTP message 9275 that contains the Delivery Response Signature 9277 o the Transaction Reference Block (see section 3.3) of the IOTP Message 9278 that contains the Delivery Response Signature 9280 o the Consumer Delivery Data component contained in the Delivery Request 9281 Block (if any) 9283 o the Signature Components contained in the Delivery Request Block (if 9284 any) 9286 o the Status Component 9288 o the Delivery Note Component 9290 9.1.5 Payment and Delivery Document Exchange 9292 The Payment and Delivery Document Exchange is a combination of the last 9293 part of the Payment Trading Exchange (see section 2.2.2) and a Delivery 9294 Trading Exchange (see section 2.2.3). It consists of: 9296 o the Consumer requesting that a payment starts by generating Payment 9297 Request IOTP Message using information from previous IOTP Messages in 9298 the Transaction and then sending it to the Payment Handler 9300 o the Payment Handler and the Consumer then swapping Payment Exchange 9301 IOTP Messages encapsulating payment protocol messages until the payment 9302 is complete, and finally 9304 o the Payment Handler sending to the Consumer in one IOTP Message: 9305 - a Payment Response Block containing a receipt for the payment, and 9306 - a Delivery Response Block containing details of the goods or services 9307 to be delivered 9309 The IOTP Messages which are involved are illustrated by the diagram 9310 below. 9311 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9312 Consumer 9313 | Payment 9314 | Handler 9315 STEP | | 9316 1. Consumer generates Pay Request Block encapsulating a payment 9317 protocol message if required and sends to Payment Handler 9318 with the Signature Block if present 9320 C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature Block; 9321 Pay Request Block 9323 2. Payment Handler processes Pay Request Block, checks optional 9324 signature and starts exchanging payment protocol messages 9325 encapsulated in a Pay Exchange Block, with the Consumer 9327 C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange 9328 Block 9330 3. Consumer and Payment Handler keep on exchanging Payment 9331 Exchange blocks until eventually payment protocol messages 9332 finish so Payment Handler creates a Pay Receipt Component 9333 inside a Pay Response Block, and an optional Signature 9334 Component inside a Signature Block, then uses information 9335 from the Offer Response Bock to crteate a Delivery Response 9336 Block and sends both to the Consumer and stops. 9338 C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref 9339 Block; Signature Block; Pay Response Block; Delivery Response 9340 Block 9342 4. Consumer checks Payment Response and Delivery Response Blocks 9343 are OK. Optionally keeps information on IOTP Transaction for 9344 record keeping purposes and either stops or creates the next 9345 IOTP message for the Transaction and sends it together with 9346 the Signature Block, if present, to the required Trading Role 9348 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9350 Figure 23 Payment and Delivery Document Exchange 9352 The Delivery Response Block and the Payment Response Block may be 9353 combined into the same IOTP Message only if the Payment Handler has the 9354 information available so that she can send the Delivery Response Block. 9355 This is likely to, but will not necessarily, occur when the Merchant, the 9356 Payment Handler and the Delivery Handler Roles are combined. 9358 The DelivAndPayResp attribute of the Delivery Component (see section 9359 7.13) contained within the Offer Response Block (see section 8.3) is set 9360 to True if the Delivery Response Block and the Payment Response Block are 9361 combined into the same IOTP Message and is set to False if the Delivery 9362 Response Block and the Payment Response Block are sent in separate IOTP 9363 Messages. 9365 9.1.5.1 Message Processing Guidelines 9367 On receiving a Payment Request IOTP Message or a Payment Exchange IOTP 9368 Message, the Payment Handler should carry out the same actions as for a 9369 Payment Document Exchange (see section 9.1.3.1). 9371 On receiving a Payment Exchange IOTP Message, the Consumer should also 9372 carry out the same actions as for a Payment Document Exchange (see 9373 section 9.1.3.1). 9375 On receiving a Payment Response and Delivery Response IOTP Message then 9376 the IOTP Transaction is complete and should take no further action. 9378 If the Consumer receives an IOTP Message containing a Cancel block, then 9379 the information contained in the IOTP Message should be reported to the 9380 Consumer but no further action taken. 9382 If the Payment Handler receives an IOTP Message containing a Cancel 9383 block, then the Consumer is likely to go to the CancelNetLocn specified 9384 on the Trading Role Element in the Organisation Component for the Payment 9385 Handler from which any further action may take place. 9387 If the Merchant receives an IOTP Message containing a Cancel block, then 9388 the Consumer should have completed the payment but not continuing with 9389 the transaction for some reason. In this case the Consumer is likely to 9390 go to the CancelNetLocn specified on the Trading Role Element in the 9391 Organisation Component for the Merchant from which any further action may 9392 take place. 9394 9.1.5.2 Payment Request IOTP Message 9396 The content of this message is the same as for a Payment Request IOTP 9397 Message in a Payment Document Exchange (see section 9.1.3.2) 9399 9.1.5.3 Payment Exchange IOTP Message 9401 The content of this message is the same as for a Payment Exchange IOTP 9402 Message in a Payment Document Exchange (see section 9.1.3.3). 9404 9.1.5.4 Payment Response and Delivery Response IOTP Message 9406 The content of this message consists of: 9408 o a Payment Response Block, 9410 o an optional Signature Block (Payment Response), and 9411 o a Delivery Response Block. 9413 PAYMENT RESPONSE BLOCK 9415 The content of this block is the same as the Payment Response Block in 9416 the Payment Response IOTP Message associated with a Payment Document 9417 Exchange (see section 9.1.3.4). 9419 SIGNATURE BLOCK (PAYMENT RESPONSE) 9421 The content of this block is the same as the Signature Block (Payment 9422 Response) in the Payment Response IOTP Message associated with a Payment 9423 Document Exchange (see section 9.1.3.4). 9425 DELIVERY RESPONSE BLOCK 9427 The content of this block is the same as the Delivery Response Block in 9428 the Delivery Response IOTP Message associated with a Delivery Document 9429 Exchange (see section 9.1.4.3). 9431 9.1.6 Baseline Authentication IOTP Transaction 9433 A Baseline Authentication IOTP Transaction may occur at any time between 9434 any of the Trading Roles involved in IOTP Transactions. This means it 9435 could occur: 9437 o before another IOTP Transaction 9439 o at the same time as another IOTP Transaction 9441 o independently of any other IOTP Transaction. 9443 The Baseline Authentication IOTP Transaction consists of just an 9444 Authentication Document Exchange (see section 9.1.1) as illustrated by 9445 the diagram below. 9446 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9448 START ------------------------------------------------------- 9449 v 9450 ---------------- 9451 | AUTHENTICATION | 9452 ---------------- 9453 | 9454 | 9455 | 9456 | 9457 ------------------- ----------------- | 9458 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9459 | OFFER | | OFFER | | 9460 ------------------- ----------------- | 9461 | 9462 | 9463 | 9464 | 9465 | 9466 --------- -------------- | 9467 | PAYMENT | | PAYMENT WITH | | 9468 | (first) | | DELIVERY | | 9469 --------- -------------- | 9470 | 9471 | 9472 | 9473 ---------- --------- | 9474 | DELIVERY | | PAYMENT | | 9475 | | | {second)| | 9476 ---------- --------- | 9477 v 9478 STOP 9480 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9482 Figure 24 Baseline Authentication IOTP Transaction 9484 Example uses of the Baseline Authentication IOTP Transaction include: 9486 o when the Baseline Authentication IOTP Transaction takes place as an 9487 early part of a session where strong continuity exists. For example, a 9488 Financial Institution could: 9489 - set up a secure channel (e.g. using [SSL/TLS]) with a customer 9490 - authenticate the customer using the Baseline Authentication IOTP 9491 Transaction, and then 9492 - provide the customer with access to account information and other 9493 services with the confidence that they are communicating with a bona 9494 fide customer. 9496 o as a means of providing a Merchant role with Organisation Components 9497 that contain information about Consumer and DelivTo Trading Roles 9499 o so that a Consumer may authenticate a Payment Handler before starting a 9500 payment. 9502 9.1.7 Baseline Deposit IOTP Transaction 9504 The Baseline Deposit IOTP Transaction supports the deposit of electronic 9505 cash with a Financial Institution. 9507 [Note] The Financial Institution has, in IOTP terminology, a role of 9508 merchant in that a service (i.e. a deposit of electronic cash) 9509 is being offered in return for a fee, for example bank charges 9510 of some kind. The term "Financial Institution" is used in the 9511 diagrams and in the text for clarity. 9512 [Note End] 9514 The Baseline Deposit IOTP Transaction consists of the following Document 9515 Exchanges: 9517 o an optional Authentication Document Exchange (see section 9.1.1) 9519 o an Offer Document Exchange (see section 9.1.2), and 9521 o a Payment Document Exchange (see section 9.1.3). 9523 The way in which these Document Exchanges may be combined together is 9524 illustrated by the diagram below. 9525 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9527 START ----------------------------------------------------- 9528 | v 9529 | ---------------- 9530 | | AUTHENTICATION | 9531 | ---------------- 9532 -------------------------------------- | 9533 | | | 9534 | -------------- | ------------- 9535 v v v v 9536 ------------------- ----------------- 9537 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9538 | OFFER | | OFFER | 9539 ------------------- ----------------- 9540 | | 9541 | | 9542 | | 9543 | ------------------- 9544 v v 9545 --------- -------------- 9546 | PAYMENT | | PAYMENT WITH | 9547 | (first) | | DELIVERY | 9548 --------- -------------- 9549 | 9550 ---------------- 9551 | 9552 ---------- --------- | 9553 | DELIVERY | | PAYMENT | | 9554 | | | {second)| | 9555 ---------- --------- | 9556 | 9557 -----------------> STOP 9559 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9561 Figure 25 Baseline Deposit IOTP Transaction 9563 See section 9.1.12 "Valid Combinations of Document Exchanges" to 9564 determine which combination of document exchanges apply to a particular 9565 instance of an IOTP Transaction 9567 Note that: 9569 o a Merchant (Financial Institution) may be able to accept a deposit in 9570 several different types of electronic cash although, since the Consumer 9571 role that is depositing the electronic cash usually knows what type of 9572 cash they want to deposit, it is usually constrained in practice to 9573 only one type. However, there may be several different protocols which 9574 may be used for the same "brand" of electronic cash. In this case a 9575 Brand Dependent Offer may be appropriate to negotiate the protocol to 9576 be used. 9578 o the Merchant (Financial Institution) may use the results of the 9579 authentication to identify not only the consumer but also the account 9580 to which the payment is to be deposited. If no single account can be 9581 identified, then it must be obtained by other means. For example: 9582 - the consumer could specify the account number prior to the Baseline 9583 Deposit IOTP Transaction starting, or 9584 - the consumer could have been identified earlier, for example using a 9585 Baseline Authentication IOTP Transaction, and an account selected 9586 from a list provided by the Financial Institution. 9588 o The Baseline Deposit IOTP Transaction without an Authentication 9589 Document Exchange might be used: 9590 - if a previous IOTP transaction, for example a Baseline Withdrawal or 9591 a Baseline Authentication, authenticated the consumer, and a secure 9592 channel has been maintained, therefore the authenticity of the 9593 consumer is known 9594 - if authentication is achieved as part of a proprietary payment 9595 protocol and is therefore included in the Payment Document Exchange 9596 - if authentication of the consumer has been achieved by some other 9597 means outside of the scope of IOTP, for example, by using a pass 9598 phrase, or a proprietary banking software solution. 9600 9.1.8 Baseline Purchase IOTP Transaction 9602 The Baseline Purchase IOTP Transaction supports the purchase of goods or 9603 services using any payment method. It consists of the following Document 9604 Exchanges: 9606 o an optional Authentication Document Exchange (see section 9.1.1) 9608 o an Offer Document Exchange (see section 9.1.2) 9610 o either: 9611 - a Payment Document Exchange (see section 9.1.3) followed by 9612 - a Delivery Document Exchange (see section 9.1.4) 9614 o a Payment Document Exchange only, or 9616 o a combined Payment and Delivery Document Exchange (see section 9.1.5). 9618 The ways in which these Document Exchanges are combined is illustrated by 9619 the diagram below. 9620 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9621 START ----------------------------------------------------- 9622 | v 9623 | ---------------- 9624 | | AUTHENTICATION | 9625 | ---------------- 9626 -------------------------------------- | | 9627 | | | | 9628 | -------------- | ------------- | 9629 v v v v | 9630 ------------------- ----------------- | 9631 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9632 | OFFER | | OFFER | | 9633 ------------------- ----------------- | 9634 | | | | | 9635 | --------------- | | | 9636 | | | | | 9637 | -------------- | -- | | 9638 v v v v | 9639 --------- -------------- | 9640 | PAYMENT | | PAYMENT WITH | | 9641 | (first) | | DELIVERY | | 9642 --------- -------------- | 9643 | | | 9644 ----------------------------- | | 9645 v | | | 9646 ---------- --------- | | | 9647 | DELIVERY | | PAYMENT | | | | 9648 | | | {second)| | | | 9649 ---------- --------- | | | 9650 | | | v 9651 ----------------------------------------------> STOP 9653 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9655 Figure 26 Baseline Purchase IOTP Transaction 9657 See section 9.1.12 Valid Combinations of Document Exchanges to determine 9658 which combination of document exchanges apply to a particular instance of 9659 an IOTP Transaction 9661 9.1.9 Baseline Refund IOTP Transaction 9663 In business terms the refund process typically consists of: 9665 o a request for a refund being made by the Consumer to the Merchant, 9666 typically supported by evidence to demonstrate: 9667 - the original trade took place, for example by providing a receipt for 9668 the original transaction 9669 - using some type of authentication, that the consumer requesting the 9670 refund is the consumer, or a representative of the consumer, who 9671 carried out the original trade 9672 - the reason why the merchant should make the refund 9674 o the merchant agreeing (or not) to the refund. This may involve some 9675 negotiation between the Consumer and the Merchant, and, if the merchant 9676 agrees, 9678 o a refund payment by the Merchant to the Consumer. 9680 The Baseline Refund IOTP Transaction supports a subset of the above, 9681 specifically it supports: 9683 o stand alone authentication of the Consumer using a separate Baseline 9684 Authentication IOTP Transaction (see section 9.1.6) 9686 o a refund payment by the Merchant to the Consumer using the following 9687 two Trading Exchanges: 9688 - an optional Authentication Document Exchange (see section 9.1.1) 9689 - an Offer Document Exchange (see section 9.1.2), and 9690 - a Payment Document Exchange (see section 9.1.3). 9692 The ways in which these Document Exchanges are combined is illustrated by 9693 the diagram below. 9694 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9696 START ----------------------------------------------------- 9697 | v 9698 | ---------------- 9699 | | AUTHENTICATION | 9700 | ---------------- 9701 -------------------------------------- | 9702 | | | 9703 | -------------- | ------------- 9704 v v v v 9705 ------------------- ----------------- 9706 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9707 | OFFER | | OFFER | 9708 ------------------- ----------------- 9709 | | 9710 | | 9711 | | 9712 | ------------------- 9713 v v 9714 --------- -------------- 9715 | PAYMENT | | PAYMENT WITH | 9716 | (first) | | DELIVERY | 9717 --------- -------------- 9718 | 9719 ---------------- 9720 | 9721 ---------- --------- | 9722 | DELIVERY | | PAYMENT | | 9723 | | | {second)| | 9724 ---------- --------- | 9725 | 9726 -----------------> STOP 9728 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9730 Figure 27 Baseline Refund IOTP Transaction 9732 A Baseline Refund IOTP Transaction without an Authentication Document 9733 Exchange might be used: 9735 o when authentication of the consumer has been achieved by some other 9736 means, for example, the consumer has entered some previously supplied 9737 code in order to identify herself and the refund to which the code 9738 applies. The code could be supplied, for example on a web page or by e- 9739 mail. 9741 o when a previous IOTP transaction, for example a Baseline 9742 Authentication, authenticated the consumer, and a secure channel has 9743 been maintained, therefore the authenticity of the consumer is known 9744 and therefore the previously agreed refund can be identified. 9746 o when the authentication of the consumer is carried out by the Payment 9747 Handler using a payment scheme authentication algorithm. 9749 9.1.10 Baseline Withdrawal IOTP Transaction 9751 The Baseline Withdrawal IOTP Transaction supports the withdrawal of 9752 electronic cash from a Financial Institution. 9754 [Note] The Financial Institution has, in IOTP terminology, a role of 9755 merchant in that a service (i.e. a withdrawal of electronic 9756 cash) is being offered in return for a fee, for example bank 9757 charges of some kind. The term "Financial Institution" is used 9758 in the diagrams and in the text for clarity. 9759 [Note End] 9761 The Baseline Withdrawal IOTP Transaction consists of the following 9762 Document Exchanges: 9764 o an optional Authentication Document Exchange (see section 9.1.1) 9766 o an Offer Document Exchange (see section 9.1.2), and 9768 o a Payment Document Exchange (see section 9.1.3). 9770 The way in which these Document Exchanges may be combined together is 9771 illustrated by the diagram below. 9772 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9774 START ----------------------------------------------------- 9775 | v 9776 | ---------------- 9777 | | AUTHENTICATION | 9778 | ---------------- 9779 -------------------------------------- | 9780 | | | 9781 | -------------- | ------------- 9782 v v v v 9783 ------------------- ----------------- 9784 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9785 | OFFER | | OFFER | 9786 ------------------- ----------------- 9787 | | 9788 | | 9789 | | 9790 | ------------------- 9791 v v 9792 --------- -------------- 9793 | PAYMENT | | PAYMENT WITH | 9794 | (first) | | DELIVERY | 9795 --------- -------------- 9796 | 9797 ---------------- 9798 | 9799 ---------- --------- | 9800 | DELIVERY | | PAYMENT | | 9801 | | | {second)| | 9802 ---------- --------- | 9803 | 9804 -----------------> STOP 9806 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9808 Figure 28 Baseline Withdrawal IOTP Transaction 9810 Note that: 9812 o a Merchant (Financial Institution) may be able to offer withdrawal of 9813 several different types of electronic cash. In practice usually only 9814 one form of electronic cash may be offered. However, there may be 9815 several different protocols which may be used for the same "brand" of 9816 electronic cash 9818 o the Merchant (Financial Institution) may use the results of the 9819 authentication to identify not only the consumer but also the account 9820 from which the withdrawal is to be made. If no single account can be 9821 identified, then it must be obtained by other means. For example: 9822 - the consumer could specify the account number prior to the Baseline 9823 Withdrawal IOTP Transaction starting, or 9824 - the consumer could have been identified earlier, for example using a 9825 Baseline Authentication IOTP Transaction, and an account selected 9826 from a list provided by the Financial Institution. 9828 o a Baseline Withdrawal without an authentication might be used: 9829 - if a previous IOTP transaction, for example a Baseline Deposit or a 9830 Baseline Authentication, authenticated the consumer, and a secure 9831 channel has been maintained, therefore the authenticity of the 9832 consumer is known 9834 - if authentication is achieved as part of a proprietary payment 9835 protocol and is therefore included in the Payment Document Exchange 9836 - if authentication of the consumer has been achieved by some other 9837 means, for example, by using a pass phrase, or a proprietary banking 9838 software solution. 9840 9.1.11 Baseline Value Exchange IOTP Transaction 9842 The Baseline Value Exchange Transaction uses Payment Document Exchanges 9843 to support the exchange of value in one currency obtained using one 9844 payment method with value in the same or another currency using the same 9845 or another payment method. Examples of its use include: 9847 o electronic cash advance on a credit card. For example the first payment 9848 could be a "dollar SET Payment" using a credit card with the second 9849 payment being a download of Visa Cash e-cash in dollars. 9851 o foreign exchange using the same payment method. For example the payment 9852 could be an upload of Mondex value in British Pounds and the second a 9853 download of Mondex value in Euros 9855 o foreign exchange using different payment methods. For example the first 9856 payment could be a SET payment in Canadian Dollars followed a download 9857 of GeldKarte in Deutchmarks. 9859 The Baseline Value Exchange uses the following Document Exchanges: 9861 o an optional Authentication Document Exchange (see section 9.1.1) 9863 o an Offer Document Exchange (see section 9.1.2), which provides details 9864 of what values and currencies will be exchanged, and 9866 o two Payment Document Exchanges (see section 9.1.3) which carry out the 9867 two payments involved. 9869 The way in which these Document Exchanges may be combined together is 9870 illustrated by the diagram below. 9871 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9873 START ----------------------------------------------------- 9874 | v 9875 | ---------------- 9876 | | AUTHENTICATION | 9877 | ---------------- 9878 -------------------------------------- | 9879 | | | 9880 | -------------- | ------------- 9881 v v v v 9882 ------------------- ----------------- 9883 | BRAND INDEPENDENT | | BRAND DEPENDENT | 9884 | OFFER | | OFFER | 9885 ------------------- ----------------- 9886 | | 9887 | | 9888 | | 9889 | ------------------- 9890 v v 9891 --------- -------------- 9892 | PAYMENT | | PAYMENT WITH | 9893 | (first) | | DELIVERY | 9894 --------- -------------- 9895 | 9896 ---- 9897 v 9898 ---------- --------- 9899 | DELIVERY | | PAYMENT | 9900 | | | {second)| 9901 ---------- --------- 9902 | 9903 -----------------------------> STOP 9905 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9907 Figure 29 Baseline Value Exchange IOTP Transaction 9909 The Baseline Value Exchange IOTP Transaction occurs in two basic forms: 9911 o Brand Dependent Value Exchange. Where the content of the offer, for 9912 example the rate at which one form of value is exchanged for another, 9913 is dependent on the payment brands and protocols selected by the 9914 consumer, and 9916 o Brand Independent Value Exchange. Where the content of the offer is not 9917 dependent on the payment brands and protocols selected. 9919 [Note] In the above the role is a Merchant even though the 9920 Organisation carrying out the Value Exchange may be a Bank or 9921 some other Financial Institution. This is because the Bank is 9922 acting as a merchant in that they are making an offer which 9923 the Consumer can either accept or decline. 9924 [Note End] 9926 The TPO Block and Offer Response Block may only be combined into the same 9927 IOTP Message if the content of the Offer Response Block does not change 9928 as a result of selecting the payment brands and payment protocols to be 9929 used in the Value Exchange. 9931 BASELINE VALUE EXCHANGE SIGNATURES 9933 The use of signatures to ensure the integrity of a Baseline Value 9934 Exchange is illustrated by the diagram below. 9936 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9938 Signature generated IotpMsg (TPO) 9939 by Merchant ensures - Trans Ref Block 9940 integrity of the Offer --------> - - Signature Block 9941 | - TPO Block MERCHANT 9942 | - Offer Response Block 9943 | 9944 Signature generated by | 9945 the Payment Handler of | IotpMsg (Pay Resp 1) 9946 the first payment binds | - Trans Ref Block PAYMENT 9947 Pay Receipt for the first -----> -> - Signature Block ----- HANDLER 9948 payment to the Offer - Pay Response Block 1 | 1 9949 | 9950 Signature generated by | 9951 the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT 9952 the second payment binds - Trans Ref Block | HANDLER 9953 the second payment to the -----> - Signature Block <------ 2 9954 first payment and therefore - Pay Response Block 2 9955 to the Offer 9957 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 9959 Figure 30 Baseline Value Exchange Signatures 9961 9.1.12 Valid Combinations of Document Exchanges 9963 The following diagram illustrates the data conditions in the various IOTP 9964 messages which can be used by a Consumer Trading Role to determine 9965 whether the combination of Document Exchanges are valid. 9966 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 9968 START 9969 | 9970 v 9971 Auth Request Block in =TRUE 9972 first IOTP Message ? --------------------------------------- 9973 | = FALSE | 9974 v v 9975 Offer Response Block in ---------------- 9976 first IOTP Message ? | AUTHENTICATION | 9977 |=TRUE |=FALSE ---------------- 9978 | | | 9979 | | v 9980 | ---------------------- TPO & Offer Response 9981 ------------- | Blocks in last IOTP Msg 9982 | | |=TRUE |=FALSE 9983 | | | v 9984 | ------------- | ---- TPO Block only if 9985 | | | last IOTP Message 9986 | | | of Authentication 9987 | | | |=TRUE |=FALSE 9988 v v v v | 9989 ------------------- ----------------- | 9990 | BRAND INDEPENDENT | | BRAND DEPENDENT | | 9991 | OFFER | | OFFER | | 9992 ------------------- ----------------- | 9993 | | | 9994 v v | 9995 Offer Response Block contains | 9996 Delivery Component ? | 9997 |=FALSE |=TRUE | 9998 --- v | 9999 | Value of DelivAndPayResp | 10000 | attribute of Delivery Component ? | 10001 | |=FALSE |=TRUE | 10002 | | | | 10003 v v v | 10004 --------- -------------- | 10005 | PAYMENT | | PAYMENT WITH | | 10006 | (first) | | DELIVERY | | 10007 --------- -------------- | 10008 | | | 10009 v | | 10010 Offer and Response Block contains -------------->| 10011 Delivery Component ? | 10012 |=TRUE |=FALSE | 10013 | v | 10014 | Two Payment Components | 10015 | present in Offer Response Block? | 10016 | |=TRUE |=FALSE | 10017 v v | | 10018 ---------- --------- | | 10019 | DELIVERY | | PAYMENT | | | 10020 | | | {second)| | | 10021 ---------- --------- | | 10022 | | | v 10023 ----------------------------------------------> STOP 10025 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10027 Figure 31 Valid Combinations of Document Exchanges 10029 1) If first IOTP Message of an IOTP Transaction contains an Authentication 10030 Request then: 10032 a) IOTP Transaction includes an Authentication Document Exchange (see 10033 section 9.1.1). (Note 1) 10035 b) If the last IOTP Message of the Authentication Document Exchange 10036 includes a TPO Block and an Offer Response Block then: 10038 i) IOTP Transaction includes a Brand Independent Offer Document 10039 Exchange (see section 9.1.2.2). (Note 2) 10041 c) Otherwise, if the last IOTP Message of the Authentication Exchange 10042 includes a TPO Block but NO Offer Response Block, then: 10044 i) IOTP Transaction includes a Brand Dependent Offer Document Exchange 10045 (see section 9.1.2.1). (Note 2) 10047 d) Otherwise (Authentication Status IOTP Message of the Authentication 10048 Document Exchange contains neither a TPO Block but nor an Offer 10049 Response Block) 10051 i) IOTP Transaction consists of just an Authentication Document 10052 Exchange. (Note 3) 10054 2) Otherwise (no Authentication Request in first IOTP Message): 10056 e) IOTP Transaction does not include an Authentication Document Exchange 10057 (Note 2) 10059 f) If first IOTP Message contains an Offer Response Block, then: 10061 i) the IOTP Transaction contains a Brand Independent Offer Document 10062 Exchange (Note 2) 10064 g) Otherwise (no Offer Response Block in first IOTP Message): 10066 i) the IOTP Transaction includes a Brand Dependent Offer Document 10067 Exchange (Note 2) 10069 3) If an Offer Response Block exists in any IOTP message then: 10071 h) If the Offer Response Block contains a Delivery Component then: 10073 i) If the DelivAndPayResp attribute of the Delivery Component is set 10074 to True, then: 10076 (1) the IOTP Transaction consists of a Payment And Delivery 10077 Document Exchange (see section 9.1.5) (Note 4) 10079 ii) otherwise (the DelivAndPayResp attribute of the Delivery 10080 Component is set to False) 10082 (1) the IOTP Transaction consists of a Payment Document Exchange 10083 (see section 9.1.3) followed by a Delivery Document Exchange 10084 (see section 9.1.4) (Note 4) 10086 i) otherwise (the Offer Response Block does not contain a Delivery 10087 Component) 10089 i) if the Offer Response Block contains just one Payment Component, 10090 then: 10092 (1) the IOTP Transaction contains just one Payment Document 10093 Exchange (Note 5) 10095 ii) if the Offer Response Block contains two Payment Components, 10096 then: 10098 1) the IOTP Transaction contains two Payment Document Exchanges. 10099 The StartAfter attribute of the Payment Components is used to 10100 indicate which payment occurs first (Note 6) 10102 iii) if the Offer Response Block contains no or more than two 10103 Payment Components, then there is an error 10105 4) Otherwise (no Offer Response Block) there is an error. 10107 The following table indicates the types of IOTP Transactions which can 10108 validly have the conditions indicated above. 10110 Note IOTP Transaction Validity 10112 1. Any Payment and Authentication IOTP Transaction 10114 2. Any Payment and Authentication IOTP Transaction except Baseline 10115 Authentication 10117 3. Either Baseline Authentication, or a Baseline Purchase, Refund, 10118 Deposit, Withdrawal or Value Exchange with a failed 10119 Authentication 10121 4. Baseline Purchase only 10123 5. Baseline Purchase, Refund, Deposit or Withdrawal 10125 6. Baseline Value Exchange only 10127 9.1.13 Combining Authentication Transactions with other Transactions 10129 In the previous sections an Authentication Document Exchange is shown 10130 preceding an Offer Document Exchange as part of a single IOTP Transaction 10131 with the same IOTP Transaction Id. 10133 It is also possible to run a separate Authentication Transaction at any 10134 point, even in parallel with another IOTP Transaction. Typically this 10135 will be used: 10137 o by a Consumer to authenticate a Merchant, Payment Handler or a Delivery 10138 Handler, or 10140 o by a Payment Handler or Delivery Handler to authenticate a Consumer. 10142 In outline the basic process consists of: 10144 o the Trading Role that decides it wants to carry out an authentication 10145 of another role suspends the current IOTP transaction being carried out 10147 o a stand-alone Authentication transaction is then carried out. This may, 10148 at implementer's option, be linked to the original IOTP Transaction 10149 using a Related To Component (see section 3.3.3) in the Transaction 10150 Reference Block. 10152 o if the Authentication transaction is successful, then the original IOTP 10153 Transaction is restarted 10155 o if the Authentication fails then the original IOTP Transaction is 10156 cancelled. 10158 For example, a Consumer could: 10160 o authenticate the Payment Handler for a Payment between receiving an 10161 Offer Response from a Merchant and before sending the Payment Request 10162 to that Payment Handler 10164 o authenticate a Delivery Handler for a Delivery between receiving the 10165 Payment Response from a Payment Handler and before sending the Delivery 10166 Request 10168 A Payment Handler could authenticate a Consumer after receiving the 10169 Payment Request and before sending the next Payment related message. 10171 A Delivery Handler could authenticate a Consumer after receiving the 10172 Delivery Request and before sending the Delivery Response. 10174 [Note] Some Payment Methods may carry out an authentication within 10175 the Payment Exchange. In this case the information required to 10176 carry out the authentication will be included in Payment 10177 Scheme Components. 10179 In this instance IOTP aware application will not be aware that 10180 an authentication has occurred since the Payment Scheme 10181 Components that contain authentication request information 10182 will be indistinguishable from other Payment Scheme 10183 Components. 10184 [Note End] 10186 9.2 Infrastructure Transactions 10188 Infrastructure Transactions are designed to support inquiries about 10189 whether or not a transaction has succeeded or a Trading Role's servers 10190 are operating correctly. There are two types of transaction: 10192 o a Transaction Status Inquiry Transaction which provides information on 10193 the status of an existing or complete IOTP transaction, and 10195 o Ping Transaction that enables one IOTP aware application to determine 10196 if the IOTP aware application at another Trading Role is operating and 10197 verify whether or not signatures can be handled. 10199 Each of these is described below 10201 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 10203 The Baseline IOTP Transaction Status Inquiry provides information on the 10204 status of an existing or complete IOTP transaction. 10206 The Trading Blocks used by the Baseline Transaction Status Inquiry 10207 Transaction are: 10209 o an Inquiry Request Trading Block (see section 8.12), 10211 o an Inquiry Response Trading Block (see section 8.13) 10213 o an optional Signature Block (see section 8.16). 10215 The Inquiry IOTP Transaction can be used for a variety of reasons. For 10216 example: 10218 o to help in resuming a suspended transaction to determine the current 10219 state of processing of one of the other roles, 10221 o for a merchant to determine if a payment, delivery, etc. was completed. 10222 For example, a Consumer might claim that payment was made but no signed 10223 IOTP payment receipt was available to prove it. If the Merchant makes 10224 an inquiry of the Payment Handler then the Merchant can determine 10225 whether or not payment was made. 10227 [Note] Inquiries on Baseline Ping IOTP Transactions (see section 10228 9.2.2) are ignored. 10229 [Note End] 10231 MAKING INQUIRIES OF ANOTHER TRADING ROLE 10233 One Trading Role may make an inquiry of any other Trading Role at any 10234 point in time. 10236 IOTP aware software that supports the Consumer Trading Role may not: 10238 o digitally sign a response if requested, since it may not have the 10239 capability, or 10241 o respond to an Inquiry Request at all since it may not be on-line, or 10242 may consider that the request is not reasonable since, for example, the 10243 Request was not digitally signed. 10245 As a guideline: 10247 o the Consumer should send a Transaction Status Inquiry Block to a 10248 Trading Role only after the following events have occurred: 10249 - to the Merchant, after sending a TPO Selection Block, 10250 - to the Payment Handler, after sending a Payment Request Block, 10251 - to the Delivery Handler, after sending a Delivery Request Block, 10253 o other Trading Roles should send a Transaction Status Inquiry Block to 10254 the Consumer only after receiving a message from the Consumer and 10255 before sending the final "Response" message to the Consumer 10257 o there are no restrictions on non-Consumer Trading Roles sending 10258 Inquiries to other trading roles. 10260 TRANSACTION STATUS INQUIRY TRANSPORT SESSION 10262 For a Transaction Status Inquiry on an ongoing transaction a different 10263 transport session from the ongoing transaction is used. For a Transaction 10264 Status Inquiry on a past transaction, how the IOTP module on the software 10265 at the Trading Role is started upon the receipt of Inquiry Request 10266 message is defined in each Mapping to Transport supplement for IOTP. 10268 TRANSACTION STATUS INQUIRY ERROR HANDLING 10270 Errors in a Transaction Status Inquiry can be categorised into one of the 10271 following three cases: 10273 o Business errors (see section 4.2) in the original (inquired) messages 10275 o Technical errors (see section 4.1) - both IOTP and payment scheme 10276 specific ones - in the original IOTP (inquired) messages 10278 o Technical errors in the message containing the Inquiry Request Block 10279 itself 10281 The following outlines what the software should do in each case 10283 BUSINESS ERRORS IN THE ORIGINAL MESSAGES 10285 Return an Inquiry Response Block containing the Status Component which 10286 was last sent to the Consumer Role. 10288 TECHNICAL ERRORS IN THE ORIGINAL MESSAGES 10290 Return an Inquiry Response Block containing a Status Component. The 10291 Status Component should contain a ProcessState attribute set to 10292 ProcessError. In this case send back an Error Block indicating where the 10293 error was found in the original message. 10295 TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK 10297 Return an Error message. That is, send back an Error Block containing the 10298 Error Code (see section 7.21.2) which describes the nature of the error 10299 in the Inquiry Request message. 10301 INQUIRY TRANSACTION MESSAGES 10303 The following Figure outlines the Baseline IOTP Transaction Status 10304 Inquiry process. 10306 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10307 1st Role 10308 | 2nd Role 10309 STEP | | 10310 1. The first role decides to inquire on an IOTP Transaction by, 10311 for example, clicking on the inquiry button of an IOTP Aware 10312 Application. This will then generate an Inquiry Request Block 10313 and send it to the appropriate Trading Role. 10315 1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block 10316 (optional); Inquiry Request Block 10318 2. The Trading Role checks the digital signature (if present). 10319 If the recipient wants to respond, then the Trading Role 10320 checks the transaction status of the transaction that is 10321 being inquired upon by using the IotpTransId in the 10322 Transaction ID Component of the Transaction Reference Block, 10323 then generates the appropriate Inquiry Response Block, sends 10324 the message back to the 1st Role and stops 10326 1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry Response 10327 Block; Signature Block (Optional) 10329 3. First role checks the Inquiry Response Block and optional 10330 signature, takes whatever action is appropriate or perhaps 10331 stops. This may include displaying status information to the 10332 end user. 10334 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10336 Figure 32 Baseline Transaction Status Inquiry 10338 The remainder of this sub-section on the Baseline Transaction Status 10339 Inquiry IOTP Transaction defines the contents of each Trading Block. Note 10340 that the term "original transaction" is the transaction which a trading 10341 role wants to discover some information about. 10343 TRANSACTION REFERENCE BLOCK 10345 A Trading Role making an inquiry must use a Transaction Id Component (see 10346 section 3.3.1) where both the IotpTransId and TransTimeStamp attributes 10347 are the same as in the Transaction Id Component of the original 10348 transaction that is being inquired upon. The IotpTransId attribute in 10349 this component serves as the key in querying the transaction logs 10350 maintained at the Trading Role's site. The value of the ID attribute of 10351 the Message Id Component should be different from those of any in the 10352 original transaction (see section 3.4.1). 10354 If up-to-date status information is required then the MsgId Component, 10355 and in particular the ID attribute for the MsgId Component must be 10356 different from any other IOTP Message that has been sent by the Trading 10357 Role. This is required because of the way that Idempotency is handled by 10358 IOTP (see section 4.5.2.2 Checking/Handling Duplicate Messages). 10360 INQUIRY REQUEST BLOCK 10362 The Inquiry Request Block (see section 8.12) contains the following 10363 components: 10365 o one Inquiry Type Component (see section 7.18). This identifies whether 10366 the inquiry is on an offer, payment, or delivery. 10368 o zero or one Payment Scheme Components (see section 7.10). This is for 10369 encapsulating payment scheme specific inquiry messages for inquiries on 10370 a payment. 10372 SIGNATURE BLOCK (INQUIRY REQUEST) 10374 If a signature block is present on the message containing the Inquiry 10375 Request Block then it may be checked to determine if the Inquiry Request 10376 is authorised. 10378 If present, the Inquiry Request Signature Block (see section 8.12) 10379 contains the following components: 10381 o one Signature Component (see section 7.19) 10383 o one or more Certificate Components, if required. 10385 Inquiry Response Blocks should only be generated if the Transaction is 10386 authorised. 10388 [Note] Digital signatures on an Inquiry Request is only likely to 10389 occur if the recipient of the request expects the Inquiry 10390 Request to be signed. In this version of IOTP this will 10391 require some kind of pre-existing agreement. This means that: 10392 o Consumers are unlikely to generate requests with signatures, 10393 although it is not an error if they do 10394 o the other trading roles may agree that digital signatures 10395 are required. For example a Payment Handler may require that 10396 an Inquiry Request is digitally signed by the Merchant so 10397 that they can check that the request is valid. 10399 On the other hand if the original transaction to which the 10400 Inquiry relates was carried out over a secure channel (e.g. 10401 [SSL]) then it is probably reasonable to presume that if the 10402 sender of the Inquiry knows the Transaction Id component of 10403 the original message (including for example the timestamp) 10404 then the inquiry is likely to be genuine. 10405 [Note End] 10407 INQUIRY RESPONSE BLOCK 10409 The Inquiry Response Block (see section 8.13) contains the following 10410 components: 10412 o one Status Component (see section 7.16). This component holds the 10413 status information on the inquired transaction, 10415 o zero or one Payment Scheme Components. These contain encapsulated 10416 payment scheme specific inquiry messages for inquiries on payment. 10418 SIGNATURE BLOCK (INQUIRY RESPONSE) 10420 If a signature block is present on the message containing the Inquiry 10421 Response Block then it may be checked by the receiver of the block to 10422 determine if the Inquiry Response is valid. 10424 If present, the Inquiry Response Signature Block (see section 8.13) 10425 contains the following components: 10427 o one Signature Component (see section 7.19) 10429 o one or more Certificate Components, if required. 10431 [Note] Digital signatures on an Inquiry Response is only likely to 10432 occur if the recipient of the response expects the Inquiry 10433 Request to be signed. In this version of IOTP this will 10434 require some kind of pre-existing agreement. This means that: 10435 o Consumers are unlikely to generate responses with 10436 signatures, although it is not an error if they do 10437 o the other trading roles may agree that digital signatures 10438 are required. For example a Merchant may require that an 10439 Inquiry Response is digitally signed by the Payment Handler 10440 so that they can check that the request response is valid. 10441 [Note End] 10443 9.2.2 Baseline Ping IOTP Transaction 10445 The purpose of the Baseline IOTP Ping Transaction is to test basic 10446 connectivity between the Trading Roles that may take part in an IOTP 10447 Transaction. 10449 It enables IOTP aware application software to: 10451 o determine if the IOTP aware application at another Trading Role is 10452 operating, and 10454 o verify whether or not the two trading roles signatures can be 10455 processed. 10457 For example it can be used by a Merchant to determine if a Payment 10458 Handler or Delivery Handler is up and running prior to starting a 10459 Purchase transaction that uses those trading roles. 10461 The Trading Blocks used by the Baseline Ping IOTP Transaction are: 10463 o a Ping Request Block (see section 8.14) 10465 o a Ping Response Block (see section 8.15), and 10467 o a Signature Block (see section 8.16). 10469 PING MESSAGES 10471 The following figure outlines the message flows in the Baseline IOTP Ping 10472 Transaction. 10474 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 10475 1st Role 10476 | 2nd Role 10477 STEP | | 10478 1. The IOTP Aware Application in the first Trading Role decides 10479 to check whether the counterparty IOTP application is up and 10480 running. It generates a Ping Request Block and optional 10481 Signature Block and sends them to the second trading role. 10483 1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block 10484 (Optional); Ping Request Block 10486 2. The second Trading Role which receives the Ping Request Block 10487 generates a Ping Response Block and sends it back to the 10488 sender of the original Ping Request with a signature block if 10489 required. 10491 1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block 10492 (Optional); Ping Response Block 10494 3. The first Trading Role checks the Ping Response Block and 10495 takes appropriate action, if necessary 10497 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 10499 Figure 33 Baseline Ping Messages 10501 The verification that signatures can be handled is indicated by the 10502 sender of the Ping Request Block including: 10504 o Organisation Components that identify itself and the intended recipient 10505 of the Ping Request Block, and 10507 o a Signature Block that signs data in the Ping Request. 10509 In this way the receiver of the Ping Request: 10511 o knows who is sending the Ping Request and can therefore verify the 10512 Signature on the Request, and 10514 o knows who to generate a signature for on the Ping Response. 10516 Note that a Ping Request: 10518 o does not affect any on-going transaction 10520 o does NOT initiate an IOTP transaction, unlike other IOTP transaction 10521 messages such as TPO or Transaction Status Inquiry. 10523 All IOTP aware applications must return a Ping Response message to the 10524 sender of a Ping Request message when it is received. 10526 A Baseline IOTP Ping request can also contain an optional Signature 10527 Block. IOTP aware applications can, for example, use the Signature Block 10528 to check the recipient of a Ping Request can successfully process and 10529 check signatures it has received. 10531 For each Baseline Ping IOTP Transaction, each IOTP role shall establish a 10532 different transport session from other IOTP transactions. 10534 Any IOTP Trading Role can send a Ping request to any other IOTP Trading 10535 Role at any time it wants. A Ping message has its own IotpTransId, which 10536 is different from other IOTP transactions. 10538 The remainder of this sub-section on the Baseline Ping IOTP Transaction 10539 defines the contents of each Trading Block. 10541 TRANSACTION REFERENCE BLOCK 10543 The IotpTransId of a Ping transaction should be different from any other 10544 IOTP transaction. 10546 PING REQUEST BLOCK 10548 If the Ping Transaction is anonymous then no Organisation Components are 10549 included in the Ping Request Block (see section 8.7). 10551 If the Ping Transaction is not anonymous then the Ping Request Block 10552 contains Organisation Components for: 10554 o the sender of the Ping Request Block, and 10556 o the verifier of the Signature Component 10558 If Organisation Components are present, then it indicates that the sender 10559 of the Ping Request message has generated a Signature Block. The 10560 signature block must be verified by the Trading Role that receives the 10561 Ping Request Block. 10563 SIGNATURE BLOCK (PING REQUEST) 10565 The Ping Request Signature Block (see section 8.16) contains the 10566 following components: 10568 o one Signature Component (see section 7.19) 10570 o one or more Certificate Components, if required. 10572 PING RESPONSE BLOCK 10574 The Ping Response Block (see section 8.15) contains the following 10575 component: 10577 o the Organisation Component of the sender of the Ping Response message 10579 If the Ping Transaction is not anonymous then the Ping Response 10580 additionally contains: 10582 o copies of the Organisation Components contained in the Ping Request 10583 Block. 10585 SIGNATURE BLOCK (PING RESPONSE) 10587 The Ping Response Signature Block (see section 8.16) contains the 10588 following components: 10590 o one Signature Component (see section 7.19) 10592 o one or more Certificate Components, if required. 10594 10. Retrieving Logos 10596 This section describes how to retrieve logos for display by IOTP aware 10597 software using the Logo Net Locations attribute contained in the Brand 10598 Element (see section 7.7.1) and the Organisation Component (see section 10599 7.6). 10601 The full address of a logo is defined as follows: 10602 Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif" 10604 Where: 10606 o Logo_net_location is obtained from the LogoNetLocn attribute in the 10607 Brand Element (see section 7.7.1) or the Organisation Component. Note 10608 that: 10609 - the content of this attribute is dependent on the Transport Mechanism 10610 (such as HTTP) that is used. See the Transport Mechanism supplement, 10611 - implementers should check that if the rightmost character of Logo Net 10612 Location is set to right-slash "/" then another, right slash should 10613 not be included when generating the Logo Address, 10615 o Logo_size identifies the size of the logo, 10617 o Logo_color_depth identifies the colour depth of the logo 10619 o "gif" indicates that the logos are in "gif@ format 10621 Logo_size and Logo_color_depth are specified by the implementer of the 10622 IOTP software that is retrieving the logo depending on the size and 10623 colour that they want to use. 10625 10.1 Logo Size 10627 There are five standard sizes for logos. The sizes in pixels and the 10628 corresponding values for Logo Size are given in the table below. 10630 Size in Logo Size 10631 Pixels Value 10633 32 x 32 or exsmall 10634 32 x 20 10636 53 x 33 small 10638 103 x 65 medium 10640 180 x 114 large 10642 263 x 166 exlarge 10644 10.2 Logo Color Depth 10646 There are three standard colour depths. The colour depth (including bits 10647 per pixel) and the corresponding value for Logo_Color_Depth are given in 10648 the table below. 10650 Color Depth Logo Color 10651 (bits per pixel) Depth Value 10653 4 (16 colors) 4 10655 8 (256 colors) nothing 10657 24 (16 million colors) 24 10659 Note that if Logo Color Depth is omitted then a logo with the default 10660 colour depth of 256 colours will be retrieved. 10662 10.3 Logo Net Location Examples 10664 If Logo Net Location was set to "ftp://logos.xzpay.com", then: 10666 o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 10667 colour logo 10669 o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16 10670 colour logo 10672 [Note] Organisations which make logos available for use with IOTP 10673 should always make available "small" and "medium" size logos 10674 and use the "gif" format. 10675 [Note End] 10677 11. Brands 10679 This section contains: 10681 o a definition of Brands and an outline of Brand Selection using Brand 10682 Lists, and 10684 o some XML examples of Brand Lists 10686 11.1 Brand Definitions and Brand Selection 10688 One of the key features of IOTP is the ability for a merchant to offer a 10689 list of Brands from which a consumer may make a selection. This section 10690 provides an overview of what is involved and provides guidance on how 10691 selection of a brand and associated payment instrument can be carried out 10692 by a Consumer. It covers: 10694 o definitions of Payment Instruments and Brands - what are Payment 10695 Instruments and Brands in an IOTP context. Further categorises Brands 10696 as optionally a "Dual Brand" or a "Promotional Brand", 10698 o identification and selection of Promotional Brands - Promotional Brands 10699 offer a Consumer some additional benefit, for example loyalty points or 10700 a discount. This means that both Consumers and Merchant must be able to 10701 correctly identify that a valid Promotional Brand is being used. 10703 Also see the following sections: 10705 o Brand List Component (section 7.7) which contains definitions of the 10706 XML elements which contain the list of Brands offered by a Merchant to 10707 a Consumer, and 10709 o Brand Selection Component (section 7.8) for details of how a Consumer 10710 records the Brand, currency, amount and payment protocol that was 10711 selected. 10713 11.1.1 Definition of Payment Instrument 10715 A Payment Instrument is the means by which a Consumer pays for goods or 10716 services offered by a Merchant. It can be, for example: 10718 o a credit card such as MasterCard or Visa; 10720 o a debit card such as MasterCard's Maestro; 10722 o a smart card based electronic cash payment instrument such as a Mondex 10723 Card, a GeldKarte card or a Visa Cash card 10725 o a software based electronic payment account such as a CyberCash or 10726 DigiCash account. 10728 Most Payment Instruments have a number, typically an account number, by 10729 which the Payment Instrument can be identified. 10731 11.1.2 Definition of Brand 10733 A Brand is the mark which identifies a particular type of Payment 10734 Instrument. A list of Brands are the payment options which are presented 10735 by the Merchant to the Consumer and from which the Consumer makes a 10736 selection. Each Brand may have a different Payment Handler. Examples of 10737 Brands include: 10739 o payment association and proprietary Brands, for example MasterCard, 10740 Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. 10742 o promotional brands (see below). These include: 10743 - store brands, where the Payment Instrument is issued to a Consumer by 10744 a particular Merchant, for example Walmart, Sears, or Marks and 10745 Spencer (UK) 10746 - cobrands, for example American Advantage Visa, where an Organisation 10747 uses their own brand in conjunction with, typically, a payment 10748 association Brand. 10750 11.1.3 Definition of Dual Brand 10752 A Dual Brand means that a single payment instrument may be used as if it 10753 were two separate Brands. For example there could be a single Japanese 10754 "UC" MasterCard which can be used as either a UC card or a regular 10755 MasterCard. The UC card Brand and the MasterCard Brand could each have 10756 their own separate Payment Handlers. This means that: 10758 o the merchant treats, for example "UC" and "MasterCard" as two separate 10759 Brands when offering a list of Brands to the Consumer, 10761 o the consumer chooses a Brand, for example either "UC" or "MasterCard, 10763 o the consumer IOTP aware application determines which Payment 10764 Instrument(s) match the chosen Brand, and selects, perhaps with user 10765 assistance, the correct Payment Instrument to use. 10767 [Note] Dual Brands need no special treatment by the Merchant and 10768 therefore no explicit reference is made to Dual Brands in the 10769 DTD. This is because, as far as the Merchant is concerned, 10770 each Brand in a Dual Brand is treated as a separate Brand. It 10771 is at the Consumer, that the matching of a Brand to a Dual 10772 Brand Payment Instrument needs to be done. 10773 [Note End] 10775 11.1.4 Definition of Promotional Brand 10777 A Promotional Brand means that, if the Consumer pays with that Brand, 10778 then the Consumer will receive some additional benefit which can be 10779 received in two ways: 10781 o at the time of purchase. For example if a Consumer pays with a "Walmart 10782 MasterCard" at a Walmart web site, then a 5% discount might apply, 10783 which means the consumer actually pays less, 10785 o from their Payment Instrument (card) issuer when the payment appears on 10786 their statement. For example loyalty points in a frequent flyer scheme 10787 could be awarded based on the total payments made with the Payment 10788 Instrument since the last statement was issued. 10790 Note that: 10792 o the first example (obtaining the benefit at the time of purchase), 10793 requires that: 10794 - the Consumer is informed of the benefits which arise if that Brand is 10795 selected 10796 - if the Brand is selected, the Merchant changes the relevant IOTP 10797 Components in the Offer Response to reflect the correct amount to be 10798 paid 10800 o the second (obtaining a benefit through the Payment Instrument issuer) 10801 does not require that the Offer Response is changed 10803 o each Promotional Brand should be identified as a separate Brand in the 10804 list of Brands offered by the Merchant. For example: "Walmart", 10805 "Sears", "Marks and Spencer" and "American Advantage Visa", would each 10806 be a separate Brand. 10808 11.1.5 Identifying Promotional Brands 10810 There are two problems which need to handled in identifying Promotional 10811 Brands: 10813 o how does the Merchant or their Payment Handler positively identify the 10814 promotional brand being used at the time of purchase 10816 o how does the Consumer reliably identify the correct promotional brand 10817 from the Brand List presented by the Merchant 10819 The following is a description of how this could be achieved. 10821 [Note] Please note that the approach described here is a model 10822 approach that solves the problem. Other equivalent methods may 10823 be used. 10824 [Note End] 10826 11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands 10828 Correct identification that the Consumer is paying using a Promotional 10829 Brand is important since a Consumer might fraudulently claim to have a 10830 Promotional Brand that offers a reduced payment amount when in reality 10831 they do not. 10833 Two approaches seem possible: 10835 o use some feature of the Payment Instrument or the payment method to 10836 positively identify the Brand being used. For example, the SET 10837 certificate for the Brand could be used, if one is available, or 10839 o use the Payment Instrument (card) number to look up information about 10840 the Payment Instrument on a Payment Instrument issuer database to 10841 determine if the Payment Instrument is a promotional brand. 10843 Note that: 10845 o the first assumes that SET is available. 10847 o the second is only possible if the Merchant, or alternatively the 10848 Payment Handler, has access to card issuer information. 10850 IOTP does not provide the Merchant with Payment Instrument information 10851 (e.g. a card or account number). This is only sent as part of the 10852 encapsulated payment protocol to a Payment Handler. This means that: 10854 o the Merchant would have to assume that the Payment Instrument selected 10855 was a valid Promotional Brand, or 10857 o the Payment Handler would have to check that the Payment Instrument was 10858 for the valid Promotional Brand and fail the payment if it was not. 10860 A Payment Handler checking that a brand is a valid Promotional Brand is 10861 most likely if the Payment Handler is also the Card Issuer. 10863 11.1.5.2 Consumer Selection of Promotional Brands 10865 Two ways by which a Consumer can correctly select a Promotional Brand 10866 are: 10868 o the Consumer visually matching a logo for the Promotional Brand which 10869 has been provided to the Consumer by the Merchant, 10871 o the Consumer's IOTP aware application matching a code for the 10872 Promotional Brand which the application has registered against a 10873 similar code contained in the list of Brands offered by the Merchant. 10875 In the latter case, the code contained in the Consumer wallet must match 10876 exactly the code in the list offered by the Merchant otherwise no match 10877 will be found. Ways in which the Consumer's IOTP Aware Application could 10878 obtain such a code include: 10880 o the Consumer types the code in directly. This is error prone and not 10881 user friendly, also the consumer needs to be provided with the code. 10882 This approach is not recommended, 10884 o using one of the Brand Identifiers defined by IOTP and pre-loaded into 10885 the Consumers IOTP Aware application or wallet by the developer of the 10886 Wallet, 10888 o using some information contained in the software or other data 10889 associated with the Payment Instrument. This could be: 10890 - a SET certificate for Brands which use this payment method 10891 - a code provided by the payment software which handles the particular 10892 payment method, this could apply to, for example, GeldKarte, Mondex, 10893 CyberCash and DigiCash, 10895 o the consumer making an initial "manual" link between a Promotional 10896 Brand in the list of Brands offered by the Merchant and an individual 10897 Payment Instrument, the first time the promotional brand is used. The 10898 IOTP Aware application would then "remember" the code for the 10899 Promotional Brand for use in future purchases. 10901 11.1.5.3 Consumer Software Brand Id recommendation 10903 New Brand Ids are allocated under IANA procedures (see section 12 IANA 10904 Considerations). Which also contains an initial list of Brand 10905 Identifiers. 10907 It is recommended that implementers of consumer IOTP aware applications 10908 (e.g. software wallets) pre-load their software with the then current set 10909 of Brand Ids and provide a method by which they can be updated. For 10910 example, by going to the software developer's web site. 10912 11.2 Brand List Examples 10914 This example contains three examples of the XML for a Brand List 10915 Component. It covers: 10917 o a simple credit card based example 10919 o a credit card based brand list including promotional credit card 10920 brands, and 10922 o a complex electronic cash based brand list 10924 Note that: 10926 o brand lists can be as complex or as simple as required 10928 o all example techniques described in this appendix can be included in 10929 one brand list. 10931 11.2.1 Simple Credit Card Based Example 10933 This is a simple example involving: 10935 o only major credit card payment brands 10937 o a single price in a single currency 10939 o a single Payment Handler, and 10941 o a single payment protocol 10943 10947 10952 10953 10958 10959 10964 10965 10968 10969 10972 10976 10977 10979 11.2.2 Credit Card Brand List Including Promotional Brands 10981 An example of a Credit Card based Brand List follows. It includes: 10983 o two ordinary card association brands and two promotional credit card 10984 brands. The promotional brands consist of one loyalty based (British 10985 Airways MasterCard) which offers additional loyalty points and one 10986 store based (Walmart) which offers a discount on purchases over a 10987 certain amount 10989 o two payment protocols: 10990 - SET (Secure Electronic Transactions) see [SET], and 10991 - SCCD (Secure Channel Credit Debit) see [SCCD]. 10993 10997 11002 11003 11004 11005 11010 11011 11012 11013 11019 11020 11021 11022 11029 11030 11033 11034 238djqw1298erh18dhoire 11035 11036 11037 11040 11041 238djqw1298erh18dhoire 11042 11043 11044 11047 11051 11052 8ueu26e482hd82he82 11053 11054 11055 11059 11060 82hd82he8226e48ueu 11061 11062 11063 11065 11.2.3 Brand Selection Example 11067 In order to pay by 'British Airways' MasterCard using the example above 11068 using SET and therefore getting double air miles, the Brand Selection 11069 would be: 11071 11076 11078 11.2.4 Complex Electronic Cash Based Brand List 11080 The following is an fairly complex example which includes: 11082 o payments using either Mondex, GeldKarte, CyberCash or DigiCash 11083 o in currencies including US dollars, British Pounds, Italian Lira, 11084 German Marks and Canadian Dollars 11086 o a discount on the price if the payment is made in Mondex using British 11087 pounds or US dollars, and 11089 o more than one Payment Handler is used for payments involving Mondex or 11090 CyberCash 11092 o support for more than one version of a CyberCash CyberCoin payment 11093 protocol. 11095 11099 11104 11105 11110 11111 11116 11117 11124 11125 11128 11129 11132 11133 11136 11137 11140 11141 11144 11145 11148 11151 11154 11157 11160 11163 11166 11169 11173 11174 11178 11179 11183 11184 11188 11189 11193 11194 11198 11199 11201 12. IANA Considerations 11203 This section describes the codes that are controlled by IANA, and also 11204 how new codes can be created for testing purposes that are not controlled 11205 by IANA. 11207 12.1 Codes Controlled by IANA 11209 To help ensure interoperability, there is a need for codes used by IOTP 11210 to be maintained in a controlled environment so that their meaning and 11211 usage are well defined and duplicate codes avoided. [IANA] is the 11212 mechanism to be used for this purpose as described in RFC 2434. 11214 The element types and attributes names to which this procedure applies is 11215 shown in the table below together with the initial values that are valid 11216 for these attributes. 11218 Note that: 11220 o the IETF Trade mailing list's email address is ietf-trade@elistx.com 11222 o "Designated Experts" (see [IANA]) are appointed by the IESG. 11224 Element Type/ Attribute Values 11225 Attribute Name 11227 Algorithm/ "sha1" - indicates that a [SHA1] authentication 11228 Name will apply 11229 (When Algorithm 11230 is a child of an "signature" - indicates that authentication 11231 AuthReq consists of the generation of a digital signature. 11232 Component) 11233 "Pay:ppp" where "ppp" may be set to any valid 11234 value for "iotpbrand" (see below) 11236 With the exception of Algorithms that begin with 11237 "pay:", new values are allocated following review 11238 on the IETF Trade mailing list and by the 11239 Designated Expert. 11241 [Note] The Algorithm element is likely to be 11242 eventually defined within the [DSIG] 11243 name space. It is likely that the 11244 maintenance procedure defined here 11245 may need to vary over time, as the 11246 DSIG proposals become more widely 11247 adopted. 11248 [Note End] 11250 Element Type/ Attribute Values 11251 Attribute Name 11253 Brand/BrandId The following list of initial BrandIds have been 11254 taken from those Organisations that have applied 11255 for SET certificates as at 1st June 1999: 11257 "Amex" - American Express 11259 "Dankort" - Dankort 11261 "JCB" - JCB 11263 "Maestro" - Maestro 11265 "MasterCard" - MasterCard 11267 "NICOS" - NICOS 11269 "VISA" - Visa 11271 In addition the following Brand Id values are 11272 defined: 11274 "Mondex" 11276 "GeldKarte" 11278 New values of BrandId must be announced to the 11279 IETF Trade mailing list and, if there are no 11280 objections within three weeks, are allocated on a 11281 "first come first served" basis. 11283 CurrencyAmount/ Currency codes are dependent on CurrCodeType (see 11284 CurrCode below). 11286 If CurrCodeType is "ISO4217-A" then the currency 11287 code is an alphabetic currency code as defined by 11288 [ISO4217]. 11290 If CurrCodeType is "IOTP" then new values must be 11291 announced to the IETF Trade mailing list and, if 11292 there are no objections within three weeks, are 11293 allocated on a "first come first served" basis. 11295 [Note] The Currency Code Type of IOTP, is 11296 designed to allow the support of 11297 "new" psuedo currencies such as 11298 loyalty or frequent flyer points. At 11299 the time of writing this 11300 specification, no currency codes of 11301 this type have been defined. 11302 [Note End] 11304 Element Type/ Attribute Values 11305 Attribute Name 11307 CurrencyAmount/ "ISO4217-A" 11308 CurrCodeType 11309 "IOTP" 11311 New values of CurrCodeType attribute are allocated 11312 following review on the IETF Trade mailing list 11313 and by the Designated Expert. 11315 DeliveryData/ "Post" 11316 DelivMethod 11317 "Web" 11319 "Email" 11321 New values of Delivery Method attribute are 11322 allocated following review on the IETF Trade 11323 mailing list and by the Designated Expert. This 11324 may require the publication of additional 11325 documentation to describe how the delivery method 11326 is used. 11328 PackagedContent/ "PCDATA" 11329 Content 11330 "MIME" 11332 "MIME:mimetype" (where mimetype must be the same 11333 as content-type as defined by [MIME] ) 11335 "XML" 11337 If the Content attribute is of the form 11338 "MIME"mimetype", then control of new values for 11339 "mimetype" is as defined in [MIME]. 11341 Otherwise, new values of the Content attribute are 11342 allocated following review on the IETF Trade 11343 mailing list and by the Designated Expert. This 11344 may require the publication of additional 11345 documentation to describe how the new attribute is 11346 used within a Packaged Content element. 11348 RelatedTo/ "IotpTransaction" 11349 RelationshipType 11350 "Reference" 11352 New values of the RelationshipType attribute are 11353 allocated following review on the IETF Trade 11354 Working Group mailing list and by the Designated 11355 Expert. This may require the publication of 11356 additional documentation to describe how the 11358 Element Type/ Attribute Values 11359 Attribute Name 11360 delivery method is used. 11362 Status/ Offer 11363 StatusType 11364 Payment 11366 Delivery 11368 Authentication 11370 Unidentified 11372 New values of the Status Type attribute are 11373 allocated following: 11374 o publication to the IETF Trade Working Group, 11375 of an RFC describing the Trading Exchange, 11376 Trading Roles and associated components that 11377 relate to the Status, and 11378 o review of the document on the IETF Trade 11379 mailing list and by the Designated Expert. 11381 [Note] The document describing new values 11382 for the Status Type attribute may be 11383 combined with documents that describe 11384 new Trading Roles and types of 11385 signatures (see below). 11386 [Note End] 11388 TradingRole/ "Consumer" 11389 TradingRole 11390 "Merchant" 11392 "PaymentHandler" 11394 "DeliveryHandler" 11396 "DelivTo" 11398 "CustCare" 11400 New values of the Trading Role attribute are 11401 allocated following: 11402 o publication to the IETF Trade Working Group, 11403 of an RFC describing the Trading Exchange, 11404 Trading Roles and associated components that 11405 relate to the Trading Role, and 11406 o review of the document on the IETF Trade 11407 mailing list and by the Designated Expert. 11409 [Note] The document describing new values 11410 for the Trading Role attribute may be 11412 Element Type/ Attribute Values 11413 Attribute Name 11414 combined with documents that describe 11415 new Status Types (see above) and 11416 types of signatures (see below). 11417 [Note End] 11419 TransId/ "BaselineAuthentication" 11420 IotpTransType 11421 "BaselineDeposit" 11423 "BaselinePurchase" 11425 "BaselineRefund" 11427 "BaselineWithdrawal" 11429 "BaselineValueExchange" 11431 "BaselineInquiry" 11433 "BaselinePing" 11435 New values of the IotpTransType attribute are 11436 allocated following: 11437 o publication to the IETF Trade mailing list, of 11438 an RFC describing the new IOTP Transaction, and 11439 o review of the document on the IETF Trade 11440 Working Group mailing list and by the 11441 Designated Expert. 11443 Attibute/ Content 11444 (see Signature 11445 "OfferResponse" 11446 Component) "PaymentResponse" 11448 "DeliveryResponse" 11450 "AuthenticationRequest" 11452 "AuthenticationResponse" 11454 "PingRequest" 11456 "PingResponse" 11458 New values of the code that define the type of a 11459 signature are allocated following: 11460 o publication to the IETF Trade Working Group, 11461 of an RFC describing the Trading Exchange where 11462 the signature is being used, and 11463 o review of the document on the IETF Trade 11464 mailing list and by the Designated Expert. 11466 Element Type/ Attribute Values 11467 Attribute Name 11469 [Note] The document describing new values 11470 for the types of signatures may be 11471 combined with documents that describe 11472 new Status Types and Trading Roles 11473 (see above). 11474 [Note End] 11476 12.2 Codes not controlled by IANA 11478 In addition to the formal development and registration of codes as 11479 described above, there is still a need for developers to experiment using 11480 new IOTP codes. For this reason, "user defined codes" may be used to 11481 identify additional values for the codes contained within this 11482 specification without the need for them to be registered with IANA. 11484 The definition of a user defined code is as follows: 11486 user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)* 11488 NameChar NameChar has the same definition as the [XML] 11489 definition of NameChar 11491 Use of domain names (see [DNS]) to make user defined codes unique is 11492 recommended although this method cannot be relied upon. 11494 13. Internet Open Trading Protocol Data Type Definition 11496 This section contains the XML DTD for the Internet Open Trading 11497 Protocols. 11499 11520 11542 11546 11552 11553 11556 11557 11564 11565 11575 11576 11583 11589 11590 11595 11600 11601 11602 11610 11611 11612 11617 11618 11619 11625 11626 11627 11631 11632 11633 11643 11644 11646 11654 11655 11663 11664 11671 11672 11679 11680 11690 11691 11693 11699 11700 11710 11711 11715 11716 11722 11723 11729 11730 11740 11741 11744 11751 11752 11756 11757 11761 11762 11766 11767 11768 11776 11777 11778 11785 11786 11787 11793 11794 11795 11799 11800 11801 11808 11809 11819 11820 11821 11825 11826 11827 11833 11834 11835 11846 11847 11848 11853 11854 11855 11861 11862 11863 11872 11873 11881 11887 11888 11889 11892 11893 11894 11897 11898 11900 11903 11904 11905 11908 11909 11910 11913 11914 11915 11918 11919 11921 11924 11925 11926 11929 11930 11932 11935 11936 11938 11941 11942 11943 11946 11947 11948 11951 11952 11953 11958 11959 11960 11963 11964 11965 11972 11973 11974 11977 11978 11979 11982 11988 11989 11993 11999 12000 12004 12013 12017 12018 12024 12025 12029 12030 12036 12037 12041 12042 12049 12050 12054 12055 12059 12065 12069 12074 12075 12080 12085 12086 12091 12092 12097 14. Glossary 12099 This section contains a glossary of some of the terms used within this 12100 specification in alphabetical order. 12102 NAME DESCRIPTION 12104 Authenticator The Organisation which is requesting the 12105 authentication of another Organisation, and 12107 Authenticatee The Organisation being authenticated by an 12108 Authenticator 12110 Business Error See Status Component. 12112 Brand A Brand is the mark which identifies a particular 12113 type of Payment Instrument. A list of Brands are 12114 the payment options which are presented by the 12115 Merchant to the Consumer and from which the 12116 Consumer makes a selection. Each Brand may have a 12117 different Payment Handler. Examples of Brands 12118 include: 12119 o payment association and proprietary Brands, 12120 for example MasterCard, Visa, American Express, 12121 Diners Club, American Express, Mondex, 12122 GeldKarte, CyberCash, etc. 12123 o Promotional Brands (see below). These include: 12124 o store Brands, where the Payment Instrument is 12125 issued to a Consumer by a particular Merchant, 12126 for example Walmart, Sears, or Marks and 12127 Spencer (UK) 12128 o coBrands, for example American Advantage Visa, 12129 where an a company uses their own Brand in 12130 conjunction with, typically, a payment 12131 association Brand. 12133 Consumer The Organisation which is to receive the benefit 12134 of and typically pay for the goods or services. 12136 ContentSoftwareId This contains information which identifies the 12137 software which generated the content of the 12138 element. Its purpose is to help resolve 12139 interoperability problems that might occur as a 12140 result of incompatibilities between messages 12141 produced by different software. It is a single 12142 text string in the language defined by xml:lang. 12143 It must contain, as a minimum: 12144 o the name of the software manufacturer 12145 o the name of the software 12146 o the version of the software, and 12147 o the build of the software 12149 NAME DESCRIPTION 12151 It is recommended that this attribute is included 12152 whenever the software which generated the content 12153 cannot be identified from the SoftwareId attribute 12154 on the Message Id Component (see section 3.3.2) 12156 Customer Care An Organisation that is providing customer care 12157 Provider typically on behalf of a Merchant. Examples of 12158 customer care include, responding to problems 12159 raised by a Consumer arising from an IOTP 12160 Transaction that the Consumer took part in. 12162 Delivery Handler The Organisation that directly delivers the goods 12163 or services to the Consumer on behalf of the 12164 Merchant. Delivery can be in the form of either 12165 digital goods (e.g. a [MIME] message), or 12166 physically delivered using the post or a courier. 12168 Document Exchange A Document Exchange consists of a set of IOTP 12169 Messages exchanged between two parties that 12170 implement part or all of two Trading Exchanges 12171 simultaneously in order to minimise the number of 12172 actual IOTP Messages which must be sent over the 12173 Internet. 12175 Document Exchanges are combined together in 12176 sequence to implement a particular IOTP 12177 Transaction. 12179 Dual Brand A Dual Brand means that a single Payment 12180 Instrument may be used as if it were two separate 12181 Brands. For example there could be a single 12182 Japanese "UC" MasterCard which can be used as 12183 either a UC card or a regular MasterCard. The UC 12184 card Brand and the MasterCard Brand could each 12185 have their own separate Payment Handlers. This 12186 means that: 12187 o the Merchant treats, for example "UC" and 12188 "MasterCard" as two separate Brands when 12189 offering a list of Brands to the Consumer, 12190 o the Consumer chooses a Brand, for example 12191 either "UC" or "MasterCard, 12192 o the Consumer IOTP aware application determines 12193 which Payment Instrument(s) match the chosen 12194 Brand, and selects, perhaps with user 12195 assistance, the correct Payment Instrument to 12196 use. 12198 Error Block An Error Block reports that a Technical Error was 12199 found in an IOTP Message that was previously 12200 received. Typically Technical Errors are caused by 12201 errors in the XML which has been received or some 12203 NAME DESCRIPTION 12204 technical failure of the processing of the IOTP 12205 Message. Frequently the generation or receipt of 12206 an Error Block will result in failure of the IOTP 12207 Transaction. They are distinct from Business 12208 Errors, reported in a Status Component, which can 12209 also cause failure of an IOTP Transaction. 12211 Exchange Block An Exchange Block is sent between the two Trading 12212 Roles involved in a Trading Exchange. It contains 12213 one or more Trading Components. Exchange Blocks 12214 are always sent after a Request Block and before a 12215 Response Block in a Trading Exchange. The content 12216 of an Exchange Block is dependent on the type of 12217 Trading Exchange being carried out. 12219 IOTP Message An IOTP Message is the outermost wrapper for the 12220 document(s) which are sent between Trading Roles 12221 that are taking part in a trade. It is a well 12222 formed XML document. The documents it contains 12223 consist of: 12224 o a Transaction Reference Block to uniquely 12225 identify the IOTP Transaction of which the IOTP 12226 Message is part, 12227 o an optional Signature Block to digitally sign 12228 the Trading Blocks or Trading Components 12229 associated with the IOTP Transaction 12230 o an optional Error Block to report on technical 12231 errors contained in a previously received IOTP 12232 Message, and 12233 o a collection of IOTP Trading Blocks which 12234 carries the data required to carry out an IOTP 12235 Transaction. 12237 IOTP Transaction An instance of an Internet Open Trading Protocol 12238 Transaction consists of a set of IOTP Messages 12239 transferred between Trading Roles. The rules for 12240 what may be contained in the IOTP Messages is 12241 defined by the Transaction Type of the IOTP 12242 Transaction. 12244 IOTP Transaction A Transaction Type identifies the type an of IOTP 12245 Type Transaction. Examples of Transaction Type include: 12246 Purchase, Refund, Authentication, Withdrawal, 12247 Deposit (of electronic cash). The Transaction Type 12248 specifies for an IOTP Transaction: 12249 o the Trading Exchanges which may be included in 12250 the transaction, 12251 o how those Trading Exchanges may be combined to 12252 meet the business needs of the transaction 12253 o which Trading Blocks may be included in the 12254 IOTP Messages that make up the transaction 12255 o Consult this specification for the rules that 12257 NAME DESCRIPTION 12258 apply for each Transaction Type. 12260 Merchant The Organisation from whom the service or goods 12261 are being obtained, who is legally responsible for 12262 providing the goods or services and receives the 12263 benefit of any payment made 12265 Merchant Customer The Organisation that is involved with customer 12266 Care Provider dispute negotiation and resolution on behalf of 12267 the Merchant 12269 Organisation A company or individual that takes part in a Trade 12270 as a Trading Role. The Organisations may take one 12271 or more of the roles involved in the Trade 12273 Payment Handler The Organisation that physically receives the 12274 payment from the Consumer on behalf of the 12275 Merchant 12277 Payment A Payment Instrument is the means by which 12278 Instrument Consumer pays for goods or services offered by a 12279 Merchant. It can be, for example: 12280 o a credit card such as MasterCard or Visa; 12281 o a debit card such as MasterCard's Maestro; 12282 o a smart card based electronic cash Payment 12283 Instrument such as a Mondex Card, a GeldKarte 12284 card or a Visa Cash card 12285 o a software based electronic payment account 12286 such as a CyberCash's CyberCoin or DigiCash 12287 account. 12289 All Payment Instruments have a number, typically 12290 an account number, by which the Payment Instrument 12291 can be identified. 12293 Promotional Brand A Promotional Brand means that, if the Consumer 12294 pays with that Brand, then the Consumer will 12295 receive some additional benefit which can be 12296 received in two ways: 12297 o at the time of purchase. For example if a 12298 Consumer pays with a "Walmart MasterCard" at a 12299 Walmart web site, then a 5% discount might 12300 apply, which means the Consumer actually pays 12301 less, 12302 o from their Payment Instrument (card) issuer 12303 when the payment appears on their statement. 12304 For example loyalty points in a frequent flyer 12305 scheme could be awarded based on the total 12306 payments made with the Payment Instrument since 12307 the last statement was issued. 12309 Each Promotional Brand should be identified as a 12311 NAME DESCRIPTION 12312 separate Brand in the list of Brands offered by 12313 the Merchant. 12315 Receipt Component A Receipt Component is a record of the successful 12316 completion of a Trading Exchange. Examples of 12317 Receipt Components include: Payment Receipts, and 12318 Delivery Notes. It's content may dependent on the 12319 technology used to perform the Trading Exchange. 12320 For example a Secure Electronic Transaction (SET) 12321 payment receipt consists of SET payment messages 12322 which record the result of the payment. 12324 Request Block A Request Block is Trading Block that contains a 12325 request for a Trading Exchange to start. The 12326 Trading Components in a Request Block may be 12327 signed by a Signature Block so that their 12328 authenticity may be checked and to determine that 12329 the Trading Exchange being requested is 12330 authorised. Authorisation for a Trading Exchange 12331 to start can be provided by the signatures 12332 contained on Receipt Components contained in 12333 Response Blocks resulting from previously 12334 completed Trading Exchanges. Examples of Request 12335 Blocks are Payment Request and Delivery Request 12337 Response Block A Response Block is a Trading Block that indicates 12338 that a Trading Exchange is complete. It is sent by 12339 the Trading Role that received a Request Block to 12340 the Trading Role that sent the Request Block. The 12341 Response Block contains a Status Component that 12342 contains information about the completion of the 12343 Trading Exchange, for example it indicates whether 12344 or not the Trading Exchange completed 12345 successfully. For some Trading Exchanges the 12346 Response Block contains a Receipt Component that 12347 forms a record of the Trading Exchange. Receipt 12348 Components may be digitally signed using a 12349 Signature Block to make completion non-refutable. 12350 Examples of Response Blocks include Offer 12351 Response, Payment Response and Delivery Response. 12353 Signature Block A Signature Block is a Trading Block that contains 12354 one or more digital signatures in the form of 12355 Signature Components. A Signature Component may 12356 digitally sign any Block or Component in any IOTP 12357 Message in the same IOTP Transaction. 12359 Status Component A Status Component contains information that 12360 describes the state of a Trading Exchange. 12362 Before the Trading Exchange is complete the Status 12363 Component can indicate information about how the 12365 NAME DESCRIPTION 12366 Trading Exchange is progressing. 12368 Once a Trading Exchange is complete the Status 12369 Component can only indicate the success of the 12370 Trading Exchange or that a Business Error has 12371 occurred. 12373 A Business Error indicates that continuation with 12374 the Trading Exchange was not possible because of 12375 some business rule or logic, for example, 12376 "insufficient funds available", rather than any 12377 Technical Error associated with the content or 12378 format of the IOTP Messages in the IOTP 12379 Transaction. 12381 Technical Error See Error Block. 12383 Trading Block A Trading Block consists of one or more Trading 12384 Components. One or more Trading Blocks may be 12385 contained within the IOTP Messages which are 12386 physically sent in the form of [XML] documents 12387 between the different Trading Roles that are 12388 taking part in a trade. Trading Blocks are of 12389 three main types: 12390 o a Request Block, 12391 o an Exchange Block, or a 12392 o a Response Block 12394 Trading Component A Trading Component is a collection of XML 12395 elements and attributes. Trading Components are 12396 the child elements of the Trading Blocks. Examples 12397 of Trading Components are: Offer, Brand List, 12398 Payment Receipt, Delivery [information], Payment 12399 Amount [information] 12401 Trading Exchange A Trading Exchange consists of the exchange, 12402 between two Trading Roles, of a sequence of 12403 documents. The documents may be in the form of 12404 Trading Blocks or they may be transferred by some 12405 other means, for example through entering data 12406 into a web page. Each Trading Exchange consists of 12407 three main parts: 12408 o the sending of a Request Block by one Trading 12409 Role (the initiator) to another Trading Role 12410 (the recipient), 12411 o the optional exchange of one or more Exchange 12412 Blocks between the recipient and the initiator, 12413 until eventually, 12414 o the Trading Role that received the Request 12415 Block sends a Response Block to the initiator. 12417 A Trading Exchange is designed to implement a 12419 NAME DESCRIPTION 12420 useful service of some kind. Examples of Trading 12421 Exchanges/services are: 12422 o Offer, which results in a Consumer receiving 12423 an offer from a Merchant to carry out a 12424 business transaction of some kind, 12425 o Payment, where a Consumer makes a payment to a 12426 Payment Handler, 12427 o Delivery, where a Consumer requests, and 12428 optionally obtains, delivery of goods or 12429 services from a Delivery Handler, and 12430 o Authentication, where any Trading Role may 12431 request and receive information about another 12432 Trading Role. 12434 Trading Role A Trading Role identifies the different ways in 12435 which Organisations can participate in a trade. 12436 There are five Trading Roles: Consumer, Merchant, 12437 Payment Handler, Delivery Handler, and Merchant 12438 Customer Care Provider. 12440 Transaction A Transaction Reference Block identifies an IOTP 12441 Reference Block Transaction. It contains data that identifies: 12442 o the Transaction Type, 12443 o the IOTP Transaction uniquely, through a 12444 globally unique transaction identifier 12445 o the IOTP Message uniquely within the IOTP 12446 Transaction, through a message identifier 12448 The Transaction Reference Block may also contain 12449 references to other transactions which may or may 12450 not be IOTP Transactions 12452 15. Copyrights 12454 Copyright (C) The Internet Society (1998). All Rights Reserved. 12456 This document and translations of it may be copied and furnished to 12457 others, and derivative works that comment on or otherwise explain it or 12458 assist in its implementation may be prepared, copied, published and 12459 distributed, in whole or in part, without restriction of any kind, 12460 provided that the above copyright notice and this paragraph are included 12461 on all such copies and derivative works. However, this document itself 12462 may not be modified in any way, such as by removing the copyright notice 12463 or references to the Internet Society or other Internet organisations, 12464 except as needed for the purpose of developing Internet standards in 12465 which case the procedures for copyrights defined in the Internet 12466 Standards process must be followed, or as required to translate it into 12467 languages other than English. 12469 The limited permissions granted above are perpetual and will not be 12470 revoked by the Internet Society or its successors or assigns. 12472 This document and the information contained herein is provided on an AS 12473 IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 12474 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 12475 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 12476 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 12477 PARTICULAR PURPOSE. 12479 16. References 12481 This section contains references to related documents identified in this 12482 specification. 12484 [Base64] Base64 Content-Transfer-Encoding. A method of 12485 transporting binary data defined by MIME. See: RFC 2045: 12486 Multipurpose Internet Mail Extensions (MIME) Part One: 12487 Format of Internet Message Bodies. N. Freed & N. 12488 Borenstein. November 1996. 12490 [DOM-HASH] A method for generating hashes of all or part of an XML 12491 tree based on the DOM of that tree. See, currently, 12492 http://www.ietf.org/internet-drafts/draft-ietf-trade- 12493 hiroshi-dom-hash-*.txt 12495 [DNS] See RFC 1034: Domain names - concepts and facilities. 12496 P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names 12497 - implementation and specification. P.V. Mockapetris. 12498 Nov-01-1987. 12500 [DSA] The Digital Signature Algorithm (DSA) published by the 12501 National Institute of Standards and Technology (NIST) in 12502 the Digital Signature Standard (DSS), which is a part of 12503 the US government's Capstone project. 12505 [ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm 12506 (ECCDSA). Elliptic curve cryptosystems are analogues of 12507 public-key cryptosystems such as RSA in which modular 12508 multiplication is replaced by the elliptic curve addition 12509 operation. See: V. S. Miller. Use of elliptic curves in 12510 cryptography. In Advances in Cryptology - Crypto '85, 12511 pages 417-426, Springer-Verlag, 1986. 12513 [HMAC] See RFC 2104 HMAC: Keyed-Hashing for Message 12514 Authentication. H. Krawczyk, M. Bellare, R. Canetti. 12515 February 1997 12517 [HTML] Hyper Text Mark Up Language. The Hypertext Mark-up 12518 Language (HTML) is a simple mark-up language used to 12519 create hypertext documents that are platform independent. 12520 See RFC 1866 and the World Wide Web (W3C) consortium web 12521 site at: http://www.w3.org/MarkUp/ 12523 [HTTP] Hyper Text Transfer Protocol versions 1.0 and 1.1. See 12524 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. T. 12525 Berners-Lee, R. Fielding & H. Frystyk. May 1996. and RFC 12526 2068: Hypertext Transfer Protocol -- HTTP/1.1. R. 12527 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- 12528 Lee. January 1997. 12530 [IANA] The Internet Assigned Numbers Authority. The organisation 12531 responsible for co-ordinating the names and numbers 12532 associated with the Internet. See http://www.iana.org/. 12534 [ISO4217] ISO 4217: Codes for the Representation of Currencies. 12535 Available from ANSI or ISO. 12537 [IOTPDSIG] A document that describes how data contained in IOTP 12538 messages may be digitally signed. See, currently, 12539 http://www.ietf.org/internet-drafts/draft-ietf-trade- 12540 iotp-v1.0-dsig-*.txt. 12542 [MD5] R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. 12544 [MIME] Multipurpose Internet Mail Extensions. See RFC822, 12545 RFC2045, RFC2046, RFC2047, RFC2048 and RFC2049. 12547 [OPS] Open Profiling Standard. A proposed standard which 12548 provides a framework with built-in privacy safeguards for 12549 the trusted exchange of profile information between 12550 individuals and web sites. Being developed by Netscape 12551 and Microsoft amongst others. 12553 [RFC822] See RFC 822: The Standard for the Format of ARPA Internet 12554 Messages. 13 August 1982, David H Crocker. 13 August 12555 1982. 12557 [RFC1738] See RFC 1738: Uniform Resource Locators (URL), ed. T. 12558 Berners-Lee, L. Masinter, M. McCahill. 1994. 12560 [RFC2434] See RFC 2434. Guidelines for Writing an IANA 12561 Considerations Section in RFCs. T. Narten and H. 12562 Alvestrand 12564 [RSA] RSA is a public-key cryptosystem for both encryption and 12565 authentication supported by RSA Data Security Inc. See: 12566 R. L. Rivest, A. Shamir, and L.M. Adleman. A method for 12567 obtaining digital signatures and public-key 12568 cryptosystems. Communications of the ACM, 21(2): 120-126, 12569 February 1978. 12571 [SCCD] Secure Channel Credit Debit. A method of conducting a 12572 credit or debit card payment where unauthorised access to 12573 account information is prevented through use of secure 12574 channel transport mechanisms such as SSL/TLS. An IOTP 12575 supplement describing how SCCD works is under 12576 development. 12578 [SET] Secure Electronic Transaction Specification, Version 1.0, 12579 May 31, 1997. Supports credit and debit card payments 12580 using certificates at the Consumer and Merchant to help 12581 ensure authenticity. 12582 Download from: . 12584 [SSL/TLS] SSL is a standard developed by Netscape for encrypting 12585 data over IP networks. See 12586 http://home.netscape.com/eng/ssl3/index.html. TLS is the 12587 likely successor to SSL being developed by the IETF. See 12588 http://www.ietf.org/internet-drafts/draft-ietf-tls- 12589 protocol-05.txt 12591 [SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of 12592 Standards and Technology, US Department Of Commerce, 12593 April 1995. Also known as: 59 Fed Reg. 35317 (1994). See 12594 http://www.itl.nist.gov/div897/pubs/fip180-1.htm 12596 [UTC] Universal Time Co-ordinated. A method of defining time 12597 absolutely relative to Greenwich Mean Time (GMT). 12598 Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" 12599 where the "+n" defines the number of hours from GMT. See 12600 ISO DIS8601. 12602 [UTF16] The Unicode Standard, Version 2.0. The Unicode 12603 Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 12604 Proposed Draft Amendment 1 12606 [X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, 12607 Including Draft Amendment 1: Certificate Extensions 12608 (Version 3 Certificate) 12610 [XML Recommendation for Namespaces in XML, World Wide Web 12611 Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC- 12612 xml-names" 12614 [XML] Extensible Mark Up Language. A W3C recommendation. See 12615 http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 12616 February 1998 version. 12618 17. Author's Address 12620 The author of this document is: 12622 David Burdett 12623 Commerce One 12624 1600 Riviera Ave, Suite 200 12625 Walnut Creek 12626 California 94596 12627 USA 12629 Tel: +1 (925) 941 4422 12631 Email: david.burdett@commerceone.com 12633 The author of this document particularly wants to thank Mondex 12634 International Limited (www.mondex.com) for the tremendous support 12635 provided in the formative stages of the development of this 12636 specification. 12638 In addition the author appreciates the following contributors to this 12639 protocol (in alphabetic order of company) without which it could not have 12640 been developed. 12641 - Phillip Mullarkey, British Telecom plc 12642 - Andrew Marchewka, Canadian Imperial Bank of Commerce 12643 - Brian Boesch, CyberCash Inc. 12644 - Tom Arnold, CyberSource 12645 - Terry Allen, Commerce One (formally Veo Systems) 12646 - Richard Brown, GlobeSet Inc. 12647 - Peter Chang, Hewlett Packard 12648 - Masaaki Hiroya, Hitachi Ltd 12649 - Yoshiaki Kawatsura, Hitachi Ltd 12650 - Donald Eastlake 3rd, International Business Machines (formerly 12651 CyberCash Inc). 12652 - Mark Linehan, International Business Machines 12653 - Jonathan Sowler, JCP Computer Services Ltd 12654 - John Wankmueller, MasterCard International 12655 - Steve Fabes, Mondex International Ltd 12656 - Surendra Reddy, Oracle Corporation 12657 - Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd) 12658 - Chris Smith, Royal Bank of Canada 12659 - Hans Bernhard-Beykirch, SIZ (IT Development and Coordination Centre 12660 of the German Savings Banks Organisation) 12661 - W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, 12662 formally AT&T Universal Card Services) 12663 - Efrem Lipkin, Sun Microsystems 12664 - Tony Lewis, Visa International 12666 The author would also like to thank the following organisations for their 12667 support: 12668 - Amino Communications 12669 - DigiCash 12670 - Fujitsu 12671 - General Information Systems 12672 - Globe Id Software 12673 - Hyperion 12674 - InterTrader 12675 - Nobil I T Corp 12676 - Mercantec 12677 - Netscape 12678 - Nippon Telegraph and Telephone Corporation 12679 - Oracle Corporation 12680 - Smart Card Integrations Ltd. 12681 - Spyrus 12682 - Verifone 12683 - Unisource nv 12684 - Wells Fargo Bank 12686 File name: [draft-ietf-trade-iotp-v1.0-protocol-07.txt] 12687 Expires: April 2000