[cap-talk] Can Capabilities be configured?

[Kevin Reid]

On Mar 17, 2010, at 14:24, Yuvaraj Athur Raghuvir wrote:

> Hello,
>
> I have just started looking into Capability based Objects and  
> learning E. I am impressed by how the simple and powerful the  
> Granovetter Diagram is. The E language design is interesting and I  
> am enjoying the way the language has been designed.
>
> After understanding the difference between the Capabilities and  
> Access Control Lists (ACLs), one question that came up in my mind  
> was how to 'externally configure' capabilities.
>
> In a way this an oxymoron as capabilities are designed to be granted  
> to enable use. However, in real life situations of software use, it  
> seems that all possibilities of flow of capabilities might not be  
> possible to define up front and so embed that flow in code.

Arguably, which is 'up front' is exactly backwards from this. Taking  
another perspective:

ACL systems configure a single policy (the ACL) up front and it is  
completely inflexible since it is only altered by administrators.  
Capabilities, on the other hand, adapt as needed because running code  
delegates access as immediately needed.

Don't think about the access decisions as being compiled into the  
code; think of them as being performed at run-time rather than in a  
relatively static configuration file.

> It seems to me that ACLs are successful because of the late  
> configuration possibility - the custodians of a resource can decide  
> who has access and this is recorded in a look-up table.
>
> Now,
> 1) Can capabilities be late configured?
> 2)Will that violate the fundamental principles of how capabilities  
> are designed?
> 3) If late configuration is possible, is there a pattern that shows  
> how this can be done?

If we take "late" as meaning "independently of the application code",  
then the closest analog is voluntary oblivious compliance (VOC)  
patterns. Here, a capability is delegated but with the mediation of  
the VOC subsystem which makes a decision about whether to refuse or  
attenuate the passed capability. It is named voluntary because the  
passer is not prohibited from delegating their own capability, and  
oblivious because the passer does not know the details of the policy.

E in a Walnut has a section on VOC: <http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Oblivious_Claim_Check:_Loan_Officer_Protocol 
 >. Alan Karp is the person to go to for more info on the VOC concept.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>