WWW5 Fifth International World Wide Web Conference
May 6-10, 1996, Paris, France


An Intermediation and Payment System Technology

Paul-André Pays (pays@gctech.fr)
Fabrice de Comarmond(fdc@gctec.com)


Abstract

This paper presents the Globe ID(R) [GID] electronic commerce enabling technology designed and developed by GC Tech [GCT]. The most important design goal was to address electronic commerce as a whole, securing the essential steps of each e-commerce transaction: the offer, the order and the payment.
Globe ID(R) is a system based on an intermediation server which acts as a trusted third party for merchants and consumers. It contributes directly to the securization and notarization of the transactions, manages the e-commerce actors' accounts, and acts as a gateway to the private networks of traditional financial instruments.
This paper presents the model, the protocol, and security features of this technology.

Keywords

Electronic commerce, trusted third party, intermediation, electronic payment system, secure transactions, secure payments, merchant system, Internet, World Wide Web.

1. Introduction

In the domain of WWW based electronic commerce, focus has been put so far almost exclusively on a single component: the electronic payment processing. For Globe ID(R) we have adopted a different approach, since our design aims primarily at securing the essential steps of electronic commerce such as the offer, the order, and the payment. In fact, in the real world, when a consumer enters in a given merchant store it is with the intent to "buy" and not to "pay". Electronic commerce will not be enabled by "payment processing" solution if one does not attempt to provides existing services and garantees available to a consumer and a merchant in the real world. Globe ID(R) is a system based on intermediation in which the trusted third party provides the commerce actors - merchands and consumers - a set of value added services of which payment is a key component but not the only one.
The Globe ID(R) technology is intended to be used by service providers in order to bring electronic commerce services on the market. The document shortly describes the requirements which have guided our design, explains the transaction model and the protocols, and shows details on the security approach and features of the Globe ID(R) Technology.

2. Rationale and Requirements

The design of Globe ID(R) was largely driven by the Globe Online(R) [GOL] project in Europe. This project was initiated by GC Tech and several merchants in France such as LVMH (Moet Hennesy - Louis Vuitton), Havas advertising (formerly EURO RSCG), and DAFSA. They were quickly joined by many content providers including newspapers such as Le Monde and Libération and many information services providers.

2.1. Securing all transactions steps

One fundamental observation in commerce is that it is not sufficient for the merchants and the customers to have a secure payment system. A selling/buying act is a form of contract in which the merchant makes an offer and the customer then agrees with the offer. The offer contains not only the requested price but also a sufficiently precise description of the offered good and some additional information such as delivery delay, warranty period, return policy, etc.. A customer must pay the requested price but requires that the terms of the contract are fulfilled by the merchant. Furthermore the merchants absolutely need to be in a position to trust the orders.
In a nushell, the intermediation server has to act as an electronic notary safely archiving non-repudiable copies of the processed transactions.

2.2. Small Payments Transactions requiring cash-alike services

Many of the content providers involved in the Globe Online(R) project had a significant experience providing on-line services through the Minitel in France and off-line information services on CDROM.
With 6.5 million of Minitel terminals (of which 4.5 million are held by private households), 6.6 billion FF (1.3 billion US$) of turnover were made through 25,000 Minitel services in 1994 with a fairly small average transaction (about 0.5 US$). From our discussions with Globe Online(R)'s content providers and our analysis of the successful 10-year experience in on-line services through the Minitel, we knew that on-line networks are well adapted to the sale of low-price goods, in particular informational goods, since the delivery could be carried out through the network itself.
This impression has been recently confirmed by the results of a poll published by France Telecom on the nature of the service that Minitel users called during their last connection. It shows that over 70% of the last calls were concerning the sale of Value added information [LCC].

Therefore, our decision was that our payment system should support small payments transactions.

2.3. No currency creation

We carefully avoided to create a virtual currency since in most countries the creation of currency is reserved to a central or federal bank. Furthermore, payment methods using a token representation of money must include complex schemes to protect themselves against the ease to duplicate - maliciously or not - such circulating or stored tokens.

In other words, the legal and technical difficulties resulting from letting the customers and merchants have tokens on their station or server would lead to heavy and cost-ineffective solutions to provide the financial guarantees required for payments.

2.4. An identified and trusted service provider

