Stories

D-Lib Magazine
January 1998

ISSN 1082-9873

Safeguarding Digital Library Contents

Charging for Online Content

Amir Herzberg
IBM Haifa Research Laboratory
Tel Aviv, Israel
[email protected]

Abstract


Charging for content is critical to the financial viability of many digital libraries as well as other (e.g. direct) providers of online content. Currently, there are a substantial number of different charging mechanisms available or proposed. We investigate the need for charging mechanisms, in particular for micropayments -- charging for small amounts. We discuss the requirements for successful charging mechanisms. We briefly describe two credit card charging mechanisms - using the SSL protocol (which is most common today) and the SET standard for charge card payments. We also describe the MiniPay micropayment mechanism for charging small amounts `per click`, and compare it to other micropayment mechanisms proposed. A bias is acknowledged for SET and MiniPay; the author was among the developers of both, and both are being produced by IBM.

1.0 Introduction

Provision of content is one of the main attractions and benefits of the Internet. Most of the content currently offered on the Internet is provided free of charge. This stands in contrast to more traditional forms of delivery of content, including other online services, where there are substantial charges. We believe that the reason that most content on the Internet is provided for free is that existing payment mechanisms are inappropriate for charging for content on the Internet, especially for small charges (often called micropayments).

The exact definition of micropayments has been the subject of considerable debate. For the purpose of this article, we will adopt the following definition: micropayments are payments whose value is too small to justify the overhead in cost and delay of a charge card transaction. In monetary terms, this translates to roughly `payments of under one dollar`, since the typical minimal charge of charge card transaction is 20-25 cents. This definition would be useful in this article, since we will consider two classes of payment mechanisms: those designed to support charge card transactions, and those designed for micropayments. It is our belief that most charges for content can (and eventually would) be satisfied by either a charge card payment or a micropayment.

Indeed, charge cards are essentially the only form of consumer payments currently in widespread use over communication networks. The most common method is providing the card number and other information over the phone. Therefore, it is relatively easy to extend charge card payments to the Internet. Indeed charge cards payments over the Internet are already quite popular (e.g. projections of a billion dollars spent this way in 1997). Direct use of charge cards over the Internet in the same way as using phone, introduces several security concerns, since the Internet is known not to provide confidentiality or authentication. This has resulted in several solutions, most notably the use of the SSL protocol to encrypt the credit card information. As will be described later, the SSL protocol leaves some security concerns, which have led to the introduction of more secure protocols designed specifically for charge card payments, most notably the SET standard. These protocols employ digital signatures over the payment order and certificates to the merchant and the customer, in addition to encryption of the card number. This provides a satisfactory mechanism for charge card payments over the Internet.

However, charge card payments involve substantial minimal fees, as well as delay, which makes them inappropriate for very small purchases. The typical minimal fee of 20-25 cents results in a minimal charge of about a dollar. As a result, other solutions must be used to finance provision of on-line content of small value. The possible solutions are:

Advertising is attractive, since it does not require any new mechanism for the content consumer, and does not require the consumer to pay. However, the revenue per view from advertising on the web is very limited, and therefore appropriate only for content with very low value `per view`, or to fund popular non-for-profit content publishing. A complete investigation of the revenue potential of advertising and related methods (such as combining the content business with product sales or commissions) is beyond the scope of this article (see [F97, IAB]). The classic means of charging the advertiser is by the number of `impressions` (users viewing the page with the ad) or number of `click throughs` (users following an ad to the site of the advertiser). CPM (cost per thousand "impressions") rates vary widely, between $1.5 and $50 [F97, MPAY97]. The higher prices go for identifiable, highly segmented, target audiences and the highly discounted rates are for highly heterogeneous random surfers. These prices translate to revenue of roughly 0.1 cent to 5 cents per view of the content. The higher prices seem to be the exception, with many indications that they may not survive for a long time. It seems fair to conclude that a prudent business plan of a content provider should not assume more then 0.5-1 cent income per view. Clearly, a large gap remains between these costs and the amounts appropriate for charging by charge card mechanisms (at least a dollar).

