rid
`
`J
`
`0
`
`u
`
`• I
`
`R
`
`N
`
`A
`
`l
`
`Fourth International
`World Wide Web Conference
`The Web Revolution
`
`December 11-14, 1995
`Boston, Massachusetts, USA
`
`Conference Proceedings
`http:j jwww. w3.orgjWWW4/
`
`O'Reilly & Associates, Inc.
`
`PayPal Ex.1013, p.1
`
`

`
`WORLD WIDE WEB jOURNAL
`~~8IsSUE ONE: CONFERENCE PROCEEDINGS, FOURTH INTERNATIONAL WORLD WIDE WEB CONFERENCE
`
`Copyright Information:
`
`The individual contributions are copyrighted by the authors or their respective employers.
`The print compilation is Copyright © 1995 O'Reilly & Associates, Inc. All rights reserved.
`Printed in the U.S.A.
`
`Printing History:
`
`November 1995: First Edition
`
`Many of the designations used by manufacturers and sellers to distinguish their products are
`claimed as trademarks. Where those designations appear in this book, and O'Reilly & Associates,
`Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps.
`
`While every precaution has been taken in the preparation of this book, the publisher assumes no
`responsibility for errors or omissions, or for damages resulting from the use of the information
`contained herein.
`W
`This book is printed on acid-free paper with 85% recycled content, 15% post-consumer
`f).- -:\) waste. O'Reilly & Associates is committed to using paper with the highest recycled content
`'CJ<;:J available consistent with high quality.
`
`ISSN: 1085-2301
`
`ISBN: 1-56592-169-0
`
`PayPal Ex.1013, p.2
`
`

`
`T H E
`
`W 0 R L D
`
`w
`
`D E
`
`W E 8
`
`J 0 U R N A L
`
`C 0 N T E N T S
`
`SURVEY
`
`Results from the Third WWW User Survey ................................................................. l
`James E. Pitkow, Colleen M. Kehoe
`
`COLLABORATIVE SYSTEMS
`
`The Open Meeting: A Web-Based System for Conferencing and Collaboration ... 15
`Roger Hurwitz, John C. Mallery
`
`Using Versioning to Provide Collaboration on the WWW ....................................... 37
`Fabio Vitali, David G. Durand
`
`Group Asynchronous Browsing on the World Wide Web ........................................ 51
`Kent Wittenburg, Duco Das, Will Hill, Larry Stead
`
`Supporting Collaborative Information Sharing with the vVWW:
`The BSCW Shared Workspace System ....................................................................... 63
`Richard Bentley, Thilo Horstmann, Klaas Sikkel, Jonathan Trevor
`
`OBJECTS ON W3
`
`A Web of Distributed Objects ..................................................................................... 75
`Owen Rees, Nigel Edwards, Mark Madsen, Mike Beasley, Ashley McClenaghan
`
`W30bjects: Bringing Object-Oriented Technology to the Web .............................. 89
`David Ingham, Mark Little, Steve Caughey, Santosh Shrivastava
`
`CACHING
`
`Making World Wide Web Caching Servers Cooperate ........................................... 1 07
`Radhika Malpani, Jacob Lorch, David Berger
`
`Caching Proxies: Limitations and Potentials .......................................................... 119
`Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, Stephen Williams, Edward A. Fox
`
`RESOURCE DISCOVERY
`
`IAFA Templates in Use as Internet Metadata ......................................................... 135
`Dave Beckett
`
`vii
`
`PayPal Ex.1013, p.3
`
`

