Journal reference: Computer Networks and ISDN Systems,
Volume 28, issues 711, p. 1197.
An Intermediation and Payment System Technology
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
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.
Electronic commerce, trusted third party, intermediation,
electronic payment system, secure transactions,
secure payments, merchant system, Internet, World Wide Web.
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.
- 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
- 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
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:
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.
- 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?
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.
- 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).
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 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 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 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
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.
- 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.
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.
A few words are sufficient to summarize our intermediation and payment system: trust, openess, generality and efficiency.
- 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.
- 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.
- The Globe ID(R) Technology supports payments from one penny to thousands of dollars.
- 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.
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.
- The First Virtual Holding home page: http://www.fv.com/
- The GC Tech company home page: http://www.gctech.fr/ or
- the Globe ID(R) server home page: http:/www.globeid.com/
- The Globe Online(R) virtual mall home page: http://www.globeonline.fr/
- GVU's Fourth WWW User Survey, Copyright 1995 Georgia Tech Research Corporation. All rights Reserved.http://www.cc.gatech.edu/gvu/user_surveys/
- The Joint Electronic Payment Initiative (JEPI) by W3 Consortium and CommerceNet:
- Laurent CIRY/CREAPRESS, in: La Lettre de Teletel et de l'Audiotel, Hors Serie n13, ,Copyright France Telecom 1995
- Millicent : a Mark Manasse paper about this extra lightweight e-payment technology: http://www.research.digital.com/SRC/millicent/
- Rivest and Shamir (MIT) paper about another ultra lightweight payment technology:
- Secure Electronic Transactions, in Visa expo: http://www.visa.com/cgi-bin/vee/sf/standard.html?2+0
- W3C section devoted to electronic commerce:
About the authors
spent several years at the head of the
"Distributed Applications" research team at Ecole Nationale
Supérieure des Mines of Saint-Etienne (EMSE), then at the head
of the CSR/Comiso network service at INRIA, France. He was a
former convenor of the RARE (Réseaux Associés pour la Recherche
Européenne) working group WG-NAP (Network Supporting Applications
and active participant in several IETF WG. Paul-André Pays left
the academic R&D community in order to found EdelWeb in 1994 and
GC Tech in 1995.
Fabrice de Comarmond,
Executive Vice President, Technology, GC
Tech Inc. Mr. de Comarmond joined GCTech in 1995. Mr. de
Comarmond has been deeply involved in academia as Research
Assistant, Systems Manager and Assistant Director for Computing
for the Institute for Systems Research (one of the leading NSF
Engineering Research Center in the US). Before joining GCTech,
Mr. de Comarmond also provided consulting work for the World
Bank, the European Commission DGXIII and was appointed scientific
counselor at INRIA, the leading french national research
institute in information technology. Mr. de Comarmond is a
graduate engineer in Electrical Engineering at the Institut de
Sciences et Technologie in Paris.