Packages or subscriptions of content offer convenience to consumers, who do not like to be `nickled and dimed`. The price for a package or subscription is significant enough to justify a one-time charge card transaction. However, packages and subscriptions reduce the ability of the user to pick and choose, and move a lot of the power from the consumers and producers of content to the middlemen - packagers, channels, editors, librarians. The consumer is required to trust the judgment of these middlemen, and more importantly, to decide which of a multitude of middlemen is the best deal for his or her specific needs. Furthermore, the subscription schemes makes this decision even more critical -- the consumer is committed to a choice even if new services and content will make it a poor one. As a result, we see that consumers are very hesitant to subscribe on the web or buy packages of content. It is difficult to measure this reluctance; Paul-Andrea Pays [MPAY97] has found that only 5% of the customers interested enough to enter the subscription form, actually become paying subscribers. Indeed, the indirection and commitment involved in packages and subscriptions make them less competitive and efficient mechanisms than direct payments for low value items - micropayments.

Micropayments empower both the consumer and the provider of on-line content, and return the payment problem to its proper place - as a necessary means of supporting the most desirable financing mechanism, but not as a key factor in determining the structure of the service. However, while micropayments have been discussed for many years already, their ultimate success faces substantial challenges. Clearly, a micropayment scheme must be inexpensive, involve negligible delay, and be extremely easy to use. However, a larger challenge is the requirement of (almost) universal acceptability - a consumer using a micropayment mechanism will expect that most (or all) merchants will accept this mechanism. Since merchants cannot be expected to support more than very few (one or two?) micropayment schemes, this implies that only very few micropayment schemes will be viable long-term. This makes the selection of the right micropayment scheme critical to the success of any early adopters of the technology. In addition to the technical considerations, the right scheme must offer promise to become the dominant one (or one of a pair?), and in particular, to have at least the necessary `critical mass` of content producers and consumers.

1.1 Rights Management

To conclude this introduction, we briefly discuss another security issue related to provision of content via networks - rights management. Unauthorized use and replication of information is a major concern to content owners, whether the content is a software program, text, audio, video or anything else. Technical means have been designed to prevent and detect such unauthorized use, and there is substantial research in this area. In particular, an important technique to counter unauthorized use and distribution, is by distributing the content encrypted within a secure container, e.g. Cryptolope, which is opened and used only by a trusted software of hardware module [GlLo97, IBMC, KLK97]. An important technique to detect unauthorized use is by watermarking or fingerprinting a document, to establish ownership or identify source of unauthorized duplications [GlLo97, BDG95, BS95, BLMG94] . Another relevant issue is access control to the content [G97], and there are others.

2.0 Charge Card Payment Mechanisms

Charge cards (credit and debit) are a very popular and widely available payment mechanism. Since their introduction in the early 1960s, charge cards have evolved rapidly, facilitated by ease of use, interoperability by virtue of large associations and extensive use of computer networks, and user confidence based on strong brand recognition and consumer protection mechanisms.

A unique feature of charge cards, compared to other payment mechanisms used by consumers, is the ability to use them when the seller and buyer are not collocated - by transmitting the card number on the phone (or by mail). This is referred to as a Mail Order / Telephone Order transaction (MOTO). In MOTO transactions, the signature of the buyer cannot be compared to the card (for mail) or even sent to the seller (by phone), and is therefore not available to authenticate the buyer. This results in higher possibility of fraud and arguments, and in additional restrictions, regulations and fees for MOTO transactions (cf. to traditional `face to face` transactions). The merchant wishing to accept MOTO payments has to pay higher fees and to accept responsibility for purchases denied by the cardholder.

It is possible and natural to pay with credit cards over the Web in the same way, i.e. to send the credit card number (and some related details). However, the risks involved are even higher than for `regular` MOTO transactions, due to the weak security of the Internet, and to the high speed and safety in which the fraudulent purchase attempts may be done. We note that the risk for the consumers is very limited as they are still protected. But, many consumers are still avoiding web transactions (even with better security solutions).

The solutions for secure charge card purchases attempt to reduce or eliminate the threat of an eavesdropper collecting credit card numbers sent on the web, and possibly achieve other security goals. These solutions take one of three approaches:

2.1 Secure Socket Layer (SSL) / Transport Layer Security (TLS)