`
`A World Wide Web Resource Discovery System ..................................................... 145
`Budi Yuwono, Savio L. Y. Lam, Jerry H. Ying, Dik L. Lee
`
`The Krakatoa Chronicle: An Interactive Personalized Newspaper
`on the Web ................................................................................................................ 159
`Tomonari Kamba, Krishna Bharat, Michael C. Albers
`
`Web Map: Concept Mapping on the Web ............................................................... 171
`Brian R. Gaines, Mildred L. G. Shaw
`
`TOOLS FOR BUILDING WEBS OVER DATABASES
`
`Swoop: An Application Generator for ORACLE/WWW Systems .......................... 185
`Andrew Hunter, Jan Ferguson, Steven Hedges
`
`Multi-Engine Search and Comparison Using the MetaCrawler ............................ 195
`Erik Selberg, Oren Etzioni
`
`DB: Browsing Object-Oriented Databases over the Web ........................................ 209
`C. Varela, D. Nekhayev, P. Chandrasekharan, C. Krishnan, V. Govindan, D. Modgi/,
`S. Siddiqui, D. Lebedenko, M. Winslett
`
`W3 APPLIED TO EDUCATION
`
`Toward a New Educational Environment ............................................................... 221
`Ming-Chih Lai, Bih-Horng Chen, Shyan-Ming Yuan
`
`CyberProf: An Intelligent Human-Computer Interface for Asynchronous
`Wide Area Training and Teaching .......................................................................... 231
`Alfred W. Hubler, Andrew M. Assad
`
`A Modular Training System for Education in the WWW Environment.. .............. 239
`U. Schroeder, B. Tritsch, A. Ktjerriem-Jasnoch
`
`A WWW Learning Environment for Mathematics .................................................. 251
`Kostadin Antchev, Markku Luhtalahti, Jari Multisilta, Seppo Pohjolainen, Kari Suomela
`
`W3 SOFTWARE DESIGN TECHNIQUES
`
`WWW Meets Linda: Linda for Global WWW-Based Transaction
`Processing Systems .................................................................................................... 259
`Werner J. Schoenfeldinger
`
`Interface-Parasite Gateways ...................................................................................... 277
`Robert A. Barta, Manfred Hauswirth
`
`viii
`
`World Wide Web Journal
`
`PayPal Ex.1013, p.4
`
`

