[cap-talk] Delegation/Proxy equivalence and limited lifespanobjects?
capibara at xs4all.nl
Mon Nov 12 14:09:40 EST 2007
On Mon, November 12, 2007 18:16, Karp, Alan H wrote:
> Rob Meijer wrote:
>> When trying to defend that proxying and delegation of
>> permissions would
>> be equivalent from a authority point of view, the folowing was brought
>> as an argument against delegation:
> I don't think that's the argument people are making. When members of
> the ACL community hear about delegation with capabilities, they
> uniformly say "but you're losing control." I then point out that
> someone who wants to delegate but is prevented from doing so can always
Yes exactly, I am trying to make the point that a 'no re-delegation'
bit would be a useless feature from an authority view, as it would be
impossible anyway to stop re-delegation as Bob could always act as a
and Alice could use a simple pattern to make the delegation to Bob revocable.
I got my argument invalidated by the facts that Bob would have a limited
lifetime not directly related to that of Alice.
The argument I got back was that eventhough Carol should not have received
authority for the file reference in the first place, the proxy version
would limit the damage to the timeframe of the existence of Bob, while the
delegation as you state would "remain" out of controll.
> The result of blocking delegation is to make it harder to get
> work done without adding security. That's not the same as claiming that
> delegation and proxying are equivalent.
Do you feel the abouve shows there is 'some' added security to proxying
over delegation here (even with attenuation patterns in place), that would
be a valid reason to implement a no-re-delegate bit ?
I seem to be unable to refute the abouve, although I have a strong feeling
that something is wrong in the abouve observation, I can however not give
any proven example of any attenuation pattern that would result in the
same (or better) security properties as the proxying example where some
objects have a limited lifetime.
More information about the cap-talk