[cap-talk] the prize - risks w. "password capabilities", "path
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
> 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