The SSL (Secure Socket Layer), proposed by Netscape at late 1994 [H95], is a mechanism for encryption and authentication between a Web browser and server. A common use for SSL is to send encrypted credit card numbers, thereby obtaining level of security comparable to MOTO. The SSL protocol is very popular, and supported by almost every browser and many Web servers. The Internet's standards body, the IETF, is working on a standard based on SSL, called TLS (Transport Layer Security), and the TLS working group is expected to issue the first formal draft of the standard very soon (an informal Internet-Draft is already available). The TLS protocol improves on SSL in its cryptographic design, but does not change its functionality.

Figure 1 shows the use of SSL for securing credit card payments over an insecure network. The protocol involved the buyer, seller, and their respective charge-card banks - the issuer for the buyer and the acquirer for the seller. Just like a traditional charge card transactions, SSL sends the credit card number from the seller to acquirer and from there to the issuers. The contribution of the SSL protocol is in encrypting the card number - along with anything else - in traffic from the buyer to the seller.

Unfortunately, the use of SSL (or TLS) offers only roughly MOTO level of security; there are several remaining problems:

All these problems are due to the weak authentication offered by relying only on the secrecy of the charge card number. This motivated the design of schemes that offer better security via the use of digital signatures, such as SET and its predecessors (iKP etc.).

2.2 Secure Electronic Transactions (SET)

SET [SET] is a standard for secure charge card payments on the Web, defined by MasterCard and Visa, and supported by the majority of the financial firms and technology vendors. It is based on several different but similar proposals, including iKP from IBM [B*95], STT from Visa and Microsoft, and SEPP from MasterCard, IBM, Netscape and others. Clearly, a `standards war` almost happened, and it is now hoped that it was avoided and that SET will become the common method of payments with charge cards over the web.

An overview of the SET protocol is shown in Figure 2.

The main points are:

We note that the deployment of SET is slow. The reasons for that seems to be:

In addition, we note that SET involves substantial overhead and delay. The overhead is due to a large number (about 20) of computationally intensive public key operations, several requirements for database lookups and updates per transaction, and the communication to the issuing bank for every transaction, through the credit card network. This delay has been cited as a potential problem for SET adoption by merchants and consumers.

3. Micropayments

Charge cards involve a substantial minimal fee, about 2%, with minimal fees of about 25 cents. Furthermore, the authorization process involves substantial delay (due to the communication to the issuing bank, through the credit card network). These are significant problems for charging small amounts (cents) for information, services etc. Payments of small amounts may enable many exciting applications of the Internet, such as selling information, software and services (e.g. directory search or games). Therefore, it is important to develop payment mechanisms which would be inexpensive (in percentage) even for small amounts (say, one cent and above).For small amounts, the delay involved should also be minimized, definitely much smaller than with SET. Such payment mechanisms will be referred to in this paper as micropayments. We will focus on a specific Micropayment mechanism that we are developing called Mini-Pay, and then compare it briefly to some of the alternative proposals. A complete list of vendors, mailing lists, and other relevant resources on micropayments can be found in the `Sub-$ registry` maintained by the author (new entries welcome).

3.1 IBM's MiniPay

MiniPay is a payment mechanism developed by IBM, and is now at beta pilot phase with several customers (content providers and billing systems, which are typically Telephone companies or large Internet Service Providers). It is described in details in [HY97], and updated details are available in the MiniPay homepage .

MiniPay is focusing on the following features:

The MiniPay protocol and architecture are described in Figure 3.

The entities are the buyer, the seller, and billing systems - in the figure, as a typical example, the billing system of the buyer is the Internet Access Provider (IAP) and the billing system of the seller is a bank or an Internet Service Provider (ISP). Of course, the buyer and the seller may sometimes use the same billing server; furthermore, MiniPay allows an additional `gateway` billing server to connect between the buyer's and the seller's billing servers, for scalability. The seller is the content provider (MiniPay also allows a `mall` operator to provide the cash register function to hosted content providers).

The MiniPay protocol involves two periodic - typically daily - processes. At the beginning of every day, the buyer's wallet exchanges with its billing server the total spending for the previous day, and once the balance is synchronized, the billing server provides the wallet with a `daily credential`. This daily credential proves that the customer is a good customer as of that day; one could think of it as a new plastic card sent from the bank once every day rather than every year or so as common today.

