This document is a NOTE made available by the W3 Consortium for
discussion only. This indicates no endorsement of its content, nor
that the Consortium has, is, or will be allocating any resources to
the issues addressed by the NOTE.

Since NOTEs are subject to change, you are advised to reference the
URL for the "latest version".

The primary goal of this paper is to document everything we learned
during JEPI project phase 1, i.e. the long-term vision, technical
problems and solutions, project management experiences, future plans,
and so on. Each section of this paper is quite independent, and
readers only interested in a particular aspect of the project could
still benefit from reading relevent sections of the paper.

JEPI is a joint project between W3C
and CommerceNet with a number of
industry partners to explore the process that takes place, typically,
after shopping and before actual payment begins. This is the point in
time where the exact payment instrument (credit card, debit card,
electronic check, electronic cash, etc.) must be agreed upon between
the browsing client and the merchant server, and then, the transaction
can take place.

With the development of appropriate HTTP extensions like PEP and
UPP, JEPI phase 1 offers an automatable payment selection
process, which ultimately enhances the user shopping experience
while allowing coexistence of multiple payment systems.

The primary goal of this paper is to document everything we learned
during JEPI project phase 1, i.e. the long-term vision, technical
problems and solutions, project management experiences, future plans,
and so on. Each section of this paper is quite independent, and
readers only interested in a particular aspect of the project could
still benefit from reading relevent sections of the paper.

The Internet is becoming an increasingly commercial arena in which
payments are rendered for goods, information, and services. To support
such commerce, various Internet payment protocols have been proposed
and adopted by a variety of organizations. Most of these payment
protocols are, however, incompatible with each other, and there
appears to be little prospect of unification or abandonment of most of
these protocols.

In fact, the existence of different payment mechanisms are
justified because there are different needs to be satisfied in terms
of:

Cryptographic needs (strong, symmetric, exportable, importable,
etc.)

Latency of the transaction (micropayment must be very fast)

Minimal and Maximal amount for the transaction itself

Minimal and Maximal amount for the cost of the transaction

Repudiation, Notarization needs

Involvement of Financial institution

etc.

Some examples of payment protocols are:

SET standard being developed by MasterCard and VISA

CyberCash system

GCtech's GlodeID

CMU's NetBill

First Virtual

DigiCash' ECash

and many more.

While the multiplicity of payment systems brings healthy
competition among players, it also brings more complexity to the
end-users, i.e. consumers and merchants. The goal of the first phase
of the JEPI project is, while allowing multiple payment systems, to
assist consumers and merchants in the process of selecting a payment
system appropriate for both parties for any given transaction.

W3C's position for the JEPI project is to provide an
architecturally viable and neutral mechanism for doing the negotiation
of payment instruments over the Web in an automatable way. It is not
to provide a new payment protocol or a way to convert dynamically
between payment schemes.

Let's put the emphasis on this point: JEPI is not about a
new payment protocol or scheme but rather a way to negotiate and
select a single payment system to be used for a particular transaction
from the group of multiple payment systems installed on the client and
server platform.

If a server has installed payment systems A and B, and a client
has installed Wallet C and D, JEPI will not help; no conversion
functionality is provided. But if a server has installed payment
systems A, B and C, and a client has installed Wallet C and D, then
JEPI should be able to select C as the appropriate method on behalf of
both users.

JEPI should also allow end-users to smoothly extend their arsenal
of payment mechanisms with new payment systems without interfering
with already installed systems.

In the real world, there is a complicated process which takes place as
indicated by the following scenario:

You approach the cash register and see decals indicating that the
merchant will accept payment by MasterCard and Visa. It is, of course,
understood that you can pay in the local currency. You ask whether the
merchant will accept a check and they tell you that they do not,
unless you have a check guarantee card that you do not own. So you ask
if they will accept American Express. They admit that they do, but
then reveal that they will give you 2% off if you use MasterCard or
Visa; or 5% if you pay cash. You decide to pay cash, but ask if there
is a discount for AAA members. They admit that there is, but not on
top of the 5% cash discount. But they do give United Airlines
Frequent Flyer Miles.

This is admittedly a bit more complicated than usual for consumer
payment. It is, however, very similar to negotiations that happen in
inter-corporate purchasing arrangements. The JEPI project is intended
to enable "automatable payment negotiation," where the
computers perform some negotiation (finding out what capabilities they
have in common) and the user makes the final selection
decision.

