[cap-talk] Declaring a victory

[Jed Donnelley]

----- Original Message -----
From: Mark Miller <erights at gmail.com>
Date: Saturday, August 11, 2007 3:36 am
Subject: [cap-talk] Declaring a victory
To: "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>

> Our Hotsec talk on Horton
> <http://www.erights.org/elib/capability/horton/> went over like a lead
> balloon. It's not that people didn't like it, it's just that people
> mostly didn't care. We got very few questions and discussion. Perhaps
> it's partially because we were the second talk so people weren't awake
> yet.

I'll mention a couple of other things regarding Horton discussions
at the meeting.   While, as MarkM noted, there were no significant
questions or interactions about Horton after our presentation,
I (at least, I don't know about MarkM or others) became engaged
in at least four or five discussions where the hooks that Horton
provides for injecting policy when delegating authority from one
identity (e.g. and especially a person) to another turned out to
be the crucial mechanism to turn around some thinking to feel
that capabilities might be the answer to their problem.

In general these were all variations along the lines of the
"loose" capability fear.   That is, people in many cases express
concern that once a program has a capability it can share that
capability 'anywhere' (i.e. loosely).  In particular with anyone.

It surprised people and allayed some fears to hear that
capability mechanisms can provide the abilities to:

1.  Ask where a capability has been delegated, and
2.  Revoke capabilities that have inappropriate
     delegations

as we have discussed with Horton on this list.

However, I was surprised when a couple of additional
possible uses for the Horton hooks (policy injection
across id to id authority communication) came up:

3.  Most surprising to me was the reemergence
in a new (and to me more reasonable) form of the
'pass once' mechanism for capabilities (e.g. as seen
as an effort to combat communicating conspirators
in a number of historical capability systems like
Demos, Mach, and others).  In this context it becomes
'delegate once' or as might be more meaningful
at this "ID" level, 'don't re delegate'.

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.

However, in the context of higher level identities
(e.g. people) I believe a "do not re delegate" policy
makes good sense and fits in as an effective
additional potential policy in a suite of voluntary
oblivious compliance policies (to use AlanK's
term).  With such a "do not re delegate" policy
(e.g. parameter to a Horton hook) in place,
communication of capabilities can still be
done within the responsibility of a single
identity.  It's only when delegating to another
identity (e.g. person) that the block takes effect.

4.  Another place where the potential for a
Horton hook provided value was what might
be called "group" control (again VOC = Voluntary
Oblivious Compliance).   Where this came
up was in discussion about a situation where
one might want to allow delegation between
people within an organization, but put up a VOC
block if an attempt was made to delegate
outside the organization.  The Horton
mechanism can be used for such control.

It was very helpful to have the hooks for such
policies available.  People were always
surprised that such policies could be supported
with capabilities.  In all cases it gave them a
new perspective on capabilities and some
indicated an interest in taking a new look at
capabilities as a mechanism that might help
them solve problems they were dealing with.

The way I read these interactions is that now
capabilities can be considered when traditionally
ACL sorts of mechanisms are wanted.  E.g.
who has access?  Remove access for this
person.  Don't allow anybody else to access.
Only allow access from within this group.

This is a big change in people's thinking about
capabilities.

--JED  http://www.nersc.gov/~jed/