On Mon, 1 Nov 1999, Lucky Green wrote:
> Mark,
> FYI. This is from an anonymous post to Cypherpunks.
>
> -- Lucky Green <shamrock@cypherpunks.to> 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 security construct.