idnits 2.17.1 draft-eastlake-universal-payment-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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-eastlake-universal-payment-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-universal-payment-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-universal-payment-02.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-universal-payment-02.txt,', but the file name used is 'draft-eastlake-universal-payment-02' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (20 March 1996) is 10264 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1521' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC 1522' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'PGP' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'SET' is defined on line 567, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1898 ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Possible downref: Non-RFC (?) normative reference: ref. 'PGP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' Summary: 13 errors (**), 1 flaw (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Expires: 19 September 1996 CyberCash 3 20 March 1996 5 Universal Payment Preamble 6 --------- ------- -------- 8 Status of This Document 10 This draft, file name draft-eastlake-universal-payment-02.txt, is 11 intended to be become a Proposed Standard RFC. Distribution of this 12 document is unlimited. Comments should be sent to the author or to 13 the and mailing 14 lists. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 The Internet is becoming an increasingly commercial arena in which 36 payments are rendered for goods and services. To support such 37 commerce, numerous incompatible Internet payment protocols have been 38 adopted by a variety of organizations. There appears to be little 39 prospect of merger or abandonment of many of these protocols. 41 A unified payment syntax is presented for parties to negotiate 42 payment alternatives at any point in shopping, until a final hand-off 43 to a particular chosen payment system. 45 Acknowledgements 47 The contributions of the following persons to this draft are 48 gratefully acknowledged: 50 Ali Bahreman 51 Brian Boesch 52 Randy Bush 53 Steve Crocker 54 Rohit Khare 55 Pieter van der Linden 56 Bill Melton 57 Jim Miller 58 Paul-Andre Pays 60 Table of Contents 62 Status of This Document....................................1 64 Abstract...................................................2 65 Acknowledgements...........................................2 67 Table of Contents..........................................3 69 1. Introduction............................................4 70 1.1 The Universal Payment Preamble Solution................4 72 2. The Universal Payment Preamble..........................6 73 2.1. The Universal Payment PEP Headers.....................6 74 2.2 Special UPP Protocol Parameters........................7 75 2.3 The Initiation Message.................................8 76 2.4 UPP Header and Message Integrity.......................9 78 3. Examples...............................................10 79 3.1 Minimal UPP Example...................................10 80 3.2 More Generous UPP Example.............................10 81 3.3 Complex UPP Example...................................11 83 4. Anticipated Effects of Universal Payment Preamble......14 85 5. Security Considerations................................15 86 References................................................15 88 Author's Address..........................................16 89 Expiration and File Name..................................16 91 Appendix A: Card Brands...................................17 93 1. Introduction 95 The Internet is becoming an increasingly commercial arena in which 96 payments are rendered for goods and services. This commerce can take 97 a variety of forms from interactiny with a vendor via a World Wide 98 Web browser to ordering by email from a CD-ROM catalog. Typically 99 the shopping or selection phase is followed by a payment phase and 100 then usually by a fulfillment or delivery phase. 102 To provide general privacy and security to all three phases, there 103 are a variety of IETF standardized protocols, such as MOSS or IPSEC, 104 and other protocols, such as S-HTPP, PGP, and SSL. Some people use 105 such general secure channel or secure message systems for payments. 106 However, the payments phase is especially sensitive because it deals 107 with "real money", thus providing a strong incentive to crackers, and 108 is also especially complex. Frequently payment involves three or 109 more parties such as a customer, merchant, and bank or payment 110 system, with structured and interlocking messages that incorporate 111 fields best encrypted for parties other than their initial recipient. 112 For these reasons a number of specialized payment protocols have been 113 adopted. 115 As examples of payment protocols, there is the SET standard being 116 developed by MasterCard and VISA, the CyberCash system [RFC 1898], 117 GCtech's GlodeID, CMU's NetBill, and many more. 119 The Universal Payment Preamble provides three capabilities: (1) 120 negotiation of payment service, (2) exchanage of payment related 121 identification information, and (3) initiation of the specific 122 payment system. The payment service and initiation information are 123 sufficient to smoothly bridge from shopping to payment and, if 124 appropriate, from payment back to other customer - vendor 125 interaction. 127 1.1 The Universal Payment Preamble Solution 129 A high level overview of the Universal Payment Preamble solution to 130 this problem is as follows: 132 Shopping proceeds in a free-form way constrained only by the desires 133 of the customer and vendor. Some information closely related to 134 shopping but not closely tied to payment is made available via 135 changes in HTML so that certain specially named fields can be semi- 136 automatically filled in with such information as shipping address. 137 This includes such items as shipping address, customer name, 138 telephone number, and email address. [The field names and HTML 139 changes will be documented elsewhere.] If desired, UPP information 140 may be exchanged before or during the shopping process. This might 141 be done so the customer is assured they can pay by a means they want 142 to use or so that a merchant can condition their offer based on 143 information about the customer. After the order has been decided on, 144 the definitive order and remaining payment options are transmitted 145 from the party knowing them to the other in a initiation message. 146 The party receiving this message chooses the payment option (in 147 general choosing transport protocol, payment system, payment type, 148 etc. to the extent these have not been decided by earlier 149 negotiation) and proceeds using the selected payment system if any of 150 those presented are acceptable. 152 2. The Universal Payment Preamble 154 The Universal Payment Preamble is so called because it exchanges 155 information that needs to be resolved before a particular payment 156 system is entered and provides an initiation message to enter the 157 payment protocol. It is expected that it will frequently be used in 158 conjunction with the profile protocol [draft-eastlake-pep-profile- 159 00.txt] which can exchange ancillary information that may be 160 important to some payment systems. 162 Information is exchanged using the Protocol Extension Protocol 163 [draft-khare-http-pep-*.txt] headers. Familiarity with PEP is 164 assumed in this draft. 166 2.1. The Universal Payment PEP Headers 168 Each payment system is considered to be a PEP protocol extension, 169 identified by a URL, and in addition there exists the 170 http://pep.w3.org/UPP protocol. Each payment system as well as the 171 umbrella UPP protocol should register itself as handling its own 172 protocol and also handling the UPP protocol. (Some payment systems 173 may also wish to register for the Profile protocol. See draft- 174 eastlake-pep-profile-00.txt.) 176 UPP headers can be exchanged before or during shopping to narrow the 177 field of payment methods and gain some assurance that there is some 178 acceptable method available. This will occur via PEP headers using 179 the payment system and UPP protocols. 181 Each individual payment service will have a proprietary protocol 182 compatible with the "generic" UPP Protocol. Compatibility is largely 183 defined by the parameters defined in section 2.2 below that lists the 184 names of common parameters and the encoding to be used for their 185 values. In addition, it implies an agreement about a "style" of 186 negotiation: the payee agrees not to take irrevocable action based 187 solely on the use of the UPP and specific payment protocol 188 negotiation. Rather, it takes place in the proprietary protocol that 189 starts at the end of the negotiation phase. Payment security is 190 attained to the extent it is provided by this proprietary protocol. 192 When a merchant says "I request UPP, optionally", it is asking the 193 customer to generate a list of the clients' offered payment systems 194 (or vice versa if the customer makes this request). The server 195 demands payment by requesting 'UPP, strength=required.' This forces 196 the client to respond with one or more 'armed' payment initiators 197 (i.e. with all parameters for chosen payment system(s) filled in). 198 If the negotiation process has not narrowed down to a single payment 199 system, the browser/UPP module may pop up a notification toolbar or 200 automatically choose or leave it to the server to either choose or 201 force a choice by using an HTML form. 203 Requesting the UPP protocol is the same as asking the other party 204 which payment services it has that it is willing to reveal. 205 Requiring the UPP protocol is requiring the other party to tender a 206 specific payment. Asserting a UPP protocol means that a protocol 207 instance message is payment. 209 2.2 Special UPP Protocol Parameters 211 The following PEP parameters, if they appear in a params bag for a 212 payment system, have the form and meaning indicated: 214 account: This parameter is used to provide information about the 215 account number to be used at the customer or merchant. Usually 216 this number is meaningful only for the particular payment system 217 but account type information, such as card brand, may be given to 218 indicate choices. For example "{params ... {account-type {AX} 219 {MC} {VI}} ...}" to indicate that American Express, MasterCard and 220 VISA are acceptable (vendor) or providable (customer). [brand-ids 221 may need to be BINs or something more complex than this...] 223 amount: This is the cost of the order thus far. It consists of a 224 list of bags with the ISO 4217 currency code as the first item and 225 optionally an amount as the second. For example "{params ... 226 {amount {usd} {gbp}} ...}" to indicate that US dollars and pounds 227 Sterling are acceptable (vendor) or providable (customer) or 228 "{params {amount {frf 1234}}}" to indicate a precise amount in 229 French francs. A cost with amount(s) is usually transferred with 230 or before the initiation message if payment of an amount is 231 required. 233 transport: This is the URL to which the initial payment service 234 specific message should be sent. Normally this field occurs only 235 in the headers on the initiation message. For example 236 "{http://paycompany.com/paysys {params ... {transport 237 http://merchant.com:8000/buy}} ...}" or {http://cashco.com/cash 238 {params {transport mailto://mailorder@merchant.com}}}". 240 success: This is the URL to continue at after successful execution 241 of the payment protocol. Normally this field occurs only in the 242 headers on the initiation message. 244 failure: This is the URL to continue at after failure of the payment 245 protocol. Normally this field occurs only in the headers on the 246 initiation message. 248 cancel: This is the URL to continue at if the payment protocol is 249 cancelled. Normally this field occurs only in the headers on the 250 initiation message. 252 2.3 The Initiation Message 254 There is a sharp transistion from the shopping phase, which may 255 include payment system negotiation as above. This is usually 256 signalled by the MIME type of a message, typically 257 "application/paysys" where "paysys" is the name of the payment system 258 being invoked. With UPP, in principle this payment system specific 259 MIME type is not required as this message will also have a UPP header 260 demanding use of the UPP protocol. But it is better pracrice to use 261 the MIME type to ensure transition to the payment system without 262 relying on the other parties UPP capabilities. The exact form nad 263 body content of the initiation message depend on the payment system 264 and the transport medium that it is sent over. 266 In almost all cases, the shopping dialog between the customer and the 267 merchant will have resulted in the creation of an "order" and pricing 268 information. This order and pricing information is frequently only 269 present at the merchant or the customer as of the end of the shopping 270 dialog. For example, if the customer has been interacting via a 271 browser with a merchant's web service, the order (or shopping basket 272 or whatever other term you like) and price has been accumulated at 273 the merchant. If the customer has been interacting with a local CD- 274 ROM catalog or the like, then the order and pricing will have been 275 accumulated at the customer. The initiation message is sent from the 276 party with knowledge of the ordering information to the part without 277 that knowledge. In addition, the message can announce the available 278 combinations of payment services, payment types (credit, cash, etc.), 279 and the like if this has not been previously determined by UPP header 280 exchange. 282 The header of the initiation message will contain an instance of the 283 selected payment protocol requiring the other party to follow that 284 payment protocol or indicate an error. The body of the initiation 285 message will normally include the "order". This is the accumulated 286 description of the good and services that have been ordered. 288 In addition, the goods and services order (GSO) must ultimately be 289 cryptographically signed and compared in most payment protocols. To 290 this end, it is essential that the GSO be conveyed exactly because 291 the hash and signatures will not work if there is any change. 292 However, some payment systems have their own out of band solution to 293 this problem. 295 In email and World Wide Web transmissions, the content-transfer- 296 encoding field defines the encoding of the body of the message and 297 the content-type field defines the type. If the type of the body/GSO 298 is text/plain with sufficiently short lines, then the encoding may be 299 omitted. (It is recommended that any hashes calculated be on the 300 text with all whitespace ignored, but this is the realm of individual 301 payment protocols.) If the body/GSO is anything other than text/plain 302 or there is any question of it being corrupted by a gateway, then the 303 content-transfer-encoding should be be base64 to preserve the 304 integrity of the message. 306 However transmitted, the GSO need not be machine parsable and in fact 307 is simply a representation of the order for the records of the 308 customer and the vendor. It would normally contain a description of 309 the goods and/or services ordered and some information on delivery. 310 Except perhaps if the customer were some automated process, the order 311 should be easy for a person to understand. It might also include an 312 order number, dates, prices, and the like but these would not 313 generally be extractable from the order. For example, although text 314 would be more common, the order might be a synthesized digitized 315 voice reciting the information (this might be particularly useful for 316 a blind customer) or an image of a completed illustrated order form. 318 WARNING: Since the order is what the customer is buying as a matter 319 of record, it is essential that it be complete unto itself. External 320 references are invalid in the sense that they can not be depended on 321 later in showing what the order was. Thus an external MIME reference 322 is prohibited as the order (or as part of the order if it is 323 multipart), external references to images or otherwise are prohibited 324 if the order or part of a multipart order is type text/HTML, etc. 326 2.4 UPP Header and Message Integrity 328 Since one of the purposes of the UPP is to negotiate between payment 329 protocols, most of which have different security and signature 330 schemes, no explicit security is provided in the UPP. If security of 331 the UPP is desired, the customer and merchant need to communicate 332 inside some security enveloping, such as IPSEC, MOSS, SHTTP, PGP, or 333 SSL from the start. If such security is not used, a UPP relevant 334 field or message could be modified in flight or spoofed; however, 335 later steps within the payment protocol chosen will normally catch 336 such a problem, reducing it to more of an interference or denial of 337 service threat. 339 3. Examples 341 Three examples are given below. The first is a minimum UPP example 342 where neither party reveals much, the second is an example of a 343 richer basic UPP example including some use of the Profile protocol, 344 and the third is a relatively complex example illustrating the 345 effects of policy at the customer and vendor ends. 347 3.1 Minimal UPP Example 349 This is a web example with a minimum of negotiation and in which the 350 customer does not reveal anything about their identity. 352 ==================================== 353 GET /catalog 354 Protocol-request: {http://pep.w3.org/UPP} 356 Above the customer asks the merchant to give back catalog data and to 357 indicate whatever payment systems it will tell a putative stranger 358 about. 360 ==================================== 361 206 Uses PEP 362 Protocol-request: {http://cybercash.com/Pay {for /} }, 363 {http://gctec.com/GlobeID {params {affiliate Kleline Cyttybank 364 Mitsushami } {for /}} 366 The merchant's server indicates that it accepts 1. CyberCash for all 367 URLs 2. GlobeID protocol for all URLs, and, using GlobeID private 368 parameters, it is affiliated with the services operated in France by 369 Kleline S.A., in Japan by Mistushami and in the Netherlands by 370 Cyttybank. The body of this message would be the HTML catalog and the 371 customer would proceed to shop and the customer knows they can pay by 372 either Globe ID or CyberCash. 374 3.2 More Generous UPP Example 376 The GlobeID system has many parameters that it can securely certify 377 once one is in the proprietary payment system. In this example, many 378 of these are passed during PEP negotiation as "hints". 380 The price or amount is not included in this negotiation because the 381 knowledge or selection of other parameters is frequently required to 382 set this value (eg. custom duties, VAT, special discount when using a 383 given instrument, or special discount because the customer is buying 384 in the same shop for the third time in the same month and because 385 GCTech system tends to present the amount to be paid (not the price) 386 in the last step when everything is known in a certified way because 387 the offer is non-repudiable and notarized within the GlobeID system. 388 (This is only an example and it is possible to present a price to the 389 customer with PEP when payment is via GloveID. This is basicly up to 390 the merchant.) 392 ==================================== 393 GET /catalog 394 Protocol-request: {http://pep.w3.org/UPP} 396 the merchant response can be 398 ==================================== 399 206 Uses PEP 400 Protocol-request: {http://cybercash.com/Pay {for /} }, 401 {http://gctec.com/GlobeID {params {affiliate Kleline Cyttybank 402 Mitsushami } {amount} {b2b}} {http://pep.w3.org/Profile {params 403 {residence-country} {delivery-country} {str opt}} 404 Protocol: {http://pep.w3.org/Profile {params {language FR NL} {amount 405 {USD} {FRF} {NLG}} {residence-country {FR}} {delivery-country 406 "ANY"} }} 408 The merchant asks for a variety of identification information from 409 the customer, including the GlobeID proprietary b2b (business-to- 410 business) parameter. The merchant optionally asserts that it is 411 French, can delivery anywhere, and can accept payment in US dollars, 412 French francs, and Netherlands guilders. 414 Shopping proceeds and the customer eventually indicates how they will 415 pay via a message with the following headers: 417 ==================================== 418 POST /buy 419 Protocol: {http://gctec.com/GlobeID {params {affiliate Kleline} 420 {account (Cid) 1234567} {amount {FRF} {NLG} {b2b TRUE}} 421 {http://pep.w3.org/Profile {params {residence-country FR} 422 {delivery-country US}}} 424 The customer gives their GloveID CiD (account), affiliate, indicates 425 that this is a business to business transaction by a French resident 426 entity for delivery in the US with payment to be in French francs or 427 Netherlands guilders. 429 3.3 Complex UPP Example 431 This is a moderately complex example using both the UPP and Profile 432 protocols. Assume the Merchant has CyberCash, FooCharge, and SET for 433 AmEx installed but is only willing to process AmEx charges over $20. 435 Assume the Customer has SET for MasterCard and VISA which they only 436 use for charges over $10 but is their preferred method when 437 available, GlobeID which they use for hard goods, CyberCash persona 438 #3 which they only use for charges over $30 and FooCharge id #7 which 439 they only use for charges under $45. 441 Note that while these policies affect each parties requests and 442 responses, the policies as such never appear on the wire. 444 ==================================== 445 Get /catalog 446 Protocol-request: {http://aba.com/SET {params {account {MC} {VI} }}}, 447 {http://pep.w3.org/Profile {params {residence-country} {age}}{str 448 req}} 449 Protocol: {http://pep.w3.org/Profile {params {age 12}}} 451 The default strength is optional and the default scope is origin. 452 This is the initial request to the merchant to see their catalog. 453 Because SET is preferred by the customer, they offer it and they also 454 demand that the merchant state their country and age. The customer 455 also states that their age is 12. To avoid sending out the MC/VI 456 option in essentially every request, the customer might not do that 457 until they got a Protocol-request from the merchant optionally 458 specifying the UPP protocol.) 460 ==================================== 461 206 Uses PEP 462 Protocol-request: {http://cybercash.com/Pay {for /}}, 463 {http://foocharge.com/Pay {for /}}, {http://aba.com/SET {params 464 {acct {AX} }}}, {http://aba.com/SET {params {acct {MC} {VI}} {str 465 ref}}} 466 Protocol: {http://pep.w3.org/Profile {params {country bd} {age 69}}} 468 = HTML for catalog 470 The merchant indicates what payment systems it can accept and refuses 471 the one offered by the customer. In addition, it answers the 472 customer Profile demand. 474 =================================== 476 User asks to see summary of order... 478 ==================================== 479 206 Uses PEP 480 Protocol-request: {http://cybercash.com/Pay {params {amount {usd 33} 481 {bdr 4162}}}, {http://foocharge.com/Pay {params {amount {usd 35} 482 {bdr 4262} }}}, {http://aba.com/SET {params {account {AX}} {amount 483 {usd 34} {bdr 4200} }}}, {http://pep.w3.org/UPP {str req} {for 484 /Pay}} 486 = HTML - shopping cart contents 487 = amend-order-button cancel-button pay-button 489 When the user gets a page with a button/anchor on it the activation 490 of which indicates they are willing to pay, that page has all the 491 merchant available payment options that have not yet been refused by 492 the customer and demands the use of the UPP protocol in the response 493 if the response is to the URL indicating that the payment button has 494 been hit (/Pay in this case). 496 ==================================== 497 GET /Pay 498 Protocol-request: {http://cybercash.com/Pay {params {amount {usd 35} 499 }},{http://foocharge.com/Pay {params {amount {bdr 4262} }} 501 This is what happens with no user interaction at the customer and 502 circumstances such that more than one payment system would work. The 503 amount options may be narrowed to the most advantageous but otherwise 504 all the options are given back. More likely, the options would be 505 presented to the user who would, in this case choose between 506 CyberCash and foocharge or possibly cancelling. 508 ==================================== 509 206 Uses PEP 510 Protocol: {http://foocharge.com/Pay {params {amount {bdr 4262} } 511 {proprietary foo} {transport URL} {success URL} {Failure URL}}} 512 Content-type: application/foocharge 514 = body of message = = includes GSO = 516 4. Anticipated Effects of Universal Payment Preamble 518 While the introduction of yet another protocol has the potential to 519 further disrupt the progress in Internet payments, the Universal 520 Payment Preamble described here is intended to provide a minimal 521 layering that enables a customer to use a multipayment wallet and to 522 easily move from payment to payment. 524 Without a Universal Payment Preamble, shoppers and merchants will be 525 forced into dealing with a large number of relatively confusing 526 choices early in the purchasing process. The merchant must provide 527 multiple payment buttons (depending on protocol) and then handle each 528 separately. 530 This is not practical. Any form of impediment to the customer will 531 discourage a number of buyers. The introduction of the Universal 532 Payment Preamble allows merchants to shop for payment systems that 533 are appropriate to their customer base and needs. Adding payment 534 systems will be painless for the customer as only choices appropriate 535 to the customer need be displayed on the screen. 537 The long term effects of this approach will be to more effectively 538 allow different payment systems to compete in an open market. 540 5. Security Considerations 542 The Universal Payment Preamble provides no security features. 544 It is intended to segue into a payment protocol selected by the 545 customer and merchant and it is assumed that this payment protocol 546 will provide adequate security. If security of (1) the Universal 547 Payment Preamble headers/messages, (2) any dialog preceding those 548 messages, or (3) any fulfillment dialog after the payment protocol is 549 desired, then an appropriate channel or message security protocol 550 such as IPSEC, MOSS, SHTTP, PGP, SSL, etc. should be used. 552 References 554 draft-khare-pep-*.txt 556 [RFC 1898] - CyberCash 558 [RFC 1521] - N. Borenstein, N. Freed, "MIME (Multipurpose Internet 559 Mail Extensions) Part One: Mechanisms for Specifying and Describing 560 the Format of Internet Message Bodies", 09/23/1993. 562 [RFC 1522] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 563 Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993. 565 [PGP] 567 [SET] 569 Author's Address 571 Donald E. Eastlake 3rd 572 CyberCash, Inc. 573 318 Acton Street 574 Carlisle, MA 01741 USA 576 Telephone: +1 508-287-4877 577 +1 508-371-7148 (fax) 578 +1 703 620-4200 (main office, Reston, Virginia, USA) 579 email: dee@cybercash.com 581 Expiration and File Name 583 This draft expires 14 September 1996. 585 Its file name is draft-eastlake-universal-payment-02.txt. 587 Appendix A: Card Brands 589 [The world is more complex than indicated below. For example, 590 although any VISA card issued outside of Brazil can be used inside 591 Brazil and vice versa, there are three different varieties of VISA 592 card within Brazil each of which may only be used within Brazil by 593 merchants approved to take that VISA subtype...] 595 Since there is no standard code for Major International card brands 596 (cards with numbers as defined in ISO xxxx), the following codes are 597 adopted for use in UPP headers account-type bag field. Additional 598 codes may be registered with IANA. 600 Code Long Name 602 AX American Express 603 DC Diner's Club 604 DS Discover 605 JB Japan Bank Card 606 MC MasterCard 607 VI VISA