[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Sun, 2007-07-15 at 09:18 +1000, James A. Donald wrote:
> Jonathan S. Shapiro wrote:
> > That can be read a couple of ways. If what you mean is
> > that a capability can be expressed as an unprotected
> > data value that is protected by sparsity, then I think
> > this is wrong. The result is not a "protected
> > capability system", and necessarily suffers from all
> > of the deficiencies identified by Boebert, Gligor,
> > etc.
> >
> > Conversely, if the capability itself is protected, it
> > is not clear what purpose is served by introducing
> > sparsity.
> 
> There is, or was, and e-gold system, loom, in which
> authority to obtain a certain amount of gold was
> represented by urls containing a 128 bit unguessable
> number.  When you deposited gold into the system, you
> got a large random url, which enabled you to withdraw
> gold from the system.  This seems like a capability
> system to me.  What was the deficiency?  What makes it
> not a capability system?

It is a capability system. It is NOT a protected capability system, and
therefore does not fall under what some people here are calling the
"ocap model".

The problem is that this authority can be overtly transferred over a
channel that is not authorized by a capability. Because of this, there
is no possibility of restricting the propagation of permissions.

For the objectives of e-gold, that design was perfectly satisfactory. It
is not satisfactory as a basis for a more general system.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC