[cap-talk] delegatable-with-probable-cost capabilities

Jed Donnelley jed at nersc.gov
Tue Jan 29 14:48:29 EST 2008

On 1/28/2008 10:30 AM, Ross McGinnis wrote:
> For me there is a definite distinction between
> low and high security in people-people networks: 
> low security is normal everyday exchange that
> occurs over the normal undefined and non-restricted
> communication channels high security is the rare
> exchange that occurs between confined people over
> fully defined and knowingly restricted communication
> channels.
> For access control in the low-security network we
> have basically two options: password cap and ACLs.
> Society has chosen to use mainly password caps.  I 
> argue that there is a real benefit gained in many
> circumstances by being able to control a password 
> cap's copying/delegation- Examples of Password
> Caps in everyday life: phone numbers, email addresses,
> movie tickets, bus tickets, car keys, house keys,
> night-club reentry stamps, ISBN of a book (to
> retrieve it at a library), the serial no. of a car
> part (to order the part at a spare-parts shop), etc,
> etc, etc.  These can all be modeled as Password
> Caps due to the fact that: 1)They are all that the
> bearer is required to have to be able to access the
> service/object that they reference, 2)These caps are
> all exchanged over an totally unconfined network of people.
> In all of these examples (except the last two) it
> is either required or would be beneficial in particular
> circumstances that they are not -copyable and/or delegatable-.
> Examples of Access Control List: swanky member only
> clubs that control access with patron list, etc.
> None of these examples can ever be re-modeled usefully
> by Object Caps because of the fact that the objects are
> not exchanged/accessed over confined networks.  In
> the networks that these objects are exchanged over
> everybody is connected to everybody else.  In this
> respect they are everyday low security systems.
> To summarise my stance: 
> - Non-confined (universally connected) network <-> everyday
> low security -> password caps (which in many cases gain
> utility by having controls placed on their copying/delegation)
> or ACLs.  - Defined and confined network <-> high security ->
> object caps (which should always be delegatable) or maybe
> in a very, very few cases ACLs.

I've been following this thread with interest, watching
where the discussion goes.

One thing I'd like to suggest - while I think the physical
examples/analogs can have some value (bus tickets, car keys,
etc.), I think it important for the IT realm to focus
attention on the case where all communication is done over
a network.  Sure, we may use biometrics or the like for
end user identification, but that is a very local situation.
By the time any access control is managed across the network,
any sort of physical tie-in is lost.

When considered over a network, the notion of ACL access
control takes on what is for me a peculiar dimension.
It seems to me this amounts to binding a more complex and
dynamic list based mechanism through a single "capability"
(that of the identity) that can become associated with
a communication channel (e.g. an encrypted, signed
ssl channel).  I can't conceive of any practical mechanism
to enforce "non-delegatability" of such an identity.  I
suppose one could do something like 100 questions to
set up every channel, but I don't consider such an
approach "practical".  Perhaps others have thoughts
on this?

Assuming that the identity "capability" is
delegatable, at least at the level of human
communication (as Marc Stiegler so often points
out), then what value is provided by using
an ACL sort of approach to manipulate permissions
within the authority associate with a single
"identity"?  From my perspective the consequences
of such an architecture are all negative:

1.  It makes it difficult to impossible to
delegate fine grained access for POLA
management of work, and

2.  It makes the one commonly used "identity"
permission especially bulky and sensitive.

Of course one might argue that an ACL mechanism
provides a focus for policy decisions, auditing,
and control, but I believe we have shown that
Horton-like mechanisms can provide all these
values while still retaining the values of
fine grained POLA.  With such a Horton on
OCaps, delegation is nominally POLA, with policy,
auditing, and management only happening within
the POLA delegated permissions.  Considering
just the semantics (not regarding implementation
issues, performance, etc.) this seems only

None the above discussion has anything to
do with high or low security.  One can
certainly obtain higher protection for
data by not connecting any computer that
touches it to a network with wide
connectivity.  Even that says nothing
about ACLs or delegatability.  Within
a "high" security network, it seems to
me all the above discussion applies.

I just thought I'd contribute some thoughts
to show I'm listening.


More information about the cap-talk mailing list