[cap-talk] Another "core" principle - Brinkmann

[David Hopwood]

Jed at Webstart wrote:
> I'll just clarify that all of these actions are what I'm assuming the
> people involved wanted:
> 
> 1.  Alice -> Bob -> Carol -> Dave  ("->" indicates delegates to),
> 
> 2.  Bob's access is revoked,
> 
> 3.  Carol is introduced to Alice and Alice decides that Carol
> should be trusted with the authority delegated to her from
> Alice via Bob.
> 
> Namely, Alice delegated to Bob as part of her work.
> Bob delegated to Carol as part of his work.  Carol
> delegated to Dave as part of his work.
> 
> Bob leaves the organization or otherwise has his
> access revoked.  Note that this only becomes an
> issue because we're trying to add value by allowing
> these sorts of delegations to begin with (which nominal
> ACL systems cannot do) AND we want the delegations
> to be revokable (which ACL systems can do - at least
> for those who have write access to the ACL for an object).
> 
> At this point Bob's access is revoked.  The right thing
> happens and the access delegated to Carol and thence
> to David becomes unusable.
> 
> Carol or Dave complain and say they can no longer get their
> work done.  If they should no longer have the access that
> Bob delegated through Carol, then the right thing is happening
> and that's it.
> 
> However, what about the case (common in ACL systems)
> where Carol (and thence Dave) should have some of the
> access that Bob delegated independent of Bob?

If it is really independent of Bob, then it will be via a different
reference/capability. So there is no problem: that reference will not
have been revoked.

If Carol tries to invoke the reference it got from Bob, however, that
invocation *should* fail, regardless of whether Carol has another
reference on which the same request would have succeeded. (Otherwise
we have something like a "bag of permissions" system that is vulnerable
to confused deputy attacks.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>