NOTE-jepi-970519
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.
A list of current NOTEs can be found at: http://www.w3.org/pub/WWW/TR/
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.
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:
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.
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:
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.
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.
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.
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.
Here is an example HTTP message extended with PICS-1.1 protocol:
Server -> Client
HTTP/1.0 200 OK
Date: Thu, 30 Jun 1995 17:51:47 GMT
Last-modified: Thursday, 29-Jun-95 17:51:47 GMT
Protocol: {PICS-1.1 {headers PICS-Label}}
PICS-Label:
(PICS-1.1 "http://www.gcf.org/v2.5" labels
for "http://www.greatdocs.com/foo.html"
ratings (suds 0.5 density 0 color/hue 1))
Content-type: text/html
...contents of foo.html...
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.
Here is an example of UPP Flows
Client -> Server GET http://www.arix.com/catalog.htm HTTP/1.1The client request the catalog.
Server -> Client
....
Content-Type: text/html
Protocol-Request: {http://w3.org/UPP {str req}
{for /SubmitButton}}
Protocol-Info:
{http://CyberCash.com/Coin {for /*}},
{http://GCTech.com/GlobeID {for /*}}
Content-Length: 807
...
The server requests the client to use UPP protocol for the Submit
button. The server also informs the client that he can accept Coin and
GlobeID.
Client -> Server
POST http://www.arix.com/SubmitButton HTTP/1.1
Protocol:
{http://w3.org/UPP {via http://CyberCash.com/Coin}}
{http://CyberCash.com/Coin {params {account 12345}
{expire 9/19/99} {amount {usd 270}}}}
The client presses the Submit button, and tells the server that it is
using Coin. He also sends a series of payment information, i.e. the
account number, expiration date and the amount.
Server -> Client
Content-Type: application/cybercash
Protocol: {http://w3.org/UPP
{params {success /worked}
{failure /didnt}
{cancel /incomplete}}}
Content-Length: 359
...
The server executes the chosen payment system, and informs the client
about 3 URLs to choose from depending on the result.
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.
We also started internally the discussions about the future of this activity within W3C.
We see a possible JEPI phase 2 encompassing several elements:
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.