Computerworld column on JEPI-related issues

Rohit Khare (
Mon, 22 Apr 96 16:22:34 -0400

[These guys have written a book recently -- I believe they hosted the conf.
Dan Connolly was at]
Payment schemes needed

Ravi Kalakota and Andrew B. Whinston

There are several business issues that current Internet mercantile schemes do
not address. Among these are simplicity and speed.

At the moment, the simplest and most widely used methods to make purchases on
the Internet are: to enclose credit-card numbers in an electronic-mail
message or go off-line and use the telephone. Given the open nature of the
Internet, the E-mail method is wide open for fraud.

To combat this, an increasing number of payment schemes based on
cryptographic techniques are appearing on the Internet. These schemes are
aimed at the issue of authentication (are you who you claim to be and is your
payment valid?). These payment schemes come in two main types: electronic
tokens and encrypted credit cards. Another payment scheme uses third-party
processors and a phone call to establish authentication.

Buying process

A mercantile process scenario would likely take place as follows:

Buyer and seller engage in a dialogue that identifies the product or service
the buyer desires and offers a price quote. This dialogue might be interactive
on-line or even off-line through an electronic catalog and telephone.

The buyer then sends the seller the encrypted credit-card number or a certain
number of electronic tokens. The seller gives its payment service information
about the buyer, the product or service and the agreed upon price and asks
for a funds transfer.

The seller's payment service authenticates the transaction and the buyer by
calling that buyer or using the digital signature method, which does not
require interaction.

The seller's payment service identifies the buyer's payment scheme and sends
a standardized message giving details of the transaction so the buyer's
account is properly debited or charged.

The seller is notified of the completed financial transaction. The seller
then dispatches the goods or, if the buyer is purchasing information, the
seller provides a key to unlock a file.

At the end of the billing cycle, the buyer receives a list of transactions.
The buyer can then deny certain transactions or complain about overbilling.
Suitable audit or customer service actions are then initiated depending on the
payment scheme.

The above process is similar to the way credit-card transactions are
processed. While the process appears to be technically sound, it may not meet
certain "hidden" criteria needed for successful business practice.

For instance, take simplicity. Let's face the facts: Typical customers such
as Aunt Sally or Uncle Bob are technophobes, and if they have to muck around
with public keys, private keys and key management, they will abandon commerce
on the Internet.

This issue will have to be addressed with user interfaces that are intuitive
and hide the complexity of the underlying technology.

Another issue transaction speed. This has not been addressed. Payment schemes
need to be sophisticated enough to happen in near-real time.

Studies have shown that most of us do not have the patience to wait 20
seconds while a hyperlink is being processed by the server. Most cryptographic
methods will take some finite time to process. Add other layers of processing
and there is a long wait.

One payment plan

Finally, a vendor must decide which payment scheme to choose. If vendors sign
up for only one of these schemes, then buyers will have to join several in
order to do business with several vendors. It would be good if buyers need
join only one service. Some vendors will be small so this appears unlikely.

So, we can expect several competing schemes simultaneously making
interoperable electronic commerce a necessity. It would be extremely valuable
to the future of electronic commerce if vendors and buyers each join only one
scheme of their choice.

Obviously, the time to address these issues is now before we get to a
situation where we have several "islands of electronic commerce."


Rohit Khare -- 617/253-5884
Technical Staff, World Wide Web Consortium
NE43-354, MIT LCS, Cambridge, MA 02139