[cap-talk] Declaring a victory - Delegation Bounds

[David Hopwood]

Valerio Bellizzomi wrote:
> On 11/08/2007, at 19.03, Jed Donnelley wrote:
> 
>> As we well know, the "pass once" mechanism for
>> 'raw' capabilities makes no sense.  It blocks the
>> development of finer grained implementations
>> of services (introducing more objects) because
>> the holder of the capability can't even communicate
>> it to new "sub" objects.

Yes. Note that 'do-not-delegate' only represents an enforceable
constraint when the subject that holds the capability is (at least
partially) confined. In that case, it cannot delegate to a subject
outside the confinement boundary without going through a component
that is able to enforce use of some delegation tracking protocol.
In all other cases, use of delegation tracking is strictly optional.

It seems increasingly clear that, in order to address many of the
most common perceived problems with capabilities, principals are
going to have to be separated by membranes. I personally think this
is an unfortunate complication -- I think that a system without
membranes would work perfectly well in practice, or at least much
better than existing non-capability systems. Hopefully, we can
reduce the overhead of membranes to a reasonable level (I'm thinking
mainly of conceptual overhead and implementation complexity, rather
than performance overhead; the latter is unlikely to be significant
even for a fairly naive implementation).

> If it is possible to do this with a counter inside a capability, it would
> become 'delegate N times'.

I don't see why a counter greater than one would be useful here.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>