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

Guaranteed merchant identity
Guaranteed proof of payment when payment is processed.
Ability to purchase "hard" and "soft" goods priced from one cent to thousands of dollars.
An acceptable level of anonymity.
Optional confidentiality of Order Data.
Ability to buy from merchants located in foreign countries or only accepting foreign currencies at an acceptable cost (Buy globally and pay locally)
Ability for customers to use a shopping cart.
Ability for customers to use one or more bank accounts or credit cards.
Ability for customers to manage their accounts online: consultation, refill, secret codes changes, addition of bank accounts or credit cards.
ability to make use of Internet Content Selection labels and infrastructure to limit access to selected services or goods.
Family or Corporate wallets and sub-wallets: one actual account with multiple sub-wallets.

Merchants's Requirements

A level of guarantee for payment at least equivalent to traditional payment instruments such as bank checks and credit-cards.
guaranteed non-repudiation of customers' orders.
Ability to charge "hard" and "soft" goods with a large price range between (e.g., between one cent to thousands of dollars).
Ability to charge customers in multiple currencies and to calculate taxes when needed.
Auditable accounting (especially for merchant and business to business)
Protected recording of all transactions as required by most national laws
Ability to differentiate the proposed prices by geographical area or customer profile.
Usage statistics to determine which products are being viewed or bought most frequently.

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:

to act as a certification authority for its customers and merchants;
to manage customers' and merchants' accounts;
to provide a gateway to one or more financial instruments (credit card, bank account, etc.) for payments.
and to provide any services required by merchants and customers.

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 Globe ID(R) Intermediation Server which authenticates other parties, archives transactions, processes small payments, performs the agreed repartition of the amounts charged to the customers and relays the payments to the traditional financial instrument networks.
The customer Globe ID(R) electronic wallet interface enables the customer to confirm its willingness to purchase a given good, select the appropriate payment instruments and authenticate itself. In practice this electronic wallet is a software application which is freely available, runs on a large variety of personal computer platforms in conjunction with any HTTP1.0 or later compliant Web-browser and has the master intermediation certificate burnt-in.
The merchant electronic cash register toolkit is used in the merchant commercial server to issue the payment request tickets and to receive and check the payment proof tickets. It consists of a small library of functions to be used on the merchant Web server; the library function can be used either within CGI scripts or by means of a tighter coupling as permitted by recent HTTP servers. The two most important functions are the ones to generate the PRT (signed offer) and the one able to receive and process the PPT (payment receipt certified by the intermediation server). Each merchant's toolkit is provided with an asymmetric key pair and a burnt-in master intermediation certificate.

The most important messages exchanged are:

the PRT (Payment Request Ticket) which represents a non repudiable offer, is issued by a merchant, and presented to the customer by the intermediation server
the PPT (Payment Processed Ticket) represents the payment proof issued by the intermediation server once it has checked that the customer accepts the offer and is able to pay
the CAC (Confirmation and Authentication Challenge) presented to the customer by the intermediation server
the CAR (Confirmation and Authentication Response) by which the customer notifies its willingness to order and specifies the payment instrument to be used for the transaction.

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.

Cid: This is the customer Globe ID(R) unique identification number.
Secret Code: this is a personal identification number (PIN) used by the customer to authenticate himself by means of his electronic wallet interface.
A given amount of electronic cash used for small payments: This cash is either representing money drawn from one of the traditional instruments (see below) - debit mode- or a credit line associated with one of these external payment instruments -credit mode-. There is a specific currency associated with this amount.
Payment Instruments description list: in general payment instruments will be credit-cards or bank accounts but may represent any financial instrument usable by the customer such as specific credit line for example.
An optional commerce related customer profile: This may contains informations useful for purchases, such as age and country.

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

addition of a new external payment instrument (resp removal),
modification of his own Secret Code,
refill of the cash part of the wallet,
account status consultation.

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:

how to organize the message flow in order to provide the third party based non-repudiation?
in the lack of largely deployed hardware authentication devices on the customers workstations, how to provide a high level of security on these stations?
how to have a smooth transition path towards the use of hardware authentication devices?

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.

the PRT (Payment Request Ticket) issued by the merchants and which represents a non-repudiable offer to a given customer,
the CAC/CAR (Confirmation and Authentication Challenge and Response) mechanism. The CAC, presented to the customer by the trusted intermediation server is based on the PRT and customer account profile and solicits the customer to confirm his willingness to buy, to select one of the available payment instruments and to authenticate himself,
the PPT (Payment Proof Ticket) represents the results of the payment processing and is certified by the intermediation; it will be presented to the merchant as a follow-on of the merchant's offer (PRT).

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).

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.
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.
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.
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:

securization and notarization of the whole transaction; it will be up to the service provider to charge or not for the online access to the notary archives.
small payments by mean of an accumulation process: it is not possible to give an economical lower bound without estimating the processing fee. In the Globe Online(R) context cheap information goods are charged a 20% fee and this leads to an acceptable lower bound of 4 to 5 cents.
estimating multiple currency processing by the financial intermediation server.

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:

CPTP (governing the interactions between the customer and the intermediation server) is encapsulated within HTTP
PRT and PPT messages are encoded as URLs (using the Location mechanism) in the opaque string
the customer PACK (electronic wallet interface) is a software only component (no smart card readers on the PC yet), thus using a shared secret type access code.
the merchant kit (or SACK) is a C++ library that may be used either in a CGI script or directly linked to a given HTTP server for better efficiency
the intermediation server front-end is a specific purpose multithreaded HTTP server tailored to only process CPTP messages
the intermediation server back-end use a relational data-base as the authentication base and the notary archive and includes appropiate code to communicate with the credit-card closed networks.

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/
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/

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