[cap-talk] the prize - risks w. "password capabilities", "path based"

Ian Grigg iang at systemics.com
Mon Oct 25 20:12:31 EDT 2004

Jed Donnelley wrote:

> It seems to me this discussion is getting somewhat confused because
> different levels are sometimes getting mixed.  We can speak of 
> communication
> of capabilities (rights) and communication of data (perhaps including
> parts of the internal representation of a capability to be sure),
> but of course communicating the representation of a capability
> at some point may well not communicate the right that the
> capability's representation conveys from one context to another.

Talk about the communication of *data* seems to be out
of scope.  If there is an actual requirements, then
it could be simply modelled as communication of a cap
to read the data.

( Also, it seems to me that talking about whether the
bits are readable and whether this can be turned into
a capability by an eavesdropper is too far into the
implementation details.  It seems sufficient to say
that a capability can be communicated from one party
to another securely, and let the designer work out
just how secure he can make it. )

Along the lines of modelling capabilities, it occurs
to me that a capability is a resource in itself.  In
which case, can one have a capability to a capability?
Where this might be interesting is in discussion of
proxying, and also revocation.  Revocation could be
modelled as an "off" capability to a capability that
is sent off from Alice to Carol.

> The "prize" that I am shooting for is the ability to communicate rights
> fully, exactly, ... - independent of where the source and destination
> are.  Anybody that wishes to proxy and/or audit or restrict (e.g.
> with revocable rights or rights that time out or whatever), etc. a right
> before communicating it may of course do so.  That would depend on
> the intended use of the communicated right, the trust of the receiver, etc.
> However, I don't believe any such restrictions or policies should be tied
> into the fundamental underlying rights communication mechanism.
> E.g. I may want to communicate a full and unaudited right remotely
> and I may want to communicate a very restricted, fully audited and
> revocable (etc.) right locally.

I'd agree.  Tying a capability to one and only one
communication channel (some sort of logical connection)
seems to be moving towards access control.  It would
seem that a capability should be usable by anyone who
can get their hands on it.

iang, from the peanut gallery

More information about the cap-talk mailing list