Merchants as well as customers are not primarily interested in technology. They do need a service provided by a trustworthy legal entity with an explicit contract. We recognize that customers and merchants want to work with the financial institutions they already know and trust, e.g., banks or credit card organizations. People are very averse to risking their money with an organization they don't know.
Results from the last GVU survey indicate that 3.4 out of 5 online consumers would prefer a third party in the transaction and the best third party would be a bank for 3.7 out of 5 and a credit card company for 4.0 out of 5. Security concerns are a primary reason for not buying among WWW users: (60% agree somewhat or strongly, average 3.53 on a 5 point scale).[GVU]

With its characteristics regarding cost and security, the Globe ID(R) technology is a tool that enables these trusted entities to provide such a service. Globe ID(R) is a technology designed to be used by such electronic commerce and financial service providers. It is not intended to be used by customers and merchants without any third party.

2.5. Detailed requirements

Following is the list of requirements for both the merchants and the customers concerning electronic commerce.

Customer's Requirements

Merchants's Requirements

3. The intermediation server approach

In order to support the above requirements, we propose an intermediation service that processes and controls all transactions.

The Globe ID(R) intermediation server (Figure 1) is a visible component which interacts directly with both customers and merchants. Thus, we named our model CMTM ("Clearing in the Middle Transaction Model").

The Intermediation service is designed to be operated by a legal entity a priori trusted by merchants and customer:

3.1. Components and Messages

In the Globe ID(R) system, merchants and customers delegate the actual management of their accounts (the customer wallets and the merchant cash registers) to the trusted third party. They are only provided with respectively a PACK (Personal Authentication and Confirmation Kit) for the customer and a SACK (merchant Server Authentication and Certification Kit) for the merchant. The kits are basically interfaces allowing to remotely control the use of the electronic accounts. The three components of the system are:

The most important messages exchanged are:

Each customer Globe ID(R) electronic wallet (Figure 2) contains all the information associated with this customer related to payment and, more generally, electronic commerce.

In addition to its use for payments, the customer's electronic wallet interface provides the customer with some operations such as:

The intermediation server supports hierarchical electronic accounts (Figure 3) which are useful for either corporate accounts or familly accounts, for which the account owner can delegate partial rights to other individuals (subordinates or children).

3.2. CMTM model and CPTP Protocol

In order to provide the services listed above we were faced to the following problems: Most of the security related choices will be detailed in the following section. The message path explained below contributes to the overall security as it forces the customer to authenticate through a challenge response (also termed loop-closure) mechanism under the control of the intermediation server and never allows any network user or application to issue unsolicited authentication attempts. However, initially the basic justification was to provide the non-repudiability feature of the system: transaction messages are archived by the intermediation server before being exchanged on the network. The transaction model presented in the Figure 4 below involves the following exchanges between the customer, the merchant and the trusted intermediation server. Though unusual in electronic payment proposals, this scheme is very traditional in normal commerce practice. It is used for example in many departmental stores in which customers select a good, receive an offer, pay at the cashier, get a receipt allowing to retrieve the purchased good. This similarity explains and contributes to the good acceptance of the Globe ID(R) model by commerce actors/parties.

3.3. Security Features

3.3.1. On the Customer's Side

As already mentioned before, the security design carefully avoids to store any security sensitive data on the customer workstation. This avoids to handle extremely complex operational and support issues, e.g., we all know that people tend to delete or duplicate their disk storage.

The usage of asymmetric cryptography for customer authentication cannot be considered as a good option until a tamper resistant "safe" allows a secure storage of the private key. We expect handheld authenticator devices to appear on the market rather soon; the EMV smart-card is certainly a good candidate, it has all the features needed to safely store the user secret key as well as one or a few servers certificates. In the mean time we consider that a shared secret access code (PIN) approach is more feasible as it does not require any storage on the consumer station. Nevertheless there is no problem to use asymmetric cryptography on the user side. as long as the cypher used is a public key that does not require to be hidden.

In other words, the customer authentication is transparent to the type of used cryptography: either shared secret for a pure software solution or asymmetric cryptography as soon as the customer station is provided with a hardware device to store a customer's private key.

