INTERNET-DRAFT Donald E. Eastlake 3rd
CyberCash
Expires: 13 April 1996 Brian Boesch
CyberCash
14 October 1995
Universal Payment Protocol
--------- ------- --------
Status of This Document
This draft, file name draft-eastlake-universal-payment-00.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the author
<dee@cybercash.com> or the ietf-payments@cc.bellcore.com mailing
list.
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, ftp.isi.edu, nic.nordu.net,
ftp.nis.garr.it, munnari.oz.au, or ftp.is.co.za.
Eastlake, Boesch [Page 1]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
Abstract
The Internet is becoming an increasingly commercial arena in which
payments are rendered for goods and services. To support such
commerce, numerous incompatible Internet payment protocols have been
adopted by a variety of organizations. There appears to be little
prospect of merger or abandonment of all of these protocols, none of
which is currently under the change control of the IETF or any other
standards body.
A universal payment protocol is proposed whereby parties can choose
between this babble of alternatives.
Acknowledgements
The contributions of the following persons to this draft are
gratefully acknowledged:
Steve Crocker <crocker@cybercash.com>
Bill Melton <melton@cybercash.com>
Eastlake, Boesch [Page 2]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 Protocol Wars..........................................4
1.2 Freedom to Shop........................................5
1.3 The Universal Payment Protocol Solution................5
2. The Universal-Payment Protocol..........................6
2.1. The Universal-Payment Message.........................6
2.1.1 Universal-Payment Formats............................6
2.1.2. Definition of Acceptable Field Values...............8
2.1.3 Transport of Universal-Payment Via HTTP..............8
2.1.4 Transport of Universal-Payment Via email.............9
2.2 The Turn-Around Message...............................10
3. Anticipated Effects of Universal Payment Protocol......11
4. Potential Long Term Issues.............................12
5. Security Considerations................................13
References................................................13
Author's Address..........................................13
Expiration and File Name..................................14
Eastlake, Boesch [Page 3]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
1. Introduction
Note: This draft does not necessarily reflect either a CyberCash
corporate position or a description of any existing CyberCash
product.
The Internet is becoming an increasingly commercial arena in which
payments are rendered for goods and services. This commerce can take
a variety of forms from shopping interactively with a World Wide Web
browser to ordering by email from a CD-ROM catalog. Typically the
shopping phase is followed by a payment phase and then sometimes by a
fulfillment or delivery phase.
To provide general privacy and security to all three phases, there
are a variety of IETF standardized protocols, such as MOSS or IPSEC,
and protocols not under the control of any standards body, such as
PGP, SSL, or PCT. Some people use such general secure channel or
secure message systems for payments. However, the payments phase is
especially sensitive due to dealing with "real money", thus providing
a strong incentive to crackers, and is also especially complex,
frequently involving three parties such as a customer, merchant, and
bank, 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.
1.1 Protocol Wars
Note: "The best thing about standards is that there are so many to
choose from."
As examples of payment protocols, MicroSoft (which controls the
operating system of about 80% of the computers in the world) and VISA
(the largest bankcard association) recently announced STT and
Netscape (which controls the web browser of about 80% of the web
users in the world) and MasterCard (the 2nd largest bankcard
association) announced SEPP. Although both have some hopes of
agreeing on a common protocol, these two systems are completely
incompatible with each other and each is completely incompatible with
every existing deployed system such as First Virtual or CyberCash.
And there are numerous other systems and proposals, such as CMU's
NetBill, a proposed service by VeriFone, and many more.
All of the above mentioned protocols, even those which have been
proposed as IETF standards, are currently under the exclusive control
of their authors and none is even before an IETF Working Group.
Eastlake, Boesch [Page 4]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
1.2 Freedom to Shop
Some of the most prominent proposals seem designed to move the
customer's decision as to payment system as early as possible. STT
urges that STT proprietary credentials be used from the very start of
any customer to merchant communications. Such a strategy is
understandable as, from the point of view of a proponent of one the
these systems, it is desirable to get the earliest possible lock-in.
But this is not what people do in real life and not what they want to
do on the Internet. People want to shop and browse without
commitment and then select among the alternative payment means after
they have selected their purchase and are generally satisfied with
the price and terms.
True, if they want privacy in shopping, they need to have a secure
channel to the merchant. But the apparent bindings between secure
channel technology and payment systems is false. There is no good
reason someone could not speak the MasterCard SEPP protocol over a
MicroSoft PCT channel or send CyberCash messages over SSL channels.
1.3 The Universal Payment Protocol Solution
A high level overview of the Universal Payment Protocol solution to
this problem is as follows:
Shopping proceeds in a completely free-form way constrained only by
the desires of the customer and merchant. After the order has been
decided on, the definitive order and payment options are transmitted
from the party knowing them to the other. The party receiving this
message chooses the payment option (in general choosing transport
protocol, payment system, payment type, etc.) and proceeds using the
selected payment system, if any of those presented are acceptable.
Eastlake, Boesch [Page 5]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
2. The Universal-Payment Protocol
The Universal-Payment Protocol consists of two message, the
Universal-Payment Message and the Turn-Around message which are
described below.
Normally only the Universal-Payment Message is required and the
recipient of the Universal-Payment message can then initiate the
payment system they selected from the options list in that message.
However, should the selected payment system require that the party
sending the Universal-Payment message also send the first message in
the selected payment system, the receiver of the Universal-Payment
message can use the Turn-Around message to prompt the sender to start
the payment system message sequence.
2.1. The Universal-Payment Message
The Universal-Payment message has three purposes, (1) payment system
independent mutual knowledge of order information at both the
customer and merchant, (2) a smooth transition from whatever shopping
dialog the customer engaged in to a specific payment system over a
particular transport, and (3) a smooth transition back to any
subsequent fulfillment dialog.
In almost all cases, the shopping dialog between the customer and the
merchant will have resulted in the the creation of an "order" and
pricing information. This order and pricing information is normally
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 Universal-Payment
message is then sent from the party with knowledge of the ordering
information to the part without that knowledge. In addition, the
message announces the available combinations of payment systems,
payment messages transport protocols, payment types (credit, cash,
etc.), and the like.
2.1.1 Universal-Payment Formats
On necessity, the exact form of the Universal-Payment message (UPM)
must depend on the transport medium that it is sent over. However,
in all cases, it contains the order and payment information. It may
optionally contain expiration and/or continuation information.
Eastlake, Boesch [Page 6]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
order: This is the accumulated description of the good and services
that have been ordered.
In several protocols, there is a need to convey the Goods and
Service (GSO) order, out of band to the actual protocol. The order
in the UPM is intended to provide a primary and unambiguous
transport for this information.
In addition, the GSO must be cryptographically signed and compared
in most of these protocols. To this end, it is essential that the
GSO be conveyed exactly as the hash and signatures will not work
if there is any change.
In email and World Wide Web tranmissions, the content-trasnsfer-
encoding field defines the encoding of the body of the message and
the content-type field defines the type. If the type of the GSO 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 ignore, but this is the realm of
individual payment protocols.) If the GSO 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.
The GSO need not be machine parsable and in fact is simply a
representation of the order for the records of the customer and
the merchant. It would normally contain a description of the
goods 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. Since the order is what the
customer is buying as a matter of record, it is essential 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.
payment: This is the pricing, payment systems, transport protocol,
payment type, and similar information. In particular, it
indicates what combinations of these are acceptable to the party
sending the Universal-Payment message. It is intended for
automated processing and it need not be easily understood by a
person. While the price will typically be the same for various
payment methods, it might differ. Payment parameters are
indicated by case insensitive digraphs as follows:
Eastlake, Boesch [Page 7]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
AM = amount ( 12.34 )
CC = credit card type
CU = currency in ISO 4217 format ( cad, jpy, usd, ... )
ID = payment system specific order identifier (this is a payment
specific identifier for the merchant to allow the Wallet to begin
the payment protocol)
PS = payment system ( CyberCash, FirstVirtual, SEPP, STT, ... )
PT = payment type ( cash, credit, debit )
TP = transport protocol ( a URL specifying protocol and absolute
address )
Parameters are separated by commas and alternatives are grouped
with square brackets ("[]") and separated with verticle bar ("|").
continuation: This optional field contains information on where the
user should be directed after the payment protocol. It may only
occur if the Universal Payment Message is being sent by the
merchant.
It consists of any one or more of the case insensitive keywords
SUCCESS, FAILURE, and CANCELLATION, followed by an equal sign and
a URL indicating where the user should go if the specific payment
protocol being used ends the way specified by the key word.
expires: This optional field specifies the date on which the offer
represented by the Universal Payment Message expires.
2.1.2. Definition of Acceptable Field Values
Some of the fields in the payment section have been explicitly
defined. Most fields must support open ended addition of new
designated names. Specifically the PS field must support (at a
minimum) the current major payment protocol options: SEPP, STT,
FirstVirtual, CyberCash, NetBill, DigiCash, ...
Similar issues affect PT though the choices are more limited there.
To support this need, we propose that IANA will maintain a registry
of payment system names as is done for MIME types.
2.1.3 Transport of Universal-Payment Via HTTP
When transmitted via HTTP as a reply, the Universal-Payment message
has MIME type application/universal-payment. The body of the reply
is a MIME message. This nested MIME message has as its body the
order information and as its Content-Type, the actual type of the
Eastlake, Boesch [Page 8]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
order information such as text/plain, and the payment info in a
header line.
HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: application/universal-payment
Content-Length: nnn
Content-Type: text/plain; charset="us-ascii"
Payment: AM=20.00, CU=cad, TP=<http://orders.merchant.tld>,
[[PS=SEPP, PT=credit, CC=MC] |
[PS=STT, PT=credit, CC=VI] |
[PS=CyberCash, ID=merchant=13,
PT=credit, [ CC=DI | CC=AX ]]]
Order of 20 December 1996 from merchant, 321 Main Street:
One Audio CD "Payment Systems I have known" $20.00
Plus shipping and tax 5.43
total 25.43
Ship to: John Doe
123 Last Street
Toronto, Ont.
2.1.4 Transport of Universal-Payment Via email
When transmitted via mail, the Universal-Payment Message is a MIME
message of type application/universal-payment. The body of this
message is in fact a MIME message. This nested MIME message has as
its body the order information and as its Content-Type the actual
type of the order such as text/plain.
The following example shows a case where a user has created an order,
possibly by interacting with an application from a CD-ROM catalog,
and wishes to place the order with a merchant. This customer has
software on their computer (possibly some installed on the same CD-
ROM) supporting the CyberCash, SEPP, and STT protocols. They also
have Diners Club, MasterCard, VISA, and American Express credit cards
and are willing to pay in cash.
The following could be generated automatically for the customer to
convey this information to the merchant. The merchant would then
initiate the payment system they chose. (The specification below
that the payment system would use email as its transport presumes
that each payment has been defined over that transport.)
From: customer@mythical.tld
To: merchant@mall.tld
Eastlake, Boesch [Page 9]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
Subject: purchase
MIME-Version: 1.0
Content-Type: application/universal-payment
Content-Type: text/plain; charset="us-ascii"
Payment: AM=130.00, CU=usd, TP=<mailto:customer@mythical.tld>,
(comment: will pay $US 130.00 and want payment via email)
[[ PS=SEPP, PT=credit, CC=MC ] |
[ PS=STT, PT=credit, CC=VI ] |
[ PS=CyberCash, ID=merchant-13,
[[ PT=credit, CC=AX ] | PT=cash ]
]]
Order of 15 December 1996 from ACME CD_ROM Catalog of July 1996:
Qty Item Unit Cost Projected Cost
1 Rocket Shoes $90.00 $ 90.00
4 Rocket Refills 10.00 40.00
TOTAL COST $ 130.00
Ship to: Wiley Coyote
123 Last Street
Springfield, ZZ 00000
2.2 The Turn-Around Message
If the the party where the order information has accumulated and
which sent the Universal-Payment Message (UPM) to the other party is
also the party which is to send the first message under the selected
payment system, then the other party must send a Turn-Around Message
to start the payment protocol. The only required data in a Turn-
Around message is the one selected set of parameters of payment
systems, type, transport, etc. If the original UPM was from customer
to merchant, then the Turn-Around Message may also contain
continuation data.
Eastlake, Boesch [Page 10]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
3. Anticipated Effects of Universal Payment Protocol
While the introduction of yet another protocol has the potential to
further disrupt the progress in Internet payments, the Universal-
Payment Message 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 Protocol, 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 protocol allows merchants to shop for payment systems that
are appropriate to her 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.
Eastlake, Boesch [Page 11]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
4. Potential Long Term Issues
There is much discussion on the use of more general extension
protocols for negotiation similar to the need filled by the Universal
Payment Protocol. We support this idea in concept. However, to speed
the introduction of payment systems, this very simple approach is
adequate and can be implemented almost immediately.
Many of the Wallet programs are implemented as add-on applications
separate from the browsers, thus any extension protocol must support
external viewers acting as Wallets.
As more general protocol extension mechanisms become widely available
in browsers and other tools, use of the Universal Payment Protocol
may be revisited.
Eastlake, Boesch [Page 12]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
5. Security Considerations
The Universal-Payment protocol 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 Protocol messages, (2) any dialog preceding those messages,
or (3) any fulfillment dialog after the payment protocol is desired,
an appropriate channel or message security protocol such as IPSEC,
SSL, PCT, MOSS, SHTTP, PGP, etc. should be chosen.
References
[CyberCash]
[Green Commerce]
[MIME]
[PGP]
[SEPP]
[STT]
Author's Address
Donald E. Eastlake, 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
+1 703-620-4200 (main office, Reston, Virginia, USA)
email: dee@cybercash.com
Brian Boesch
CyberCash, Inc.
2100 Reston Parkway, Suite 430
Reston, VA 22091 USA
Telephone: +1 703-620-4200
email: boesch@cybercash.com
Eastlake, Boesch [Page 13]
INTERNET-DRAFT Universal Payment Protocol 14 October 1995
Expiration and File Name
This draft expires 13 April 1996.
Its file name is draft-eastlake-universal-payment-00.txt.
Eastlake, Boesch [Page 14]