INTERNET-DRAFT Donald E. Eastlake 3rd
Expires: 27 February 1997 CyberCash
28 August 1996
Universal Payment Preamble
--------- ------- --------
Status of This Document
This draft, file name draft-eastlake-universal-payment-02y.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 <ietf-pay@imc.com> and <jepi@commerce.net> mailing lists.
INTERNET-DRAFT Universal Payment Preamble 28 August 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 or
abandonment of all of these protocols.
A header syntax is presented for parties to negotiate payment
alternatives at any point in shopping, until a final hand-off to a
particular chosen payment system.
Acknowledgements
The contributions of the following persons to this draft are
gratefully acknowledged:
Ali Bahreman <ali@eit.com>
Brian Boesch <boesch@cybercash.com>
Randy Bush <randy@psg.com>
Steve Crocker <crocker@cybercash.com>
Rohit Khare <khare@w3.org>
Pieter van der Linden <vdl@GCTech.fr>
Bill Melton <melton@cybercash.com>
Jim Miller <jmiller@w3.org>
Paul-Andre Pays <pays@gctech.edelweb.fr>
Table of Contents
[Table of Contents gets moved here from the end]
Donald Eastlake 3rd [Page 3]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 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-HTPP, PGP, and
SSL. Some people use such general secure channel or secure message
systems for payments. Such protocols help protect privacy but 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.
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
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
Donald Eastlake 3rd [Page 4]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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 28 August 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 others may 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 proprietary
protocol that starts at the end of the negotiation phase. Payment
security is attained to the extent it is provided by this proprietary
protocol.
Donald Eastlake 3rd [Page 6]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
2.2 The UPP Protocol
As with an PEP based protocol, UPP negoations 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 will
be generated. If any particular payment system is installed, it MAY
generate a Protocol-Info response.
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.
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 knwon 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.
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 ususally has a MIME type (such as application/cybercash)
specified to select the desired payment system.
Donald Eastlake 3rd [Page 7]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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. 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
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}}}".
type: This is the type of payment. Values incude Credit, Debit,
Check, cash, etc.
2.4 The Initiation Message
There is a sharp transistion from the shopping phase, which may
include payment system negotiation as above. This is usually
Donald Eastlake 3rd [Page 8]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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 at the merchant or 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 may 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 in most payment 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
Donald Eastlake 3rd [Page 9]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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
such a problem, reducing it to an interference or denial of service
threat rather than an actual compromise of funds.
Donald Eastlake 3rd [Page 10]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 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 "pay" 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://cybercash.com/coin {for /*}},
{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 {via http://cybercash.com/coin }},
{http://cybercash.com/coin {params {persona "Anonymous"}}}
= posted form data
====================================
200 OK
Content-Type: application/cybercash
Protocol: {http://w3.org/UPP {params {success /worked} {failure
/didnt} {cancel /incomplete}}}
=message body probably containing order description
3.2 More Extensive UPP Example
1) Customer asks vendor for payment options and mentions a payment
system the customer has.
Donald Eastlake 3rd [Page 11]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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 "pay" button hit.
6) Customer hits "pay" 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 {params {type
checking}}}
====================================
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 {via http://pep.CashMach.com/e$ }},
{http://pep.CashMach.com/e$ {params {amount {usd 11.00}} {account
7312} {persona "Anonymous"}}}
= posted form data
====================================
200 OK
Content-Type: application/x-e$
Protocol: {http://w3.org/UPP {params {success /worked} {failure
/didnt} {cancel /incomplete}}}
=message body probably containing order description
Donald Eastlake 3rd [Page 12]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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 "pay" button and sends alternate payment details.
5) Alternate payment fails.
6) Customer tries again with known acceptable payment details.
7) Merchant initiates proprietary portion of selected system.
====================================
206 Uses PEP
Content-Type: text/html
Protocol-Query: {http://w3.org/UPP}
Protocol-Info {http://cybercash.com/credit {for /*} {params {brand
visa mastercard}}}, {http://cybercash.com/credit {for /*} {params
{brand discover}}{str ref}}, {http://gctec.com/GlobeID {params
{affiliate Kleline Cyttybank Mitsushami} {for /*} {amount {usd}
{frf} {nlg}}}
=content
====================================
Protocol-Info: {http://w3.org/UPP}, {http://cybercash.com/credit
{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-request: {http://cybercash.com/Pay {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} }}}, {http://pep.w3.org/UPP {str req} {for
/Pay} {params {type 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
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).
====================================
Donald Eastlake 3rd [Page 13]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
GET /Pay
Protocol-request: {http://cybercash.com/Pay {params {amount {usd 35}
}},{http://foocharge.com/Pay {params {amount {bdr 4262} }}
This is what happens with no user interaction at the customer and
circumstances such that more than one payment system would work. The
amount options may be narrowed to the most advantageous but otherwise
all the options are given back. More likely, the options would be
presented to the user who would, in this case choose between
CyberCash and foocharge or possibly cancelling.
====================================
206 Uses PEP
Protocol: {http://foocharge.com/Pay {params {amount {bdr 4262} }
{proprietary foo} {transport URL} {success URL} {Failure URL}}}
Content-type: application/foocharge
= body of message = = includes OD =
Donald Eastlake 3rd [Page 14]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 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 15]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 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-10.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.
[PEP]
[PGP]
[SET]
Donald Eastlake 3rd [Page 16]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 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 27 February 1997.
Its file name is draft-eastlake-universal-payment-02y.txt.
Donald Eastlake 3rd [Page 17]
*
INTERNET-DRAFT Universal Payment Preamble 28 August 1996
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:............................................7
2.3 UPP Defined Payment Negotiation Parameters............8
2.4 The Initiation Message.................................8
2.5 UPP Header and Message Integrity......................10
3. Examples...............................................11
3.1 Minimal UPP Example...................................11
3.2 More Extensive UPP Example............................11
3.3 Final UPP Example.....................................13
4. Anticipated Effects of Universal Payment Preamble......15
5. Security Considerations................................16
References................................................16
Author's Address..........................................17
Expiration and File Name..................................17