[tahoe-dev] [cap-talk] time-based authority

[David-Sarah Hopwood]

Raoul Duke wrote:
> David-Sarah Hopwood wrote:
>> Manual revocation, based on some user interface to a database that
>> remembers all capabilities that have been granted (and metadata about
>> the principal they were granted to, the context, etc.), would in most
>> cases be far preferable.
> 
> pardon me for stating the obvious follow on, but i will:
> 
> and one could build the time expiry feature on top of that, if such
> need really exists.

... or more generally, any arbitrary revocation policy that can be
expressed in the code of a revocation agent, or several such agents.

Caveat: if revocation always (or even sometimes) requires an explicit
action, then it is desirable to minimize the impact of denial of service
attacks against the revocation mechanism, since such attacks may be
easier than more direct attacks against integrity. The way I would
suggest to do this is not to automatically revoke an object on expiry
of a timeout, but instead to *suspend* operations on the object on
expiry of a timeout (effectively a lease), and have the revocation
agent for the object periodically renew the lease before it is due
to expire. Then, the object will recover from a DoS attack if and when
its revocation agent recovers, and its clients will only have been delayed.
(If a particular client depends on timely service, then it should
implement its own timeout.)

In an event-loop system, it may be sufficient to suspend objects only
between turns, I think.

-- 
David-Sarah Hopwood ⚥