Must-read capabilities paper (fwd)
Tue, 2 Nov 1999 01:09:24 -0800 (PST)
On Mon, 1 Nov 1999, Lucky Green wrote:
> FYI. This is from an anonymous post to Cypherpunks.
> -- Lucky Green <email@example.com> PGP v5 encrypted email preferred.
> ---------- Forwarded message ----------
> 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.
Here is an approximate expression of the response that comes to
mind for me. I would appreciate feedback on whether my
understanding and emphasis are correct. I am not on the Cypherpunks
list, so my primary purpose in writing this is not to respond to
the original author but to see if i have recognized the key;
however, anyone can feel free to forward this response to Cypherpunks
if they feel it is an appropriate response.
The answer to the question is "yes".
The power and flexibility of the system comes from Alice's and
Bob's abilities to construct new objects and behaviours from the
basic components -- capabilities and capability design patterns --
which they are given. The bank transfer example, as an isolated
case, can indeed be reduced to a simple transaction where Alice
tells the bank to transfer funds to an account specified by a given
number. However, Bob's account number is a permanent identifier --
a True Name -- so the flexibility ends there. Setting up more
interesting kinds of contracts between Alice and Bob would require
developing and verifying a new protocol for each kind of contract.
Using E, we can build new contracts and financial instruments
easily. Bob can create a new object which represents his
account but provides a variety of flavours of access to it --
say, a maximum transfer limit, or an expiry date, or a type of
access which incurs transaction fees. The possibilities are
limitless because the programming language is built upon the