INTERNET-DRAFT D. Turner Expires: March 18, 2004 CSU San Bernardino K. Ross Polytechnic University September 18, 2003 The Lightweight Currency Protocol draft-turner-lcp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on Mar 18, 2004. Abstract The Lightweight Currency Protocol (LCP) is a framework for creating lightweight currencies to be used by applications that rely on market forces for the allocation of scarce resources, or rely on incentives for the creation and operation of desirable services that would be otherwise impractical or infeasible through the use of real-world currencies. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Turner & Ross Expires March 18, 2003 [Page 1] Internet Draft LCP Sept 2003 1. Introduction and Overview Lightweight Currency was conceived as a means to enable the peer-to-peer resource market -- a market for computer systems to sell their unused bandwidth, storage and compute power [11]. End user applications use earned funds to purchase services built on top of this pool of distributed resources. Thus, applications may also earn money by selling derived services. Lightweight Currency is called lightweight, because it avoids the risk, complexity and cost of real-world currencies. It is thus suitable as a medium of exchange for low-value, unreliable resources provided through groups of collaborating, unrelated end systems. However, lightweight currency can also be used as a control mechanism for the allocation of resources available through the collaboration of trusted end systems. 1.1 Scope The intent of this document is to establish a standard protocol that defines the method by which currency is securely transferred between entities. 1.2 Public Key Identifiers Under the lightweight currency paradigm, entities (individuals, organizations or software agents) assume an identity by generating a public/private key pair, and using the public key as an identity. Although not required, entities MAY publish one or more public key certificates that bind its public key with one or more aliases. A given entity may have any number of public key identities. 1.3 Currency Issuers Any entity may issue a currency through its public key identifier by exposing a Web service at one or more network locations. Connecting clients use their public key identifiers to authenticate with the issuer and establish a TLS session for transport of RPC-style SOAP messages [6]. An entity holds a given currency by having an account with the currency issuer. An account is simply an entry in the issuer's database that maps the currency holder's public key to the amount of currency held. Through the Web service interface, an issuer processes two types of request messages from entities that hold the issuer's currency: a request to transfer funds to another entity, a request to obtain a list of deposits made into one's account. Turner & Ross Expires March 18, 2003 [Page 2] Internet Draft LCP Sept 2003 1.4 Transferability An entity that issues a currency SHOULD NOT restrict the use of its currency for the purchase of a service it sells, but SHOULD allow entities that hold its currency to transfer currency to other entities for transactions that occur in other application contexts. A currency issuer MAY charge a fee when transferring funds from one account to another. In this manner, currency issuers can recoup expenses related to operating its currency for use in other application contexts. This is also a mechanism that issuers can use to control their supply of money. A currency issuer SHOULD NOT restrict the set of holders of its currency, but SHOULD allow its currency to be transferable to any entity represented by any public key identifier. 1.5 Accounts A currency issuer maintains an account for each entity that holds its currency. The set of accounts maintained by a currency issuer can be thought of as a table that maps public keys to an amount of currency held. An entity holding units of a given currency can send a message to the currency issuer to have funds transferred from its account to another entity's account. Typically, a transfer occurs during a sale of resources or services; the entity that requests a transfer of funds is the buyer, and the recipient of funds is the seller. When a buying entity transfers currency to a selling entity, the currency issuer debits the buyer's account by the transfer amount and credits the seller's account by the same amount. If the issuer receives a request to transfer funds to an identity that is not in its table, the issuer creates an account for it. 1.6 Security Currency holders and issuers authenticate with each other, and establish a private, secure communication channel with TLS. A message counter is used in request messages, so that clients (currency holders) can resend messages in case real or fabricated congestion results in the client not being sure if the issuer received and acted on its request message. Clients and servers SHOULD cache TLS sessions, and clients SHOULD resume these sessions rather than initiate new ones, because resuming TLS sessions reduces the overhead resulting from asymmetric key encryption. This is important, because clients may frequently establish new TCP connections with a single currency issuer. Turner & Ross Expires March 18, 2003 [Page 3] Internet Draft LCP Sept 2003 1.7 Message Format We choose to use a SOAP message format, because of its broad support across the major development environments. Thus, lightweight currency can be easily integrated into new and existing applications with the aid of web service development tools. Additionally, the protocol can evolve more easily, because of the flexibility of XML. Although a SOAP message structure provides a relatively easy path to adoption, a binary message format would be able to reduce the size of messages, and reduce the computational overhead resulting from XML processing. Thus, a mechanism for two parties to select a binary format may be provided in a future version of this document. 1.8 Essential Value An issuer of currency may advertise a service that it provides in exchange for its own currency. The currency is thus redeemable for this service. 1.9 Not Legal Tender Lightweight currency is not intended to function as a general replacement for real-world currencies, but as an enabler of micro-payment based systems in which real-world currencies are impractical. In these systems, entities may fail to uphold contracts. In many cases, these failures are related to factors outside their control, such as network reliability. In this case, failure is not translated into legal recourse, but rather translated into diminished reputation and corresponding lowering of prices for service contracts (or complete loss of business). As an example, consider a market in which storage contracts are sold. These contracts provide the right to the buyer to write or read bytes at a rate of x currency units per megabyte over a period of 1 month. Suppose that it is believed that public key identity A1A1 fails to provide contracted read and write services with probability 0.25, and that B2B2 and C3C3 fail with probability 0.5. In this case, purchasing services from B2B2 and C3C3 will provide a combined failure rate equal to purchasing service solely from A1A1. Thus, a fair pricing scheme would set the combined price for contracts from B2B2 or C3C3 to be equal to the price for a contract from A1A1. The lightweight currency encourages this type of probabilistic pricing rather than dispute resolution accomplished through legal recourse. Turner & Ross Expires March 18, 2003 [Page 4] Internet Draft LCP Sept 2003 1.10 Anonymity One of the goals of the lightweight currency paradigm is ease of integration with new and existing services. For this reason, we avoid defining a complex protocol that provides strong anonymity. Consequently, currency issuers will be able to observe money flows between entities that are represented by public keys, but will not know what has been purchased. The issuer will also be able to ascertain the IP address of these entities. If IP anonymity is desired, entities can hide their IP addresses to issuers by using go-between entities to perform message forwarding for them. 1.11 Scope of Applications The original motivation for the design of the lightweight currency paradigm and protocol was to enable a P2P resource market. However, lightweight currencies can potentially enhance or enable other applications for which transactions with real-world currencies are desirable but impractical. These potential applications include spam reduction through payment-based email [12], content sales, and peer-to-peer lookup and proxy services. 1.12 Messages The Lightweight Currency Protocol (LCP) is comprised of 2 request messages and 2 response messages. 1.12.1 The Transfer Message A transfer-request message is sent by the buying entity to the currency issuer; it specifies a transaction ID, the amount to be transferred, a message counter and the public key of the entity to receive the funds. A transfer-funds-response message is returned by the currency issuer to the buying entity; it indicates success or failure of the transfer, and specifies the transaction fee that was applied. The purpose of the message counter in the transfer message is to allow retransmission of messages in the case that network failure or a man-in-the-middle attack results in the sender's inability to determine whether a transfer message has arrived or not. Our solution is to require a message counter, so that the sender can retransmit the message without fear that the currency issuer will execute a given transfer request more than one time. In this case, currency issuers MUST record the state of the message counter for each currency holder, and discard redundant messages. Turner & Ross Expires March 18, 2003 [Page 5] Internet Draft LCP Sept 2003 The message counter starts at zero, is incremented by one for each message sent. The message counter attains a maximum value of 1, after which it is set back to zero. The message counter applies to all messages sent from holder to issuer, that is, it applies to both transfer and query messages. In other words, there are not two separate message counters for these two messages. The reason the counter cycles between 0 and 1 rather than cycling across a wider range of values is to protect implementers from introducing the difficult-to-find bug that only occurs when the counter completes its first cycle. 1.12.2 The Query Message A query-request message is sent by the selling entity to the currency issuer when the selling entity expects funds to be transferred to it from another entity. It contains a message counter. A query-response message is returned by the currency issuer to the selling entity; it informs the seller of the amounts that have been transferred into its account since the issuer last replied to a query-request message. Additionally, the currency issuer returns the amount charged to the seller as a transaction fee for requesting a transaction report, and provides the current balance of funds in the account. Because a fee is potentially applied to process a query message, we use the same message counter that is used for the transfer request. Thus, an entity that can not determine whether a query message was processed or not can resend the message without fear of being double charged for the request. This precaution thwarts a man-in-the-middle attack in which the attacker drops packets at the right moment so as to cause the originator of the query to repeatedly resend the query message, and potentially drain his account of funds. 1.13 Example Suppose that Alice initially holds 100 units of Claire's currency. This means that Claire maintains an account for Alice in which 100 units are recorded. Furthermore, suppose that Alice wants to transfer 10 units of Claire's currency to Bob. The following steps are taken: (a) Alice initiates (or resumes) an SSL session with Claire in which both ends authenticate with each other. (b) Alice sends to Claire a transfer-request message that instructs Claire to transfer 10 units to Bob. (c) Claire debits Alice's account by 11 and credits Bob's account by 10. Claire returns a transfer-response message to Alice, specifying a transaction fee of 1 unit. (d) Bob establishes a secure, authenticated connection with Claire, and sends a query-request message. (e) Claire returns to Bob a list of deposits made to Alice's account. After transmitting the list, Claire deletes these deposit records in order to conserve space. Turner & Ross Expires March 18, 2003 [Page 6] Internet Draft LCP Sept 2003 1.14 Enabling Banking A likely derivative service is banking. With banking, a user relies on a trusted service to manage financial transactions on its behalf. This bank would provide a Web interface for users to check received payments and their balances, and also to transfer payment to other entities. To enable this service, there must be a way for the bank to assign deposits made into its accounts to the correct bank customer. Implementors can accomplish this by embedding user identifiers into the transaction-ids. Thus, transacting applications that use LCP MUST let the recipient of funds generate the transaction-id. 2 Protocol Messages 2.1 WSDL Currency issuers SHOULD publish a WSDL document [8] as a means of specifying the format of messages, and the means by which holders may interact with the issuer. The WSDL document MUST match the one in this specification, except that the wsdl:port element will be specific to the issuer. The following WSDL document is the current description of the LCP message format. Turner & Ross Expires March 18, 2003 [Page 7] Internet Draft LCP Sept 2003 Turner & Ross Expires March 18, 2003 [Page 8] Internet Draft LCP Sept 2003 2.2 Transfer Request Message We describe the elements of the message used by currency holders to transfer funds to other entities by way of an example. Suppose that Alice and Bob are two entities that have negotiated some type of purchase, and it is time for Alice to make a payment to Bob. In their negotiation, both sides agreed to a payment of 100 units of money.com currency, that is, for 100 units of the currency issued by the entity whose interface is defined by the WSDL document at http://money.com/lcp.wsdl. In the negotiation, Bob will have provided his public key identifier to Alice as the entity to whom the 100 units of money.com currency should be sent. Additionally, Bob would give Alice a transaction identifier as a means of associating her money transfer with the specific purchase activity. Alice resumes her ongoing TLS session with money.com, and sends a transferRequest message over HTTP with the following information: Bob's public key: B0CF...7E24 Amount of funds to transfer to Bob: 100 Transaction id: bob1234567890 messageCounter: 0 Money.com returns a transferResponse with the following information: Result: success Fee: 1.2 Money.com will debit Alice's account by 101.2 units, and credit Bob's account by 100 units. After this operation is performed, money.com queues a deposit notification, which is delivered to Bob when he requests a statement of deposits. Specifically, Bob resumes his SSL session with money.com, and sends a depostsRequest message with the following information: messageCounter: 0 maxWaitMilliseconds: 5000 Turner & Ross Expires March 18, 2003 [Page 9] Internet Draft LCP Sept 2003 Suppose that money.com hadn't received Alice's transfer request, and that Bob had no unretrieved deposit notifications. In this case, money.com waits up to 5 seconds before returning a response with an empty list of deposit notifications. After money.com processes Alice's transfer request, money.com returns a quesryResponse message with the following information: Deposit List: Deposit 1 TransactionId: bob1234567890 Amount: 100 End of Deposit List Balance: 9200 3. Security Considerations LCP relies on TLS [1] to provide privacy, and to protect messages from known communication threats, such as reply and tampering. Additionally, LCP relies on TLS to provide mutual authentication between LCP clients and servers. Even with TLS, it is possible for a "man in the middle" to simulate network failure at the right moment to render the client unsure as to whether a transfer (or query) operation was received and acted on by the issuer. In such a situation, the client can resend the message without fear that the issuer will perform a double transfer, because the issuer will ignor all messages without the proper value for the message counter. Normative References [1] T. Dierks and C. Allen. "The TLS Protocol Version 1.0", RFC 2246, January 1999. [2] T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler. "Extensible Markup Language (XML) 1.0 (2nd ed), W3C REC-xml", October 2000, . [3] T. Bray, D. Hollander and A. Layman. "Namespaces in XML", W3C REC-xml-names, January 1999, . [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . Turner & Ross Expires March 18, 2003 [Page 10] Internet Draft LCP Sept 2003 [6] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", June 2002, . [7] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", June 2002, . [8] R. Chinnici, M. Gudgin, J. Moreau and S. Weerawarana. "Web Services Description Language (WSDL) Version 1.2 Part 1: Core Language", W3C Working Draft 11 June 2003. [9] M. Gudgin, A. Lewis and J. Schlimmer. "Web Services Description Language (WSDL) Version 1.2 Part 2: Message Patterns", W3C Working Draft 11 June 2003. [10] J. Moreau and J. Schlimmer. "Web Services Description Language (WSDL) Version 1.2 Part 4: Bindings", W3C Working Draft 11 June 2003. Informative References [11] D. Turner and K. Ross. A lightweight currency paradigm for the P2P resource market. Submitted, Sep 2003. [12] D. Turner and Daniel Havey. Controlling spam through lightweight currency. Submitted, Sep 2003. Authors' Addresses David A. Turner Department of Computer Science California State University San Bernardino, CA 92407 Phone: +1 909 473 8678 Email: dturner@csusb.edu Web: http://csci.csusb.edu/turner/ Keith W. Ross Department of Computer and Information Science Polytechnic University Brooklyn, NY 11201 Phone: 718-260-3859 Email: ross@poly.edu Web: http://cis.poly.edu/~ross/ Expiry This draft expires on March 18, 2004 Turner & Ross Expires March 18, 2003 [Page 11]