When the customer reaches a page with a `per-fee link`, this link will display on the browser using the MiniPay plug-in, which makes it appear a bit different from `regular` links - in a rectangle rather than underlined. Furthermore, when the cursor moves over a per-fee link, its shape changes to reflect the fee - to either a cent sign or a dollar sign (other currencies can be used), where the cent is an amount under a user-defined threshold, and a dollar indicates an amount over that. When the user clicks on the per-fee link, the MiniPay plug-in piggybacks a signed payment order, and the daily credential, on the regular request for the link. Note that no new window opens - the operation is very similar to normal browsing.

The Seller software verifies the daily credential and the signature from the buyer. Following that, the seller software decides whether to perform an on-line confirmation with the billing server of the buyer. This decision is implemented currently based on the total spending by this customer on this day, and a parameter set by the merchant.

At the end of the day, an efficient deposit and clearance protocol is run between the seller and the seller's billing server, and among all billing servers.

3.1.1 Cost Factors for On-line Payments

There are many factors that contribute to the substantial minimal-fee requirement of existing payment mechanisms. In order to design a mechanism with significantly reduced costs, we need to consider -- and minimize -- each of these cost factors. Here is a list of the major cost factors, and the method for eliminating or reducing them in MiniPay.

In addition to these, it is critical to minimize the cost of publishing information and services per fee. In MiniPay, we reduce the expense and effort required to publish by an automated compiler tool, that transforms a site from existing HTML format so that some links become MiniPay links (which are not free). This allows the content provider to use any HTML authoring tool and even modify existing sites (especially attractive to sites that offer presently only subscription-based services).

3.1.2 Minimizing Delay, Computations and Storage Costs with MiniPay

Existing payment schemes have significant delay. The basic cause of the delay is the on-line authorization through the credit card network. With SET [SET], there are also many public-key and database operations per purchase, which result in substantial computation burden as well as delay.

Many of the proposals for Micropayment mechanisms have focused on completely eliminating the public key operations. However, we analyzed the actual bottlenecks when designing MiniPay and found out that the public key operations are a small fraction of the delay and certainly not the bottleneck. Indeed, the bottleneck is the communication delays - and almost all proposals and mechanisms eliminating public key operations, do this at the cost of additional communication. To be specific, typical numbers on a Pentium 166 MHz machine are:

In fact, Mini-Pay has negligible delay, and small computational overhead. Early, non-optimized implementation (on Pentium 166MHz running Windows NT) easily supported 10 transaction/second for each merchant (for both merchant and billing server). The delay at the buyer's end was completely dominated by the delays associated with following a regular HTML link with a browser (local processing time and communication delay). Amortization of communication and signature operations in the clearing process (collecting many purchase orders together).

3.1.3 Scalability and Universal Acceptance

A key requirement for successful payment systems is universal acceptability, i.e. the support of payments between any pair of buyers and sellers. Specifically, it is important to avoid restrictions such as compatible needs (e.g. barter vs. gold), direct trust (personal checks or IOU notes, vs. charge card and bank notes), physical proximity (cannot send cash over the net), or common provider for buyer and seller (key differentiator between credit card brands). Obviously, acceptability is a challenge to any new payment mechanism. The problem is more complicated as payment mechanisms must also be scaleable -- i.e., be able to support the entire Internet population -- which implies many competing offerings.

MiniPay is designed to maximize acceptability by avoiding the establishment of any central organization or server. In particular, there would be no `brand`. New billing servers would be able to offer interoperable MiniPay services, by connecting to other existing MiniPay servers. Payment orders would be routed among the servers, similar to the routing of IP packets (and to the ability to connect additional routers without centralized coordination).

Public Key Certificates in MiniPay. MiniPay uses public keys to authenticate parties (servers and wallets). This may seem to imply reliance on a centralized certification authority infrastructure, yet to be established. However MiniPay is based on peer to peer relationships, where public keys are exchanged and authenticated using the existing relationships between the peers. This allows a decentralized, open organization, following the model of the growth of the Internet itself.

Multi-Currencies Support. We decided to integrate multi-currency support into MiniPay early on, to allow interoperability among the early adopters and pilots. The support follows the MiniPay philosophy of building on the existing relationships. Specifically, the billing systems send to their buyers and sellers a table of supported currencies and exchange rates; we assume that each relationship has a specific reference currency. The MiniPay links will contain the price in several supported currencies. This may enable the wallet to chose whether to pay with its native currency (and let the seller perform the exchange if necessary), or to pay with the seller's currency (and pay according to the exchange rates of the buyer's billing system). We expect that at least one currency, probably the US dollar, would be common to most MiniPay links as well as available to most wallets.