In the Globe ID system, each customer is provided with a Cid (Customer Wallet Identification) and a PIN (the shared secret) during registration with the intermediation service. The Cid associated with each customer enables to register all customer payment relevant specific information such as one or more credit-card numbers or a bank-account. In addition there is an optional customer profile which may be used to certify for example the required age permitting the purchase of alcoholic beverage.
The customer, by means of its PACK (Personal Authentication and Confirmation Kit) software interface - in fact his Globe ID(R) electronic wallet interface - knows the intermediation server public key.

The figures below will present in more details the actual protocol version which does not require consumer certificates. As soon as hardware devices will be available on the consumers workstations and trusted certificates distributed to end-users another protocol version will be used for these fortunate users.

3.3.2. Merchant Server Side

The merchants who operate well managed and reasonably secure commercial Web servers don't present the same problem; the advantages of asymmetric cryptography are so obvious that each merchant obtains his own asymmetric key pair.

Each merchant server is provided with a an asymetric key pair (by means of the merchant Cash Register Toolkit), the toolkit contains the intermediation server public key and a function library in order to generate and process the Globe ID(R) system messages.

3.3.3. Intermediation Server Side

The intermediation server is provided with an asymmetric key pair (public key and private key), maintains a customer authentication database (currently a Cid and Secret Code for each customer) and a merchant authentication database (Mid and merchant public key for each registered merchant).

3.3.4. Messages Flow

The transaction dynamics by which the intermediation server challenges the consumer, ensures a complete view of all the transactions for a given wallet. Not only that it makes any type of network based attack extremely difficult, it even protects against external problems. For example the intermediation server will detect and thus block any unusually intensive and abnormal use of the electronic wallet that might result from stealing a PIN.

3.3.4 Overall Description

The two figures below (Figures 5 and 6) detail the protocol governing the exchange between the customer (customer software) and the intermediation software including essentially the the CAC/CAR mechanism. The keys on these pictures indicate the type of cryptography and keys used to ensure message integrity and to authenticate both parties.

This protocol is named CPTP, which stands for Customer, Payment Server Transaction Protocol. For all pure payment transactions this is a mechanism involving four exchanges as illustrated in the first picture. As the the protocol allows some additional operations, such as wallet status consultation, there may exist additional exchanges (second picture).

  1. The PRT received by the customer from the merchant is relayed by the customer to the intermediation server fundamentally as is. The message is signed by the originating merchant but the customer interface does not add any security element. Sending this PRT from the customer station to the intermediation server constitutes the step 1 of the CPTP protocol.
  2. The CAC received by the customer has been signed using the intermediation server secret key. The CAC basically contains the PRT and the payment instrument set from which the consumer will have to select one.
  3. The CAR contains two parts. One is signed using the intermediation server public key and contains the customer secret code (combined with data received in the challenge to protect against replay attacks). The other part is signed with the customer secret code using a MAC and basically contains a session key in addition to the customer Cid.
  4. According to its type (result or error) the last and 4th message is signed either with the session key (result) or the Intermediation Server private key (error).
The session key is used in the few cases, when additional exchanges are needed in order to complete the transaction between the customer and the intermediation server.

The next figures (Figures 5 and 6) illustrate the details of CPTP, by presenting the essential information elements exchanged and how they are protected :

The rationale for this approach was the desire to reach maximal security. Part of this security is a result of the loop-closure mechanism which other systems such as First Virtual [FVH] have demonstrated to be extremely reliable. Furthermore, the cryptographical challenge response scheme is a very traditional scheme for securing authentication. Last but not least, this scheme allows the customer to select a payment instrument without typing or transfering any sensitive information about it. The intermediation server presents the selectable payment options to the customer within the CAC using pre-established and customer defined nicknames, the consumer sends back it choice within the CAR by means of an enumerate value. In fact the intermediation already knows all the informations for each payment instrument of each registered customers, no transfer over the network is needed.

From a technical point of view GC Tech's system brings a very high level of security together with efficiency, thanks to a clever combination of two mechanisms: loop closure and strong cryptography.
GC Tech use the same level of strong cryptography such as the one found in the specifications for SET.

4. Globe ID(R) technology functionalities

4.1. Basic Services

The basic services of the Globe ID(R) system are:

4.2. Independant Name Space


Globe ID(R) has its own registration system and allocates its customers system specific identifiers (distinct from the credit-cards). This can be seen as a drawback (one more identifier) but is also a clear advantages as it helps to separate the domains of responsibilities and protect each system against a potential failure of another system.