To demonstrate the advantages of using JEPI, we will show two
online shopping scenarios, one without JEPI and another with JEPI.

Without JEPI, a merchant must allow the consumer to manually select
payment options (via WWW pages).

You go to a merchant's Web site. After browsing the catalog for some
time, you find a few interesting items. You select the items, and
press Submit button. The merchant acknowledges the order by sending
you an invoice along with a list of payment systems he can
accept. Being uncertain about what payment system his customer might
want to use, the merchant presents a list of all 79 payment systems he
can accept. After intensive browsing through the list and some
head-scatching, you select one payment system, and press Pay
button. The payment transaction starts. But you suddenly realize that
you missed a significant discount offered to customers who use the
merchant's favorite credit card. Too late...

This is the way electronic commerce is usually conducted today, and
the situation is also found in the physical world; for example, it is
not difficult to find a gas pump with 40 - 50 different decals on
today. The limitations of this approach are:

merchant must specify all choices up-front instead of silently
accepting some without advertising them

potentially long list of payment choices, which would be
cumbersome for consumer

no way to automatically eliminate choices that can't work, e.g.
accepting a check in a foreign currency

no way to automatically apply payment preferences, e.g. you
might want to use micropayment method for all transactions under
certain amount of money if and only if merchant accepts that method

no way for consumer to counter-offer some other choice

JEPI is designed to address these issues by providing an automatable
negotiation and selection of payment system based on common
capabilities and preferences of the consumer and the merchant.

Here is the same scenario, but this time, both the consumer and the
merchant are JEPI-enabled:

You go to a merchant's Web site. While browsing the catalog, your
JEPI-enabled client software talks to your merchant server; it informs
the server about your 5 preferred payment methods. Now, you select
your items, and press Submit button. The merchant acknowledges the order
by sending you an invoice along with a list of payment systems he can
accept. But this time, he sends only 7 options; 4 of 5 methods
suggested by you and 3 additional methods of his preference, including
his favorite credit card to which a big discount is associated. To
take advantage of the discount, you select the merchant's favorite
credit card, and press Pay button. The payment transaction starts.

In this scenario, the consumer is happy because he didn't miss the
discount. The merchant is also happy because he was able to use his
favorite payment method. Besides, the consumer was presented only with
relevant payment choices.

As with all W3C activities, industrial partners, coming from our
membership base or invited (in this particular project CommerceNet
members were all welcome), are a requirement for a project to exist.

In JEPI project, we first defined several roles in the context of
an Electronic Commerce transaction and the following companies stepped
up to participate in the design and implementation phase.

Payment systems: CyberCash, GCTech

Browser: Microsoft

Servers: IBM, OpenMarket

Merchants: Xerox, British Telecom, VendaMall

W3C: Specifications, Prototyping, Technical Management

CommerceNet: Management, Marketing

Ericsson: Demonstrator, Engineering resource to W3C

As you may have noticed, there is no bank or financial institution
in the above list. The simple reason is that, in JEPI, we rely on the
payment system service providers to handle the connection/gateway to
the financial world. This happens both on the client (wallet) and the
server (cash register) sides.

JEPI hinges around creating specifications for a pair of negotiation
protocols:

A general purpose negotiation protocol based on PEP (Protocol
Extension Protocol). This allows a Web client and server to ask one
another what extension modules they support, negotiate parameters for
these extensions, and ask the other end to commence using an extension
if possible. This work is being folded into the specifications of HTTP
through the IETF processes.

A specific extension module, UPP (Universal Payment Preamble), used
to negotiate over the payment instrument (check, credit card, debit card,
electronic cash, etc.), brand (Visa, MasterCard, American Express, etc.),
and payment protocol (SET, CyberCash, GlobeID, etc.). This work is being
done primarily in the JEPI project, but will probably be turned over to
another party for formal standardization when the project is complete.

The diagram above shows the overall architecture of JEPI, with the
PEP and UPP layers acting as a stack on top of existing HTTP
communication to perform a negotiation and selection of payments.

The Protocol Extension Protocol (PEP) is a generic framework for
describing extensions within HTTP. Each PEP extension represents new
features to HTTP, and is associated with a URL. A PEP extension uses a
few new header fields to carry the extension identifier and related
information from HTTP clients, through proxies and intermediaries, to
servers, and back again.

