[cap-talk] In defense of Object Capabilities, against non-delegatable *authority*

[Jed Donnelley]

On 12/22/2007 12:15 AM, Mark Miller wrote:

> Jed, they <Toby and Duncan in their paper:
"Non-Delegatable Authorities in Capability Systems"
http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf >
> are not doing "non-delegatable objects" or permissions. They
> are doing non-delegatable *authority*.

As this discussion seems to have died, I think I should at
least correct one thing I said with regard to the above.
Namely in:

http://www.eros-os.org/pipermail/cap-talk/2007-December/009457.html

when I said:
_________________
Why can't we waffle as I argue Alan is
doing?  We can't because it has become
abundantly clear with the coming together
of the object programming model and the
capability model that the power of this
model derives exactly from its "decomposability".
That is from the ability to break code into
pieces that can be reasoned about separately
that can communicate authorities according
to POLA.  If we support non-delegatable
capabilities we break that model.  With
non-delegatable capabilities we can't take
what was a single module/object implementation
and break it up into two or more modules/objects
with communicated authority because we might
not actually be able to communicate an
owned capability even to a new "sub" object
within our implementation.  Of course we
know that we could do so by proxying, but
then we end up always being prepared to
proxy and in fact using proxying as needed
to get around this misguided effort at
non-delegatability.
_____________

as you note, I should have instead said:
________
If we support non-delegatable
AUTHORITY we break that model.  With
non-delegatable AUTHORITY we can't take
what was a single module/object implementation
and break it up into two or more modules/objects
with communicated authority because we might
not actually be able to communicate an
owned AUTHORITY even to a new "sub" object
within our implementation.
_________

I believe this more general statement makes
the argument stronger.  I probably should also
have generalized from "code" to something
like "active domains" as I believe the same
argument (as per David Wagner, "Don't prohibit
what you can't prevent") applies to delegation
of authority between people.

The basic point is that we use capabilities
as a flexible (object oriented) representation
of permission that can be used to effect
controlled propagation of authority.  If we
ever find ourselves forced into a position of
using another representation of permission (e.g.
in a misbegotten effort to control delegation
of authority) then we break all the value
we have in the capability model for managing
authority.  While applying other models or
algorithms above the level of the delegatable
"object" (e.g. identity based access control
as with Horton) is fine, if we try to go below
the object level and break the basic object
capability paradigm for controlling the propagation
of authority (capabilities as permissions can flow
over existing capability arcs) then we break the
values that derive from the object oriented model -
most importantly decomposability - whether at
the programming level of the level of interactions
between people.

--Jed  http://www/webstart.com/jed/