`
`MEDIA
`
`Not Just Decoration: Quality Graphics for the Web ............................................... 291
`Chris Lilley
`
`Bringing Music to the Web ....................................................................................... 309
`Jacco van Ossenbruggen, Anton Eliens
`
`Polymap: A Versatile Client-Side Image Map for the Web ..................................... 315
`Cheong S. Ang, Michael D. Doyle, Peter Brantley
`
`Translating ISO 12083 Mathematical Markup for Electronic Documents ........... 323
`Roger Thompson, Keith Shafer
`
`Real-Time Video and Audio in the World Wide Web ............................................. 333
`Zhigang Chen, See-Mong Tan, Roy H. Campbell, Yongcheng Li
`
`Lessons for the World Wide Web from the Text Encoding Initiative .................... 349
`David T. Barnard, Lou Burnard, Steven J. DeRose, David G. Durand,
`C. M. Sperberg-McQueen
`
`MOBILE CODE
`
`Omniware: A Universal Substrate for Web Programming ..................................... 359
`Steven Lucca, Oliver Sharp, Robert Wahbe
`
`Low Level Security injava ........................................................................................ 369
`Frank Yellin
`
`SECURITY
`
`CCI-Based Web Security: A Design Using PGP ....................................................... 381
`Judson D. Weeks, Adam Cain, Briand Sanderson
`
`Securing the World Wide Web: Smart Tokens and Their Implementation .......... 397
`Michael F. Jones, Bruce Schneier
`
`CLIENT-SIDE TECHNIQUES
`Introducing Candleweb and A (awe), Bringing Animation Power
`to the World Wide Web ............................................................................................ 411
`Kjell ffystein Arisland, Svein Arne Johansen, Gunnar RRJnning
`
`Local Control over Filtered WWW Access .............................................................. .423
`Brenda S. Baker, Eric Grosse
`
`World Wide Web Journal
`
`ix
`
`PayPal Ex.1013, p.5
`
`

`
`Multi-Head Multi-Tail Mosaic .................................................................................. 433
`Brian C. Ladd, Michael V. Capps, P. David Stotts, Rick Furuta
`
`Mobile GUIon the Web ........................................................................................... 441
`Daniel Dardailler
`
`Using Graphic History in Browsing the World Wide Web .................................... .451
`Eric Z. Ayers, John T. Stasko
`
`AGENTS
`
`An HTTP-Based Infrastructure for Mobile Agents ................................................ .461
`Anselm Lingnau, Oswald Drobnik, Peter Dome/
`
`Jasper: Communicating Information Agents for WWW ........................................ 473
`John Davies, Richard Weeks, Mike Revett
`
`Constellation: A Web-Based Design Framework for Developing
`Network Applications ............................................................................................... 483
`Nino Vidovic, Dalibor F. Vrsalovic
`
`HYPERTEXT AND LINKING
`
`Linking in a Global Information Architecture ...................................................... .493
`Karen R. Sol/ins, Jeffrey R. Van Dyke
`
`Commercial Hypertext Publishing: Electronic Books Using Trails
`and the Author-Publisher-Reader Model ............................................................... 509
`Leslie D. Cuff
`
`Ingrid: A Self-Configuring Information Navigation Infrastructure ...................... 519
`Paul Francis, Takashi Kambayashi, Shin-ya Sato, Susumu Shimizu
`
`APPLICATION BUILDING TOOLS
`
`Application-Specific Proxy Servers as HTTP Stream Transducers ........................ 539
`Charles Brooks, Murray S. Mazer, Scott Meeks, Jim Miller
`
`Dyna Web: Integrating Large SGML Repositories and the WWW ......................... 549
`Gavin Thomas Nicol
`
`RMC: A Tool to Design WWW Applications ........................................................... 559
`Alicia DTaz, Tomas lsakowitz, Vanesa Maiorana, Gabriel Gilabert
`
`X
`
`World Wide Web Journal
`
`PayPal Ex.1013, p.6
`
`

`
`Programming the Web: An Application-Oriented Language
`for Hypermedia Service Programming ................................................................... 567
`David A. Ladd, Christopher Ramming
`
`PAYMENT
`
`Scalable, Secure, Cash Payment for WWW Resources
`with the Pay Me Protocol Set .................................................................................... 587
`Michael Peirce, Donal O'Mahony
`
`The Millicent Protocol for Inexpensive Electronic Commerce ............................. 603
`Steve Glassman, Mark Manasse, Martin Abadi, Paul Gauthier, Patrick Sobalvarro
`
`AUTHORING TOOLS
`
`A Schema-Based Approach to HTML Authoring ................................................... 619
`Marcus Kesseler
`
`Rules for Extending a WWW Client: The Symposia API.. ...................................... 633
`Jean Paoli
`
`The Distributed Link Service: A Tool for Publishers, Authors, and Readers ....... 647
`Leslie Carr, David De Roure, Wendy Hall, Gary Hill
`
`Structured Cooperative Authoring on the World Wide Web ................................ 657
`Dominique Decouchant, Vincent Quint, Manuel Romero Salcedo
`
`The Boomerang White Paper: A Page as You Like It ............................................. 667
`Curtis E. Dyreson, Anthony M. Sloane
`
`NOVEL APPLICATIONS FOR W3
`
`A World Wide Web Telerobotic Remote Environment Browser ............................ 677
`Eric Paulos, John Canny
`
`Data Transport Within the Distributed Oceanographic Data System ................... 691
`James Gallagher, George Milkowski
`
`Requirements for Taking Applications Beyond the Enterprise ............................. 703
`Graeme Port, Clifford Heath, Tim Segall, Phillip Merrick
`
`World Wide Web Journal
`
`xi
`
`PayPal Ex.1013, p.7
`
`