4.3. A mesh of cooperating intermediation servers


The Globe ID(R) model is designed to be used in a worldwide mesh of locally trusted intermediation operators.
Each intermediation service will have its own and natural sphere of trust: the customers and merchants registered with an account. Very often this sphere of trust will reflect cultural, legal and economical zones.
Globe ID(R) technology enables the legal entities operating such a service to enter bilateral agreements: each intermediation server can technically be considered by a merchant server by any other intermediation service. No modification is required to the protocol and model, a intermediation server simply forwards a given PRT to another intermediation server in order to allow a customer registered at one service to buy from a merchant registered at another service.
Thus, simply by encoding the Globe ID(R) service identity within the customer (Cid) or merchand (Mid) identification a worldwide mesh of locally trusted servers can cooperate to provide a worldwide coverage as long as the intermediation service providers come to an agreement to mutually trust each other and share fees.

4.4. Payment Instrument Independance

GC Tech system is not tied to a specific payment instrument. It is able to use the credit-card system and services, and it provides access to direct bank accounts, credit lines or whatever payment instrument available for a given customer.

5. Implementation Considerations

For obvious reasons HTTP and the Web were choosen to be the first context for which the Globe ID protocols are implemented. In the initial release: In the near to medium term the customer PACK will be enhanced to take profit from smart-card readers containing a user certificate, thus enabling to use a SET purchase message in the CAR response to the intermediation server.
Upon market demand, a native version of CMTM, CPTP can be developed, by now we consider that the WWW HTTP context is a successful environment for large scale electronic commerce on the Internet.

6. Conclusion

A few words are sufficient to summarize our intermediation and payment system: trust, openess, generality and efficiency.
trust:
Banks, or equivalent financial institutions are natural candidates to operate the intermediation services, as they already are the insitutions trusted by the commercial actors for this financial intermediary role. The trust is also a result of the transaction model where each party (intermediation, buyer, vendor) checks and authenticates the others. Most important, the users and consumers are not requested to trust in a technical system but to trust in a financial institution.
openness:
the model and protocols are been designed so that it will be extremely easy to go a step further and use any handheld hardware authenticators when available, instead of a pure software e-wallet interface; the EMV smart-card seems to be the most obvious candidate.
generality:
The Globe ID(R) Technology supports payments from one penny to thousands of dollars.
efficiency:
the unique transaction model allows to offer a very high security level while maintaining processing costs at a very reasonable level.

GC Tech's involvement in the W3C indicates the willingness to contribute to the design and wide adoption of core technologies for electronic commerce and to develop this technology to keep it synchronized with the latest Web core technology evolution such as HTTP 1.1+ , SEA, PEP.


Acknowledgements

We would like to thanks the GC Tech staff for all contributions or comments to this paper and particularly Pieter Van Der Linden and Peter Sylvester. We are also thankful to the reviewers for their numerous requests and suggestions.

References

FVH
The First Virtual Holding home page: http://www.fv.com/
GCT
The GC Tech company home page: http://www.gctech.fr/ or http://www.gctec.com/
GID
the Globe ID(R) server home page: http:/www.globeid.com/
GOL
The Globe Online(R) virtual mall home page: http://www.globeonline.fr/
GVU
GVU's Fourth WWW User Survey, Copyright 1995 Georgia Tech Research Corporation. All rights Reserved.http://www.cc.gatech.edu/gvu/user_surveys/
JEP
The Joint Electronic Payment Initiative (JEPI) by W3 Consortium and CommerceNet: http://www.w3.org/pub/WWW/Payments/JEPI.html
LCC
Laurent CIRY/CREAPRESS, in: La Lettre de Teletel et de l'Audiotel, Hors Serie n13, ,Copyright France Telecom 1995
MIL
Millicent : a Mark Manasse paper about this extra lightweight e-payment technology: http://www.research.digital.com/SRC/millicent/
PAY
Rivest and Shamir (MIT) paper about another ultra lightweight payment technology: http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps
SET
Secure Electronic Transactions, in Visa expo: http://www.visa.com/cgi-bin/vee/sf/standard.html?2+0
WEC
W3C section devoted to electronic commerce: http://www.w3.org/pub/WWW/Payments/