Risk Management

MiniPay has a simple, but rather unique, risk allocation policy. The goal is to place all risk on the parties which have the most control over that risk - and where the cost and delay implications are minimal. The main risks are handled as follows:

3.2 Other Micropayment Mechanisms

In this article, we will not attempt a complete survey of the many micropayment proposals and mechanisms. However, here is a short, incomplete, and obviously biased categorization of some of the mechanisms. The focus here is on commercially available mechanisms rather than on more academic proposals or experiments.

The first group are mechanisms that place complete trust in (one) billing server. There are many such mechanisms, e.g. ClickShare, CyberCent, CyBank, etc. The advantages are simplicity in setting up the service, and the ability to avoid requiring any new client software. The drawbacks are the requirement of lots of trust in the server -- i.e., weak security; and, more critically, the fact that this obviously requires one centralized, universally trusted, entity. Since the same idea (in different flavors) has occurred to many companies, the result is lack of interoperability and market fragmentation. The fragmentation would happen even if all of the billing servers will use the same technology.

The second group are systems that avoid the use of public-key, i.e. shared-key systems. Such system try to gain efficiency by avoiding the computationally-intensive public key operations; however they end up paying a much higher performance penalty in additional communication overhead and database lookups. The communication is required to set up chain of trust from the buyer to the merchant -- public key signatures allow the trust to be established without on-line communication. Another disadvantage of these solutions is that the use of shared-key trust makes decentralization much more difficult and less efficient. The most visible example of this class of solutions is Millicent (from Digital) [G*96], which saves on communication for repeat shopping at the same store by buying store money (`scrip`). This mechanism does give some remedy to the communication overhead, when buyers actually buy repeatedly from the same seller -- however at the expense of additional complexity and inconvenience to the buyer who needs to manage all the `store money`.

The third group is that of systems employing public-key signatures in order to allow off-line (or semi-off-line) payments. MiniPay belongs to this group. Two other important systems in this group are CyberCoin and DigiCash.

CyberCoin, from CyberCash Inc., is based on one centralized server for merchants and buyers. There are now three CyberCoin servers, one in the USA, one in Japan, and one in UK, each using the local currency. No interoperability among servers is available. The CyberCash system is also designed for higher amounts (over 25 cents). The details of the protocols used in CyberCash have not been public to the best of our knowledge, and therefore it is difficult to evaluate it further.

The DigiCash solution is substantially more complex than all others, and the reason is that this solution is attempting to provide anonymous payments, and low-cost is only a secondary goal. The anonymity feature hides the identity of the specific buyers from the billing systems and sellers. Achieving this requires nontrivial cryptographic solutions with resulting overhead and complexity. In addition, since the sellers cannot identify the buyer, an on-line confirmation becomes essential -- even for repeat purchases with the same seller. This results in substantial delay per transaction.

We also note that in all systems we are aware of, except MiniPay, the per-fee link is not integrated with the browser, but involves an additional `pop-up` window on which purchases need to be confirmed.

Additional Publications on Electronic Payments

For more information, the reader is encouraged to consult some of the many publications which appeared, mostly recently, about secure payment mechanisms over communication networks and especially the Internet [AJSW97, W97, OPT97]. For more information on MiniPay, see the MiniPay homepage. For list of resources and vendors of Micropayments, see the Sub-$ registry. Discussions on Micropayments are carried on in the Micropay mailing list [MPAYL].

References

[MPAY97]Anthony Appleby, Nick Hart-Williams, Paul-Andrea Pays, Joe Shea, and others. Revenues of Ads & Reluctance to Subscribe Messages from the MicroPay Mailing List, December 1997.

[AJSW97]N. Asokan, P. Janson, M. Steiner and M. Waidner. State of the Art in Electronic Payment Systems, IEEE Computer Magazine, September 1997, Vol. 30 No. 9, pp. 28-35.

[B*95]M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik and Michael Waidner. iKP - A Family of Secure Electronic Payment Protocols, Usenix workshop on Electronic Commerce, June 1995, pp. 89-106.

