Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_d_h/draft-eastlake-universal-payment-03.txt

Text File | 1996-10-29 | 32KB | 1,045 lines

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 <[e-mail]> and <[e-mail]> 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 <[e-mail]>
      Brian Boesch <[e-mail]>
      Randy Bush <[e-mail]>
      Steve Crocker <[e-mail]>
      Rohit Khare <[e-mail]>
      Mark Linehan <[e-mail]>
      Pieter van der Linden <[e-mail]>
      Bill Melton <[e-mail]>
      Jim Miller <[e-mail]>
      Paul-Andre Pays <[e-mail]>




















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://[e-mail]}}}".



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:   [phone]
                [phone] (fax)
                [phone] (main office, Reston, Virginia, USA)
   email:       [e-mail]



Expiration and File Name

   This draft expires 30 April 1997.

   Its file name is draft-eastlake-universal-payment-03.txt.