PEP has already been used by the PICS (Platform for Internet
Content Selection) project to exchange labels and we expect it to be
used whenever a negotiation of features is needed at the level of
client/server communication on the Web. In JEPI, it forms the basis of
UPP, which does the payment negotiation.

JEPI phase 1 uses the version of PEP from August 1996 which defines
4 new headers: Protocol:, Protocol-Request:,
Protocol-Query: and Protocol-Info:. These headers
allow for naming (identification of extension), initiation/request of
a protocol usage, inquiries on protocol availability and advertising
(notification of usage). The newer version of PEP is somewhat
simpler.

The Universal Payment Preamble (UPP) is the foundation of JEPI. It
provides the semantics of the payment selection. It is based on PEP
and therefore operates at the HTTP level.

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. Each payment system is
considered to be a PEP extension, identified by a URL. In addition,
there exists the http://w3.org/UPP protocol and a module implementing
it.

UPP headers allow parties to negotiate payment alternatives at any
point in shopping, until a final hand-off to a particular chosen
payment system. It 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.

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.

In addition to allowing exchange of purchase information such as
amount, currency, brand, etc., UPP also provides a way of
transitioning to the next state depending on the result of the
execution of the chosen payment system; either side can notify
success, failure, or cancel of the transaction.

JEPI architecture itself does not address security issues. It is
the specific payment system invoked, not PEP or UPP, that is
responsible for the secure transmission of funds.

In JEPI phase 1, we only implemented credit card
protocols. However, UPP is more general, and provides features to
support other payment systems; UPP can carry payment protocol
parameters, such as brand names. This implicitly allows a fourth
protocol layer on top of HTTP, PEP and UPP, where protocol-specific
stuff is carried via UPP. This is the way UPP claims to provide
extensibility in order to meet the needs of other payment protocols.

The JEPI phase 1 is based on a version of PEP specification from
August 1996. Since then, it has been revised and a new version of PEP
has been submitted to IETF for review. When it is accepted by IETF, it
will formally be a part of HTTP.

UPP specification is based on the PEP draft from August 1996, and
has not yet been updated to meet the changes of PEP.

As of the writing of this document, we have an implementation of
PEP and UPP available as extensions to Microsoft Internet Explorer
3.01 and IBM web server on Windows NT.

We also have a JEPI
Demonstrator, provided by Ericsson, which is a set of Web pages
that illustrate various shopping scenarios, with and without
JEPI. PEP/UPP messages transported in each step of a shopping scenario
are described in detail.

Our pilot so far has only been involved with emulated transactions,
not any real merchants back-end systems. The next step is to move into
a real life experiment. We could extend the pilot to support a real
merchant system just based on the JEPI support we've already got in
the MS browser and the IBM server. However, it would be more desirable
to define a simple pre-defined interfaces, and build on top of it.

Distributed project: JEPI project is quite different from
a traditional industry project geared towards a specific product
development by a dedicated team of developers. Most notable
characteristics are:

Participants come from completely independent organizations
(i.e. companies) spread over different geographical locations, and all
have different interests and expertise. Diversification of expertise
is good, but diversification of interest can be harmful. Different
time zones (9 hours of difference between Seattle and France) didn't
help either.

The project leader does not hold a stick nor carrot; he must
rely on participants' voluntary cooperation.

It is really hard and time-consuming to coordinate a project involving
so many different participants.

Attacking a poorly understood problem: The scope of JEPI
project was limited to payment negotiation and selection. This gave us
a good focus on the problem to be solved, but we were still too
ambitious; we wanted to support back-and-forth negotiation but we
didn't have any real experience of what the real demand is for such
negotiation. We helped ourselves tremendously, in the demo, when we
limited the scope to simple payment selection.

Basing project on an unstable ground: We were not helped
by the status of PEP which was still in design flux and poorly
described. In particular, both the server and browser support for UPP
got caught up in issues of how to support PEP itself. Besides, UPP was
not flexible enough for certain situations, specially where selection
of payment brand was needed depending on conditions dictated by the
merchant or client.