`
`BEST PAPERS FROM REGIONAL CONFERENCES
`
`Classifying Internet Objects ..................................................................................... 711
`F. Luis Neves, Jose N. Oliveira
`
`A Generic Map Interface to Query Geographic Information Using
`the World Wide Web ................................................................................................. 723
`David Crossley, Tony Boston
`
`xii
`
`World Wide Web Journal
`
`PayPal Ex.1013, p.8
`
`

`
`SCALABLE, SECURE CASH PAYMENT
`FOR WWW RESOURCES WITH THE
`FAYME PROTOCOL SET
`
`Michael Peirce, Donal OMahony
`
`Abstract
`Tbe use of the W1VW as an electronic marketplace is increasing, and there is a need for a cash payment
`system that is scalable, anonymous, and secure. In this paper we examine two existing systems, Ecash
`and NetCash, discuss their strengths and weaknesses and propose a new system called the FayMe
`Tran~fer Protocol (PMTP). We show how it improves on existing systems and illustrate its use with an
`example based on purchase of goods across the W1VW. Keywords: Web payment, electronic cash,
`secure payment, scalable payment, Internet payment mechanism~~ security
`
`Introduction
`The World Wiele Web has potential to become a
`highly efficient electronic marketplace for goods
`and services. When payments are effected elec(cid:173)
`tronically, there is always a risk that organizations
`may resort to gathering information relating indi(cid:173)
`viduals with the amounts that they have spent,
`locations involved, and types of good purchased.
`Misuse of such information can give rise to seri(cid:173)
`ous breaches of personal privacy [18]. If a pay(cid:173)
`ment system for the WWW is to receive wide(cid:173)
`spread support, it must offer its users some form
`of protection against the gathering of such infor(cid:173)
`mation. The most effective method of achieving
`this is to implement a form of electronic cash,
`where the coins being spent cannot be linked
`with their owner. This gives rise to a secondary
`problem in that since the coin is an electronic
`quality that is easily duplicated, such a payment
`system must guard against the coin being spent
`more than once. It should not be possible for an
`attacker to bypass the system or to falsely obtain
`monetary value from it.
`
`At the time of writing, it has been estimated that
`there may be over 30 million users of the Internet
`spread across 96 different countries [12] using
`over 6.6 million host computers [15], and these
`figures are rising very rapidly. This means that an
`
`effective electronic payment system must be
`highly scalable. In practice, the system must sup(cid:173)
`port large numbers of buyers and sellers affiliated
`to many different banks. The problem of detec(cid:173)
`tion of double spending is particularly acute, and
`solutions must be found that allow for large num(cid:173)
`bers of payments to take place without requiring
`unreasonably large databases to be maintained.
`In the following section, we discuss related work
`on two systems for electronic payment and go on
`to propose a new set of protocols that surmounts
`some of their inherent problems.
`
`Related Work
`Recently, two electronic cash systems, requiring
`no additional hardware such as smart cards,
`which can be used to make payments for WWW
`resources have been published.
`
`The first, Ecash, is a fully anonymous electronic
`cash system, using numbered bank accounts and
`blind signatures. The second, NetCash, uses iden(cid:173)
`tified electronic cash giving a more scalable but
`less anonymous system.
`
`Electronic cash is the electronic equivalent of real
`paper cash, and can be implemented using pub(cid:173)
`lic-key cryptography, digital signatures, and blind
`signatures. In an electronic cash system there is
`
`World Wide Web Journal
`
`587
`
`PayPal Ex.1013, p.9
`
`

`
`usually a bank, responsible for issuing currency,
`customers who have accounts at the bank and
`can withdraw and deposit currency, and mer(cid:173)
`chants who will accept currency in exchange for
`goods or a service. Evety customer, merchant,
`and bank has its own public/private key pair.
`The keys are used to encrypt, for security, and to
`digitally sign, for authentication, blocks of data
`that represent coins. A bank digitally signs coins
`using its private key. Customers and merchants
`verify the coins using the bank's widely available
`public key. Customers sign bank deposits and
`withdrawals with their private key, and the bank
`uses the customer's public key to verify the sig(cid:173)
`nature.
`
`Ecash from DigiCash
`Ecash [9, 10) is a fully anonymous electronic cash
`system, from a company called Digicash, whose
`managing director is David Chaum, the inventor
`of blind signatures and many electronic cash pro(cid:173)
`tocols[l, 2, 3, 4, 5, 61. It is an online software
`solution that implements fully anonymous elec(cid:173)
`tronic cash using blind signature techniques.
`
`The Ecash system consists of three main entities:
`
`• Banks who mint coins, validate existing
`coins and exchange real money for Ecash
`
`• Buyers who have accounts with a bank,
`from which they can withdraw and deposit
`Ecash coins
`
`• Merchants who can accept Ecash coins in
`payment for information or hard goods. It is
`also possible for merchants to run a pay-out
`service where they can pay a client Ecash
`coins.
`
`Ecash is implemented using RSA public-key ctyp(cid:173)
`tography. Every user in the system has their own
`public/private key pair. Special client and mer(cid:173)
`chant software is required to use the Ecash sys(cid:173)
`tem. The client software is called a "cyberwallet"
`and is responsible for withdrawing and deposit(cid:173)
`ing coins from a bank and paying or receiving
`coins from a merchant.
`
`Withdrawing Ecash Coins
`To make a withdrawal from the bank, the user's
`cyberwallet software calculates how many digital
`coins of what denominations are needed to with(cid:173)
`draw the requested amount. The software then
`generates random serial numbers for these coins.
`The serial numbers are large enough so that
`there is very little chance that anyone else will
`ever generate the same serial numbers. Using a
`100-digit serial number usually guarantees this.
`The serial numbers are then blinded using the
`blind signature technique [3). This is clone by
`multiplying the coins by a random factor. The
`blinded coins are then packaged into a message,
`digitally signed with
`the user's private key,
`encrypted with the bank's public key, and then
`sent to
`the bank. The message cannot be
`decrypted by anyone but the bank.
`
`When the bank receives the message, it checks
`the signature. The withdrawal amount can then
`be debited from the signature owner's account.
`The bank signs the coins with a private key.
`
`After signing the blind coins, the bank returns
`them to the user, encrypted with the user's public
`key. The user can then decrypt the message and
`unblind the coins by dividing out the blinding
`factor. Since the bank couldn't see the serial
`numbers on the coins it was signing there is no
`way to now trace these coins back to the user
`who withdrew them. In this way the cash is fully
`anonymous.
`
`Spending Ecash
`To spend Ecash coins, the user starts up their
`cyberwallet software and a normal Web client
`and then browses the Web until they find a mer(cid:173)
`chant shop selling goods. The Ecash software can
`be used with any existing Web client and Web
`server software. A merchant shop is simply an
`HTML document with URLs representing the
`items for sale. To buy an item the user selects the
`URL representing that item. The following steps
`then occur as shown in Figure 1.
`
`588
`
`Fourth International World Wide Web Conference Proceedings
`
`PayPal Ex.1013, p.10
`
`

`
`0 Send Coins
`Cyberwallet
`'--~~~--------------0 Receipt
`0 Merchant
`invoked
`
`0 Goods
`
`O Request URL - - - - - - - - - - - - - -+1
`Jlr-1---------- 0 Goods returned by Web Server
`
`Figure 1:
`
`Making a purchase with Ecash
`
`The numbered items in Figure 1 are explained in
`more detail here:
`
`1. The user's Web client sends an HTTP mes(cid:173)
`sage requesting the URL to the Merchant's
`normal Web server. This URL will invoke a
`Common Gateway Interface (CGI) program
`[19).
`
`2. The CGI program invoked will be the mer(cid:173)
`chant Ecash software, and it will be passed
`details of the item selected encoded in the
`URL. The
`location of the buyer's host
`machine will also be passed in an environ(cid:173)
`ment variable from the server to the mer(cid:173)
`chant Ecash software.
`
`3. The merchant software now contacts the
`buyer's wallet using a TCP/IP connection,
`asking it for payment.
`
`4. When the cyberwallet receives this request,
`it will prompt the user, asking them if they
`wish to make the payment. If they agree, the
`cybe1wallet will gather together the exact
`amount of coins and send this as payment to
`
`the merchant. The coins will be encrypted
`with the merchant's public key so that only
`the merchant can decrypt them:
`
`{Coins}K[public,Merchant]
`
`If they disagree or do not have the exact
`denominations necessary to make a correct
`payment, the merchant is sent a payment
`refusal message.
`
`5. When the merchant receives the coins in
`payment, he must verify that they are valid
`coins, and have not been double spent. To
`do this he must contact the bank, as only the
`minting bank can tell whether coins have
`been spent before or not. Thus the merchant
`packages the coins, signs the message with
`his private key, encrypts the message with
`the bank's public key, and sends it to the
`bank.
`
`{{Coins}K[private,Merchant]}K[public,Bank)
`
`6. The bank validates the coins by checking
`the serial numbers with the large online
`database of all the serial numbers ever spent
`
`World Wide Web Journal
`
`589
`
`PayPal Ex.1013, p.11
`
`

`
`and returned to the bank. If the numbers
`appear in the database then they are not
`valid, since they have been spent before. If
`the serial numbers don't appear in the data(cid:173)
`base, and have the bank's signature on
`them, then they are valid. The value of the
`coins are credited to the merchant's account.
`The coins are destroyed, and the serial num(cid:173)
`bers added to the database of spent coins.
`Thus coins are good for one transaction
`only. The bank notifies the merchant of the
`successful deposit.
`
`7. Since the deposit was successful, the mer(cid:173)
`chant was paid, and a signed receipt is
`returned to the buyer's cyberwallet.
`
`8. The purchased item, or an indication of suc(cid:173)
`cessful purchase of hard goods, is then sent
`from the merchant Ecash software to the
`Web Server.
`
`9. The Web server forwards this information to
`the buyer's Web client.
`
`Ecash client and merchant software is available
`for many platforms. Currently no real money is
`used in the system, but an Ecash trial [11] with
`10,000 participants, each being given 100 "cyber(cid:173)
`bucks" for free has been running since late 1994.
`There are many sample Web shops at which to
`spend cyberbucks.
`
`Advantages and Failings
`The strengths of Ecash are its full anonymity and
`security. The electronic cash used is untraceable,
`due to the blind signatures used when generating
`coins.
`
`By employing secure protocols using RSA public(cid:173)
`key cryptography, the Ecash system is safe from
`eavesdropping, and message tampering. Coins
`cannot be stolen while they are in transit. How(cid:173)
`ever,
`the protection of coins on the
`local
`machine could be strengthened by password
`protection and encryption.
`
`people start using the system, the size of this
`database could become very large and unman(cid:173)
`ageable. Keeping a database of the serial number
`of evety coin ever spent in the system is not a
`scalable solution. Digicash plans to use multiple
`banks each minting and managing their own cur(cid:173)
`rency with interbank clearing to handle the prob(cid:173)
`lems of scalability. It seems likely that the bank
`host machine has an internal scalable structure so
`that it can be set up not only for a 10,000 user
`bank, but also for a 1,000,000 user bank. Under
`the circumstances, the task of maintaining and
`querying a database of spent coins is probably
`beyond today's state-of-the-art database systems.
`
`NetCash
`NetCash [13, 14] is a framework for electronic
`cash developed at the Information Sciences Insti(cid:173)
`tute of the University of Southern California.
`Many of the ideas used in PayMe came from the
`NetCash proposal. It uses identified online elec(cid:173)
`tronic cash. Although the cash is identified there
`are mechanisms whereby
`coins
`can be
`exchanged to allow some anonymity. The system
`is based on distributed currency setvers where
`electronic checks, such as NetCheque [16, 22] can
`be exchanged for electronic cash. The use of
`multiple currency servers allows the system to
`scale well.
`
`The NetCash system consists of buyers, mer(cid:173)
`chants, and currency servers. An organization
`wishing to set up and manage a currency server
`obtains insurance for the new currency from a
`central certification authority. The currency
`server generates a public/private key pair. The
`public key is then certified by being signed by
`the central authority. This certificate contains a
`certificate ID, name of the currency server, cur(cid:173)
`rency server's public key, issue date, and an
`expiry date, all signed by the central authority:
`
`{Certif_id,CS_name,K[public,CS],issue_date,exp_
`date}K[private,Auth]
`
`The main problem with Ecash may be the size of
`the database of spent coins. If a large number of
`
`The currency server mints electronic coins, which
`consist of:
`
`590
`
`Fourth International World Wide Web Conference Proceedings
`
`PayPal Ex.1013, p.12
`
`

`
`0 {Coins, SKBuy Kauy S_id}KM
`
`0 {Coins, SKM, transJKcs
`
`Currency Server
`cs
`
`O {{amount, tr_id, date}KM- 1JSK8uy
`
`f) {new_coins}SKM
`
`Figure 2:
`
`Purchasing from a merchant using NetCash
`
`• Currency server name. Identifies a currency
`server.
`
`• Currency server network address. Where the
`currency server can be found; if this address
`is no longer in use, a name server can be
`queried to find the current address.
`
`• Expiry date. Limits the state that must be
`maintained by each currency server.
`
`• Serial number. Uniquely identifies the coin.
`
`• Coin value. Amount coin is worth. The coin
`is signed with the currency server's private
`key:
`{CS_name,CS_addr,exp_date,serial_
`num,coin_ va!lK[private, CS]
`
`The currency server keeps track of the serial
`numbers of all outstanding coins. In this way
`double spending can be prevented by checking a
`coin's serial number with the currency server at
`the time of purchase (or exchange). If the coin's
`serial number is in the database, it has not been
`spent already and is valid. When the coin is
`checked the serial number is then removed from
`the database. The coin is then replaced with a
`new coin (coin exchange).
`
`An electronic check can be exchanged with a
`currency server for electronic coins. The currency
`server is trusted not to record to whom the coins
`are issued. To further aid anonymity a holder of
`coins can go
`to any currency server and
`exchange valid coins for new ones. The currency
`server does not know who is exchanging coins,
`
`only the network address of where they are com(cid:173)
`ing from. By performing the exchange and by
`choosing any currency server to do this with, it
`becomes dift1cult to track the path of the coins. If
`a currency server receives coins that were not
`minted by it, it will contact the minting currency
`server to validate those coins.
`
`Figure 2 shows how a buyer uses NetCash coins
`to purchase an item from a merchant. In this
`transaction the buyer remains anonymous since
`the network
`the merchant will only know
`address of where the buyer is coming from. Net(cid:173)
`Cash assumes that the buyer has or can obtain
`the public key of the merchant, and that the mer(cid:173)
`chant has the public key of the currency server.
`
`Implementation details of how the NetCash pro(cid:173)
`tocols might be linked with applications such as
`the Web are not available, but it could be done
`in a similar fashion to Ecash using an out-of-band
`communications channel. The transaction con(cid:173)
`sists of the following four steps, starting from
`when the buyer attempts to pay the merchant:
`
`1. The buyer sends the electronic coins in pay(cid:173)
`ment, the identifier of the purchased ser(cid:173)
`vice(S_id), a freshly generated secret key
`(SK[Buyer]), and a public session key
`(K[public,Buyer]), all encrypted with
`the
`Merchant's public key, to the merchant.
`
`{Coins,SK[Buyer],K[public,Buyer],S_id}K[pub(cid:173)
`lic,Merchant]
`
`The message can't be eavesdropped on or
`tampered with. The secret key is used by the
`
`World Wide Web Journal
`
`591
`
`PayPal Ex.1013, p.13
`
`

`
`merchant to establish a secure channel with
`the buyer later. The public session key is
`later used to verify that subsequent requests
`originate from the buyer who paid for the
`service.
`
`the
`that
`to check
`2. The Merchant needs
`received coins are valid. To do this he sends
`them to the currency server to be exchanged
`for new coins or for a check. The merchant
`generates a new symmetric session key
`SK[Merchant] and sends this along with the
`coins and the chosen transaction type to the
`currency se1ver. The whole message
`is
`encrypted with the server's public key so
`that only it can see the contents:
`
`(Coins,SK[Merchant],transaction_typelK[pub(cid:173)
`lic,CS]
`
`3. The Currency server checks that the coins
`are valid by checking its database. A valid
`coin is one whose serial number appears in
`the database. The server will then return
`new coins or a check to the merchant,
`encrypted with the merchant's session key:
`
`(New _coinslSK[Merchant]
`
`4. Having received new coins (or a check) the
`merchant knows that he has been properly
`paid by the buyer. He now returns a receipt,
`signed with his private key and encrypted
`with the buyer's secret key:
`
`((Amount, transaction_id, date l K[private,Mer(cid:173)
`chantllSK[Buyer]
`
`The buyer can then use the transaction iden(cid:173)
`tifier and the public session key to obtain
`the service purchased.
`
`This is the basic purchase protocol used in Net(cid:173)
`Cash. While it prevents double spending it does
`not protect the buyer from fraud. There is noth(cid:173)
`ing to stop the merchant spending the buyer's
`coins without providing a receipt.
`
`Extensions to the protocol are detailed in [14].
`These are more complex and give protection
`against fraud for both the merchant and buyer.
`
`There are also mechanisms to allow the merchant
`to be fully anonymous to the buyer. Partially
`offline protocols where the bank does not need
`to be contacted during a purchase are also
`described. These, however, rely on the buyer
`contacting the currency server beforehand, and
`knowing who the merchant is at that time. They
`use a time window in which the coins are only
`valid for certain short lengths of time. Full techni(cid:173)
`cal details are given in [14].
`
`The advantages of NetCash are that it is scalable
`and secure. It is scalable since multiple currency
`servers are present and security is provided by
`the cryptographic protocols used. Possible disad(cid:173)
`vantages of the system are that it uses many ses(cid:173)
`sion keys and in particular public key session
`keys. To generate a public key of suitable length
`to be secure takes a very large amount of time
`compared with that involved in generating a
`symmetric session key. This could compromise
`the performance of the system as a whole.
`
`NetCash is not fully anonymous, unlike Ecash. It
`is difficult but not impossible for a currency
`server to keep records of who it issues coins to
`and who it receives them back from. The ability
`to exchange coins and use any or multiple cur(cid:173)
`rency servers increases the anonymity of the sys(cid:173)
`tem.
`
`A NetCash system is currently being imple(cid:173)
`mented, but no details are given as to how it will
`be linked with applications such as the Web.
`NetCheque will be used to provide checks that
`can be used to buy coins or that can be issued
`when coins are traded in.
`
`Discussion
`The two payment systems outlined each have
`their strengths and weaknesses. Ecash is a fully
`secure system that provides for very strong ano(cid:173)
`nymity. The use of banks within the system
`reflects current practice in nonelectronic payment
`systems. Successful operation of the Ecash sys(cid:173)
`tem depends on the maintenance of a central
`database of all coins ever issued within the sys-
`
`592
`
`Fourth International World Wide Web Conference Proceedings
`
`PayPal Ex.1013, p.14
`
`

`
`tern. If it were to become accepted as a global
`payment system, this would quickly become a
`major problem.
`
`NetCash uses identified coins with multiple cur(cid:173)
`rency servers, and thus, while anonymity is main(cid:173)
`tained, there is only a requirement to keep track
`of all currency currently in circulation. This
`makes for a much more scalable solution to the
`payment problem. NetCash is also fully secure,
`and achieves this using protocols that are quite
`complex in nature.
`
`The PayMe Protocol Set
`In an attempt to combine the best features of the
`two systems described, a new payment system
`called the FayMe Protocol Set was devised. A
`major goal was to preserve as much of the ano(cid:173)
`nymity provided by Ecash while adopting many
`of the features of NetCash that allow it to scale to
`large numbers of users with multiple banks. In
`the following sections, we will discuss the overall
`design of the protoc