revocability and transivity of capabilities

5.15: adda/cap'based/revocable capabilities:
. I'm seeing how to do revocable capabilities
-- the same way as concurrency:
the client is given the server's mail box,
the client sends a link of who they are
and which client mail box the result is wanted in;
then the client id is ok'd with security
-- asking: (does client x have access to service y ?).
web:
Grand Unified Capabilities/Advantages:

embodies OrthogonalSecurity, FineGrainedHistory,
BidirectionalCapabilities .
. One achieves orthogonal security
in precisely the same way as TransparentPersistence:
by building it in at such a low level
that programmers never see it .
It entails pervasive use of the FacetPattern
(Restrict an interface to obtain a smaller interface
that provides less authority)
and the PrincipleOfLeastPrivilege.
. see security patterns:
FacetPattern
CaretakerPattern
ProtectionProxy
UserPassword
PermissionFlags
TwoKindsOfCapabilities
RevokableCapabilities

5.15: adda/cap'based/transivity of capabilities:
. if you give A access to B, and B access to C,
you are implicitly giving A access to C;
so, if you wanted to deny A access to C,
you have to check the capabilities of
everything A is allowed to call .