[BDG95]S. Brin, J. Davis, H. Garcia-Molina. Copy Detection Mechanisms for Digital Documents, Proceedings of the ACM SIGMOD Annual Conference, San Francisco, California, May 1995.

[BS95]D. Boneh, J. Shaw. Collusion-Secure Fingerprinting for Digital Data. Technical Report 468, Computer Science Department, Princeton University, January 1995.

[BLMG94]J. Brassil, S. Low, N. Maxemumchuk, L.O. Gorman. Document Marking and Odentification Using both Line and Word Shifting. Technical Report, AT & T Bell Labs, 1994.

[C96] Clickshare Public Information Packet, http://www.clickshare.com/pubpack/.

[CC] CyberCoin, at CyberCash Inc. site. http://www.cybercash.com.

[F97] Scott Finer. Alternative Revenue Models for Television Affiliate Web Sites, to be published in The Antenna, Dec. 1997.

[G97] Henry M. Gladney. Safeguarding Digital Library Contents and Users: Document Access Control. D-Lib Magazine, June 1997.

[GlLo97]H.M. Gladney, J.B. Lotspiech. Safeguarding Digital Library Contents and Users: Assuring Convenient Security and Data Quality. D-Lib magazine, May 1997.

[G*96]Steve Glassman, Mark Manasse, Martin Abadi, Paul Gauthier, and Patrick Sobalvarro. The Millicent Protocol for Inexpensive Electronic Commerce. In proceedings of the Fourth International World Wide Web Conference, pp. 603-618. O'Reilly, December 1995.

[H95]K. Hickman. The SSL protocol, Netscape, Feb. 1995

[H97]Amir Herzberg. Developing MiniPay Billing Systems and Content/Service Merchants, presented at the Sixth WWW conference, Santa Clara, California, April 97.

[HSY97]Amir Herzberg, Anat Sarig and Hilik Yochai. Secure Payments in Java: MiniPay and JECF, presented at the MASCOT 97 International Workshop on Security and Efficiency Aspects of Java, Eilat, Israel, January 1997.

[HY97]A. Herzberg, H. Yochai. Mini-Pay: Charging per Click on the Web, presented at the Sixth WWW conference, Santa Clara, California, April 1997.

[CARI95]Information Technology Partners. Collect All Relevant Information (CARI), 1995.

[IAB]Internet Advertising Bureau.

[IBMC] IBM Cryptolope Technology - Digital Content Distribution and Delivery, at http://www.cryptolope.ibm.com/white.htm

[KLK97]Ulrich Kohl, Jeffrey Lotspiech, and Marc A. Kaplan: Safeguarding Digital Library Contents and Users: Protecting Documents Rather Than Channels. D-Lib Magazine, September 1997.

[MPAYL] The Micropay mailing list is maintained by Phil Hallam-Baker. To subscribe, send the word `subscribe` in e-mail [email protected].

[OPT97] D. O'Mahony, M. Peirce, H. Tewari: Electronic Payment Systems, Artech House, ISBN 0-89006-925-5, 1997.

[SET] Secure Electronic Transactions, MasterCard and VISA, http://www.mastercard.com/set/.

[SSBR95]L. Stein, E. Stefferud, N. Borenstein, M. Rose. The Green Commerce Model, May 1995.

[W97]P. Wayner. Digital Cash, 2nd edition, Academic Press, ISBN 0-12-738763-3, 1997.

(C) Copyright IBM Corp. 1998. All Rights Reserved. Copies may be printed and distributed, provided that no changes are made to the content, that the entire document including the attribution header and this copyright notice is printed or distributed, and that this is done free of charge.

We have written for the usual reasons of scholarly communication. This report does allude to technologies in early phases of definition and development, including IBM property partially implemented in products. However, the information it provides is strictly on an as-is basis, without express or implied warranty of any kind, and without express or implied commitment to implement anything described or alluded to or provide any product or service. IBM reserves the right to change its plans, designs, and defined interfaces at any time. Therefore, use of the information in this report is at the reader's own risk.

Intellectual property management is fraught with policy, legal, and economic issues. Nothing in this report should be construed as an adoption by IBM of any policy, position, or recommendation.

D-Lib Magazine | Current Issue | Search Comments
Previous Story | Next Story

hdl:cnri.dlib/january98-herzberg