Must-read capabilities paper (fwd)

Lucky Green
Mon, 01 Nov 1999 21:27:07 -0800

FYI. This is from an anonymous post to Cypherpunks.

-- Lucky Green <> PGP v5 encrypted email preferred.

---------- Forwarded message ----------
Date: Mon, 1 Nov 1999 20:29:07 +0100 (CET)
From: Anonymous <>
Subject: Re: Must-read capabilities paper


The E work may be significant and important, but it always seems difficult
to pin down specific advantages that it offers.

Consider their cash example, from the paper above.  They describe a mint
which can make a "purse" which can hold funds.  The purse has a deposit
operation which takes an amount and a source purse to transfer from.
The idea is that for Alice to pay Bob, she creates a new, empty, temporary
purse, and transfers the payment amount into it.  She gives the temp purse
to Bob, and then he can transfer the amount from that purse into his own.
All is done with distributed object security.

It sounds impressive if this can be done with distributed objects,
using cryptography to secure authenticate all the steps.  However when
they describe the underlying cryptographic mechanisms, we find that the
mint must be running on its own trusted system.  All transfers are done
with requests to the mint.  Alice asks the mint to make a new purse and
transfer money into it, and the mint returns a reference to the new purse.
Alice gives the ref to Bob, and Bob then asks the mint to transfer from
that purse to his own.  This is a rather mundane approach and relies on
a trusted server to maintain account balances.

A simpler system along the same lines would have Bob giving Alice a
reference to his purse (account), subject to the rules that she can
only deposit to it, and can only withdraw from her own purse when she
authenticates herself as the owner (via PKC).  In other words, Bob gives
Alice his account number, and she asks the bank to transfer into it.
This is the standard approach for electronic payment systems.

One aspect of the E model is that users don't need to authenticate
themselves to the mint.  Each user knows a magic number which references
their purse.  By knowing that number, they have the right to access their
purse, and spend from it.  Alice gets the magic number of a new empty
purse, then sends the mint her main purse number and this purse's number,
along with the transfer amount.  Now she can send Bob the magic number
of the temporary purse, and he can then pass that to the mint along with
the number of his own purse, to get the mint to transfer into his purse.
Neither Alice nor Bob had to authenticate themselves to the mint; just
knowing the magic numbers was enough.  This is the alternate perspective
brought about by the use of capabilities.

Capabilities thus put some constraints on the design of the system,
but with sufficient ingenuity one can make systems do what is needed.
The question is whether this approach brings significant advantages over
the conventional way of doing things.  Is the promised synergy real?
How does the capability model help the crypto protocol designer, to
compensate for the limitations it imposes?

As protocol designers, and even more as protocol users, we are interested
in matters of trust and boundaries.  Which aspects of the object model
are under our control, and where are we forced to trust others?  The E
language formalism doesn't seem to lend itself to this kind of analysis.
It is not obvious who owns which objects, where the objects reside, on
whose computer they run, and how trust is spread among them.  These are
the most crucial issues in a crypto protocol or in any protocol involving
untrusting participants.

Obviously the E developers are talented and thoughtful, but more work
must be done to show that the language can be a useful tool for the
protocol designer.