One document matched: draft-turner-lcp-00.txt
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.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://lightweightcurrency.org"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://lightweightcurrency.org"
xmlns:intf="http://lightweightcurrency.org"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema targetNamespace="http://lightweightcurrency.org"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="Transaction">
<sequence>
<element name="amount" type="xsd:double"/>
<element name="id" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
Turner & Ross Expires March 18, 2003 [Page 7]
Internet Draft LCP Sept 2003
<complexType name="ArrayOfTransaction">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="impl:Transaction[]"/>
</restriction>
</complexContent>
</complexType>
<complexType name="QueryResult">
<sequence>
<element name="balance" type="xsd:double"/>
<element name="fee" type="xsd:double"/>
<element name="transactions" nillable="true"
type="impl:ArrayOfTransaction"/>
</sequence>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="queryResponse">
<wsdl:part name="queryReturn" type="impl:QueryResult"/>
</wsdl:message>
<wsdl:message name="queryRequest">
<wsdl:part name="in0" type="xsd:long"/>
<wsdl:part name="in1" type="xsd:int"/>
</wsdl:message>
<wsdl:portType name="Account">
<wsdl:operation name="query" parameterOrder="in0 in1">
<wsdl:input message="impl:queryRequest"
name="queryRequest"/>
<wsdl:output message="impl:queryResponse"
name="queryResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AccountSoapBinding" type="impl:Account">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="query">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="queryRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lightweightcurrency.org"
use="encoded"/>
</wsdl:input>
<wsdl:output name="queryResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://lightweightcurrency.org"
use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Turner & Ross Expires March 18, 2003 [Page 8]
Internet Draft LCP Sept 2003
<wsdl:service name="AccountService">
<wsdl:port binding="impl:AccountSoapBinding" name="Account">
<wsdlsoap:address
location="http://p2p-market.org/issuer/Account"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
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, <http://www.w3.org/TR/REC-xml>.
[3] T. Bray, D. Hollander and A. Layman. "Namespaces in XML", W3C
REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-
names>.
[4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>.
[5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
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, <http://
www.w3.org/TR/2002/WD-soap12-part1-20020626/>.
[7] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 2: Adjuncts", June 2002, <http://www.w3.org/
TR/2002/WD-soap12-part2-20020626/>.
[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]
| PAFTECH AB 2003-2026 | 2026-04-23 04:07:21 |