[cap-talk] Definition of "persistence" - a step back

[Jed Donnelley]

cap-talk,

I've followed the various discussions of "persistence" with
interest.  However, occasionally I've had the feeling that
I may not be thinking of the same "persistence" as others.

Let me first state something that I hope we can agree
on with regard to the Principle Of Least Authority.

Application of POLA is just as important/appropriate in
the temporal dimension as it is in the "physical" or
domain dimension.  That is, it is just as important
to revoke (disable) capabilities when they are no
longer needed as it is to avoid delegating unnecessary
authorities via capabilities to begin with.  Only by
so disabling capabilities can POLA be achieved.

Capabilities may not be particularly natural as
a means of revocation, but revocation can certainly
be achieved with capabilities - even, as we've noted
with Horton, revocation of individually (POLA)
delegated capabilities based on "who" has been
delegated responsibility for them.

When I started the "Persistence as a cap value"
thread, I wasn't arguing that capabilities should
remain valid even when no longer needed.
What I was talking about were capabilities and
their objects that remain available after a system
is restarted.

So, my definition of persistent capabilities is:

Definition: Capabilities are "persistent" if
they can be used to access referenced objects
after the system that supports the referenced
objects is restarted.  "Persistent" capabilities
are valid until they are revoked or until they
fail in a manner unintended by their design.


Can we agree on the above definition or something
like it?  I don't think I can fully participate/
understand the "persistence" threads until I
fully understand what is meant by "persistence",
so I welcome discussion of this definition.



 From my perspective capabilities and their objects
that become invalid or disappear when a system
is restarted are capricious and provide less
(or in some cases no) value to the management
of access control that I believe is needed.

For example, in the case of distributed systems
(always my focus), capabilities and/or their objects
that disappear on one system's restart must necessarily
appear less reliable and somewhat capricious to
other systems that don't restart.

Also, as we've discussed, capabilities that disappear
on system restart can't be used to provide a lasting
means for managing access to objects that do 'persist'
between system restarts.  With such non persistent
capabilities some other persistent means must be used
to support management of access control for persistent
objects.


I want to better understand the "Styles of Persistence"
thread, but I feel I can only do so if I'm certain
we share a common understanding of how we're using
the "persistence" term.

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