INTERNET-DRAFT Donald E. Eastlake 3rd Expires: 30 April 1997 CyberCash 31 October 1996 Universal Payment Preamble --------- ------- -------- Status of This Document This draft, file name draft-eastlake-universal-payment-03.txt, is intended to be become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the author or to the and mailing lists. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Donald Eastlake 3rd [Page 1] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 Abstract The Internet is becoming an increasingly commercial arena in which payments are rendered for goods, information, and services. To support such commerce, various incompatible Internet payment protocols have been proposed or adopted by a variety of organizations. There appears to be little prospect of merger of all or abandonment of most of these protocols. A header syntax, the Universal Payment Preamble (UPP), is presented for parties to negotiate payment alternatives at any point in shopping, until a final hand-off to a particular chosen payment system. The chosen payment system, not UPP, is responsible for the security of any actual transmission of funds. Acknowledgements The contributions of the following persons to this draft are gratefully acknowledged: Ali Bahreman Brian Boesch Randy Bush Steve Crocker Rohit Khare Mark Linehan Pieter van der Linden Bill Melton Jim Miller Paul-Andre Pays Donald Eastlake 3rd [Page 2] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................4 1.1 The Universal Payment Preamble Solution................4 2. The Universal Payment Preamble..........................6 2.1. The Universal Payment PEP Headers.....................6 2.2 The UPP Protocol......................................7 2.2.1 Protocol-Query:......................................7 2.2.2 Protocol-Info:.......................................7 2.2.3 Protocol-Request:....................................7 2.2.4 Protocol:............................................8 2.3 UPP Defined Payment Negotiation Parameters............8 2.4 The Initiation Message.................................9 2.5 UPP Header and Message Integrity......................10 3. Examples...............................................12 3.1 Minimal UPP Example...................................12 3.2 More Extensive UPP Example............................13 3.3 Final UPP Example.....................................14 4. Anticipated Effects of Universal Payment Preamble......16 5. Security Considerations................................17 References................................................17 Author's Address..........................................18 Expiration and File Name..................................18 Donald Eastlake 3rd [Page 3] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 1. Introduction The Internet is becoming an increasingly commercial arena in which payments are rendered for goods, information, and services. This commerce can take a variety of forms from interacting with a vendor via a World Wide Web browser to ordering by email from a CD-ROM catalog. Typically the shopping or selection phase is followed by a payment phase and then usually by a fulfillment or delivery phase. To provide general privacy and security to all three phases, there are a variety of protocols, such as MOSS, IPSEC, S-HTTP, PGP, and SSL. Some people use such general secure channel or secure message systems for payments. However, while such protocols help protect privacy, they do not meet all the needs of payment. The payments phase is especially sensitive because it deals with "real money", thus providing a strong incentive to crackers, and is also complex. Frequently payment involves three or more parties such as a customer, merchant, and bank or payment system, with structured and interlocking messages that incorporate fields best encrypted for parties other than their initial recipient. For these reasons a number of specialized payment protocols have been adopted. As examples of payment protocols, there is the SET standard being developed by MasterCard and VISA [SET], the CyberCash system [RFC 1898], GCtech's GlodeID, CMU's NetBill, First Virtual [FV] and many more. The Universal Payment Preamble provides two capabilities: payment service negotiation and initiation of the specific payment system. The payment service and initiation information are sufficient to smoothly bridge from shopping to payment and, if appropriate, from payment back to other customer - vendor interaction. It is the specific payment system invoked, and not UPP, that is responsible for the secure transmission of funds. UPP is built on PEP, the Protocol Extension Protocol. The reader is assumed to understand PEP as documented in draft-ietf-http-pep-*.txt. 1.1 The Universal Payment Preamble Solution A high level overview of the Universal Payment Preamble solution to this problem is as follows: Shopping proceeds in a free-form way constrained only by the desires of the customer and vendor. UPP information may be exchanged before or during the shopping Donald Eastlake 3rd [Page 4] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 process as well as at the end. This might be done so the customer is assured they can pay by a means they want to use or so that a merchant can condition their offer based on information about the payment system(s) installed at the customer. After the order has been decided, the definitive order and remaining payment options are transmitted from the party knowing them to the other in a initiation message. The party receiving this message chooses the payment option (in general choosing transport, payment protocol, payment instrument, etc. to the extent these have not been decided by earlier negotiation) and proceeds using the selected payment system if any of those presented are acceptable. Donald Eastlake 3rd [Page 5] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 2. The Universal Payment Preamble The Universal Payment Preamble is so called because it exchanges information that needs to be resolved before a particular payment system is entered and provides an initiation message to enter the payment protocol. Information is exchanged using the Protocol Extension Protocol [draft-ietf-http-pep-*.txt] headers. Familiarity with PEP is assumed in this draft. 2.1. The Universal Payment PEP Headers UPP views the world as consisting of some set of payment protocols installed with the consumer software and a possibly different set of payment protocols installed at the vendor. Some payment protocols provide only one kind of payment but most provide for various payment instruments (such as bank cards or accounts) and/or various currencies including the possibility of specialized currencies such as "frequent flyer miles". Each payment system is considered to be a PEP protocol extension, identified by a URL, and in addition there exists the http://w3.org/UPP protocol and a module implementing it. Each payment system installed at a customer or vendor site must register itself with the UPP module at that site. The UPP module registers with the PEP level to handle the umbrella UPP protocol and also registers to handle any payment protocol that registers with it. (This may actually be implemented by a combined PEP/UPP level of software.) UPP headers can be exchanged before or during shopping to narrow the field of payment methods. This could help gain some assurance that there is some acceptable method available or to provide special offers or otherwise condition the shopping experience based on available payment methods. This will occur via PEP headers using the payment system and UPP protocols. Each individual payment service will have a proprietary protocol compatible with the "generic" UPP Protocol. Compatibility is largely defined by the parameters defined in section 2.3 below that lists the names of common parameters and the encoding to be used for their values. In addition, it implies an agreement about a "style" of negotiation: the payee agrees not to take irrevocable action based solely on the use of the UPP and specific payment protocol negotiation headers. Rather, it takes place in the specific payment protocol that starts at the end of the negotiation phase. Payment security is attained to the extent it is provided by this payment protocol. Donald Eastlake 3rd [Page 6] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 2.2 The UPP Protocol As with any PEP based protocol, UPP negotiations occur via exchange of the four PEP headers as described below. 2.2.1 Protocol-Query: A Protocol-Query header for the UPP protocol is used to determine if the other party has UPP available and what payment systems are installed. If UPP is available, then a Protocol-Info response MUST be generated. If any particular payment system is installed, it MAY generate a Protocol-Info response. Example: Protocol-query: {http://w3.org/UPP {for /*}} 2.2.2 Protocol-Info: The Protocol-Info request is used to reply to Protocol-Query's and to volunteer information. In a message replying to a Protocol-Query for protocol UPP, the UPP will appear in a Protocol-Info header. Other Protocol-Info header content for payment negotiation will specify particular payment protocols and can either be information being spontaneously sent by the payment system or information replying to a Protocol-Query for the UPP protocol or for that payment protocol. Example, spontaneous offer of payment system info: Protocol-info: {http://payment.com/psys {for /*} {params {proprietary value}}} Example, response to UPP protocol query: Protocol-info: {http://w3.org/UPP {via http://payment.com/psys}}, {http://payment.com/psys {for /*} {params {proprietary value}}} 2.2.3 Protocol-Request: The server demands payment by requesting 'UPP, strength=required.' This forces the client to respond with a complete payment initiator (i.e. with all known required parameters for chosen payment system(s) filled in). If the negotiation process has not narrowed down to a single payment system, the browser/UPP module may pop up a notification toolbar or automatically choose, possibly based on a profile or rules established by the user. Donald Eastlake 3rd [Page 7] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 Example: Protocol-request: {http://w3.org/UPP {str req} {for /pay- button}} 2.2.4 Protocol: A Protocol header with a payment protocol specified occurs only in the initiation message that transitions to that payment system. There MUST also be a Protocol header entry for the UPP protocol with a {via ...} bag specifying the specific protocol actually used. This message also has a MIME type (such as application/cybercash) specified to select the desired payment system. Example: Protocol: {http://payment.com/psys {params {transport http://paymentserver.com} {proprietary value}}} 2.3 UPP Defined Payment Negotiation Parameters The following PEP parameters, if they appear in a params bag for a payment system, have the form and meaning indicated. They are listed in alphabetic order. account: This parameter is used to provide information about the account number to be used at the customer or merchant. Usually this number is meaningful only for the particular payment system amount: This is the cost of the order as one payment. It consists of a list of bags with the ISO 4217 currency code as the first item and optionally an amount as the second. Each amount is an alternative for the entire order. For example "{params ... {amount {usd} {gbp}} ...}" to indicate that US dollars and pounds Sterling are acceptable (vendor) or providable (customer) or "{params {amount {frf 1234}}}" to indicate a precise amount in French francs. brand: The BrandID field format from SET will be used for cards. This consists of either a simple brand, such as "MasterCard" or a brand, a colon, and a product type, such as "Visa:Gold". cancel: This is the URL to continue at if the payment protocol is cancelled. Normally this field occurs only in the headers on the initiation message. failure: This is the URL to continue at after failure of the payment protocol. Normally this field occurs only in the headers on the Donald Eastlake 3rd [Page 8] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 initiation message. success: This is the URL to continue at after successful execution of the payment protocol. Normally this field occurs only in the headers on the initiation message. transport: This is the URL to which the initial payment service specific message should be sent. Normally this field occurs only in the headers on the initiation message. For example "{http://paycompany.com/paysys {params ... {transport http://merchant.com:8000/buy}} ...}" or {http://cashco.com/cash {params {transport mailto://mailorder@merchant.com}}}". 2.4 The Initiation Message There is a sharp transition from the shopping phase, which may include payment system negotiation as above. This is signalled by the MIME type of a message, typically "application/paysys" where "paysys" is the name of the payment system being invoked. The exact form and body content of the initiation message depend on the payment system and the transport medium that it is sent over. In almost all cases, the shopping dialog between the customer and the merchant will have resulted in the creation of an "order" and pricing information. This order and pricing information is frequently only present and understood at the merchant or at the customer as of the end of the shopping dialog. For example, if the customer has been interacting via a browser with a merchant's web service, the order (or shopping basket or whatever other term you like) and price has been accumulated at the merchant. If the customer has been interacting with a local CD-ROM catalog or the like, then the order and pricing will have been accumulated at the customer. The initiation message is sent from the party with knowledge of the ordering information to the part without that knowledge. In addition, through UPP, the message can announce the remaining available combinations of payment services, payment types (credit, cash, etc.), and the like if this has not been previously determined by UPP header exchange. The headers of the initiation message should contain an instance of the selected payment protocol requiring the other party to follow that payment protocol or indicate an error. The body of the initiation message will normally include the "order". This is the accumulated description of the good and services that have been ordered. In addition, the order description must ultimately be cryptographically signed and compared for security in most payment Donald Eastlake 3rd [Page 9] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 protocols. To this end, it is essential that the OD be conveyed exactly because the hash and signatures will not work if there is any change. Some payment systems have their own out of band solution to this problem. In email and World Wide Web transmissions, the content-transfer- encoding field defines the encoding of the body of the message and the content-type field defines the type. If the type of the body/OD is text/plain with sufficiently short lines, then the encoding may be omitted. (It is recommended that any hashes calculated be on the text with all whitespace ignored, but this is the realm of individual payment protocols.) If the body/OD is anything other than text/plain or there is any question of it being corrupted by a gateway, then the content-transfer-encoding should be be base64 to preserve the integrity of the message. However transmitted, the OD need not be machine parsable and in fact is simply a representation of the order for the records of the customer and the vendor. It would normally contain a description of the goods, information, and/or services ordered and some information on delivery. Except perhaps if the customer were some automated process, the order should be easy for a person to understand. It might also include an order number, dates, prices, and the like but these would not generally be extractable from the order. For example, although text would be more common, the order might be a synthesized digitized voice reciting the information (this might be particularly useful for a blind customer) or an image of a completed illustrated order form. WARNING: Since the order description is what the customer is buying as a matter of record, it is important that it be complete unto itself. External references are invalid in the sense that they can not be depended on later in showing what the order was. Thus an external MIME reference is prohibited as the order (or as part of the order if it is multipart), external references to images or otherwise are prohibited if the order or part of a multipart order is type text/HTML, etc. 2.5 UPP Header and Message Integrity Since one of the purposes of the UPP is to negotiate between payment protocols, most of which have very different security and signature schemes, no explicit security is provided in the UPP. If security of the UPP is desired, the customer and merchant need to communicate inside some security enveloping, such as IPSEC, MOSS, SHTTP, PGP, or SSL from the start. If such security is not used, a UPP relevant field or message could be modified in flight or spoofed; however, later steps within the payment protocol chosen will normally catch Donald Eastlake 3rd [Page 10] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 such a problem, reducing it to an interference or denial of service threat rather than an actual compromise of funds. Donald Eastlake 3rd [Page 11] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 3. Examples Three examples are given below. The first is a minimum UPP example where neither party reveals much, the second is an example of a richer basic UPP example including some use of the Profile protocol, and the third is a relatively complex example illustrating the effects of policy at the customer and vendor ends. 3.1 Minimal UPP Example This is a web example with a minimum of negotiation. 1) Merchant sends payment options with pay page. 2) Customer hits RpayS button and sends payment details. 3) Merchant initiates proprietary portion of selected system. ==================================== 220 Uses Protocol Extensions Content-Type: text/html Protocol-Request: {http://w3.org/UPP {str req} {for /PayButton}} Protocol-Info: {http://www.cybercash.com/UPP {for /*} {params {accepts coin}}}, {http://gctech.com/globeid {for /*}}, =catalog The merchant's server indicates that it accepts: 1. CyberCoin for all URLs 2. GlobeID protocol for all URLs. The body of this message would be the HTML catalog and the customer would proceed to shop and the customer knows they can pay by either Globe ID or CyberCash. ==================================== POST /PayButton HTTP/1.1 Protocol: {http://w3.org/UPP {params {via http://www.cybercash.com/coin} }}, {http://www.cybercash.com/UPP {params {persona RAnonymousS}}} = posted form data ==================================== 200 OK Content-Type: application/cybercash Protocol: {http://www.cybercash.com/UPP {params {success /worked} {failure /didnt} {cancel /incomplete}}} =message body probably containing order description Donald Eastlake 3rd [Page 12] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 3.2 More Extensive UPP Example 1) Customer asks vendor for payment options and mentions a payment system the customer has. 2) Vendor responds with payment options and refuses the one mentioned by customer. 3) ...shopping... 4) Customer asks for shopping cart display. 5) Merchant extends shopping cart message with payment systems, costs, and demand for payment if RpayS button hit. 6) Customer hits RpayS button and sends payment details. 7) Merchant initiates proprietary portion of selected system. ==================================== GET /Catalog HTTP/1.1 Protocol-Query: {http://w3.org/UPP {for /*} }, Protocol-Info: {http://LocalBank.com/DebitCard2.1} ==================================== 220 Uses Protocol Extensions Content-Type: text/html Protocol-Info: {http://www.CreditCentral.com/TypeF {for /*}}, {http://pep.CashMach.com/e$ {params {cost {usd} {jpy}}} {for /*}}, {http://LocalBank.com/DebitCard2.1{str ref}{for /*}} =catalog= Shopping proceeds and the customer eventually gets their shopping card / invoice. ==================================== 220 Uses Protocol Extensions Content-Type: text/html Protocol-Request: {http://w3.org/UPP {str req} {for /PayButton}} Protocol-Info: {http://pep.CashMach.com/e$ {params {amount {usd 11.00} {jpy 1200.}}} {for /PayButton}}, {http://www.CreditCentral.com/TypeF {params {amount {cad 15.07} {usd 11.42}}{merchant 6699}} {for /PayButton}} =display of shopping cart as an html form ==================================== POST /PayButton HTTP/1.1 Protocol: {http://w3.org/UPP {params {via http://pep.CashMach.com/e$} }}, {http://pep.CashMach.com/e$ {params {amount {usd 11.00}} {account 7312} {persona RAnonymousS}}} = posted form data ==================================== 200 OK Content-Type: application/x-e$ Protocol: {http://w3.org/UPP {params {success /worked} {failure Donald Eastlake 3rd [Page 13] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 /didnt} {cancel /incomplete}}} =message body probably containing order description 3.3 Final UPP Example 1) Vendor asks customer for payment options and volunteers some. 2) Customer responds with payment options. 3) ...shopping..., ...ask for shopping cart.., 4) Customer hits RpayS button and sends alternate payment details. 5) Alternate payment fails. 6) Customer tries again with known acceptable payment details. 7) Merchant initiates payment system specific portion of selected system. ==================================== 206 Uses PEP Content-Type: text/html Protocol-Query: {http://w3.org/UPP} Protocol-Info: {http://www.cybercash.com/UPP {for /*} {params {brand visa mastercard}}}, {http://www.cybercash.com/UPP {for /*} {params {brand discover}}{str ref}}, {http://gctec.com/GlobeID {params {affiliate Kleline Cyttybank Mitsushami} {for /*} {amount {usd} {frf} {nlg}} }} =content ==================================== GET ... Protocol-Info: {http://w3.org/UPP}, {http://www.cybercash.com/UPP {params {version 0.9.3}}} ask for shopping cart get shopping cart form extended to require payment when pay button hit ==================================== 206 Uses PEP Protocol-info: {http://www.cybercash.com/UPP {params {amount {usd 33} {bdr 4162}} }}, {http://foocharge.com/Pay {params {amount {usd 35} {bdr 4262}} }}, {http://aba.com/SET {params {account {AX}} {amount {usd 34} {bdr 4200}} }} Protocol-request: {http://w3.org/UPP {str req} {for /Pay}} = HTML - shopping cart contents = amend-order-button cancel-button pay-button When the user gets a page with a button/anchor on it, the activation Donald Eastlake 3rd [Page 14] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 of which indicates they are willing to pay, that page has all the merchant available payment options that have not yet been refused by the customer and demands the use of the UPP protocol in the response if the response is to the URL indicating that the payment button has been hit (/Pay in this case). ==================================== POST /Pay HTTP 1.1 Protocol: {http://w3.org/UPP {params {via http://foocharge.com/Pay} }}, {http://foocharge.com/Pay {params {amount {bdr 4262}} }} User tries a new payment system not previous mentioned. ==================================== 206 Uses PEP Protocol: {http://foocharge.com/Pay {str ref}} Protocol-request: {http://w3.org/UPP {str req} {for /Pay}} Protocol-info: {http://www.cybercash.com/UPP {params {amount {usd 33} {bdr 4162}} }}, {http://foocharge.com/Pay {params {amount {usd 35} {bdr 4262}} }}, {http://aba.com/SET {params {account {AX}} {amount {usd 34} {bdr 4200}} }} = HTML - shopping cart contents = amend-order-button cancel-button pay-button Merchant rejects new payment system tried by customer and re-iterates choices it knows about and its demand for payment if the pay button is clicked. ==================================== POST /Pay HTTP 1.1 Protocol: {http://w3.org/UPP {params {via http://www.cybercash.com/UPP} }}, {http://www.cybercash.com/UPP {params {brand visa} {amount {bdr 4162}} }} User tries a different know acceptable payment system. ==================================== 206 Uses PEP Protocol: {http://www.cybercash.com/UPP {params {amount {bdr 4162} } {proprietary foo} {transport URL} {success URL} {Failure URL}}} Content-type: application/cybercash = body of message = = includes OD = Donald Eastlake 3rd [Page 15] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 4. Anticipated Effects of Universal Payment Preamble While the introduction of yet another protocol has the potential to further disrupt the progress in Internet payments, the Universal Payment Preamble described here is intended to provide a minimal layering that enables a customer to use a multipayment wallet and to easily move from payment to payment. Without a Universal Payment Preamble, shoppers and merchants will be forced into dealing with a large number of relatively confusing choices early in the purchasing process. The merchant must provide multiple payment buttons (depending on protocol) and then handle each separately. This is not practical. Any form of impediment to the customer will discourage a number of buyers. The introduction of the Universal Payment Preamble allows merchants to shop for payment systems that are appropriate to their customer base and needs. Adding payment systems will be painless for the customer as only choices appropriate to the customer need be displayed on the screen. The long term effects of this approach will be to more effectively allow different payment systems to compete in an open market. Donald Eastlake 3rd [Page 16] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 5. Security Considerations The Universal Payment Preamble provides no security features. It is intended to segue into a payment protocol selected by the customer and merchant and it is assumed that this payment protocol will provide adequate security. If security of (1) the Universal Payment Preamble headers/messages, (2) any dialog preceding or mixed with those messages, or (3) any fulfillment dialog after the payment protocol, is desired, then an appropriate channel or message security protocol such as IPSEC, MOSS, SHTTP, PGP, SSL, etc. should be used. References draft-ietf-http-pep-00.txt [RFC 1898] - CyberCash [RFC 1521] - N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 09/23/1993. [RFC 1522] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993. [PGP] [SET] Donald Eastlake 3rd [Page 17] INTERNET-DRAFT Universal Payment Preamble 31 October 1996 Author's Address Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508-287-4877 +1 508-371-7148 (fax) +1 703 620-4200 (main office, Reston, Virginia, USA) email: dee@cybercash.com Expiration and File Name This draft expires 30 April 1997. Its file name is draft-eastlake-universal-payment-03.txt.