Attracting non-technical participants in a technical
project: Merchants are interested in completed solutions.
Bringing them in at the requirements development process was a good
idea, and we got useful input. But they were not interested in the
technical design, and didn't really want to be involved in a
prototype. It's hard to get merchants to invest in a demonstration
that has no planned follow-on.

Use of Demonstrator: The Demonstrator was extremely
useful not only as a way of illustrating the potential of JEPI, but
also as a means of communication between different participants in the
projects. It was an efficient complement to the PEP and UPP
specifications.

Timing: JEPI is ahead of the real world demand for
payment negotiation. Most consumers and merchants support only a small
number of payment systems today and so don't see the need for it. We
should have made a larger effort to understand our "window of
opportunity" and try to match it.

As currently structured, UPP is oriented to select a payment
mechanism (i.e. CyberCash, GCTech etc.) first, and within that
mechanism, a brand (Visa, MC etc.). For today's consumers, who usually
are familiar with brands but not with mechanisms, this is a bad
strategy. Consumers might not even care about the underlying
mechanisms used to carry out the transaction. This suggests
negotiation over payment instruments (credit card brands, etc.), not
over payment mechanisms. On the other hand, there are also situations
where consumers need to care about mechanisms. For example, the choice
of mechanism could be directly related to consumer's rights,
liability, cost etc. A system like JEPI should allow different payment
models and operation modes to coexist.

Implicitly, there were four levels of negotiation -- and we didn't
do a good job of distinguishing them. Seen from the perspective of
one participant in a PEP/UPP negotiation, we have the following cases
to consider: (1) the peer may or may not support PEP; (2) the peer may
or may not support UPP; (3) the peer may or may not recognize or be
willing to use a given payment mechanism; (4) the peer may or may not
recognize or be willing to use a specific aspect (e.g. a brand)
associated with a particular payment mechanism. In particular, PEP
and UPP don't have a good way to handle case (4). There's no easy way
to say "I reject brand X for mechanism Y" versus "I reject mechanism
Y", much less say "I would accept brand X and mechanism Y but only
under constraint Z."

Payment negotiation inherently requires keeping some state at
each end of the negotiation. We were trying to do that in the HTTP
environment which doesn't really support that, and were working with
browsers and servers that consequently don't have good infrastructure
for maintaining state. In JEPI, the state was kept within the
protocol lines with parameters such as AMOUNT and MERCHANT-CCID. The
payment systems accumulate this state between transactions. This is a
rather limited manner, and we should have spent more time looking at
the issues surrounding state in an HTTP environment.

It's really complex, in a development sense, to be dealing with
many different interfaces. For example, at the server end, we had
four such interfaces: (a) the PEP/UPP protocol messages exchanged with
the browser; (b) the merchant server itself; (c) CyberCash's merchant
support; (d) GC Tech's merchant support. It takes a lot of time to
get all that working. We significantly underestimated the time it
would take to get it all done.
The complexities of supporting multiple interfaces has been made
simpler by using a common platform -- Intel-based Windows NT. However,
it required porting of many already existing software components to
the common platform, leaving less time to focus on the protocol
itself.

We also started internally the discussions about the future of this
activity within W3C.

We see a possible JEPI phase 2 encompassing several elements:

Revise UPP in the context of the evolution of PEP, on top of
which it is layered.

Implement all scenario described in the UPP flows document
(JEPI1 focused on just one).

Extend UPP to address issues arising from introducing smart
cards, electronic checks, electronic cash, and micropayments as
payment mechanisms that can be negotiated.

Prototype implementation using new payment system like the ones
derived from SET, micropayment, smart card, etc.

Extend HTML to address issues arising from micropayment, but
not necessarily the other mechanisms.

Wallet and cash register APIs for connecting to payment systems
only if the participant request that it be done. Ditto APIs between
wallet/cash register and browser/server.

We are in the process of getting feedback from the industry as to
what priority should be given to the items in the above list.

The pace at which we will pursue any activity in that area will
depend greatly on the market context. For one thing, the Electronic
Market has been slower than expected to really take off, and working
on any payment negotiation aspect in that context could be perceived
by some as putting the car before the horse.

We still believe that negotiation over payment method is important,
given the continuing growth of the number of protocols. We think the
community is slowly beginning to see that the problem is, in fact,
getting worse and not better. JEPI1 is probably ahead of its time, and
JEPI 2 is yet to be defined because of that.