>
> http://www.erights.org/elib/capability/ode/index.html
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.