First Virtual?

[Hal]

-----BEGIN PGP SIGNED MESSAGE-----

Mark Terka <werewolf at io.org> writes:
>Ok, so what are our options, given that this company seems to think of 
>security in terms of a plastic padlock. From corresponding posts on the
>list, the only other alternative, Digicash, doesn't seem to be too
>responsive to anyone's participation right now.

Allow me then to repost this, a summary of how some available payment
systems work.  It is oriented towards remailers but has info and pointers
to several payment systems.


- From owner-cypherpunks at toad.com  Sat Oct 29 09:35:38 1994
Date: Sat, 29 Oct 1994 09:31:27 -0700
From: Hal <hfinney at shell.portal.com>
Message-Id: <199410291631.JAA27105 at jobe.shell.portal.com>
X-To: cypherpunks at toad.com
Subject: Payment systems for remailers

This is an edited version of a posting I made to remailer-operators at c2.org,
discussing how some of the various payment systems which have recently
been introduced on the net might be used to support a for-pay remailer.
First I discussed some motivation, such as improving the quality of
service and discouraging spam attacks, then this was the part about the
various services.  If anyone knows of other alternatives please let me
know.


I know of two systems that are VISA/Mastercard based.  One is called
First Virtual (http://www.fv.com).  They are oriented towards information
sales and say that they aren't for service providers, but in practice it
looked to me like they could be used for services.  When a customer
wants to pay, he sends you his FV ID.  You send this to FV and they send
an email message to the customer asking whether he authorizes the
payment.  If he says "yes", FV credits your account.  You get a check
every month.  Customers who always say "no" get booted out of the system
(as do merchants who submit bogus bills).  They charge 29 cents plus 2
percent per transaction, but merchants can batch up multiple orders by a
single customer before sending it in.

There are a few problems with a system like this, many of which are
somewhat generic to our situation.  The most fundamental is that we
don't know who our customers are much of the time.  In fact, the whole
point of the remailer network is that we not know that fact for any case
except the first hop in the chain.  If we required customers to expose
their FV account ID at every hop, it would make it a lot easier to track
messages through the network (even if the ID's were hidden in the
encryption envelope it seems risky).  If we then sent a message to FV
saying that we needed to charge ID XXX, and FV responds with an email to
the person's home address, this offers more possibilities for tracing.

One solution would be only to charge on entry into the remailer net.
Perhaps remailer operators would even charge each other then, and the first
remailer would charge some larger amount to deal with a "typical" chain
length?  Many interesting possibilities here.

Another issue is that the overhead charges by FV would require batching
up messages before submitting them.  Let me make clear that the batch
must consist all of charges to a single user.  It doesn't do any good to
send one message to FV asking them to please charge a penny to each of
100 VISA accounts.  No, you would have to count messages from each user,
separately, and when user XXX had sent, say, $1 worth of messages, you
could send in the request to FV and get back 70 or so cents.

So this adds some overhead and record-keeping that we don't currently
have to do, although perhaps it is not so difficult.  But it would raise
new questions of authenticating FV ID's, and shares some of the negative
privacy impacts and message linking issues mentioned above.

The other VISA based system is called OpenMarket. I just read about it
tonight so I don't know it as well (http://www.openmarket.com).  It is
pretty tied to the WWW so it would not seem to work for us.  Customers
get connected to a particular WWW server which authenticates them and
charges their VISA card appropriately, then they get redirected to the
merchant with some kind of token that says they have paid.

The NetBank (email to netbank-intro at agents.com) is a digital-cash like
system.  Customers get tokens which are basically large secret numbers
which have a cash value.  They send them to the merchants, and the
merchants then send them to the bank which credits their account.  The
NetBank sends you a check every month.

The interesting thing is how customers buy the cash tokens.  One way is
by connecting to a 900 number with your modem.  They charge the customer
$10.00 and give him a digital cash token worth that much.  Another way is
by faxing a check to them.  I wasn't clear on how you get the cash token
back in that case; I guess they email it to you at an address you
specify.  From the privacy point of view, these are not that great; 900
numbers have Automatic Number Identification so unless you are willing to
tramp out to a pay phone to get your cash then it could be linked to your
phone number.  And the fax system must have some kind of return address
that would link to you.

The other problem with NetBank is that the smallest denomination which
can be spent is 25 cents.  Due to the cash-like nature of the tokens, I
don't see a natural way to accumulate several messages into one payment.
Maybe we could layer our own low-value digital cash system on top of
NetBank, where users could buy our anonymous cash for 25 cents and get
enough tokens for 25 messages, then we would settle amongst ourselves (or
actually with the anon-mail-token bank).  Actually this might help with
the privacy problems, too.  Anonymous digital cash is heavily patented,
though.

With a cash-like system, each message would include a numeric token in
the header which is the digital cash.  The remailer would strip that out
and send it in for credit.  This is a simple system and could be largely
automatic.  However there are some tricky issues about cheaters re-using
cash.

NetBank charges $4 per month, plus, for the 900-number-based cash, 20%
off of face value.

The last system I'll describe is David Chaum's DigiCash
(http://www.digicash.com).  Chaum is the inventor of digital cash and
he certainly knows his stuff, plus as I said he has the intellectual
property pretty well sewed up patent-wise.  The DC payment system is
also WWW based at present.  The customer has to be running a special
program on his computer, separate from his web browser.  This program
holds his digital cash, which is similar conceptually to the NetBank
cash but more sophisticated cryptographically.  When he wants to buy
something, the merchant's web server makes a connection to the
customer's DC program, and it transfers the cash to the merchant.

DigiCash says they are planning an email based system but for now their
emphasis is on the WWW.  Right now they are only in beta and not using
real money.  I don't know when they will be real and email based, and I
don't know if they have said what their commission will be.  But when this
comes up it may be the best approach if small-value transactions can be
supported.  DigiCash is fully anonymous in the sense that once a customer
receives the money, it is "blinded" in a special cryptographic way so
that the bank cannot associate it with that customer (and no one else
can, either).  This kind of anonymity fits in very well with our remailer
requirements.

Well, I know this is a lot of information to work through, but mostly I
want people to be aware of the possibilities.  Most of this stuff is
very, very new, only weeks old, generally.  Probably over the next few
months we will see a lot more options appear.  I am confident that there
will soon be payment systems that would provide the technical basis for
fee based remailing.  I don't expect anyone to get rich by this, but it
might help compensate for the risks we all face, and it might serve to
improve the quality of the remailer network.

Hal Finney
hfinney at shell.portal.com


-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLt+fKxnMLJtOy9MBAQG8ZgIAoBMb4Tctn56LUV1RnIkh4ENPYwTVz4Fn
b+k2Nl6hPN2UP+llyJHXDS8WTTHUAJ6rzM3oNMDtZcAXRJMBgNmPTg==
=hZYK
-----END PGP SIGNATURE-----